EP1938551A1 - Procede pour etablir une liaison visiophonique et/ou une liaison telephonique multimedia dans un reseau de donnees - Google Patents

Procede pour etablir une liaison visiophonique et/ou une liaison telephonique multimedia dans un reseau de donnees

Info

Publication number
EP1938551A1
EP1938551A1 EP06793368A EP06793368A EP1938551A1 EP 1938551 A1 EP1938551 A1 EP 1938551A1 EP 06793368 A EP06793368 A EP 06793368A EP 06793368 A EP06793368 A EP 06793368A EP 1938551 A1 EP1938551 A1 EP 1938551A1
Authority
EP
European Patent Office
Prior art keywords
network
message
ims
signaling
sip
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.)
Withdrawn
Application number
EP06793368A
Other languages
German (de)
English (en)
Inventor
Thomas Belling
Franz Kalleitner
Norbert Seitter
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.)
Siemens AG
Original Assignee
Siemens AG
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 Siemens AG filed Critical Siemens AG
Publication of EP1938551A1 publication Critical patent/EP1938551A1/fr
Withdrawn 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/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1043—Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • 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/1069—Session establishment or de-establishment
    • 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/1095—Inter-network session transfer or sharing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/141—Systems for two-way working between two video terminals, e.g. videophone
    • H04N7/148—Interfacing a video terminal to a particular transmission medium, e.g. ISDN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/15—Conference systems
    • H04N7/152—Multipoint control units therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]

