Andrew%20Allen

1
Communication Service Identifier

• Andrew Allen
• aallen_at_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

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.

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.talkburstrequireexplici
  t
• 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