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

From: "Mark Zezren" <[email-masked]>
Date: Tue, 27 Nov 2001 16:14:34 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan 
> -----Original Message-----
> From: Lei Liang [mailto:[email-masked]]
...
> 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.

[mjz] 
I think there is demand to know the state of all of the other parties in
a conference. Can a SIP central controller provide information about the
state of other parties to each individual party?

mjz

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Nov 2001 16:34:29 -0500

> From: Mark Zezren [mailto:[email-masked]]
> Sent: Tuesday, November 27, 2001 4:15 PM
> To: 'Jonathan Rosenberg'; 'Lei Liang'; [email-masked]
> Subject: RE: [Sip] multicast conference service of SIP
> 
> 
> real

http://www.jdrosen.net/papers/draft-rosenberg-sip-call-package-00.txt

-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

---

From: "Agboh, Charles" <[email-masked]>
Date: Wed, 28 Nov 2001 16:13:26 +0100

> From: Roy, Radhika R, ALCTA [mailto:[email-masked]]
> Sent: Wednesday, November 28, 2001 2:56 PM
> To: Lei Liang; Jonathan Rosenberg
> Cc: [email-masked]
> Sent: Wednesday, November 28, 2001 4:30 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]
> 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.

What you are actaully describing is similar to the H.332 conferencing model.
This model may or may not work for SIP.  The requirements have not been
defined.  The degree of  scalability of this and other conference model
depends on the capability of the servers to announce ressource usage to
other servers and the granularity of this information....boils down to
server load balancing (depends on your network topology).......

> cheers,
> lei
> 
> On Tue, 27 Nov 2001, Jonathan Rosenberg wrote:
> 
> > 
> > 
> >  
> > 
> > > Sent: Tuesday, November 27, 2001 1:07 PM
> > > To: [email-masked]
> > > Subject: [Sip] multicast conference service of SIP
> > > 
> > > 
> > > hi, falks,
> > with a simple yet correct solution. Centralized signaling 
> for conferences

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Wed, 28 Nov 2001 12:45:59 -0500

-----Original Message-----
From: Agboh, Charles [mailto:[email-masked]]
Sent: Wednesday, November 28, 2001 10:13 AM
To: Roy, Radhika R, ALCTA; Lei Liang; Jonathan Rosenberg
Cc: [email-masked]
Subject: RE: [Sip] multicast conference service of SIP

What you are actaully describing is similar to the H.332 conferencing model.
This model may or may not work for SIP.  

[RRR] The above example is a generic one and, is NOT H.332.

The requirements have not been
defined.  

[RRR] Yes, that is why, the proposal has been made to define one.

The degree of  scalability of this and other conference model
depends on the capability of the servers to announce ressource usage to
other servers and the granularity of this information....boils down to
server load balancing (depends on your network topology).......

[RRR] I brought the issue of scalability, as an example, in the light of the
centralized conferencing that Lei provided. I have expanded that one a
little more in that direction considering MCUs/Controllers only. You are
welcome to bring more things along that line if you want to, but it will be
good to be more specific.

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Wed, 28 Nov 2001 13:19:16 -0500

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

hi, Jonathan,
  thanks indeed for your explanation. 

[RRR] If I understand you correctly, this reply was sent by me (Radhika R.
Roy [RRR], not Jonathan Rosenberg).

  I am not sure why you insist that the centralized system is better.

[RRR] I guess that no one is saying that the centralized system is better.
Rather, people say, how to implement a centralized conferencing system is
better understood (than the distributive one). People are yet to understand
clearly how to implement a distributive one and their implications on
resources.

I am also not sure if you mean that all of the stream(signaling and media
data) should be handled by the central controller.

[RRR] No necessarily. Primarily, I have been pointing to the signaling part.
However, media can also be handled in a similar way if the multicasting is
handled in the application layer. However, the media need to be handled
separately, decoupling from signaling.

 I personally think that maybe a centralized sip signaling server plus a
multicast RTP solution is not bad. 

[RRR] I agree.

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. 

[RRR] Quite possible.

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.

[RRR] This is the area, I guess, where we need to do more work.

cheers.
lei

On Wed, 28 Nov 2001, Roy, Radhika R, ALCTA wrote:

>    for the centralized signaling model, the MCU or the centre controller
> [RRR] Yes, this risk remains with the centralized conferencing. So, what
> people might do is to build redundancy in MCUs or controllers. However,
the
> [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
conferences