EP1938551A1 - Verfahren zum aufbau einer videotelefonverbindung und/oder multimediatelefonverbindung in einem datennetz - Google Patents

Verfahren zum aufbau einer videotelefonverbindung und/oder multimediatelefonverbindung in einem datennetz

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
English (en)
French (fr)
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/de
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)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Aufbau einer Videotelefonverbindung in einem Datennetz umfassend ein Telefonnetz und ein auf dem Internetprotokoll basierendes IP-Netz. Der Ausdruck Videotelefonverbindung ist hier und im folgenden allgemein zu verstehen und umfasst neben reiner Videotelefonie auch Multimediatelefonie.

Description

Beschreibung
Verfahren zum Aufbau einer Videotelefonverbindung und/oder Multimediatelefonverbindung in einem Datennetz
Die Erfindung betrifft ein Verfahren zum Aufbau einer Videotelefonverbindung in einem Datennetz umfassend ein Telefonnetz und ein auf dem Internetprotokoll basierendes IP-Netz. Der Ausdruck Videotelefonverbindung ist hier und im folgenden allgemein zu verstehen und umfasst neben reiner Videotelefo- nie auch Multimediatelefonie .
Zur Übertragung von Multimedia-Daten ist es aus dem Stand der Technik bekannt, ein Telefonnetz, beispielsweise ein Mobil- funknetz, insbesondere ein GSM- oder UMTS-Mobilfunknetz, mit einem IP-basierten Netz zu verbinden, um über ein derartig kombiniertes Datennetz Sprach- und Videotelefonie effektiv durchzufuhren. Hierbei muss sichergestellt werden, dass die Dienste des Telefonnetzes mit den Diensten des IP-Netzes zu- sammenwirken und insbesondere eine Umwandlung der verwendeten Signalisierungen und des Transportformats der Nutzdaten gewahrleistet ist.
Auf dem Gebiet der 3GPP-Netze (3GPP = 3rd Generation Part- nership Project) wurde in den 3GPP Standard TS 29.163 ein Zusammenwirken zwischen einem sog. CS-Telefonnetz (CS = Circuit Switched) , insbesondere einer 3GPP-CS-Domain oder einem PSTN- Netz (PSTN = Public Switched Telephone Network) , und einem IP-basierten IMS-Netz (IMS = IP Multimedia Subsystem) spezi- fiziert. Die Spezifikation betrifft jedoch nur reine Sprach- telefonie, und es ist kein Verfahren bekannt, wie effektiv eine Videotelefonverbindung zwischen einem CS-Netz und einem IMS-Netz (IMS = IP Multimedia Subsystem) aufgebaut werden kann .
Aufgabe der Erfindung ist es deshalb, ein Verfahren zu schaffen, welches den Aufbau einer Videotelefonverbindung zwischen einem Teilnehmer auf der Seite eines Telefonnetzes und einem Teilnehmer auf der Seite eines IP-Netzes ermöglicht.
Diese Aufgabe wird durch die unabhängigen Patentansprüche ge- lost. Weiterbildungen der Erfindung sind in den abhangigen Ansprüchen definiert.
In dem erfindungsgemaßen Verfahren erfolgt in einem Schritt a) ein Rufaufbau zwischen einem ersten Teilnehmer, der sich im oder benachbart zum Telefonnetz befindet, und einem zweiten Teilnehmer, der sich im oder benachbart zum IP-Netz befindet, über das Telefonnetz und das IP-Netz mit Hilfe eines ersten Signalisierungsprotokolls im Telefonnetz und eines zweiten Signalisierungsprotokolls im IP-Netz. Unter Teilneh- mer ist hierbei insbesondere ein Endgerat zu verstehen, insbesondere ein Mobilfunkendgerat oder ein Festnetzendgerat . Um eine Signalisierung zwischen dem ersten und dem zweiten Sig- nalisierungsprotokoll zu gewahrleisten, werden beim Rufaufbau Signalisierungsnachrichten des ersten Signalisierungsproto- kolls in Signalisierungsnachrichten des zweiten Signalisierungsprotokolls und/oder umgekehrt umgewandelt (Schritt b) ) . In einem Schritt c) werden bei dieser Umwandlung eine oder mehrere Codierungen festgelegt, welche bei der Übertragung der wahrend der Videotelefonverbindung ausgetauschten Nutzda- ten im Telefonnetz verwendbar und/oder voraussichtlich verwendbar sind. Diese Festlegung der Codierungen wird vorgenommen, da bei der Signalisierung mit dem ersten Signalisie- rungsprotokoll im Telefonnetz meist keine Informationen über die verwendbaren Codierungen für die Nutzdaten übermittelt werden. Diese Informationen werden in der Telefonverbindung erst zu einem spateren Zeitpunkt, nämlich beim Aufbau der eigentlichen Datenverbindung zur Übertragung der Nutzdaten, u- bermittelt. Andererseits benotigt ein im IP-Netz verwendetes Signalisierungsprotokoll die Informationen bezuglich verwend- barer Codierungen. Deshalb werden in einem Schritt d) die Codierungen, die in Schritt c) festgelegt wurden, mit einer o- der mehreren Signalisierungsnachrichten des zweiten Signali- sierungsprotokolls in das IP-Netz gesendet. Anschließend wird nach und/oder wahrend der Durchfuhrung des Rufaufbaus eine Datenverbindung zur Übertragung der wahrend der Videotelefonverbindung ausgetauschten Nutzdaten aufgebaut. Innerhalb der Datenverbindung, insbesondere wahrend deren Aufbau gemäß
Schritt e) , wird dann auf Seiten des Telefonnetzes mithilfe eines dritten Signalisierungsprotokolls, welches insbesondere H.245 ist, die für die Nutzdaten verwendete Codierung bestimmt .
Der vorliegenden Erfindung liegt die Erkenntnis zugrunde, dass zur Signalisierung im IP-Netz bereits verwendbare bzw. voraussichtlich verwendbare Codierungen festgelegt sein müssen. Da die Codierungen auf Seiten des Telefonnetzes jedoch bei der Signalisierung noch nicht bekannt sind, wird in dem erfindungsgemaßen Verfahren vorab abgeschätzt bzw. bestimmt, welche Codierungen bei der Übertragung der Nutzlast im Telefonnetz verwendbar bzw. voraussichtlich verwendbar sind. Diese Information wird dann von dem zweiten Signalisierungspro- tokoll verwendet. Somit kann mit dem erfindungsgemaßen Verfahren ein schneller Verbindungsaufbau gewahrleistet werden, da nicht auf den eigentlichen Aufbau der Datenverbindung, in der die tatsachlich im Telefonnetz verwendbaren Codierungen mitgeteilt werden, gewartet werden muss.
Das erfindungsgemaße Verfahren wird vorzugsweise in dem bereits oben erwähnten 3GPP-Datennetz eingesetzt. Als Telefonnetz wird insbesondere ein CS-Netz und/oder ein PSTN-Netz verwendet, welche bereits oben erwähnt wurden. Als erstes Signalisierungsprotokoll wird in dem erfindungsgemaßen Verfahren vorzugsweise das aus dem Stand der Technik bekannte BICC-Protokoll (BICC = Bearer Independent CaIl Control) verwendet. Alternativ oder zusatzlich kann auch das aus dem Stand der Technik bekannte ISUP-Protokoll (ISUP = ISDN User Part) eingesetzt werden. Als zweites IP-Netz wird vorzugsweise das bereits oben erwähnte IMS-Netz verwendet. Ferner kommt als zweites Signalisierungsprotokoll insbesondere das hin- länglich aus dem Stand der Technik bekannte SIP/SDP-Protokoll (SIP = Session Initiation Protocol; SDP = Session Description Protocol) in Betracht. In einer bevorzugten Ausführungsform wird bei dem SIP-Protokoll die bekannte Preconditions- Erweiterung eingesetzt, um nach Schritt f) zu signalisieren, dass der Aufbau einer Transportverbindung (auch als Bearer- Verbindung bezeichnet) abgeschlossen ist.
In einer bevorzugten Ausführungsform der Erfindung werden die Schritte b) bis d) des erfindungsgemäßen Verfahrens in einem oder mehreren Schnittstellenknoten zwischen dem Telefonnetz und dem IP-Netz durchgeführt, wobei die Schnittstellenknoten vorzugsweise einen MGCF-Knoten (MGCF = Media Gateway Control Function) und einen IM-MGW-Knoten (IM-MGW = IMS Media Gate- way) umfassen. Diese Art von Schnittstellenknoten bzw.
Schnittstellenrechnern sind hinlänglich aus dem Stand der Technik bekannt und werden an dieser Stelle nicht näher beschrieben .
Beim Aufbau der Datenverbindung im Schritt e) wird in einer besonders bevorzugten Ausführungsform die hinlänglich aus dem Stand der Technik bekannte H.324-Protokollfamilie verwendet. Bei der Verwendung eines Mobilfunknetzes als Telefonnetz wird hierbei eine Abwandlung dieses Protokolls, nämlich das H.324M-Protokoll, eingesetzt.
Um eine effektive Abschätzung der im Telefonnetz verwendbaren Codierungen im Schritt c) sicherzustellen, werden in einer bevorzugten Ausführungsform in diesem Schritt die Codierungen in Abhängigkeit von dem verwendeten Telefonnetz festgelegt. Hierbei wird sich die Erkenntnis zugrunde gemacht, dass je nach verwendetem Telefonnetz bestimmte Codierungen bevorzugt werden .
In einer weiteren Ausführungsform werden die Codierungen im Schritt c) des erfindungsgemäßen Verfahrens in Abhängigkeit von der Rufnummer des ersten Teilnehmers, der in bzw. benach- bart auf der Seite des Telefonnetzes liegt, festgelegt. Es wird sich hierbei die Erkenntnis zunutze gemacht, dass mit Hilfe der Rufnummer des ersten Teilnehmers ermittelt werden kann, in welchem Telefonnetz sich der Teilnehmer befindet. Hieraus kann wieder darauf geschlossen werden, welche Codierungen bevorzugt verwendet werden.
In einer weiteren Ausgestaltung werden im Schritt c) diejenigen Codierverfahren festgelegt, die in Abhängigkeit von dem verwendeten Telefonnetz und dem verwendeten IP-Netz am wahrscheinlichsten in beiden Netzen verwendet werden. Es wird hierdurch gewährleistet, dass bereits vorab die richtige Auswahl von kompatiblen Codierungen festgelegt wird. Eine derartige Auswahl der Codierungen kann beispielsweise durch Bewer- ten von Statistiken bzw. durch administrative Einstellungen erreicht und optimiert werden. Insbesondere ist es auch möglich, dass nur eine Sprach- und Videocodierung ausgewählt wird.
In einer weiteren Ausgestaltung der Erfindung können die Sig- nalisierungsnachrichten des ersten Signalisierungsprotokolls derart ausgestaltet sein, dass sie Informationen über im Telefonnetz verwendbare Sprachcodierungen enthalten. Diese Sprachcodierungen werden vorzugsweise ebenfalls bei der Fest- legung der Codierungen im Schritt c) berücksichtigt. Hierdurch wird ein reibungsloser Aufbau auch für den Fall gewährleistet, dass auf der Seite des IP-Netzes nur reine Sprachte- lefonie ausgewählt wird.
In einer besonders bevorzugten Ausführungsform der Erfindung werden beim Aufbau der Datenverbindung im Schritt f) des erfindungsgemäßen Verfahrens eine oder mehrere erste Spezifikations-Nachrichten im Telefonnetz übertragen, wobei eine erste Spezifikations-Nachricht die im ersten Teilnehmer verwendba- ren Codierungen spezifiziert. Diese ersten Spezifikations- Nachrichten sind insbesondere im Stand der Technik aus dem Protokoll H.245 zur Verhandlung der Codierungen als "Terminal Capability Set" Nachrichten TCS bekannt. Die in einer ersten Spezifikations-Nachrichten spezifizierten Codierungen werden insbesondere mit dem im Schritt c) festgelegten Codierungen verglichen. Wenn der Vergleich ergibt, dass keine oder nur eine teilweise Übereinstimmung zwischen den in der ersten Spezifikations-Nachricht spezifizierten Codierungen und den im Schritt c) festgelegten Codierungen besteht, wird in einer bevorzugten Ausfuhrungsform eine Signalisierungsnachricht des zweiten Signalisierungsprotokolls in das IP-Netz gesendet, wobei diese Signalisierungsnachricht zumindest teilweise die in der ersten Spezifikations-Nachrichten spezifizierten Codierungen enthalt. Hierdurch wird gewahrleistet, dass eine Datenverbindung auch hergestellt werden kann, wenn die ursprunglich abgeschätzten Codierungen nicht mit den tatsach- lieh verwendbaren Codierungen übereinstimmen.
In einer weiteren bevorzugten Ausfuhrungsform des erfindungs- gemaßen Verfahrens werden Signalisierungsnachrichten des zweiten Signalisierungsprotokolls im IP-Netz übertragen, wo- bei diese Signalisierungsnachrichten die im zweiten Teilnehmer verwendbaren Codierungen spezifizieren und ferner die in diesen Signalisierungsnachrichten enthaltenen Codierungen mit einer zweiten Spezifikations-Nachricht beim Aufbau der Datenverbindung in Schritt e) in das Telefonnetz gesendet werden. Auf diese Weise werden die von Seiten des IP-Netzes empfangenen Angaben über die Codierungen bei der Verhandlung der Codierungen im Telefonnetz, welche insbesondere mit dem H.245- Protokoll durchgeführt wird, berücksichtigt.
In einer weiteren Ausfuhrungsform wird eine Signalisierungsnachricht des zweiten Signalisierungsprotokolls, welche die im zweiten Teilnehmer verwendbaren Codierungen spezifiziert, mit einer ersten Spezifikations-Nachricht verglichen und der Aufbau der Videotelefonverbindung wird abgebrochen oder ein Umschalten auf Sprachtelefonie, vorzugsweise mit Hilfe der
SCUDIF-"Service Change"-Prozedur gemäß dem 3GPP-Standard 3GPP TS 23.172, wird veranlasst, wenn nicht zumindest eine Über- einstimmung von für eine Videotelefonverbindung erforderlichen Codierungen in der Signalisierungsnachricht und der ersten Spezifikations-Nachricht vorliegt.
Insbesondere betreffen die in der Erfindung verwendeten Codierungen Sprach- und Videocodierungen, welche beide bei der Videotelefonie verwendet werden. Ggf. umfasst die Erfindung jedoch auch weitere Datencodierungen.
In einer weiteren Ausführungsform des erfindungsgemäßen Verfahrens, insbesondere im Falle, wenn ein verwendetes SIP- Protokoll nicht die Preconditions-Erweiterung unterstützt, wird der zweite Teilnehmer angewiesen, keine Nutzdaten zu ü- bertragen, bis ein vorbestimmter Verfahrensabschnitt des Auf- baus der Datenverbindung, insbesondere der Aufbau der Transportverbindung im Telefonnetz, abgeschlossen ist. Hierdurch wird das sog. "Clipping" vermieden, d.h. der Verlust von Sprache und Video, die durch den Angerufenen gesendet werden, bevor eine durchgängige Transportverbindung vorhanden ist.
Neben dem soeben beschriebenen erfindungsgemäßen Verfahren betrifft die Erfindung ferner ein Datennetz mit einem Telefonnetz und einem auf dem Internetprotokoll basierenden IP- Netz, wobei das Datennetz derart ausgestaltet ist, dass das erfindungsgemäße Verfahren durchführbar ist. Hierzu weist das Datennetz vorzugsweise einen oder mehrere Schnittstellenknoten zwischen dem Telefonnetz und dem IP-Netz auf, wobei die Schnittstellenknoten zur Durchführung der Schritte b) bis d) des erfindungsgemäßen Verfahrens dienen. Vorzugsweise umfas- sen die Schnittstellenknoten die hinlänglich aus dem Stand der Technik bekannten MGCF- und IM-MGW-Knoten, die bereits bei der Beschreibung des erfindungsgemäßen Verfahrens erwähnt wurden .
Ausführungsbeispiele der Erfindung werden nachfolgend anhand der beigefügten Zeichnungen detailliert beschrieben. Es zeigen :
Fig. 1 eine schematische Darstellung einer Ausführungsform eines Datennetzes, in dem das erfin- dungsgemäße Verfahren eingesetzt werden kann;
Fig.2 - Fig.16 Signalisierungsdiagramme, welche den Signali- sierungsverlauf der Nachrichten in den in der Erfindung verwendeten Protokollen für verschie- dene Szenarien verdeutlichen.
Bevor detailliert Ausführungsformen des erfindungsgemäßen Verfahrens beschrieben werden, wird zunächst zum besseren Verständnis der Erfindung auf die bereits vorhandenen Ent- Wicklungen im Stand der Technik eingegangen. Insbesondere wird hierbei auf die Entwicklungen der Datennetze eingegangen, für welche das erfindungsgemäße Verfahren bevorzugt verwendet wird. Die im Folgenden sowie auch im Vorangegangenen definierten Protokolle und deren Abkürzungen sind hinlänglich aus dem Stand der Technik bekannt und werden deshalb nicht näher erläutert.
Aus dem 3GPP-Mobilfunk-Projekt ist das sog. "Circuit Switched Domain"-Netz CS und das sog. "IP-Multimedia Subsystem (IMS)"- Netz für Sprach- und Videotelefonie bekannt. Es muss hierbei ein so genanntes „Interworking" der betreffenden Dienste dieser Netze gewährleistet sein, d. h. ein Verbinden der Dienste mittels einer geeigneten Umwandlung der verwendeten Signalisierung und des verwendeten Transportformats der Daten, zwi- sehen IMS und der CS Domain ist erforderlich. Das IMS wird neben den 3GPP-Zugangsnetzen „Global System for Mobile Communications" (GSM) und „Universal Mobile Telecommunications System" (UMTS) auch für andere Zugangsnetze verwendet, beispielsweise „Wireless Local Area Network" (WLAN) und „Digital Subscriber Line" (DSL) . Gerade in diesen Szenarien ist zuerst zu erwarten, dass Sprach- und Videotelefonie über das IMS erfolgen. Videotelefonie kann auch in einem öffentlichen Tele- fonnetz, d.h. einem so genannten „Public Switched Telephone Network (PSTN)", genutzt werden, wobei hier in der Regel für Transport und Signalisierung dieselben Protokolle wie in der 3GPP-CS-Domain genutzt werden. Auch von einem PSTN-Netz ist ein Interworking hin zum IMS erforderlich.
Bisher ist ein Interworking zwischen IMS und CS-Domain oder PSTN nur für Sprachtelefonie beschrieben. Die vorliegende Erfindung betrifft das entsprechende Interworking für Videote- lefonie. Ein Bedarf dafür ist abzusehen, da sowohl in der 3GPP-CS-Domain wie auch in IMS Videotelefonie an Bedeutung gewinnt, und zwar insbesondere für Zugangsnetze wie WLAN oder DSL bzw. für neu entstehende Netz-Zutrittsmöglichkeiten (z.B. Worldwide Interoperability for Microwave Access (WiMAX) ) .
Das Interworking zwischen einem IMS-Netz und einem CS- Netzwerk, also einem PSTN oder einer 3GPP-CS-Domain, ist ab 3GPP Release 6 nur für reine Sprachtelefonie in 3GPP TS 29.163 spezifiziert.
Gemäß TS 29.163 erfolgt das Interworking der so genannten „Call-Control" Signalisierung in der so genannten „Media Gateway Control Function" (MGCF) . Das Interworking der Nutzverbindung, also das Weiterreichen und Umpacken sowie nötigen- falls das Transkodieren der Nutzdaten, erfolgt in der so genannten „Internet Multimedia-Media Gateway" (IM-MGW). Die MGCF kontrolliert die IM-MGW mittels des von der ITU-T standardisierten H.248 Protokolls, wie in 3GPP TS 29.332 weiter beschrieben wird. Im Folgenden werden MGCF und IM-MGW zusam- men als „Multimedia-Interworking-Knoten" (MIK) bezeichnet.
Im CS-Netz wird Bearer Independent CaIl Control (BICC) oder ISDN User Part (ISUP) zur Call-Control Signalisierung verwendet. Im Falle, wenn die Call-Control Signalisierung getrennt von den Transportverbindungen geführt werden, wird diese Methode auch als "out-of-band" Signalisierung bezeichnet. In weiterer Folge besteht auch die Möglichkeit innerhalb der Transportverbindung Signalisierungs-Meldungen auszutauschen, welche als "in-band" Signalisierungen bezeichnet werden. Im Falle von ISUP wird Time Division Multiplex (TDM) als Transport im CS-Netzwerk genutzt, und im Falle von BICC Paket- transport mittels Internet Protocol (IP) oder Asynchron
Transfer Modus (ATM) . Die Aushandlung, ob reine Sprachtelefo- nie oder Videotelefonie verwendet wird, kann für ISUP während des Call-Control Signalisierung zum Aufbau des Gesprächs mittels der so genannten ISUP "UDI Fallback" Prozedur erfol- gen. Für BICC kann diese Aushandlung mittels dem in 3GPP TS 23.172 standardisierten „Service Change and UDI Fallback" (SCUDIF) erfolgen, der auch während des Gesprächs einen Wechsel zwischen Sprachtelefonie und Videotelefonie ermöglicht. Sowohl „UDI Fallback" wie SCUDIF nutzen out-of-band Signali- sierung. Daneben ist es für ISUP und BICC möglich, die genannten Prozeduren nicht zu verwenden, und einen Rufaufbau (auch als Call-Control bezeichnet) nur für Videotelefonie zu versuchen, und im Falle, dass Videotelefonie nicht unterstützt wird, den Rufaufbau abzubrechen. Im Gegensatz zur op- tionalen Verhandlung zwischen Sprache und Video erfolgt die Verhandlung der für Videotelefonie verwendeten Sprach- und Video-Codecs "in-band", nachdem bereits vorher Videotelefonie ausgewählt und eine entsprechende Transportverbindung (engl. „Bearer") aufgebaut wurde.
Für Videotelefonie wird in dem CS-Netwerk eine so genannte BS30 Datenverbindung mit 64 kbyte/s Bandbreite verwendet. Innerhalb dieser Datenverbindung wird die von der ITU-T standardisierte Protokollsuite H.324 verwendet, wobei in der 3GPP-CS-Domain die für den Mobilfunk angepasste Variante
H.324M ausgewählt wird. Nach dem Rufaufbau wird hierbei die Konfiguration der Multimedia-Verbindung in-band über das von der ITU-T standardisierte H.245 Protokoll ausgehandelt, besonders der verwendete Video-Codec und Sprach-Codec und die Details der jeweiligen Codec-Konfiguration. Sprache und Video werden mittels des H.223 Protokolls in dieselbe Transportverbindung gemultiplext . Für die 3GPP-CS-Domain beschreibt TS 26.110 die Verwendung der Protokollsuite H.245 weiter, wobei insbesondere die so genannte H.324M Konfiguration ausgewählt wird.
Die wichtigsten Ablaufe beim Aufbau einer 3G-324M Verbindung (engl, "session") sind die folgenden:
1. Nach dem Start der ISUP oder BICC Rufaufbausignalisie- rung erfolgt die Reservierung der notwendigen Ressourcen, welche für den gewünschten "Bearer" benotigt wer- den, und in weiterer Folge der Aufbau der Transportverbindung.
2. Start der "in-band" Verhandlung. Zunächst Verhandlung, welcher H.223 "Multiplexer Level" für diese Transportverbindung zu verwenden ist. 3. Erkennung des leitenden Endgerates, welches die MuI- tistream-Verbindung eröffnet mittels H.245 Verhandlung, falls erforderlich. Diese Funktion ist nur dann notwendig, falls es zu einem Konflikt im Zusammenhang beim Offnen eines bidirektionalen logischen Kanals (= logical Channel) kommt. Diese Funktion wird als "Master or Slave determination" (MSD) bezeichnet.
4. Mittels so genannter „Terminal Capability Set" H.245- Nachrichten TCS werden die Fähigkeiten des die Nachricht sendenden Endgerats übertragen. Solche Meldungen werden unabhängig von beiden Endgeraten gesendet. Diese beschriebenen Fähigkeiten beinhalten folgende Informationen: Audio- und Video-Codec und deren spezifischen Eigenschaften bzw. dessen Ausprägungen; funktionaler Umfang des Multiplexers, im Detail welcher Adaptions-Layer unterstutzt wird (z.B "simple" (=einfach) oder "nested" (=verschachtelt) multiplexing) und dessen Mobilfunk spezifische Erweiterungen.
5. Aufbau von "logischen" Kanälen je Mediastrom mittels
H.245-Signalisierung. Ab diesem Zeitpunkt, entweder mit MSD oder ohne, ist das Endgerat bzw. die IM-MGW dazu bereit, "logical Channels" zu offnen, um den Austausch von Sprach-, und/oder Video-Nutzdaten zu ermöglichen. Bei dem Erstellen eines bidirektionalen "logical Channel" wird die Kanalnummer (=channel number) und die endgültigen zu verwendeten Fähigkeiten der Medien (engl, "media capabilities" ) festgelegt. 6. Definition der Multiplexeigenschaften mittels H.245.
7. Start der Übermittlung von Video, Audio/Sprache oder Daten .
Im IMS erfolgt die Aushandlung für Videotelefonie "out-of- band" mit Hilfe des so genannten „Session Description Proto- col" (SDP), IETF RFC 2327, das mittels des so genannten „Session Initiation Protocol" (SIP), IETF RFC 3261, transportiert wird. Hierbei ist die Aushandlung, ob Sprachtelefonie oder Videotelefonie verwendet wird, mit der Aushandlung der Ver- wendeten Codecs verbunden, und erfolgt vor oder wahrend des Aufbaus der Bearer. Es wird der so genannte SDP „offer- answer" Mechanismus gemäß RFC 3264 verwendet. Hierbei schickt der Anbieter in der SDP „offer" Nachricht eine Liste von unterstutzten Codecs. Nach Erhalt dieser Nachricht schickt der Antwortende eine SDP „Answer" Nachricht, die diejenigen Codecs aus der Liste enthalt, die auch er unterstutzt und benutzen will. Der Antwortende darf keine Codecs angeben, die nicht in der Liste der SDP „offer" enthalten waren. Im Gegensatz zur CS-Domain werden für Sprache und Video zwei getrenn- te Transportverbindungen (engl. „Bearer") genutzt, die jeweils das so genannte „Real Time Transport Protocol" (RTP) , IETF RFC 3550, verwenden. Für das 3GPP-IMS, welches über ein General Packet Radio Service (GPRS) Zugangsnetz verwendet, beschreibt 3GPP TS 26.235 die für Videotelefonie zu verwendenden Codecs.
Im Folgenden werden die auf Seiten der CS-Domain und auf Seiten des IMS für Videotelefonie verwendeten Protokolle und Codecs nochmals zusammengefasst :
CS-Netz (insbesondere 3GPP CS-Domain) : CaIl Control BICC oder ISUP.
Aushandlung zwischen reiner Sprachtelefonie und Videotelefonie kann für ISUP mittels "UDI Fallback" und für BICC mittels "SCUDIF" erfolgen .
Multimedia Protocol suite H.324M (H.324 Annex C): Codec-Verhandlung: H.245 in-band Verhandlung über den aufgebauten CS-Bearer mit 64 kbit/s Video-Codec: Unterstützung von H.263 vorgeschrieben
H.261 optional
MP4V-ES (simple video profile level 0) optional
Sprach-Codec : Unterstützung von NB-AMR vorgeschrieben WB-AMR optional
G.723.1 empfohlen
Transport: Multiplexen von Sprache und Video in einen Bearer gemäß H.223 Annex A + B
IMS (Codecs für GPRS-Zugangsnetz) : CaIl Control: SIP
Beinhaltet sowohl Aushandlung zwischen reiner Sprachtelefonie und Videotelefonie, wie auch Codec-Verhandlung . Codec-Verhandlung : Vor Aufbau des Bearers Out-of-band mittels SDP, das in SIP transportiert wird. Video-Codec: Unterstützung von H.263 vorgeschrieben, H.264 optional, MP4V-ES (simple video profile level 0) optional,
Sprach-Codec Unterstützung von NB-AMR und WB-AMR vorgeschrieben . Transport : Zwei getrennte RTP Bearer für Sprache und Video unter Verwendung von unterschiedlichen so genannten RTP "Payload" Formaten:
Sprache: Nb-AMR + WB-AMR: IETF RFC 3267 Video: H.263: IETF RFC 2429
H.264 (AVC) : IETF RFC 3984 MPEG-4: IETF RFC 3016
Synchronisation von parallel RTP Medienstromen erfolgt mittels so genannter RTP "timestamps", die durch das " Real Time Control Protocol" (RTCP, siehe IETF RFC 3550) ausgehandelt werden .
Neben den oder an Stelle der hier angegeben Codecs können a- ber auch andere Codecs von den Endgeraten unterstutzt werden, insbesondere wenn die CS-Endgerate sich im PSTN befinden oder die IMS-Endgerate GPRS nicht als Zugangsnetz nutzen.
Es ist wünschenswert, auf der CS-Seite und im IMS den gleichen Videocodec und wenn möglich auch den gleichen Sprachcodec zu verwenden, um ein Transkodieren zu vermeiden. Ein Transkodieren insbesondere des Videocodecs, aber in geringerem Umfang auch des Sprachcodecs, wurde erhebliche Rechen- leistung und Ressourcen in der IM-MGW erfordern. Zudem wurde die Übertragung verzögert und die Qualität des Bildes bzw. der Sprache verschlechtert. Wenn die erforderliche Bandbreite für die Codecs auf Seiten der CS-Domain und dem IMS unterschiedlich sind, wurde auf einer Seite zusatzliche Bandbreite verwendet, ohne dass dadurch die Bild- oder Sprachqualitat verbessern wurde.
Figur 1 zeigt eine typische Netzwerkkofiguration, wie sie in der nachfolgend beschriebenen Ausfuhrungsform der Erfindung verwendet werden kann.
Es ist die Netzwerkkonfiguration dargestellt, die notig ist, damit ein mit der 3GPP CS-Domane verbundenes Terminal in der Form eines mobilen Endgerats MSl mit einem mit dem IMS ver- bundenen Terminal in der Form eines mobilen Endgerats MS2 kommunizieren kann. Die CS-Domane ist mit Hilfe einer „Media Gateway Control Function" (MGCF) und einer IMS Media Gateway (IM-MGW) mit dem IMS verbunden. Die MGCF kontrolliert die IMS Media Gateway über die so genannte „Mn" Schnittstelle. Auf Seiten der CS-Domane befinden sich im Kernnetz so genannte „Mobile Switching Center" (MSC) -Server, die über BICC Signali- sierung miteinander und mit der MGCF kommunizieren. Sie kontrollieren jeweils CS-MGWs. Die CS-MGWs sind untereinander und mit der IM-MGW über die so genannte ,,Nb" Schnittstelle verbunden. Für Videotelefonie wird der so genannte „BS30" Da- tentransportdienst (engl. „Bearer Service") verwendet. MSl ist mittels eines so genannten Radiozugangsnetzes, beispielsweise eines UTRAN, mit einem MSC-Server einer CS-MGW verbunden. Auf Seiten des IMS kommuniziert die MGCF mit Hilfe des SIP CaIl Control Protokolls mit so genannten „call Session control functions" (CSCF) , die die Signalisierung über den Gateway GPRS Support node" (GGSN) und ein Radiozugangsnetzes, beispielsweise eines sog. UTRAN, zum mobilen Endgerat MS2 weiterreichen. Daten werden von der IMS Media Gateway über die Mb Schnittstelle zum GGSN transportiert, der diese Daten ebenfalls über das Radiozugangsnetz UTRAN zum MS2 weiter- reicht.
In Fig. 1 bezeichnet somit die Linie Ll, die sich über die beiden MSC-Server zur MGCF erstreckt, die BlCC-Signalisie- rung. Die Linie L2, die sich von der MGCF über die CSCF zum GGSN und von dort zum UTRAN auf der IMS-Seite erstreckt, bezeichnet die SIP-Signalisierung. Ferner bezeichnet die Linie L3, welche sich von der Schnittstelle UTRAN auf der CS-Seite über die beiden CS-MGWs und IM-MGW erstreckt, den kombinierten Sprach-/Videostrom. Die Linie L4, welche sich - analog zur Linie L3 - vom UTRAN auf der CS-Seite über die beiden CS- MGWs hin zum IM-MGW erstreckt, bezeichnet die Übertragung gemäß dem H.245 Protokoll. Die Linie L5, die sich vom IM-MGW über den GGSN zum UTRAN auf der IMS-Seite erstreckt, betrifft den Transport des Videostroms im IMS-Netz und die Linie L6, die sich ebenfalls von IM-MGW über den GGSN zum UTRAN auf der IMS-Seite erstreckt, betrifft den im IMS-Netz transportierten Sprachstrom. Ein Verfahren, das das Interworking von Videotelefonie unter Vermeidung von Transkodieren zwischen einem CS-Netz, also einem PSTN oder einer 3GPP CS-Domain, sowie einem IP-Netz, das SIP und SDP zur Aushandlung der Codecs verwenden, also beispielsweise dem IMS, ist Gegenstand der Erfindung.
Im Falle eines Rufaufbaus von Seiten des CS-Netzes in Richtung des IMS, der im Weiteren als „IMS terminierender" (IMS- T) Rufaufbau bezeichnet wird, empfängt die MGCF zunächst ISUP oder BICC Signalisierung, aus der sie erkennen oder vermuten kann, dass Videotelefonie gewünscht ist, aber nicht, welche Sprach- und Video-Codecs verwendet werden.
Im Falle eines Rufaufbaus von Seiten des IMS in Richtung des CS-Netzes, der im Weiteren als „IMS originierender" (IMS-O) Rufaufbau bezeichnet wird, empfängt die MGCF zunächst SIP- Signalisierung, aus der sie erkennen oder vermuten kann, dass Videotelefonie gewünscht ist, sowie welche Codecs auf Seiten des IMS unterstützt werden.
Um einen schnellen Aufbau der Verbindung zu erreichen, und im Folgenden die Signalisierung zwischen IMS und CS-Netz in geeigneter Weise umsetzen zu können, ist es im Falle des IMS-O Rufaufbaus - wie auch im Falle des IMS-T Rufaufbaus - erforderlich, dass die MGCF für die Signalisierung in Richtung des IMS Angaben über die auf der CS-Seite unterstützen Codecs macht, bevor sie diese Information aus der H.324/M Verbindung erhält. Diese Information wird auf der CS-Seite häufig erst zur Verfügung stehen, nachdem die Out-of-Band Call-Control Signalisierung zum Rufaufbau bereits abgeschlossen ist, zum Beispiel wenn zu diesem Zeitpunkt die Transportverbindung durchgeschaltet wird. In vielen Netzen werden in Richtung des Rufaufbaus gesendete Daten in der Transportverbindung, so ge- nannte „forward early media", bis zu diesem Zeitpunkt geblockt . Der Kern der Erfindung besteht darin, dass der Multimedia- Interworking-Knoten (MIK) in der SIP-Codec-Verhandlung beim Rufaufbau zunächst nur eine Abschätzung der auf der CS-Seite unterstützen Codecs abgibt. In einer vorteilhaften Ausfüh- rungsform berücksichtigt der MIK bei der Auswahl der Codecs das CS-Netz, an dem dieser angeschlossen ist. Wenn es sich beim CS-Netz um eine 3GPP CS-Domäne handelt, verwendet die MGCF vorzugsweise die in 3GPP TS 26.110 angegeben Codecs. In einem Festnetz können andere Codecs vorherrschen. In einer anderen vorteilhaften Ausführungsform berücksichtigt der MIK bei der Auswahl der Codecs das Netz, in dem sich der CS- seitige Gesprächsteilnehmer befindet. So verwendet der MIK im IMS-O Fall die Telefonnummer des Angerufenen, um zu ermitteln, in welchem Netz sich der Angerufene befindet, um für dieses Netz wahrscheinliche Codecs auszuwählen. Im IMS-T Fall verwendet der MIK die Telefonnummer des Anrufers, um zu ermitteln, in welchem Netz sich der Anrufer befindet, um für dieses Netz wahrscheinliche Codecs auszuwählen. Die Selektion der Codecs kann durch Bewerten von Statistiken bzw. durch ad- ministrative Einstellungen durch den Betreiber des MIK optimiert werden.
In einer einfacheren Ausführungsform wählt der MIK jeweils nur einen Sprachcodec und Videocodec aus, der mit großer Wahrscheinlichkeit auch vom Terminal im IMS unterstützt wird, beispielsweise den H.263 und den AMR Codec. Diese Ausführungsform kann ausreichend sein, weil gemäß 3GPP TS 26.235 und TS 26.110 die selben Sprach- und Videocodecs in der CS Domäne und dem IMS unterstützt werden müssen. Die Ausfüh- rungsform ist vorteilhaft, um die darauf folgenden Signali- sierungsabläufe zu vereinfachen.
Falls im IMS-T Falle SCUDIF verwendet wird, ist es vorteilhaft, wenn der MIK neben den oben beschriebenen ausgewählten Codecs auch die Sprachcodecs aufnimmt, welche bei der Verwendung von SCUDIF in der anfänglich beim Rufaufbau übermittelten IAM-Nachricht (IAM = Initial Address Message) in einer Codecliste hinterlegt sind. Hierdurch wird ein reibungsloser Rufaufbau auch für den Fall gewährleistet, dass auf Seiten des IMS Sprachtelefonie ausgewählt wird.
Der MIK empfängt im Folgenden in der H.245 Inband-Verhandlung eine so genannte „Terminal Capability Set" Nachricht. Darin befinden sich Angaben zu den Fähigkeiten des Terminals auf Seiten des CS-Netzes, unter anderem zu den unterstützten Videocodecs und Sprachcodecs unter genauen Angaben, welche Op- tionen der einzelnen Codecs unterstützt werden. Erfindungsgemäß vergleicht der MIK die darin enthaltenen Codecs mit den zuvor abgeschätzten und in das IMS signalisierten Codecs. Sollten die Codecs voneinander abweichen, kann es vorteilhaft oder erforderlich sein, dass der MIK zu diesem Zeitpunkt er- neut eine SDP „offer" in das IMS schickt, wobei er die in der „Terminal Capability Set" Nachricht angegeben Codecs weiterreicht. Die SDP „offer" kann beispielsweise mittels einer SIP „re-INVITE" oder „UPDATE" Nachricht transportiert werden. Eine erneute SDP offer ist im Besonderen dann erforderlich, wenn die zuvor abgeschätzten Codecs nicht mit jeweils mindestens einem Sprachcodec und Videocodec mit den in der „Terminal Capability Set" Nachricht empfangenen Codecs übereinstimmen .
Im IMS-O Fall hat der MIK bereits in der SIP „INVITE" Nachricht Informationen über die IMS-seitig unterstützten Codecs erhalten. Falls diese Codecs nicht in mindestens jeweils einem Sprachcodec und Videocodec mit den in der „Terminal Capability Set" Nachricht empfangenen Codecs übereinstimmen, ist es vorteilhaft, wenn der MIK die H.223 Verbindung abbaut und den Rufaufbau als Sprachtelephonie fortsetzt, beispielsweise indem er SCUDIF nutzt oder indem er CS-seitig den Rufaufbau zunächst komplett beendet und dann für Sprachtelefonie neu beginnt. Es kann auch der Fall auftreten, dass der MIK in der von ihm zuvor gesendeten SDP „answer" IMS-seitig unterstützte Codec ausgeschlossen hat, die er nun doch auf Grund der in der „Terminal Capability Set" Nachricht empfangenen Codecs auswählen mochte.
Im IMS-T Fall sendet der MIK dagegen die abgeschätzten Codecs in einer SDP „offer" und besitzt aus der erhaltenen SDP „ans- wer" nur die Information, welche der zunächst von ihm abgeschätzten Codecs auf der Seite des IMS unterstutzt werden. Es ist also sinnvoll, mittels einer neuen „SDP offer" abzufragen, ob in der ersten SDP „offer" nicht enthaltene Codecs im IMS unterstutzt werden.
Ein weiterer entscheidender Punkt der Erfindung ist, dass der MIK die von der IMS-Seite empfangenen Angaben über Codec in der H.245 Inband-Verhandlung mittels einer „Terminal Capabi- lity Set" Nachricht weiterreicht. Vorzugsweise wartet der MIK mit dem Senden dieser Nachricht, bis er von der IMS-Seite die SDP-Nachricht mit Angaben zu den Codecs empfangen hat. Es ist besonders vorteilhaft, wenn der MIK auch für eine gewisse Zeit auf den Empfang einer „Terminal Capability Set" Nach- rieht wartet, bevor er diese Nachricht selbst schickt, da der MIK, wie oben beschrieben, auf Grund der in der empfangenen „Terminal Capability Set" Nachricht enthaltenen Codecinformation beschließen kann, auf der IMS-Seite eine SDP „offer" zu schicken, und die in der folgenden SDP „answer" enthaltenen Informationen in der von ihm geschickten Terminal Capability Set" Nachricht berücksichtigt.
Sollte der MIK jedoch für eine gewisse Zeit von der Gegenseite keine „Terminal Capability Set" Nachricht empfangen, bei- spielsweise weil sich hinter dem CS-Netz wieder ein anderer
MIK an einem Übergang zu einem IMS-Netzwerk befindet, kann es erforderlich sein, dass der MIK vor Erhalt einer „Terminal Capability Set" Nachricht selbst eine „Terminal Capability Set" Nachricht schickt. Darin gibt der MIK erfindungsgemaß diejenigen Codecs an, die in der letzten, auf der IMS Seite gesendeten bzw. empfangenen SDP-Nachricht enthalten waren. Sollte der MIK nach Senden einer „Terminal Capability Set" Nachricht auf Seiten des IMS erneut eine SDP-Nachricht empfangen, das in der ersten „Terminal Capability Set" Nachricht erlaubte Codecs ausschließt, so sendet der MIK erfindungsge- maß eine neue „Terminal Capability Set" Nachricht, in der die entsprechenden Codecs entfernt sind.
Nachdem auf Seiten des CS-Netzes H.245 „Terminal Capability Set" Nachrichten ausgetauscht wurden, werden mittels der H.245 Signalisierung getrennte logische Kanäle des H.223 Protokolls zum Transport von Sprache und Video ausgewählt. Dadurch wird auch jeweils genau einer der unterstutzten Sprachcodecs und Videocodecs ausgewählt. Sollten zu diesem Zeitpunkt auf Seiten des IMS noch mehrere Sprachcodecs oder Vide- ocodecs ausgewählt sein, sendet der MIK erfindungsgemaß erneut eine „SDP offer" auf Seiten des IMS, in der er genau die mittels H.245 ausgewählten Codecs angibt, um zu verhindern, dass von Seiten des IMS-Terminals ein Codec verwendet wird, den der MIK nicht weiterreichen kann. Die SDP „offer" kann beispielsweise mittels einer SIP „re-INVITE" oder „UPDATE" Nachricht transportiert werden.
Im IMS-T Falle ist es wünschenswert, „Clipping" zu vermeiden, dass heißt einen Verlust von Sprache oder Video, die durch den Angerufenen gesendet wird, bevor eine durchgangige Transportverbindung vorhanden ist. Falls auf Seiten des IMS die „SIP Preconditions" Erweiterung gemäß IETF RFC 3312 unterstutzt wird, nutzt der MIK die SIP „Preconditions" Erweiterung, um anzuzeigen, dass lokale so genannte „QoS preconditi- ons" vorhanden sind, d.h. ein Aufbau der Transportverbindung erforderlich ist, bevor der Rufaufbau abgeschlossen werden kann. Sobald durch das Offnen der logischen H.223 Kanäle für Sprache und Video der CS-seitige Aufbau der Transportverbindung abgeschlossen ist, nutzt der MIK erfindungsgemaß die SIP „Preconditions" Erweiterung, um anzuzeigen, dass lokale so genannten „QoS preconditions" erfüllt sind. Allerdings kann es vorkommen, dass CS-seitig „forward early media" erst nach Abschluss des Rufaufbaus in der Call-Control-Signalisierung durchgereicht werden, und erst zu diesem Zeitpunkt die H.223 und H.245 Verhandlung innerhalb der Transportverbindung möglich wird. Um ein Blockieren des Rufaufbaus zu vermeiden, signalisiert der MIK auch dann auf Seiten des IMS, dass lokale so genannten ,,QoS preconditions" erfüllt sind, wenn nach Aufbau der Transportverbindung eine gewisse Zeit lang keine H.223 Signalisierung empfangen wird.
Falls auf Seiten des IMS die SIP „precondition" Erweiterung nicht unterstutzt wird, oder aber auf Seiten des CS-Netzes „forward early media" nicht unterstutzt werden, ist es vorteilhaft, wenn der MIK das IMS-seitige Terminal anweist, solange keine Medienstrome zu senden, bis die H.223 und H.245 Verhandlung innerhalb der CS-seitigen Transportverbindung abgeschlossen ist. Das IMS-Terminal kann diese Information seinem Benutzer anzeigen, und dadurch ebenfalls „Clipping" vermeiden. Dazu nutzt der MIK erfindungsgemaß die in RFC 3264 beschriebene so genannte „hold" Prozedur, also beispielsweise das SDP „inactive" Attribut. Sobald durch das Offnen der logischen H.223 Kanäle für Sprache und Video der CS-seitige Aufbau der Transportverbindung abgeschlossen ist, nutzt der MIK dann erfindungsgemaß die „Resume" Prozedur gemäß RFC 3284, um dem IMS-seitigen Terminal das Senden von Medienstro- men zu gestatten.
Im IMS-T Falle ist es möglich, dass in der Call-Control Signalisierung die Videotelefonie nicht eindeutig erkennbar ist, da nur ein transparenter BS30-Bearer signalisiert wird (z.B. nur Parameter „TMR" mit Wert „UDI" in der „IAM" Nachricht) . In diesem Fall bietet der MIK vorzugsweise neben einem Sprach- und einem Video-Codec auf der IMS-Seite auch andere in Frage kommende Daten-Codecs, beispielsweise den so genannten „Clearmode" Codec, IETF RFC 4040, oder einen FAX Codec, beispielsweise im Format von RFC 3362, an. Durch den „Clearmode" Codec wird es möglich, einen BS30-Datendienst transparent durch das IMS weiterzureichen. Die Verwendung des „Clearmode" Codec ist daher auch vorteilhaft, um das Inter- working in dem Fall zu erleichtern, dass der Verbindungsaufbau vom IMS zu einem anderen MIK weitergeleitet wird. In einer Ausführungsform konfiguriert der MIK die CS-seitige Transportverbindung zunächst nur für den BS30-Service, und schaltet die Datenverbindung noch nicht durch. Sobald der MIK von der IMS-Seite Signalisierung bezüglich der ausgewählten Codecs erhält, kann der MIK erkennen, ob es sich um Videote- lefonie handelt, und startet in diesem Fall die H.223 Inband- Verhandlung. In einer anderen Ausführungsform startet der MIK bereits bei Erhalt der IAM-Nachricht die Inband-Aushandlung mittels H.223 und H.245. Falls der MIK von der IMS-Seite Signalisierung bezüglich der ausgewählten Codecs erhält, und daraus erkennt, dass keine Videotelefonie ausgewählt wurde, beendet der MIK den Versuch der H.223 und H.245 Aushandlung.
Nachfolgend wird detailliert der Rufaufbau für verschiedene Szenarien gemäß dem erfindungsgemäßen Verfahren erläutert.
Figur 2 zeigt mit Hilfe des Signalisierungsverlaufs das Prinzip des Interworkings zwischen der H.245 Signalisierung und auf der CS-Seite und der SIP/SDP CaIl Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) , der beispielsweise aus MGCF und IM-MGW bestehen kann, im Falle eines Rufaufbaus von Seiten des CS-Netzes in Richtung des IMS, der im Weiteren als „IMS terminierender" (IMS- T) Rufaufbau bezeichnet wird. Es sind lediglich für die Erfindung direkt relevante Nachrichten dargestellt.
Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
1. Der MIK erhält eine so genannte BICC oder ISUP „IAM" Nachricht von der CS-Seite. Der MIK erkennt auf Grund der darin enthaltenen Parameter, dass Videotelephonie gewünscht ist oder gewünscht sein könnte. Die IAM-Nachricht enthält keine Angaben über die für Videotelefonie zu verwendenden Sprach- und Video-Codecs. 2. Der MIK wandelt die IAM Nachricht in eine SIP „INVITE" Nachricht um. Erfindungsgemaß macht der MIK in der darin enthaltenen SDP „offer" Angaben über die Sprach- (im Beispiel AMR) und Video-Codecs (im Beispiel H.263 und MP4V-ES) , die wahrscheinlich auf der CS-Seite für die H.324 Videotelephonie unterstutzt werden. Bei der Auswahl der Codecs kann der MIK auch berücksichtigen, welche Codecs der Betreiber des IMS- Netzes wünscht, um beispielsweise nicht zu große Bandbreite für die Übertragung an der Luftschnittstelle zu benotigen. Um den Signalisierungsverlauf und die Implementierung einfach zu halten, ist es vorteilhaft, wenn der MIK nur jeweils einen Sprach- und Video-Codec auswählt, der mit großer Wahrscheinlichkeit auch vom Terminal im IMS unterstutzt wird, beispielsweise den H.263 und den AMR Codec. Dadurch können Schritte 7, 8, 11 und 12 vermieden werden, falls die gewählten Codecs tatsachlich auf der CS-Seite und im IMS unterstutzt werden. Falls der MIK dagegen nicht mit hinreichender Wahrscheinlichkeit weiß, dass jeweils ein bestimmter Sprachcodec und Videocodec auf der CS-Seite und IMS unterstutzt wird, ist es sinnvoll, alle in Frage kommenden Codecs aufzunehmen, um zumindest die Nachrichten 7 und 8 mit gewisser Wahrscheinlichkeit zu vermeiden.
Es ist vorteilhaft wenn der MIK zusatzlich auch den „clearmo- de" Codec, RFC 4040, einfugt, um das Interworking in dem Fall zu erleichtern, dass der Verbindungsaufbau vom IMS zu einem anderen MIK weitergeleitet wird. Durch den Clearmode Codec wird es möglich, einen BS30-Datendienst transparent durch das IMS weiterzureichen.
3. Die Transport Verbindung wird auf Seiten des CS-Netzes aufgebaut. Dann findet durch die Transportverbindung die In- band-Verhandlung des H.223 Multiplexer Levels statt und ein logischer H.223 Kanal zum Austausch von H.245 Nachrichten wird geöffnet.
4. Der MIK erwartet in der Transportverbindung eine H.245 „Terminal Capability Set" Nachricht 5. Nur falls er in einer gewissen Zeit diese Nachricht nicht empfangt, beispielsweise weil sich ein weiter MIK auf der CS-Seite befindet, sendet der MIK erfindungsgemaß eine H.245 „Terminal Capability Set" Nachricht, in der er die in Nachricht 2 gesendeten, bzw. falls Nachricht 6 schon eingetroffen ist, in dieser empfangenen Sprachcodecs und Videocodecs angibt. 5. Der MIK enthalt in der Transportverbindung eine H.245
„Terminal Capability Set" Nachricht. Darin befinden sich Angaben zu den Fähigkeiten des Terminals auf Seiten des CS- Netzes, unter anderem zu den unterstutzten Videocodecs (im Beispiel H.263 und H.261) und Sprachcodecs (im Beispiel G.711 und AMR) unter der genauen Angaben, welche Optionen der einzelnen Codecs unterstutzt werden, und welche Codecs parallel unterstutzt werden können.
6. Der MIK erhalt auf Seiten des IMS eine SIP-Nachricht, die die SDP answer enthalt. In der SDP answer sind diejenigen Co- decs aus der in Nachricht 2 angebotenen Liste enthalten, die vom Terminal auf Seiten des IMS unterstutzt und gewünscht werden, im Beispiel AMR als Sprachcodec und H.263 und MP4V-ES als Videocodecs, aber nicht der Clearmode Codec. Der MIK vergleicht erfindungsgemaß die in Nachrichten 5 und 6 empfange- nen Codecs. Falls die Codecs übereinstimmen, oder ihre
Schnittmenge (im Beispiel H.263 und AMR) zumindest jeweils mindestens einen für den Betreiber akzeptablen Sprach- und Video-Codec enthalt, fahrt der MIK direkt mit Schritt 9 fort.
7. Falls in Nachricht 5 im Vergleich zu Nachricht 2 zusatzli- che Codecs enthalten waren (Im Beispiel der H.261 Videocodec und der G.711 Sprachcodec), kann der MIK entscheiden, dass es wünschenswert ist, zu überprüfen, ob diese zusatzlichen Codecs auf Seiten des IMS unterstutzt werden, beispielsweise weil sie eine höhere Qualität bieten oder vom Betreiber des MIK vorgezogen werden, oder weil die zuvor ermittelte
Schnittmenge keinen Sprach- und/oder Video-Codec enthalt. Im Beispiel entscheidet der MIK, zu überprüfen, ob der H.261 Videocodec auf Seiten des IMS unterstutzt wird. Um eine Überprüfung durchzufuhren, sendet der MIK erfindungsgemaß eine geeigneten SIP-Nachricht, beispielsweise einer re-INVITE oder einer UPDATE Nachricht, mit einer SDP offer, die die Codecs der Schnittmenge und zusatzlich die zu überprüfenden Codecs enthalt .
8. Falls der MIK Nachricht 7 gesendet hat, empfangt er erneut eine SDP „answer" innerhalb einer SIP Nachricht. In der SDP „answer" sind diejenigen Codecs aus der in Nachricht 6 angebotenen Liste enthalten, die das vom Terminal auf Seiten des IMS unterstutzt und gewünscht werden, im Beispiel AMR als Sprachcodec und H.263 und H.261 als Videocodecs.
9. Falls Nachricht 4 nicht gesendet wurde oder die darin ent- haltenen Codecs sich von den in Nachricht 8, bzw. falls
Schritte 7 und 8 übersprungen wurden, in Nachricht 6 empfangenen Codecs unterscheiden, reicht der MIK erfindungsgemaß die in Nachricht 8, bzw. falls Schritte 7 und 8 übersprungen wurden, in Nachricht 6 empfangenen Sprach- und Video-Codecs sowie die Details der Codec-Konfiguration mittels einer H.245 „Terminal Capability Set" Nachricht weiter.
Falls die Schnittmenge der in Nachricht 4 bzw. 9 weitergereichten Codecs und der in Nachricht 5 empfangenen Codecs jeweils nur einen Sprachcodec und Videocodec enthalt, ist es vorteilhaft, Schritt 11 parallel zu Schritt 10 durchzufuhren.
10. Die so genannte H.245 "Master-Slave-Determination" , also die Ermittlung des "Master" bzw. "Slave"-Terminals, wird durchgeführt. Die „Master-Slave-Determination" Nachrichten können auch bereits zusammen mit den „Terminal Capability Set" Nachrichten 5 und 4 bzw. 9 gesendet worden sein. Die
"Master-Slave-Determination" ist nur zum Auflosen eines Ressourcenkonflikts relevant und wird daher in dieser Erfindung nicht weiter betrachtet. Mittels H.245 werden dann so genannte logische Kanäle des H.223 Protokolls zum Übertragen der Sprache und Video geöffnet. Dabei wird jeweils ein
Sprachcodec und ein Videocodec aus der Schnittmenge der in Nachrichten 5 und 4 bzw. 9 übertragenen Codecs ausgewählt.
11. Falls in Nachricht 6 bzw. 8 noch mehr als ein Sprach oder mehr als ein Videocodec enthalten war, sendet der MIK erfin- dungsgemaß eine geeignete SIP Nachricht, beispielsweise einer re-INVITE oder einer UPDATE Nachricht, mit einer SDP „offer", in der der MIK den in Schritt 10 ausgewählten Sprach- und Video-Codec angibt.
12. Falls der MIK Nachricht 11 gesendet hat, empfängt er eine SIP-Nachricht, die die zugehörige SDP „answer" enthält.
Figur 3 stellt mit Hilfe des Signalisierungsverlaufs das Prinzip des Interworkings zwischen der H.245 Signalisierung und auf der CS-Seite und der SIP/SDP CaIl Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) , der beispielsweise aus MGCF und IM-MGW bestehen kann, im Falle eines Rufaufbaus von Seiten des IMS in Richtung des CS-Netzes dar, der im Weiteren als „IMS orginieren- der" (IMS-O) Rufaufbau bezeichnet wird. Es sind lediglich für die Erfindung direkt relevante Nachrichten dargestellt.
Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
1. Der MIK erhält eine SIP „INVITE" Nachricht mit einer SDP „offer", die Angaben über die Sprachcodecs (im Beispiel AMR) und Videocodecs (im Beispiel H.263 und MP4V-ES) enthält, die das Terminal auf der IMS-Seite unterstützt und zur Verwendung für diesen Anruf wünscht. Der MIK erkennt an der Kombination aus Videocodecs und Sprachcodecs, dass Videotelefonie gewünscht wird.
2. Der MIK sendet eine so genannte BICC oder ISUP „IAM" Nach- rieht zur CS-Seite, und gibt darin an, dass Videotelephonie gewünscht wird. Die IAM-Nachricht enthält jedoch keine Angaben über die für Videotelefonie zu verwendenden Sprach- und Video-Codecs .
3. Der MIK sendet auf Seiten des IMS eine SIP-Nachricht, die die SDP answer enthält. Dies ist in vielen Fällen auf Grund von spezifischen Regeln zum Transport von SDP „offer" und „answer" in SIP in RFC 3261 bereits vor dem Aufbau der Transportverbindung auf der CS-Seite in Schritt 4 erforderlich, um den Verbindungsaufbau nicht zu verzögern, und ein sinnvolles Interworking späterer SIP und ISUP/BICC Nachrichten während des Verbindungsaufbaus zu ermöglichen. In der SDP answer fügt der MIK erfindungsgemäß diejenigen Codecs aus der in Nach- rieht 1 angebotenen Liste ein, die wahrscheinlich auf der CS- Seite für die H.324/M Videotelephonie unterstutzt werden (im Beispiel den H.263 Videocodec und den AMR Sprachcodec) . Bei der Auswahl der Codecs kann der MIK auch berücksichtigen, welche Codecs der Betreiber des IMS-Netzes wünscht, um beispielsweise nicht zu große Bandbreite für die Übertragung an der Luftschnittstelle zu benotigen.
Um den Signalisierungsverlauf und Implementierung einfach zu halten, ist es vorteilhaft, wenn der MIK nur jeweils einen Sprach- und Video-Codec auswählt, beispielsweise den H.263 und den AMR Codec. Dadurch können Schritte 7 und 8 vermieden werden, falls die gewählten Codecs tatsachlich auf der CS- Seite unterstutzt werden. Falls der MIK vor Senden von Nachricht 3 schon Nachricht 6 erhalten hat, wählt der MIK aus der Schnittmenge der Codecs in Nachricht 1 und 6 jeweils eine Sprachcodec und Videocodec aus, und fugt diese in Nachricht 3 ein.
4. Die Transport-Verbindung wird auf Seiten des CS-Netzes aufgebaut. Dann findet durch die Transportverbindung die In- band-Verhandlung des H.223 Multiplexer Levels statt und ein logischer H.223 Kanal zum Austausch von H.245 Nachrichten wird geöffnet.
5. Der MIK erwartet in der Transportverbindung eine H.245 „Terminal Capability Set" Nachricht 6. Nur falls er in einer gewissen Zeit diese Nachricht nicht empfangt, beispielsweise weil sich ein weiterer MIK auf der CS-Seite befindet, sendet der MIK erfindungsgemaß eine H.245 „Terminal Capability Set", in der er die in Nachricht 3 gesendeten Sprachcodecs und Videocodecs angibt. 6. Der MIK enthalt in der Transportverbindung eine H.245
„Terminal Capability Set" Nachricht. Darin befinden sich Angaben zu den Fähigkeiten des Terminals auf Seiten des CS- Netzes, unter anderem zu den unterstutzten Videocodecs (im Beispiel MP4V-ES und H.261) und Sprachcodecs (im Beispiel G.711 und AMR) . Der MIK vergleicht erfindungsgemaß die in
Nachricht 5 empfangenen Codecs mit den in Nachricht 3 gesendeten Codecs. Falls in Nachricht 3 jeweils nur ein Videocodec und ein Sprachcodec ausgewählt wurden, und diese Codecs in Nachricht 6 enthalten waren, fahrt der MIK direkt mit Schritt 9 fort (Im Beispiel ist der in Nachricht 3 gesendete Videocodec H.263 nicht in Nachricht 5 enthalten) . 7. Der MIK vergleicht erfindungsgemaß die in Nachricht 6 empfangenen Codecs mit den in Nachricht 1 gesendeten Codecs. Der MIK wählt aus der Schnittmenge der Codecs in Nachrichten 6 und 1 jeweils einen Sprach und Videocodec aus. Der MIK sendet diese Codecs erfindungsgemaß in einer SDP „offer" Nachricht innerhalb einer geeigneten SIP Nachricht, beispielsweise einer re-INVITE oder einer UPDATE Nachricht.
8. Falls der MIK Nachricht 7 gesendet hat, empfangt er erneut eine SDP „answer" innerhalb einer SIP-Nachricht . In der SDP „answer" muss das IMS Terminal die Auswahl der Codecs aus Nachricht 6 bestätigen. Das IMS Terminal wird diese Codecs akzeptieren, da es sie bereits in Nachricht 1 selbst angeboten hat .
9. Falls Nachricht 5 nicht gesendet wurde, reicht der MIK er- findungsgemaß die in Nachricht 7, bzw. falls Schritte 7 und 8 übersprungen wurden, in Nachricht 3 gesendeten Sprach- und Video-Codecs sowie die Details der Codec-Konfiguration mittels einer H.245 „Terminal Capability Set" Nachricht weiter. Falls Nachricht 5 und Nachricht 7 gesendet wurden und die darin enthaltenen Codecs sich unterscheiden, sendet der MIK ebenfalls eine H.245 „Terminal Capability Set" Nachricht und gibt darin die in Nachricht 7 enthaltenen Codecs an.
10. Die so genannte H.245 "Master-Slave-Determination" , also die Ermittlung des "Master" bzw. "Slave"-Terminals, wird durchgeführt. Die „Master-Slave-Determination" Nachrichten können auch bereits zusammen mit den „Terminal Capability Set" Nachrichten 6 und 5 bzw. 9 gesendet worden sein. Die "Master-Slave-Determination" ist nur zum Auflosen eines Ressourcenkonflikts relevant und wird daher in dieser Erfindung nicht weiter betrachtet. Mittels H.245 werden dann so genann- te logische Kanäle des H.223 Protokolls zum Übertragen der
Sprache und Video geöffnet. Dabei werden die bereits in Nach- rieht 5 bzw. 9 ausgewählten Sprachcodecs und Videocodecs verwendet .
Figur 4 stellt mit Hilfe des Signalisierungsverlaufs das In- terworking zwischen der BICC Signalisierung auf der CS-Seite und der SIP/SDP CaIl Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS terminierenden Rufaufbaus dar. Der MIK kann beispielsweise aus MGCF und IM-MGW bestehen. Im CS-Netz wird „Service Change and UDI Fallback" (SCUDIF) gemäß 3GPP TS 23.172 verwendet. Es wird angenommen, dass das CS-Netz so konfiguriert ist, dass es so genannte „forward early media" unterstützt, d.h. bereits vor der BICC ,,ANM" Nachricht vom Anrufer gesendete Nutzdaten weitereicht. Auf Seiten des IMS werden die SIP „Preconditions" (IETF RFC 3312), „Update"
(IETF RFC 3311) und „lOOrel" (IETF RFC 3262) Erweiterungen verwendet. Es wird angenommen, dass das IMS Terminal Videote- lephonie unterstützt und akzeptiert.
Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
1. Der MIK erhält eine so genannte „IAM" Nachricht von der CS-Seite. Gemäß SCUDIF Signalisierung ist darin eine Codecliste enthalten, die für Sprachtelephonie zu verwendende Codecs angibt sowie als Platzhalter für Videotelefonie einen so genannten ,,MuMe" Dummy-Codec, der lediglich anzeigt, dass Videotelefonie gemäß H.324M unterstützt wird, nicht aber welche Sprachcodecs und Videoodecs in diesem Fall unterstützt werden. Da der MuME Codec als erster Codec in der Codecliste enthalten ist, wird er auf CS-Seite bevorzugt, d.h. Videote- lephonie ist gewünscht.
2. Der MIK wandelt die IAM Nachricht in eine SIP „INVITE" Nachricht um. Erfindungsgemäß macht der MIK in der darin enthaltenen SDP „offer" Angaben über die Sprachcodecs (im Beispiel AMR) und Videocodecs (im Beispiel H.263 und MP4V-ES) , die wahrscheinlich auf der CS-Seite für die H.324 Videotele- phonie unterstützt werden, wie bereits für Schritt 2 in Figur 2 beschrieben. Um einen reibungslosen Rufaufbau auch für den Fall, dass auf Seiten des IMS Sprachtelefonie ausgewählt wird, zu gewährleisten, sollte der MIK erfindungsgemäß als weniger bevorzugte Alternative auch die in Nachricht 1 enthaltenen Sprachcodecs angeben. Der MIK nützt die SIP „Precon- ditions" Erweiterung, um anzuzeigen, dass lokal ein Aufbau der Transportverbindung erforderlich ist, bevor der Rufaufbau abgeschlossen werden kann. Dieses ist vorteilhaft, um so genanntes „Clipping" zu vermeiden, dass heißt ein Verlust von Sprache oder Video, die durch den Angerufenen gesendet wird, bevor eine durchgängige Transportverbindung vorhanden ist.
3. Eine SIP „Trying" Nachricht quittiert die INVITE Nachricht .
4. Der MIK empfängt von Seiten des IMS eine SIP „183" Nachricht, die die SDP „answer" enthält. In der SDP answer sind diejenigen Codecs aus der in Nachricht 2 angebotenen Liste enthalten, die vom Terminal auf Seiten des IMS unterstützt und gewünscht werden. Der MIK erkennt daran, dass Videocodec (s) enthalten sind, dass Videotelephonie gewünscht ist, und verfährt wie im Detail für Nachricht 5 in Figur 2 be- schrieben.
5. Der MIK sendet eine BICC „APM" Nachricht, in der als so genannte „available codec list" der MuMe Codec sowie erfindungsgemäß diejenigen Sprachcodecs enthalten sind, die sowohl in Nachricht 1 wie in Nachricht 4 enthalten waren. Als „se- lected codec" wird der ,,MuMe" Codec angegeben. Der MIK entfernt also erfindungsgemäß Sprachcodecs aus Nachricht 4, die nur für Videotelephonie mittels H.324M in Frage kommen, um die Regeln der Out-of-Band BICC Codec-Verhandlung einzuhalten . 6. Gemäß SIP „lOOrel" Extension bestätigt der MIK den Empfang der 183 Nachricht mit einer SIP „PRACK" Nachricht.
7. Die SIP „PRACK" Nachricht wird bestätigt.
8. Die Transportverbindung wird auf Seiten des CS-Netzes aufgebaut . 9. Falls auf Seiten des CS-Netzes die so genannte „Continuity Check" Prozedur verwendet wird, empfängt der MIK eine so genannte BICC „COT" Nachricht. 10. Durch die Transportverbindung des CS-Netzes findet die Inband-Verhandlung des H.223 Multiplexer Levels sowie die in Figur 2 beschriebene H.245 Verhandlung statt.
11. und 12. Wie in Figur 2 für Nachrichten 7 und 8 beschrie- ben, kann es während der H.245 Verhandlung zum Senden einer
SDP „offer" und „answer" kommen. Sie wird mittels einer SIP „UPDATE" Nachricht (IETF RFC 3311) transportiert. 13. Nach Abschluss der H.245 Inband-Verhandlung signalisiert der MIK erfindungsgemäß mit Hilfe der SIP „Preconditions" Er- Weiterung, dass der lokale Aufbau der Transportverbindung abgeschlossen ist. Die Nachricht kann mit Nachricht 11 aus Figur 2 verknüpft werden, falls diese erforderlich ist. Eine SIP „UPDATE" Nachricht wird zum Transport des entsprechenden SDPs verwendet. 14. Die SIP „UPDATE" Nachricht wird bestätigt.
15. Eine SIP „Ringing" Nachricht wird empfangen.
16. Die Information aus Nachricht 15. wird als „ACM" Nachricht weitergereicht.
17. Der angerufene Teilnehmer nimmt den Anruf an. Der MIK empfängt eine SIP „200 OK(INVITE)" Nachricht.
18. Die Information aus Nachricht 17. wird als „ANM" Nachricht weitergereicht.
19. Die SIP „200 OK(INVITE)" wird bestätigt.
Figur 5 stellt mit Hilfe des Signalisierungsverlaufs das In- terworking zwischen der BICC Signalisierung auf der CS-Seite und der SIP/SDP CaIl Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS terminierenden Rufaufbaus dar. Der MIK kann bei- spielsweise aus MGCF und IM-MGW bestehen. Im CS-Netz wird „Service Change and UDI Fallback" (SCUDIF) gemäß 3GPP TS 23.172 verwendet. Auf Seiten des IMS werden die SIP „Preconditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und „lOOrel" (IETF RFC 3262) Erweiterungen verwendet. Es wird an- genommen, dass das IMS Terminal nur Sprachtelephonie unterstützt . Die Signalisierungs-Schritte sind im Einzelnen wie folgt: 1. bis 3. wie in Figur 4 beschrieben.
4. Der MIK empfängt von Seiten des IMS eine SIP „183" Nachricht, die die SDP „answer" enthält. In der SDP answer sind diejenigen Codecs aus der in Nachricht 2 angebotenen Liste enthalten, die vom Terminal von Seiten des IMS unterstützt und gewünscht werden. Der MIK erkennt, dass Sprachtelephonie gewünscht ist, weil nur Sprachcodec (s) enthalten sind.
5. Der MIK sendet eine BICC „APM" Nachricht, in der als so genannte „available codec list" erfindungsgemäß diejenigen
Sprachcodecs enthalten sind, die sowohl in Nachricht 1 wie in Nachricht 4 enthalten waren. Als „selected codec" wird ein Sprachcodec angegeben. Der MIK entfernt also erfindungsgemäß Sprachcodecs aus Nachricht 4, die nur für Videotelephonie mittels H.324M in Frage kommen, um die Regeln der Out-of-Band BICC Codec-Verhandlung einzuhalten.
6. bis 16. Der Rufaufbau schreitet wie in TS 29.163 beschrieben weiter fort.
Figur 6 stellt mit Hilfe des Signalisierungsverlaufs das In- terworking zwischen der BICC Signalisierung auf der CS-Seite und der SIP/SDP CaIl Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS terminierenden Rufaufbaus dar. Der MIK kann bei- spielsweise aus MGCF und IM-MGW bestehen. Im CS-Netz wird „Service Change and UDI Fallback" (SCUDIF) gemäß 3GPP TS 23.172 verwendet. Es wird angenommen, dass das CS-Netz so konfiguriert ist, dass es so genannte „forward early media" nicht unterstützt, d.h. vor der BICC „ANM" Nachricht vom An- rufer gesendete Nutzdaten nicht weitereicht. Auf Seiten des IMS werden die SIP „Preconditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und „lOOrel" (IETF RFC 3262) Erweiterungen verwendet. Es wird angenommen, dass das IMS Terminal Videotelephonie unterstützt und akzeptiert.
Die Signalisierungs-Schritte sind im Einzelnen wie folgt: 1. bis 9. Wie in Figur 4 beschrieben. 10. Falls der MIK durch Konfiguration bereits weiß, dass auf Seiten des CS-Netzes keine „forward early Media" unterstützt werden, überspringt er diesen Schritt. Andernfalls wartet er eine gewisse Zeit darauf, in der Transportverbindung H.223 Signalisierung zu empfangen, um H.223 Multiplexer Levels auszuhandeln. Er stellt dann erfindungsgemäß fest, dass keine „forward early Media" unterstützt werden, und fährt, wie im Weiteren beschrieben, fort.
11. Um den Rufaufbau fortzusetzen, signalisiert der MIK er- findungsgemäß mit Hilfe der „Preconditions" Erweiterung, dass der lokale Aufbau der Transportverbindung abgeschlossen ist. Um „Clipping", dass heißt einen Verlust von Sprache oder Video, die durch den Angerufenen gesendet wird, bevor eine durchgängige Transportverbindung vorhanden ist, zu vermeiden, ist es erfindungsgemäß vorteilhaft, wenn der MIK die Medien im SDP wie in RFC 3264 beschrieben auf „hold" setzt, beispielsweise, indem er sie mit dem so genannten „inactive" Attribut versieht. Eine SIP „UPDATE" Nachricht wird zum Transport des entsprechenden SDPs verwendet. 12. Die SIP „UPDATE" Nachricht wird bestätigt.
13. Eine SIP „Ringing" Nachricht wird empfangen.
14. Die Information aus Nachricht 13 wird als „ACM" Nachricht weitergereicht .
15. Der angerufene Teilnehmer nimmt den Anruf an. Der MIK empfängt eine SIP „200 OK(INVITE)" Nachricht.
16. Die SIP „200 OK (INVITE) "-Nachricht wird bestätigt.
17. Die Information aus Nachricht 15 wird als „ANM" Nachricht weitergereicht .
18. Durch die Transportverbindung des CS-Netzes findet die Inband-Verhandlung des H.223 Multiplexer Levels sowie die in
Figur 2 beschriebene H.245 Verhandlung statt.
19. bis 20. Wie in Figur 2 für Nachrichten 7 und 8 beschrieben, kann es während der H.245 Verhandlung zum Senden einer SDP „offer" und „answer" kommen. Sie wird mittels einer SIP „re-INVITE" Nachricht transportiert.
21. Die SIP „200 OK(INVITE)" 20 wird bestätigt. 22. Falls der MIK die Medien in Nachricht 11 auf „hold" gesetzt hat, aktiviert er sie nach Abschluss der H.245 Inband- Verhandlung wieder, wie in RFC 3264 beschrieben, beispielsweise in dem er SDP ohne das „inactive" Attribut sendet. Die Nachricht kann mit Nachricht 11 aus Figur 2 verknüpft werden, falls dieses erforderlich ist. Eine SIP „re-INVITE" Nachricht wird zum Transport des entsprechenden SDPs verwendet.
23. Die SIP „re-INVITE" Nachricht wird bestätigt.
24. Die SIP „200 OK(INVITE)" 23 wird bestätigt.
Figur 7 stellt mit Hilfe des Signalisierungsverlaufs das In- terworking zwischen der BICC Signalisierung und auf der CS- Seite und der SIP/SDP CaIl Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS terminierenden Rufaufbaus dar. Der MIK kann beispielsweise aus MGCF und IM-MGW bestehen. Im CS-Netz wird „Service Change and UDI Fallback" (SCUDIF) gemäß 3GPP TS 23.172 verwendet. Auf Seiten des IMS werden die SIP „Precon- ditions" (IETF RFC 3312) und „Update" (IETF RFC 3311) Erwei- terungen nicht genützt, aber die SIP „lOOrel" (IETF RFC 3262) Erweiterungen wird verwendet. Es wird angenommen, dass das IMS Terminal Videotelephonie unterstützt und akzeptiert.
Die Signalisierungs-Schritte sind im Einzelnen wie folgt: 1. Wie in Figur 4.
2. Der MIK wandelt die IAM Nachricht in eine SIP „INVITE" Nachricht um. Erfindungsgemäß macht der MIK in der darin enthaltenen SDP „offer" Angaben über die Sprachcodecs (im Beispiel AMR) und Videocodecs (im Beispiel H.263 und MP4V-ES) , die wahrscheinlich auf der CS-Seite für die H.324 Videotelephonie unterstützt werden, wie bereits für Schritt 2 in Figur 2 beschrieben. Um einen reibungslosen Rufaufbau auch für den Fall, dass auf Seiten des IMS Sprachtelefonie ausgewählt wird, zu gewährleisten, sollte der MIK erfindungsgemäß als weniger bevorzugte Alternative auch die in Nachricht 1 enthaltenen Sprachcodecs angeben. Um „Clipping", dass heißt einen Verlust von Sprache oder Video, die durch den Angerufenen gesendet wird, bevor eine durchgängige Transportverbindung vorhanden ist, zu vermeiden, ist es erfindungsgemäß vorteilhaft, wenn der MIK die Medien im SDP wie in RFC 3264 beschrieben auf „hold" setzt, beispielsweise indem er sie mit dem so genannten „inactive" Attribut versieht. 3. bis 10. Wie in Figur 4.
11. bis 15. Wie Nachrichten 15. bis 19. in Figur 4. 16. bis 17. Wie in Figur 2 für Nachrichten 7 und 8 beschrieben, kann es während der H.245 Verhandlung zum Senden einer SDP „offer" und „answer" kommen. Sie wird mittels einer SIP „re-INVITE" Nachricht transportiert.
18. Die SIP „200 OK (INVITE) "-Nachricht wird bestätigt.
19. Falls der MIK die Medien in Nachricht 2 auf „hold" gesetzt hat, aktiviert er sie nach Abschluss der H.245 Inband- Verhandlung wieder, wie in RFC 3264 beschrieben, beispielsweise indem er SDP ohne das „inactive" Attribut sendet. Die Nachricht kann mit Nachricht 11 aus Figur 2 verknüpft werden, falls dieses erforderlich ist. Eine SIP „re-INVITE" Nachricht wird zum Transport des entsprechenden SDPs verwendet. 20. Die SIP „re-INVITE" Nachricht wird bestätigt.
21. Die SIP „200 OK (INVITE) "-Nachricht wird bestätigt.
Figur 8 stellt mit Hilfe des Signalisierungsverlaufs das In- terworking zwischen der BICC Signalisierung auf der CS-Seite und der SIP/SDP CaIl Control Signalisierung auf Seiten des
IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS terminierenden Rufaufbaus dar. Der MIK kann beispielsweise aus MGCF und IM-MGW bestehen. Im CS-Netz wird „Service Change and UDI Fallback" (SCUDIF) gemäß 3GPP TS 23.172 verwendet. Auf Seiten des IMS werden die SIP „Precon- ditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und „lOOrel" (IETF RFC 3262) Erweiterungen nicht genützt. Es wird angenommen, dass das IMS Terminal Videotelephonie unterstützt und akzeptiert.
Die Signalisierungs-Schritte sind im Einzelnen wie folgt: 1. bis 3. Wie in Figur 7. 4. Um den Rufaufbau fortzusetzen, sendet der MIK eine BICC „APM" Nachricht. Zu diesem Zeitpunkt hat der MIK noch keine Kenntnis, ob Videotelefonie auf Seiten des IMS akzeptiert wird, und welche Codecs unterstützt werden. Der MIK nimmt an, dass Videotelefonie akzeptiert wird und wählt Sprachcodecs aus der in Nachricht 1 enthaltenen Liste aus, die wahrscheinlich auf Seiten des IMS unterstützt werden, beispielsweise den „AMR" Codec. Der MIK fügt diese Sprachcodecs und den „Mu- Me" Codec in die so genannte „available codec list" ein. Als „selected codec" wird der ,,MuMe" Codec angegeben.
5. bis 9. Wie Nachrichten 8 bis 12 in Figur 7.
10. Der MIK empfängt auf Seiten des IMS eine SIP „200 OK(INVITE)" Nachricht, die die SDP „answer" enthält. In der SDP answer sind diejenigen Codecs aus der in Nachricht 2 an- gebotenen Liste enthalten, die vom Terminal auf Seiten des
IMS unterstützt und gewünscht werden. Der MIK erkennt daran, dass Videocodec (s) enthalten sind, dass Videotelephonie gewünscht ist, und verfährt wie im Detail für Nachricht 5 in Figur 2 beschrieben. 11. bis 18. Wie Nachrichten 14 bis 21 in Figur 7.
Figur 9 stellt mit Hilfe des Signalisierungsverlaufs das In- terworking zwischen der BICC Signalisierung auf der CS-Seite und der SIP/SDP CaIl Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS terminierenden Rufaufbaus dar. Der MIK kann beispielsweise aus MGCF und IM-MGW bestehen. Im CS-Netz wird „Service Change and UDI Fallback" (SCUDIF) gemäß 3GPP TS 23.172 verwendet. Auf Seiten des IMS werden die SIP „Precon- ditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und
„lOOrel" (IETF RFC 3262) Erweiterungen nicht genützt. Es wird angenommen, dass das IMS Terminal nur Sprachtelephonie unterstützt .
Die Signalisierungs-Schritte sind im Einzelnen wie folgt: 1. bis 9. Wie in Figur 9. 10. Der MIK empfängt auf Seiten des IMS eine SIP „200 OK(INVITE)" Nachricht, die die SDP „answer" enthält. In der SDP answer sind diejenigen Codecs aus der in Nachricht 2 angebotenen Liste enthalten, die vom Terminal auf Seiten des IMS unterstützt und gewünscht werden. Der MIK erkennt daran, dass keine Videocodec (s) , aber Sprachcodecs enthalten sind, dass Sprachtelephonie gewünscht ist.
11. Der MIK bricht die H.223 und H.245 Verhandlung ab.
12. bis 13. Wie Nachrichten 11 und 12 in Figur 9. 14. Falls der MIK die Medien in Nachricht 2 auf „hold" gesetzt hat, aktiviert er sie nach Abschluss der H.245 Inband- Verhandlung wieder, wie in RFC 3264 beschrieben, beispielsweise indem er SDP ohne das „inactive" Attribut sendet. Eine SIP „re-INVITE" Nachricht wird zum Transport des entsprechen- den SDPs verwendet.
15. Die SIP „re-INVITE" Nachricht wird bestätigt.
16. Die SIP „200 OK(INVITE)" 15 wird bestätigt.
17. bis 18. Der MIK nützt die so genannte BICC „Codec Modifi- cation" Prozedur, um auf Seiten des CS-Netzes auf Sprachtele- fonie umzuschalten.
Figur 10 stellt mit Hilfe des Signalisierungsverlaufs das In- terworking zwischen der ISUP Signalisierung auf der CS-Seite und der SIP/SDP CaIl Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS terminierenden Rufaufbaus dar. Der MIK kann beispielsweise aus MGCF und IM-MGW bestehen. Es wird angenommen, dass das CS-Netz so konfiguriert ist, dass es so genannte „forward early media" unterstützt, d.h. bereits vor der BICC „ANM" Nachricht vom Anrufer gesendete Nutzdaten weitereicht. Auf Seiten des IMS werden die SIP „Preconditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und „lOOrel" (IETF RFC 3262) Erweiterungen verwendet. Es wird angenommen, dass das IMS Terminal Videotelephonie unterstützt und akzeptiert.
Die Signalisierungs-Schritte sind im Einzelnen wie folgt: 1. Der MIK erhält eine so genannte ISUP „IAM" Nachricht von der CS-Seite und erkennt oder vermutet auf Grund der signalisierten Parameter, beispielsweise auf Grund des Wertes „UDI" im Parameter TMR sowie geeignete Werte im Parameter „USI", dass Videotelefonie erwünscht.
2. Der MIK wandelt die IAM Nachricht in eine SIP „INVITE" Nachricht um. Erfindungsgemäß macht der MIK in der darin enthaltenen SDP „offer" Angaben über die Sprach- (im Beispiel AMR) und Videocodecs (im Beispiel H.263 und MP4V-ES) , die wahrscheinlich auf der CS-Seite für die H.324 Videotelephonie unterstützt werden, wie bereits für Schritt 2 in Figur 2 beschrieben. Der MIK nützt die SIP „Preconditions" Erweiterung, um anzuzeigen, dass lokal ein Aufbau der Transportverbindung erforderlich ist, bevor der Rufaufbau abgeschlossen werden kann. Dieses ist vorteilhaft, um so genanntes „Clipping" zu vermeiden, dass heißt ein Verlust von Sprache oder Video, die durch den Angerufenen gesendet wird, bevor eine durchgängige Transportverbindung vorhanden ist. Für den Fall, dass der MIK nicht sicher entscheiden kann, ob Videotelefonie oder ein anderer Datendienst gewünscht ist, kann der MIK zusätzlich für andere Datendienste geeignete Codecs einfügen, beispielsweise einen FAX codec „t38" gemäß RFC 3362. Falls das angerufene Terminal nur einen bestimmten Datendienst unterstützt, wird es den entsprechenden Datendienst auswählen. Der Anrufer hat möglicherweise ebenfalls gewusst, dass das Terminal nur diesen bestimmten Datendienst unterstützt, und sendet entsprechend diesen Datendienst.
3. bis 4. Wie in Figur 4.
6. bis 7. Wie Nachrichten 7. bis 8. in Figur 4. 7. bis 17. Wie Nachrichten 9. bis 19. in Figur 4.
Figur 11 stellt mit Hilfe des Signalisierungsverlaufs das In- terworking zwischen der SIP Signalisierung auf der CS-Seite und der SIP/SDP CaIl Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS terminierenden Rufaufbaus dar. Der MIK kann beispielsweise aus MGCF und IM-MGW bestehen. Auf Seiten des IMS werden die SIP „Preconditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und „lOOrel" (IETF RFC 3262) Erweiterungen nicht genützt. Es wird angenommen, dass das IMS Terminal Vi- deotelephonie unterstützt und akzeptiert.
Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
1. bis 3. Wie in Figur 10.
4. bis 16. Wie Nachrichten 6. bis 18. in Figur 8
Figur 12 stellt mit Hilfe des Signalisierungsverlaufs das In- terworking zwischen der BICC Signalisierung auf der CS-Seite und der SIP/SDP CaIl Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS originierenden Rufaufbaus dar. Der MIK kann bei- spielsweise aus MGCF und IM-MGW bestehen. Im CS-Netz wird „Service Change and UDI Fallback" (SCUDIF) gemäß 3GPP TS 23.172 verwendet. Auf Seiten des IMS werden die SIP „Precon- ditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und „lOOrel" (IETF RFC 3262) Erweiterungen verwendet. Es wird an- genommen, dass das CS Terminal Videotelephonie unterstützt und akzeptiert.
Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
1. Der MIK erhält eine so genannte SIP „INVITE" Nachricht, die eine SDP „offer" enthält. In der SDP offer sind Codecs enthalten, die vom Terminal auf Seiten des IMS unterstützt und die für den Ruf gewünscht werden. Der MIK erkennt daran, dass Videocodec (s) enthalten sind, dass Videotelephonie gewünscht ist, und verfährt wie im Detail für Nachricht 1 in Figur 3 beschrieben.
2. Der MIK sendet eine so genannte „IAM" Nachricht zur CS- Seite. Gemäß SCUDIF Signalisierung ist darin eine Codecliste enthalten, die für Sprachtelephonie zu verwendende Codecs angibt sowie als Platzhalter für Videotelefonie einen so ge- nannten „MuMe" Dummy-Codec, der lediglich anzeigt, dass Videotelefonie gemäß H.324M unterstützt wird, nicht aber welche Sprachcodecs und Videocodecs in diesem Fall unterstützt wer- den. Als Sprachcodecs wählt der MIK vorzugsweise die in Nachricht 1 enthaltenen Codecs. Der MIK fügt den MuME Codec als ersten Codec in die Codecliste ein, um auszudrücken, dass Videotelephonie gewünscht ist. 3. Eine SIP „Trying" Nachricht quittiert die INVITE Nachricht .
4. Der MIK empfängt eine BICC „APM" Nachricht, in der als so genannter „selected codec" der „MuMe" Codec angegeben ist. Daraus erkennt der MIK, dass auch das CS Terminal Videotele- fonie unterstützt. In der „available codec list" der MuMe Codec sind Sprachcodecs enthalten, die das CS Terminal für Sprachtelefonie unterstützt.
5. Die Transportverbindung wird auf Seiten des CS-Netzes aufgebaut . 6. Der MIK sendet auf Seiten des IMS eine SIP „183" Nachricht, die die SDP „answer" enthält, wie für Nachricht 3 in Figur 3 im Detail beschrieben.
7. Gemäß SIP „lOOrel" Extension empfängt der MIK eine SIP „PRACK" Nachricht als Bestätigung der 183 Nachricht mit. 8. Die SIP „PRACK" Nachricht wird bestätigt.
9. Der MIC empfängt eine SIP „UPDATE" Nachricht, die mit Hilfe der SIP „Preconditions" Erweiterung anzeigt, dass auf Seiten des IMS Terminals der lokale Aufbau der Transportverbindung abgeschlossen ist. 10. Falls auf Seiten des CS-Netzes die so genannte „Continui- ty Check" Prozedur verwendet wird, sendet der MIK eine so genannte BICC „COT" Nachricht.
11. Die SIP „UPDATE" Nachricht wird bestätigt.
12. Durch die Transportverbindung des CS-Netzes findet die Inband-Verhandlung des H.223 Multiplexer Levels sowie die in
Figur 3 beschriebene H.245 Verhandlung statt.
13. und 14. Wie in Figur 3 für Nachrichten 7 und 8 beschrieben, kann es während der H.245 Verhandlung zum Senden einer SDP „offer" und „answer" kommen. Sie wird mittels einer SIP „UPDATE" Nachricht (IETF RFC 3311) transportiert. Sollte zu diesem Zeitpunkt Nachricht 20 bereits gesendet worden sein, wird statt der „UPDATE" Nachricht eine SIP „re-INVITE" Nachricht verwendet.
15. Eine „ACM" Nachricht wird empfangen.
16. Die Information aus Nachricht 15 wird als SIP „Ringing" Nachricht weitergereicht.
17. Der angerufene Teilnehmer nimmt den Anruf an. Der MIK empfängt eine „ANM" Nachricht Nachricht.
18. Die Information aus Nachricht 17 wird als SIP „200 OK(INVITE)" weitergereicht. 19. Die SIP „200 OK(INVITE)" wird bestätigt.
Figur 13 stellt mit Hilfe des Signalisierungsverlaufs das In- terworking zwischen der BICC Signalisierung auf der CS-Seite und der SIP/SDP CaIl Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS originierenden Rufaufbaus dar. Der MIK kann beispielsweise aus MGCF und IM-MGW bestehen. Im CS-Netz wird „Service Change and UDI Fallback" (SCUDIF) gemäß 3GPP TS 23.172 verwendet. Auf Seiten des IMS werden die SIP „Precon- ditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und
„lOOrel" (IETF RFC 3262) Erweiterungen verwendet. Es wird angenommen, dass das CS Terminal nur Sprachtelephonie unterstützt und akzeptiert.
Die Signalisierungs-Schritte sind im Einzelnen wie folgt: 1. bis 3. Wie Figur 12.
4. Der MIK empfängt eine BICC „APM" Nachricht, in der als „a- vailable codec list" nur Sprachcodecs enthalten sind. Daraus erkennt der MIK, dass das CS Terminal nur Sprachtelefonie un- terstützt.
5. Die Transportverbindung wird auf Seiten des CS-Netzes aufgebaut .
6. Der MIK sendet auf Seiten des IMS eine SIP „183" Nachricht, die die SDP „answer" für Nachricht 1 enthält. Darin gibt der MIK nur Sprachcodecs an.
7. bis 16. Der Rufaufbau für Sprachtelefonie schreitet wie in TS 29.163 beschrieben voran. Figur 14 stellt mit Hilfe des Signalisierungsverlaufs das In- terworking zwischen der BICC Signalisierung auf der CS-Seite und der SIP/SDP CaIl Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS originierenden Rufaufbaus dar. Der MIK kann beispielsweise aus MGCF und IM-MGW bestehen. Im CS-Netz wird „Service Change and UDI Fallback" (SCUDIF) gemäß 3GPP TS 23.172 verwendet. Auf Seiten des IMS werden die SIP „Precon- ditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und
„lOOrel" (IETF RFC 3262) Erweiterungen nicht verwendet. Es wird angenommen, dass das CS Terminal Videotelephonie unterstützt und akzeptiert.
Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
I. bis 5. Wie Figur 12
6. Falls auf Seiten des CS-Netzes die so genannte „Continuity Check" Prozedur verwendet wird, sendet der MIK eine so genannte BICC „COT" Nachricht. 7. Durch die Transportverbindung des CS-Netzes findet die
Inband-Verhandlung des H.223 Multiplexer Levels sowie die in Figur 3 beschriebene H.245 Verhandlung statt.
8. Eine „ACM" Nachricht wird empfangen.
9. Die Information wird als SIP „Ringing" Nachricht weiterge- reicht.
10. Der angerufene Teilnehmer nimmt den Anruf an. Der MIK empfängt eine „ANM" Nachricht.
II. Der MIK sendet auf Seiten des IMS eine SIP „200 OK(INVITE)" Nachricht, die die SDP „answer" enthält, wie für Nachricht 3 in Figur 3 im Detail beschrieben.
12. Die SIP „200 OK(INVITE)" wird bestätigt.
13. und 14. Wie in Figur 3 für Nachrichten 7 und 8 beschrieben, kann es während der H.245 Verhandlung zum Senden einer SDP „offer" und „answer" kommen. Sie wird mittels einer SIP „re. INVITE" Nachricht transportiert.
15. Die SIP „200 OK(INVITE)" wird bestätigt. Figur 15 stellt mit Hilfe des Signalisierungsverlaufs das In- terworking zwischen der ISUP Signalisierung auf der CS-Seite und der SIP/SDP CaIl Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS originierenden Rufaufbaus dar. Der MIK kann beispielsweise aus MGCF und IM-MGW bestehen. Auf Seiten des IMS werden die SIP „Preconditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und „lOOrel" (IETF RFC 3262) Erweiterungen verwendet. Es wird angenommen, dass das CS Terminal Videote- lephonie unterstützt und akzeptiert.
Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
1. Wie Figur 12.
2. Der MIK sendet eine so genannte „IAM" Nachricht zur CS- Seite. Der MIK drückt darin aus, dass Videotelephonie gewünscht wird, zum Beispiel durch Wahl von Wert „UDI" für Parameter TMR und geeigneter Werte im Parameter ,,USI".
3. Wie Figur 12.
4. bis 17. Wie Nachrichten 6 bis 19 in Figur 12.
Figur 16 stellt mit Hilfe des Signalisierungsverlaufs das Interworking zwischen der ISUP Signalisierung auf der CS-Seite und der SIP/SDP CaIl Control Signalisierung auf Seiten des IMS durch einen Multimedia Interworking Knoten (MIK) im Falle eines IMS originierenden Rufaufbaus dar. Der MIK kann beispielsweise aus MGCF und IM-MGW bestehen. Auf Seiten des IMS werden die SIP „Preconditions" (IETF RFC 3312), „Update" (IETF RFC 3311) und „lOOrel" (IETF RFC 3262) Erweiterungen nicht verwendet. Es wird angenommen, dass das CS Terminal Vi- deotelephonie unterstützt und akzeptiert.
Die Signalisierungs-Schritte sind im Einzelnen wie folgt:
1. Wie Figur 14.
2. Der MIK sendet eine so genannte „IAM" Nachricht zur CS- Seite. Der MIK drückt darin aus, dass Videotelephonie gewünscht wird, zum Beispiel durch Wahl von Wert „UDI" für Parameter TMR und geeigneter Werte im Parameter „USI". 3. Wie Figur 14.
4. bis 13. Wie Nachrichten 6 bis 15 in Figur 14.

