Subject: [MEDIACTRL] Conferencing Query

From: Rahul <[email-masked]>
Date: Tue, 14 Nov 2006 18:37:02 +0530

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

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 14 Nov 2006 17:42:52 +0100

Hi Rahul,

> Will these scenarios be addressed by MediaCtrl group?

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: Eric Burger <[email-masked]>
Date: Tue, 14 Nov 2006 20:11:11 -0500

<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

---

From: Rahul <[email-masked]>
Date: Wed, 15 Nov 2006 16:50:51 +0530

All,
     I completely agree with the Eric and Lorenz that distributed media
mixing technology is still in conceptual stage. I also agree that group has
other priority work to be finished and this can be taken up as a later stage
so I agree with wordings of the draft.
But philosophically somehow I find it hard to agree that since no (or not
effective) technology exist for distributed media mixing so we shouldn't
drive it.
May be we can provide some guidelines how this can get implemented on the
basis of current understanding of video/audio mixing.
For example for mixing audios on two conf we can specify some algorithm like
if n-loudest is specified on any of group what algorithm can be used as
common. 
Something like who will be master of two conf can be easily specified!
I think leaving this problem to implementers will again cause lot of issues
in integration when the technology is completely available to us.
I do agree the problems are difficult but we need to figure out some way to
provide some guidelines slowly else we'll see flurry of propriety
distributed conf protocols like we have seen in Unix world till POSIX came.
Regards,
Rahul

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: Wednesday, November 15, 2006 6:41 AM
To: [email-masked]
Subject: Re: [MEDIACTRL] Conferencing Query

<chair hat off>

<chair hat on>

   is comp

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 15 Nov 2006 13:41:07 +0100

Hi Rahul,

> distributed conf protocols like we have seen in Unix world till POSIX came.

I agree with you that some guidelines would be useful, and I'm sure many 
will just come out from our discussions on the ML. As long as the main 
focus will still be the interaction between the AS and the MS which, and 
I agree with Eric on that, should look as a single one even if they're 
actually more than one. The inter-MS control, exchange and 
synchronization protocols could become so complex that they could easily 
take a whole new WG on their own :)
However, as I already said, we at University of Napoli are deeply 
interested in the matter (even if in a slightly different context, which 
is distributed conferencing and thus involving not only more than one 
MS, but also more than one AS), so I'll be glad to share with you any 
consideration about it.

Cheers,
Lorenzo

---

From: "Tim Melanchuk" <[email-masked]>
Date: Wed, 15 Nov 2006 11:02:42 -0800

i agree with eric. the state exchange/coordination is the difficult
part. that is really ms<-->ms work and hence should be out
of scope for mediactrl.

timm