Patent Application
20200259873
The present invention relates to method and apparatus for exchanging content between a User Equipment (UE) and an Application Server, AS, of an IP Multimedia Subsystem, IMS. It makes use of a new network function referred to here as a Messaging Resource Function.
IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media that it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services.
IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. 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 IP-based networks. 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). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly.
IMS services are enabled by so-called Application Servers (ASs). An AS may for example provide video conference calls to a group of users connected to the IMS via respective User Equipments (UEs), e.g. mobile phones, laptops etc.
An AS may also want to exchange messages between itself and UEs and other nodes in the IMS. For example, an AS may be used in a Chat Helpdesk, to match customers to agents. It may be desirable to send messages from the AS to the customer, or to receive messages from the customer at the AS. Currently, all IMS ASs that want to make use of the Message Session Relay Protocol (MSRP) must implement an MSRP stack and handle all the complexity that comes with anchoring media. This makes it more difficult to create and manage new IMS ASs with messaging support.
According to a first aspect of the present invention there is provided a method of exchanging content between a User Equipment, UE, and an Application Server, AS, of an IP Multimedia Subsystem, IMS, or between the UE and a peer UE. The method comprises establishing a Session Initiation Protocol, SIP, session between a messaging resource function of the IMS and the AS, and establishing a Message Session Relay Protocol, MSRP, session between the UE and the messaging resource function. The method also comprises exchanging content between the first mentioned UE and the messaging resource function in messages sent over the established MSRP session.
Where content is exchanged between the first mentioned User Equipment, UE, and the Application Server, AS, the method may comprise exchanging said content between the messaging resource function and the AS over the established SIP session.
Exchanging content between the UE and the AS may comprise sending a SIP message comprising instructions from the AS to the messaging resource function over the established SIP session, and sending a message from the messaging resource function to the first mentioned UE over the established MSRP session according to the instructions.
Where content is exchanged between the UE and the peer UE, the method may comprise exchanging said content between the messaging resource function and the peer UE over a further MSRP session.
A SIP INVITE containing an MSRP session setup request may be sent from the UE to the AS to initiate said establishing steps. The MSRP session setup request can be contained within a Session Description Protocol, SDP, part of the SIP INVITE. Upon receipt of the SIP INVITE at the AS, the As may forward the SIP INVITE to the messaging resource function or the AS may construct a further SIP INVITE including the MSRP session setup request and send that further SIP INVITE to the messaging resource function.
The method may comprise receiving as content in a message or messages sent over one of said sessions, a target identity, and upon receipt of the content at the messaging resource function, the target identity can be used to fetch further content from some other entity. The further content is included in said message or messages and sent over a second of the sessions.
In a second aspect of the present invention there is provided a method of operating a messaging resource function within an IP Multimedia Subsystem, IMS, in order to facilitate the exchange of content between User Equipments, UEs, or between the UEs and one or more Application Servers, ASs. the method comprises establishing Session Initiation Protocol, SIP, sessions between the or each AS and the messaging resource function of the IMS, and establishing respective Message Session Relay Protocol, MSRP, sessions between the UEs and the messaging resource function. the method also comprises exchanging content between the UEs and the messaging resource function in messages sent over the respective established MSRP sessions.
Where content is exchanged between the UEs and the one or more ASs, the method may comprise receiving said content from the one or more ASs and/or sending said content to the one or more ASs over the or each established SIP session.
Exchanging content may comprise receiving from the or each AS a SIP message comprising instructions from the AS, and sending messages to the UEs over the respective established MSRP sessions according to the instructions.
Where content is exchanged between UEs, the method may comprise exchanging said content between the messaging resource function and other UEs over the other UEs respective established MSRP sessions.
A SIP INVITE from an AS containing an MSRP session setup request may be received to initiate said establishing steps. The MSRP session setup request may be contained within a Session Description Protocol, SDP, part of the SIP INVITE.
The method may comprise receiving as content in a message or messages sent over one of said sessions, a target identity, and upon receipt of the content, using the target identity to fetch further content from some other entity and including that further content in said message or messages sent over a second of the sessions.
According to a third aspect of the invention there is provided an apparatus for implementing a messaging resource function in an IP Multimedia Subsystem, IMS, to facilitate the exchange of content between User Equipments, UEs, or between the UEs and one or more Application Servers, ASs. The apparatus comprises a processor or processors configured to establish respective Session Initiation Protocol, SIP, sessions between the AS(s) and the messaging resource function of the IMS, and to establish respective Message Session Relay Protocol, MSRP, sessions between the UEs and the messaging resource function. The processor or processors are also configured to exchange content between the UEs and the messaging resource function in messages sent over the respective established MSRP sessions.
The apparatus may comprise a receiver configured to receive messages sent over the established SIP and MSRP sessions, and a transmitter configured to send messages over the established SIP and MSRP sessions.
Where the exchange of content between the UEs and the one or more ASs is facilitated, the receiver may be configured to receive said content from the one or more ASs, and/or the processor may be configured to effect the transmitter to send said content to the one or more ASs over the or each established SIP session.
The receiver may be configured to receive content from the one or more ASs and to receive, from the or each AS, a SIP message comprising instructions from the AS. The processor may be configured to effect the transmitter to send messages to the UEs over the respective established MSRP sessions according to the instructions.
The receiver may be configured to receive said content from other UEs, and/or the processors may be configured to effect the transmitter to send said content to other UEs over the other UEs' respective established MSRP sessions.
The receiver may be configured to receive SIP INVITEs containing an MSRP session setup request to initiate said establishing steps. The MSRP session setup request may be contained within a Session Description Protocol, SDP, part of the SIP INVITEs.
The receiver may be configured to receive as content in a message or messages sent over one of said sessions, a target identity, and the processor may be configured to, upon receipt of the content, use the target identity to fetch further content from some other entity and include that further content in said message or messages, and to effect the transmitter to send said message or messages over a second of the sessions.
The apparatus may comprise a memory for storing instructions which can be effected by the processor to establish the SIP and MSRP sessions, and to exchange content between the UEs and the messaging resource function.
Embodiments of the invention provide a new function in an IP Multimedia Subsystem (IMS) network referred to as a Messaging Resource Function (MsgRF). The MsgRF may be referred to as a “node” in the IMS although it may be implemented as a standalone node, colocated in a node with other functions, and/or implemented in a cloud configuration. The function implements a Session Initiation Protocol (SIP) interface which allows IMS Application Servers (ASs) to manage messaging in sessions or groups via a control protocol based on SIP (e.g. using SIP INFO). This is similar to how MSCML/MSML is used for the Media Resource Function, relying upon the negotiation of a session (also referred to as “establishing a session”) using Session Description Protocol (SDP) via 3pcc (third party call control), sending chat messages, receiving chat messages (like “ivr” used by the MRF for audio/video), managing group sessions (like “conf” used by the MRF to manage conferences).
The MsgRF is configured to enable the UEs and application servers to exchange content over the MSRP sessions and SIP sessions. The SIP session between the MsgRF and an AS can be established by receiving at the MsgRF a SIP INVITE from the AS and sending a SIP response from the MsgRF to the AS. For example, the MsgRF may be configured to receive SIP messages (e.g. SIP INFO messages) comprising instructions from the application servers, and to send messages over MSRP sessions to one or more of the UEs, according to the instructions. The MsgRF may also be configured to fetch images or files to be included in any such MSRP message to one or more UEs. For example, the instructions from the AS may comprise a target identity (e.g. a web address, or file address), which allows the MsgRF to fetch content from some other entity (e.g. a local or remote sever), and include that content in a message over a MSRP session to one or more of the UEs.
In this sense, ‘exchanging content’ comprises both the simple relaying of information from a UE to one or more other UEs or from a UE to an AS via the MsgRF (and vice versa), as well as more complex functions performed by the MsgRF. For example, as described above, the MsgRF may fetch, ad and/or modify the content that is exchanged.
Since the Chat Helpdesk wants to send messages to the customers in the queue it wants to set up an MSRP session between the MsgRF and the customer (UE1). The AS sends a SIP INVITE with the SDP to the MsgRF. The MsgRF receives the SIP INVITE from the AS and sends a SIP 200 response to the AS, which routes the response to the customer (UE1). Sending the response to the customer (UE1) establishes a MSRP session between the MsgRF and the customer (UE1). UE1 sends an ACK message to the MsgRF.
The AS then signals the MsgRF to send a message over the MSRP session, asking what the customer wants. That is, the AS sends a SIP INFO message comprising instructions to the MsgRF. The instructions inform the MsgRF to send a message comprising the text “How can we help?” to the customer (UE1). The MsgRF receives the SIP INFO message from the AS, and sends a message over the MSRP session to the customer (UE1) according to the instructions from the AS. The customer (UE1) answers by sending a message back to the MsgRF over the MSRP session. The message from the customer (UE1) comprises the text “I have a difficult problem”. The MsgRF receives the message from the customer (UE1), and, in response to receiving the message, an event (e.g. a SIP INFO message) is sent from the MsgRF to the AS.
The AS relays the customer message (i.e. the text “I have a difficult problem”) to an AI (Artificial Intelligence) bot using HTTP. The Al bot does not know the answer to the question, and informs the AS of this.
The AS sends a SIP INFO message to the MsgRF, containing instructions to send the text “Please wait to get connected to an agent” to the customer (UE1). The MsgRF receives the message from the AS, and sends the text in a message over the MSRP session to the customer (UE1), according to the instructions. The AS finds an agent (UE2) who might know the answer to the question and connects the agent (UE2) to the chat session. To connect the agent to the chat session, the AS sends a SIP INVITE to the agent (UE2). In response, the agent sends a SIP 200 response with a SDP to the AS. The AS receives the response and sends a SIP INVITE with the SDP to the MsgRF. The MsgRF sends a SIP 200 response to the AS in order to establish a MSRP session between the MsgRF and the agent (UE2). The agent (UE2) sees the history of the chat session with the AI bot and answers the question.
In the scenario described above the MsgRF enables the customer (UE1) and the AS to exchange content over the MSRP session and the SIP session by relaying messages. That is, the MsgRF ‘translates’ MSRP messages (i.e. messages received over the MSRP session) from the UE into SIP messages which can be sent from the MsgRF to the AS over the SIP session. The process also works in reverse, where SIP messages received from the AS are ‘translated’ and sent over the MSRP session to the customer (UE1).
More generally, embodiments provide a method of communication between an AS and one or more UEs, using a MsgRF. To establish a MSRP session between the MsgRF and a UE, the MsgRF receives an INVITE message from the AS originating from the UE. In response, the MsgRF sends a response, e.g. a SIP 200 response, to the UE via the AS. That is, the MsgRF sends the response to the AS, and the AS routes it to the UE. Sending the response from the MsgRF establishes a MSRP session between the MsgRF and the UE. The MsgRF and the UE can send messages directly between each other over the MSRP session.
A second UE may connect (also referred to as “anchor”) to the MsgRF by sending an INVITE to the AS which in turn sends a SIP INVITE to the MsgRF. The MsgRF receives the SIP INVITE, originating from the second UE, from the AS. The MsgRF sends a response, e.g. a SIP 200 response, to the second UE via the AS. That is, the MsgRF sends the response to the AS, and the AS routes the response to the second UE. Sending the response from the MsgRF establishes a (second) MSRP session between the MsgRF and the second UE. The MsgRF and the second UE can send messages directly between each other over the (second) MSRP session. The MsgRF may receive SIP messages from the AS with instructions for sending messages to one or both of the first and second UEs. For example, if a third UE connects to the AS (e.g. a third participant who joins a chat group) the AS may send a message to the MsgRF with instructions to notify the first and second UEs of the third UE connected to the AS. The MsgRF receives the SIP message comprising the instructions from the AS and sends a message over the first and second MSRP sessions to the first and second UEs respectively. Similarly, if a specific UE in a group of UEs, connected to the AS via the MsgRF, leaves the group (e.g. by disconnecting from the network) the AS may send a message (e.g. a SIP INFO message) to the MsgRF comprising instructions to inform each UE remaining in the group that a UE has left the group.
Alternatively, the AS may renegotiate an MSRP session directly between a first UE and a second UE (for example between the customer and the agent), if anchoring is no longer needed. This may be preferable if network resources need to be conserved.
The AS may monitor the session by receiving events (e.g. SIP INFO messages) from the MsgRF when messages are sent or received by the UEs. For example, the first UE may send a message to the second UE over a MSRP session. The message is routed via the MsgRF. As the MsgRF receives the message it may send an event to the AS. The event may comprise the message sent between the UEs.
In one embodiment the MsgRF receives a message (e.g. a SIP INFO message) comprising instructions from the AS. The message may specify a UE or a group of UEs to which the MsgRF is connected by respective MSRP sessions, and instructions to send a message to the specified UE or group of UEs. The message may further comprise content, e.g. text, images or files, to be included in the message to the UE or group of UEs. Alternatively, or in addition, the message may comprise instructions for fetching content to be included in the message to the UE or group of UEs, e.g. with the content to be fetched being identified by a URL.
For example, UE1, UE2, and UE3 may form a group of UEs. UE1, UE2 and UE3 are all connected to an AS (e.g. an application server which provides message conference services). At some point after the UEs have connected to the AS via the MsgRF, a fourth UE (UE4) wants to join the group. The AS receives a SIP INVITE with a SDP from UE4. The AS sends a new SIP INVITE with the SDP and a session identity (ID), related to the group of UEs, to the MsgRF. The MsgRF receives the SIP INVITE from the AS and establishes a MSRP session between the MsgRF and UE4 by sending a SIP response to the AS (which in turn sends a SIP response to UE4). At this stage, the MsgRF receives a message comprising instructions from the AS. The instructions inform the MsgRF to notify UE1, UE2 and UE3 (the original group members) of the arrival of UE4. The message may also contain an image, for example related to a user profile of UE4, which is to be sent with the notification. Alternatively, the instructions may inform the MsgRF to fetch such an image (e.g. from a server, or database). The MsgRF sends a message, comprising the notification and the image, to UE1, UE2 and UE3, according to the instructions from the AS. The UEs in the group may send MSRP messages (i.e. messages over an MSRP session) to each other via the MsgRF.
At some later time, UE1 may accidentally lose its connection to the IMS (e.g. by moving out of WiFi coverage). The AS determines that UE1 is no longer in the group of UEs. For example, the MsgRF may send a SIP INFO message to the AS informing the AS that UE1 is no longer anchored to the MsgRF. The AS instructs the MsgRF to notify UE2, UE3 and UE4 (i.e. the UEs remaining in the group) that UE1 has left the group. The MsgRF receives the message (e.g. a SIP INFO message) comprising the instructions and sends a MSRP message to the UEs remaining in the group, according to the instructions from the AS.
In one embodiment, the MsgRF may be used by the AS to send content generated at one UE to another UE or a group of UEs. The one UE sends the content, to the MsgRF in a message over a MSRP session. The MsgRF receives the message with the content. The MsgRF then sends a SIP message, e.g. a SIP INFO message, comprising the content to the AS. The AS determines that the content is to be shared with another UE or a group of UEs. The AS sends a SIP message, e.g. a SIP INFO message, to the MsgRF with instructions for sending the content to the other UE or the group of UEs. The MsgRF sends a message, comprising the content, to the other UE or the group of UEs according to the instructions.
The customer chooses to also talk to the agent over Real Time Protocol (RTP), e.g. using real time audio or video. The customer sends a Re-INVITE with a new SDP including both a MSRP and RTP media description (MSRP-1 & RTP-1) to the AS (via the CSCF). The MSRP session is kept towards the MsgRF for chat purposes, while the RTP is sent to the agent. That is, the AS sends a Re-INVITE to the MsgRF with the MSRP-1 in the SDP context (media description). The MsgRF sends a SIP 200 response with MSRP-2 in the SDP to the AS. The AS sends a Re-INVITE to the MsgRF for the agent's MSRP session, and the MsgRF sends a SIP 200 response with MSRP-3 in the SDP to the AS. The AS sends a Re-INVITE to the agent with both the RTP and MSRP media descriptions, i.e. the SDP includes MSRP-3 and RTP-1. The agent sends a SIP 200 response with MSRP-4 and RTP-2 in the SDP to the AS. The AS sends an ACK with MSRP-4 to the MsgRF, to update the MSRP session between the MsgRF and the agent.
The AS has both the RTP and MSRP media descriptions from the agent and the MsgRF respectively, and sends a SIP 200 response to the customer (via the CSCF) with MSRP-2 and RTP-2 in the SDP. The customer sends an ACK to the AS which establishes the RTP session between the customer and the agent. The AS also sends an ACK to the MsgRF, which updates the MSRP session between the customer and the MsgRF.
In general, if the SIP INVITE contains multiple media descriptions (including MSRP) in the SDP, the AS may generate a new SIP INVITE with only the request for establishing a MSRP session (i.e. a SIP INVITE with only MSRP as a media description) and send this new SIP INVITE to the MsgRF.
In order to establish a MSRP session between a UE and the MsgRF, the receiver 2 may receive a SIP INVITE from an AS with a request for establishing a MSRP session with the (specified) UE. The processor 4 processes the SIP INVITE (e.g. according to instructions stored in the memory 5) and effects the transmitter 3 to send a SIP response to the UE via the AS, in order to establish the MSRP session.
The node (i.e. the MsgRF) provides a SIP interface which allows IMS ASs to negotiate an MSRP session using SDP, and to interact with the session by receiving events when messages are sent/received and to send messages on the session. The node also allows for control of chat groups via functionality such as adding and removing, or temporarily muting participants (UEs), sending and receiving events for messages and sending messages.
The above described embodiments provide a MsgRF which may allow IMS ASs to build new functionality that includes messaging with less complexity, by taking advantage of the messaging support in the network provided by the MsgRF. This may improve AS development time and hence cost effectiveness.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/SE2017/051089 | 11/2/2017 | WO | 00 |
