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

[Jonathan Rosenberg <[e-mail]>]

Here are my thoughts on this topic.

Firstly, you are correct that there is a fairly extensive discussion on 
this topic in terms of presence. I'd strongly suggest that folks take a 
look at:

http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-data-model-07.txt

and in particular, Section 3.3 on Services and Section 3.3.2, which 
describes Reach Information. I'll quote three paragraphs that are 
particularly relevant to this discussion:


>  It is difficult to give a precise definition for service.  One
>    reasonable approach is to model each software or hardware agent in
>    the system as a service.  If a user starts a softphone application on
>    their PC, then that represents a service.  If a user has a videophone
>    device, then that represents another service.  This is effectively a
>    physical view of services.  This definition, however, starts to fall
>    apart when a service is spread across multiple software agents or
>    devices.  For example, a SIP URI representing an address-of-record
>    can be routed to a softphone or a videophone, or both.  In that case,
>    one might attempt instead to define a service based on its address on
>    the network.  This definition also falls apart when modeling devices
>    or applications that receive calls and dispatch them to different
>    "helpers" based on potentially complex logic.  For example, a
>    cellular telephone might house multiple SIP applications, each of
>    which can "register" different handlers based on the method or even
>    body type of the request.  Each of those applications or handlers can
>    rightfully be considered a service, but it doesn't have an address on
>    the network distinct from the others.
> 
>    Because of this inherent difficulty in precisely defining a service,
>    the data model doesn't try to constrain what can be considered a
>    service.  Rather, anything can be considered a service so long as it
>    exhibits a set of key properties defined by this model.  In
>    particular, Each service is associated with characteristics which
>    identify the nature and capabilities of that service, with reach
>    information that indicates how to connect to the service, with status
>    information representing the state of that service, and relative
>    information that describes the ways in which that service relates to
>    others associated with the presentity.
> 
>    As a consequence, in this model, services are not explicitly
>    enumerated.  There is no central registry where one finds identifiers
>    for each service.  Consequently, each service does not have a single
>    "service" attribute with values such as "ptt" or "telephony".  That
>    doesnt mean that these consolidated monikers aren't useful; indeed,
>    they represent an essential summary of what the service is.  Such
>    summarization is useful in creating icons that allow a user to choose
>    one service over another. 

Regardless of whether you use presence or not, the discussion and 
guidance here are directly applicable to this topic.

They key takeaway is that there are many dangers to interoperability 
associated with the explicit enumeration of services; they require 
global definition and agreement, and they result in (when taken to the 
extreme), a separation of SIP communications into multiple parallel, 
non-interoperable SIP networks, one for each vendor or service providers 
definition of what the service is. I believe others have commented on 
this within this thread. Nothing would be a greater crime to global 
interoperability for 3gpp to define a service called 'voip' and then 
require that only calls tagged with this service be processed and routed 
to the 'voip' client on each phone. This would inhibit the ability of 
clients outside of 3gpp to ever communicate with 3gpp endpoints, and 
that is something I am sure we all want to avoid.

That said, the text above recognizes that there are cases where you need 
to reach a specific instance of software in an endpoint because the 
communications is in the context of that application, and is truly 
meangingless outside of it. One example is voice communications that are 
part of a multiplayer game, where the voice is in concert with non-sip 
protocols that facilitate the game. In such a case, when I start a game, 
and try and connect with another user, unless that user is also running 
the game software, the voice communications should not take place. It 
would be non-sensical to connect to, for example, a regular telephone or 
voice-capable softphone that lacks the game.

The presence data model recognizes this, but strongly recommends that 
the URI itself be distinct for each of these. Distinct URI are readily 
obtained through presence. Each presence document would have a number of 
'tuples', each of which identifies a unique service. Each unique service 
has a unique service URI, which represents the mechanism I use to 
contact someone for that service. In the case of the game, the ideal 
solution is that I, in invoking this game, would subscribe to the 
presence of sip:[e-mail], get back their presence, find the one 
matching the game I'm interested in, and the select that URI. All of 
that can happen automatically.

The data model further states that there are cases where the URI cannot 
be used as a unique identifier for services, and indeed it calls out the 
use case of a cellular phone, which is the exact case I believe you are 
worried about. In that case, it recommends tecnologies like caller prefs 
for this purpose. However, I will restate an important sentence in the 
above:

