Subject: RE: [Sip] multicast conference service of SIP

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Wed, 28 Nov 2001 08:56:18 -0500

-----Original Message-----
From: Lei Liang [mailto:[email-masked]]
Sent: Wednesday, November 28, 2001 4:30 AM
To: Jonathan Rosenberg
Cc: [email-masked]
Subject: RE: [Sip] multicast conference service of SIP

hi, Jonathan, 
   for the centralized signaling model, the MCU or the centre controller
may become the bottleneck of the conference and risk to fail the whole
conference upon its failure. isn't it?

[RRR] Yes, this risk remains with the centralized conferencing. So, what
people might do is to build redundancy in MCUs or controllers. However, the
redundancy in configurations is outside the scope of standard.

[RRR] In fact, the centralized conferencing is being offered commercially.

[RRR] However, I do believe that there can be more scalable conferencing
protocol architecture in centralized conferencing as well. For example, a
single MCU or controller may not scale in a large network or a conference
may spread the boundary of multiple service providers. In this situation,
there will be multiple MCUs or controllers where a central MCU/Controller
will act the master one while the other MCUs/Controllers will act the slaves
(a kind of tree-like architecture). This is where we also need to put our
energy for standardization. First, we need to write a functional requirement
document and, then we need to find how SIP conferencing services can be
offered in a standard way for the sake of interoperability. Hope that we
would move in that direction soon.

cheers,
lei

On Tue, 27 Nov 2001, Jonathan Rosenberg wrote:

> 
> 
>  
> 
> > -----Original Message-----
> > From: Lei Liang [mailto:[email-masked]]
> > Sent: Tuesday, November 27, 2001 1:07 PM
> > To: [email-masked]
> > Subject: [Sip] multicast conference service of SIP
> > 
> > 
> > hi, falks,
> >   for the case of multicast conference service using SIP as signalling
> > protocol, I know from 
> > draft-ietf-sipping-conferencing-models-00.txt that
> > only media streams are transported using multicast rather 
> > than multicast
> > signalling. I now wondered if a callee can know all of the 
> > rest existing
> > users in the conference upon receipt of the first INVITE and 
> > if it should
> > establish sip connections with all of them. 
> 
> What you are talking about is fully distribute multiparty conferencing,
> which uses a full mesh of signaling relationships among participants.
Thats
> a really hard problem, and not a conferencing model there appears to be
real
> demand for. We've been around the bush a few times on it, and never came
up
> with a simple yet correct solution. Centralized signaling for conferences
> (whether its "centralized" in a handset or the network is irrelevant) is
> well understood and easily done with SIP, so that is the area work has
> focused on.
> 
> -Jonathan R.
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Lei Liang <[email-masked]>
Date: Wed, 28 Nov 2001 14:33:57 +0000 (GMT)

hi, Jonathan,
  thanks indeed for your explanation. 
  I am not sure why you insist that the centralized system is better.
I am also not sure if you mean that all of the stream(signaling and media
data) should be handled by the central controller.
 I personally think that maybe a centralized sip signaling server plus a
multicast RTP solution is not bad. the central server handles signaling
and session control information(includes status distribution). hence, it
won't face the bandwidth problem as well as realise some other service,
e.g. billing. when the multicast address problem is solved, RTP multicast
then can be adopted by large number of conference while all of them can
share the same signaling and control center.
cheers.
lei