Subject: RE: [MEDIACTRL] Conferencing Query

From: "Chris Boulton" <[email-masked]>
Date: Tue, 14 Nov 2006 17:45:22 -0000

Ok - IMHO this type of scenario is out of scope and implementation
specific.  For example I don't totally agree that terminating the
sessions is the best first step - to me this would be a cascaded
conference managed by the AS where one media server instance is made a
participant of another media server instance.  As long as such scenarios
are possible using the MediaCtrl solution - then that's as far as we
should go.

Chris.

-----Original Message-----
From: Rahul [mailto:[email-masked]] 
Sent: 14 November 2006 13:07
To: [email-masked]
Subject: [MEDIACTRL] Conferencing Query

All,
      Is the domain of MediaCtrl covers the scenario in which two
conferences on two different media servers can be joined by application
without clearing the existing connections on respective media servers?
To elaborate assume AS controls two media servers MS1 and MS2:
One conference C1 is going on MS1 with say 10 members and other
conference
C2 with 10 members is going on C2. Now AS wants to join the conference
C1
and C2. 
Currently this will be performed by AS through deleting the sessions on
either of MS and creating new legs on the other MS and updating the
associated parties SDP through UPDATE or reINVITE.
This is quite an overhead for AS (Consider the application when already
existing conference want to join some conference and leave it quite
frequently).
AS should be able to send a message to both MS for the corresponding
conference's Mixer Ports and exchange SDPs for corresponding Mixer Ports
so
that two conferences can be joined on two separate media servers. 
Will these scenarios be addressed by MediaCtrl group?

Regards,
Rahul

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl

Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation.  All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email.  Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding.  Thank you.

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl

---

From: "Braudes, Robert \(Bob\)" <[email-masked]>
Date: Wed, 15 Nov 2006 06:59:19 -0500

I'm sorry if I implied that this group should be involved with inter-media server state sharing, as that was not my intent.  I definitely agree that this is out of scope. 

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: Wednesday, November 15, 2006 11:31 AM
To: Braudes, Robert (Bob); [email-masked]
Subject: Re: [MEDIACTRL] Conferencing Query

Let's not confuse implementation with architecture.

There is nothing to prevent one having an implementation where the media servers are distributed.  So long as they look like a single media server, great.  We should be very mindful not to put anything in the protocol to make that hard.  An example would be referencing conference legs by RTP (IP:port), as that could move.  Conversely, using SIP for location (which allows a server farm) and referencing legs with SIP dialog identifiers makes it easier to build distributed media servers.

What would be very much out of scope for now is the inter-media server state sharing required to make cross-media server mixing possible.

On 11/15/06 4:18 AM, "Braudes, Robert (Bob)" <[email-masked]> wrote:

