Subject: [SIP] Invitation for a multicast session

From: Baniel Uri-CUB001 <[email-masked]>
Date: Fri, 1 Jun 2001 15:31:23 -0500

My understanding is that a UAC can invite an individual or 'the first one to
respond' from a group to a multicast session, but a UA can not invite the
whole group by multicasting an Invite to the group. Is that true?

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

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Sun, 3 Jun 2001 02:15:33 -0400

> -----Original Message-----
> From: Baniel Uri-CUB001 [mailto:[email-masked]]
> Sent: Friday, June 01, 2001 4:31 PM
> To: [email-masked]
> Subject: [SIP] Invitation for a multicast session
> 
> 

Yes. I should have been clearer that when I talking about inviting a group,
I meant that the invitation was destined for any member of the group, not
all of them. 

-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: Baniel Uri-CUB001 <[email-masked]>
Date: Sun, 3 Jun 2001 07:58:26 -0500

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?? 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...

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Sunday, June 03, 2001 1:16 AM
> To: 'Baniel Uri-CUB001'; [email-masked]
> Subject: RE: [SIP] Invitation for a multicast session
> 
> 
> 
> 
>  
>

---

From: "Ashutosh Dutta" <[email-masked]>
Date: Sun, 3 Jun 2001 13:03:13 -0400

It would be helpful if we can use one multicast INVITE to invite the group
members to an Mbone conference (which is of course can be a different
multicast address), otherwise just four unicast INVITEs to join the  mbone
session should do the trick. Would multicasting  4 INVITEs be better than
unicasting 4 INVITEs in any way?

Thanks
Ashutosh

Baniel Uri-CUB001 <[email-masked]> on 06/03/2001 08:58:26 AM

To:   "'Jonathan Rosenberg'" <[email-masked]>,
      [email-masked]
cc:    (bcc: Ashutosh Dutta/Telcordia)
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??
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...

---

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

Yes, yes, sorry when I said ACK I meant Cancel...
Okay I think I have bombarded the list enough with this...

> From: Vijay Gurbani [mailto:[email-masked]]
> Sent: Monday, June 04, 2001 11:27 AM
> To: Baniel Uri-CUB001
> Cc: 'Varadarajan Srinivasan'; [email-masked]'
> Subject: Re: [SIP] Invitation for a multicast session
> 
> 
> Baniel Uri-CUB001 wrote:
> > 
> > According the spec after you get a 200 Ok you are not 
> supposed to send an 
> > 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
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Jun 2001 01:28:13 -0400

> Sent: Monday, June 04, 2001 10:36 AM
> To: 'Jonathan Rosenberg'; [email-masked]'
> 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...)

Sounds like its time to repeat the mantra:

All transactions complete independently.
All transactions complete independently.
All transactions complete independently.

Applying our beloved mantra here, the UAC will ACK both, and then send BYE
to the ones it doesn't want. As Vijay has pointed out, this is much clearer
in the current spec.

-Jonathan R.

---