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

From: "Salvatore Loreto (JO/LMF)" <[email-masked]>
Date: Fri, 07 Jul 2006 12:27:41 +0300

Hi Dale,

see in line

On Thu, 2006-06-29 at 22:17 -0400, [email-masked] wrote:
> I think there are some dangers that the IMS people aren't guarding
> adequately against -- dangers that the Internet-heads sense but are
> having a hard time explaining.
> 
> - The notions of "service" and "application", and a network
> architecture that uses them, are philosophically very different from
> most Internet architectures.  E.g., the first routing decision is
> based on the service, rather than the destination AOR.  The I-D
> contains definitions of these terms, but from the Internet-head point
> of view, the definitions have a circular feel, because it doesn't
> start by explaining the overall architecture.  And if your mental
> image is of an ordinary IP network, all this talk of applications and
> services seems nonsensical.  (Traditionally, any service that a host
> has access to is implemented entirely on that host.)  We need
> something like:
> 
>     "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."

you are right your explanation is more ietf understandable
something like that could be included in the next release of the draft 

> 
> - It appears that it is assumed that the identifiers will (1) be a
> small set, (2) be standardized to the point that all providers will
> completely agree as to their meaning, (3) the services that will
> required by any particular dialog can be completely described by *one*
> identifier.

relatively the services identifier yes for all three the points.

> 
> If these are true, they need to be listed as requirements, or
> assumptions, or something.  Not so much because these affect what the
> identifiers are, but they heavily affect how the identifiers are
> applied to requests/responses, and how the list of standard
> identifiers is maintained.

yes, it should be an assumptions.
I think how the list of standard identifiers should be maintained is a
matter of the solution.

> 
> Dale
> 
> _______________________________________________
> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Jul 2006 17:23:52 -0400

> relatively the services identifier yes for all three the points.

Now we get to the crux of the matter!

If the CSI is intended to become a mechanism of SIP, rather than just 
IMS, then we will have to question whether this restricted notion of 
service is something we want in SIP.

If this is only intended to be a mechanism for IMS, then it might be 
accomplished via a P-header, with the lower bar for approval. If it 
isn't done via P-header then we may be in a gray area.

For instance, if it is done via a feature tag defined in the sip tree, 
then it is a sip feature, and again we may want to question it 
carefully. If it is done a feature tag, regardless of what tree it is 
in, if it is used in Accept-Contact we may want to question if it is 
being used as that header is intended to be used. (That also may be a 
gray area.)

	Paul

---

From: Dean Willis <[email-masked]>
Date: Wed, 12 Jul 2006 01:50:30 -0500

>     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

---

From: "Salvatore Loreto (JO/LMF)" <[email-masked]>
Date: Wed, 12 Jul 2006 16:40:55 +0300

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.

/sal

---

From: David R Oran <[email-masked]>
Date: Wed, 12 Jul 2006 10:34:20 -0400

> applications are deployed in a session must use the same service  
Really? the MRCPv2 server doing hotword recognition on a media stream  
that is also being sent to the voicemail server has to use the same  
service logic as the voicemail server?

The idea that applications are a hirearchical containment of a  
"communciation service" is what I (and others) find to be a flawed idea.

Dave Oran.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Jul 2006 11:39:02 -0400

> 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

---

From: "Salvatore Loreto (JO/LMF)" <[email-masked]>
Date: Wed, 12 Jul 2006 20:40:04 +0300

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 

/Sal

---

From: Keith Lantz <[email-masked]>
Date: Wed, 12 Jul 2006 11:08:58 -0700

Well, I haven't read the draft(s?) in question, but I can flag a 
problem with the acronym "CSI", especially as used in the context of 
IMS-related discussions, namely: Said acronym is already "reserved" 
by 3GPP to describe "combinational services" -- that is, the 
"combination of Circuit-Switched and IMS services" to deliver, for 
example, "see-what-I-see" services. The technical specification can 
be found 
in 
http://www.3gpp.org/ftp/TSG_SA/TSG_SA/TSGS_27/Docs/PDF/SP-050118.pdf 
and revenue-generating examples of such services have already been 
deployed (e.g. by Telecom Italia). In the interest of clarity I would 
therefore recommend that a different acronym be chosen for the 
functionality being discussed below.

