Multimedia telephony communications

Abstract

A method of establishing a multimedia connection, such as an augmented reality (AR) connection, in a mobile communication network is provided. The connection is established between a source terminal, an Internet Protocol Multimedia Subsystem (IMS), a media application server, and a target terminal. The source terminal requests (e.g., by indicating multimedia support) media application server information from the IMS and receives the media application server information from the IMS. Based on the received media application server information, the source terminal requests multimedia (e.g., AR) related data from and receives the multimedia (e.g., AR) related data from the media application server. The source terminal then initiates a multimedia connection with the target terminal based on the received multimedia-related data. The media application server includes a web server function.

Description

Technical Field

[0001] The example embodiments described herein relate generally to mobile communication networks, such as, for example, 5G communication networks, and particularly to facilitating multimedia telephony, and more particularly to facilitating augmented reality (AR) telephony communications. Background Art

[0002] AR telephony is being developed for different types of AR-capable terminals. IP Multimedia Subsystem (IMS) procedures including signaling and media processing are used to support AR telephony. For example, two IMS-based AR communication solutions have been proposed, both of which use the Data Channel (DC) framework, e.g., AR metadata is downloaded to the terminal via a DC application. Summary of the invention

[0003] According to a first exemplary embodiment, a method for establishing a multimedia connection (e.g., an augmented reality (AR) multimedia connection) in a mobile communication network is provided. The method includes a source terminal, an Internet Protocol Multimedia Subsystem (IMS), a media application server, and a target terminal. The source terminal requests media application server information from the IMS (e.g., by indicating multimedia support to the IMS) and receives media application server information from the IMS. Based on (e.g., by using) the received media application server information, the source terminal requests multimedia-related data (e.g., AR-related data) from the media application server. The source terminal receives the multimedia-related data from the media application server (e.g., through a secure connection). Based on (e.g., by using) the received multimedia-related data, the source terminal initiates the multimedia connection with the target terminal.

[0004] In some example embodiments, the media application server information includes a media application server address or a uniform resource identifier (URI) and / or a link to the AR-related data.

[0005] In some example embodiments, the media application server information includes terminal AR capabilities and / or network AR capabilities.

[0006] In some example embodiments, the AR-related data includes at least one of the following: an AR object, AR-related metadata, and an AR application.

[0007] In some example embodiments, the AR object comprises a video, an image, a point cloud, and / or a 2D / 3D media representation, and the AR-related metadata comprises AR object characteristics such as depth and / or object position.

[0008] In some example embodiments, the source terminal requests media application server information from the IMS based on (eg, by using) a Session Initiation / Description Protocol (SIP / SDP) of the mobile communication network and receives the media application server information from the IMS.

[0009] In some example embodiments, the source terminal requests and receives AR-related data based on (e.g., by using) an Internet protocol connection (e.g., Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS) protocol) for communicating with the media application server including a website server.

[0010] In some example embodiments, the source terminal initiates the multimedia connection with the target terminal based on (eg, by using) an Internet Protocol connection.

[0011] In some example embodiments, the source terminal indicates multimedia support in an additional data field of a SIP / SDP session establishment or modification message sent from the source terminal to the IMS.

[0012] In some example embodiments, the SIP / SDP session message is an INVITE message.

[0013] In some example embodiments, the source terminal receives the media application server information from the IMS in an additional data field of a SIP / SDP session response message.

[0014] In some example embodiments, the source terminal sends the media application server information to the target terminal via a SIP / SDP session establishment or modification message.

[0015] In some example embodiments, the source terminal receives the indication of multimedia support of the target terminal in an additional data field of a SIP / SDP session response message sent from the target terminal.

[0016] According to another exemplary embodiment, a method for establishing a multimedia connection (e.g., an augmented reality (AR) multimedia connection) in a mobile communication network is provided. The method includes a target terminal, an Internet Protocol Multimedia Subsystem (IMS), a media application server, and a source terminal. The target terminal receives media application server information from the IMS. Based on (e.g., by using) the received media application server information, the target terminal requests multimedia-related data (e.g., AR-related data) from the media application server. The target terminal receives the multimedia-related data from the media application server (e.g., via a secure connection). Based on (e.g., by using) the received multimedia-related data, the target terminal establishes the multimedia connection with the source terminal.

[0017] In some example embodiments, the target terminal receives the media application server information based on (eg, by using) the Session Initiation / Description Protocol (SIP / SDP).

[0018] In some example embodiments, the target terminal requests and receives multimedia-related data based on (e.g., by using) an Internet protocol connection (e.g., Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol (HTTPS) protocol) for communicating with the media application server including a Web server.

[0019] In some example embodiments, the target terminal establishes the multimedia connection with the source terminal based on (eg, by using) an Internet Protocol connection.

[0020] In some example embodiments, the target terminal confirms multimedia support in an additional data field of a SIP / SDP session response message sent from the target terminal to the IMS and / or source IMS and / or the source terminal.

[0021] In some example embodiments, the target terminal receives the media application server information from the IMS in an additional data field of a SIP / SDP session response message.

[0022] In some example embodiments, the target terminal receives the media application server information from the source terminal via a SIP / SDP session establishment or modification message.

[0023] In some example embodiments, the target terminal sends the indication of multimedia support of the target terminal in an additional data field of a SIP / SDP session response message to the source terminal.

[0024] According to yet another example embodiment, an Internet Protocol Multimedia Subsystem (IMS) for establishing a multimedia connection (e.g., an augmented reality (AR) multimedia connection) in a mobile communication network is provided. The connection is established between a source terminal, a media application server, and a target terminal. The IMS is arranged to receive a Session Initiation / Description Protocol (SIP / SDP) message indicating multimedia support (e.g., AR support) of the source terminal from the source terminal. The IMS is arranged to select the media application server and is arranged to send a SIP / SDP message including information about the media application server to the source terminal.

[0025] In some example embodiments, the IMS is arranged to send a SIP / SDP message including the information about the media application server to the target terminal and / or target IMS.

[0026] In some example embodiments, the IMS is arranged to select a target media application server and send a SIP / SDP message including the information about the target media application server to the target terminal and / or target IMS.

[0027] In some example embodiments, the SIP / SDP message received from the source terminal is a SIP / SDP session establishment or modification message, and the multimedia support is indicated in an additional data field of the SIP / SDP session establishment or modification message.

[0028] In some example embodiments, the IMS is further arranged to receive a Session Initiation / Description Protocol (SIP / SDP) message from the target terminal indicating AR support of the target terminal, and to send the SIP / SDP message to the source terminal.