> From my experience, connecting multiple media servers is managed by 
> the AS using the same protocol as is used to direct an MS to add an 
> endpoint to the mix, and I expect whatever we specify to be used in 
> this fashion whether it is our "explicit" intent or not.  That said, I 
> don't have a good suggestion for how to state this in the charter.  
> Perhaps Eric's suggestion of having it initially out of scope but 
> slated for inclusion at a future time is the best compromise, but I have a feeling it may cause some short- to medium-term pain.
> 
> Bob
> 
> From: Eric Burger [mailto:[email-masked]]
> Sent: Wednesday, November 15, 2006 1:11 AM
> To: [email-masked]
> Subject: Re: [MEDIACTRL] Conferencing Query
> 
> <chair hat off>
> Distributed conference mixing is very hard.  As Lorenzo points out, 
> distributed video conference mixing is very, very, very hard and not 
> understood.
> 
> For example, consider the n-loudest audio algorithm.  I may have the 
> three loudest talkers hosted on media server X.  If we blindly mix 
> media server X's conference with media server Y's, we might have the 
> top 3 talkers from X get mixed with talkers # 4 and 5 on media server Y.
> 
> There are algorithms and methods for exchanging state between media servers.
> [In the interests of full disclosure, we have a patent application on 
> the technology, filed in 2002; I'm sure there's lots of similar prior 
> art.]  It is hard, and there is a lot to convey with a VERY short latency budget.
> 
> The good news is humans naturally have a CSMA algorithm.  If things 
> get garbled, they wait and jump in asking people to repeat.
> 
> Reinforcing Lorenzo's point (and why I'm using his message as the 
> launch point for this comment), distributed video mixing is a RESEARCH 
> project, not an ENGINEERING project.
> 
> <chair hat on>
> I would offer that since video mixing is a research project and that 
> audio mixing has a layer 8 solution, postponing work on distributed 
> media server coordination is not a deal-killer.  How is this for proposed language:
> 
> 
>    Distributed conference mixing, such as tying together two distant
>    media servers each hosting some portion of a larger conference, is
>    explicitly out of scope.  However, we would expect that this would
>    be a timely topic for a rechartering activity after the work group
>    completes other priority work.
> 
> 
>    is comp
> 
> 
> On 11/14/06 11:42 AM, "Lorenzo Miniero" <[email-masked]> wrote:
> 
>> Hi Rahul,
>> 
>>> All,
>>> conferences on two different media servers can be joined by 
>>> application without clearing the existing connections on respective 
>>> media servers?
>>> C2 with 10 members is going on C2. Now AS wants to join the 
>>> conference C1 and C2.
>>> Currently this will be performed by AS through deleting the sessions 
>>> on either of MS and creating new legs on the other MS and updating 
>>> the associated parties SDP through UPDATE or reINVITE.
>>> This is quite an overhead for AS (Consider the application when 
>>> already existing conference want to join some conference and leave 
>>> it quite frequently).
>>> conference's Mixer Ports and exchange SDPs for corresponding Mixer 
>>> Ports so that two conferences can be joined on two separate media servers.
>> The case you're depicting is very close to a distributed conferencing 
>> point of view, and I don't know if it actually fits in the charter.
>> However, I'll give you my opinion about it, since here at University 
>> of Napoli we've already started studying the possibility of realizing 
>> distribuited conferencing scenarios based upon XCON.
>> In my opinion, not clearing the existing connections and keeping 
>> every conference, user and resource on the MS they were before the MS 
>> join, would of course give more than one problem. While audio 
>> wouldn't probably give much problems (the MSs could just exchange the 
>> already mixed streams between each other, and locally mix them with 
>> their own as if it came from a single user), video would, expecially 
>> considering the case of multiplexed video with sources on both the 
>> MSs: how could it be handled? Another potential solution to not clear 
>> the existing connections could be the forwarding of the incoming 
>> streams from one server (who would transparently act as a MS proxy 
>> for its users from that moment on) to the other (who would become the 
>> master MS of both the conferences), even if this would introduce 
>> latency, and probably other problems too.
>> However, these are just rough conceptual ideas at the moment. I'm 
>> really interested in your opinions about this matter, if it's not 
>> off-topic for this WG, of course...
>> 
>> Cheers,
>> Lorenzo
>> 
>> --
>> Lorenzo Miniero, Junior Researcher
>> Dipartimento di Informatica e Sistemistica Università degli Studi di 
>> Napoli "Federico II"
>> Via Claudio 21 -- 80125 Napoli (Italy)
>> Phone: +390817683821 - Fax: +390817683816
>> Email: [email-masked]
>> 
>> 
>> --
>> Il messaggio e' stato analizzato alla ricerca di virus o contenuti 
>> pericolosi da MailScanner, ed e'
>> risultato non infetto.
>> 
>>

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Fri, 17 Nov 2006 15:48:20 +0100

The text as proposed implies that there might be an interface directly between two media servers which could be in scope in a future discussion. I would have said that such would be entirely out of scope. I assume the paragraph was meant to relate only to the application to media server covering such communication.

I am also not keen on mentioning future work on distrubuted conferencing as in scope even if done later. I thought XCON explicitly excluded it, and perhaps we should do likewise. If the group completes its initial work, and work has advanced sufficiently, then is the time to consider whether a rechartering should take place to consider it in scope.

Regards

Keith

> Sent: 15 November 2006 01:11
> To: [email-masked]
> Distributed conference mixing is very hard.  As Lorenzo 
> points out, distributed video conference mixing is very, 
> very, very hard and not understood.
> 
> For example, consider the n-loudest audio algorithm.  I may 
> have the three loudest talkers hosted on media server X.  If 
> we blindly mix media server X's conference with media server 
> Y's, we might have the top 3 talkers from X get mixed with 
> talkers # 4 and 5 on media server Y.
> 
> [In the interests of full disclosure, we have a patent 
> application on the technology, filed in 2002; I'm sure 
> there's lots of similar prior art.]  It is hard, and there is 
> a lot to convey with a VERY short latency budget.
> 
> The good news is humans naturally have a CSMA algorithm.  If 
> things get garbled, they wait and jump in asking people to repeat.
> 
> Reinforcing Lorenzo's point (and why I'm using his message as 
> the launch point for this comment), distributed video mixing 
> is a RESEARCH project, not an ENGINEERING project.
> 
> <chair hat on>
> I would offer that since video mixing is a research project 
> and that audio mixing has a layer 8 solution, postponing work 
> on distributed media server coordination is not a 
> deal-killer.  How is this for proposed language:
> 
> 
> >> application without clearing the existing connections on 
> respective media servers?
> >> already existing conference want to join some conference 
> and leave it 
> >> quite frequently).
> > In my opinion, not clearing the existing connections and 
> keeping every 
> > conference, user and resource on the MS they were before 
> the MS join, 
> > would of course give more than one problem. While audio wouldn't 
> > probably give much problems (the MSs could just exchange 
> the already 
> > mixed streams between each other, and locally mix them with 
> their own 
> > as if it came from a single user), video would, expecially 
> considering 
> > the case of multiplexed video with sources on both the MSs: 
> how could 
> > it be handled? Another potential solution to not clear the existing 
> > connections could be the forwarding of the incoming streams 
> from one 
> > server (who would transparently act as a MS proxy for its 
> users from 
> > that moment on) to the other (who would become the master 
> MS of both 
> > the conferences), even if this would introduce latency, and 
> probably 
> > other problems too.