WO2015088418A1 - Applications de sous-système multimédia ip - Google Patents

Applications de sous-système multimédia ip Download PDF

Info

Publication number
WO2015088418A1
WO2015088418A1 PCT/SE2014/051196 SE2014051196W WO2015088418A1 WO 2015088418 A1 WO2015088418 A1 WO 2015088418A1 SE 2014051196 W SE2014051196 W SE 2014051196W WO 2015088418 A1 WO2015088418 A1 WO 2015088418A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
ims
identifier
message
category
Prior art date
Application number
PCT/SE2014/051196
Other languages
English (en)
Inventor
Jan Lidin
Nancy M GREENE
Cristina Badulescu
Original Assignee
Telefonaktiebolaget L M Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget L M Ericsson (Publ) filed Critical Telefonaktiebolaget L M Ericsson (Publ)
Publication of WO2015088418A1 publication Critical patent/WO2015088418A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1063—Application servers providing network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/561—Adding application-functional data or data for application control, e.g. adding metadata

Definitions

  • the invention relates to the field of IP Multimedia Subsystem applications, and in particular to identifying an IP Multimedia Subsystem application.
  • the Universal Mobile Telecommunications System is a third generation wireless system designed to provide higher data rates and enhanced services to subscribers.
  • the Long Term Evolution System (LTE), or the E-UTRAN (Evolved Universal Terrestrial Access Network), is a fourth generation wireless system providing both radio and core network evolution. Both are part of the Evolved Packet System (EPS) which is an evolution of the Packet-Switched (PS) architecture used in GPRS/UMTS.
  • EPS Evolved Packet System
  • PS Packet-Switched
  • EPC Evolved Packet Core
  • IMS IP Multimedia Core Network Subsystem
  • IMS I P Multimedia Subsystem
  • IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to- content (client-to-server) services over I P-based networks.
  • the IMS is able to connect to both PSTN/ISDN (Public Switched Telephone Network/Integrated Services Digital Network) as well as the Internet.
  • PSTN/ISDN Public Switched Telephone Network/Integrated Services Digital Network
  • Components of the IMS core may be interconnected with, for example, a PSTN network, a legacy mobile signalling network such as a Global System for Mobile Communications (GSM)/ General Packet Radio Service (GPRS) network, 3G and 4G networks.
  • GSM Global System for Mobile Communications
  • GPRS General Packet Radio Service
  • the IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers).
  • SIP Session Initiation Protocol
  • UAs SIP User Agents
  • SDP Session Description Protocol
  • IMS Internet multimedia subsystem
  • 3GPP has chosen SIP for signalling between a User Equipment (UE) and the IMS as well as between the components within the IMS.
  • UE User Equipment
  • An IMS application uses an IMS communication service(s) in order to provide a specific service to the end-user.
  • an IMS communication service is a type of communication defined by a service definition that specifies the rules and procedures and allowed medias for a specific type of communication and that utilises the IMS enablers". Examples of communication services are instant messaging and Push to Talk over Cellular (PoC).
  • a communication service can be thought of as a set of media and the rules that govern them.
  • Each IMS application uses specific IMS Communication Service(s) and provides service to an end user through the reuse of SIP communication.
  • an IMS Application Reference Identifier IARI
  • the IMS application reference has significance at the UE and the SIP AS behaving as SIP endpoints. The IMS application reference can be taken into account when selecting the correct UE(s), if multiple UEs are registered for the same Public User Identity(s).
  • a multimedia telephony communication service 1 is used by a default application 2 for multimedia telephony and by Application 1.
  • a first IARI 3 is associated with Application 1 in order for Application 1 to be identified.
  • a Push to Talk over Cellular (PoC) communication service 4 is used by a default application 5 for PoC and by Application 2.
  • Application 2 is identified by a second IARI 6. - -
  • a core set of categories may be defined and used to minimize the number of lARIs that must be registered in the IMS core, although such IARI categories are not currently standardized.
  • IARI values are included in a Contact header field in SIP REGISTER requests, or in SIP OPTIONS requests/responses. Only one IARI can be included in a SIP request Accept-Contact header at a time. When a UE supports a large number of IMS applications (identified by lARIs), the IMS core might not able to handle a lengthy enumeration of IARI values in the Contact header field.
  • An IARI declaration in SIP REGISTER is required in order that the IMS Core can route terminating requests carrying such an IARI to a UE that has registered support for the application identified by that IARI.
  • An IARI declaration in SIP OPTIONS (or in Presence publications) informs other devices about applications capabilities of a specific user or device.
  • IMS Core may not be able to handle listing of identifiers for a large number of IMS applications. However, it remains necessary to use IMS Core forking mechanisms to limit application traffic only towards devices that support identified applications.
  • a sending device includes an application category identifier identifying a category of the IMS application in a Contact and an Accept-Contact header of a Session Initiation Protocol (SIP) message.
  • An application identifier identifying the IMS application is included in a Session Description Protocol attribute of the Session Initiation Protocol message.
  • the sending device then sends the SIP message towards a receiving device.
  • An advantage of this is that the identifier of the specific application need not be included in an Accept-Contact-header field of the SIP message, and need not be registered in the IMS Core network. Instead only the application category is registered in the IMS Core network and included in an Accept-Contact header field of the SIP message. This reduces the number of identifiers that must be handled by the IMS Core. However, correct routing in the IMS Core is still possible because the - - application category is used to route to the devices that registered with that category, and then correct routing in the recipient device is still possible because the application identifier is contained in the SDP attribute. If a device does not support that application, it simply rejects the SIP message once it realizes it does not support the application listed in the SDP attribute.
  • the application identifier is an IMS Application Reference Identifier (IARI) and the application category identifier is a further IARI.
  • IARI IMS Application Reference Identifier
  • the Session Initiation Protocol message is optionally used to negotiate a Message Session Relay Protocol session.
  • the IMS application category identifier is suitable for registering in an IMS Core network.
  • the method optionally further comprises sending a SIP Register message, the Register message including a further IARI.
  • the sending device is any suitable sending device, an optional example of which is a User Equipment.
  • a method of identifying an IMS application in a communications network receives a SIP message, the SIP message including an application identifier identifying the IMS application in a Session Description Protocol attribute: The message also includes an application category identifier in a Contact and an Accept-Contact header of the message, the application category identifier identifying the category of the IMS application. The receiving device identifies the IMS application using the identifier and routes the SIP message towards the identified IMS application.
  • the application identifier is an IARI and the application category identifier is a further IARI. - -
  • the SIP message is optionally used to negotiate a Message Session Relay Protocol session.
  • the IMS application category identifier is suitable for registering in an IMS Core network.
  • a sending device for use in a communications network.
  • the sending device is provided with a processor that is arranged to include an application identifier identifying an IMS application in a Session Description Protocol attribute of a SIP message.
  • the processor is further arranged to include an application category identifier identifying a category of the IMS application in a Contact and an Accept-Contact header of the Session Initiation Protocol message.
  • a transmitter is also provided, configured to send the SIP message towards a receiving device.
  • the processor is arranged to use an IARI as the application identifier and a further IARI as the application category identifier.
  • the sending device is optionally a User Equipment.
  • receiving device for use in a communications network.
  • the receiving device is provided with a receiver arranged to receive a SIP message, the SIP message including an application identifier identifying an IMS application in a Session Description Protocol attribute.
  • the message includes an application category identifier in a Contact and an Accept- Contact header of the message, the application category identifier identifying the category of the IMS application.
  • a processor is also provided, the processor being configured to identify the IMS application using the identifier and route the SIPmessage towards the IMS application.
  • a computer program comprising computer readable code instructions which, when run from a memory in a processor on a - - computer device, causes the computer device to perform the method steps described above in any of the first and second aspects.
  • a carrier containing the computer program described above in the fifth aspect, wherein the carrier is any of an electronic signal, and optical signal, a radio signal and a computer readable storage medium.
  • Figure 1 illustrates schematically in a block diagram exemplary IMS applications on top of an IMS communication service
  • Figure 2 is a flow diagram showing exemplary steps at a sending device
  • Figure 3 is a flow diagram showing exemplary steps at a receiving device
  • Figure 4 is a flow diagram showing steps at both the sending and the receiving devices;
  • Figure 5 illustrates schematically in a block diagram an exemplary sending device;
  • Figure 6 illustrates schematically in a block diagram an exemplary receiving device.
  • IARI IMS Application Reference Identifier
  • MSRP Message Session Relay Protocol
  • the sending, routing and receiving devices must be capable of interpreting the IARI value in the list of Content Types. This allows, for example, a routing device to identify an IMS application in an incoming SIP request and to route it to the correct IMS application. There is no need to register all IMS applications in the IMS Core network, and so the problem of the IMS Core having to handle identifiers for a large number of IMS applications, is addressed while retaining the ability to use IMS Core forking mechanisms to forward IMS application-specific traffic only towards devices that support the identified IMS applications.
  • Each IMS application is assigned a main IARI category to which it belongs.
  • IARI categories may be based on existing application stores categories. This allows the equivalent standard IARI category values to be inferred from application store categories.
  • the IARI value is now associated with the IARI category instead of with an IMS application. This greatly reduces the number of IARI values that must be registered in the IMS Core network.
  • Registering IARI categories to which an IMS application belongs in the IMS core addresses the problem of reducing the number of registrations in the IMS Core network.
  • a receiving device can interpret an IARI value received inside an SDP attribute, and use it to determine to which IMS application at the receiving device the SIP request should be routed.
  • the IARI relating to a specific IMS application does not need to be known exactly at the time of IMS registration. This allows smaller values (relating to the IARI categories) to be used in the Contact header field of a SIP REGISTER method, which can then be processed by IMS core entities without being impacted by the growing number of IMS applications.
  • SIP messages destined for a specific IMS application will include the application category in the Accept-Contact header.
  • the application category in the SDP attribute of a SIP request is then used by a receiving client (or device) to route the SIP request to the proper IMS application.
  • Figure 2 is a flow diagram showing exemplary steps at a sending device. The following numbering corresponds to that of Figure 2:
  • the sending device includes an application category identifier (in this example, a further IARI associated with the IMS application category) identifying a category of the IMS application in a Contact and an Accept-Contact header of a Session Initiation Protocol message.
  • an application category identifier in this example, a further IARI associated with the IMS application category
  • the sending device includes an IMS application identifier (in this example, the IARI associated with the IMS application) in an SDP attribute of a SIP message.
  • an IMS application identifier in this example, the IARI associated with the IMS application
  • the sending device sends the SIP message towards a receiving device.
  • the receiving device can use the IMS application identifier to route the SIP message towards the correct IMS application.
  • Figure 3 is a flow diagram showing exemplary steps at a receiving device. The following numbering corresponds to that of Figure 3:
  • the receiving device receives the SIP message that includes the IMS application identifier (for example, the IARI) in an SDP attribute.
  • the IMS application identifier for example, the IARI
  • the receiving device is able to identify the IMS application using the IMS application identifier. S6.
  • the SIP message is routed towards the identified IMS application.
  • FIG. 4 is a flow diagram showing steps at both the sending and the receiving devices, to better illustrate how they interact: S7.
  • An IMS application at a sending device is associated with an IMS application identifier (such as an IARI). It is also associated with an IMS application category.
  • IMS application identifier such as an IARI
  • IMS application category is itself associated with an IMS application category identifier (such as a further IARI).
  • the IMS application identifier is built using the application category identifier and the unique application name within that category.
  • a SIP Register is sent towards the IMS Core network.
  • the SIP Register includes the further IARI (identifying the category) in the Contact header filed of the SIP Register message. This allows the IMS application category to be registered in the IMS Core network.
  • the sending device includes the IMS application category identifier in the Accept-Contact header and the IMS application identifier in an SDP attribute of a SIP message (such as a SIP Invite) sent towards a receiving device.
  • ⁇ appname> where ⁇ appname> also includes the application category identifier
  • the sending device sends the SIP message towards a receiving device.
  • the IMS Core determines which receiving devices are registered with the received IMS application category identifier and routes the SIP message only towards those devices.
  • the receiving device receives the SIP message that includes the IMS application category identifier in the Accept-Contact header and the IMS application identifier (e.g. the IARI) in the SDP attribute.
  • the IMS application category identifier e.g. the IARI
  • the receiving device is able to identify the IMS application using the IMS application identifier.
  • the SIP message is routed towards the identified IMS application.
  • the exemplary procedure described in Figure 4 allows the category of the IMS application to be registered in the Core network, without needing the register the IMS application itself.
  • SIP messaging can be routed towards the correct IMS application.
  • an IMS application is a tic-tac-toe game, and exists on a device such as a UE.
  • the tic-tac-toe application runs on top of the Open Mobile Alliance (OMA) Converged IP Messaging (CPM) chat (as the base IMS communication service ICSI).
  • OMA Open Mobile Alliance
  • CCM Converged IP Messaging
  • tictactoe in the SDP attributes of a SIP request, as well as the application category IARI in the Accept-Contact header of the same SIP request (e.g. a SIP INVITE in the CPM chat example) that starts a game with another user.
  • MSRP media being negotiated in the SIP request, as defined in RFC 4975.
  • a processor 8 is provided to include an IMS application category identifier (e.g. a further IARI), as well as an IMS application identifier, such as an application IARI, in an SDP attribute of a SIP message, and a transmitter 9 is provided to send the SIP message towards a receiving node.
  • the sending device 7 may include one or more IMS applications 10, 11 that can be grouped into one of more IMS application - - categories 12.
  • the IMS application category 12 has a category IARI assigned to it, that can be included in the Contact and Accept-Contact header field of SIP messages and registered in the IMS Core.
  • An example of a sending device is a UE, but it will be appreciated that it may be any communications device in a communication network.
  • a non-transitory computer readable medium in the form of a memory 13 is provided. This may be used to store data and/or a program 14 which, when executed by the processor 8, causes the sending device 7 to behave as described above. Note that the program 14 may be provided on an external non-transitory computer readable medium 15, such as a flash drive or disk, or on an optical or electrical carrier wave.
  • a receiver 17 is provided to receive a SIP message that includes an application identifier identifying an IMS application (such as an IARI) in an SDP attribute and an application category identifier (such as a further IARI) in the Contact and Accept-Contact header filed of the SIP message.
  • a processor 18 is provided, arranged to identify the IMS application using the application identifier and route the SIP message towards the identified IMS application 19, 20.
  • An example of a receiving device is a UE, but it will be appreciated that it may be any communications device in a communication network.
  • the receiving device 16 may be provided with a plurality of IMS applications 19, 20, that are grouped into one or more IMS application categories 21.
  • the IMS application category may be associated with an IARI allowing the IMS application category to be registered in the IMS Core network.
  • a non-transitory computer readable medium in the form of a memory 22 is provided. This may be used to store data and/or a program 23 which, when executed by the processor 18, causes the receiving device 16 to behave as described above. Note that the program 23 may be provided on an external non-transitory computer readable medium 24, such as a flash drive or disk, or on an optical or electrical carrier wave.
  • each IMS application is associated with an IMS application category (which may include several different IMS applications).
  • the IMS application category is registered in the IMS core, and so IMS - - applications only need to be registered at a category level. This minimizes the effect of the IMS application ecosystem on the IMS Core, and specifically on the S-CSCF.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention concerne un procédé et un appareil pour identifier une application de sous-système multimédia IP (IMS) dans un réseau de communication. Un dispositif d'envoi comprend un identificateur de catégorie d'application identifiant une catégorie de l'application IMS dans un contact et un en-tête d'acceptation de contact d'un message de protocole d'initiation de session (SIP). Un identificateur d'application identifiant l'application IMS est inclus dans un attribut de protocole de description de session du message de protocole d'initiation de session. Le dispositif d'envoi envoie ensuite le message SIP vers un dispositif de réception. Ceci réduit le nombre d'identificateurs pour des applications spécifiques qui doivent être traités par le cœur IMS.