Definitions

  • the invention relates to a method for establishing a video telephone connection in a data network comprising a telephone network and an IP network based on the Internet Protocol.
  • video telephone connection is to be understood here and in the following as general and, in addition to pure video telephony, also includes multimedia telephony.
  • a telephone network for example a mobile radio network, in particular a GSM or UMTS mobile radio network
  • IP-based network for example a GSM or UMTS mobile radio network
  • CS Circuit Switched
  • PSTN Public Switched Telephone Network
  • IMS IP Multimedia Subsystem
  • the object of the invention is therefore to provide a method which the construction of a video telephone connection between allows a subscriber on the side of a telephone network and a subscriber on the side of an IP network.
  • a call setup is established between a first subscriber who is located in or adjacent to the telephone network and a second subscriber who is located in or adjacent to the IP network via the telephone network and the IP network using a first signaling protocol in the telephone network and a second signaling protocol in the IP network.
  • Subscribers here are in particular a terminal, in particular a mobile terminal or a landline terminal.
  • signaling messages of the first signaling protocol are converted into signaling messages of the second signaling protocol and / or vice versa during call establishment (step b)).
  • step c) one or more encodings are defined during this conversion, which are usable and / or presumably usable in the transmission of the payloads exchanged during the video telephone connection in the telephone network.
  • This determination of the codings is made since, in the case of signaling with the first signaling protocol in the telephone network, usually no information about the usable codings for the useful data is transmitted. This information is transmitted in the telephone connection only at a later time, namely when establishing the actual data connection for transmitting the user data.
  • a signaling protocol used in the IP network requires the information regarding usable codings. Therefore, in a step d), the codes which have been defined in step c) are combined with one or more signaling messages of the second signal.
  • Step e) is then determined on the part of the telephone network using a third signaling protocol, which is in particular H.245, the coding used for the user data.
  • a third signaling protocol which is in particular H.245, the coding used for the user data.
  • the present invention is based on the finding that for the purpose of signaling in the IP network already useable or probably usable codings must be established. However, since the codings on the part of the telephone network are not yet known in the signaling, in the method according to the invention it is estimated in advance or determined which codings can be used or expected to be usable in the transmission of the payload in the telephone network. This information is then used by the second signaling protocol. Thus, with the method according to the invention, a fast connection can be ensured, since it is not necessary to wait for the actual structure of the data connection, in which the codings which can actually be used in the telephone network are communicated.
  • the inventive method is preferably used in the already mentioned above 3GPP data network.
  • a telephone network in particular a CS network and / or a PSTN network is used, which have already been mentioned above.
  • the second IP network used is preferably the IMS network already mentioned above.
  • the known Preconditions- extension is used in the SIP protocol to signal after step f) that the construction of a transport connection (also referred to as bearer connection) is completed.
  • MGCF Media Gateway Control Function
  • IM-MGW IMS Media Gateway
  • the H.324 protocol family well known from the prior art is used.
  • a mobile network as a telephone network here is a modification of this protocol, namely the H.324M protocol used.
  • the codings are determined as a function of the telephone network used. This is based on the knowledge that certain codes are preferred depending on the telephone network used.
  • the codings in step c) of the method according to the invention are dependent on the telephone number of the first subscriber who is in or adjacent to beard on the side of the telephone network. In this case, it is made use of the knowledge that the number of the first subscriber can be used to determine in which telephone network the subscriber is located. From this it can again be concluded which codings are preferably used.
  • step c) those coding methods are defined which, depending on the telephone network used and the IP network used, are most likely to be used in both networks. This ensures that the correct selection of compatible encodings is determined in advance. Such a selection of the codes can be achieved and optimized, for example, by evaluating statistics or by administrative settings. In particular, it is also possible that only one voice and video coding is selected.
  • the signaling messages of the first signaling protocol can be configured such that they contain information about speech codings that can be used in the telephone network. These speech codings are preferably also taken into account in the determination of the codings in step c). This ensures a smooth set-up even in the event that only pure voice telephony is selected on the IP network side.
  • one or more first specification messages are transmitted in the telephone network, a first specification message specifying the codings usable in the first subscriber.
  • These first specification messages are in particular in the prior art from the protocol H.245 for negotiating the coding as "terminal Capability Set "TCS
  • the codings specified in a first specification message are compared, in particular, with the codings defined in step c), if the comparison shows that no or only a partial match between the codings specified in the first specification message and the codings defined in step c), in a preferred embodiment a signaling message of the second signaling protocol is sent to the IP network, this signaling message at least partially containing the codifications specified in the first specification message can also be produced if the originally estimated codings do not match the actually usable codings.
  • signaling messages of the second signaling protocol are transmitted in the IP network, whereby these signaling messages specify the codings usable in the second subscriber and also encode the codings contained in these signaling messages with a second specification message in the structure of FIG Data connection in step e) are sent to the telephone network.
  • a signaling message of the second signaling protocol which specifies the codings usable in the second subscriber, is compared with a first specification message and the structure of the video telephone connection is aborted or switched to voice telephony, preferably with the aid of
  • SCUDIF "Service Change" procedure according to the 3GPP standard 3GPP TS 23.172, is prompted, if not at least one in accordance with the coding required in the signaling message and the first specification message for a video telephone connection.
  • the encodings used in the invention relate to voice and video encodings, both of which are used in video telephony. Possibly. however, the invention also encompasses other data encodings.
  • the second subscriber in particular in the case when a SIP protocol used does not support the preconditions extension, is instructed not to transmit user data until a predetermined process section of the setup of the data connection, in particular the structure of the transport connection in the telephone network, is completed. This avoids the so-called "clipping", i. the loss of voice and video sent by the called party before a continuous transport connection exists.
  • the invention further relates to a data network with a telephone network and an IP network based on the Internet Protocol, wherein the data network is designed such that the method according to the invention can be carried out.
  • the data network preferably has one or more interface nodes between the telephone network and the IP network, the interface nodes serving to carry out steps b) to d) of the method according to the invention.
  • the interface nodes include the well-known MGCF and IM-MGW nodes already mentioned in the description of the method of the invention.
  • FIG. 1 shows a schematic representation of an embodiment of a data network in which the method according to the invention can be used
  • FIGS. 2 to 16 are signaling diagrams which illustrate the signaling curve of the messages in the protocols used for different scenarios in the invention.
  • the so-called "Circuit Switched Domain” network CS and the so-called “IP Multimedia Subsystem (IMS)” network for voice and video telephony is known. It is necessary to ensure interworking of the relevant services of these networks, ie to connect the services by means of a suitable conversion of the signaling used and the transport format of the data used, between the IMS and the CS domain in addition to the 3GPP access networks Global System for Mobile Communications (GSM) and Universal Mobile Telecommunications System (UMTS) also used for other access networks, such as Wireless Local Area Network (WLAN) and Digital Subscriber Line (DSL) In these scenarios in particular, voice and video telephony can first be expected via the IMS.
  • GSM Global System for Mobile Communications
  • UMTS Universal Mobile Telecommunications System
  • WLAN Wireless Local Area Network
  • DSL Digital Subscriber Line
  • Video telephony can also be used in public telephones. fonnetz, ie a so-called "Public Switched Telephone Network (PSTN)" are used, where usually the same protocols are used for transport and signaling as in the 3GPP-CS domain.Also, a PSTN network is an interworking towards the IMS required.
  • PSTN Public Switched Telephone Network
  • the present invention relates to the corresponding interworking for video telephony.
  • a need for this is foreseeable since video telephony is becoming increasingly important both in the 3GPP-CS domain and in IMS, in particular for access networks such as WLAN or DSL or for emerging network access options (eg Worldwide Interoperability for Microwave Access (WiMAX )).
  • WiMAX Worldwide Interoperability for Microwave Access
  • the interworking between an IMS network and a CS network ie a PSTN or a 3GPP CS domain, is specified as of 3GPP Release 6 only for pure voice telephony in 3GPP TS 29.163.
  • MGCF Media Gateway Control Function
  • IM-MGW Internet Multimedia Media Gateway
  • Bearer Independent Call Control BICC
  • ISUP ISDN User Part
  • TDM Time Division Multiplex
  • IP Internet Protocol
  • Transfer Mode ATM.
  • the negotiation of whether pure voice telephony or video telephony is used can be carried out for ISUP during the call-control signaling to set up the call by means of the so-called ISUP "UDI fallback" procedure.
  • this negotiation can be carried out using the 3GPP TS 23,172 standardized “Service Change and UDI Fallback” (SCUDIF), which also allows a switch between voice telephony and video telephony during the call, both "UDI Fallback" and SCUDIF use out-of-band signaling.
  • SCUDIF Service Change and UDI Fallback
  • ISUP and BICC it is possible for ISUP and BICC not to use the procedures mentioned, and to call set-up (also referred to as call control) to try only for video telephony, and in the event that video telephony is not supported to cancel the call setup.
  • call set-up also referred to as call control
  • the negotiation of the voice and video codecs used for video telephony is carried out "in-band" after videotelephony has already been selected and a corresponding transport connection (“bearer") has been set up.
  • the CS network uses a so-called BS30 data connection with 64 kbytes / s bandwidth.
  • BS30 data connection with 64 kbytes / s bandwidth.
  • ITU-T standardized protocol suite H.324 is used, whereby in the 3GPP CS domain the adapted variant for mobile communication
  • H.324M is selected.
  • the configuration of the in-band multimedia connection is negotiated via the H.245 protocol standardized by the ITU-T, in particular the video codec and voice codec used and the details of the respective codec configuration. Speech and video are multiplexed into the same transport connection using the H.223 protocol.
  • TS describes the 3GPP CS domain 26.110 the use of the protocol suite H.245 on, in particular, the so-called H.324M configuration is selected.
  • TCS Terminal Capability Set
  • H.245 signaling. From then on, either with MSD or without, the terminal or IM-MGW is ready to open "logical channels" to allow the exchange of voice and / or video payload data. at Creating a bidirectional "logical channel” defines the channel number and the final media capabilities to be used. 6. Definition of multiplex properties using H.245.
  • the negotiation for video telephony takes place "out-of-band" with the aid of the so-called “Session Description Protocol” (SDP), IETF RFC 2327, which uses the so-called “Session Initiation Protocol” (SIP), IETF RFC 3261, is transported.
  • SDP Session Description Protocol
  • IP Session Initiation Protocol
  • IETF RFC 3261 the negotiation whether voice telephony or video telephony is used is connected with the negotiation of the used codecs, and takes place before or during the construction of the bearer.
  • SDP Session Description Protocol
  • SIP Session Initiation Protocol
  • the respondent Upon receiving this message, the respondent will send an SDP "Answer" message containing those codecs from the list that he also wants to support and use, and the respondent may not specify any codecs that were not in the SDP "offer" list.
  • voice and video use two separate transport connections ("bearers"), each of which uses the so-called “Real Time Transport Protocol” (RTP), IETF RFC 3550.
  • RTP Real Time Transport Protocol
  • IETF RFC 3550 IETF RFC 3550.
  • 3GPP IMS which uses a General Packet Radio Service (GPRS) access network
  • 3GPRS 26.235 describes the codecs to be used for video telephony.
  • CS network in particular 3GPP CS domain: Call Control BICC or ISUP.
  • Multimedia Protocol Suite H.324M (H.324 Annex C): Codec Negotiation: H.245 in-band negotiation over the built-up CS bearer with 64 kbps video codec: support required by H.263
  • MP4V-ES simple video profile level 0
  • Transport multiplexing voice and video into a bearer according to H.223 Annex A + B
  • IMS Codecs for GPRS access network
  • Call Control SIP
  • Codec negotiation Before setting up the bearer out-of-band using SDP, which is transported in SIP.
  • Video codec Required support of H.263, H.264 optional, MP4V-ES (simple video profile level 0) optional,
  • Nb-AMR + WB-AMR IETF RFC 3267
  • RTP Real Time Control Protocol
  • codecs specified here can also be supported by the terminals, in particular if the CS terminals are located in the PSTN or the IMS terminals do not use GPRS as the access network.
  • Figure 1 shows a typical Netzwerkkofiguration, as can be used in the embodiment of the invention described below.
  • the CS domain is using a "Media Gateway Control Function” (MGCF) and an IMS Media Gateway (IM-MGW) connected to the IMS.
  • MGCF Media Gateway Control Function
  • IM-MGW IMS Media Gateway
  • the MGCF controls the IMS Media Gateway via the so-called "Mn” interface.
  • MSC Mobile Switching Center
  • the CS domain has so-called “Mobile Switching Center” (MSC) servers in the core network, which communicate with each other and with the MGCF via BICC signaling communicate. They each control CS-MGWs.
  • the CS-MGWs are interconnected with each other and with the IM-MGW via the so-called "Nb" interface
  • the so-called "BS30" data transport service (“bearer service")
  • the MGCF uses the SIP call control protocol to communicate with so-called "call session control functions” (CSCF), which control the signaling via the radio access network, for example a UTRAN Gateway GPRS Support node “(GGSN) and a radio access network, for example a so-called UTRAN, to the mobile terminal MS2 Passing data from the IMS Media Gateway via the Mb interface to GGSN, which also passes this data via the radio access network UTRAN to MS2 - enough.
  • CSCF call session control functions
  • the line L1 which extends to the MGCF via the two MSC servers, thus denotes the BlCC signaling.
  • Line L2 which extends from the MGCF via the CSCF to the GGSN and from there to the UTRAN on the IMS side, denotes the SIP signaling.
  • the line L3 extending from the CS-side interface UTRAN via the two CS-MGWs and IM-MGW denotes the combined voice / video stream.
  • the line L5 extending from the IM-MGW via the GGSN to the UTRAN on the IMS side relates to the transport of the video stream in the IMS network and the line L6, which also extends from IM-MGW via the GGSN to the UTRAN on the IMS side IMS page relates to the voice stream transported in the IMS network.
  • the MGCF In the case of a call setup on the part of the CS network in the direction of the IMS, which is referred to below as "IMS terminating" (IMS-T) call setup, the MGCF first receives ISUP or BICC signaling, from which it can recognize or assume that Video telephony is desired, but not which voice and video codecs are used.
  • IMS terminating IMS-T
  • the MGCF In the case of a call set up by the IMS in the direction of the CS network, which is referred to as "IMS originating" (IMS-O) call setup hereinafter, the MGCF first receives SIP signaling, from which it can recognize or suspect that video telephony is desired, as well as which codecs are supported on the side of the IMS.
  • IMS-O IMS originating
  • the MGCF for signaling in the direction of the IMS makes information about the codecs supported on the CS side before receiving this information from the H.324 / M connection. This information is often only available on the CS side after the out-of-band call-control signaling for call setup has already been completed, for example if the transport connection is switched through at this time. In many networks, data sent in the direction of the call setup is blocked in the transport connection, so-called "forward early media", up to this point in time.
  • the multimedia interworking node (MIK) in the SIP codec negotiation initially only provides an estimate of the codecs supported on the CS side during call setup.
  • the MIK takes into account the CS network to which it is connected when selecting the codecs.
  • the MGCF preferably uses the codecs specified in 3GPP TS 26.110. In a landline, other codecs may prevail.
  • the MIK takes into account the network in which the CS-side caller is located.
  • the MIK uses the callee's phone number to determine which network the callee is in to select probable codecs for that network.
  • the MIK uses the caller's telephone number to determine which network the caller is in to select probable codecs for that network.
  • the selection of codecs can be optimized by evaluating statistics or administrative settings by the MIK operator.
  • the MIK selects only one voice codec and one video codec, which is most likely also supported by the terminal in the IMS, for example the H.263 and the AMR codec.
  • This embodiment may be sufficient because, according to 3GPP TS 26.235 and TS 26.110, the same voice and video codecs must be supported in the CS domain and the IMS.
  • the embodiment is advantageous in order to simplify the subsequent signaling processes.
  • SCUDIF is used in the IMS-T trap
  • MIK initial call message
  • the MIK subsequently receives a so-called "Terminal Capability Set” message in the H.245 in-band negotiation, which contains information on the capabilities of the terminal on the part of the CS network, including the supported video codecs and voice codecs with details
  • the MIK compares the codecs contained therein with the previously estimated codecs signaled in the IMS If the codecs differ from each other, it may be advantageous or necessary that the MIK at this time he - sends an SDP "offer" to the IMS, passing on the codecs specified in the "Terminal Capability Set” message
  • the SDP "offer” can, for example, be transported by means of a SIP "re-INVITE" or "UPDATE” message.
  • a renewed SDP offer is necessary if the previously estimated codecs do not match with at least one speech codec and video codec with the codecs received in the "Terminal Capability Set” message.
  • the MIK has already received information on the IMS side supported codecs in the SIP "INVITE" message, if these codecs do not match in at least one voice codec and video codec each with the codecs received in the "Terminal Capability Set” message , it is advantageous if the MIK abolishes the H.223 connection and continues the call setup as voice telephony, for example by using SCUDIF or by first completing the call setup on the CS side and then restarting it for voice telephony. It may also be the case that the MIK in the previously sent by him SDP "answer" IMS-side supported codec has excluded, which he now but due to the in the "Terminal Capability Set” message to select received codecs.
  • the MIK sends the estimated codecs in an SDP "offer” and, from the received SDP "answer", has only the information as to which of the codecs it initially estimates on the IMS side are supported. So it makes sense to use a new "SDP offer" to query whether in the first SDP "offer” codecs not included in the IMS are supported.
  • the MIK forwards the information received by the IMS side about the codec in the H.245 inband negotiation by means of a "terminal capacity set” message, preferably the MIK waits to send this message until he has received the SDP message with details of the codecs from the IMS side, and it is particularly advantageous if the MIK waits for a certain time to receive a "Terminal Capability Set” before sending it Message itself sends, as described above, because of the codec information contained in the received "Terminal Capability Set” message, the MIK may decide to send an SDP "offer" on the IMS side and answer in the following SDP "answer "contained information contained in the sent by him Terminal Capability Set” message.
  • the MIK does not receive a "Terminal Capability Set" message from the other side for a certain time, for example, another one is behind the CS network
  • MIK is at a transition to an IMS network, it may be necessary for the MIK to send itself a "Terminal Capability Set” message prior to receiving a "Terminal Capability Set” message.
  • MIK according to the invention indicates those codecs that were included in the last, sent on the IMS page or received SDP message. If, after sending a "Terminal Capability Set” message on the IMS side, the MIK again receives an SDP message that excludes codecs permitted in the first "Terminal Capability Set” message, MIK will send a new "Terminal Capability Set Message in which the corresponding codecs are removed.
  • the H.245 signaling is used to select separate logical channels of the H.223 protocol for transporting voice and video If several voice codecs or video ocodecs are still selected on the IMS side at this time, the MIK according to the invention again sends an "SDP offer" on the IMS side in which it specifies exactly the codecs selected by means of H.245 to prevent the IMS terminal from using a codec that the MIK can not pass on.
  • the SDP "offer” can be transported, for example, by means of a SIP "re-INVITE” or "UPDATE" message.
  • the MIK uses the SIP "preconditions" extension to indicate that local so-called “QoS preconditions” exist, ie a connection to the transport connection is required before call setup can be completed.
  • the MIK according to the invention uses the SIP "preconditions" extension in order to indicate that local so-called “QoS preconditions” are fulfilled.
  • the MIK also signals on the IMS side that local so-called "QoS preconditions" are fulfilled if, after establishing the transport connection, no H.223 signaling is received for a certain time.
  • the MIK instructs the IMS-side terminal, as long as no media streams are available until the H.223 and H.245 negotiation within the CS-side transport connection has been completed.
  • the IMS terminal can display this information to its user, thereby also avoiding "clipping."
  • the MIK uses according to the invention the so-called “hold” procedure described in RFC 3264, for example the SDP "inactive" attribute logic H.223 channels for voice and video the CS-side structure of the transport connection is completed, the MIK then uses according to the invention the "Resume” procedure according to RFC 3284, to allow the IMS-side terminal to send media streams.
  • the MIK preferably offers besides a voice and a video codec on the IMS side also other candidate data codecs, for example the so-called “Clearmode” codec, IETF RFC 4040, or a FAX codec, for example, in the format of RFC 3362.
  • the "Clearmode” codec makes it possible to pass on a BS30 data service transparently through the IMS Therefore, the "clearmode” codec is also advantageous for facilitating interworking in the event that call setup is forwarded from the IMS to another MIK
  • the MIK first configures the CS-side transport connection for the BS30 service only , and does not yet turn off the data connection, as soon as the MIK receives signaling from the IMS side regarding the selected codecs, the MIK can detect if it is video telephony and in this case starts the H.223 in-band negotiation
  • the MIK already starts inband negotiation using H.223 and H.245 upon receipt of the IAM message, if the MIK receives signaling from the IMS side regarding the selected codecs, and recognizes that there is no video calling MIK ends the attempt of H.223 and H.245 negotiation.
  • FIG. 2 shows, with the aid of the signaling curve, the principle of interworking between the H.245 signaling and on the CS side and the SIP / SDP Call Control on the IMS side by a Multimedia Interworking Node (MIK), which for example consists of MGCF and IM -MGW, in the case of a call setup on the part of the CS network in the direction of the IMS, which is referred to below as "IMS terminating" (IMS-T) call setup Only messages directly relevant to the invention are shown.
  • MIK Multimedia Interworking Node
  • the MIK receives a so-called BICC or ISUP "IAM" message from the CS side
  • the MIK recognizes that video telephony is desired or may be desired due to the parameters contained in it
  • the IAM message does not contain information about the Video telephony to be used voice and video codecs.
  • the MIK converts the IAM message into a SIP "INVITE" message
  • the MIK in the SDP "offer" contains information about the voice (in the example AMR) and video codecs (in the example H.263 and MP4V-ES), which are likely to be supported on the CS side for the H.324 video telephony.
  • the MIK can also take into account which codecs the operator of the IMS network desires, for example, in order not to need too much bandwidth for the transmission at the air interface.
  • the MIK selects only one voice and one video codec, which is most likely also supported by the terminal in the IMS, for example the H.263 and the AMR codec.
  • steps 7, 8, 11 and 12 can be avoided if the selected codecs are actually supported on the CS side and in the IMS.
  • the MIK does not know with sufficient certainty that a particular voice codec and video codec on the CS side and IMS are supported, it makes sense to include all possible codecs in order to avoid messages 7 and 8 with a certain probability ,
  • the MIK also includes the "clearmode" codec, RFC 4040, to facilitate interworking in case the connection is relayed from the IMS to another MIK. pass on a BS30 data service transparently through the IMS.
  • the transport connection is set up on the CS network side. Then the inbound negotiation of the H.223 multiplexer level takes place through the transport connection and a logical H.223 channel for exchanging H.245 messages is opened.
  • the MIK expects an H.245 "Terminal Capability Set” message in the transport connection. 5. Only if it does not receive this message in a certain time, for example because there is a further MIK on the CS side According to the invention, the MIK has an H.245 "Terminal Capability Set” message in which it indicates the voice codecs and video codecs sent in message 2 or, if message 6 has already arrived, 5. The MIK contains an H in the transport connection .245
  • Terminal Capability Set contains information on the capabilities of the terminal on the CS network side, including the supported video codecs (H.263 and H.261 in the example) and voice codecs (G.711 and AMR in the example) ), specifying which options each codec supports, and which codecs can be supported in parallel.
  • the MIK receives on the part of the IMS a SIP message containing the SDP answer.
  • the SDP answer contains those codecs from the list offered in message 2, which are supported and desired by the terminal on the IMS side, in the example AMR as voice codec and H.263 and MP4V-ES as video codecs, but not the clearmode codec.
  • the MIK compares the codecs received in messages 5 and 6. If the codecs match, or theirs
  • Intersection contains at least in each case at least one acceptable for the operator voice and video codec, the MIK proceeds directly to step 9.
  • the MIK may decide that it is desirable to check whether these additional codecs be supported on the part of the IMS, for example because they offer a higher quality or are preferred by the operator of MIK, or because the previously determined
  • Intersection contains no voice and / or video codec.
  • the MIK decides to check whether the H.261 video codec is supported on the IMS side.
  • the MIK according to the invention sends a suitable SIP message, for example a re-INVITE or an UPDATE message, with an SDP offer containing the codecs the intersection and additionally contains the codecs to be checked.
  • the SDP "answer" contains those codecs from the list offered in message 6, which supports that from the terminal on the IMS side and, in the example, AMR as voice codec and H.263 and H.261 as video codecs.
  • Steps 7 and 8 were skipped to distinguish in message 6 received codecs, the MIK according to the invention extends in accordance with the message 8, or if steps 7 and 8 were skipped, received in message 6 voice and video codecs and the details of the codec configuration via an H.245 "Terminal Capability Set" message.
  • step 11 it is advantageous to carry out step 11 in parallel to step 10.
  • Speech codec and a video codec selected from the intersection of codecs transmitted in messages 5 and 4 and 9, respectively.
  • the MIK according to the invention sends an appropriate SIP message, for example a re-INVITE or an UPDATE message, with an SDP "offer", where MIK specifies the voice and video codec selected in step 10.
  • MIK If the MIK has sent message 11, it receives a SIP message containing the associated SDP "answer".
  • FIG. 3 illustrates, with the aid of the signaling curve, the principle of interworking between the H.245 signaling and on the CS side and the SIP / SDP Call Control on the IMS side by a Multimedia Interworking Node (MIK) which, for example, consists of MGCF and IM -MGW, in the case of a call establishment on the part of the IMS in the direction of the CS network, which is referred to as "IMS originating" (IMS-O) call setup in the following: Only messages directly relevant to the invention are shown ,
  • MIK Multimedia Interworking Node
  • the MIK receives a SIP "INVITE" message with an SDP "offer" which contains information about the speech codecs (in the example AMR) and video codecs (in the example H.263 and MP4V-ES) that the terminal on the IMS Supported and wants to use for this call.
  • the MIK recognizes the combination of video codecs and voice codecs that video telephony is desired.
  • the MIK sends a so-called BICC or ISUP "IAM" to the CS side, indicating that video telephony is desired, but the IAM message does not contain information about the voice and video to be used for video telephony Codecs.
  • the MIK sends a SIP message on the IMS side containing the SDP answer. This is in many cases required due to specific rules for transporting SDP "offer” and "answer” in SIP in RFC 3261 even before the establishment of the transport connection on the CS side in step 4 so as not to delay the connection establishment, and to enable meaningful interworking of later SIP and ISUP / BICC messages during call setup.
  • the MIK according to the invention adds those codecs from the Looks at 1 offered list, which is probably supported on the CS side for the H.324 / M video telephony (in the example the H.263 video codec and the AMR voice codec).
  • the MIK can also take into account which codecs the operator of the IMS network desires, for example, in order not to need too much bandwidth for the transmission at the air interface.
  • the MIK selects only one voice and one video codec at a time, for example the H.263 and the AMR codec. Thus, steps 7 and 8 can be avoided if the selected codecs are actually supported on the CS side. If the MIK has already received message 6 before sending message 3, the MIK selects from the intersection of the codecs in message 1 and 6 each a voice codec and video codec, and inserts them in message 3.
  • the transport connection is set up on the CS network side. Then the inbound negotiation of the H.223 multiplexer level takes place through the transport connection and a logical H.223 channel for exchanging H.245 messages is opened.
  • the MIK expects an H.245 "Terminal Capability Set” message 6 in the transport connection. Only if it does not receive this message within a certain time, for example because another MIK is located on the CS side, does the MIK according to the invention send one H.245 "Terminal Capability Set", in which it specifies the voice codecs and video codecs sent in message 3. 6.
  • the MIK contains a H.245 in the transport connection
  • Terminal Capability Set contains information on the capabilities of the terminal on the CS network side, including the supported video codecs (MP4V-ES and H.261 in the example) and voice codecs (G.711 and AMR in the example)
  • the MIK compares the codecs received in message 6 with the codecs sent in message 1. The MIK selects from the intersection of the codecs in messages 6 and 1 each a voice and video codec. According to the invention, the MIK transmits these codecs in an SDP "offer" message within a suitable SIP message, for example a re-INVITE or an UPDATE message.
  • the MIK according to the invention reaches the voice and video codecs sent in message 7, or if steps 7 and 8 were skipped, and the details of the codec configuration by means of an H .245 "Terminal Capability Set" message If message 5 and message 7 were sent and the codecs contained therein differ, the MIK will also send an H.245 "Terminal Capability Set” message indicating the codecs contained in message 7 ,
  • H.245 master-slave-determination
  • the "Master-Slave-Determination” messages may also already have been sent together with the "Terminal Capability Set” messages 6 and 5 or 9.
  • the "master-slave-determination” is only relevant for resolving a resource conflict and is therefore not further considered in this invention.
  • FIG. 4 illustrates the interworking between the BICC signaling on the CS side and the SIP / SDP Call Control on the IMS side by a multimedia interworking node (MIK) in the case of an IMS terminating call setup with the aid of the signaling curve may for example consist of MGCF and IM-MGW.
  • the CS network uses "Service Change and UDI Fallback" (SCUDIF) according to 3GPP TS 23.172 It is assumed that the CS network is configured to support so called “forward early media", i. Additional payloads sent by the caller before the BICC ,, ANM "message.
  • SCUDIF Service Change and UDI Fallback
  • the SIP Preconditions "(IETF RFC 3312),” Update "
  • the MIK receives a so-called "IAM" message from the CS side
  • SCUDIF signaling it contains a codec list indicating the codecs to be used for voice telephony and a so-called "MuMe" dummy codec as a placeholder for video telephony. which merely indicates that video calling is supported according to H.324M, but not which voice codecs and videoodecs are supported in this case.
  • the MuME codec is included as the first codec in the codec list, it is preferred on the CS side, i. Video telephony is desired.
  • the MIK converts the IAM message into a SIP "INVITE" message
  • MIK in the SDP "offer" contains information about the speech codecs (in the example AMR) and video codecs (in the example H.263 and MP4V-ES ), which are probably supported on the CS side for the H.324 video telephony, as already described for step 2 in FIG.
  • the MIK should specify according to the invention as a less preferred alternative, the voice codecs contained in message 1.
  • the MIK uses the SIP "precon- ditions" extension to indicate that it is necessary to set up the transport connection locally before call setup can be completed, which is advantageous for avoiding so-called "clipping", ie a loss of voice or video sent by the called party before a continuous transport connection exists.
  • the MIK receives from the IMS side a SIP "183" message containing the SDP "answer".
  • the SDP answer contains the codecs from the list offered in message 2, which are supported and desired by the terminal on the IMS side.
  • the MIK recognizes that video codec (s) are included, that video telephony is desired, and proceeds as described in detail for message 5 in Figure 2.
  • the MIK sends a BICC "APM" message in which the so-called “available codec list” of the MuMe codec and according to the invention those speech codecs are contained, which were contained both in message 1 as in message 4.
  • the "MuMe” codec is specified as "selected codec".
  • the MIK removes voice codecs from message 4 which are only suitable for video telephony by means of H.324M in order to comply with the rules of the out-of-band BICC codec negotiation.
  • SIP "100rel" extension the MIK confirms the receipt of the 183 message with a SIP "PRACK" message.
  • the transport connection is established on the part of the CS network.
  • the MIK receives a so-called BICC "COT" message.
  • the in-band negotiation of the H.223 multiplexer level as well as the H.245 negotiation described in FIG. 2 takes place.
  • SDP "offer” and "answer” come. It is transported by means of a SIP "UPDATE” message (IETF RFC 3311) 13.
  • the MIK Upon completion of the H.245 inband negotiation, the MIK, according to the invention, signals with the aid of the SIP "Preconditions" extension that the local structure of the transport connection has been completed , The message can be linked to message 11 of Figure 2, if necessary.
  • a SIP "UPDATE” message is used to transport the corresponding SDP 14. The SIP "UPDATE” message is acknowledged.
  • the called party answers the call.
  • the MIK receives a SIP "200 OK (INVITE)" message.
  • FIG. 5 illustrates, with the aid of the signaling curve, the interworking between the BICC signaling on the CS side and the SIP / SDP Call Control on the IMS side by a multimedia interworking node (MIK) in the case of an IMS terminating call setup may for example consist of MGCF and IM-MGW.
  • the CS network uses "Service Change and UDI Fallback" (SCUDIF) according to 3GPP TS 23.172
  • SCUDIF Service Change and UDI Fallback
  • the IMS uses the SIP "Preconditions" (IETF RFC 3312), “Update” (IETF RFC 3311) and “100rel” ( IETF RFC 3262) extensions. It is assumed that the IMS terminal only supports voice telephony.
  • the signaling steps are as follows: 1. to 3. as described in FIG.
  • the MIK receives from the IMS side a SIP "183" message containing the SDP "answer".
  • the SDP answer contains the codecs from the list offered in message 2, which the terminal supports and desires on the part of the IMS.
  • the MIK recognizes that voice telephony is desired because only voice codec (s) are included.
  • the MIK sends a BICC "APM" message, in the so-called “available codec list” according to the invention those
  • the MIK removes voice codecs from message 4 which are only suitable for video telephony by means of H.324M in order to comply with the rules of the out-of-band BICC codec negotiation.
  • FIG. 6 illustrates, with the aid of the signaling curve, the interworking between the BICC signaling on the CS side and the SIP / SDP call control on the IMS side by a multimedia interworking node (MIK) in the case of an IMS terminating call setup may for example consist of MGCF and IM-MGW.
  • MIK multimedia interworking node
  • the CS network uses "Service Change and UDI Fallback" (SCUDIF) according to 3GPP TS 23.172 It is assumed that the CS network is configured so that it does not support so called “forward early media", i.
  • the signaling steps are as follows: 1. to 9. As described in FIG. 10. If the MIK already knows by configuration that no forward early media is supported on the CS network side, it skips this step, otherwise it waits for some time to receive H.223 signaling in the transport connection It then determines according to the invention that no "forward early media" are supported, and proceeds as described below.
  • the MIK In order to continue the call setup, the MIK, according to the invention, signals with the aid of the "preconditions" extension that the local establishment of the transport connection has been completed, ie "clipping", ie a loss of voice or video sent by the called party Before a continuous transport connection is present, it is advantageous according to the invention if the MIK sets the media in the SDP as described in RFC 3264 to "hold", for example by providing it with the so-called "inactive” attribute.
  • a SIP "UPDATE” message is used to transport the corresponding SDP 12. The SIP "UPDATE” message is acknowledged.
  • a SIP ringing message is received.
  • the MIK receives a SIP "200 OK (INVITE)" message.
  • FIG. 7 illustrates the interworking between the BICC signaling and on the CS side and the SIP / SDP Call Control on the IMS side by a multimedia interworking node (MIK) in the case of an IMS terminating call setup with the aid of the signaling curve
  • MIK can consist of MGCF and IM-MGW.
  • the CS network uses "Service Change and UDI Fallback" (SCUDIF) in accordance with 3GPP TS 23.172, while the IMS adds the "Precon- nitions" (IETF RFC 3312) and “Update” (IETF RFC 3311) extensions not used, but the SIP "100rel” (IETF RFC 3262) extensions is used. It is assumed that the IMS terminal supports and accepts video telephony.
  • SCUDIF Service Change and UDI Fallback
  • the signaling steps are as follows: 1. As in FIG. 4.
  • the MIK converts the IAM message into a SIP "INVITE" message
  • MIK in the SDP "offer" contains information about the speech codecs (in the example AMR) and video codecs (in the example H.263 and MP4V-ES ), which are likely to be supported on the CS side for the H.324 video telephony, as already described for step 2 in FIG.
  • the MIK should also specify the voice codecs contained in message 1 as a less preferred alternative.
  • the MIK sets the media in the SDP as described in RFC 3264 on “hold", for example by providing them with the so-called “inactive” attribute. 3. to 10. As in FIG. 4.
  • MIK has set the media to "hold” in message 2
  • it will re-enable it after completing the H.245 in-band negotiation, as described in RFC 3264, for example by sending SDP without the "inactive" attribute.
  • the message can be linked to message 11 of Figure 2, if required.
  • a SIP "re-INVITE” message is used to transport the corresponding SDP 20.
  • the SIP "re-INVITE” message is acknowledged.
  • FIG. 8 illustrates the interworking between the BICC signaling on the CS side and the SIP / SDP Call Control on the side of the signaling path
  • the IMS through a Multimedia Interworking Node (MIK) in the case of an IMS terminating call setup.
  • the MIK may consist of MGCF and IM-MGW, for example.
  • the CS network uses "Service Change and UDI Fallback" (SCUDIF) in accordance with 3GPP TS 23.172
  • SCUDIF Service Change and UDI Fallback
  • the IMS uses the SIP "Precon- ditions" (IETF RFC 3312), “Update” (IETF RFC 3311) and “100rel "(IETF RFC 3262) extensions not used. It is assumed that the IMS terminal supports and accepts video telephony.
  • the signaling steps are as follows: 1. to 3. As in FIG. 7. 4.
  • the MIK sends a BICC "APM" message, at which time the MIK has no knowledge of whether video calling is accepted on the IMS side and which codecs are supported.
  • the MIK supposes that video telephony accepts selects and selects voice codecs from the list contained in message 1 which are likely to be supported by the IMS, for example the "AMR" codec.
  • the MIK inserts these voice codecs and the "mu-me” codec in the so-called “available codec list”.
  • the "MuMe" codec is specified as "selected codec".
  • the MIK receives on the IMS side a SIP "200 OK (INVITE)" message containing the SDP "answer".
  • the SDP answer contains the codecs from the list offered in message 2, which are available from the terminal on the
  • IMS are supported and desired.
  • the MIK recognizes that video codec (s) are included, that video telephony is desired, and proceeds as described in detail for message 5 in FIG. 11. to 18. Like messages 14 to 21 in FIG. 7.
  • FIG. 9 illustrates the interworking between the BICC signaling on the CS side and the SIP / SDP Call Control on the IMS side by a multimedia interworking node (MIK) in the case of an IMS terminating call setup with the aid of the signaling curve may for example consist of MGCF and IM-MGW.
  • the CS network uses "Service Change and UDI Fallback" (SCUDIF) in accordance with 3GPP TS 23.172
  • SCUDIF Service Change and UDI Fallback
  • the IMS uses the SIP "Precon- ditions" (IETF RFC 3312), “Update” (IETF RFC 3311) and
  • the signaling steps are as follows: 1. to 9. As in FIG. 9. 10.
  • the MIK receives on the IMS side a SIP "200 OK (INVITE)" message containing the SDP "answer".
  • the SDP answer contains the codecs from the list offered in message 2, which are supported and desired by the terminal on the IMS side.
  • the MIK recognizes that no video codec (s), but voice codecs are included that voice telephony is desired.
  • the MIK aborts the H.223 and H.245 negotiations.
  • MIK has set the media in message 2 to "hold”, it will reactivate them after completing the H.245 in-band negotiation, as described in RFC 3264 for example by sending SDP without the "inactive" attribute.
  • a SIP "re-INVITE" message is used to transport the corresponding SDP.
  • the MIK uses the so-called BICC "Codec Modification" procedure to switch to voice telephony on the CS network side.
  • FIG. 10 illustrates the interworking between the ISUP signaling on the CS side and the SIP / SDP Call Control on the IMS side through a multimedia interworking node (MIK) in the case of an IMS terminating call setup with the aid of the signaling curve may for example consist of MGCF and IM-MGW.
  • MIK multimedia interworking node
  • the signaling steps are as follows: 1.
  • the MIK receives a so-called ISUP "IAM" message from the CS side and recognizes or suspects, due to the signaled parameters, for example due to the value "UDI” in the parameter TMR and appropriate values in the parameter "USI", that video telephony he wishes.
  • the MIK converts the IAM message into a SIP "INVITE" message
  • MIK provides information about the voice (in the example AMR) and video codecs (in the example H.263 and MP4V). ES), which are likely to be supported on the CS side for the H.324 video telephony, as already described for step 2 in FIG.
  • the MIK uses the SIP "Preconditions" extension to indicate that locally a transport connection establishment is required before call setup can be completed, which is beneficial to avoid so-called "clipping", ie a loss of voice or video that is sent by the called party before a continuous transport connection exists.
  • the MIK may additionally insert suitable codecs for other data services, for example a FAX codec "t38" according to RFC 3362. If the called terminal has only one specific If the data service supports it, it will select the appropriate data service and the caller may also have known that the terminal only supports that particular data service and will send that data service accordingly.
  • suitable codecs for example a FAX codec "t38" according to RFC 3362.
  • FIG. 11 illustrates, with the aid of the signaling curve, the interworking between the SIP signaling on the CS side and the SIP / SDP Call Control on the IMS side by a multimedia interworking node (MIK) in the case of an IMS terminating call setup may for example consist of MGCF and IM-MGW.
  • MIK multimedia interworking node
  • the SIP "Preconditions" (IETF RFC 3312), “Update” (IETF RFC 3311) and “100rel” (IETF RFC 3262) extensions are not used and it is assumed that the IMS terminal supports and accepts video telephony.
  • FIG. 12 illustrates, with the aid of the signaling curve, the interworking between the BICC signaling on the CS side and the SIP / SDP call control on the IMS side by a multimedia interworking node (MIK) in the case of an IMS-originating call setup may for example consist of MGCF and IM-MGW.
  • the CS network uses "Service Change and UDI Fallback" (SCUDIF) in accordance with 3GPP TS 23.172
  • SCUDIF Service Change and UDI Fallback
  • the IMS uses the SIP "Precon- ditions" (IETF RFC 3312), “Update” (IETF RFC 3311) and “100rel "(IETF RFC 3262) Extensions used. It is assumed that the CS terminal supports and accepts video telephony.
  • the MIK receives a so-called SIP "INVITE" message containing an SDP "offer".
  • SDP offer includes codecs that are supported by the terminal on the side of the IMS and that are desired for the call.
  • the MIK recognizes that video codec (s) are included, that video telephony is desired, and proceeds as described in detail for message 1 in FIG.
  • the MIK sends a so-called "IAM" message to the CS side
  • SCUDIF signaling it contains a codec list which specifies codecs to be used for voice telephony and a so-called "MuMe" dummy codec as a placeholder for video telephony. which only indicates that video telephony according to H.324M is supported, but not which voice codecs and video codecs are supported in this case.
  • voice codecs the MIK preferably selects the codecs contained in message 1.
  • the MIK inserts the MuME codec as the first codec in the codec list to express that video telephony is desired. 3.
  • a SIP "Trying" message acknowledges the INVITE message.
  • the MIK receives a BICC "APM” message in which the "MuMe” codec is specified as the so-called “selected codec", from which the MIK recognizes that the CS terminal also supports video telephony in the "available codec list "The MuMe codec includes voice codecs that support the CS terminal for voice telephony.
  • the transport connection is established on the part of the CS network. 6.
  • the MIK sends to the IMS a SIP "183" message containing the SDP "answer” as described in detail for message 3 in FIG.
  • the MIK receives a SIP "PRACK” message as confirmation of the 183 message. 8. The SIP "PRACK” message is confirmed.
  • the MIC receives a SIP "UPDATE” message indicating with the aid of the SIP "Preconditions” extension that the IMS terminal has completed the local establishment of the transport connection. 10. If the so-called "Continuity Check” procedure is used on the CS network side, the MIK sends a so-called BICC "COT" message.
  • the called party answers the call.
  • the MIK receives an "ANM" message message.
  • FIG. 13 illustrates the interworking between the BICC signaling on the CS side and the SIP / SDP Call Control on the IMS side by means of the signaling curve, by means of a multimedia interworking node (MIK) in the case of an IMS originating call setup may for example consist of MGCF and IM-MGW.
  • the CS network uses "Service Change and UDI Fallback" (SCUDIF) in accordance with 3GPP TS 23.172
  • SCUDIF Service Change and UDI Fallback
  • the IMS uses the SIP "Precon- ditions" (IETF RFC 3312), “Update” (IETF RFC 3311) and
  • the MIK receives a BICC "APM" message containing only voice codecs as the "avaible codec list”. From this MIK recognizes that the CS terminal only supports voice telephony.
  • the transport connection is established on the part of the CS network.
  • the MIK sends on the IMS side a SIP "183" message containing the SDP "answer" for message 1. In it, the MIK specifies only voice codecs.
  • FIG. 14 illustrates, with the aid of the signaling curve, the interworking between the BICC signaling on the CS side and the SIP / SDP call control on the IMS side by a multimedia interworking node (MIK) in the case of an IMS-originating call setup may for example consist of MGCF and IM-MGW.
  • MIK multimedia interworking node
  • the CS network uses "Service Change and UDI Fallback" (SCUDIF) in accordance with 3GPP TS 23.172
  • SCUDIF Service Change and UDI Fallback
  • the IMS uses the SIP "Precon- ditions" (IETF RFC 3312), “Update” (IETF RFC 3311) and
  • the information is forwarded as a SIP "ringing" message.
  • the called party answers the call.
  • the MIK receives an "ANM" message.
  • the MIK sends on the IMS side a SIP "200 OK (INVITE)" message containing the SDP "answer” as described in detail for message 3 in FIG.
  • FIG. 15 illustrates the interworking between the ISUP signaling on the CS side and the SIP / SDP Call Control on the IMS side by means of the signaling curve, using a multimedia interworking node (MIK) in the case of an IMS-originating call setup may for example consist of MGCF and IM-MGW.
  • MIK multimedia interworking node
  • the IMS uses the SIP "preconditions" (IETF RFC 3312), "update” (IETF RFC 3311) and “lOOrel” (IETF RFC 3262) extensions, it is assumed that the CS terminal supports and accepts video telephony ,
  • the MIK sends a so-called "IAM" message to the CS side
  • the MIK expresses that video telephony is desired, for example by selecting the value "UDI” for parameter TMR and appropriate values in the parameter "USI".
  • FIG. 16 illustrates the interworking between the ISUP signaling on the CS side and the SIP / SDP Call Control on the IMS side through a multimedia interworking node (MIK) in the case of an IMS-originating call setup with the aid of the signaling process consisting of MGCF and IM-MGW.
  • MIK multimedia interworking node
  • the MIK sends a so-called "IAM" message to the CS side
  • the MIK expresses that video telephony is desired, for example by selecting value "UDI” for parameter TMR and appropriate values in parameter "USI”. 3.
  • UMI User Data Management
  • USI User Data Management

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé pour établir une liaison visiophonique dans un réseau de données comprenant un réseau téléphonique et un réseau IP basé sur le protocole Internet. L'expression "liaison visiophonique" est à prendre, ici et ci-après, au sens général et comprend, outre la visiophonie pure, la téléphonie multimédia.
EP06793368A 2005-10-21 2006-09-08 Procede pour etablir une liaison visiophonique et/ou une liaison telephonique multimedia dans un reseau de donnees Withdrawn EP1938551A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102005050586A DE102005050586B3 (de) 2005-10-21 2005-10-21 Verfahren zum Aufbau einer Videotelefonverbindung und/oder Multimediatelefonverbindung in einem Datennetz
PCT/EP2006/066185 WO2007045527A1 (fr) 2005-10-21 2006-09-08 Procede pour etablir une liaison visiophonique et/ou une liaison telephonique multimedia dans un reseau de donnees

