Subject: Re: [Sip] Multicasting in SIP

From: "Samuel Osorio Calvo" <[email-masked]>
Date: Wed, 21 Sep 2005 13:24:00 +0200

Although 3261 left the door opened for multicasting SIP requests, besides the usage of locating registrar servers via a multicast REGISTER, there isn't description for other cases.
So, AFAIK, multicast is just mentioned in the standard and no other draft expands the use of multicast within SIP. Probably the classic multicast issues (insecurity and lack of support) has stopped describing reliable usages. 

Samuel.

Unclassified.
>>> "Thejeswara Reddy.P" <[email-masked]> 09/21/05 11:22AM >>>

 Hai,

   I had a question,

Is there any draft for SIP in case of multicast signalling.

thanks
theja

__________________________________________________________ 
Yahoo! India Matrimony: Find your partner now. Go to http://yahoo.shaadi.com 

_______________________________________________
Sip mailing list  https://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

_______________________________________________
Sip mailing list  https://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: Wed, 21 Sep 2005 08:34:14 -0400

RFC2543 had "more" support for multicast; we had in mind that you could 
send an INVITE to a multicast group for help desk kinds of functions. 
But it proved to be very complicated and the mechanisms in 2543 didn't 
work. The transaction state machine didn't work particularly well for 
multicast and the demand was not there. So the capability was 
significantly reduced in 3261.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Thejeswara Reddy.P" <[email-masked]>
Date: Wed, 21 Sep 2005 16:03:00 +0100 (BST)

hai Rosenberg.
       multicast signalling support in sip may open many applications in iptel such as news on demand.
 
i think some investigation needed in this area.
 
thanks
 
theja

Jonathan Rosenberg <[email-masked]> wrote:

-Jonathan R.

Samuel Osorio Calvo wrote:

>>>>"Thejeswara Reddy.P" 09/21/05 11:22AM >>>
> 
> 
> 
> Hai,
> 
> I had a question,
> 

---------------------------------
 Yahoo! India Matrimony: Find your partner now.

---

From: "Dale R. Worley" <[email-masked]>
Date: Thu, 22 Sep 2005 14:59:25 -0400

> Is there any draft for SIP in case of multicast signalling.

An interesting idea.  It seems to me that one could send a request to a
UDP multicast address to set up dialog(s) much like one does in unicast
-- the request will be forked (by the transport) to many recipients, who
can each reply.  The replies establish a set of dialogs, much like a
forked request does now.  (The proxies or recipients need to Record-
Route a unicast address to replace the multicast address the first
request was sent to.)

But that does not allow a new UA to join the "dialog" by simply
subscribing to the multicast address.  The problem is that SIP is
inherently request/response, much like TCP, and each endpoint needs to
know state about all endpoints that it is communicating with.

But it seems to me that RTP could be sent to a multicast address without
messing up.  So it might be possible to have one UA send a request to a
second UA, and the second UA would negotiate to have media sent to a
multicast address.  So the second UA would act as a substitute for all
the (mute) UAs that are rendering the multicast stream.

Dale

---

From: "Thejeswara Reddy.P" <[email-masked]>
Date: Fri, 23 Sep 2005 05:59:26 +0100 (BST)

Hai Dale,
 This my basic idea.
   1) UAC advertises its multicast address to set of servers and a to set of
receivers as as initial step. all of these will send 200 OK
   2) some of the servers acts as RPs.
   3) Future UAS (intersted in multicast traffic sends JOIN request).
    servers establish binding for them and send 200 OK).

Transport protocol is other than TCP.

thanks 

theja