WO2016083961A1 - Messagerie et interfonctionnement de messagerie combinée - Google Patents

Messagerie et interfonctionnement de messagerie combinée Download PDF

Info

Publication number
WO2016083961A1
WO2016083961A1 PCT/IB2015/058985 IB2015058985W WO2016083961A1 WO 2016083961 A1 WO2016083961 A1 WO 2016083961A1 IB 2015058985 W IB2015058985 W IB 2015058985W WO 2016083961 A1 WO2016083961 A1 WO 2016083961A1
Authority
WO
WIPO (PCT)
Prior art keywords
messaging
user
combined
messaging server
media feature
Prior art date
Application number
PCT/IB2015/058985
Other languages
English (en)
Inventor
Patrice Varinot
Nancy M. Greene
Original Assignee
Telefonaktiebolaget Lm 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 Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Publication of WO2016083961A1 publication Critical patent/WO2016083961A1/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
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/58—Message adaptation for wireless communication
    • 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]

Definitions

  • IP Internet Protocol
  • IMS Internet Multimedia Subsystem
  • SMS Short Message Service
  • the Session Initiation Protocol is an Internet Engineering Task Force (IETF) standard protocol that allows for the establishment of interactive user sessions involving multimedia elements such as video, voice, chat, gaming, and virtual reality.
  • IETF Internet Engineering Task Force
  • SIP works in the application layer of the Open Systems Interconnection (OSI) communications model and can establish multimedia sessions or Internet telephony calls, modify, or terminate them.
  • OSI Open Systems Interconnection
  • the protocol can also invite participants to unicast or multicast sessions that do not necessarily involve the initiator. Because SIP supports name mapping and redirection services, it makes it possible for users to initiate and receive communications and services from any location, and for networks to identify the users wherever they are.
  • SIP is a request-response protocol, dealing with requests from clients and responses from servers. Participants are typically identified by SIP Uniform Resource Identifiers (URIs). Requests can be sent through any transport protocol, such as the User Datagram Protocol (UDP), the Simple Control Transport Protocol (SCTP), or Transfer Control Protocol (TCP). SIP can determine the end system to be used for the session, the communication media and media parameters, and the called party's desire to engage in the communication. Once these are assured, SIP establishes call parameters at either end of the communication, and handles call transfer and termination.
  • UDP User Datagram Protocol
  • SCTP Simple Control Transport Protocol
  • TCP Transfer Control Protocol
  • SIP services were typically implemented via SIP-based application servers.
  • a SIP application server is a server of the SIP-based distributed network mat provides business logic for one or more application programs that enable the provision of SIP services. Examples of SIP services mat may be provided to SIP users are: SIP conferencing service, SIP presence service, push-to-talk, SIP Session Forwarding, and Messaging Server.
  • IETF defines so-called SIP option tags in RFC 3261. These option tags indicate capabilities of the SIP end-points (e.g. User Equipment (UE), application servers, etc.) of a SIP session.
  • SIP end-point e.g. User Equipment (UE), application servers, etc.
  • An end-point refers to and encompasses any node in a route followed by a SIP message, which may not only include the sender and the receiver of the SIP message, but also any intermediate node, such as for example a SIP-based application server or proxy server, which may be configured to perform processing on the SIP message.
  • the RFC 3261 describes a mechanism in which, during a SIP session, SIP end-points can request from other end-points the capabilities they support, or advertise their own capabilities, or require from the recipient end-point the support of specific capabilities to make the service provision successful.
  • SIP message headers of various SIP messages e.g. SIP INVITE message, SIP OPTIONS message, etc.
  • option tag information “Required”, “Supported”, "Proxy-Required”, and "Unsupported”.
  • a SIP option tag is a string of characters associated with a particular SIP option (i.e., an extension), and identifies the option to SIP end-points.
  • IETF also defines so-called SIP media feature tags in RFC 2506.
  • Media feature tags represent individual and simple characteristics related to media capabilities, properties or preferences associated with the resource to which they are applied. Feature collections may be composed using a number of individual media feature tags. Media feature tags are not bound by a particular transport protocol or capability exchange mechanism.
  • Callee/Caller preferences are used to advertise what capabilities are supported by a given User Equipment (UE) or required from a given UE to establish a SIP communication.
  • the UE may advertise its own capabilities through the use of SIP media feature tags including, for example, using a SIP message's "Contact" header employed during a SIP registration process.
  • a given UE can also find out the media feature tags provided by another UE by sending a SIP OPTIONS request towards the other UE. It may include a SIP "Contact" header with its own media feature tags as well, so that each UE involved can learn about the other UE's supported, or required, features.
  • media feature tags can be discovered through requests and responses that create dialogs such as INVITE.
  • a caller could request a new SIP session to be established with a callee identified by a URI and having a plurality of UE terminals.
  • Feature tags included in the SIP request message could insure that the SIP session is established with the UE that best corresponds to the tags required by the caller.
  • caller preferences describe how a SIP request can be best routed to a UE that provides support as defined by certain media feature tags.
  • GSM Global System for Mobile communications
  • GSMA Global System for Mobile communications
  • RCS Rich Communication Suite
  • 3GPP Third Generation Partnership Project
  • OMA Open Mobile Alliance
  • RCS reuses the capabilities of 3GPP specified Internet Protocol (IP) Multimedia Subsystem (IMS) core system as the underlying service platform taking care of issues such as authentication, authorization, registration, charging and routing.
  • IP Internet Protocol
  • IMS Multimedia Subsystem
  • Unified messaging also interchangeably called integrated or combined messaging is a concept that refers to the integration of different communication streams (SMS, MMS, 1-to-I or group chat or instant messaging, file transfer, location push and voice or video messages) into a single, or, unified message store accessible from a variety of different devices.
  • RCS includes specifications for messaging, instant messaging and combined messaging.
  • GSMA provides specification for combined messaging and the GSMA RCC.61
  • RCS Common Core Service Description Document provides that a UE must be able to indicate whether combined messaging is provided to a user, through a SIP OPTIONS tag, but that if the client does not own the capability to manage unified messaging, the device shall not advertise combined messaging capability.
  • RCS provides mechanisms for interwoiking with legacy messaging services, such as SMS.
  • the user experience is degraded for the user of this UE since the instant messaging application may not be able, for some platforms, to access and/or retrieve the SMS messages and to display these messages in single conversation thread offering a combined view of all the communication streams.
  • SMS Short Message Service
  • the method comprises receiving at a second messaging server a Session Initiation Protocol (SIP) INVITE or a 200 OK response message, comprising a first media feature tag. indicative of support of combined messaging for a primary device of a first user, and a second media feature tag, indicative of support of combined messaging for a first messaging server serving a first device of the first user.
  • SIP Session Initiation Protocol
  • the method further comprises, responsive to receiving the first and second media feature tags, determining, at the second messaging server, if interworking from IMS messaging to SMS is available for a second device associated with a second user served by the second messaging server, in the event of a loss of data connectivity at least at one point along a path between the first and second devices.
  • a messaging server comprising processing circuitry and memory, the memory contains instructions executable by the processing circuitry whereby the messaging server is operative to receive, a Session Initiation Protocol (SIP) INVITE or a 200 OK response message, comprising a first media feature tag, indicative of support of combined messaging for a primary device of a first user, and a second media feature tag, indicative of support of combined messaging for a first messaging server serving a first device of the first user.
  • SIP Session Initiation Protocol
  • the messaging server is further operative to, responsive to receiving the first and second media feature tags, determine if interworking from IMS messaging to SMS is available for a second device associated with a second user served by the messaging server, in the event of a loss of data connectivity at least at one point along a path between the first and second devices.
  • a user terminal comprising processing circuitry and memory, the memory containing instructions executable by the processing circuitry whereby the user terminal is operative to receive, a Session Initiation Protocol (SIP) INVITE or a 200 OK response message, comprising a first media feature tag, indicative of support of combined messaging for a primary user terminal of a first user, and a second media feature tag, indicative of support of combined messaging for a first messaging server serving a first user terminal of the first user.
  • the user terminal is further operative to, responsive to receiving the first and second media feature tags, determine if interworking from IMS messaging to SMS is available for the user terminal in the event of a loss of data connectivity at least at one point along a path between the user terminal and the first user terminal.
  • a messaging server instance in a cloud computing environment providing processing and interface circuitry and memory, the memory containing instructions executable by the processing circuitry whereby the messaging server instance is operative to receive, a Session Initiation Protocol (SIP) INVITE or a 200 OK response message, comprising a first media feature tag, indicative of support of combined messaging for a primary device of a first user, and a second media feature tag, indicative of support of combined messaging for a first server serving a first device of the first user.
  • SIP Session Initiation Protocol
  • the messaging server instance is further operative to, responsive to receiving the first and second media feature tags, determine if interworking from IMS messaging to SMS is available for a second device associated with a second user served by the messaging server, in the event of a loss of data connectivity at least at one point along a path between the first and second devices.
  • a messaging server for detennining availability of mtemorking from IMS messaging to Short Message Service (SMS) when combined messaging is used by at least one network entity involved in a messaging session.
  • the messaging server comprises a receiving module, for receiving a Session Initiation Protocol (SIP) INVITE or a 200 OK response message, comprising a first media feature tag, indicative of support of combined messaging for a primary device of a first user, and a second media feature tag, indicative of support of combined messaging for a first messaging server serving a first device of the first user.
  • SIP Session Initiation Protocol
  • the messaging server further comprises a processing module for determining, responsive to receiving the first and second media feature tags, if interworking from IMS messaging to SMS is available for a second device associated with a second user served by the messaging server, in the event of a loss of data connectivity at least at one point along a path between the first and second devices.
  • Figure 1 is a schematic illustration of some entities involved in a messaging communication according to an embodiment
  • Figure 2 is a flowchart illustrating steps of a method according to an embodiment
  • Figure 3 is a signaling flow illustrating a REGISTER operation according to an embodiment
  • Figures 4 a-c is a signaling flow illustrating messages exchange where primary device A does not support combined messaging but network A supports combined messaging, and both primary device B and Network B support combined messaging, according to an embodiment.
  • Figure 5 a-c is a signaling flow illustrating messages exchange where both primary device A and network A do not support combined messaging, and both primary device B and Network B support combined messaging, according to an embodiment
  • Figure 6 illustrates a messaging server according to an embodiment.
  • Figure 7 illustrates a user terminal or device according to an embodiment
  • Figure 8 illustrates a messaging server instance running in the cloud environment according to an embodiment.
  • FIG. 9 illustrates a messaging server according to an alternative embodiment
  • Rich Communication Suite provides mechanisms for mterworking with legacy messaging services, such as Short Message Service (SMS), when two or more devices are in communication using a messaging and there is a failure or unavailability of the data service for at least one of the devices.
  • SMS Short Message Service
  • legacy messaging services such as Short Message Service (SMS)
  • SMS Short Message Service
  • the user experience is degraded for the user of mis device since the instant messaging application may not be able, for some platforms, to access and/or retrieve the SMS messages and to display these messages in single conversation thread offering a combined view of all the communication streams.
  • IP Internet Protocol
  • IMS Internet Multimedia Subsystem
  • the devices can be served by different operator networks, but both devices could alternately be served by the same operator network and could be served by the same or by a different messaging server.
  • the present disclosure covers many use case, one for each combination of devices and servers configuration and for the different places where the loss of connectivity can occur.
  • Figure 1 illustrates the main entities involved in the combined messaging session.
  • Each of device 10, messaging server 11, messaging server 21 and device 20 can either support or not support combined messaging. Failure in the communication path can occur at any point 30, 31 or 32 between two or more of these entities. And a user involved in the communication can either be using his/her primary device or another of his/her devices.
  • a method for determining availability of interworking from IMS messaging to Short Message Service (SMS) when combined messaging is used or supported by at least one network entity 10, 11, 20, 21 involved in a messaging sessioa comprises receiving, step 201, at a second messaging server 21, a Session Initiation Protocol (SIP) INVITE or a 200 OK response message, comprising a first media feature tag, indicative of support of combined messaging for a primary device 10 of a first user, and a second media feature tag, indicative of support of combined messaging for a first messaging server 11 serving a first device of the first user.
  • SIP Session Initiation Protocol
  • the indication may take the form of a binary value such as true/false or of any other suitable value, string, flag, etc.
  • the second messaging server 21 determines if interworking from IMS messaging to SMS is available for a second device 20, associated with a second user and served by the second messaging server 21, in the event of a loss of data connectivity at least at one point along a path between the first and second devices 10, 20.
  • the media feature tags may be added to the SIP INVITE and 200 OK response by the messaging servers 11, 21 upon receiving information from the devices 10, 20 that can be used to determine the values to add.
  • the messaging servers can send messages via SMS to or from the device that lost connectivity.
  • the device that did not lose connectivity does not support combined messaging, it cannot send or receive messages in the form of an SMS, such messages have to be IMS messages which may be converted by the serving messaging server, which therefore needs to support combined messaging in order to handle the SMS messages.
  • the first media feature tag indicates support of combined messaging for a primary device of the user.
  • the primary device can be the same device as the first device (i.e. the device being used during the messaging session) by the first user.
  • the primary device can also be a different device; this case will be addressed further below.
  • step 203 that interworking from IMS messaging to SMS is not available to the second device.
  • the second device does not send an SMS to the first device if the first device and its corresponding server both do not support combined messaging, because men the SMS would not be available to be read in the messaging window of the RCS based application.
  • step 204 when data connectivity is lost anywhere between the first and the second devices, it is determined, step 204, that interworking from IMS messaging to SMS is available to the second device.
  • the SMS message can be incorporated into the combined messaging view of the RCS based application.
  • the SMS can go to the user device and be integrated in the combined messaging view of the RCS based application. In this case, however, when the same conversation thread is read from another device, the SMS may be lost since they may not have been combined at the messaging server since this one does not support combined messaging.
  • the first media feature tag indicates that combined messaging is not supported by the primary device of the first user and the second media feature tag indicates that combined messaging is supported by the first messaging server
  • the SMS is intercepted by the messaging server and converted to an IMS message that can be transferred to the user device.
  • the first messaging server can buffer messages, step 205, received from the second device until the data connectivity is restored between the first device and the first messaging server. Further, if the message received is an SMS, the first messaging server can convert, step 206, the SMS to an IMS message before sending it to the first device when the data connectivity is restored between the first device and the first messaging server.
  • the second messaging server can buffer, step 207, messages received from the second device until the data connectivity is restored between the first and second messaging servers and then send the buffered messages towards the first messaging server.
  • the primary device of the first user may not be the same device as the first device of the first user.
  • the first feature tag for this user is based on the support or no support of combined messaging of the primary device of the user. Determining if interworking towards SMS is available therefore depends on the capabilities of the primary device.
  • the first messaging server 11 and the second messaging server 21 could be the same entity and the first and second devices 10, 20 could be served by a same operator's network and the same messaging server. The method would basically be executed in a similar manner, but inter-operator connection failure would not happen. If two messaging servers of the same operator were serving the devices, then the method would also be executed in a similar manner, but inter messaging server failure might be possible.
  • the third party SIP REGISTER includes a message/sip content type containing the User- Agent header from the UE.
  • the messaging server may determine, based on information received during the third party IMS registration, for example based on the values describing the device in the User-Agent header field, whether the information is related to the primary device and store information about the primary device support or no support of combined messaging.
  • a Messaging Server has different functions: Participating Function (PF), where a particular subscriber's services are handled, Controlling Function (CF) for handling group chat conference focus and Interworking Function (IWF) for interworking to/from SMS/MMS i.e. the decision to interwork is made in the CF or PF which then sends the request to the IWF.
  • PF Participating Function
  • CF Controlling Function
  • IWF Interworking Function
  • an originating PF determines that the user primary device is e.g. an iPhone® Operating System (IOS) device which does not support combined messaging
  • IOS Operating System
  • every INVITE request for this user is modified to include a feature tag specifying it, considering that the message or chat may be initiated by the primary device or by any other devices from this user.
  • a second feature tag is inserted if the originating network support majority of e.g. IOS devices that support combined messaging. This information is inserted whether or not the originating sender uses an IOS device.
  • this information When this information is received on the tenninating PF node, it may be used, for example, for IOS notification creation. Information already stored for the served user on the terminating side is used by the tenninating PF node to know whether or not to create an IOS push notification creation. This information is passed to the orchestration level and kept for future use, for example when Store and Forward (S&F) happens.
  • S&F Store and Forward
  • This information on the sender of the message has to be stored with the recipient user's S&F message so it can be taken into consideration at the subsequent message delivery attempt [0057]
  • the sender primary device information is retrieved from the Messaging Server.
  • the feature tag "combined messaging" is included or not in the SEP request contact header sent to the terminating messaging server.
  • the sender information is received by the terminating network via SIP, and is included in any message stored when unsuccessful delivery happens.
  • the IOS application Since the IOS application is not always running in the background, it is notified so that it can register in IMS and thus it is available to receive incoming messages via IMS.
  • IOS When IOS is used by either the sender or receiver, the combined messaging experience is kept by forcing end to end (e2e) communication via RCS/EMS, instead of allowing fall back to SMS.
  • the IOS application can be started up by issuing an IOS push notification.
  • the primary device is the driver for setting up an e2e communication via RCS/IMS versus fall back to SMS.
  • the combined or integrated messaging media feature tag configured on the device (Messaging UX parameter defined in RCC.61 Common Core SDD) is defined to be used in SIP OPTIONS. This is not sufficient to be used for the SEP INVITE, since what the remote side needs to know is whether the sender's primary device supports integrated messaging or not, and in multi-device scenarios, the sender might not have used their primary device at that moment Therefore this feature tag is added to the SIP request by the originating Messaging Server PF instead of having the client add it And, of course, the terminating Messaging Server adds the feature tag corresponding to the primary device of the recipient to the SEP response.
  • the message recipient has access to the feature tags received in the SEP EMVITE or 200 OK response for the sender of the message (message may have been received in the SEP INVITE or via Messaging Session Relay Protocol (MSRP) SEND). This may be done through a plug-in.
  • Table 1 is a Decision table for how to deliver a message when data connectivity to the receiver's user device is lost and is used to determine how to deliver the message to the recipient if connectivity is lost towards the recipient user.
  • FIG. 3 is a signaling flow illustrating a Register operation according to an embodiment
  • the first device 10, also labeled UE-A sends a REGISTER, at step 301, to the messaging server 11 through the Call Session Control Function CSCF 310.
  • the register message comprises a media feature tag indicating that combined messaging is not supported.
  • the messaging server sends a 200 OK to the device 10 and determines from the User-Agent that UE-A is the primary device of the user.
  • the messaging server stores that device 10 does not support combined messaging.
  • the messaging server checks, at step 303, if there are stored messages for the user of device 10. Since there is no stored message, no action is taken.
  • the second device 20 also labeled UE-B
  • sends a REGISTER at step 304, to the messaging server 21 through the CSCF 320.
  • the register message comprises a media feature tag indicating that combined messaging is supported.
  • the messaging server sends a 200 OK to the device 20 and determines from the User-Agent that UE-B is the primary device for the user.
  • the messaging server stores that device 20 supports combined messaging.
  • the messaging server then checks, at step 306, if there are stored messages for the user of device 20. Since there is no message, no action is taken.
  • Figure 4a-c is a signaling flow illustrating an INVITE and subsequent message exchanges where the primary device 10 of the first user does not support combined messaging but first messaging server 11 supports combined messaging, and both the second device 20 and messaging server 21 supports combined messaging.
  • the first device 10 sends a SIP INVITE with first media feature tag and message "Hi, how are you” 422 to the CSCF 310, which forwards it at step 402 towards the messaging server 11, which adds to its database that UE-A requires push messaging.
  • the messaging server 11 responds to the CSCF 310 at step 403 and the CSCF sends the SIP INVITE towards the second device 20 at step 404, including in the SIP INVITE the first media feature tag, indicating that the primary device for the first user does not support combined messaging and a second media feature tag indicating that the messaging server 11 supports combined messaging.
  • the CSCF 320 forwards the SIP INVITE to the messaging server 21, which then transmits the same SIP INVITE to the second device 20 at steps 406 and 407.
  • the second device 20 responds with a 200 OK message indicating, with a first media feature tag, that it supports combined messaging, at step 408.
  • the message is transmitted to the CSCF 320 which forwards the 200 OK to the messaging server 21 at step 409.
  • the messaging server adds to its database that the second device 20, UE-B, does not require push notification. Push notification may be requested, for some types of devices, when the device does not support combined messaging.
  • the messaging server 21 also adds the second media feature tag indicating that it supports combined messaging to the 200 OK message.
  • the 200 OK is then transmitted towards the first device 10 at steps 411 to 415 with bom the first and second feature tags.
  • the MSRP session is now setup.
  • the message 422 can be transmitted from the first device 10 to the second device 20, through both messaging servers 11 and 21, at step 417.
  • the connection is broken between the second device 20 and the second messaging server 21.
  • the second device 20 knowing that the messaging server 11 serving the first device 10 supports combined messaging decides to interwork to SMS and sends the message "Pretty good" 424, as an SMS at step 419.
  • the messaging server 11 receives the message and converts it to an IMS message or standalone message and forwards it to the first device at steps 420 and 421.
  • the user of die first device sends the message "What r u doing?" 42S to the second user, at step 429.
  • the message is relayed to the second messaging server 21 which converts it to SMS and forwards it, at step 430, towards the second device 21.
  • the user of the second device responds "Not much" 426 while the connection is being reestablished.
  • a reestablishment of the session is executed at steps 431 to 436 and the message 426 is sent towards the first device normally at step 437.
  • the user of the first device sends the message "Meet for dinner?" 427, at step 438, towards the second device, but the connection is now lost between the first and second messaging servers 11 and 21.
  • the first messaging server stores the messages and tries to deliver it again after a timer expires. Eventually, based on a local timer in the first messaging server, the connection is reestablished at steps 440 to 445.
  • the message 427 is then sent to the second device at steps 446 and 447.
  • the user of the second device responds "Sure where?" 428 and this message is sent towards the first device at step 448.
  • the first device sends the message "that new place” 449 at step 454 towards the second device.
  • the user of the second device replies “what time?" 4S0 at step 45S, but the connection gets broken between the first device 10 and the first messaging server 11.
  • the first messaging server stores the messages 450, step 457. and waits until the connection to the first device is reestablished.
  • the user of first device 10 who is waiting for an answer, sends a message "when?" 451 to the second device using an SMS, step 458.
  • the connection is reestablished between the first device and the first messaging server at steps 459, 460, 462 and 463.
  • the messaging server checks if there are messages waiting to be sent to the first device and sends the message 450 at step 464 when the connection is reestablished.
  • Both users exchange messages 452 and 453 normally at steps 465 and 466 concluding the message exchange. After a period of inactivity the first messaging server 11 tears down me session, steps 467 to 472.
  • Figure 5a-c is a signaling flow illustrating an INVITE and subsequent message exchanges where both the primary device for the first user and the first messaging server do not support combined messaging and both the primary device for the second user and the second messaging server support combined messaging.
  • the first device 10 sends a SIP INVITE with first media feature tag indicating that combined messaging is not supported and that push notification is requested along with message "Hi, how are you?" 522 to the CSCF 310, which forwards it at step 502 towards the messaging server 11.
  • the messaging server 11 adds to its database that the first device 10, UE-A, requires push messaging.
  • the messaging server 11 responds to the CSCF 310, at step 503, and the CSCF sends the SIP INVITE towards the second device 20 at step 504, including, in the SIP INVITE, the first media feature tag indicating that the primary device for the first user does not support combined messaging and a second media feature tag indicating that the messaging server 11 does not support combined messaging.
  • the CSCF 320 forwards the SIP INVITE to the messaging server 21, which then transmits the same SIP INVITE to the second device 20 at steps 506 and 507.
  • the second device 20 responds with a 200 OK message including a first media feature tag indicating that it supports combined messaging, at step 508.
  • the message is transmitted to the CSCF 320 which forwards the 200 OK to the messaging server 21 at step 509.
  • the messaging server adds to its database that the second device 20, UE-B, does not require push notification and adds the second media feature tag indicating that it supports combined messaging to the 200 OK message.
  • the 200 OK is then transmitted towards the first device 10 at steps SI 1 to SIS with both the first and second media feature tags.
  • the Messaging Session Relay Protocol (MSRP) session is now setup.
  • MSRP Messaging Session Relay Protocol
  • the message 522 can be transmitted from the first device 10 to the second device 20, through both messaging servers 11 and 21, at step 517.
  • the second device tries to send the message "pretty good" 524, but the connection is broken between the second device 20 and the second messaging server 21.
  • the second device 20 knowing that the messaging server 11 serving the first device 10 does not support combined messaging does not fall back to SMS, do not send the message 524 and waits.
  • the user of the first device sends the message "What r u doing?" 525 to the second user, at step 529.
  • the message is relayed to the second messaging server 21 which does not convert it to SMS because the primary device of the first user does not support combined messaging.
  • the reason for this is that, in some example case, the second device could respond back with SMS to a received SMS while the first device would not support combined messaging and the first messaging server would not be able to interwork the SMS message to an IMS message.
  • the connection is reestablished at steps 531 to 535.
  • the message "What r u doing?" 525 can now be sent by the messaging server 21 , at step 530, towards the second device 20.
  • the user of the second device responds "Not much", step 537.
  • the user of the first device sends the message "Meet for dinner?" 527, at step 538, towards the second device, but the connection is now lost between the first and second messaging servers 11 and 21.
  • the first messaging server stores the messages and tries to deliver it again after a timer expires. There is no fall back to SMS. Eventually the connection is reestablished at steps 540 to S4S.
  • the message 527 is then sent to the second device at steps 546 and 547.
  • the user of the second device responds "Sure where?" 528 and this message is sent towards the first device at step 548.
  • the first device sends the message "that new place” 549 at step 554 towards the second device 20.
  • the user of the second device replies “what time?" 550 at step 555, but the connection gets broken, step 556, between the first device 10 and the first messaging server 11.
  • the first messaging server stores the message, step 557, and waits until the connection to the first device is reestablished.
  • the user of first device 10 who is waiting for an answer, sends a message "when?” 551 to the second device using an SMS, step 558.
  • the connection is then reestablished between the first device and the first messaging server at steps 559, 560, 562 and 563.
  • the messaging server checks if there are messages waiting to be sent to the first device and sends the message 550, at step 564, when the connection is reestablished.
  • a messaging server 11 comprising a processor 610, or processing circuitry, and memory 620.
  • the memory 620 contains instructions executable by the processor 610, which is operative to execute the method described above.
  • the messaging server comprises processing circuitry 610 and memory 620, the memory containing instructions executable by the processing circuitry whereby the messaging server is operative to receive, a Session Initiation Protocol (SIP) INVITE or a 200 OK response message, comprising a first media feature tag, indicative of support of combined messaging for a primary device of a first user, and a second media feature tag, indicative of support of combined messaging for a first messaging server serving a first device of the first user.
  • SIP Session Initiation Protocol
  • FIG. 6 is a block diagram of a messaging sever node 11, 21 suitable for implementing aspects of the embodiments disclosed herein. As discussed above, in the context of messaging mterworking, the messaging sever node 11, 21 may include a communication interlace 630.
  • the communication interface 630 generally includes analog and/or digital components for sending and receiving communications to and from mobile devices 10, as well as sending and receiving communications to and from other messaging server 21 , either directly or via a network.
  • the block diagram of the messaging server 11 necessarily omits numerous features that are not necessary for a complete understanding of this disclosure.
  • the messaging server 11 comprises one or several general-purpose or special-purpose processors 610 or other microcontrollers programed with suitable software programming instructions and/or firmware to carry out some or all of the functionality of the messaging server 11 described herein.
  • the messaging server 11 may comprise various digital hardware blocks (e.g., one or more Application Specific Integrated Circuits (ASICs), one or more off-the-shelf digital or analog hardware components, or a combination thereof) (not illustrated) configured to carry out some or all of the functionality of the messaging server 11 described herein.
  • ASICs Application Specific Integrated Circuits
  • a memory 620 such as a random access memory (RAM) may be used by the processor 610 to store data and programming instructions which, when executed by the processor 610, implement all or part of the functionality described herein.
  • the messaging server 11 may also include one or more storage media (not illustrated) for storing data necessary and/or suitable for implementing the functionality described herein, as well as for storing the programming instructions which, when executed on the processor 610, implement all or part of the functionality described herein.
  • One embodiment of the present disclosure may be implemented as a computer program product that is stored on a computer-readable storage medium, the computer program product including programming instructions that are configured to cause the processor 610 to cany out the steps described herein.
  • a user terminal 10 comprising a processor or processing circuitry 710 and memory 720.
  • the memory 720 contains instructions executable by the processor 710, which is operative to execute the method described above.
  • the I/O interface 730 may be used by the user terminal 10 to send/receive messages.
  • a messaging server instance in a cloud computing.
  • a general-purpose network device includes hardware 830 comprising a set of one or more processor(s) or processing circuitry 860, which can be commercial off-the-shelf (COTS) processors, and network interface controllers) 870 (NICs), also known as network interface cards, which include physical Network Interface 880, as well as a memory, or non-transitory machine readable storage media 890 having stored therein software 895 and/or instructions executable by the processor.
  • COTS commercial off-the-shelf
  • NICs network interface controllers
  • NICs network interface cards
  • the processor(s) 860 execute the software 895 to instantiate a hypervisor 850, sometimes referred to as a virtual machine monitor (VMM), and one or more virtual machines 840, 841 that are run by the hypervisor 850, which are collectively referred to as software instances) 820.
  • a virtual machine is a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtual ized machine; and applications generally do not know they are running on a virtual machine as opposed to running on a "bare metal" host electronic device, though some systems provide para-viitualization which allows an operating system or application to be aware of the presence of virtualization for optimization purposes.
  • Each of the virtual machines 840, 841, and that part of the hardware 830 that executes that virtual machine be it hardware dedicated to that virtual machine and/or time slices of hardware temporally shared by that virtual machine with others of the virtual machines) 840, 841, forms a separate virtual network elements) (VNE) 810.
  • VNE virtual network elements
  • the hypervisor 850 may present a virtual operating platform that appears like networking hardware to virtual machine 840, and the virtual machine 840 may be used to implement functionality such as control communication and configuration module(s) and forwarding table(s), this virtual ization of the hardware is sometimes referred to as network function visualization (NFV).
  • NFV network function visualization
  • CPE customer premise equipment
  • Different embodiments of the messaging server instance may be implemented on one or more of the virtual machine(s) 840, 841, and the implementations may be made differently.
  • a messaging server 11 for determining availability of interworking from IMS messaging to Short Message Service (SMS) when combined messaging is used by at least one network entity involved in a messaging session.
  • the messaging server comprises a receiving module 930, for receiving a Session Initiation Protocol (SIP) INVITE or a 200 OK response message, comprising a first media feature tag, indicative of support of combined messaging for a primary device of a first user, and a second media feature tag, indicative of support of combined messaging for a first messaging server serving a first device of the first user.
  • SIP Session Initiation Protocol
  • the messaging server also comprises a processing module 910, which may communicate with a memory module 920 to get executable instructions, for detennining, responsive to receiving the first and second media feature tags, if interworking from IMS messaging to SMS is available for a second device, associated with a second user served by the messaging server, in the event of a loss of data connectivity at least at one point along a path between the first and second devices.
  • a processing module 910 which may communicate with a memory module 920 to get executable instructions, for detennining, responsive to receiving the first and second media feature tags, if interworking from IMS messaging to SMS is available for a second device, associated with a second user served by the messaging server, in the event of a loss of data connectivity at least at one point along a path between the first and second devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé, un serveur de messagerie et un terminal d'utilisateur permettant de déterminer la disponibilité d'interfonctionnement entre une messagerie de sous-système multimédia IP (IMS pour IP Multimedia Subsystem) et une messagerie texto (SMS pour Short Message Service) lorsqu'une messagerie combinée est utilisée par au moins une entité de réseau impliquée dans une session de messagerie. Le procédé consiste à recevoir, au niveau d'un second serveur de messagerie, un message comprenant une première étiquette de caractéristique multimédia, indiquant une capacité de prise en charge d'une messagerie combinée pour un dispositif principal d'un premier utilisateur, et une seconde étiquette de caractéristique multimédia, indiquant une capacité de prise en charge d'une messagerie combinée pour un premier serveur de messagerie desservant un premier dispositif du premier utilisateur, et, suite à la réception des étiquettes de caractéristiques multimédia, à déterminer, au niveau du second serveur de messagerie, si un interfonctionnement entre la messagerie de sous-système IMS et une messagerie SMS est disponible pour un second dispositif associé à un second utilisateur desservi par le second serveur de messagerie, dans le cas d'une perte de connectivité des données, au moins en un point, le long d'un chemin entre les premier et second dispositifs.
