Subject: RE: [Sipping] Conferencing for UAs

From: "Chris Boulton" <[email-masked]>
Date: Tue, 24 Feb 2004 12:22:10 -0000

>-----Original Message-----
>From: Gonzalo Camarillo [mailto:[email-masked]]
>Sent: 24 February 2004 12:06
>To: sipping
>Cc: Alan Johnston; Orit Levin; Miguel Angel Garcia Martin
>Subject: [Sipping] Conferencing for UAs
>
>Hello,
>
>some comments on the following draft:
>http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-conferencing-
>03.txt
>
>The focus of a conference returns the conference URI in the contact
>header field of the 200 OK for the INVITE. The UAC uses this URI to
>SUBSCRIBE to the conf package (using a new dialog)...
>
>Why are we forcing the focus to use the same URI for receiving the
>INVITEs from all the users and for receiving the SUBSCRIBEs? I believe
>the solution would be cleaner if we defined a new header field (e.g.,
>Associated-Conf-State) that carried a globally routable URI. The 200 OK
>for the initial INVITE (or the INVITE in a dial-out case) would carry
>this header field. This would keep separate the URI used for joining
the
>conference and the URI used for subscribing to the state of the
conference.

[Chris Boulton] I agree that it would be better to convey this
information separately for instances where the presence module is a
separate entity to the conference focus.

This message has been scanned for viruses by MailControl - www.mailcontrol.com

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

---

From: [email-masked]
Date: Wed, 25 Feb 2004 08:47:36 +0200

Gonzalo:

I see your idea as a future proof solution. Basically, with the current framework, we are assuming that subscriptions and other state information is kept in the same entity that has established the dialog, and that probably is the common case today. I don't see any application today that would need to split and send pointers to different entities, perhaps in the future, but I haven't seen that one.

Having said that, I still think that from the point of view of the protocol design it is a clear solution to separate items, and avoid assumptions. Perhaps one of the most frustrating things in protocol design is to find out that "a couple of years ago we design feature foo based on assupmption bar, which is not valid anymore; now we need to patch the protocol". So I would support your proposal.

/Miguel

> From: ext Gonzalo Camarillo [mailto:[email-masked]]
> Sent: 24 February, 2004 16:26
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; Garcia
> Miguel.An (Nokia-NRC/Helsinki)
> Subject: Re: [Sipping] Conferencing for UAs
> 
> 
> Hello,
> 
> > I don't see what the problem is here and why it is a problem? Why do
> > they need to be separate. Both the INVITEs and SUBSCRIBEs are
> > destined to the same resource.
> 
> You send an INVITE to a conference server that will INVITE 
> the rest of 
> the participants in the conference. This INVITE is creating:
> 
> 1) a dialog
> 2) an INVITE explosion
> 3) a conference
> 
> I find it cleaner to have three separate URIs instead of a single URI 
> where the server figures out what the UAC is trying to do by 
> looking at 
> the contents of the request (in this case, the event header).
> 
> In addition, the application server handling the presence for the 
> conference may not be co-located with the entity handling the SIP 
> signalling for the conference.
> 
> Furthermore, when you deal with requests that do not 
> establish a dialog 
> (e.g., MESSAGE), the server needs to convey the URI of the 
> resource to 
> the UAC using a different mechanism (Contact is not allowed). 
> It would 
> be good to use the same mechanism for requests that create a 
> dialog and 
> for requests that do not create a dialog. This avoids overloading the 
> Contact header field.
> 
> I believe that having something like this:
> 
> Associated-Resource: sip:[email-masked];purpose=conference-state
> Associated-Resource: sip:[email-masked];purpose=explosion-state
> 
> makes it easier for the UAC to know what can be done; it is 
> more explicit.
> 
> Gonzalo
> 
> 
> This communication is confidential and intended solely for 
> the addressee(s). Any unauthorized review, use, disclosure or 
> distribution is prohibited. If you believe this message has 
> been sent to you in error, please notify the sender by 
> replying to this transmission and delete the message without 
> disclosing it. Thank you.
> 
> E-mail including attachments is susceptible to data 
> corruption, interruption, unauthorized amendment, tampering 
> and viruses, and we only send and receive e-mails on the 
> basis that we are not liable for any such corruption, 
> interception, amendment, tampering or viruses or any 
> consequences thereof.
> 
>

---

From: [email-masked]
Date: Sun, 29 Feb 2004 15:16:12 +0200