[0029] According to another exemplary embodiment, a source terminal for establishing a multimedia connection (e.g., an augmented reality (AR) multimedia connection) in a mobile communication network is provided. The connection is established between the source terminal, an Internet Protocol Multimedia Subsystem (IMS), a media application server, and a target terminal. The source terminal is arranged to request (e.g., by indicating multimedia support) media application server information from the IMS, and is arranged to receive (e.g., via a secure connection) media application server information from the IMS. The source terminal is arranged to request multimedia-related data (e.g., AR-related data) from the media application server based on (e.g., by using) the received media application server information. The source terminal is arranged to receive the multimedia-related data from the media application server, and is arranged to initiate the multimedia connection with the target terminal based on (e.g., by using) the received multimedia-related data.

[0030] In some example embodiments, the source terminal is arranged to implement any of the source terminal methods described above.

[0031] According to another exemplary embodiment, a target terminal for establishing an augmented reality (AR) multimedia connection in a mobile communication network is provided. The connection is established between the target terminal, an Internet Protocol Multimedia Subsystem (IMS), a media application server and a source terminal. The target terminal is arranged to receive media application server information from the IMS, and request relevant data from the media application server based on (e.g., by using) the received media application server information. The target terminal is arranged to receive (e.g., via a secure connection) the multimedia related data from the media application server, and establish the multimedia connection with the source terminal based on (e.g., by using) the received multimedia related data.

[0032] In some example embodiments, the target terminal is arranged to implement any of the target terminal methods described above.

[0033] According to yet another exemplary embodiment, a program includes instructions, which, when executed by at least one processor, cause a terminal of a mobile communication network to perform any of the above-mentioned terminal-related methods.

[0034] According to yet another example embodiment, a program comprises instructions which, when executed by at least one processor, cause an IMS of a mobile communication network to perform any of the above-described IMS-related arrangements. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Example embodiments will be described in more detail below with reference to the accompanying drawings, in which:

[0036] Figure 1 An example embodiment of an AR telephony system is depicted.

[0037] Figure 2 An example embodiment of the architecture of a 5G STAR UE is shown.

[0038] Figure 3 An example embodiment of AR telephony communication establishment is shown.

[0039] Figure 4 An alternative example embodiment of an IMS call flow is shown, where the AR is rendered in the source terminal.

[0040] Figure 5 An alternative example embodiment of an IMS call flow is shown, where AR is rendered in both terminals.

[0041] Figure 6 An alternative example embodiment of an IMS call flow is depicted where AR is rendered within a media application server.

[0042] Figure 7 An example embodiment of a reference architecture supporting the use of data channels in IMS is shown.

[0043] Figure 8 An example embodiment of a user equipment (UE) initiated bootstrap data channel establishment signal flow diagram is depicted.

[0044] Fig. 9 An example embodiment of application data channel establishment between UEs is shown. DETAILED DESCRIPTION

[0045] 3GPP TR 26.928 defines the terms augmented reality (AR) and mixed reality (MR) as follows:

[0046] -Augmented Reality (AR) refers to the provision of additional information or artificially generated items or content to the user and superimposing it on their current environment. Such additional information or content is usually visual and / or auditory, and the user's observation of the current environment may be direct, without intermediate perception, processing and rendering, or it may be indirect, with the user's perception of the environment being relayed through sensors and possibly enhanced or processed.

[0047] -Mixed reality (MR) is an advanced form of AR where some virtual elements are inserted into the physical scene,

[0048] The intention is to provide the illusion that these units are part of a real scene.

[0049] The example embodiments described herein provide, for example, a method for establishing a multimedia connection from one terminal to another in a mobile communication network without using a data channel protocol stack, as described in TR 23.700, and therefore without requiring support in the terminal or the network. In addition, the example embodiments use SIP / SDP messages from the IP Multimedia Subsystem (IMS) to negotiate the necessary information between the terminal and the network, and then download metadata from an external source, such as an AR server in the Internet via HTTP. In this way, no DC support is required in the UE and the network, and it fits into the existing AR ecosystem in the industry. In addition, this proposed method can support the growth of AR IMS solutions.

[0050] Before explaining the examples in detail, refer to Figure 1 and Figure 2 Certain general principles of mobile communication systems and multimedia communication devices are briefly explained to help understand the technology underlying the examples.

[0051] Figure 1 A general system architecture for implementing an AR phone is depicted, including a so-called standalone AR (STAR) user equipment (UE), a 5G network, and an external media server. A STAR UE 100 is a conventional 5G UE that includes all UE capabilities in addition to AR capabilities. An AR / MR application 101 resides on the device, and all necessary AR / MR functions and entities (such as AR runtime 102, AR scene manager 103, and media access functions 104) are available for typical media processing use cases. Since such devices need to process large amounts of data, they may require higher power consumption compared to other types of devices (such as EDGe-dependent AR UEs or wireless tethered AR UEs).

[0052] The 5G connectivity of the STAR UE 100 is provided through an embedded 5G modem, which is connected to a base station (e.g., next generation NB (gNB)) 106 of a 5G system 107 through a dedicated Uu interface 105. The base station may be controlled or assisted by at least one appropriate controller device to be able to operate the base station and manage mobile communication devices communicating with the base station. An external media application provider 108 is providing services that can be supported by network-based AR functions and rendering.

[0053] As used herein, the term "base station" has the full scope of its usual meaning and includes at least a wireless communication station installed in a fixed location and used to communicate as part of a wireless telephone system or radio system. The communication area (or coverage area) of a base station may be referred to as a "cell". A base station and UE may be configured to communicate over a transmission medium using any of a variety of radio access technologies (RATs), also referred to as wireless communication technologies or telecommunication standards.

[0054] An example of a wireless communication system is an architecture standardized by the Third Generation Partnership Project (3GPP). The latest 3GPP-based development is generally referred to as the Long Term Evolution (LTE) of the Universal Mobile Telecommunications System (UMTS) radio access technology. The various development stages of the 3GPP specification are referred to as releases. The newer development of LTE is generally referred to as LTE Advanced (LTE-A). LTE (or LTE-A) adopts a radio mobile architecture called Evolved Universal Terrestrial Radio Access Network (E-UTRAN) and a core network called Evolved Packet Core (EPC). The base stations of such systems are called Evolved or Enhanced Node Bs (eNBs) and provide E-UTRAN features for communication devices, such as user plane packet data convergence / radio link control / media access control / physical layer protocols (PDCP / RLC / MAC / PHY) and control plane radio resource control (RRC) protocol termination. Other examples of radio access systems include those provided by base stations of systems based on technologies such as WLAN and / or Worldwide Interoperability for Microwave Access (WiMax). The base station can provide coverage for an entire cell or similar radio service area. The core network elements include a Mobility Management Entity (MME), a Serving Gateway (S-GW), and a Packet Gateway (P-GW).