Claims

Patentansprüche
1. Verfahren zum Aufbau einer Videotelefonverbindung und/oder Multimediatelefonverbindung in einem Datennetz umfassend ein Telefonnetz (CS) und ein auf dem Internet Protokoll basierendes IP-Netz (IMS), bei dem: a) ein Rufaufbau zwischen einem ersten Teilnehmer (MSl), der sich im oder benachbart zum Telefonnetz (CS) befindet, und einem zweiten Teilnehmer (MS2), der sich im o- der benachbart zum IP-Netz (IMS) befindet, über das Telefonnetz (CS) und das IP-Netz (IMS) mithilfe eines ersten Signalisierungsprotokolls (BICC) im Telefonnetz (CS) und eines zweiten Signalisierungsprotokolls (SIP) im IP- Netz durchgeführt wird; b) beim Rufaufbau Signalisierungsnachrichten des ersten
Signalisierungsprotokolls (BICC) in Signalisierungsnachrichten des zweiten Signalisierungsprotokolls (SIP) und/oder umgekehrt umgewandelt werden; c) in Schritt b) ein oder mehrere Codierungen festgelegt werden, welche bei der Übertragung der wahrend der Videotelefonverbindung ausgetauschten Nutzdaten im Telefonnetz (CS) verwendbar und/oder voraussichtlich verwendbar sind; d) die in Schritt c) festgelegten Codierungen mit einer o- der mehreren Signalisierungsnachrichten des zweiten Signalisierungsprotokolls (SIP) in das IP-Netz (IMS) gesendet werden; e) nach und/oder wahrend der Durchfuhrung des Rufaufbaus eine Datenverbindung zur Übertragung der wahrend der Vi- deotelefonverbindung ausgetauschten Nutzdaten aufgebaut wird; f) innerhalb der Datenverbindung auf Seiten des Telefonnetzes (CS) mithilfe eines dritten Signalisierungsprotokolls (H.245) die für die Nutzdaten verwendete Codierung bestimmt wird.
2. Verfahren nach Anspruch 1, wobei das Datennetz ein 3GPP- Netz (3GPP = 3rd Generation Partnership Project) ist.
3. Verfahren nach Anspruch 1 oder 2, wobei das Telefonnetz ein CS-Netz (CS = Circuit Switched) und/oder ein PSTN-Netz
(PSTN = Public Swiched Telephone Network) ist.
4. Verfahren nach einem der vorhergehenden Ansprüche, bei dem das erste Signalisierungsprotokoll BICC (BICC = Bearer Inde- pendent CaIl Control) und/oder ISUP (ISUP = ISDN User Part) ist .
5. Verfahren nach einem der vorhergehenden Ansprüche, bei dem das IP-Netz (IMS) ein IMS-Netz (IMS = IP Multimedia Subsys- tem) ist.
6. Verfahren nach einem der vorhergehenden Ansprüche, bei dem das zweite Signalisierungsprotokoll SIP/SDP ist (SIP = Session Initiation Protocol; SDP = Session Description Protocol) ist.
7. Verfahren nach Anspruch 6, wobei das SIP/SDP-Protokoll die Preconditions-Erweiterung beinhaltet und die Erweiterung verwendet wird, um nach Schritt f) zu signalisieren, dass der Aufbau einer Transportverbindung im Telefonnetz (CS) abgeschlossen ist.
8. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Schritte b) bis d) in einem oder mehreren Schnittstellen- knoten zwischen dem Telefonnetz (CS) und dem IP-Netz (ISM) durchgeführt werden.
9. Verfahren nach Anspruch 8, bei dem die Schnittstellenknoten einen MGCF-Knoten (MGCF = Media Gateway Control Function) und einen IM-MGW-Knoten (IM-MGW = IMS Media Gateway) umfassen .
10. Verfahren nach einem der vorhergehenden Ansprüche, bei dem der Aufbau der Datenverbindung in Schritt e) mithilfe der H.324-Protokollfamilie, insbesondere der H.324M-Protokoll- familie, erfolgt.
11. Verfahren nach einem der vorhergehenden Ansprüche, wobei das oder die Codierungen in Schritt c) in Abhängigkeit von dem verwendeten Telefonnetz (CS) festgelegt werden.
12. Verfahren nach einem der vorhergehenden Ansprüche, wobei das oder die Codierungen in Schritt c) in Abhängigkeit von der Rufnummer des ersten Teilnehmers (MSl) festgelegt werden.
13. Verfahren nach einem der vorhergehenden Ansprüche, bei dem in Schritt c) diejenigen Codierverfahren festgelegt werden, die in Abhängigkeit von dem verwendeten Telefonnetz (CS) und dem verwendeten IP-Netz (ISM) am wahrscheinlichsten in beiden Netzen verwendet werden.
14. Verfahren nach einem der vorhergehenden Ansprüche, wobei in den Signalisierungsnachrichten des ersten Signalisierungs- protokolls Informationen über im Telefonnetz (CS) verwendbare Sprachcodierungen enthalten sind, wobei in Schritt c) unter anderem diese Sprachcodierungen festgelegt werden.
15. Verfahren nach einem der vorhergehenden Ansprüche, wobei beim Aufbau der Datenverbindung im Schritt f) eine oder mehrere erste Spezifikations-Nachrichten (TCS) im Telefonnetz (CS) übertragen werden, welche jeweils die im ersten Teilneh- mer (MSl) verwendbaren Codierungen spezifizieren.
16. Verfahren nach Anspruch 15, bei dem die in einer ersten Spezifikations-Nachricht (TCS) spezifizierten Codierungen mit den in Schritt c) festgelegten Codierungen verglichen werden.
17. Verfahren nach Anspruch 16, bei dem, wenn der Vergleich der in der ersten Spezifikations-Nachricht (TCS) spezifizier- ten Codierungen mit den in Schritt c) festgelegten Codierungen ergibt, dass die Codierungen nicht oder nur teilweise u- bereinstimmen, eine Signalisierungsnachricht des zweiten Sig- nalisierungsprotokolls (SIP) in das IP-Netz gesendet wird, welche zumindest teilweise die in der ersten Spezifikations- Nachricht (TCS) spezifizierten Codierungen enthalt.
18. Verfahren nach einem der vorhergehenden Ansprüche, wobei Signalisierungsnachrichten des zweiten Signalisierungsproto- kolls (SIP) im IP-Netz (IMS) übertragen werden, welche die im zweiten Teilnehmer (MS2) verwendbaren Codierungen spezifizieren, wobei die in diesen Signalisierungsnachrichten enthaltenen Codierungen mit einer zweiten Spezifikations-Nachricht beim Aufbau der Datenverbindung in Schritt e) in das Telefon- netz (CS) gesendet werden.
19. Verfahren nach Anspruch 18 in Kombination mit Anspruch 15, wobei eine Signalisierungsnachricht des zweiten Signali- sierungsprotokolls (SIP) , welche die im zweiten Teilnehmer (MS2) verwendbaren Codierungen spezifiziert, mit einer ersten Spezifikations-Nachricht verglichen wird und der Aufbau der Videotelefonverbindung abgebrochen wird oder ein Umschalten auf Sprachtelefonie, vorzugsweise mit Hilfe der SCUDIF- "Service Change"-Prozedur gemäß dem 3GPP-Standard 3GPP TS 23.172, veranlasst wird, wenn nicht zumindest eine Übereinstimmung von für eine Videotelefonverbindung erforderlichen Codierungen in der Signalisierungsnachricht und der ersten Spezifikations-Nachricht vorliegt .
20. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die in Schritt c) festgelegten Codierungen Sprach- und Videocodierungen umfassen.
21. Verfahren nach Anspruch 20, bei dem die in Schritt c) festgelegten Codierungen neben den Sprach- und Videocodierungen weitere Datencodierungen umfassen.
22. Verfahren nach einem der vorhergehenden Ansprüche, bei dem der zweite Teilnehmer (MS2) angewiesen wird, keine Nutzdaten zu übertragen, bis ein vorbestimmter Verfahrensabschnitt des Aufbau der Datenverbindung, insbesondere der Auf- bau der Transportverbindung im Telefonnetz (CS) , abgeschlossen ist.
23. Datennetz, umfassend ein Telefonnetz (CS) und ein auf dem Internet Protokoll basierendes IP-Netz (IMS), wobei das Da- tennetz derart ausgestaltet ist, dass ein Verfahren nach einem der vorhergehenden Ansprüche durchführbar ist.
24. Datennetz nach Anspruch 23, wobei das Datennetz einen o- der mehrere Schnittstellenknoten zwischen dem Telefonnetz (CS) und dem IP-Netz (IMS) zur Durchführung der Schritte b) bis d) des Verfahrens nach Anspruch 1 enthält.
25. Datennetz nach Anspruch 24, wobei die Schnittstellenknoten einen MGCF-Knoten (MGCF = Media Gateway Control Function) und einen IM-MGW-Knoten (IM-MGW = IMS Media Gateway) umfassen .
EP06793368A 2005-10-21 2006-09-08 Verfahren zum aufbau einer videotelefonverbindung und/oder multimediatelefonverbindung in einem datennetz Withdrawn EP1938551A1 (de)

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 (de) 2005-10-21 2006-09-08 Verfahren zum aufbau einer videotelefonverbindung und/oder multimediatelefonverbindung in einem datennetz