Publications (1)

Publication Number Publication Date
EP1938551A1 true EP1938551A1 (fr) 2008-07-02

Family

ID=37085301

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06793368A Withdrawn EP1938551A1 (fr) 2005-10-21 2006-09-08 Procede pour etablir une liaison visiophonique et/ou une liaison telephonique multimedia dans un reseau de donnees

Country Status (7)

Country Link
US (1) US10075479B2 (fr)
EP (1) EP1938551A1 (fr)
JP (1) JP5237816B2 (fr)
KR (1) KR101422223B1 (fr)
CN (1) CN101292497A (fr)
DE (1) DE102005050586B3 (fr)
WO (1) WO2007045527A1 (fr)

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7953867B1 (en) 2006-11-08 2011-05-31 Cisco Technology, Inc. Session description protocol (SDP) capability negotiation
WO2008069723A2 (fr) * 2006-12-08 2008-06-12 Telefonaktiebolaget Lm Ericsson (Publ) Gestion de multimédia d'annonce dans un environnement de réseau de communications
KR100977812B1 (ko) * 2007-02-21 2010-08-25 (주) 콜게이트 단문메시지를 이용한 3세대 통신 서비스 제공 방법 및시스템
GB0715555D0 (en) * 2007-08-10 2007-09-19 Ericsson Telefon Ab L M Improvements in mobile telecommunication
EP2163068B1 (fr) * 2007-05-22 2016-02-03 Telefonaktiebolaget LM Ericsson (publ) Procédé, appareils et programme d'ordinateur pour configurer de façon dynamique une fonction de commande de session d'appel par mandataire du sous-système multimédia ip à partir d'un serveur de règles de commande de politique
CN101316435B (zh) * 2007-05-31 2012-08-08 华为技术有限公司 呼叫控制的方法和ims的电路交换控制装置及终端设备
US7788383B2 (en) * 2007-10-30 2010-08-31 Cisco Technology, Inc. Communicating a selection of a potential configuration
CN101453706B (zh) * 2007-12-04 2011-03-30 华为技术有限公司 一种多媒体呼叫建立方法、系统和装置
CN101471860B (zh) * 2007-12-27 2011-04-13 华为技术有限公司 一种软交换设备选择呼叫仲裁节点的方法、系统和设备
KR101571723B1 (ko) * 2008-09-02 2015-11-25 엘지전자 주식회사 단말기 및 그 제어 방법
CN101355608B (zh) * 2008-09-11 2011-05-25 中兴通讯股份有限公司 一种实现彩铃ip化的系统及方法
CN101997848B (zh) * 2009-08-14 2015-05-20 中兴通讯股份有限公司 应用服务器呼叫控制中呼叫继续的方法和装置
CN102045298B (zh) * 2009-10-17 2013-12-04 中兴通讯股份有限公司 一种ims媒体编解码器协商的方法和系统
CN101848481B (zh) * 2010-05-12 2012-08-22 杭州东信北邮信息技术有限公司 一种无接入网条件下的bicc业务测试系统和方法
TW201215214A (en) * 2010-07-06 2012-04-01 Interdigital Patent Holdings IP multimedia subsystem (IMS)-based pre-negotiation of video codec for video single radio video call continuity
US9401975B2 (en) 2010-11-10 2016-07-26 Panasonic Intellectual Property Corporation Of America Terminal and codec mode selection method
JP2012105211A (ja) * 2010-11-12 2012-05-31 Ntt Docomo Inc コアネットワークおよび通信システム
JP2012105210A (ja) * 2010-11-12 2012-05-31 Ntt Docomo Inc コアネットワークおよび通信システム
JP2012105212A (ja) * 2010-11-12 2012-05-31 Ntt Docomo Inc コアネットワークおよび通信システム
CN102065095A (zh) * 2010-12-31 2011-05-18 华为技术有限公司 一种建立主被叫间呼叫连接的方法及装置
EP3139696B1 (fr) 2011-06-09 2020-05-20 Panasonic Intellectual Property Corporation of America Terminal de communication et procédé de communication
GB2494745B (en) * 2011-07-08 2015-11-11 Avaya Inc Negotiate multi-stream continuous presence
CA2842886C (fr) 2011-08-17 2020-08-25 Telefonaktiebolaget L M Ericsson (Publ) Mecanisme de signalisation dynamique de capacites de codeur
CN102984493B (zh) * 2012-11-21 2016-03-02 华为终端有限公司 视频数据传输的方法、装置及通信设备
CN103856461A (zh) * 2012-12-04 2014-06-11 联芯科技有限公司 Ims业务实时媒体流的协商式调节方法
EP3145165B1 (fr) * 2014-05-13 2019-10-16 Panasonic Intellectual Property Corporation of America Noeud de réseau et procédé de traitement de signalisation
US10148703B2 (en) 2014-10-09 2018-12-04 T-Mobile Usa, Inc. Service capabilities in heterogeneous network
JP6636157B2 (ja) 2016-07-14 2020-01-29 日本電信電話株式会社 通信方法及び通信プログラム
US11799922B2 (en) * 2016-12-21 2023-10-24 T-Mobile Usa, Inc. Network core facilitating terminal interoperation
US10771509B2 (en) 2017-03-31 2020-09-08 T-Mobile Usa, Inc. Terminal interoperation using called-terminal functional characteristics
FR3073115A1 (fr) * 2017-10-27 2019-05-03 Orange Procede et entite de gestion d'une session multimedia entre un terminal appelant et au moins un terminal appele, terminal et programme d'ordinateur correspondants.
CN110830748A (zh) * 2019-12-19 2020-02-21 广东以诺通讯有限公司 一种视频通话方法及系统

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040028037A1 (en) * 2000-12-22 2004-02-12 Juha Rasanen Method and system for modifying a connection parameter

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000307720A (ja) 1999-04-21 2000-11-02 Canon Inc ネットワーク接続装置における音声符号化方法
JP4763136B2 (ja) 1999-05-17 2011-08-31 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 遠隔通信ネットワークにおける機能ネゴシエーション
CN1158819C (zh) * 1999-07-12 2004-07-21 艾利森电话股份有限公司 用于在多媒体网络节点之间交换信息的方法和系统
JP3764609B2 (ja) 1999-09-08 2006-04-12 株式会社エヌ・ティ・ティ・ドコモ 制御装置、交換機、制御方法および符号化変換方法
US7688745B1 (en) 2000-08-14 2010-03-30 Nokia Siemens Networks Oy Communication system and method providing a mode selection procedure
US20020078151A1 (en) * 2000-12-15 2002-06-20 Wickam Bryce C. System for communicating messages of various formats between diverse communication devices
WO2002051542A1 (fr) * 2000-12-22 2002-07-04 Nippon Kayaku Kabushiki Kaisha Catalyseur d'oxydation d'alcane, procede de production correspondant et procede de production d'un compose insature contenant de l'oxygene
WO2002052825A1 (fr) * 2000-12-22 2002-07-04 Nokia Corporation Procede et systeme permettant d'etablir une connexion multimedia par une negociation de capacite dans un canal de commande sortant
JP4362261B2 (ja) 2002-01-17 2009-11-11 日本電気通信システム株式会社 音声符号制御方法
KR20030089264A (ko) * 2002-05-17 2003-11-21 (주)씨앤에스 테크놀로지 인터넷망과 공중전화망 겸용 영상전화기
US20030236892A1 (en) * 2002-05-31 2003-12-25 Stephane Coulombe System for adaptation of SIP messages based on recipient's terminal capabilities and preferences
US7685315B2 (en) * 2002-10-28 2010-03-23 Nokia Corporation System and method for conveying terminal capability and user preferences-dependent content characteristics for content adaptation
US7443879B2 (en) * 2002-11-14 2008-10-28 Lucent Technologies Inc. Communication between user agents through employment of codec format unsupported by one of the user agents
US7353021B2 (en) * 2002-11-14 2008-04-01 Lucent Technologies Inc. Network controller replacement of indication of one or more specific network connections usable by first network component in signaling message for second network component with wild card network connection information
US7139279B2 (en) 2002-12-12 2006-11-21 Dilithium Networks Pty Ltd. Methods and system for fast session establishment between equipment using H.324 and related telecommunications protocols
GB2417174B (en) * 2003-02-24 2007-01-31 Mitsubishi Electric Corp Communication service unit and connection sequence executing method
US7586857B2 (en) * 2003-04-01 2009-09-08 Alcatel-Lucent Usa Inc. Fast network SIP/SDP procedures for conference operations upon request from end user with optimization of network resources
DE10323403A1 (de) * 2003-05-23 2004-12-09 Siemens Ag Verfahren zur Signalisierung von Anrufumleitungsparametern in einem SIP-Netz
EP1509018A1 (fr) 2003-08-18 2005-02-23 Siemens Aktiengesellschaft Méthode, produit logiciel et dispositifs pour signaler la modification des canaux porteurs utilisant le protocole SIP
US7885208B2 (en) * 2003-09-11 2011-02-08 Nokia Corporation IP-based services for circuit-switched networks
US6924831B2 (en) 2003-09-12 2005-08-02 Aevoe Incorporated Video telephone integrating public-switch telephone network and asymmetric digital subscriber line
JP2005159581A (ja) 2003-11-21 2005-06-16 Anyuser Global Kk Ｉｐ電話用異種プロトコール（ｓｉｐ／ｈ．３２３）インターワーキング方法
US20060002373A1 (en) * 2004-06-30 2006-01-05 Michael Denny Terminals, methods, systems, and computer program products for providing video communications over a broadband connection based on a call via a PSTN
JP4044082B2 (ja) 2004-09-14 2008-02-06 株式会社東芝 選択装置、変換装置、選択方法、変換方法、コンピュータプログラム

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040028037A1 (en) * 2000-12-22 2004-02-12 Juha Rasanen Method and system for modifying a connection parameter