PCT/IB2015/058985 2014-11-26 2015-11-19 Messagerie et interfonctionnement de messagerie combinée WO2016083961A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201462085085P 2014-11-26 2014-11-26
US62/085,085 2014-11-26

Publications (1)

Publication Number Publication Date
WO2016083961A1 true WO2016083961A1 (fr) 2016-06-02

Family

ID=54783962

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2015/058985 WO2016083961A1 (fr) 2014-11-26 2015-11-19 Messagerie et interfonctionnement de messagerie combinée

Country Status (1)

Country Link
WO (1) WO2016083961A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2249590A2 (fr) * 2008-02-13 2010-11-10 Samsung Electronics Co., Ltd. Procédé et système d'interfonctionnement de service de messagerie convergé
EP2493166A1 (fr) * 2011-02-11 2012-08-29 Vodafone IP Licensing Limited Système et procédé de communications sur la base de la capacité de service et d'une présence sociale

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2249590A2 (fr) * 2008-02-13 2010-11-10 Samsung Electronics Co., Ltd. Procédé et système d'interfonctionnement de service de messagerie convergé
EP2493166A1 (fr) * 2011-02-11 2012-08-29 Vodafone IP Licensing Limited Système et procédé de communications sur la base de la capacité de service et d'une présence sociale

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
GSM ASSOCIATION: "RCS Common Core Service Description Document RCS Common Core Service Description RCC.61", 16 September 2014 (2014-09-16), pages 1 - 172, XP055253981, Retrieved from the Internet <URL:http://www.gsma.com/network2020/wp-content/uploads/2014/07/RCS-Common-Core-SDD-V1.0.pdf> [retrieved on 20160229] *

