1 / 9

Communication Service Identifier

Communication Service Identifier. Andrew Allen aallen@rim.com. 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

isleen
Télécharger la présentation

Communication Service Identifier

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Communication Service Identifier Andrew Allen aallen@rim.com

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

  3. 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 • http://www.3gpp.org/ftp/Specs/Latest-drafts/23816-110.zip

  4. 3GPP Requirements for the IMS Communication Identifier • 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. • 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. • 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. • 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. • It shall be possible for the UE to invoke appropriate application based on the IMS communication service identifier contained in a received SIP request. • 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. • 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. • 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.

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

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

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

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

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

More Related