Subject: RE: [MEDIACTRL] Conferencing Query

From: "Braudes, Robert \(Bob\)" <[email-masked]>
Date: Wed, 15 Nov 2006 04:18:10 -0500

>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

-----Original Message-----
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,
>>       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
>>  
> 
> 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.
> 
> 
> _______________________________________________
> MEDIACTRL mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mediactrl
> 

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

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

---

From: Eric Burger <[email-masked]>
Date: Wed, 15 Nov 2006 06:30:45 -0500

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
> 
> 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:
> 
>