Hi,

The benefit of having the same URI would be also that you could just SUBSCRIBE to the conference state without even needing to join it via INVITE. I think there could be some application use cases why you would want to do this: for instance a user wants to join a conference only when certain other user or certain amount of users are present. To do this, the user should only need to know the single conference URI.

(Supposedly you could find out the URI to subscribe to with OPTIONS too, but why bother, if it could be the same.)

Markus

> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext Jonathan Rosenberg
> Sent: 25 February, 2004 21:48
> To: Gonzalo Camarillo
> Cc: Garcia Miguel.An (Nokia-NRC/Helsinki); [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Sipping] Re: Conferencing for UAs
> 
> 
> 
> I think the same URI makes sense. At the core, there really is one 
> resource here - the conference. All that differs is the 
> methods that are 
> invoked on it and how that resource behaves when users contact it. 
> Subscribing to it and initiating a session to it are two different 
> methods, but both against fundamentally the same resource.
> 
> -Jonathan R.
> 
> Gonzalo Camarillo wrote:
> 
> > Hi,
> > 
> >> Aren't we heading to defining a generic Associated-State 
> header with
> >> a "role" parameter that contains a value "transaction", 
> "conference",
> >> "xxx", etc...
> > 
> > 
> > I actually do not care how we encode this information; in a 
> header with 
> > several parameters or in multiple headers (in any case, you 
> may be right 
> > that using a single header could be cleaner).
> > 
> > What I want to know is whether or not people think that it 
> is worthwhile 
> > keeping separate the URI used for the INVITE dialog and the one (or 
> > ones) used for subscriptions to some piece of state that is 
> associated 
> > somehow with that dialog. My personal opinion is that we 
> should keep 
> > them separate.
> > 
> > Gonzalo
> > 
> > 
> > This communication is confidential and intended solely for the 
> > addressee(s). Any unauthorized review, use, disclosure or 
> distribution 
> > is prohibited. If you believe this message has been sent to you in 
> > error, please notify the sender by replying to this 
> transmission and 
> > delete the message without disclosing it. Thank you.
> > 
> > E-mail including attachments is susceptible to data corruption, 
> > interruption, unauthorized amendment, tampering and 
> viruses, and we only 
> > send and receive e-mails on the basis that we are not 
> liable for any 
> > such corruption, interception, amendment, tampering or 
> viruses or any 
> > consequences thereof.
> > 
> > 
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>

---

From: [email-masked]
Date: Sun, 29 Feb 2004 15:16:03 +0200

Hi,

I also hope there could be more clarity on the relationship between exploders and conferencing work. Some thoughts below.

One clear use case for exploders is the establishment of a "dial-out ad-hoc" conference. One of Gonzalo's drafts proposes that the exploder B2BUA (which in this case becomes a conference focus) could return to the originating UA a reference (URI) to the list, after which the UA could use e.g. XCAP to manage the list out-of-band. The idea seems to be that the default format for this list indeed would be the XCAP resource list.

In conferencing framework this list clearly overlaps with the dial-out list concept to be defined in CPCP. Also, if the semantics of removing a user from the list will result in ejection of this user from the conference, this list may overlap with some other functionality of CPCP too.

My proposal to make the exploders and CPCP compliant with each other would be:
- When the conference is established by invoking an exploder, the conference server will use the exploder-list to populate a CPCP document in such a way that its semantics match with what was done with the exploder.
- URI for this CPCP document is provided in 200 OK using the mechanisms dicussed elsewhere (Call-info purpose, new header, ...).
- Conference participants can thereafter make conference policy operations by doing changes to this document, and the situation is as if the conference was originally created by CPCP in the first place.  
- If ad hoc list management via re-INVITEs is still allowed, there needs to be a clear mapping how adding/removing list entries interacts with the CPCP document.

To enable this the CPCP semantics still need more clarity, and maybe also adopting the XCAP resource list format for the possible dial-out etc. lists in that document would help this mapping.

(We could still keep the simple non-CPCP controllable conference case, where the only manipulated object would be a simple resource list. In this case access lists and other such features woould not be supported.) 

Do people think that this would be feasible? Or would we be getting to an interaction that is too complex to model? In general I think there's room for both exploders AND CPCP, so it would be important to specify how they interwork.

Regards,
	Markus