Similar Documents

Publication Publication Date Title
US9065970B2 (en) Method and system for facilitating communication between wireless communication devices
CN107251510B (zh) 一种用于建立并且保持voip呼叫的系统、装置以及方法
US20130179521A1 (en) Method and device for implementing a group session
CN100512461C (zh) 消息业务实现方法和消息应用服务器
US9467406B2 (en) Devices for instant message client swap
KR20100127316A (ko) 메시지 및 세션의 교환
EP3172880B1 (fr) Procédé et équipement de gestion de communications permettant de commander l&#39;établissement d&#39;une session de communication dans un réseau de communications multimédia
EP2892186A1 (fr) Procédé et serveur permettant à un premier utilisateur de découvrir automatiquement les identificateurs de réseau social d&#39;un second utilisateur et les états respectifs de ce second utilisateur dans ces réseaux sociaux
CN106161201B (zh) 一种以邮箱账号为标识参与群聊的方法、设备及系统
EP3100446B1 (fr) Techniques de communication
GB2488120A (en) Facilitating communication between devices by requesting a status indicator of the ability of a second device to use a second communication method.
EP3704841A1 (fr) Fonction de ressource de messagerie
US8606243B2 (en) Mobile network system and guidance message providing method
WO2016083961A1 (fr) Messagerie et interfonctionnement de messagerie combinée
US9367367B2 (en) Application router
CN108337215B (zh) 一种文件传输方法及系统、装置、电子设备
EP2640029A1 (fr) Système et procédé de transmission de messages multimédias multipages, terminal sip et serveur proxy de messagerie multimédia
US9900352B2 (en) SIP network border element session augmentation
KR20170034016A (ko) 무선 통신 시스템에서 메시지 수신 정보를 송신하기 위한 장치 및 방법
TR201720818A2 (tr) Sip tabanli konferans sunuculari i̇çi̇n eşler arasi oturum yeni̇leme yöntemi̇

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: 15805292

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: 15805292

Country of ref document: EP

Kind code of ref document: A1