PCT/SE2014/051196 2013-12-09 2014-10-09 Applications de sous-système multimédia ip WO2015088418A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201361913463P 2013-12-09 2013-12-09
US61/913,463 2013-12-09

Publications (1)

Publication Number Publication Date
WO2015088418A1 true WO2015088418A1 (fr) 2015-06-18

Family

ID=51900950

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2014/051196 WO2015088418A1 (fr) 2013-12-09 2014-10-09 Applications de sous-système multimédia ip

Country Status (1)

Country Link
WO (1) WO2015088418A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105516658A (zh) * 2015-11-30 2016-04-20 浙江宇视科技有限公司 一种监控设备控制方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110103373A1 (en) * 2009-11-03 2011-05-05 Alex Shatsky System and method for session initiation protocol header modification
US20110320555A1 (en) * 2010-06-29 2011-12-29 At&T Intellectual Property I, L.P. Prioritization of protocol messages at a server
US20120331159A1 (en) * 2005-05-25 2012-12-27 Aasrtoem Bo Method and Apparatus for Identifying an IMS Service

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120331159A1 (en) * 2005-05-25 2012-12-27 Aasrtoem Bo Method and Apparatus for Identifying an IMS Service
US20110103373A1 (en) * 2009-11-03 2011-05-05 Alex Shatsky System and method for session initiation protocol header modification
US20110320555A1 (en) * 2010-06-29 2011-12-29 At&T Intellectual Property I, L.P. Prioritization of protocol messages at a server

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ROSENBERG DYNAMICSOFT H SCHULZRINNE COLUMBIA UNIVERSITY P KYZIVAT CISCO SYSTEMS J: "Caller Preferences for the Session Initiation Protocol (SIP); rfc3841.txt", 20040801, 1 August 2004 (2004-08-01), XP015009619, ISSN: 0000-0003 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105516658A (zh) * 2015-11-30 2016-04-20 浙江宇视科技有限公司 一种监控设备控制方法及装置