> ext Alan Johnston
> Sent: 26 February, 2004 21:05
> To: Gonzalo Camarillo
> Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); [email-masked];
> [email-masked]; Garcia Miguel.An (Nokia-NRC/Helsinki)
> At 02:13 PM 2/26/2004 +0200, Gonzalo Camarillo wrote:
> >Alan,
> >
> >I agree with you that we do not want to change the 
> conferencing framework 
> >at this point in time (I already said in my previous mail that I 
> >understood that my comments related to this came too late). 
> Still, I found 
> >the discussion useful to understand your point of view.
> 
> Gonzalo,
> 
> Glad to hear that.  I'd be happy to think about how to extend the 
> conferencing work to cover the exploder scenarios you are 
> proposing with 
> MESSAGE, INVITE, and even REFER.    With the current drafts, 
> I have a hard 
> time understanding how to do this, but I look forward to 
> clarifications.   The SUBSCRIBE exploder does not seem to have any 
> conferencing semantics, but seems to be a SIMPLE application 
> since it is 
> tightly coupled to the presence application.
> 
> Thanks,
> Alan Johnston
> MCI
> sip:[email-masked]
> 
> 
> >In any event, the topic I am interested in is the creation 
> of different 
> >resources (identified by URIs) by a single request. In 
> particular, how to 
> >communicate those URIs to the UAC. (I sent separate comments 
> on Hisham's 
> >draft.)
> >
> >I hope we can discuss these issues in Korea.
> >
> >Thanks,
> >
> >Gonzalo
> >
> >
> >Alan Johnston wrote:
> >
> >>At 09:47 AM 2/25/2004 +0200, Gonzalo Camarillo wrote:
> >>
> >>>Hi Alan,
> >>>
> >>>I understand that my comments come late in the game and 
> that it might be 
> >>>impossible to change the conferencing framework at this 
> point. In any 
> >>>event, I do not agree with your statement below:
> >>>
> >>>>No - this is the problem.  You are looking at your single narrow 
> >>>>application.
> >>>
> >>>
> >>>I believe I am actually looking at a much wider range of 
> applications 
> >>>than just conferencing. So, to me, the problem is that the 
> conferencing 
> >>>framework is too focused on a "single narrow application"; 
> conferencing.
> >>
> >>Gonzalo,
> >>If you are saying that some of your exploder services do not have a 
> >>conferencing component, then I agree.  Some of the exploder 
> services seem 
> >>to just be a "request to fork" to a set of URIs.  Others 
> definitely have 
> >>conferencing semantics.  The ones with conferencing 
> semantics, I believe, 
> >>can be, and should be modeled using the conferencing framework.
> >>The problem is that each method seems to have a different set of 
> >>semantics as to what exploding that method means - INVITE 
> is handled 
> >>differently from SUBSCRIBE, from MESSAGE.   From a high 
> level, exploders 
> >>may seem to be a consistent set of services.  However, as I 
> delve into 
> >>the details and think about call flows (something  absent 
> from any of the 
> >>exploder drafts), a different story emerges.
> >>I think we need to explore exactly the services and call 
> flows that are 
> >>being envisioned for exploders before proposing major 
> changes to our 
> >>conferencing framework, which I believe is well understood 
> and documented.
> >>
> >>>In a conferencing service, there is a single resource 
> created by the 
> >>>initial INVITE; a conference. That's why the server can 
> use the Contact 
> >>>header field to send it back to the UAC. If you think of 
> services that 
> >>>create more than one resource (e.g., an explosion and a 
> conference), the 
> >>>server may not want to use the same URI for both. Moreover, 
> >>>conceptually, is is not a good thing to use the same URI 
> to identify 
> >>>both resources.
> >>
> >>As Paul has pointed out - they are the same resource.  
> Additionally, it 
> >>is a trivial SIP routing issue to fix this - many proxies 
> do method-based 
> >>request routing - that would completely solve your problem 
> of sending 
> >>SUBSCRIBEs to a different UA than the initial request.
> >>
> >>>So, my main concern is the semantics overload of the 
> Contact header. (We 
> >>>abused this header when design REGISTER as well, by the 
> way. That's why 
> >>>I do not want to do it again.)
> >>>
> >>>In my opinion, the Contact header is the URI where you 
> send subsequent 
> >>>requests within the dialog. If the server wants to tell 
> the client that 
> >>>a resource (e.g., a conference) has been created, it can 
> use a different 
> >>>header to include the URI of such a resource. Note that, 
> if you want 
> >>>both URIs to be the same (like in the conferencing case), 
> you can do it.
> >>>
> >>>Contact: sip:[email-masked];isfocus
> >>>Resource: sip:[email-masked];isfocus
> >>>
> >>>An entity receiving these headers would use the URI in the Contact 
> >>>header to send subsequent requests *within* the dialog, 
> and the URI in 
> >>>the other header to send requests *outside* that dialog 
> (e.g., SUBSCRIBE 
> >>>to the conference package).
> >>
> >>No.  A GRUU should be used in the Contact, and its routing is valid 
> >>outside the dialog.
> >>
> >>>In brief, instead of sticking the conference URI in a 
> Contact header and 
> >>>label that URI with an isfocus parameter so that the UAC 
> figures what is 
> >>>going on, I find it more explicit to use a different 
> header. Although, 
> >>>as I said, I understand that this comment comes late and 
> that may not be 
> >>>useful at this point.
> >>
> >>I think much more work is needed before the working group 
> can evaluate 
> >>the exploders work and see how and if it fits in with 
> existing concepts 
> >>and approaches.
> >>Thanks,
> >>Alan Johnston
> >>MCI
> >>sip:[email-masked]
> >>
> >>>Thanks,
> >>>
> >>>Gonzalo
> >>>
> >>>
> >>>Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> >Gonzalo Camarillo         Phone :  +358  9 299 33 71
> >Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> >Telecom R&D               Fax   :  +358  9 299 30 52
> >FIN-02420 Jorvas          Email :  [email-masked]
> >Finland                   http://www.hut.fi/~gonzalo
> >
> >
> distribution is 
> >prohibited. If you believe this message has been sent to you 
> in error, 
> >please notify the sender by replying to this transmission 
> and delete the 
> >message without disclosing it. Thank you.
> >
> >interruption, unauthorized amendment, tampering and viruses, 
> and we only 
> >send and receive e-mails on the basis that we are not liable 
> for any such 
> >corruption, interception, amendment, tampering or viruses or any 
> >consequences thereof.
> 
>