[0055] An example of a suitable communication system is the 5G or NR concept. The network architecture in NR may be similar to that of LTE-A. The base stations of the NR system may be referred to as next generation Node Bs (gNBs). Changes in the network architecture may depend on the need to support various radio technologies and more refined quality of service (QoS) support, as well as some on-demand requirements for QoS levels to support quality of experience (QoE) from the user's perspective. In addition, network-aware services and applications, as well as service- and application-aware networks, may bring changes to the architecture. These are related to information-centric network (ICN) and user-centric content delivery network (UC-CDN) approaches. NR may use multiple-input multiple-output (MIMO) antennas, many more base stations or nodes than LTE (the so-called small cell concept), including macro sites operating in collaboration with smaller sites, and perhaps also adopt various radio technologies for better coverage and enhanced data rates.

[0056] The 5G system 107 also supports Internet / Intranet connectivity, granting a transmission path from the 5G UE to an external media application provider 108, while its own internal media application server provides services like SMS or IP voice. Low-latency services (such as AR phone communications) may require application servers to be placed physically close to the UE to minimize transmission delays. The Internet Protocol Multimedia Subsystem (IMS) (further detailed in TS23.228) is suitable for such communications and provides multimedia services by providing wireless and wired users with access to voice, video, messaging, data and Web-based technologies. Support for IP multimedia applications includes terminals, specific functional elements of the IM subsystem and an IP Connectivity Access Network (IP-CAN) (such as a General Packet Radio Service (GPRS) core network with a GSM Edge RAN (GERAN) and / or UTRAN radio access network, an EPC core network and an E-UTRAN radio access network or a 5G system access network).

[0057] IMS has many interfaces towards IP multimedia networks and tries to support Internet standards. In this disclosure, the interfaces between the IMS and UE side will be explained in further detail as they are the first access points. Starting with the Proxy Call Session Control Function (P-CSCF), it is the first point of contact within the IMS. As the name implies, the P-CSCF acts as a proxy, i.e., the UE can find its address, it accepts requests and provides services internally or forwards requests. The UE can send a Session Initiation Protocol (SIP) request, and the P-CSCF forwards this message to a SIP server (e.g., a serving CSCF) or responds directly to the UE. The P-CSCF also ensures that the relevant SIP messages contain correct or up-to-date information about the user's location information, and / or the UE time zone provided by the access network currently used by the UE.

[0058] The interrogating CSCF (I-CSCF) is the contact point for all connections within the operator's network destined for the network operator's users. One of the functions performed by the I-CSCF is to assign an S-CSCF to the user performing the SIP registration and forward or respond to the S-CSCF.

[0059] The Serving CSCF (S-CSCF) performs session control services for the UE. It maintains session state to support services as required by the network operator. The functions of the S-CSCF include accepting registration requests and making their information available through the location server, notifying the user about registration changes, handling interactions with the service platform to support services or, in particular, ensuring for the source user / UE that the source endpoint is subscribed to the determined IMS communication service and ensuring that the content of the SIP request or response sent or received by the source endpoint matches the IMS communication service definition determined based on the subscription of the source UE.

[0060] The terminal mentioned in this disclosure may be a UE with AR capabilities or a device capable of communicating over a telecommunication network using an AR context. In this disclosure, we exemplarily mention a 5G STAR UE, such as Figure 2 As shown, it is able to execute AR applications without necessarily requiring external computing or rendering help.

[0061] As above Figure 1 As shown, STAR UE has three entities supporting AR applications 101, namely AR runtime 102, AR scene manager 103 and media access function 104. The components of each entity are now explained in more detail.

[0062] The AR runtime 102 implements a set of APIs 203 to provide access to the underlying AR / MR hardware and uses input from sensors 200, audio input from cameras 201, and / or video input to access or share this information to a network with the help of three internal components. The XR spatial computing 206 entity provides AR capabilities to process sensor data to generate information about the world's 3D space around the AR user, such as SLAM for spatial mapping and positioning, 3D reconstruction, and semantic perception. The posture correction 207 entity provides posture correction functionality that helps stabilize AR media as the user moves. Sound field mapping 208 is used to provide functionality to visualize sound levels on structures and locate unwanted sound sources.

[0063] The AR scene manager 103 is a software component that processes scene descriptions and provides immersive rendering capabilities. The scene graph processor 209 provides functionality to support scene graph management, which represents an object-based hierarchy of the scene's geometry and allows interaction with the scene. The compositor 210 is used to synthesize image layers at different depth levels for representation. The immersive audio / visual renderers 211, 212 use the GPU to render media and can include 2D or 3D visual / audio rendering, as well as posture correction capabilities.

[0064] The media access function 104 supports AR UE access and streaming media. The media access function 104 is divided into two components, namely the media client 213 and the media session processor 214, the latter of which provides support for the delivery of media content components through the 5G system, especially the cloud and split rendering support functions. The media session processor 214 is a common function on the device, which is used to set up the 5G system functions, while the media client 213 has more entities (such as 2D codec 215) to compress and decompress media. The three delivery entity functions scene description delivery 216, XR spatial description delivery 218 and content delivery 219 are used to deliver media content between the UE and the network through the Uu interface 105 according to the requirements of the application. This includes timing, synchronization, reliability, reporting and other features.

[0065] Now, since the general functions of the AR UE are explained, reference will be made to Figure 3 The AR telephone communication method is described in detail from the perspective of the source terminal.

[0066] The multimedia connection for AR telephone communication is established using Figure 1 The architecture includes IMS ( Figure 1 ), where data for AR applications is provided. In order to establish a multimedia connection, that is, to run AR / MR applications on the source 300 and the target terminal 303 and share the same AR / MR application, at 304, the source terminal 300 requests the IMS 301 for media application server information, such as a server address, and similarly, the target terminal 303 receives the media application server information from the IMS. The media application server / AR server 302 is used to provide AR application information to the target terminal 303 to which a connection should be established, and acts as an external server accessible to both terminals. If there is no active connection between them, the IMS 301 selects a suitable media application server 302 and assigns the source terminal 300 to the media application server 302. Otherwise, that is, if there is already a connection between the source terminal 300 and the media application server 302, the IMS provides the source terminal 300 with the necessary information during IMS call establishment or modification. In response, at 305, the source terminal 300 receives the media application server information from the IMS 301.

