RE: [Sipping] Requirements for the identification of IMS communic ation services.

["Drage, Keith (Keith)" <[e-mail]>]

It is worth noting that the document quoted by Jonathan is normatively referenced in its entirety as part of both the OMA and 3GPP presence stage 3 specifications.

regards

Keith

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[e-mail]]
> Sent: 22 March 2006 15:53
> To: Stephen Terrill (E2/EEM)
> Cc: Rohan Mahy; sipping; Gonzalo Camarillo (JO/LMF); Dean Willis
> Subject: Re: [Sipping] Requirements for the identification of IMS
> communication services.
> 
> 
> 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/Doc
> s/S2-060468.ZIP_ 
> > and 
> > 
> _http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_50_Budapest/Doc
> s/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
> 

_______________________________________________
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