---

From: Alan Johnston <[email-masked]>
Date: Sun, 29 Feb 2004 22:12:31 -0600

Markus,

I think you are on the right track.  Look for some movement on harmonizing 
exploders and conferencing this week  - stay tuned...

Thanks,
Alan Johnston
MCI
sip:[email-masked]

At 03:16 PM 2/29/2004 +0200, [email-masked] wrote:
>Hi,
>
>I also hope there could be more clarity on the relationship between 
>exploders and conferencing work. Some thoughts below.
>
>One clear use case for exploders is the establishment of a "dial-out 
>ad-hoc" conference. One of Gonzalo's drafts proposes that the exploder 
>B2BUA (which in this case becomes a conference focus) could return to the 
>originating UA a reference (URI) to the list, after which the UA could use 
>e.g. XCAP to manage the list out-of-band. The idea seems to be that the 
>default format for this list indeed would be the XCAP resource list.
>
>In conferencing framework this list clearly overlaps with the dial-out 
>list concept to be defined in CPCP. Also, if the semantics of removing a 
>user from the list will result in ejection of this user from the 
>conference, this list may overlap with some other functionality of CPCP too.
>
>- When the conference is established by invoking an exploder, the 
>conference server will use the exploder-list to populate a CPCP document 
>in such a way that its semantics match with what was done with the exploder.
>- URI for this CPCP document is provided in 200 OK using the mechanisms 
>dicussed elsewhere (Call-info purpose, new header, ...).
>- Conference participants can thereafter make conference policy operations 
>by doing changes to this document, and the situation is as if the 
>conference was originally created by CPCP in the first place.
>- If ad hoc list management via re-INVITEs is still allowed, there needs 
>to be a clear mapping how adding/removing list entries interacts with the 
>CPCP document.
>
>To enable this the CPCP semantics still need more clarity, and maybe also 
>adopting the XCAP resource list format for the possible dial-out etc. 
>lists in that document would help this mapping.
>
>(We could still keep the simple non-CPCP controllable conference case, 
>where the only manipulated object would be a simple resource list. In this 
>case access lists and other such features woould not be supported.)
>
>Do people think that this would be feasible? Or would we be getting to an 
>interaction that is too complex to model? In general I think there's room 
>for both exploders AND CPCP, so it would be important to specify how they 
>interwork.
>
>Regards,
>         Markus
>