WO2009111991A1 - Procédé et dispositif de réalisation de l’interfonctionnement entre le domaine ims et le domaine cs - Google Patents

Procédé et dispositif de réalisation de l’interfonctionnement entre le domaine ims et le domaine cs Download PDF

Info

Publication number
WO2009111991A1
WO2009111991A1 PCT/CN2009/070785 CN2009070785W WO2009111991A1 WO 2009111991 A1 WO2009111991 A1 WO 2009111991A1 CN 2009070785 W CN2009070785 W CN 2009070785W WO 2009111991 A1 WO2009111991 A1 WO 2009111991A1
Authority
WO
WIPO (PCT)
Prior art keywords
video
mgcf
codec
endpoint
domain
Prior art date
Application number
PCT/CN2009/070785
Other languages
English (en)
Chinese (zh)
Inventor
朱浩鹏
沈洪峰
李昌坤
Original Assignee
华为技术有限公司
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 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2009111991A1 publication Critical patent/WO2009111991A1/fr

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/1023—Media gateways
    • H04L65/103—Media gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
    • H04M7/1225—Details of core network interconnection arrangements
    • H04M7/123—Details of core network interconnection arrangements where the packet-switched network is an Internet Protocol Multimedia System-type network
    • 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]

Definitions

  • the present invention relates to the field of communications, and in particular, to a method and device for implementing interworking between an IMS domain and a CS domain. Background technique
  • SIP Session Initiation Protocol
  • MGCF Media Gateway Control Function
  • ISUP ISDN User Part
  • BICC Bearer Independent Call Control
  • the IMS domain performs video interworking with the CS domain through the MGCF, as shown in Figure 1.
  • the MGCF is required to control the transformation of the video medium, that is, the IM-MGW can encode and decode different video codecs at both ends.
  • the VP call user plane of the IMS domain is two RTP (Real Time Transmit Protocol) flows, and the signaling plane is established through SIP; and the VP user plane of the circuit domain is based on
  • the signaling plane is established by ISUP / BICC. This requires the IM-MGW to convert the two RTP streams of the IMS domain and the H.324M multiplexed stream of the circuit domain.
  • the embodiments of the present invention provide a method and a device for implementing video interworking between an IMS domain and a CS domain, and implementing video interworking between the IMS domain and the CS domain.
  • the embodiment of the invention provides a method for realizing interworking between an IMS domain of an IP multimedia subsystem and a circuit switched CS domain, including the following steps:
  • Receiving media gateway control function MGCF establishes a video bearer indication, and establishes an audio real-time transport protocol RTP stream and a video RTP stream;
  • the endpoints carrying the audio data and the video data are set up on the ingress side and the outbound side respectively, and the end stream direction is deactivated inactive. After the endpoint is established, the direction of the endpoint flow is modified as the sending mode. sendrecvo
  • An embodiment of the present invention provides an IM-MGW, including:
  • An RTP stream establishing unit configured to receive an indication of the MGCF when establishing a video bearer, and establish an audio
  • the bearer endpoint establishing unit is configured to establish an endpoint carrying audio data and video data on the ingress side and the outbound side, and set the endpoint topology to inactive. After the endpoint is established, modify the endpoint topology to sendrecv.
  • An embodiment of the present invention provides an MGCF, including:
  • the indicating unit when used to establish a video bearer, instructs the IM-MGW to establish an audio RTP stream and a video RTP stream, and create a bearer endpoint.
  • the embodiment of the invention provides a method for video fallback, which includes the following steps:
  • the MGCF determines that a video fallback service needs to be initiated;
  • the MGCF instructs the IM-MGW to establish an audio real-time transport protocol RTP stream, and establish an endpoint for carrying audio data on the ingress side and the outbound side, and set the direction of the endpoint flow to deactivate inactive. After the endpoint is established, modify the endpoint.
  • the flow direction is the send/receive mode sendrecv.
  • the embodiment of the invention provides a monitoring method, which includes the following steps:
  • the MGCF receives the interception request
  • the MGCF instructs the IM-MGW to establish an audio real-time transport protocol RTP stream and a video RTP stream.
  • the scenario of intercommunication between the IMS domain and the CS domain is implemented by the cooperation of the MGCF and the VIG, and since the MGCF does not need to implement codec conversion when using the same codec, the operation of the IM-MGW is relatively simple. Streamlined business processes and reduced interface messages. DRAWINGS
  • FIG. 1 is a schematic diagram of a MGCF video interworking networking architecture in the prior art
  • FIG. 2 is a schematic structural diagram of an IMS and VIG interworking networking structure in an embodiment of the present invention
  • FIG. 3 is a schematic structural diagram of an interworking network between an IMS and a CS in an embodiment of the present invention
  • FIG. 4 is a schematic diagram of an architecture of interworking between MGCF and VIG in the embodiment of the present invention
  • FIG. 5 is a schematic diagram of a process of establishing a bearer endpoint in the embodiment of the present invention
  • FIG. 6 is a schematic diagram of a video fallback operation during a call in an embodiment of the present invention.
  • FIG. 7 is a schematic diagram of a video fallback operation during a call in an embodiment of the present invention.
  • FIG. 7A is a schematic diagram of an endpoint model in an embodiment of the present invention.
  • FIG. 7B is a schematic diagram of another endpoint model in the embodiment of the present invention.
  • FIG. 8 is a schematic diagram of only listening to audio in an embodiment of the present invention.
  • FIG. 9 is a schematic diagram of an IMS call CS video listening endpoint in an embodiment of the present invention.
  • 10 is a schematic diagram of an CS call IMS video interception endpoint in an embodiment of the present invention
  • 11 is a schematic diagram of intercepting SIP signaling between an MGCF and a SIP according to an embodiment of the present invention
  • FIG. 12 is a structural diagram of an IM-MGW according to an embodiment of the present invention.
  • FIG. 13 is a block diagram of an MGCF in an embodiment of the present invention. detailed description
  • the IMS domain and the CS domain video intercommunication adopt the MGCF and VIG joint networking architecture as shown in FIG. 2, and the MGCF plays a transit role in the video call, and can satisfy the TrFO feature, that is, the codec negotiation can be performed in the whole process.
  • the VIG converts the IMS incoming SIP signaling into ISUP/BICC signaling and sends it to the CS domain.
  • the MSC forwards the CSUP incoming ISUP/BICC signaling to the VIG, so that the VIG converts the ISUP/BICC signaling into a SIP message. Order, sent to the IMS domain.
  • the signaling interaction between the IMS domain and the CS domain is implemented.
  • VIG can process the voice and video dual data streams of the IMS domain into multiplexed streams that can be supported by the CS domain and send them to the CS domain.
  • the MGCF controls the IM-MGW to perform codec conversion, thereby implementing interworking between the IMS and the VIG.
  • IMS supports codec modes 1 and 2
  • VIG supports codec modes 3 and 4
  • MGCF supports codec modes 1 and 3
  • IMS requests codec mode 1 and 2 to MGCF
  • MGCF and IMS interworking will use Decoding mode 1;
  • MGCF will request interworking with VIG.
  • VIG supports codec modes 3 and 4
  • MGCF and VIG can only interwork through codec mode 3. This requires that the MGCF itself needs to be able to interwork the codec modes 1 and 3, and the result is that the MGCF supports the conversion of the codec mode 1 and the codec mode 3.
  • IM-MGW can not encode and decode the video stream, but only unpack and pack, so that the data stream can be reduced. Decoding operations, thereby reducing data errors and enhancing accuracy. Because you need to deliver both audio and video streams, you need to make sure that your audio and video streams are as close as possible.
  • the two ends of the MGCF control that is, the endpoints carrying audio data on the ingress side and the outgoing side
  • the audio codec uses the same codec as much as possible to prevent audio from being converted on the IM-MGW to generate voice. The delay, which causes the voice and video to be different.
  • the audio must be converted on the IM-MGW, and the lip-tone function is used to ensure the voice and video.
  • the VIG the MGCF and the CS domain's office connection
  • there is an office route that connects the MSC through the VIG and there is also an office route of the directly connected MSC.
  • the video call coming from the IMS domain can pass the VIG. Transfer to the CS domain, and send the audio call from the IMS domain directly to the MSC in the CS domain, as shown in Figure 3.
  • a video call when establishing a bearer endpoint, the MGCF establishes an endpoint for audio and video to transmit an audio stream and a video stream, as shown in FIG.
  • a video call establishes only one physical C (context), such as the dotted line in Figure 4, to establish four physical Ts (endpoints).
  • TI and ⁇ 2 carry audio streams, such as the thin solid line in Figure 4; ⁇ 3, ⁇ 4 carry the video stream, as shown by the thick solid line in Figure 4.
  • Step s501 After receiving the INVITE message from the IMS domain, the MGCF needs to establish a bearer connected to the IMS. At this time, the IM-MGW is notified by the ADD message to establish two endpoints T1 and ⁇ 3. When sending an ADD REQ message to the IM-MGW, the flow mode is inactive.
  • Step s502 Before the MGCF sends the outgoing INVITE, the IM-MGW is notified to establish the bearer on the outgoing side, and T2 and ⁇ 4 are established by using the ADD message. The stream mode at this time is also inactive.
  • Step s503 After receiving the response message of the INVITE, if the MGCF has the media information of the opposite end in the response message, the MGCF changes the flow mode of T2 and ⁇ 4 to sendrecvo by using the MOD REQ message.
  • Step s504 finally the MGCF changes the T1, ⁇ 3 stream mode to sendrecv.
  • the flow mode between T1 and T2 is modified to sendrecv
  • the flow mode between T3 and T4 is modified to sendrecv, but between T1 and T3, T1 and T4, ⁇ 2 and ⁇ 3 And between ⁇ 2 and ⁇ 4 endpoints are not interoperable.
  • the IMS domain For video calls initiated by the IMS domain to the CS domain, the IMS domain first arrives through SIP signaling.
  • the MGCF forwards the SIP signaling to the VIG by the MGCF; the VIG converts the SIP signaling into ISUP or BICC signaling and sends it to the CS domain.
  • the CS domain reaches the VIG through ISUP/BICC signaling, and the VIG converts the response into SIP signaling and sends it to the MGCF, and then the MGCF sends the response to the IMS domain.
  • the CS domain For the video call initiated by the CS domain to the IMS domain, the CS domain first passes the ISUP/BICC signaling to the VIG.
  • the VIG converts the signaling into SIP signaling and sends it to the MGCF, and then the MGCF sends the signaling to the IMS domain.
  • the response to the video call is sent by the IMS domain via SIP signaling.
  • the MGCF forwards the response to the VIG; VIG converts the response to ISUP or BICC signaling to the CS domain. So far, the MGCF implements signaling interworking between the IMS domain and the CS domain.
  • the MGCF In the process of bearer establishment, for example, when the IMS domain calls the CS domain, if the MGCF doubles as the gateway, the MGCF sends an SRI to the HLR (Home Location Register) after receiving the INVITE message from the IMS (Send Routing). Information, sending routing information), because the INVITE message carries the video codec, and when the routing information is taken, the bearer information of the video is carried. If the routing information fails to be obtained through the video bearer information, it indicates that the called party does not support the video call, and the video can be dropped.
  • HLR Home Location Register
  • the video that is behind the call is an audio call.
  • Step s601 After receiving the rennvite message sent by the IMS, the MGCF determines that the video stream direction is inactive, the video stream port is 0, or the IP address is invalid (0 or all F), indicating that the video fallback needs to be initiated.
  • Step s602 The MGCF sends a relnvite message to the VIG, carrying the same video stream attribute in the received relnvite message, indicating that the VIG video falls back.
  • Step s603 After receiving the 200 response message of the VIG, the MGCF modifies the bearer attribute on the gateway by using the MOD REQ message, and changes the flow direction to inactive. Also modify the media attributes at both ends of the incoming.
  • Step s604 The MGCF sends a 200 response message to the IMS domain.
  • video recovery can also be performed.
  • the process is the same as the video fallback process, except that the video stream direction in the SDP is sendrecv, and both the port and the IP are valid values, indicating that video recovery is required; and the MGCF is the same. Modify the bearer attribute and change the video stream direction to both.
  • a method for implementing video intercommunication between an IMS domain and a CS domain is provided, which is applied to a scene in which a video falls back during a call setup process. As shown in FIG. 7, the video is dropped back into four scenarios: The establishment of.
  • the MGCF When the IMS domain calls the CS domain, if the MGCF serves as the gateway, the MGCF sends an SRI to the HLR after receiving the INVITE message from the IMS.
  • the INVITE message carries the video codec. Bearer information. If the routing information fails to be obtained through the video bearer information, it indicates that the called party does not support the video call, and the video can be dropped. Or, when the MGCF takes the user routing information, the multimedia service BC and the voice service BC are packaged in the SRI, and the HLR determines the service type that can be supported. If the HLR determines that the user does not support the multimedia service, the BC carried in the returned user routing data is voice. Business BC (or carry two BCs, voice service BC in front).
  • the frequency port number is 0).
  • the video endpoint is not established when the endpoint is established on the ingress side; the outgoing office can select the office direction that can directly reach the CS domain.
  • the endpoint model is shown in Figure 7A.
  • the VIG side After receiving the 183 message of the VIG, it is determined whether the video codec is valid (the bearer IP is not 0, the port is not 0, and the flow direction is the transceiver). If one is not satisfied, the VIG side initiates the video fallback operation. SIP needs to modify the corresponding attribute and notify the attribute to the incoming side. At this point, the endpoint model behaves like Figure 7B.
  • the third embodiment of the present invention provides a method for interworking between an IMS domain and a CS domain video, which is applied to a video monitoring scenario, which only monitors audio, monitors audio and video, DTMF monitoring, and MGCF and LIC (Lawful Interception Center).
  • the central relay is discussed in four cases using SIP signaling.
  • VIG For video monitoring, in the case where you cannot use SIP for monitoring relay, you need to consider sending the monitored information to the monitoring center by other methods. Due to the existence of VIG, it is considered that two RTP data streams are synthesized by VIG to synthesize a H.324M data volume to monitor the data stream.
  • the IMS domain calls the CS domain video interception (establishes the bypass path, and listens through the path).
  • the endpoint model is shown in Figure 9.
  • the MGCF can determine whether the call is a video call; In the case of a video call, if the user is listening, if the video needs to be monitored at this time, if the SIP listening relay is not directly taken, the listening endpoint is not established first, and the outgoing SIP server is selected to change the number. (For example, add a special prefix at the beginning of the number, etc.); Configure the number analysis on the VIG side.
  • the MGCF For the number called the special prefix, route it back to the MGCF, and remove the prefix to make the VIG pass ISUP signaling and MGCF. connection. After receiving the incoming message, the MGCF treats the call as a general call, and directly routes the call to the MSC on the CS domain according to the analysis of the number. At this point, a listening endpoint for the call is established on the MGCF.
  • the video interception endpoint model is shown in FIG. 10. If the incoming ISUP signaling indicates a video call, and the number analysis can select the office route to the VIG, the interception endpoint monitors the call at this time. A special prefix is added in front of the called number that is outgoing to the VIG. On the VIG, the call can be routed back to the MGCF according to the prefix, and the prefix is removed.
  • DTMF Dual Tone Multi- Frequency monitoring: For the video call, if you need to monitor the DTMF tone, you can do it in two ways:
  • Method 1 Directly report the DTMF tone to the monitoring center through the event; Method 2, mix the DTMF tone in the data stream and send it to the monitoring center, and the monitoring center performs the separation operation.
  • the monitoring relay between the MGCF and the LIC uses SIP signaling:
  • the MGCF and the LIC are connected by SIP signaling. At this time, the video call service can directly monitor the listening path to the LIC.
  • SIP listening is used to establish a listening session
  • the SIP listening endpoints are two endpoints on the MGCF, which carry voice and voice channels respectively.
  • the MGCF sends an INVITE request message to the LIC, and the LIC returns a 183 response message to the MGCF; the MGCF sends an acknowledgment message PRACK to the LIC 183; the LIC returns a 200 response message to the MGCF; the MGCF will listen The event is reported to the LIC; the MGCF sends an end request BYE to the LIC, and the LIC returns a 200 response message to the MGCF for the end request.
  • the codec of the video call needs to include the audio stream and the video stream, and the video intercommunication can be performed only when both the audio and the video can be successfully negotiated.
  • the MGCF In the case of a SIP incoming slow start (with no SDP in the INVITE), the MGCF is required to automatically generate the codec of the cost side. In the process of docking with the VIG, it is common to transfer the video-capable call from the CS domain to the MGCF through the VIG. At this time, when generating codec, the MGCF needs to generate video codec and audio codec at the same time, and perform 0/A negotiation through the codec and VIG generated by itself. This ensures that the video call when VIG is slow to start can also be smoothly interoperable.
  • An embodiment of the present invention further provides an IM-MGW.
  • the method includes: an RTP flow establishing unit 10, configured to receive an indication of an MGCF when establishing a video bearer, and establish an audio RTP stream and a video RTP stream;
  • the unit 20 is configured to establish an endpoint that carries audio data and video data on the ingress side and the outbound side, and set the direction of the endpoint flow to inactive, and the endpoint is established. After that, modify the endpoint flow direction to sendrecv.
  • the codec negotiation unit 30 is configured to have an intersection between the codec supported by the MGCF and the codec supported by the IMS side, and also has an intersection codec supported by the codec supported by the MGCF and the codec supported by the IMS side when there is an intersection between the codec supported by the MGCF and the codec supported by the IMSCF.
  • the codec supported by the MGCF and the intersection codec of the codec supported by the VIG side are interworking, that is, the codec supported by the MGCF and the codec codec supported by the IMS side, the codec supported by the MGCF, and the codec of the codec supported by the VIG side are used as the codec.
  • the codec information notifies the RTP stream establishing unit 10.
  • the RTP stream establishing unit 10 establishes an audio RTP stream and a video RTP stream according to the codec information when establishing the audio RTP stream and the video RTP stream, and the RTP stream establishing unit 10 obtains the codec information by: determining the codec and IMS supported by the MGCF.
  • the side supports the intersection of the codec and the intersection of the codec supported by the MGCF and the codec supported by the VIG side, and obtains the intersection codec supported by the MGCF and the codec supported by the IMS side, the codec supported by the MGCF, and the VIG side support.
  • the codec's intersection codec is used as codec information.
  • the embodiment of the present invention further provides an MGCF, as shown in FIG. 13, including: an indicating unit 100, configured to: when the video bearer is established, instruct the IM-MGW to establish an audio RTP stream and a video RTP stream, and create a bearer endpoint.
  • the video fallback service determining unit 200 is configured to determine whether to initiate a video fallback service by using a video codec attribute, whether to support video codec, and whether the called party subscribes to the video service.
  • the listening unit 300 is configured to monitor single audio, monitor audio and video, listen to DTMF or directly listen to the voice channel to the LIC.
  • An embodiment of the present invention further provides a video fallback method, including the following steps:
  • the MGCF determines that a video fallback service needs to be initiated.
  • the specific manner of the MGCF determining that the video fallback service needs to be initiated includes: after receiving the INVITE message of the IMS, the MGCF obtains the user routing information SRI from the home location register HLR, and fails to obtain routing information through the video bearer information; or obtains After the routing information, if the called party supports the video call, the VIG office is selected to be outgoing. If the VIG office is unreachable, the video is dropped. Or if the office direction to the VIG is open, if the video codec in the INVITE message is The incoming office does not have an intersection with the video codec that can be supported.
  • the IM-MGW under the control of the MGCF does not support the codec conversion; or the MGCF receives
  • the IMS sends a message, and determines whether to initiate a video fallback by using the bearer IP, PORT, and flow attributes in the message, when the bearer IP, PORT, or stream attribute is invalid.
  • the MGCF instructs the IM-MGW to establish an audio real-time transport protocol RTP stream, and establish an endpoint for carrying audio data on the ingress side and the outbound side, and set the direction of the endpoint flow to deactivate inactive. After the endpoint is established, Change the direction of the endpoint flow to send and receive mode sendrecv.
  • the embodiment of the invention further provides a monitoring method, which includes the following steps:
  • the MGCF receives the interception request
  • the MGCF instructs the IM-MGW to establish an audio real-time transport protocol RTP stream and a video RTP stream.
  • step 2 it can also include:
  • the MGCF directly establishes a listening endpoint to listen to audio on the ingress side endpoint;
  • the MGCF listens to audio and video: synthesizes two RTP data streams into a H.324M multiplexed data stream through the VIG, and monitors the multiplexed data stream; or
  • the MGCF monitors the dual tone multi-frequency: directly reports the DTMF tone to the monitoring center; or mixes the DTMF tone in the data stream and sends it to the monitoring center, and the monitoring center performs the separation operation.
  • the combination of the MGCF and the VIG implements a scenario in which the IMS domain and the CS domain video intercommunication are implemented in the case of the cooperation of the existing network elements; when the same codec is used, the MGCF and the IM-MGW are reduced. Inter-message interaction; if the same codec cannot be used, the codec conversion can also be performed.
  • the present invention can be implemented by means of software plus a necessary general hardware platform.
  • the present invention can also be implemented by hardware, but in many cases, the former is A better implementation.
  • the technical solution of the present invention which is essential or contributes to the prior art, may be embodied in the form of a software product stored in a storage medium, including a plurality of instructions.
  • a computer device (which may be a personal computer, server, or network device, etc.) is caused to perform the methods described in various embodiments of the present invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Des modes de réalisation de la présente invention se rapportent à un procédé et à un dispositif de réalisation de l’interfonctionnement entre le domaine Système IP Multimédia (IMS) et le domaine Circuit Commuté (CS), comprenant les étapes suivantes consistant à : recevoir une indication de la Fonction de Commande de Passerelle de Média (MGCF) pour établir un support vidéo, établissant un flux audio de Protocole de Transmission en Temps réel (RTP) et un flux vidéo RTP ; établir les terminaisons pour supporter les données audio et les données vidéo du côté entrant et du côté sortant respectivement, déterminer les directions de flux des terminaisons devant être inactives, après l’établissement des terminaisons, modifier les directions de flux des terminaisons vers le mode envoi/réception sendrecv. Par le biais de la coopération de la MGCF et de la Passerelle d’interfonctionnement Vidéo (VIG), la présente invention réalise le scénario selon lequel l’interfonctionnement vidéo entre le domaine IMS et le domaine CS est réalisé sous la coopération des éléments de réseau existants. En outre, étant donné que la MGCF n’implémente pas la transformation de codec lorsque le même codec est utilisé, le fonctionnement de la Passerelle Média IP Multimédia (IM-MGW) peut être simplifié, les messages d’interface sont réduits.
