Subject: RE: [SIP] Invitation for a multicast session

From: Baniel Uri-CUB001 <[email-masked]>
Date: Mon, 4 Jun 2001 11:04:53 -0500

According the spec after you get a 200 Ok you are not supposed to send an ACK but rather you should send a BYE...

================================================================= 
[email-masked], 
Tel: (847) 632 4616; Fax: (847) 632 3963; 
"Only by learning do we discover how ignorant we are" E.w.c 
================================================================= 

-----Original Message-----
From: Varadarajan Srinivasan [mailto:[email-masked]]
Sent: Monday, June 04, 2001 10:35 PM
To: Baniel Uri-CUB001
Cc: [email-masked]'
Subject: Re: [SIP] Invitation for a multicast session

Hi , 

I feel A's proxy will send ACK to B and CANCEL to C ( I read somewhere that CANCEL 
is of the same transaction as that of  the INVITE). 

Regards, 
Varadarajan 

Baniel Uri-CUB001 wrote: 

OK now it is really clear! Thanks!! 
Anyways in case a "race" condition has happened and both stations (say B and 
C) responded with a 200 OK. (i.e. despite of the delay-response and Cancel 
mechanisms described in the spec), what is the correct behavior of the UAC? 
Say he wants to accept B and reject C, does it need to Ack C (in order to 
complete the 1st transaction) and then right away sends it a BYE? 
(I know I am actually asking here a generic and probably a naive/basic 
question regarding how a UAC should behave in case it does not want to 
accept the 200...) 

================================================================= 
[email-masked], 
Tel: (847) 632 4616; Fax: (847) 632 3963; 
"Only by learning do we discover how ignorant we are" E.w.c 
================================================================= 

> -----Original Message----- 
> From: Jonathan Rosenberg [ mailto:[email-masked] <mailto:[email-masked]> ] 
> Sent: Sunday, June 03, 2001 10:43 PM 
> To: 'Baniel Uri-CUB001'; [email-masked] 
> Subject: RE: [SIP] Invitation for a multicast session 
> 
> 
> 
> 
> 
> 
> > -----Original Message----- 
> > From: Baniel Uri-CUB001 [ mailto:[email-masked] <mailto:[email-masked]> ] 
> > Sent: Sunday, June 03, 2001 8:58 AM 
> > To: 'Jonathan Rosenberg'; [email-masked] 
> > Subject: RE: [SIP] Invitation for a multicast session 
> > 
> > 
> > So just to be 100% sure that I got this one right once and 
> > for all... say I like to invite A, B, C and D who belong to 
> > the same multicast group, to a conf call (mbone session). Say 
> > I like to invite them by multicast means. 
> > Do I have to multicast 4 Invites (each with a different 
> > request-URI and To fields(e.g. [email-masked], [email-masked], 
> > etc.,) or one multicast will do?? 
> 
> Sending the same request four times would completely defeat 
> the purpose of 
> using multicast in the first place. The whole idea with 
> multicast is that 
> you don't know how many recipients there are. So, the answer is "one 
> multicast will do". 
> 
> If one will do, what will 
> > be the request-URI? What will be the To? 
> > Based on your message below I think we need 4 invitations, 
> > but just to be on the safe side... 
> 
> INVITE sip:[email-masked] SIP/2.0 
> From: "Me" <sip:[email-masked]> 
> To: "The Gaggle" <sip:[email-masked]> 
> Via: SIP/2.0/UDP 1.2.3.4;maddr=224.2.3.4;ttl=2 
> 
> Of course, each user in the group would need to be prepared to accept 
> request sfor [email-masked]. Once one decides to accept, 
> they send a 200 
> OK. This triggers a CANCEL by the UAC. As a result, the 
> caller is connected 
> to one of the members of this group, whomever it might be. 
> What SIP cannot 
> do is help you generate a request so that a call is connected 
> to ALL members 
> of the group (this really requires reliable multicast to 
> avoid response 
> implosion). You'll only get the first to answer. 
> 
> -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 <http://www.jdrosen.net>                       PHONE: (973) 952-5000 
> http://www.dynamicsoft.com <http://www.dynamicsoft.com>  
> 

_______________________________________________ 
This list is for continuing development of the SIP protocol. 
The sip-implementor's list is the place to discuss implementation, 
and to receive advice on understanding existing sip. 
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Vijay Gurbani <[email-masked]>
Date: Mon, 04 Jun 2001 11:27:26 -0500

> ACK but rather you should send a BYE...

Nope; where in the spec does it say that?

If a UAC gets multiple 200 OK (INVITE), it should send an ACK to all of them 
to allow the INVITE transaction to complete.  It should then send a BYE to 
all call legs that it is not interested in, maintaining the call legs it is 
interested in.

This behavior is better specified in the latest (-03) bis.  See page 109 of
the PDF version; notice the change bar towards the middle of the page.

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184