[0067] Now, the source terminal 300 is assigned to the media application server 302, and based on (e.g., by using) the media application server information received from the IMS 301, the source terminal 300 requests AR-related data, such as AR object data and / or metadata using an AR object identifier, from the media application server 302 at 306. Likewise, the target terminal 304 requests AR-related data based on (e.g., by using) the received media application server information. The media application server responds at 307 by sending the requested AR-related data to the source terminal and the target terminal 303 (not shown) that are receiving AR-related data from the media application server.

[0068] The IMS also provides all necessary information of the target terminal 303, and the IMS provides the same information to the media application server 302 and the source terminal 300 so that a connection with the target terminal 304 can be established. Therefore, at 308, based on (e.g., by using) the received AR-related data, the source terminal 300 initiates an AR multimedia connection with the target terminal 303, and similarly, the target terminal 303 establishes an AR multimedia connection with the source terminal 300. The AR-related data includes at least one of the following: an AR object, AR-related metadata, and an AR application.

[0069] Information (eg, audio, video, text, and AR data) between the two terminals 300 , 303 is exchanged via the Real-time Transport Protocol (RTP).

[0070] In another example embodiment, AR rendering is completed in the source terminal, and then the source terminal provides AR / MR information to the media application server and / or the target terminal via RTP. Figure 4 An exemplary IMS call flow is shown in FIG, where AR is rendered in the source terminal. Therefore, more attention is paid to the interaction of the IMS interface and the message information sent to the entities of the IMS call flow. Note that each terminal or UE may have its own dedicated IMS application server for its own AR application.

[0071] The source terminal / UE 300 with AR capabilities wants to initiate an AR telephony communication with the target terminal / UE 303. Therefore, it initiates an INVITE session at 404, or, if there is already a connection that should be changed, a Re-INVITE directed to the source P / I / S-CSCF interface 400 of the source IMS application server 401 indicated with a new attribute a=arimsservice-app1 in the Session Initiation Protocol (SIP). The source UE 300 indicates AR support in the additional data field of the SIP / SDP session establishment or modification message sent from the source terminal to the IMS AS 401 to create the AR IMS session.

[0072] The SIP / SDP session message is an INVITE or RE-INVITE message, which is received by the source P / I / S-CSCF interface 400 at 405 and then forwarded to the appropriate IMS AS 401 .

[0073] At 406, AR support is indicated to the source IMS AS 401 in the INVITE / Re-INVITE message, and then the source IMS AS 401 responds to the INVITE with a 18xSDP response code (e.g., 180 Ringing or 181 Call Forwarding), which also has a new path attribute as an HTTP URL to provide the media application server 302 address to the source P / I / S-CSCF interface 400. An example new SDP path attribute may be as follows a=path: https: / / example.com / ar01234567890; tcp. It should be noted that the source terminal and / or the target terminal requesting the media application server information from the IMS and receiving the media application server information from the IMS are performed based on (e.g., by using) the Session Initiation / Description Protocol (SIP / SDP) of the mobile communication network.

[0074] Next, at 407, the source P / I / S-CSCF interface 400 forwards the media application server information received from the IMS in the additional data field of the SIP / SDP session response message sent from the IMS to the source terminal. The received 18x response code with SDP is forwarded to the source UE 300. The source UE 300 identifies the media application server 302 based on the 18x response code with the SDP path attribute.

[0075] On the other hand, the source IMS AS 401 forwards the initial INVITE message originating from the source UE 300 to the target P / I / S-CSCF interface 402 at 408, where two new AR SDP attributes are shown as samples as follows: a=arimsservice-app1 and a=path:https: / / example.com / ar01234567890;tcp.

[0076] Then at 409 , the target P / I / S-CSCF interface 402 forwards this INVITE with two new AR SDP attributes (AR support indication of the source UE 300 and the media application server address) to the target IMS AS 403 .

[0077] Based on the HTTP URL in the SDP path attribute received at 408, the source UE 300 sends an HTTP request across 410 to the media application server 302 for AR metadata exchange for HTTP connection establishment. As part of the initial request, AR object data (which includes, for example, video, image, point cloud, and / or 2D / 3D media representation) and / or AR related metadata (which includes AR object properties such as depth and / or object position) are requested using object identification or other naming conventions. Note that the media application server 302 address can be pre-configured in the UE, which is an alternative to static AR configuration. Static AR configuration is a limited solution because manual user intervention is required to select the media application server.

[0078] Therefore, at 411, the media application server 302 responds with a 200OK HTTP response with AR metadata (2D / 3D model data), and the IMS client on the source UE 300 provides the AR metadata to the AR runtime engine in the source UE 300 for further processing (not shown).

[0079] Next, another INVITE is sent back from the target IMS AS 403 to the target P / I / S-CSCF interface 402 to send the corresponding AR support information of the target UE 303 and request the media application server 302 details in the SDP at 412 .

[0080] Then, 413, the target P / I / S-CSCF interface 402 forwards the INVITE to the terminating UE 303 with the AR SDP details of the source UE 300 and the media application server information including the terminal AR capabilities and / or the network AR capabilities. Alternatively, when the connection between the source UE 300 and the target UE 303 is ensured, a Re-INVITE including the media application server information is sent from the source terminal to the target terminal via a SIP / SDP session establishment or modification message.

[0081] At 414, the response from the target UE 303 is sent back to the target P / I / S-CSCF 402 as a 200 OK SDP with the target terminal AR support specification.

[0082] Then, at 415 , the target UE sends an HTTP request to the media AS and receives initial AR metadata as a response to the request. Requesting and receiving AR-related data is performed based on (eg, by using) an Internet protocol connection at the target UE 303 .

[0083] At 416, a 200 OK SDP response code is sent back from the target P / I / S-CSCF interface 402 towards the target IMS AS 403 as a result of the INVITE message of activity 412 as a reverse path for the response.

[0084] Next, at 417 , a 200 OK SDP response code is sent back from the target IMS AS 402 to the target P / I / S-CSCF interface 402 as a result of the INVITE message of activity 409 .

[0085] This is followed 418 by a 200 OK response sent back from the target P / I / S-CSCF 402 towards the source IMS AS 401 , which is a result of the INVITE message of activity 408 .

