Subject: Re: [Sipping] Requirements for the identification of IMS communicationservices.

From: "Leis, Peter" <[email-masked]>
Date: Mon, 17 Jul 2006 08:36:41 +0200

I agree with Paul here. 

It would be really good to see more examples.

Peter

> -----Ursprüngliche Nachricht-----
> Von: Paul Kyzivat [mailto:[email-masked]] 
> Gesendet: Donnerstag, 13. Juli 2006 22:04
> An: Salvatore Loreto (JO/LMF)
> Cc: [email-masked]; Dean Willis
> Betreff: Re: [Sipping] Requirements for the identification of 
> IMS communicationservices.
> 
> I'm sorry - maybe I lack imagination. But to the extent that I can 
> imagine communication services, I don't see them as disjoint. 
> But mostly 
> I don't yet see the need for this at all.
> 
> The only examples mentioned so far are PoC and "basic telephony". And 
> given only those as examples I can see a multitude of ways to handle 
> them without this mechanism. And, I don't see PoC and basic 
> telephony as 
> mutually exclusive - I can easily see it to be desirable to 
> transition 
> between them on the same call. I would love to see a much 
> richer set of 
> examples of the kinds of things that are considered to be 
> communication 
> services.
> 
> I keep thinking I'm missing something fundamental about the 
> environment 
> you are assuming, that makes me not "get it", and that with a more 
> complete explanation I will eventually understand. If I'm the 
> only one 
> in this boat then don't bother. But I suspect the lack of 
> comprehension 
> is more widespread.
> 
> 	Paul
> 
> Salvatore Loreto (JO/LMF) wrote:
> > Hi Paul,
> > 
> > as I said during the presentation the fact there is 
> > only one CSI per session, mean each session has just one 
> specific set of
> > rules, procedures and media; 
> > on top of this communication service you can have inside the same
> > session different Applications all using the set or a subset of the
> > rules, procedure and media defined in the communication service. 
> > 
> > /sal
> > 
> > 
> > On Wed, 2006-07-12 at 17:31 -0400, Paul Kyzivat wrote:
> >> Salvatore Loreto (JO/LMF) wrote:
> >>> Hi Paul,
> >>>
> >>> your understanding of filter criteria is correct.
> >>> CSI is a new and different way to invoke services.
> >>>
> >>> The CSI should be useful 
> >>> -to route the signaling through the right application 
> server in both the
> >>> originating and terminating network.
> >>> -identify the right terminal 
> >> It then confuses me more if there is to be only one CSID per call, 
> >> because this implies there is only one service per call 
> (though perhaps 
> >> multiple applications) whereas AFAIK the ISC allows 
> multiple services 
> >> per call. Or are you equating "service" = "user profile"?
> >>
> >> 	Paul
> >>
> >>> /Sal
> >>>
> >>>
> >>>
> >>> On Wed, 2006-07-12 at 11:39 -0400, Paul Kyzivat wrote:
> >>>> Salvatore Loreto (JO/LMF) wrote:
> >>>>> Hi Dean,
> >>>>>
> >>>>> just to clarify
> >>>>>
> >>>>> the draft at present doesn't claim that it is never 
> possible to deploy
> >>>>> more than one application in a session, it only says 
> all the different
> >>>>> applications should be based on the same Communication 
> Service (that
> >>>>> mean on the same service logic and media handling). All 
> the different
> >>>>> applications are deployed in a session must use the 
> same service logic.
> >>>> The above is inconsistent with my (somewhat limited) 
> understanding of 
> >>>> IMS. I thought the triggers in the filter criteria 
> potentially represent 
> >>>> *different* services that may be invoked in the same 
> call. So in that 
> >>>> case the different applications could be associated with 
> different 
> >>>> services in that sense. But the CSI seems to be singling out a 
> >>>> particular named service as special.
> >>>>
> >>>> 	Paul
> >>>>
> >>>>> /sal
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Wed, 2006-07-12 at 01:50 -0500, Dean Willis wrote:
> >>>>>> On Jun 29, 2006, at 9:17 PM, [email-masked] wrote:
> >>>>>>
> >>>>>>>     "Any dialog with the UA passes through, and is 
> mediated by, an
> >>>>>>>     application which runs on a server.  Different 
> dialogs may be  
> >>>>>>> mediated
> >>>>>>>     by different applications, but each dialog is 
> handled by one
> >>>>>>>     application.  Hence, all incoming dialogs must be 
> first routed  
> >>>>>>> to the
> >>>>>>>     proper application, which will then establish 
> communication  
> >>>>>>> with the
> >>>>>>>     specified UA.  Each application can provide 
> additional services  
> >>>>>>> beyond
> >>>>>>>     what is implemented in the UA.  Hence, incoming 
> dialogs must be
> >>>>>>>     accurately classified as to the services they 
> will need, so that
> >>>>>>>     they can be routed to a suitable application."
> >>>>>> Ah, you've hit (and continued to flog) my worry exactly.
> >>>>>>
> >>>>>> You say "each dialog is handled by one application". 
> That's the part  
> >>>>>> that I think is fundamentally wrong. Even in an IMS 
> "service model"  
> >>>>>> as you have described, each dialog would be handled by 
> zero or more  
> >>>>>> applications, as determined by a combination of:
> >>>>>>
> >>>>>> 1) If we have them, service identifiers.
> >>>>>> 2) "Triggers"  defined in the subscriber record (from 
> HSS) driving S- 
> >>>>>> CSCF routing decisions
> >>>>>> 3) Caller preferences
> >>>>>> 4) Callee capabilities
> >>>>>> 5) Route headers
> >>>>>> 5) Request URI parameters
> >>>>>>
> >>>>>> and all not necessarily in that order.
> >>>>>>
> >>>>>> The key point here is "zero or more applications".  
> The fundamental  
> >>>>>> promise of the IMS service architecture is that 
> applications are  
> >>>>>> additive. That is, it is possible to deploy more than 
> one on a call.  
> >>>>>> But the current identification draft seems to think of 
> them as  
> >>>>>> exclusive, such that it is never possible to deploy 
> more than one.
> >>>>>>
> >>>>>> --
> >>>>>> Dean
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> 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
> >>>>> _______________________________________________
> >>>>> 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
> >>>>>
> > 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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