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

Drage, Keith (Keith) wrote:
> 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.

Do you the proposed service identifier is intended to be consistent with 
this philosophy? I'm having difficulty getting a definitive reading on 
this.

	Paul

> regards
> 
> Keith
> 
> 
>>-----Original Message-----
>>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]
>>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:joe@example.com, 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 sip-implementors@cs.columbia.edu for questions on current sip
>>>Use sip@ietf.org for new developments of core SIP
>>
>>-- 
>>Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
>>Cisco Fellow                                   Parsippany, NJ 
>>07054-2711
>>Cisco Systems
>>jdrosen@cisco.com                              FAX:   (973) 952-5050
>>http://www.jdrosen.net                         PHONE: (973) 952-5000
>>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 sip-implementors@cs.columbia.edu for questions on current sip
>>Use sip@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP