[go: up one dir, main page]

WO2009062903A1 - Procédé, appareil et produit de programme d'ordinateur pour remplacement de flux de données partiel dans un protocole d'ouverture de session - Google Patents

Procédé, appareil et produit de programme d'ordinateur pour remplacement de flux de données partiel dans un protocole d'ouverture de session Download PDF

Info

Publication number
WO2009062903A1
WO2009062903A1 PCT/EP2008/065209 EP2008065209W WO2009062903A1 WO 2009062903 A1 WO2009062903 A1 WO 2009062903A1 EP 2008065209 W EP2008065209 W EP 2008065209W WO 2009062903 A1 WO2009062903 A1 WO 2009062903A1
Authority
WO
WIPO (PCT)
Prior art keywords
communications device
media component
message
target
invite message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2008/065209
Other languages
English (en)
Inventor
Jari Mutikainen
Miikka POIKSELKÄ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Solutions and Networks Oy
Original Assignee
Nokia Siemens Networks Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Siemens Networks Oy filed Critical Nokia Siemens Networks Oy
Publication of WO2009062903A1 publication Critical patent/WO2009062903A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1083—In-session procedures
    • H04L65/1089—In-session procedures by adding media; by removing media
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1083—In-session procedures
    • H04L65/1094—Inter-user-equipment sessions transfer or sharing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/756—Media network packet handling adapting media to device capabilities