Regards, Keith

---

From: "Salvatore Loreto (JO/LMF)" <[email-masked]>
Date: Wed, 12 Jul 2006 21:16:29 +0300

Hi Keith,

you are right,
in the 3GPP world the right acronym should be "CSID" 

/sal

On Wed, 2006-07-12 at 11:08 -0700, Keith Lantz wrote:
> IMS-related discussions, namely: Said acronym is already "reserved" by
> 3GPP to describe "combinational services" -- that is, the "combination
> of Circuit-Switched and IMS services" to deliver, for example,
> "see-what-I-see" services. The technical specification can be found in
> > > >>>     application which runs on a server.  Different dialogs may
> > be  
> > > >>> mediated
> > > >>>     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
> > > >> Sipping mailing list
> > https://www1.ietf.org/mailman/listinfo/sipping
> > > > Sipping mailing list
> > https://www1.ietf.org/mailman/listinfo/sipping

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Jul 2006 17:31:07 -0400

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

---

From: Keith Lantz <[email-masked]>
Date: Wed, 12 Jul 2006 15:28:51 -0700

Yes, indeed, they are *very* different concepts -- developed, best I 
can tell, in total isolation from each other. While one can *imagine* 
the use of "communication service identifiers" such as those 
underlying this long-running thread as being useful in support of the 
"combinational services" I mentioned, that's all it would appear to 
be at this point -- imagination.

Keith

At 02:27 PM 7/12/2006, Paul Kyzivat wrote:

>So these are *different* concepts? Based on the quote from Keith I 
>could easily  believe these are intended to be the same concept.
>
>         Paul
>
>>/sal
>>
>>>>The CSI should be useful -to route the signaling through the 
>>>>right application server in both
>>>>the

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Jul 2006 17:27:01 -0400

> in the 3GPP world the right acronym should be "CSID" 

So these are *different* concepts? Based on the quote from Keith I could 
easily  believe these are intended to be the same concept.

	Paul

---

From: "Salvatore Loreto (JO/LMF)" <[email-masked]>
Date: Thu, 13 Jul 2006 21:52:45 +0300

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Jul 2006 16:04:22 -0400

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

---

From: [email-masked]
Date: Mon, 17 Jul 2006 19:27:13 -0400

From: Dean Willis <[email-masked]>

   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
   [6]) Request URI parameters

and while we're at it:

7) Additional headers
8) SDP media descriptions

But I notice that to date, there seems to be no shared understanding
of how these IMS identifiers are to be used (even whether more than
one can be applied to a given dialog seems to be unclear) -- and
that's assuming that the IETF sees fit to accept the current IMS
architecture entirely unchanged.

I think this is proof the background information needs to be improved
seriously.  Can the author make such a revision?

Dale

---

From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
Date: Tue, 25 Jul 2006 17:40:53 +0200

Hi Paul; Peter; Dean; All;

Thank-you for the feedback.  We will produce an update of the draft
soon.

Best Regards,

Stephen and Sal.
-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Thursday, July 13, 2006 10:04 PM
To: Salvatore Loreto (JO/LMF)
Cc: [email-masked]; Dean Willis
Subject: Re: [Sipping] Requirements for the identification of IMS
communicationservices.

	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
> 
> 
>>> -to route the signaling through the right application server in both

>>> the originating and terminating network.
>> 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
>>>
>>>
>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>> be mediated
>>>>>>> routed to the
>>>>>>> services beyond
>>>>>> 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:
>>>>>>
>>>>>> 2) "Triggers"  defined in the subscriber record (from HSS) 
>>>>>> driving S- CSCF routing decisions
>>>>>> 3) Caller preferences
>>>>>> 4) Callee capabilities
>>>>>> 5) Route headers
>>>>>> 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.
>>>>>> 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
>>>>> 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