Slide title In CAPITALS 50 pt Slide subtitle 32 pt Addressing & Invocation of IMS-attached Services Ioannis Fikouras, Roman Levenshteyn, Salvatore Loreto, Gonzalo Camarillo Ericsson Research IPTComm 2007, July, New York

Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level pt © Ericsson GmbH 2007IPTComm 2007Adressing & Invocation of IMS-attached Services (12) IMS & non-IMS services The IP Multimedia Subsystem (IMS) is an IP and IETF protocol based architecture by 3GPP & ETSI TISPAN IMS was designed as a platform for current & future telecoms & Internet services Still, a plethora of non IMS-enabled systems and services is and will continue to be available to the subscriber However, non-IMS services may be accessible locally to IMS terminals An approach to provide access to such non-IMS services would extend the reach of IMS and is therefore desirable

Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level pt © Ericsson GmbH 2007IPTComm 2007Adressing & Invocation of IMS-attached Services (12) Introducing IMS-attached services Attached services are: not directly addressable e.g. provided by devices without SIP connectivity, or remotely hosted services, accessible via a network connection Introducing Attached Services Identifiers ASIs support: registration of attached services in the IMS domain (e.g. on presence servers) discovery of attached services dispatching of service requests for attached services

Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level pt © Ericsson GmbH 2007IPTComm 2007Adressing & Invocation of IMS-attached Services (12) IMS-attached services identifiers ASIs consist of three components used to: –address the IMS-enabled node (IMS URI), –identify specific types or instantiations of services (LSI) –signify service semantics (feature identifier, e.g. IANA) Local Service Identifiers (LSI) are required to facilitate: –differentiation between multiple services with the same Feature Identifier –addressing of specific variations of attached services Attached Serv. Identifier IMS node URIFeature IdentifierLSI (video)LSI3 (video)LSI2 (audio)LSI1

Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level pt © Ericsson GmbH 2007IPTComm 2007Adressing & Invocation of IMS-attached Services (12) Detection of IMS-attached services Detection of attached services is achieved through: –Local discovery mechanisms for local services provided by devices connected to an IMS terminal –Remote services can be registered via a network connection to the IMS- enabled node The IMS-enabled node creates the Local ASI Mapping Table containing the mapping between ASIs and attached services Attached Serv. Identifier Attached Serv. Desc. IMS node URIFeature IdentifierLSIAttached Serv. AddressOther (video) LSI (IP-address) data (video) LSI (IP-address) … (audio) LSI100:20:DF:E0:A3:5A (bluetooth address) …

Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level pt © Ericsson GmbH 2007IPTComm 2007Adressing & Invocation of IMS-attached Services (12) Registration of IMS-attached services Attached services should be registered in the IMS domain using their ASIs in order to enable: –Discovery –Invocation An appropriate registry could be a Presence server or even the CSCF itself.

Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level pt © Ericsson GmbH 2007IPTComm 2007Adressing & Invocation of IMS-attached Services (12) Attached service registration via SIP REGISTER REGISTER sip:example.com SIP/2.0 From: To: Call-ID: CSeq: 9987 REGISTER Max-Forwards: 70 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds Contact: ;audio=LSI1 ;video=LSI2;video=LSI3;actor="msg-taker" ;automata;mobility="fixed" ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" Content-Length: 0 The Contact header field contains : the SIP URI in the Contact field is taken from the URI column of the local ASI mapping table audio and video feature tags are according to IANA classification and are taken from the Feature Identifier column of the local ASI mapping table LSIs can be omitted, in case only one service with a specific Feature Identifier is registered

Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level pt © Ericsson GmbH 2007IPTComm 2007Adressing & Invocation of IMS-attached Services (12) Discovery ASI mapping table Based on the information provided by the registration process, a table consisting of all registered ASIs for an IMS- enabled node is created and maintained within a registry such as the presence server Attached Serv. Identifier Other data IMS node URIFeature IdentifierLSI (video)LSI3… (video)LSI2… (audio)LSI1…

Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level pt © Ericsson GmbH 2007IPTComm 2007Adressing & Invocation of IMS-attached Services (12) Discovery ASI mapping flow

Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level pt © Ericsson GmbH 2007IPTComm 2007Adressing & Invocation of IMS-attached Services (12) Invocation of IMS-attached services INVITE SIP/2.0 Via: SIP/2.0/UDP 5555::aaa:bbb:ccc:ddd];branch=z9hG4bKna shds7 Max-Forwards: 70 Route:, From: ;tag= To: Call-ID: cb03a0s09a2sdfglkj Cseq: 127 INVITE Contact: Accept-Contact: audio; video=LSI1 Content-Type: application/sdp Content-Length: 248 Accept-Contact header fields are used to select appropriate attached services for incoming invocations The set of features specified by the Accept- Contact header field defines the set of attached services to reach

Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level pt © Ericsson GmbH 2007IPTComm 2007Adressing & Invocation of IMS-attached Services (12) Conclusions This paper outlines a method for providing access to attached non-IMS services to all IMS subscribers The approach enables the IMS terminal to act as gateway for accessing services hosted by other devices Mechanisms for the detection, registration, discovery and invocation of attached services are presented The proposed solution opens the way for innovative scenarios and new business cases

Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level pt © Ericsson GmbH 2007IPTComm 2007Adressing & Invocation of IMS-attached Services (12) Thank you! Q&A For more information please contact: Roman Levenshteyn Ioannis Fikouras Salvatore Loreto Gonzalo Camarillo

Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level pt © Ericsson GmbH 2007IPTComm 2007Adressing & Invocation of IMS-attached Services (12)