[0086] The 200 OK response code chain continues in the next activities 419 and 420. First, the source IMS AS 401 responds to the source P / I / S-CSCF 400, and then the source P / I / S-CSCF 400 responds to the source UE 300. Therefore, finally, the source UE 300 receives an indication of AR support of the target terminal in the additional data field of the SIP / SDP session response message sent by the target terminal.

[0087] Finally, at 421, the source UE 300 and the target UE 303 have the same media application server information. Therefore, an AR media exchange is initiated between the source UE 300 and the media application server 302. The source UE initiates an AR multimedia connection with the target terminal based on (e.g., by using) an Internet Protocol connection. Similarly, the target terminal establishes an AR multimedia connection with the source terminal based on (e.g., by using) an Internet Protocol connection. The source UE 300 is exchanging AR media information with the media application server 302. At 422, the rendered AR audio / video from the source UE 300 is exchanged between the source UE 300 and the target UE 303 via RTP. With this approach, direct UE-to-UE AR capability exchange is not required because all AR information is exchanged by the media application server 302.

[0088] Similar to the previous example embodiment, Figure 5 An example embodiment is shown in which AR is rendered in both UEs, which means that both UEs are running AR / MR applications when attempting to establish a connection. The connection establishment is still initiated by the source UE 300.

[0089] The first phase of the AR telephony communication establishment is the same, including activities 404 and 405. The AR-capable UE initiates an INVITE / Re-INVITE session using the AR indication in the SDP.

[0090] Now, at 500, the source IMS AS 402 sends an HTTP notification message to the media application server 302 to create a new AR session ID in order to support the media application server 302's authorization of the source UE 300 and the target UE 303. In addition, the source UE ID is exchanged in the notification message to associate the IMS session with the media application server. Note that compared to before, the media application server 302 does not need AR object data because the AR application is running on both UEs, and therefore only needs to provide metadata to be exchanged between the UEs.

[0091] Then, in activities 406 and 407, the source IMS AS 401 sends an 18xSDP response code to the source P / I / S-CSCF 400, and the source P / I / S-CSCF 400 forwards the response to the source UE 300, which includes the media application server information, which includes the media application server address or uniform resource identifier (URI) and / or a link to AR related data.

[0092] Next, at 408 and 409 , the source IMS AS 401 sends an INVITE / Re-INVITE to the target P / I / S-CSCF 402 , which forwards the INVITE / Re-INVITE to the target IMS AS 403 .

[0093] Since the target UE 303 is also running an AR application, the target IMS AS 403 now has to inform the media application server 302 via HTTP at 501 (as in activity 500) that both UEs are authorized to access the media application server by providing the session ID and the target UE ID.

[0094] The next flow chart calls 410 to 420 are exactly the same as described above, so after the source UE 300 receives the forwarded 200OK SDP response code, the AR media exchange can proceed. This time at 421, the media exchange is performed between the media application server 302 and the source UE 300 / target UE 303, for example, the target UE 303 selects the preferred AR metadata in the source UE 300.

[0095] Finally, at 422, AR telephony communication is established, where the two UEs exchange their rendered videos, including mixed augmented reality information, via RTP.

[0096] Figure 6Another example embodiment shown in shows an IMS call flow for establishing an AR connection and performing AR rendering in the network. Instead, the Multimedia Resource Function (MRF) now takes over the role of mixing and processing the incoming media streams provided by the two UEs. For more details on the MRF, document TS23.228 subsection 4.7 provides more details. In this example embodiment, neither UE 300, 303 has to render the mixed video, thereby saving resources.

[0097] Similar to the previous example embodiment, this example embodiment has the same initiation process, so 404 and 405 are the same as before. Then, the first difference occurs at 601, where the source IMS AS 401 notifies the media application server 302 of the new AR session ID via HTTP and uses the corresponding media application server ID to identify this new session. Please note that the media application server ID can be pre-configured in the source IMS AS 401.

[0098] The IMS call flow activities 406 to 409 are the same as in the previous example embodiment described further above.

[0099] Then, at 603, the target IMS AS 403 notifies the media application server 302 of the new AR session ID via HTTP. In response, the media application server ID is assigned to this AR session ID.

[0100] The following stages, from 412 to 420, are the same as the previous example embodiment described further above.

[0101] Now, at 605 and 606, both UEs 300, 303 are aware of each other's AR support capabilities, and in order to start the connection, both UEs are exchanging AR control information with the media application server to control the AR rendering process on the media application server and select the preferred enhancement and control the rendering process.

[0102] The MRF processes, renders, and mixes the AR objects and video in 607 to provide all information back to the UE from the media application server 302 .

[0103] Finally, at 608 , both UEs 300 , 303 may download the mixed video from the media application server 302 .

[0104] In some example embodiments, example 3GPP contributions related to various updates to Solution #7 - Reference architecture supporting data channel usage in TR 23.700-87 are disclosed as follows:

[0105] proposal

[0106] The following changes are proposed for Solution #7 in TR 23.700-87.

[0107] ***The beginning of change***

[0108] 6.7 Solution #7: Reference Architecture to Support the Use of Data Channels in IMS

[0109] 6.7.1 Description

[0110] In section 6.2.10 of TS26.114 [6], a data channel workflow is defined, including a data channel server and a data channel application repository. However, this workflow does not define the interface between functions, nor does it show or define the interface between the data channel server and existing IMS functions.

[0111] This solution defines architectural enhancements to IMS to support data channel functionality by reusing the data channel workflow described above. Data channel functionality can be used to enable, for example, screen sharing, file transfer, and co-editing during and in the context of an IMS call. The overall reference architecture supporting the use of data channels in IMS is as follows: Figure 7 shown.

[0112] The Data Channel Server (DC Server) and Data Channel Application Repository are defined in TS 26.114 [6], and Figure 6 All other functions in .7.1-1 are defined in TS23.228 [5]. The DC server is divided into control functions and media functions called data channel (DC) control functions and data channel (DC) media functions (referred to as DCS-C and DCS-M respectively).

[0113] Note: The DC Control function can run independently or be co-located with other functions (such as MMTel AS). The DC Media function can run independently (i.e. only handle DC Media) or be co-located with other functions (such as MRF).