Similar Documents

Publication Publication Date Title
CN107113294B (zh) 用于实现电信网络呼叫控制的设备和方法
US9294618B2 (en) Call-back to a UE that has made an emergency call via a visited IMS network
EP1964342B1 (fr) Procede et appareil pour rediriger selectivement le controle d'une session pour un sous-systeme multimedia de protocole internet
DK2737678T3 (en) Methods and devices to support the implementation of IMS service continuity
US8848666B2 (en) Handover of emergency calls from a circuit switched to a packet switched access network
EP2792117B1 (fr) Indicateur de service pour la sélection d'un domaine de service
EP3262816B1 (fr) Transposition de domaine dans un réseau ims
EP2112799A1 (fr) Gestion de l'intégrité de service dans un système basé sur IMS
EP2737747A1 (fr) Procédés et dispositifs permettant un transfert d'accès à continuité d'appel vocal radio unique (srvcc) pour une session de rappel d'urgence
WO2019245711A1 (fr) Logique de commande de session avec routage basé sur un protocole internet (ip)
US20090103518A1 (en) Call origination by an application server in an internet protogol multimedia core network subsystem
US9246955B2 (en) Capability query handling in a communication network
US20140370834A1 (en) Disable of supplementary service on emergency in ims network
EP2489210A1 (fr) Procédé pour permettre la délivrance d'un message entre un domaine ims et un domaine cs
US20130060954A1 (en) Enabling set up of a connection from a non-registered ue in ims
EP2149243B1 (fr) Sous-système multimédia IP (IMS) et procédé de routage d'un message http par l'intermédiaire d'un IMS
US9705993B1 (en) Information exchange between a directory assistance application server and a web-RTC engine
WO2015088418A1 (fr) Applications de sous-système multimédia ip
WO2015176746A1 (fr) Procédé et appareil permettant d'établir une session supplémentaire pour un utilisateur anonyme
WO2008117165A2 (fr) Enregistrement urgent dans un système de communication
EP3094059B1 (fr) Routage d'invitations d'appel lte vocaux dans un ims de terminaison
EP3742695B1 (fr) Système et procédé de service de réseau
EP3086593A1 (fr) Entité de réseau et procédé permettant de surveiller un service ims
WO2014086433A1 (fr) Critères de filtre initiaux par défaut
US9350768B2 (en) Suppressing CAMEL service invocation for diverting users

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14799236

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14799236

Country of ref document: EP

Kind code of ref document: A1