RE: [Sipping] Conferencing for UAs

[[e-mail]]

Hi,

OK, this sounds reasonable. So the list carried within SIP payload would be only one input to the overall initial state of the application, which in this case is a conference. 

It makes things cleaner that the list management is dropped from SIP side. However, there is  still some interaction between sending further REFERs to the conference instance (for instance kicking people out), and doing CPCP operations. Is this something that would still need more attention before letting exploders and CPCP to go forward in their own silos?

I guess the idea now anyway is that what happens with the list depends a lot on the application (which is represented by the URI that the SIP request is destined to). 

Markus

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]]On Behalf Of
> ext Miguel Garcia
> Sent: 03 March, 2004 08:52
> To: Isomaki Markus (Nokia-NRC/Helsinki)
> Cc: [e-mail]; [e-mail]; Khartabil
> Hisham (Nokia-TP-MSW/Helsinki); [e-mail]; [e-mail]
> Subject: Re: [Sipping] Conferencing for UAs
> 
> 
> Markus,
> 
> I think your proposal is inline with some thoughts we heard 
> today right 
> before the SIPPING session.
> 
> What it became clearer is that the list that is transported in a SIP 
> message is not necessarily the same list that can be 
> manipulated by CPCP.
> 
> I can think of scenarios where by the conference policy 
> indicates that a 
> particular user need to be added to each conference (e.g., the 
> conference welcome-message automat). In that case the list 
> included in 
> the SIP request and the list of partipants differ.
> 
> /Miguel
> 
> [e-mail] 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.
> > 
> > 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
> > 
> > 
> >>-----Original Message-----
> >>From: [e-mail] 
> >>[mailto:[e-mail]]On Behalf Of
> >>ext Alan Johnston
> >>Sent: 26 February, 2004 21:05
> >>To: Gonzalo Camarillo
> >>Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); [e-mail];
> >>[e-mail]; Garcia Miguel.An (Nokia-NRC/Helsinki)
> >>Subject: Re: [Sipping] Conferencing for UAs
> >>
> >>
> >>
> >>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:[e-mail]
> >>
> >>
> >>
> >>>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:[e-mail];isfocus
> >>>>>Resource: sip:[e-mail];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:[e-mail]
> >>>>
> >>>>
> >>>>>Thanks,
> >>>>>
> >>>>>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.
> >>>>>
> >>>>>
> >>>>>_______________________________________________
> >>>>>Sipping mailing list  
> >>
> >>https://www1.ietf.org/mailman/listinfo/sipping
> >>
> >>>>>This list is for NEW development of the application of SIP
> >>>>>Use [e-mail] for questions on current sip
> >>>>>Use [e-mail] for new developments of core SIP
> >>>
> >>>--
> >>>Gonzalo Camarillo         Phone :  [phone]
> >>>Oy L M Ericsson Ab        Mobile:  [phone]
> >>>Telecom R&D               Fax   :  [phone]
> >>>FIN-02420 Jorvas          Email :  [e-mail]
> >>>Finland                   http://www.hut.fi/~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.
> >>
> >>
> >>_______________________________________________
> >>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> >>This list is for NEW development of the application of SIP
> >>Use [e-mail] for questions on current sip
> >>Use [e-mail] for new developments of core SIP
> >>
> > 
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [e-mail] for questions on current sip
> > Use [e-mail] for new developments of core SIP
> 
> -- 
> Miguel A. Garcia           tel:[phone]
> Nokia Research Center      Helsinki, Finland
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
> 

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