[0114] UE A and UE B contain a DCMTSI client, which is a MTSI client with data channel functionality that supports data channel media, as defined in TS26.114 [6]. The DCMTSI client uses SIP / SDP to indicate support for "webrtc-datachannel" and establishes a "bootstrap" data channel to the data channel server. During an IMS call, the "bootstrap" data channel is used to send applications (JavaScript files) from the data channel server to the UE. The DC server obtains the application from the data channel application repository via the DC2 interface, which is beyond the scope of 3GPP. The DCMTSI client in the initiating UE uses SIP / SDP to establish data channel media, either to the DC media function or directly to the terminating UE via the IMS domain. This data channel transmits media content between the two UEs via the DC media function or directly.

[0115] After negotiating the guided data channel with the DCS-C, the UE can establish a guided data channel connection with the DCS-M. The UE can then initiate an HTTP GET request on the root (" / ") URL over the guided data channel. The DCS-M sends the application list to the UE in an HTTP response.

[0116] The DC control function interacts with the IMS MMTel AS through the DC1 interface. DC1 is used for data channel call control (establishing boot and application data channels to UE A and UE B) and call event notification. The call event trigger from the MMTel AS to the DC control function contains the calling (calling) identity and called (called) identity, UE functions and SDP related information. The notification sent from the DC control function to the MMTel AS through the DC1 interface contains, for example, the address / port information of the DC media function for the UE to send and receive data channel media, as well as optional QoS data related to the media channel. DC1 is based on the HTTP Restful API protocol and follows the SBI principle.

[0117] After establishing the DC application data channel, the UE can send / receive DC data to / from another UE directly through the application data channel or through DCS-M. DCS-M can use HTTP / S to provide DC data (for example, AR model data if it is an AR application) to the UE.

[0118] IMS MMTel AS discovers and selects the DC control function, or

[0119] - Using the SBI principle: the DC Control Function registers its capabilities (e.g. supporting data channel capabilities) with the NRF, and the MMTel AS discovers and selects the DC Control Function through the NRF; or

[0120] - Through static configuration: The MMTel AS is configured with the DC control function FQDN or IP address.

[0121] The DC control function discovers and selects the DC media function, or

[0122] - using the SBI principle: the DC media function registers its capabilities (e.g. supporting data channel capabilities) with the NRF, and the DC control function discovers and selects the DC media function through the NRF; or

[0123] - Through static configuration: The DC control function configures the DC media function FQDN or IP address.

[0124] The impact on the IMS interfaces Gm, Mw, ISC, Iq is determined during the normative phase.

[0125] 6.7.2 Process

[0126] 6.7.2.1UE-initiated bootstrap data channel establishment

[0127] At once Figure 8 For example, the process of establishing a guided data channel initiated by the UE is as follows:

[0128] 1. UE A sends a SIP INVITE request with an initial SDP to the MMTel AS through the initiating network IMS core. The initial SDP contains audio / video and bootstrap data channel establishment requirements.

[0129] 2. After receiving the SIP INVITE request, the MMTel AS verifies the data channel media description information and user subscription data to determine whether to send the DC call event notification to the DCS-C.

[0130] If a DC call event notification needs to be sent to the DCS-C, the MMTel AS selects a DCS-C for this session based on local configuration or service discovery, and selects a DCS-C instance through the NRF. The DC call event notification includes the calling / called party identifier and the boot data channel information.

[0131] 3-5. After receiving the DC call event notification, the DCS-C determines the policy on how to handle the bootstrap data channel establishment request based on the relevant parameters in the DC call event notification, service subscription and / or operator policy. When the bootstrap data channel is allowed, the DCS-C sends a DC media resource reservation request to the DCS-M. The DCS-M allocates media resources for bootstrapping and sends them to the DCS-C. The DCS-C sends a DC control request with reserved media resources to the MMTel AS.

[0132] 6. The MMTel AS sends the INVITE including the modified SDP offer to the initiating IMS core and then to the remote network side. The SDP offer includes the bootstrap data channel establishment information from the DCS-M.

[0133] 7. UE B returns a 183 response with an SDP answer. The SDP answer includes the bootstrapped data channel from UE B.

[0134] 8. The terminating network IMS core performs QoS procedures for directing data channel media according to the SDP answer information from the 183 response.

[0135] 9-10. The terminating network IMS core returns a 183 response to the originating network IMS core and MMTel AS.

[0136] 11. After receiving the 183 response, the MMTel AS verifies the data channel media description information and sends the DC call event notification (such as calling party and called party information) and the guided data channel establishment information to the DCS-C.

[0137] 12-14. After receiving the DC call event notification, DCS-C sends a DC media resource update and reservation request to DCS-M. Then DCS-M updates the bootstrap data channel establishment information. DCS-M media allocates the media resources for bootstrapping to UE A and sends it to DCS-C. DCS-C sends a DC control request with reserved media resources to MMTel AS.

[0138] 15. The MMTel AS sends the 183 response including the modified SDP answer to the originating IMS core and then to UE A. The SDP answer includes the bootstrap data channel establishment information from the DCS-M. The originating network IMS core performs the QoS process for bootstrapping the data channel media according to the SDP answer information in the 183 response.

[0139] 16. PRACK (Provisional Response Acknowledgement) and UPDATE (Update) negotiation between the initiating network and the terminating network.

[0140] 17-22.UE A and UE B initiate the establishment of a guided data channel according to SDP negotiation. The guided data channel is established between the initiating DCS-M and UE A and UE B. The UE sends an application request message to the DCS-M via the guided data channel to retrieve the application list. The DCS-M retrieves the appropriate application list from the data channel application repository and includes it in the response to UE A and UE B.

[0141] 23. The subsequent process continues.

[0142] 6.7.2.2 Establishment of application data channel between UEs

[0143] At once Fig. 9 For example, the process of establishing an application data channel between UEs is as follows:

[0144] 1. UE A sends a SIP re-INVITE request with an initial SDP to the MMTel AS through the initiating network IMS core. The initial SDP contains the audio / video and application data channel establishment requirements.

[0145] 2. After receiving the SIP re-INVITE request, the MMTel AS verifies the data channel media description information and user subscription data to determine whether to send a DC call event notification to the DCS-C.

[0146] If a DC call event notification needs to be sent to the DCS-C, the MMTel AS selects a DCS-C for the session based on local configuration or service discovery, and selects a DCS-C instance through the NRF. The DC call event notification includes the calling / called party identifiers and application data channel information.

[0147] 3. After receiving the DC call event notification, the DCS-C determines the policy on how to handle the application data channel establishment request based on the relevant parameters in the DC call event notification, service subscription and / or operator policy. For the P2P application data channel, it does not require DC media resources. The DCS-C sends a DC control request without reserving media resources to the MMTel AS.