PCT/CN2009/070785 2008-03-14 2009-03-13 Procédé et dispositif de réalisation de l’interfonctionnement entre le domaine ims et le domaine cs WO2009111991A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN 200810084730 CN101534264A (zh) 2008-03-14 2008-03-14 一种实现ims域与cs域互通的方法及设备
CN200810084730.9 2008-03-14

Publications (1)

Publication Number Publication Date
WO2009111991A1 true WO2009111991A1 (fr) 2009-09-17

Family

ID=41064770

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/070785 WO2009111991A1 (fr) 2008-03-14 2009-03-13 Procédé et dispositif de réalisation de l’interfonctionnement entre le domaine ims et le domaine cs

Country Status (2)

Country Link
CN (1) CN101534264A (fr)
WO (1) WO2009111991A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102546578B (zh) * 2010-12-28 2015-02-04 中国移动通信集团浙江有限公司 Ims与2g/3g网络之间协议流程的关联方法及系统
CN102843336A (zh) * 2011-06-20 2012-12-26 中兴通讯股份有限公司 一种ims多媒体会议接入的方法及系统
CN102523222B (zh) * 2011-12-20 2014-10-22 中国联合网络通信集团有限公司 可视电话回落的处理方法和系统
US9681095B2 (en) * 2013-08-19 2017-06-13 Microsoft Technology Licensing, Llc Seamless call transitions with pre-escalation participation confirmation

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1581997A (zh) * 2003-08-04 2005-02-16 华为技术有限公司 电路域多媒体业务回退到语音业务的实现方法
CN1856131A (zh) * 2005-04-26 2006-11-01 华为技术有限公司 一种多媒体回落的处理方法
CN1882116A (zh) * 2005-08-11 2006-12-20 华为技术有限公司 内置视频网关的移动交换中心及实现多媒体互通的方法
CN1889469A (zh) * 2005-07-14 2007-01-03 华为技术有限公司 监听视频呼叫的方法和装置
WO2007045522A1 (fr) * 2005-10-21 2007-04-26 Siemens Aktiengesellschaft Procede de transmission de donnees de signalisation dans une unite passerelle et dans une unite de commande, et unites correspondantes
CN101009605A (zh) * 2006-12-22 2007-08-01 华为技术有限公司 一种实现多媒体监听的方法、系统及监听媒体网关

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1581997A (zh) * 2003-08-04 2005-02-16 华为技术有限公司 电路域多媒体业务回退到语音业务的实现方法
CN1856131A (zh) * 2005-04-26 2006-11-01 华为技术有限公司 一种多媒体回落的处理方法
CN1889469A (zh) * 2005-07-14 2007-01-03 华为技术有限公司 监听视频呼叫的方法和装置
CN1882116A (zh) * 2005-08-11 2006-12-20 华为技术有限公司 内置视频网关的移动交换中心及实现多媒体互通的方法
WO2007045522A1 (fr) * 2005-10-21 2007-04-26 Siemens Aktiengesellschaft Procede de transmission de donnees de signalisation dans une unite passerelle et dans une unite de commande, et unites correspondantes
CN101009605A (zh) * 2006-12-22 2007-08-01 华为技术有限公司 一种实现多媒体监听的方法、系统及监听媒体网关