Definitions

  • Embodiments of the present invention relate generally to maintaining continuity in communications sessions, and more particularly, relate to a method, apparatus, and computer program product for providing a mechanism to identify media components in a session dialog which can facilitate transfer of those components to target access environments or devices.
  • session continuity An important aspect of mobile communications is session continuity. As newer generations of mobile technology evolve, mobile terminals must have the ability to move between differing technologies and seamlessly maintain session continuity. Additionally, session continuity can become increasingly complex in situations where a user is attempting to split or merge multiple communications component streams, such as voice, video, multimedia, and/or data between multiple communications devices. Accordingly, as new technologies evolve, additional complexity will likely be attributed to session continuity.
  • person-to-person communications is undergoing a transformation that will see users sharing rich content as never before.
  • Users may utilize a multitude of communications devices with differing capabilities, such as, for instance, devices with large or small display screens, devices with cameras or no camera, devices with full keyboards and so forth.
  • Current protocol design allows transferring whole ongoing multimedia communication session to different recipients and /or devices.
  • more granular session transfer capabilities between devices are needed.
  • a user may have the ability to transfer particular media component streams of a single session to differing devices, such as transferring video to a television, or transferring a messaging session to a PC, while maintaining a voice communication on a mobile communications device, such as a cell phone.
  • 3GPP Third Generation Partnership Project
  • AS application services
  • MMSC Multi-Media Session Continuity
  • MMSC AS MMSC application service
  • SIP Session Initiation Protocol
  • a SIP session can contain multiple media component streams, such as voice, video, multimedia, and/or data.
  • VCC voice call continuity
  • a device user may choose to split the video stream off of the original session to, for instance, a personal computer, but maintain the voice stream on, for instance, a mobile terminal.
  • the AS allows this splitting operation to occur in a manner that the device on the far end of the SIP session is unaware that any splitting operation occurred.
  • the AS can operate similarly in merging or transferring operations.
  • an AS can operate to hide the splitting, merging, or transferring operations from a far end device
  • systems without an AS are possible as well.
  • the far end device may be aware of the splitting, merging, and transferring operations and mobility of media component streams can be visible to the far end device.
  • the continual increases in the device computing powers such solutions where no AS is utilized are becoming increasingly desirable.
  • an AS For an exemplary situation where an AS is utilized, consider a mobile terminal on a source network, where a first type of access technology is utilized and a SIP session is opened with multiple media components. As a mobile terminal transitions onto a target network having a second type of access technology, a transfer of the session must occur. The AS could determine that the entire SIP session should be transferred to the target network, where the target network can support a single SIP session for the multiple media components. However, if the target network cannot support a single SIP session for all media components, or if a single SIP session for all media components is possible but not desirable, the AS could determine that the SIP session should be split with respect to particular media components.
  • Splitting of the SIP session may be required where, for example, the source network is entirely packet switched and the target network is comprised of a circuit switched portion for voice and a packet switched portion for multimedia.
  • a MMSC AS could merge the separate sessions when transitioning to the target network.
  • the AS can also manage SIP sessions where the user of a mobile device desires that media components within a SIP session should be split or merged so that particular media components can be transferred from a source device to one or more target devices.
  • a SIP session directed to, or intended for, a mobile terminal with voice and video components could be split according to a user' s desire, where the voice component is sent to a land-line telephone and the video component is sent to a personal computer.
  • a target device or a source device it may also be possible for a target device or a source device to request the transfer of the session or of particular media components within a session.
  • the process can be known as a transfer operation.
  • a target device requests the transfer, the process can be known as a retrieval operation.
  • the AS which could be an MMSC AS, can perform the splitting or merging of SIP sessions such that the splitting or merging is transparent at the other end, or the far end, of the communication. As such the far end of the communication can be unaware that any splitting or merging of the SIP session has occurred.
  • a method, apparatus, and computer program product are therefore provided that label or otherwise identify media component streams within a communications session dialog.
  • a message header can be extended to include a label parameter which specifically identifies a particular media component stream.
  • a message header can be extended to include a media type parameter which identifies particular types of media component streams within a session dialog.
  • a label parameter can be included in the body of a message which specifically identifies a particular media component stream. Further, combinations of these embodiments can be utilized to identify and target particular media component streams.
  • a communications device when a communications device receives a request for a new session dialog which contains indications of a media stream component label or type, the communications device can maintain the existing session and generate a new session which incorporates additional streams. The communications device can additionally modify the original session to remove appropriate media component streams.
  • a method for partial replacement in session initiation protocol may be provided. The exemplary method may include receiving a message indicating that a plurality of media component streams are anchored between a far end communications device and a transferring communications device. In this regard, the message may include respective labels for the media component streams.
  • the exemplary method may also include identifying a target label associated with a target media component stream to be transferred from the transferring communications device to a receiving communications device in the received message.
  • the target media component stream may be one of the plurality of media component streams.
  • the exemplary method may include generating an invite message, where the invite message may include the target label and a parameter value associated with the target label. The parameter value may indicate that the target media component stream is to be transferred from the transferring communications device to the receiving communications device.
  • an apparatus for partial replacement in session initiation protocol may be provided.
  • the apparatus may include a processor.
  • the processor may be configured to receive a message indicating that a plurality of media component streams are anchored between a far end communications device and a transferring communications device.
  • the message may include respective labels for the media component streams.
  • the processor may be further configured to identify a target label associated with a target media component stream to be transferred from the transferring communications device to a receiving communications device in the received message.
  • the target media component stream may be one of the plurality of media component streams.
  • the processor may be further configured to generate an invite message, where the invite message may include the target label and a parameter value associated with the target label. The parameter value may indicate that the target media component stream is to be transferred from the transferring communications device to the receiving communications device.
  • a computer program product for partial replacement in session initiation protocol.
  • the computer program product may comprise at least one computer-readable storage medium having executable computer-readable program code instructions stored therein.
  • the computer-readable program code instructions may be configured to receive a message indicating that a plurality of media component streams are anchored between a far end communications device and a transferring communications device.
  • the message may include respective labels for the media component streams.
  • the program code instructions may be further configured to identify a target label associated with a target media component stream to be transferred from the transferring communications device to a receiving communications device in the received message.
  • the target media component stream may be one of the plurality of media component streams.
  • the program code instructions may be further configured to generate an invite message, where the invite message may include the target label and a parameter value associated with the target label. The parameter value may indicate that the target media component stream is to be transferred from the transferring communications device to the receiving communications device.
  • Yet another exemplary embodiment of the present invention may be an apparatus for partial replacement in session initiation protocol.
  • the apparatus may include means for receiving a message indicating that a plurality of media component streams are anchored between a far end communications device and a transferring communications device.
  • the message may include respective labels for the media component streams.
  • the apparatus may further include means for identifying a target label associated with a target media component stream to be transferred from the transferring communications device to a receiving communications device in the received message.
  • the target media component stream being one of the plurality of media component streams.
  • the apparatus may include means for generating an invite message, where the invite message may include the target label and a parameter value associated with the target label. The parameter value may indicate that the target media component stream is to be transferred from the transferring communications device to the receiving communications device.
  • FIG. 1 is a schematic block diagram of a mobile terminal according to an exemplary embodiment of the present invention
  • FIG. 2 a schematic block diagram of a wireless communications system according to an exemplary embodiment of the present invention
  • FIG. 3 is a block diagram of a communications environment according to an exemplary embodiment of the present invention.
  • FIG. 4 is a flow diagram depicting an access transfer procedure according to an exemplary embodiment of the present invention.
  • FIG. 5 is a flow diagram depicting a transfer or retrieval operation according to an exemplary embodiment of the present invention.
  • FIG. 1 illustrates a block diagram of a mobile terminal 10 in accordance with exemplary embodiments of the present invention.
  • a mobile telephone as illustrated and hereinafter described is merely illustrative of one type of mobile terminal (also known as user equipment) that could benefit from embodiments of the present invention and, therefore, should not be taken to limit the scope of embodiments of the present invention.
  • mobile terminal 10 While one embodiment of the mobile terminal 10 is illustrated and will be hereinafter described for purposes of example, other types of mobile terminals, such as portable digital assistants (PDAs), pagers, mobile computers, mobile televisions, gaming devices, laptop computers, cameras, video recorders, Global Positioning System (GPS), GPS devices, and other types of voice and text communications systems, can readily employ embodiments of the present invention.
  • PDAs portable digital assistants
  • GPS Global Positioning System
  • GPS Global Positioning System
  • devices that are not mobile may also readily employ embodiments of the present invention.
  • the mobile terminal 10 may include an antenna 12 (or multiple antennas) in operable communication with a transmitter 14 and a receiver 16.
  • the mobile terminal 10 may further include an apparatus, such as a controller 20 or other processing element, that provides signals to and receives signals from the transmitter 14 and receiver 16, respectively.
  • the signals may include signaling information in accordance with the air interface standard of the applicable cellular system, and also user speech, received data and/or user generated data.
  • the mobile terminal 10 may be capable of operating with one or more air interface standards, communication protocols, modulation types, and access types.
  • the mobile terminal 10 may be capable of operating in accordance with any of a number of first, second, third and/or fourth- generation communication protocols or the like.
  • the mobile terminal 10 may be capable of operating in accordance with second-generation (2G) wireless communication protocols IS-136 (time division multiple access (TDMA)), GSM (global system for mobile communication), and IS-95 (code division multiple access (CDMA)), or with third-generation (3G) wireless communication protocols, such as Universal Mobile Telecommunications System (UMTS), CDMA2000, wideband CDMA (WCDMA) and time division-synchronous CDMA (TD-SCDMA), with fourth-generation (4G) wireless communication protocols, or the like.
  • 2G wireless communication protocols IS-136 (time division multiple access (TDMA)
  • GSM global system for mobile communication
  • IS-95 code division multiple access
  • third-generation (3G) wireless communication protocols such as Universal Mobile Telecommunications System (UMTS), CDMA2000, wideband CDMA (WCDMA) and time division-synchronous CDMA (TD-SCDMA), with fourth-generation (4G) wireless communication protocols, or the like.
  • 3G wireless communication protocols such as Universal Mobile Telecommunications System (UMTS), CDMA2000, wideband CDMA
  • the apparatus may include means, such as circuitry, desirable for implementing audio and logic functions of the mobile terminal 10.
  • the controller 20 may be comprised of a digital signal processor device, a microprocessor device, and various analog to digital converters, digital to analog converters, and other support circuits. Control and signal processing functions of the mobile terminal 10 may be allocated between these devices according to their respective capabilities.
  • the controller 20 thus may also include the functionality to convolutionally encode and interleave message and data prior to modulation and transmission.
  • the controller 20 can additionally include an internal voice coder, and may include an internal data modem. Further, the controller 20 may include functionality to operate one or more software programs, which may be stored in memory.
  • the controller 20 may be capable of operating a connectivity program, such as a conventional Web browser.
  • the connectivity program may then allow the mobile terminal 10 to transmit and receive Web content, such as location-based content and/or other web page content, according to a Wireless Application Protocol (WAP), Hypertext Transfer Protocol (HTTP) and/or the like, for example.
  • WAP Wireless Application Protocol
  • HTTP Hypertext Transfer Protocol
  • the mobile terminal 10 may also comprise a user interface including an output device such as a conventional earphone or speaker 24, a microphone 26, a display 28, and a user input interface, all of which may be coupled to the controller 20.
  • the user input interface which allows the mobile terminal 10 to receive data, may include any of a number of devices allowing the mobile terminal 10 to receive data, such as a keypad 30, a touch display (not shown) or other input device.
  • the keypad 30 may include the conventional numeric (0-9) and related keys (#, *), and other hard and/or soft keys used for operating the mobile terminal 10.
  • the keypad 30 may include a conventional QWERTY keypad arrangement.
  • the keypad 30 may also include various soft keys with associated functions.
  • the mobile terminal 10 may include an interface device such as a joystick or other user input interface.
  • the mobile terminal 10 may further include a battery 34, such as a vibrating battery pack, for powering various circuits that may be required to operate the mobile terminal 10, as well as optionally providing mechanical vibration as a detectable output.
  • the mobile terminal 10 may further include a user identity module (UIM) 38.
  • the UIM 38 may be a memory device having a processor built in.
  • the UIM 38 may include, for example, a subscriber identity module (SIM), a universal integrated circuit card (UICC), a universal subscriber identity module (USIM), a removable user identity module (R-UIM), etc.
  • SIM subscriber identity module
  • UICC universal integrated circuit card
  • USIM universal subscriber identity module
  • R-UIM removable user identity module
  • the UIM 38 may store information elements related to a mobile subscriber.
  • the mobile terminal 10 may be equipped with memory.
  • the mobile terminal 10 may include volatile memory 40, such as volatile Random Access Memory (RAM) including a cache area for the temporary storage of data.
  • RAM volatile Random Access Memory
  • the mobile terminal 10 may also include other non-volatile memory 42, which can be embedded and/or may be removable.
  • the non-volatile memory 42 can additionally or alternatively comprise an electrically erasable programmable read only memory (EEPROM), flash memory, or the like, such as that available from the SanDisk Corporation of Sunnyvale, California, or Lexar Media Inc. of Fremont, California.
  • EEPROM electrically erasable programmable read only memory
  • flash memory or the like, such as that available from the SanDisk Corporation of Sunnyvale, California, or Lexar Media Inc. of Fremont, California.
  • the memories can store any of a number of pieces of information, and data, used by the mobile terminal 10 to implement the functions of the mobile terminal 10.
  • the memories can include an identifier, such as an international mobile equipment identification (IMEI) code, capable of uniquely identifying the mobile terminal 10.
  • IMEI international mobile equipment identification
  • FIG. 2 is a schematic block diagram of a wireless communications system according to an exemplary embodiment of the present invention.
  • the system may include a plurality of network devices.
  • one or more mobile terminals 10 may each include an antenna 12 for transmitting signals to and for receiving signals from, a base site or base station (BS) 44.
  • the base station 44 may be a part of one or more cellular or mobile networks, each of which includes elements required to operate the network, such as a mobile switching center (MSC) 46.
  • MSC mobile switching center
  • the mobile network may also be referred to as a Base Station/MSC/Interworking function (BMI).
  • BMI Base Station/MSC/Interworking function
  • the MSC 46 may be capable of routing calls to and from the mobile terminal 10 when the mobile terminal 10 is making and receiving calls.
  • the MSC 46 can also provide a connection to landline trunks when the mobile terminal 10 is involved in a call.
  • the MSC 46 can be capable of controlling the forwarding of messages to and from the mobile terminal 10, and can also control the forwarding of messages for the mobile terminal 10 to and from a messaging center. It should be noted that although the MSC 46 is shown in the system of FIG. 2, the MSC 46 is merely an exemplary network device and embodiments of the present invention are not limited to use in a network employing an MSC.
  • the MSC 46 can be coupled to a data network, such as a local area network (LAN), a metropolitan area network (MAN), and/or a wide area network (WAN).
  • the MSC 46 can be directly coupled to the data network.
  • the MSC 46 may be coupled to a gateway device (GTW) 48, and the GTW 48 may be coupled to a WAN, such as the Internet 50.
  • GTW gateway device
  • devices such as processing elements (e.g., personal computers, server computers or the like) can be coupled to the mobile terminal 10 via the Internet 50.
  • the processing elements can include one or more processing elements associated with a computing system 52, origin server 54, and/or the like, as described below.
  • the BS 44 can also be coupled to Internet 50 through internet protocol multimedia subsystem (IMS) 70 and, in some embodiments, application service (AS) 72.
  • IMS internet protocol multimedia subsystem
  • AS application service
  • IMS 70 can provide a link to Internet 50 in a packet switched domain.
  • the link between BS 44 and Internet 50 through IMS 70 can also optionally include AS 72.
  • AS 72 can be an application service (AS) which can provide functionality for managing communications sessions.
  • the BS 44 can also be coupled to a signaling GPRS (General Packet Radio Service) support node (SGSN) 56.
  • GPRS General Packet Radio Service
  • the SGSN 56 may be capable of performing functions similar to the MSC 46 for packet switched services.
  • the SGSN 56 like the MSC 46, can be coupled to a data network, such as the Internet 50.
  • the SGSN 56 can be directly coupled to the data network.
  • the SGSN 56 may be coupled to a packet-switched core network, such as a GPRS core network 58.
  • the packet-switched core network may be coupled to another GTW 48, such as a GTW GPRS support node (GGSN) 60, and the GGSN 60 may be coupled to the Internet 50.
  • the packet-switched core network can also be coupled to a GTW 48.
  • the GGSN 60 can be coupled to a messaging center.
  • the GGSN 60 and the SGSN 56 may be capable of controlling the forwarding of messages, such as MMS messages.
  • the GGSN 60 and SGSN 56 may also be capable of controlling the forwarding of messages for the mobile terminal 10 to and from the messaging center.
  • the SGSN 56 may be coupled to the GPRS core network 58 and the
  • devices such as a computing system 52 and/or origin server 54 may be coupled to the mobile terminal 10 via the Internet 50, SGSN 56 and GGSN 60.
  • devices such as the computing system 52 and/or origin server 54 may communicate with the mobile terminal 10 across the SGSN 56, GPRS core network 58, and the GGSN 60.
  • the mobile terminals 10 may communicate with the other devices and with one another, such as according to Session Initiation Protocol (SIP) or the Hypertext Transfer Protocol (HTTP) and/or the like, to thereby carry out various functions of the mobile terminals 10.
  • SIP Session Initiation Protocol
  • HTTP Hypertext Transfer Protocol
  • the mobile terminal 10 may be coupled to one or more of any of a number of different networks through the BS 44.
  • the network(s) may be capable of supporting communication in accordance with any one or more of a number of first-generation (IG), second-generation (2G), 2.5G, third- generation (3G), 3.9G, fourth-generation (4G) mobile communication protocols or the like.
  • IG first-generation
  • 2G second-generation
  • 3G third- generation
  • 4G fourth-generation
  • 4G fourth-generation
  • one or more of the network(s) can be capable of supporting communication in accordance with 2G wireless communication protocols IS-136 (TDMA), GSM, and IS- 95 (CDMA).
  • one or more of the network(s) can be capable of supporting communication in accordance with 2.5G wireless communication protocols GPRS, Enhanced Data GSM Environment (EDGE), or the like. Further, for example, one or more of the network(s) can be capable of supporting communication in accordance with 3G wireless communication protocols such as a UMTS network employing WCDMA radio access technology.
  • Some narrow-band analog mobile phone service (NAMPS), as well as total access communication system (TACS), network(s) may also benefit from embodiments of the present invention, as should dual or higher mode mobile stations (e.g., digital/analog or TDM A/CDMA/analog phones).
  • the mobile terminal 10 can further be coupled to one or more wireless access points (APs) 62.
  • the APs 62 may comprise access points configured to communicate with the mobile terminal 10 in accordance with techniques such as, for example, radio frequency (RF), Bluetooth (BT), infrared (IrDA) or any of a number of different wireless networking techniques, including wireless LAN (WLAN) techniques such as IEEE 802.11 (e.g., 802.11a, 802.11b, 802. Hg, 802. Hn, etc.), world interoperability for microwave access (WiMAX) techniques such as IEEE 802.16, and/or ultra wideband (UWB) techniques such as IEEE 802.15 and/or the like.
  • the APs 62 may be coupled to the Internet 50.
  • the APs 62 can be directly coupled to the Internet 50. In one embodiment, however, the APs 62 may be indirectly coupled to the Internet 50 via a GTW 48. Furthermore, in one embodiment, the BS 44 may be considered as another AP 62. As will be appreciated, by directly or indirectly connecting the mobile terminals 10 and the computing system 52, the origin server 54, and/or any of a number of other devices, to the Internet 50, the mobile terminals 10 can communicate with one another, the computing system, etc., to thereby carry out various functions of the mobile terminals 10, such as to transmit data, content, or the like to, and/or receive content, data or the like from, the computing system 52. As used herein, the terms "data,” "content,”
  • the mobile terminals 10 can communicate with one another, the computing system, 52, the origin server 54, etc., to thereby carry out various functions of the mobile terminals 10, such as to transmit data, content, or the like to, and/or receive content, data or the like from, the computing system 52, and/or the origin server 54, etc.
  • the mobile terminal 10 and computing system 52 may be coupled to one another and communicate in accordance with, for example, RF, BT, IrDA or any of a number of different wireline or wireless communication techniques, including LAN, WLAN, WiMAX, UWB techniques and/or the like.
  • One or more of the computing system 52 can additionally, or alternatively, include a removable memory capable of storing content, which can thereafter be transferred to the mobile terminal 10.
  • the mobile terminal 10 can be coupled to one or more electronic devices, such as printers, digital projectors and/or other multimedia capturing, producing and/or storing devices (e.g., other terminals).
  • IMS Internet Engineering Task Force
  • IETF Internet Engineering Task Force
  • media component streams can be defined using an extension to a SIP Replaces header described in the IETF, Network Working Group, Standards Track, Request for Comments (RFC) 3891 by R. Mahy, et al. (September 2004), where the session dialog is an SIP session dialog. Since the Replaces header can be used to replace a SIP dialog with a new SIP dialog, the extension to the header which describes the media component streams can be used to partially replace the SIP dialog. For instance, an extension can be used to replace only certain media components in an existing SIP dialog, while maintaining other media components.
  • RRC Request for Comments
  • RFC 3891 mandates that when a communications device, otherwise known as user equipment (UE), receives and accepts an INVITE message with a Replaces header to release an SIP dialog, the UE can do so by generating a BYE message.
  • UE user equipment
  • the UE may not release the existing SIP dialog, but generate a re-INVITE message and remove the appropriate media component streams from the existing SIP dialog.
  • the recipient UE does not support a Replaces header extension, the entire existing SIP dialog can be released.
  • a media reference tag can be provided in a Replaces header in accordance with a label pointer described in IETF, Network Working Group, Standards Track, RFC 4574 by O. Levin, et al. (August 2006).
  • RFC 4574 describes a media attribute in a session description protocol (SDP) that can be used to identify media streams.
  • SDP session description protocol
  • a unique label can be assigned to each media component stream, and one or more media component streams can be identified in a Replaces header.
  • An exemplary description of the Replaces header parameters can be comprised as follows, where the label parameter can provide a unique identifier for each media component stream.
  • a UE that generates an INVITE message, with the associated Replaces header can indicate unambiguously which media component streams should be replaced.
  • the media component stream types need not be the same.
  • a video stream may replace and audio stream.
  • the above implementations indicate two exemplary means of including media component stream labels in a Replaces header.
  • Each of the two examples when implemented in an appropriate message, such as, for example, an INVITE message, can cause the replacement of the ABC and XYZ media component streams in an existing SIP dialog with new media component streams having the labels ABC and XYZ.
  • An alternative means of identifying media component streams can be to identify the type of media component stream in a Replaces header of a SIP dialog, using, for example, a media- type-tag. By merely indicating the type of stream, however, it may not be possible to identify a specific stream when multiple streams of the same type are present.
  • a recipient of an INVITE message containing the Replaces header may select and replace one or more media or all media component streams of a particular type based on, for example a local policy, such as maintaining the most recently connected media component stream of a particular type.
  • the SDP offer in an INVITE message could contain the label parameter described above to unambiguously indicate a specific media component stream.
  • a third alternative means of identifying media component streams can be to not extend the header, but to identify the media component streams in the body of an INVITE message, or other SIP message, in a SDP offer. If a label of a media component stream appears in the body of the message, then the appropriate media component stream can be acted upon.
  • a device with an open dialog with one party receives a new INVITE message for some other party it may compare the media component stream labels received in the SDP offer with the original dialog. If the labels of the media stream match, then the media stream can be replaced, otherwise the media stream can be considered to be a new media stream.
  • An advantage to this alternative is that no changes to SIP are necessary.
  • FIG. 3 depicts a block diagram of an exemplary communications environment 300 comprising user equipment (UE) 310, 320, and 330 where an exemplary transfer procedure can occur using a means of identifying media component streams within a session dialog between two or more communications devices, including, but not limited to, the various means described above.
  • the communications environment 300 may be supported, for example, by the communications system of FIG. 2 and may include UE 310, 320 and 330 where each of UE 310, 320, and 330 can be, for example, a mobile terminal 10 as shown in FIG. 1 or any other wired or wireless communications device, such as, but not limited to a personal computer, a television, or a television tuner unit.
  • UE 320 and UE 330 have an ongoing session dialog 340, such as a SIP dialog, where two exemplary media component streams have been established. Attributes of the original SIP dialog between UE 320 and UE 330 are indicated at 350.
  • the media streams can be labeled stream ABC, which, in this example, can be a video stream, and stream DEF, which in this example can be an audio stream, for identification purposes. Further, it is contemplated that with respect to utilizing labels for the media streams, in some embodiments, the offeror or the answerer can assign labels.
  • UE 320 desires to transfer video media stream ABC to UE 310, but maintain audio media stream DEF.
  • UE 320 can send a REFER message with a Replaces header having a refer-to tag directed to UE 310 at 360.
  • a call-id tag, a from tag, and a to tag in the Replaces header can refer to the ongoing dialog between UE 320 and UE 330.
  • a means of identifying media component streams can be included.
  • the Replaces header of the REFER message can contain a media component stream label for ABC.
  • the refer-to header in the REFER message can also contain an audio media feature, as described in IETF, Network Working Group, Standards Track RFC 4508 by O. Levin, et al. (May 2006).
  • the audio media feature tag can indicate to UE 310 that that UE 330 supports audio media, and as such, UE 330 can include audio media to the SDP offer that it generates as a result of receiving the REFER message.
  • UE 310 can then generate an INVITE message towards UE 330 at 370.
  • the INVITE message can comprise a Replaces header with the same media component stream labels.
  • the INVITE message can also comprise a SDP offer with a media component stream label for ABC that replaces the original media component stream ABC and a new media component stream GHI.
  • UE 330 can then receive and accept the INVITE message with the Replaces header, and generate a re-INVITE message towards UE 320 at 380.
  • the SDP offer of the re-INVITE message can remove the media component stream ABC from the original SIP dialog.
  • an acknowledgement for the INVITE message such as a 200 OK message from UE 320 and UE 330
  • one audio media stream DEF can exist between UE 320 and UE 330 at 390, a video media streams ABC and an audio media stream GHI between UE 310 and UE 330.
  • the above exemplary operations were described where an audio and a video stream were originally present between UE 320 and UE 330. However, the streams could have been of any type and the operations can be equally applicable.
  • the original SIP dialog between UE 320 and UE 330 involves an audio stream ABC, and a data stream DEF.
  • UE 320 is a mobile terminal 10
  • UE 310 is a personal computer.
  • the user of the mobile terminal, UE 320 may desire to transfer audio stream ABC to the personal computer, UE 310, generate a video stream GHI between UE 330 and the personal computer, UE 310, but maintain the original data stream DEF between the mobile terminal, UE 320, and UE 330.
  • the data stream DEF would be maintained between UE 330 and the mobile terminal.
  • the audio stream ABC would be transferred to be between UE 330 and the personal computer, and a video stream GHI between UE 330 and the personal computer would be generated.
  • UE 330 can be a conferencing server, and UE 310 and UE 320 can be devices utilized by a single user.
  • the media streams can be labeled stream ABC and DEF both of which, in this example, can be an audio streams, for identification purposes.
  • the user may desire to transfer an existing media component stream in a conference session from UE 320 to UE 310, while maintaining the remaining media flows on UE 320.
  • the transfer procedures described above can be applicable to this scenario as well.
  • UE 320 can direct a REFER message to UE 310, where the REFER message has a Replaces header that includes the media component stream label for ABC.
  • UE 310 can then generate an INVITE message toward UE 330 having a Replaces header with labels for streams ABC and GHI.
  • UE 330 can then generate a re-INVITE toward UE 320 having a SDP offer to remove the ABC stream from the original SIP dialog.
  • one audio media stream DEF can exist between UE 320 and UE 330 at 390, and two audio media streams ABC and GHI between UE 310 and UE 330.
  • a conferencing communication of UE 310 and UE 320 can occur where UE 330 is a conferencing server.
  • both UE 320 and UE 330 have an audio stream connection to the conferencing server, which can allow UE 320 and UE 310 to communicate with each other through the conferencing server, UE 330.
  • UE 310 has a second stream GHI to the conferencing server, UE 330, which could be, for example, a video stream.
  • Embodiments of the present invention can be utilized in a retrieval procedure as well.
  • UE 310 could use a dialog event package, such as the dialog event package described in IETF, Network Working Group, Standards Track RFC 4235 by J. Rosenburg, et al. (November 2005), to retrieve ongoing SIP dialogs from UE 320 or UE 330.
  • UE 310 receives a NOTIFY message with the dialog event package body for UE 320 or UE 330, the UE 310 can receive the ongoing dialogs between UE 320 and UE 330.
  • UE 310 may set an include-session-description parameter to a SUBSCRIBE request, where, according to various embodiments, the body of the NOTIFY message can contain the media type of each ongoing media stream.
  • the dialog event package Extensible Markup Language (XML) schema can also be extended to contain a media component stream label as part of the media type description.
  • a dialog event package XML schema can be extended to contain a media component stream label in accordance with RFC 4574.
  • INVITE message with an appropriate SDP body containing media stream information that can enable UE 310 to retrieve media from the ongoing session, e.g. by including an SDP offer with a media component stream label for ABC.
  • UE 310 can, similar to the previous example, set a media component stream label in the Replaces header of an INVITE message.
  • UE 310 can set a media-type-tag to "audio" in the Replaces header of an INVITE message.
  • UE 310 has retrieved the ABC media stream from the SIP dialog between UE 320 and UE 330.
  • This exemplary operation could be used where a user of UE 310 desires to, and has permission to, break into a communication between UE 320 and UE 330.
  • FIG. 4 is an exemplary flow diagram depicting an access transfer procedure, such as where a UE transfers one or more media components from a network having a first access technology to a network having a second access technology.
  • the first access technology may include slow packet switched technology for multimedia and circuit switched technology for voice
  • the second access technology may include faster packet switched technology for multimedia, but the same circuit switched technology for voice.
  • the environment depicted in FIG. 4 may be supported by the communications system of FIG. 2 and may include two communications devices UE 400 and far end 440.
  • UE 400 and far end 440 can be any type of communications devices including, but not limited to, mobile terminal 10.
  • a session between UE 400 and far end 440 can involve an internet protocol multimedia subsystem (IMS) 420, and an application service (AS) 430.
  • IMS internet protocol multimedia subsystem
  • AS application service
  • AS 430 can be a MMSC AS.
  • UE 400 has an ongoing SIP dialog with far end 440 through AS 430.
  • the dialog includes voice and multimedia streams through a first access for illustration purposes, however, any type of stream could be included.
  • the voice stream can be labeled A and multimedia (mm) stream can be labeled B.
  • the AS 430 can anchor the SIP dialog session.
  • the AS 430 is an MMSC AS
  • the MMSC AS can be a back to back user agent (B2BUA).
  • B2BUA back to back user agent
  • the MMSC AS can maintain a binding between a call-id tag, a from tag, and a to tag, in both the UE 400 side and far end 440 side. Note that the examples described with respect to FIG.
  • UE 400 utilizes an AS, but embodiments of the invention are contemplated where no AS is present and the transfers of media component streams are managed directly between UE 400 and far end 440.
  • a new access becomes available to UE 400, and UE 400 determines that it would be desirable to transfer the multimedia stream to the new access, but maintain the voice media stream on the original access.
  • UE 400 can register to IMS 420 over the new access, and generate an INVITE message with a Replaces header.
  • the Replaces header can refer to the ongoing SIP dialog between UE 400, through AS 430, to far end 440, and include, according to some embodiments, a media label that refers to the existing multimedia stream in the existing SIP dialog.
  • the INVITE message can include an SDP offer in the body, where the labeled multimedia stream can be offered. Additionally, in some embodiments, an INVITE message can contain the appropriate labels within a Replaces header.
  • the Replaces header can refer to the ongoing SIP dialog between UE 400, through AS 430, to far end 440, and include, according to some embodiments, a media-type-tag set to an appropriate value that refers to the existing multimedia stream in the existing SIP dialog.
  • the INVITE message can be routed to AS 430, where AS 430 can interpret the content of the Replaces header and/or SDP offer in the body and recognize that the existing multimedia stream over the original access needs to be replaced with a new multimedia stream over the new access.
  • AS 430 can generate a re-INVITE message towards far end 440.
  • the re-INVITE message can include the new internet protocol (IP) address of the multimedia stream.
  • IP internet protocol
  • the re-INVITE message can also include changed codec, and other attributes.
  • AS 430 can generate an additional re-INVITE message towards UE 400 over the original access to remove the original multimedia stream.
  • UE 400 can have two SIP dialogs to AS 430, one over the original access with voice media stream, and the other over the new access with multimedia stream.
  • the voice media stream may utilize a VCC dialog between the UE 400 and AS 430.
  • AS 430 can combine these dialogs such that far end 440 sees only one SIP dialog with two media streams.
  • the multimedia stream B can be transferred to the second access technology, which may support faster data transfer rates.
  • the voice stream A can be maintained on the first access technology because no improvement in service may result from transferring the voice stream to the second access technology.
  • FIG. 5 is an exemplary flow diagram depicting a transfer or retrieval operation.
  • the environment depicted in FIG. 5 may be supported by the communications system of FIG. 2 and may include three communications devices, UE 500, UE 510 and far end 540.
  • UE 500, UE 510 and far end 540 can be any type of communications devices including, but not limited to, mobile terminal 10.
  • a session between UE 500, or UE 510, and far end 540 can involve IMS 520 and AS 530.
  • AS 530 can be an MMSC AS. Note that the examples described with respect to FIG. 5 utilize an AS, but embodiments of the invention are contemplated where no AS is present and the transfers of media component streams are managed directly between UE 500, UE 510 and far end 540.
  • a SIP dialog can be open between UE 500 and AS 530, and eventually with far end 540.
  • the dialog includes voice and multimedia streams for illustration, however any type of stream could be used.
  • the voice stream can be labeled A and multimedia (mm) stream can be labeled B.
  • UE 500 desires a transfer of the multimedia stream to UE 510. Accordingly, at 560, UE 500 can send a REFER message with Replaces header, where the header includes a value in a refer-to parameter directed to UE 510, as described earlier.
  • UE 510 can generate an INVITE message with a Replaces header having, in some embodiments, a label parameter that refers to the multimedia stream between UE 500 and AS 530 and eventually far end 540.
  • the Replaces header can refer to the ongoing SIP dialog between UE 500, through AS 530, to far end 540, and include, according to some embodiments, a media-type-tag set to the appropriate value that refers to the existing multimedia stream between UE 500 and AS 530 and eventually far end 540.
  • the INVITE message can be routed to AS 530 where application logic can be applied.
  • AS 530 can generate a re-INVITE message to far end 540 with an SDP offer that changes the remote IP address of the multimedia stream.
  • AS 530 can receive an acknowledgement, such as a 200 OK message for INVITE, from far end 540.
  • AS 530 can generate an acknowledgement, such as a 200 OK message for INVITE, for UE 510.
  • AS 530 can also remove the multimedia stream from UE 500 by sending an appropriate re-INVITE message to UE 500.
  • UE 500 can request a transfer of the multimedia stream to UE 510.
  • UE 510 is a personal computer or other device that supports multimedia applications and UE 500 is a mobile terminal.
  • the voice stream can remain with the mobile terminal, but the multimedia stream can be sent to the personal computer possibly to facilitate user interaction with respect to the multimedia stream.
  • UE 510 could have retrieved the multimedia stream by sending a SUBSCRIBE message for a dialog event package to AS 530.
  • AS 530 can then report the SIP dialogs which UE 510 is authorized to receive.
  • dialogs with the same public user identity can be received, but this policy may vary depending on the configuration of AS 530.
  • AS 530 can report the SIP dialog with UE 500, where the notification can comprise the types of media streams in the dialog and, according to some embodiments, an extension to hold the label of each media stream.
  • UE 510 can determine the labels of the media streams between UE 510 and AS 530.
  • UE 510 can accordingly retrieve the multimedia stream and generate an INVITE message with a Replaces header having, in some embodiments, a label extension.
  • UE 510 can use the obtained information and send an INVITE message with an appropriate SDP body containing media stream information that can enable UE 510 to retrieve media from the ongoing session, e.g. by included SDP offer with a media component stream label for B.
  • UE 510 can set a media-type-tag to an appropriate value e.g. "video" in the Replaces header of an INVITE message.
  • UE 510 can retrieve the multimedia stream from UE 500. Such a procedure may be desirable where UE 510 is a personal computer or other device that supports multimedia applications and UE 500 is a mobile terminal. The voice stream can remain with the mobile terminal, but the multimedia stream can be retrieved to the personal computer possibly to facilitate user interaction with respect to the multimedia stream.
  • the functionality described above in conjunction with the UEs can be provided in various manners. In one embodiment, however, the functionality of the UEs can be provided by the controller 20 of the UE that operates under control of a computer program stored by memory, such as RAM 40 or ROM 42. As will be appreciated, any such computer program instructions may be loaded onto a computer or other programmable apparatus (i.e., hardware) to produce a machine, such that the instructions which execute on the computer or other programmable apparatus (e.g., hardware) means for implementing the functions described above.
  • These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the functions specified in the flowcharts block(s) or step(s).
  • the computer program instructions may also be loaded onto a computer or other programmable apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions that are carried out in the system.
  • the functionality described above can be implemented as a method. The method can include initially labeling or retrieving labels of media component streams.
  • labeling can include extending a session message header, such as a Replaces header, with one or more labels associated with a predetermined media component stream.
  • labeling can include extending a session message header, such as a Replaces header, with a media-type- tag associated with one or more predetermined media component streams.
  • labeling can include extending a session message body with one or more labels associated with one or more predetermined media component streams.
  • a dialog event package XML schema can also be extended to contain a media component stream label as part of the media type description. Where a media component stream label or type tag is included in a session message, the method can further include, in some embodiments, splitting or merging predetermined media component streams into a particular communications session.
  • an apparatus can be configured to implement the functionality described above.
  • the apparatus can be configured to initially label or retrieve labels of media component streams.
  • the apparatus can be configured to label one or more media component streams by extending a session message header, such as a Replaces header.
  • the apparatus can be configured to label one or more media component streams by extending a session message header, such as a Replaces header, with a media-type-tag associated with one or more predetermined media component streams.
  • the apparatus can be configured to extend a session message body with one or more labels associated with one or more predetermined media component streams.
  • a dialog event package XML schema can also be extended to contain a media component stream label as part of the media type description.
  • the apparatus can be further configured, in some embodiments, to detect one or more media component stream labels or type tags in a session message, and when detected, the apparatus can be configured to split or merge predetermined media component streams into a particular communications session.
  • the above described functions may be carried out in many ways. For example, any suitable means for carrying out each of the functions described above may be employed to carry out the invention. In one embodiment, all or a portion of the elements of the invention generally operate under control of a computer program product.
  • the computer program product for performing the methods of embodiments of the invention includes a computer-readable storage medium, such as the non- volatile storage medium, and computer-readable program code portions, such as a series of computer instructions, embodied in the computer-readable storage medium.
  • labeling can include initially labeling or retrieving labels of media component streams.
  • labeling can include extending a session message header, such as a Replaces header, with one or more labels associated with a predetermined media component stream.
  • labeling can include extending a session message header, such as a Replaces header, with a media-type- tag associated with one or more predetermined media component streams.
  • labeling can include extending a session message body with one or more labels associated with one or more predetermined media component streams.
  • an apparatus can be configured to implement the functionality described above.
  • the apparatus can be configured to initially label or retrieve labels of media component streams.
  • the apparatus can be configured to label one or more media component streams by extending a session message header, such as a Replaces header.
  • the apparatus can be configured to label one or more media component streams by extending a session message header, such as a Replaces header, with a media-type-tag associated with one or more predetermined media component streams.
  • the apparatus can be configured to extend a session message body with one or more labels associated with one or more predetermined media component streams.
  • the apparatus can be further configured, in some embodiments, to detect one or more media component stream labels or type tags in a session message, and when detected, the apparatus can be configured to split or merge predetermined media component streams into a particular communications session.

Landscapes

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

Abstract

L'invention porte sur un procédé, un appareil et un produit de programme d'ordinateur permettant de marquer de façon spécifique des flux de composantes multimédias spécifiques ou d'identifier le type de flux de composantes multimédias, dans un dialogue de session de communications. À cet effet, des flux de composantes multimédias peuvent être scindés ou fusionnés en des dialogues de session de communications existants ou nouvellement créés.
PCT/EP2008/065209 2007-11-12 2008-11-10 Procédé, appareil et produit de programme d'ordinateur pour remplacement de flux de données partiel dans un protocole d'ouverture de session Ceased WO2009062903A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US98718407P 2007-11-12 2007-11-12
US60/987,184 2007-11-12

Publications (1)

Publication Number Publication Date
WO2009062903A1 true WO2009062903A1 (fr) 2009-05-22

Family

ID=40405105

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2008/065209 Ceased WO2009062903A1 (fr) 2007-11-12 2008-11-10 Procédé, appareil et produit de programme d'ordinateur pour remplacement de flux de données partiel dans un protocole d'ouverture de session

Country Status (1)

Country Link
WO (1) WO2009062903A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012087419A3 (fr) * 2010-12-22 2012-08-23 Rambus Inc. Gestion de session pour une communication dans un réseau hétérogène
US20240080377A1 (en) * 2022-09-06 2024-03-07 At&T Intellectual Property I, L.P. Facilitating elastic distributed computing for resource intensive tasks including split rendering in advanced networks
WO2024109582A1 (fr) * 2022-11-22 2024-05-30 中兴通讯股份有限公司 Procédé de traitement multimédia, serveur multimédia et support d'enregistrement

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
LEVIN MICROSOFT CORPORATION G CAMARILLO ERICSSON O: "The Session Description Protocol (SDP) Label Attribute; rfc4574.txt", IETF STANDARD, INTERNET ENGINEERING TASK FORCE, IETF, CH, 1 August 2006 (2006-08-01), XP015055011, ISSN: 0000-0003 *
SHACHAM H SCHULZRINNE COLUMBIA UNIVERSITY S THAKOLSRI W KELLERER DOCOMO EUROLABS R: "Session Initiation Protocol (SIP) Session Mobility; draft-shacham-sipping-session-mobility-02.txt", IETF STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, no. 2, 1 February 2006 (2006-02-01), XP015044574, ISSN: 0000-0004 *
STUDENT: CHEN-JUI PENG ADVISOR: REN-HUNG HWANG: "SSIP: Split a SIP Session over Multiple Devices", INTERNET CITATION, June 2005 (2005-06-01), XP007904234, Retrieved from the Internet <URL:http://140.123.21.32/ETD-db/ETD-search/getfile?URN=etd-0727105-020000 &filename=etd-0727105-020000.pdf> [retrieved on 20080304] *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012087419A3 (fr) * 2010-12-22 2012-08-23 Rambus Inc. Gestion de session pour une communication dans un réseau hétérogène
US20240080377A1 (en) * 2022-09-06 2024-03-07 At&T Intellectual Property I, L.P. Facilitating elastic distributed computing for resource intensive tasks including split rendering in advanced networks
WO2024109582A1 (fr) * 2022-11-22 2024-05-30 中兴通讯股份有限公司 Procédé de traitement multimédia, serveur multimédia et support d'enregistrement

Similar Documents

Publication Publication Date Title
US7685293B2 (en) Method and apparatus for optimization of sigcomp UDVM performance
EP2266282B1 (fr) Appareil, procédé, système et programme pour une communication
KR101240797B1 (ko) 네트워크 컴포넌트가 통신 세션을 라우팅하는 방법
US8781126B2 (en) Method, apparatus and computer program product for providing security during handover between a packet-switched network and a circuit-switched network
US7561081B2 (en) Method and apparatus for optimization of SigComp UDVM performance
JP5502860B2 (ja) サポートされるｉｐバージョンを示し、ｓｉｐと互換性のあるｉｐバージョンをサポートするデバイスに到達するための方法
US20100325286A1 (en) Session transfer method and method for supporting session continuity
KR20090079977A (ko) 채널 스위칭 방법, 장치 및 컴퓨터 판독가능 매체
JP2011527532A5 (fr)
JP4864099B2 (ja) ドメイン転換制限方法及び端末
EP2294890B1 (fr) Procédés destinés à router un support par commutation de circuits vers un noeud de système multimédia à protocole internet à l&#39;aide d&#39;un en-tête de contact de protocole de lancement de session
EP2020135B1 (fr) Procédé d&#39;enregistrement de dispositifs à contacts multiples
WO2009062903A1 (fr) Procédé, appareil et produit de programme d&#39;ordinateur pour remplacement de flux de données partiel dans un protocole d&#39;ouverture de session
CN101491054B (zh) 信号压缩udvm性能优化的方法和装置
US20150208447A1 (en) Composite ars service providing method and apparatus
WO2023213275A1 (fr) Procédé et appareil de communication, terminal, dispositif côté réseau et support
WO2025087757A1 (fr) Appareil, procédé et programme informatique
WO2024012288A1 (fr) Procédés et appareils de maintien de canal de données, dispositifs de communication et support de stockage lisible
HK40002822A (en) Methods to route a bearer via circuit switching to an internet protocol multimedia system node using session initiation protocol contact header

Legal Events

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

Ref document number: 08849000

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08849000

Country of ref document: EP

Kind code of ref document: A1