[0148] 4. The MMTel AS sends the INVITE including the original SDP offer to the originating IMS core and then to the remote network side.

[0149] 5. UE B returns a 200 OK response with an SDP answer. The SDP answer includes the application data channel from UE B.

[0150] 6-7. The terminating network IMS core performs a QoS process for the application data channel media according to the SDP answer information in the 200 OK response. The terminating network IMS core returns a 200 OK response message to the originating network IMS core and MMTelAS.

[0151] 8. After receiving the 200OK response, the MMTel AS verifies the data channel media description information and sends a DC call event notification with application data channel establishment information to the DCS-C.

[0152] 9-10. After receiving the DC call event notification, the DCS-C determines that it is for a P2P application data channel, which does not require DC media resources. The DCS-C sends a DC control request without reserved media resources to the MMTel AS.

[0153] 11. The MMTel AS sends a 200OK response including an SDP answer to the originating network IMS core, and then to UE A. The SDP answer includes the application data channel establishment information from UE B. The originating network IMS core performs QoS procedures for the application data channel media according to the SDP answer information from the 200OK response.

[0154] 12. ACK for 200OK process.

[0155] 13-14. UE A and UE B initiate the establishment of an application data channel according to SDP negotiation. UE A and UE B exchange application data through the application data channel.

[0156] 6.7.3 Impact on existing nodes and functions

[0157] The following nodes are affected by this solution.

[0158] HSS:

[0159] - Impact on HSS (e.g. data channel specific subscription information) is FFS (further study).

[0160] Data channel control (DCS-C) function:

[0161] -Interacts with IMS MMTel AS through DC1 interface. DC1 is used for data channel call control and call event notification and is based on HTTP Restful API. The control function interacts with DC media function through DC3 to reserve and maintain media resources.

[0162] - The DC Control Function discovers and selects the DC Media Function using the SBI principle (ie through the NRF) or through static configuration (eg by using a configured FQDN or IP address).

[0163] Data Channel Media (DCS-M) Function:

[0164] -Maintain DC media resources and interact with DC control functions through DC3. DC3 can be based on HTTP / S.

[0165] DataChannel Application Repository:

[0166] - It stores the data channel application. This functionality is outside the scope of 3GPP.

[0167] CSCF:

[0168] -The impact on P-CSCF, I-CSCF, and S-CSCF is FFS.

[0169] MMTel AS:

[0170] - Need to interact with DC control function through DC1 interface to send call event triggers and receive notifications converted to SIP / SDP.

[0171] - The MMTel AS discovers and selects the DC control function using the SBI principle (ie via NRF) or via static configuration (eg by using a configured FQDN or IP address).

[0172] IMS-AGW:

[0173] - Need to support DC data transmission.

[0174] UE:

[0175] -Support the use of data channels in IMS.

[0176] ***END OF CHANGES***

[0177] It is worth noting that although the example embodiments have been described for LTE and 5G NR, similar principles can be applied to other networks and communication systems that require forced fast connection reestablishment. Therefore, although certain example embodiments are described above by way of example with reference to certain example architectures of wireless networks, technologies and standards, the example embodiments can be applied to any other suitable form of communication system other than the communication system shown and described herein.

[0178] It is also noted herein that while the above describes example embodiments, there are numerous variations and modifications which could be made to the disclosed solution without departing from the scope of the subject disclosure.

[0179] In general, various example embodiments may be implemented in hardware or dedicated circuits, software, logic, or any combination thereof. Some example embodiments of the subject disclosure may be implemented in hardware, while other aspects may be implemented in firmware or software, which may be executed by a controller, microprocessor, or other computing device, but the subject disclosure is not limited thereto. Although various example embodiments of the subject disclosure may be illustrated and described with block diagrams, flow charts, or other graphical representations, it is fully understood that the blocks, devices, systems, techniques, or methods described herein may be implemented in hardware, software, firmware, dedicated circuits or logic, general hardware or controllers or other computing devices, or some combination thereof as non-limiting examples.

[0180] The various example embodiments disclosed in the subject matter may be implemented by computer software executable by a data processor of a mobile device (e.g., in a processor entity), or by hardware, or by a combination of software and hardware. Computer software or programs (also referred to as program products) including software routines, applets, and / or macros may be stored in any device-readable data storage medium, and they include program instructions for performing specific tasks. A program product may include one or more computer executable components that are configured to perform an embodiment when the program is operated. The one or more computer executable components may be at least one software code or a portion thereof.

[0181] Furthermore, in this regard, it should be noted that any block of the logic flow as in the figure may represent program steps, or interconnected logic circuits, blocks and functions, or a combination of program steps and logic circuits, blocks and functions. The software may be stored on physical media such as memory chips or memory blocks implemented within a processor, magnetic media such as hard disks or floppy disks, and optical media such as, for example, DVDs and their data variants, CDs. Physical media are non-transitory media.

[0182] The memory may be of any type suitable for the local technical environment and may be implemented using any suitable data storage technology (e.g., semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory, and removable memory). The data processor may be of any type suitable for the local technical environment and may include one or more of a general-purpose computer, a special-purpose computer, a microprocessor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an FPGA, a gate-level circuit, and a processor based on a multi-core processor architecture, as non-limiting examples.

[0183] Embodiments of the subject disclosure may be practiced in various components such as integrated circuit modules. The design of integrated circuits is generally a highly automated process. Complex and powerful software tools are available to convert a logic level design into a semiconductor circuit design ready to be etched and formed on a semiconductor substrate.

[0184] The foregoing description has provided by way of non-limiting examples a complete and informative description of example embodiments of the present disclosure. However, various modifications and adaptations may become apparent to those skilled in the relevant art in view of the foregoing description when read in conjunction with the accompanying drawings and the appended claims. However, all such and similar modifications to the teachings of the present disclosure will still fall within the scope of the subject disclosure. In fact, there is another example embodiment including a combination of one or more example embodiments with any other example embodiment previously discussed.

Claims

1. A method for establishing a multimedia connection between a source terminal, an Internet Protocol Multimedia Subsystem (IMS), a media application server and a target terminal in a mobile communication network, the method comprising: At the source terminal, Requesting media application server information from the IMS; Receiving media application server information from the IMS; Based on the received media application server information, request multimedia related data from the media application server; receiving the multimedia-related data from the media application server; Based on the received multimedia-related data, the AR multimedia connection with the target terminal is initiated.

2. The method according to claim 1, wherein: The multimedia connection is an augmented reality (AR) multimedia connection, and wherein the multimedia related data is AR related data.