Also Published As

Publication number Publication date
US10075479B2 (en) 2018-09-11
WO2007045527A1 (fr) 2007-04-26
US20090290573A1 (en) 2009-11-26
CN101292497A (zh) 2008-10-22
KR101422223B1 (ko) 2014-07-22
DE102005050586B3 (de) 2006-11-02
KR20080069617A (ko) 2008-07-28
JP2009512379A (ja) 2009-03-19
JP5237816B2 (ja) 2013-07-17

Similar Documents

Publication Publication Date Title
DE102005050586B3 (de) Verfahren zum Aufbau einer Videotelefonverbindung und/oder Multimediatelefonverbindung in einem Datennetz
EP1938625B1 (fr) Procede de transmission de donnees de signalisation dans une unite passerelle et dans une unite de commande
DE102005050588B4 (de) Signalisierung bezüglich des Aufbaus von H.324 Videotelefonie zwischen einer Mediagateway und einem Controller
DE60037350T2 (de) Vefahren zur Zusammenarbeit unterschiedlicher IP Telefon-Protokolle
DE602004000139T2 (de) Schnelles SIP/SDP-Netzverfahren für Konferenzbetrieb mit Optimierung der Netzressourcen
DE602006000816T2 (de) Verfahren zur Bereitstellung von nahtlose mobile Sitzung
EP2073480B1 (fr) Procédé d'attribution d'au moins une connexion de données utiles à au moins une liaison multiplexe
DE102005036298B3 (de) Verfahren und Kommunikationssystem zur Auswahl eines Übertragungsmodus' für eine Übermittlung von Nutzdaten
WO2004045182A1 (fr) Transmission de parametres de commande d'appel entre deux controleurs de passerelle de telecommunication dans des reseaux sip/sip-t
DE102005031167A1 (de) Verfahren, Server-Einrichtung und Umsetzeinrichtung zum Aufbauen einer Nutzdatenverbindung
WO2005039140A1 (fr) Traitement de medias anticipes ii
DE60212988T2 (de) Verfahren, Einrichtung und Computerprogramm zur Auswahl einer Medienübergangskontrollfunktion basierend auf der Überwachung von Resourcen von Medienübergangsfunktionen
WO2005039139A1 (fr) Traitement de donnees media precoces i
EP1493285B1 (fr) Mise en attente/portabilite de terminal dans des reseaux h.323/isup-bicc-sip
DE102004040480B4 (de) Verfahren und Vorrichtung zum Nutzdatenabgriff multimedialer Verbindungen in einem Paketnetz
EP1430701B1 (fr) Procede de commande de services supplementaires dans des systemes de communication orientes par paquets
EP1845676A1 (fr) Procédé pour la vidéo-téléphonie entre un terminal dans un premier réseau de données à commutation de circuit et un deuxième réseau de données à commutation de paquet
DE102005045121B4 (de) Vorrichtung zur Unterstützung des Leistungsmerkmals "Fall-back" in SIP-Netzen
WO2007141190A1 (fr) Procédé pour l'assistance d'appels intercellulaires dans un transfert intercellulaire ims/cs dans des réseaux ims/cs hybrides existants
WO2007065738A1 (fr) Dispositif et procede pour prendre en charge des applications de fax t.38 dans des reseaux fmc
WO2004047470A1 (fr) Transmission de donnees vocales dans un reseau de telephonie mobile constitue d'un reseau d'acces radio et d'un reseau de commutation

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20080314

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

17Q First examination report despatched

Effective date: 20110120

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS AKTIENGESELLSCHAFT

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS AKTIENGESELLSCHAFT

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20180613