Publications (1)

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

Family

ID=37085301

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06793368A Withdrawn EP1938551A1 (de) 2005-10-21 2006-09-08 Verfahren zum aufbau einer videotelefonverbindung und/oder multimediatelefonverbindung in einem datennetz

Country Status (7)

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

Families Citing this family (31)

* 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
JP5112447B2 (ja) * 2006-12-08 2013-01-09 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 通信ネットワーク環境におけるアナウンスメディアの処理
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
ES2619423T3 (es) * 2007-05-22 2017-06-26 Telefonaktiebolaget Lm Ericsson (Publ) Método, aparatos y programa informático para configurar dinámicamente una función de control de sesión de llamada proxy del subsistema multimedia IP desde un servidor de reglas de control de política
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业务测试系统和方法
WO2012006310A1 (en) * 2010-07-06 2012-01-12 Interdigital Patent Holdings, Inc. Ip multimedia subsystem (ims)-based pre-negotiation of video codec for video single radio video call continuity
EP3554127B1 (de) * 2010-11-10 2020-09-09 Panasonic Intellectual Property Corporation of America Endgerät und codierungsmodusauswahlverfahren
JP2012105210A (ja) * 2010-11-12 2012-05-31 Ntt Docomo Inc コアネットワークおよび通信システム
JP2012105211A (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 华为技术有限公司 一种建立主被叫间呼叫连接的方法及装置
CN103548369B (zh) 2011-06-09 2017-07-21 松下电器（美国）知识产权公司 网络节点、终端、带宽变更判断方法及带宽变更方法
US8966095B2 (en) * 2011-07-08 2015-02-24 Avaya Inc. Negotiate multi-stream continuous presence
WO2013024464A2 (en) 2011-08-17 2013-02-21 Telefonaktiebolaget L M Ericsson (Publ) Mechanism for dynamic signaling of encoder capabilities
CN102984493B (zh) * 2012-11-21 2016-03-02 华为终端有限公司 视频数据传输的方法、装置及通信设备
CN103856461A (zh) * 2012-12-04 2014-06-11 联芯科技有限公司 Ims业务实时媒体流的协商式调节方法
WO2015174018A1 (ja) * 2014-05-13 2015-11-19 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ ネットワークノード及びシグナリング処理方法
US10148703B2 (en) 2014-10-09 2018-12-04 T-Mobile Usa, Inc. Service capabilities in heterogeneous network
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 ネットワーク接続装置における音声符号化方法
ES2375304T3 (es) * 1999-05-17 2012-02-28 Telefonaktiebolaget Lm Ericsson (Publ) Negociación de capacidad en una red de telecomunicaciones.
EP1192773B1 (de) * 1999-07-12 2012-04-11 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Verfahren und system für den informationsaustausch zwischen multimedia-netzknoten
JP3764609B2 (ja) * 1999-09-08 2006-04-12 株式会社エヌ・ティ・ティ・ドコモ 制御装置、交換機、制御方法および符号化変換方法
ATE484933T1 (de) * 2000-08-14 2010-10-15 Nokia Siemens Networks Oy Kommunikationssystem und verfahren zum bereitstellen eines verfahrens zur auswahl der betriebsart
US20020078151A1 (en) * 2000-12-15 2002-06-20 Wickam Bryce C. System for communicating messages of various formats between diverse communication devices
DE60042461D1 (de) * 2000-12-22 2009-08-06 Nokia Corp Verfahren und system für den aufbau einer multimedia verbindung durch austausch der übertragungskapazitäten in einem ausserband-signalisierungskanal
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
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
CN1754368B (zh) * 2003-02-24 2011-06-15 三菱电机株式会社 通信服务单元以及连接顺序执行方法
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 (de) * 2003-08-18 2005-02-23 Siemens Aktiengesellschaft Verfahren, Software-Produkt und Vorrichtungen zur Signalisierung der Modifikation von Bearerverbindungen mittels SIP Protokoll
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
WO2007045527A1 (de) 2007-04-26
US10075479B2 (en) 2018-09-11
JP5237816B2 (ja) 2013-07-17
JP2009512379A (ja) 2009-03-19
KR101422223B1 (ko) 2014-07-22
US20090290573A1 (en) 2009-11-26
DE102005050586B3 (de) 2006-11-02
KR20080069617A (ko) 2008-07-28
CN101292497A (zh) 2008-10-22

Similar Documents

Publication Publication Date Title
DE102005050586B3 (de) Verfahren zum Aufbau einer Videotelefonverbindung und/oder Multimediatelefonverbindung in einem Datennetz
EP1938625B1 (de) Verfahren zum weiterleiten von signalisierungsdaten in einer netzübergangseinheit und in einer steuereinheit
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
EP2073480B1 (de) Verfahren zur Zuordnung von zumindest einer Nutzdatenverbindung zu zumindest einer Multiplexverbindung
DE102005036298B3 (de) Verfahren und Kommunikationssystem zur Auswahl eines Übertragungsmodus' für eine Übermittlung von Nutzdaten
WO2004045182A1 (de) Übertragung von anrufsteuerungsparameter zwischen zwei media gateway controllern in sip/sip-t netzen ______________________________________________________________________________________
DE102005031167A1 (de) Verfahren, Server-Einrichtung und Umsetzeinrichtung zum Aufbauen einer Nutzdatenverbindung
WO2005039140A1 (de) Behandlung von early media ii
DE60212988T2 (de) Verfahren, Einrichtung und Computerprogramm zur Auswahl einer Medienübergangskontrollfunktion basierend auf der Überwachung von Resourcen von Medienübergangsfunktionen
EP1673918B1 (de) Behandlung von Early Media-Daten I
EP1493285B1 (de) Call hold / terminal portability in h.323/isup-bicc-sip netzen
DE102004040480B4 (de) Verfahren und Vorrichtung zum Nutzdatenabgriff multimedialer Verbindungen in einem Paketnetz
EP1430701B1 (de) Verfahren zum steuern von leistungsmerkmalen in paketorientierten kommunikationssystemen
EP1845676A1 (de) Verfahren zur Videotelefonie zwischen einem ersten Endgerät in einem leitungsvermittelten Datennetz und einem zweiten Endgerät in einem paketvermittelten Datennetz
DE102005045121B4 (de) Vorrichtung zur Unterstützung des Leistungsmerkmals "Fall-back" in SIP-Netzen
WO2007141190A1 (de) Verfahren zur unterstützung von handoff calls for ims/cs handover in existierenden hybrid ims/cs networks
WO2007065738A1 (de) Vorrichtung und verfahren zur unterstützung von fax t.38 anwendungen in fmc netzen
WO2004047470A1 (de) Übermittlung von sprachdaten in einem mobilfunknetz bestehend aus einem funkzugangsnetz und einem vermittlungsnetz

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