Also Published As

Publication number Publication date
CN101534264A (zh) 2009-09-16

Similar Documents

Publication Publication Date Title
US7746845B2 (en) Support for fax and modem in SIP/SIP-T networks and the interworking of these networks with ISUP+/BICC
JP4567359B2 (ja) ネットワーク・リソースの最適化による、エンド・ユーザの要求に応じた会議運営のための迅速なネットワークｓｉｐ／ｓｄｐ手順
US8885638B2 (en) Method and apparatus for enabling peer-to-peer communication between endpoints on a per call basis
US7907708B2 (en) Voice and fax over IP call establishment in a communications network
JP5450444B2 (ja) マルチメディア通話を処理するための方法及び装置
WO2009049531A1 (fr) Procédé, dispositif de commande de passerelle réseau multimédia et serveur d'application pour mettre en œuvre l'intercommunication des tonalités de retour d'appel personnalisées
US20110075669A1 (en) Audio mixer and method
WO2006128356A1 (fr) Procede d'ecoute par le terminal utilisateur appelant du signal du terminal utilisateur appele en cas d'interconnexion
EP2135424B1 (fr) Améliorations en télécommunication mobile
JP2007318343A (ja) ゲートウェイ装置及び再ネゴシエーション方法
US20120075406A1 (en) Method And System For Handling A Multi-Media Call Setup Request
WO2012174904A1 (fr) Procédé, dispositif et système d'accès à une conférence ims
WO2009111991A1 (fr) Procédé et dispositif de réalisation de l’interfonctionnement entre le domaine ims et le domaine cs
US8179916B2 (en) Properly playing in-band tones before call establishment when performing protocol interworking
CN101014153A (zh) 一种ims网络sip终端互通系统及其方法
WO2009079960A1 (fr) Procédé, système et équipement pour un interfonctionnement de signalisation dtmf hors bande
US7460533B1 (en) System and method for multi-casting announcements
EP1388997B1 (fr) Système et méthode pour service de conférence à trois
US7881294B1 (en) Method and apparatus for enabling network based media manipulation
WO2008049371A1 (fr) Procédé et système pour transférer un événement de service
JP4335037B2 (ja) インタワーク装置
WO2012171290A1 (fr) Procédé de demande de transfert, serveur d'applications, terminal de service et système
JP2004173051A (ja) ＶｏＩＰパケット情報蓄積システム
KR101208119B1 (ko) 스마트 카드를 이용한 ｓｉｐ 기반 영상통화 서비스 시스템 및 그 방법
CN100499708C (zh) 慢速呼叫终端播放个性化回铃音的方法

Legal Events

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

Ref document number: 09718962

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09718962

Country of ref document: EP

Kind code of ref document: A1