3. The method according to claim 1 or 2, wherein: The media application server information includes a media application server address or a uniform resource identifier (URI), and / or a link to the multimedia related data.

4. The method according to any one of claims 2 to 3, wherein: The media application server information also includes terminal AR capabilities and / or network AR capabilities.

5. The method according to any one of claims 2 to 4, wherein: The AR-related data includes at least one of the following: AR objects, AR-related metadata, and AR applications.

6. The method according to claim 5, wherein: The AR object includes a video, an image, a point cloud, and / or a 2D / 3D media representation, and the AR-related metadata includes AR object characteristics such as depth and / or object position.

7. A method according to any one of the preceding claims, wherein: Requesting media application server information to and receiving media application server information from the IMS of the mobile communication network are performed based on Session Initiation Protocol / Session Description Protocol SIP / SDP.

8. A method according to any one of the preceding claims, wherein: Requesting and receiving multimedia related data is performed based on a hypertext transfer protocol HTTP or a hypertext transfer protocol secure HTTPS protocol for communicating with the media application server including a website server.

9. A method according to any one of the preceding claims, wherein: Initiating the multimedia connection with the target terminal is performed based on an Internet Protocol connection.

10. The method according to any one of the preceding claims, further comprising: Multimedia support is indicated in an additional data field of a SIP / SDP session establishment or modification message sent from the source terminal to the IMS.

11. The method according to claim 10, wherein: The SIP / SDP session message is an INVITE message.

12. A method according to any one of the preceding claims, wherein: The media application server information is received from the IMS in an additional data field of a SIP / SDP session response message sent from the IMS to the source terminal.

13. The method according to any one of the preceding claims, further comprising: The media application server information is sent from the source terminal to the target terminal via a SIP / SDP session establishment or modification message.

14. The method according to any one of the preceding claims, further comprising: At the source terminal, an indication of multimedia support of the target terminal is received in an additional data field of a SIP / SDP session response message sent from the target terminal.

15. A method for establishing a multimedia connection between a target terminal, an Internet Protocol Multimedia Subsystem (IMS), a media application server and a source terminal in a mobile communication network, the method comprising: At the target terminal, Receiving media application server information from the IMS; Based on the received media application server information, request multimedia related data from the media application server; receiving the multimedia related data from the media application server; Based on the received multimedia related data, the multimedia connection is established with the source terminal.

16. The method according to claim 15, wherein: The multimedia connection is an augmented reality (AR) multimedia connection, and wherein the multimedia related data is AR related data.

17. The method according to claim 15 or 16, wherein: The receiving of the media application server information is performed based on a Session Initiation Protocol / Session Description Protocol SIP / SDP.

18. The method according to any one of claims 15 to 17, wherein: Requesting and receiving multimedia related data is performed based on a hypertext transfer protocol HTTP or a hypertext transfer protocol secure HTTPS protocol for communicating with the media application server including a website server.

19. The method according to any one of claims 15 to 18, wherein: Establishing the multimedia connection with the source terminal is performed based on an Internet Protocol connection.

20. The method according to any one of claims 15 to 19, further comprising: Multimedia support is confirmed in an additional data field of a SIP / SDP session response message sent from the target terminal to the IMS, and / or the source IMS, and / or the source terminal.

21. The method according to any one of claims 15 to 20, wherein: The media application server information is received from the IMS in an additional data field of a SIP / SDP session response message sent from the IMS to the target terminal.

22. The method according to any one of claims 15 to 21, further comprising: The media application server information is received from the source terminal via a SIP / SDP session establishment or modification message.

23. The method according to any one of claims 15 to 22, further comprising: At the target terminal, an indication of multimedia support of the target terminal is sent in an additional data field of a SIP / SDP session response message to the source terminal.

24. An Internet Protocol Multimedia Subsystem (IMS) for establishing a multimedia connection between a source terminal, a media application server and a target terminal in a mobile communication network, the IMS being arranged to: receiving a Session Initiation Protocol / Session Description Protocol (SIP / SDP) message from the source terminal indicating multimedia support of the source terminal; Selecting the media application server; A SIP / SDP message including information about the media application server is sent to the source terminal.

25. The IMS of claim 24, wherein: The multimedia connection is an augmented reality (AR) multimedia connection, and wherein the message indicating multimedia support of the source terminal is a message indicating AR support of the source terminal.

26. The IMS according to claim 24 or 25, wherein: The IMS is further arranged to send a SIP / SDP message including the information about the media application server to the target terminal and / or target IMS.

27. An IMS according to any one of claims 24 to 26, wherein: The IMS is further arranged to select a target media application server and send a SIP / SDP message including information about the target media application server to the target terminal and / or target IMS.

28. An IMS according to any one of claims 24 to 27, wherein: The SIP / SDP message received from the source terminal is a SIP / SDP session establishment or modification message, and the multimedia support is indicated in an additional data field of the SIP / SDP session establishment or modification message.

29. An IMS according to any one of claims 24 to 28, wherein: The IMS is further arranged to receive a Session Initiation / Description Protocol (SIP / SDP) message from the target terminal indicating multimedia support of the target terminal, and to send the SIP / SDP message to the source terminal.

30. A source terminal, for establishing a multimedia connection between the source terminal, an Internet Protocol Multimedia Subsystem IMS, a media application server and a target terminal in a mobile communication network, the source terminal being arranged as follows: Requesting media application server information from the IMS; Receiving media application server information from the IMS; Based on the received media application server information, request multimedia related data from the media application server; receiving the multimedia related data from the media application server; Based on the received multimedia-related data, the multimedia connection with the target terminal is initiated.

31. A source terminal according to claim 30, further arranged to implement a method according to any one of claims 2 to 14.

32. A target terminal, for establishing a multimedia connection between the target terminal, an Internet Protocol Multimedia Subsystem IMS, a media application server and a source terminal in a mobile communication network, the target terminal being arranged as follows: Receiving media application server information from the IMS; Based on the received media application server information, requesting relevant data from the media application server; receiving the multimedia related data from the media application server; Based on the received multimedia related data, the multimedia connection is established with the source terminal.

33. A target terminal according to claim 32, further arranged to implement a method according to any one of claims 15 to 23.

34. A program comprising instructions which, when executed by at least one processor, cause a terminal of a mobile communication network to perform a method according to any one of claims 1 to 23.

35. A program comprising instructions which, when executed by at least one processor, cause an IMS of a mobile communication network to perform the steps of any one of claims 24 to 29.

Images