>  Since the reach
>    information has to be understood in order for the service to be
>    utilized, reach information beyond the URI should be defined and used
>    sparingly. 


With an emphasis on SPARINGLY.

Your text below has me quite worried that these guidelines are not being 
adequately followed, and that will result in substantial 
interoperability problems.


Thanks,
Jonathan R.

Stephen Terrill (E2/EEM) wrote:

> Hello All,
> 
> I am of the understanding that there have been some questions regarding 
> the requirements for the identification of IMS services.  I would like 
> to provide an understanding of the 3GPP discussions on this topic.  As I 
> see it, the need to identify the IMS communication services stems from 
> that we have/are devloping different services on IMS as a SIP 
> infrastructure, such as push-to-talk over cellular (PoC) or messaging.  
> As there are different services and as it is not safe to rely on the 
> expressed media as the media may be used in different services then 
> there is the need to identify the service that is requisted.  This could 
> be seen as a means to identify the context upon which to interpret the 
> SIP signalling.  This is required to e.g. Identify the application 
> server that supports this communication service and to identify the 
> client to invoke in the terminating network.  While writting this, I 
> seem to recall a parrallel discussion in relation to presence, and that 
> was along the lines that was that it was required to identify the 
> service that was used to communicate in the presence, as otherwise two 
> if the same presence information appeared for two incompatabile services 
> (e.g. two incomptable versions of push to talk) which fulfulled the same 
> end-user expectation appeared the same in presence, then the end-user 
> would get confused as to why s/he could communicate with some users but 
> not with others.
> 
> Please note that this is not intended to identify service that are 
> routed to, such as train time tables etc.  For these services, the 
> communication services is a means to route to and reach the ultimtate 
> end-user service.  This discussion is about how to identify the 
> communication service.
> 
> This has been discussed at an architectural level within 3GPP and a 
> Technical Report has been produced.  The Technical report can be found 
> at _http://www.3gpp.org/ftp/Specs/Latest-drafts/23816-110.zip_.  This 
> has been moved to approved status this week.  The essence of this 
> technical report has been included in specification text which can be 
> captured in 
> _http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_50_Budapest/Docs/S2-060468.ZIP_ 
> and 
> _http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_50_Budapest/Docs/S2-060469.ZIP_ 
> .  Note that the changes included in S2-060468.ZIP are changes to what 
> was already included in the specification text last year.  These 
> documents represent the approved requirements within 3GPP.
> 
> I can appreciate that a number of readers prefer to read this in text 
> instead of word, as such the approved 3GPP text that has been included 
> in the specifications is included below.  As such, the text below are 
> the 3GPP stage 2 representation of the requirements.  It is worth 
> keeping in mind that the text below represensts archtectural 
> requirements and not the protocol realisation of these requirements.
> 
> Please don't hesitate to contact me if you have any questions.
> 
> I apologies in advance to the references to the 3GPP interfaces, they 
> are retained as I though it was better to avoid modifying any of the 
> agreed text when copying it into this email.
> 
> Best Regards,
> 
> Stephen Terrill
> 
> <Specification Text>
> 4.13.2  Identification of IMS communication Services
> A communication service identifier provides a framework for the 
> identification of IMS communication services utilising the IMS 
> enablers.  An IMS communication service is provided via the use of the 
> IMS enablers. At terminals, the use of a communication service 
> identifier is similar to the use of the port concept in TCP/IP, in that 
> it allows applications in a terminal and the network that use SIP for 
> communication purposes to be identified. In the terminal this means 
> dispatching a SIP message to the correct application, and in the network 
> it means selection of the correct application server over ISC. Examples 
> of IMS based applications and communication services are OMA messaging 
> and OMA PoC.
> 
> The communication service is an aggregation of one or several media 
> components and the service logic managing the aggregation, represented 
> in the protocols used. Its behaviour and characteristics may be 
> standardized as done for the two examples above, or proprietary and 
> specific for e.g. an operator or an enterprise.
> 
> A service description specifies this behaviour and states e.g. the 
> allowed media combinations and state transitions as a consequence of 
> signalling and use of IMS enablers in the network and terminals.
> 
> The need of applying a service identifier is to be taken within the 
> specification of each individual service.
> The communication service identifier identifies IMS communication 
> services and shall be included in the relevant SIP methods.
> 
> The IMS communication service identifier shall fulfil the following 
> requirements:
> 1. It shall be possible for the UE and an Application Server (AS) to set 
> the
>    IMS communication service identifier in a SIP request, e.g. in the
>    REGISTER and INVITE request.
> 2. Based on operator policy the S-CSCF or an AS shall be able to 
> validate an
>    IMS communication service identifier in a SIP request. This includes 
> e.g.
>    to check the syntactical correctness of a service identifier, and 
> policing
>    the usage of a communication service identifier.
> 3. It shall be possible, e.g. for the UE, S-CSCF and AS, to identify an
>    IMS service uniquely by the IMS communication service identifier.
> 4. It shall be possible for the S-CSCF to invoke appropriate service
>    logic based on the IMS communication service identifier contained
>    in a SIP request, e.g. route a SIP request containing a service 
> identifier
>    based on initial filter criteria to the correct AS.
> 5. It shall be possible for the UE to invoke appropriate application
>    based on the IMS communication service identifier contained in a
>    received SIP request.
> 6. It shall be possible for the UE to indicate its service capabilities
>    to the network, e.g. during registration, using the
>    IMS communication service identifier.
> 7. The structure of the IMS communication service identifier shall be as
>    simple as possible, i.e. the IMS communication service identifier shall
>    be limited to identify a service.
> 8. Based on operator policy S-CSCF and AS shall consider the
>    IMS communication service identifier for online and offline charging,
>    e.g. put appropriate data into call detailed records.
> 9. The communication service identifier shall be capable of being an
>    input into the policy control and charging rules.
> 10. It shall be possible to use the IMS communication service identifier as
>     a means to authorise whether a subscriber is allowed to initiate or
>     receive request for a communication service.
> 11. The communication service identifier shall be taken into account
>     when selecting the correct UE(s), if multiple UEs are registered
>     for the same Public User Identity(s).
> 12. The usage of communication service identifiers shall not adversely
>     affect interoperability between IMS networks and interoperability
>     with external SIP networks and CS networks. The behaviour of a network
>     receiving the IMS requests without an IMS communication service
>     identifier is a matter of operator policy. Usage of communication
>     service identifiers shall not decrease the level of interoperability
>     with networks and UEs that are unaware of the communication service 
> identifier.
> 13. It shall be possible for the IMS network and UE to support 
> communications
>     that do not use a communication service identifier. In the case that an
>     IMS communication service identifier is not present then the network 
> may
>     assume a particular IMS communication service.
> 14. The usage of communication service identifiers shall not restrict 
> the inherent
>     capabilities of SIP.
> 15. The usage of communication service identifiers shall not require 
> additional user
>     interaction, i .e. the communication service identifier is assumed
>     to be “added” by the UE that initiates the communication.
> 
> The network and the terminal shall be able to continue operation as 
> defined in 3GPP Release 5 and 3GPP Release 6.
> 
> The communication service identifier shall be available at least in the 
> following interfaces:
> -       ISC; Gm; Mi, Mj, Mk, Mw; Mg; Mr;
> -       Cx; Dx (e.g as part of the iFC);
> -       Rx;
> -       Rf, Ro.
> 
> NOTE:   The communication service identifier does not replace the
> public service identity (PSI). The communication service identifier 
> would be used to indicate the communication service used to access the 
> service addressed via a PSI, and is required to identify the 
> communication service even when SIP requests are sent towards another 
> entity without using a PSI.
> 
> 4.13.2  Identification of IMS applications
> 
> An IMS application is an application that uses an IMS communication 
> service(s) in order to provide a specific service to the end-user.  The 
> IMS application uses specific IMS Communication Service(s) and provides 
> the end user service through the reuse of the SIP communication part of 
> service. The IMS application does not extend the definition of the IMS 
> communication service.  The IMS application reference identifies the 
> application utilising the IMS communication service.
> 
> << removed figure >>
> 
> Figure 4.13-1:  IMS applications on top of an IMS communication service 
> The IMS application reference is used to identify the IMS applications 
> other than the default for the IMS communication service.  The IMS 
> application reference has significance at the UE and the SIP AS behaving 
> as SIP endpoints.  The means to transport the IMS application reference 
> is defined within the IMS communication services.  When used, it shall 
> be possible to transport the IMS application reference on at least on 
> the following interfaces:
> 
> •       ISC; Gm; Mi, Mj, Mk, Mw; Mg; Mr; Ro, Rx, Rf
> 
> 
> </Specification Text>
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[e-mail]                              FAX:   [phone]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com

_______________________________________________
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