Andrew Allen Communication Service Identifier

Introduction I am active in 3GPP and OMA But I am not representing the 3GPP or OMA view on this Initially IMS was defined as just a service enabler –Without defining standardised services Recent work in OMA, TISPAN and 3GPP has standardized services –OMA PoC, –OMA Instant Messaging, –OMA Presence Service –TISPAN Supplementary Telephony Services –3GPP Multimedia Telephony Services

Overview As standardized services were defined it was determined that a means to easily associate a SIP request with the corresponding Communication Service was needed. This eventually led to 3GPP work on the IMS Communication Service Identifier Examples of Communication Services –Telephony Supplementary Service (emulate GSM, ISDN or 5ESS) –Emergency Services (e911) –Standardied Applications - Push to Talk (OMA PoC) –Proprietary Services - Microsoft Messenger My primary concern is that such work be done in SIPPING not 3GPP –Ensure a generally applicable solution –Not an IMS only solution that could impact interoperability 3GPP IMS Communications Identifier Technical Resport –

3GPP Requirements for the IMS Communication Identifier 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.

3GPP Requirements for the IMS Communication Identifier (cont) 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.

IMS Service Architecture Originating Client Orig Service Logic AS 1 S-CSCF App 1 App 2 S-CSCF Term Service Logic AS 1 Target Client A App 1 App 2 Target Client B App 3

Current OMA PoC Solution Define feature tag and include in Accept-Contact header of all requests: –Accept-Contact: *;+g.poc.talkburst;require;explicit Concerns with this approach –Accept-Contact included in requests such as Subscribe and Publish which are never destined for a PoC Terminal or require that the destination support TalkBurst control capability –Semantics of Accept-Contact match a feature set predicate to a registered capability set –Feature set predicates can be quite complicated –A service identifier included in an Accept-Contact header overloads and extends the scope of RFC 3840/3841 –Potential interactions could restrict the use of complex predicates –Potential interoperability problems as only devices that explicitly support the standardized services can interoperate

Some Ideas for Alternative Approaches Service URN –Leverage and align with some of the work on Emergency Services in SIPPING and ECRIT –Emergency Service can be considered an Instance of a Communication Service –Where to include the URN? Route Header URI-Parameter in the Request-URI New Header (Service-ID suggested) –The Service-ID could act as a Superset of feature tags –The Service-ID could point to a document that would contain a feature set predicate required for the service

Way Forward Is SIPPING willing to take up this work? –If not then 3GPP will likely simple endorse the OMA Accept-Contact based solution Write a Communication Service Identifier requirements draft Who is interested in contributing to such work? 3GPP timescales would indicate that work would need to be completed around the end of 2006 –At least a stable solution that could be referenced