WO2009111991A1 - 一种实现ims域与cs域互通的方法及设备 - Google Patents

一种实现ims域与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)
French (fr)
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/zh

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)

Description

一种实现 IMS域与 CS域互通的方法及设备 技术领域
本发明涉及通信领域， 尤其涉及一种实现 IMS域与 CS域互通的方法及 设备。 背景技术
在 IMS (IP Multimedia Subsystem, IP多媒体子***） 网络与传统的 CS (Circuit Switched, 电路交换） 网络对接实现中， 需要通过 MGCF (Media Gateway Control Function, 媒体网关控制功能） 实现 SIP ( Session Initiation Protocol, 会话初始化协议） 信令与 ISUP (ISDN User Part, ISDN用户部 分） /BICC (Bearer Independent Call Control, 承载无关呼叫控制） 信令的相 互转换。 按照协议实现 IMS - CS VP互通是基于 MGCF控制内置在 IM- MGW (IP Multimedia Media Gateway, IP多媒体网关） 的 VIG (Video Interwork Gateway, 视频互通网关） 实现。
现有技术中， 采用的一种方案是 IMS域直接和 CS域的 VIG进行互 通。 然而， 采用 IMS直接与 VIG互通时， 由于中间没有互通单元， 因此对 业务的支持能力大大降低。
另一种方案是 IMS域通过 MGCF与 CS域进行视频互通， 如图 1所 示。 该方案中要求 MGCF能够控制视频媒体的变换， 即控制 IM-MGW能够 在两端分别对不同的视频编解码进行编码、 解码。
IMS域的 VP呼叫用户面是两个 RTP ( Realtime Transmit Protocol， 实时 传输协议） 流， 信令面通过 SIP建立； 而电路域的 VP用户面是基于
H.324M复用流， 信令面通过 ISUP / BICC建立。 这就要求 IM-MGW能够对 IMS域的两个 RTP流与电路域的 H.324M复用流进行相互转换。
在实现本发明的过程中， 发明人发现现有技术存在以下缺点： 使用 IMS域通过 MGCF与 CS域进行视频互通时， MGCF及其控制下 的 IM-MGW不能够利用现有的网元实现视频互通。 发明内容
本发明的实施例提供一种实现 IMS域与 CS域视频互通的方法及设备， 实现 IMS域与 CS域视频互通。
本发明实施例提供了一种实现 IP多媒体子*** IMS域与电路交换 CS 域互通的方法， 包括以下歩骤：
接收媒体网关控制功能 MGCF的建立视频承载指示， 建立音频实时传 输协议 RTP流和视频 RTP流；
分别建立入局侧和出局侧的承载音频数据和视频数据的端点， 将所述端 点流方向置为去激活 inactive, 所述端点建立完成后， 修改端点流方向为收 发方式 sendrecvo
本发明实施例提供了一种 IM-MGW, 包括：
RTP流建立单元， 用于建立视频承载时接收 MGCF的指示， 建立音频
RTP流和视频 RTP流；
承载端点建立单元， 用于建立入局侧和出局侧的承载音频数据和视频数 据的端点， 将所述端点拓扑置为 inactive, 所述端点建立完成后， 修改端点 拓扑为 sendrecv。
本发明实施例提供了一种 MGCF, 包括：
指示单元， 用于建立视频承载时， 指示 IM-MGW建立音频 RTP流和视 频 RTP流， 并创建承载端点。
本发明实施例提供了一种视频回落的方法， 包括以下歩骤：
MGCF确定需要发起视频回落业务； 所述 MGCF指示 IM-MGW建立音频实时传输协议 RTP流， 并建立入 局侧和出局侧的承载音频数据的端点， 将所述端点流方向置为去激活 inactive, 所述端点建立完成后， 修改端点流方向为收发方式 sendrecv。
本发明实施例提供了一种监听方法， 包括以下歩骤：
MGCF接收监听请求；
所述 MGCF指示 IM-MGW建立音频实时传输协议 RTP流和视频 RTP 流。
与现有技术相比， 本发明的实施例具有以下优点：
本发明实施例中， 通过 MGCF和 VIG的配合， 实现 IMS域和 CS域视 频互通的场景， 而且由于 MGCF在使用相同编解码时不用实现编解码的转 换， 对 IM-MGW的操作会比较简单， 简化了业务流程， 减少了接口消息。 附图说明
图 1是现有技术中 MGCF视频互通组网架构示意图；
图 2是本发明实施例中 IMS与 VIG互通组网架构示意图；
图 3是本发明实施例中 IMS与 CS互通组网架构示意图；
图 4是本发明实施例中 MGCF与 VIG互通组网架构示意图； 图 5是本发明实施例中承载端点建立过程示意图；
图 6是本发明实施例中通话过程中视频回落操作示意图；
图 7是本发明实施例中呼叫过程中视频回落操作示意图；
图 7A是本发明实施例中一种端点模型示意图；
图 7B是本发明实施例中另一种端点模型示意图；
图 8是本发明实施例中只监听音频示意图；
图 9是本发明实施例中 IMS呼叫 CS视频监听端点示意图；
图 10是本发明实施例中 CS呼叫 IMS视频监听端点示意图； 图 11是本发明实施例中 MGCF与 SIP之间监听中继走 SIP信令示意 图；
图 12是本发明实施例中一种 IM-MGW结构图；
图 13是本发明实施例中一种 MGCF结构图。 具体实施方式
以下结合附图和实施例， 对本发明的实施方式作进一歩说明。
本发明实施例中 IMS域与 CS域视频互通采用 MGCF和 VIG联合组网 架构如图 2所示， MGCF在视频呼叫时， 起中转作用， 能够满足 TrFO特 性， 即能够进行全流程的编解码协商； VIG将 IMS入局的 SIP信令转换为 ISUP/BICC信令发送到 CS域， MSC将 CS域入局的 ISUP/BICC信令转发到 VIG, 使所述 VIG将 ISUP/BICC信令转换为 SIP信令， 发送到 IMS域。 从 而实现 IMS域与 CS域在信令上的交互。 同时 VIG能够将 IMS域的语音、 视频双数据流通过处理， 变为 CS域能够支持的复用流， 发送到 CS域。
在图 2的组网架构中， 如果 MGCF与 IMS使用的编解码和 MGCF与
VIG使用的编解码不同时， MGCF控制 IM-MGW进行编解码转换， 从而实 现 IMS和 VIG的互通。 例如， IMS支持编解码方式 1和 2， VIG支持编解 码方式 3和 4， MGCF支持编解码方式 1和 3， IMS请求使用编解码方式 1 和 2给 MGCF, 则 MGCF和 IMS的互通会使用编解码方式 1 ; MGCF会请 求与 VIG的互通， 此时由于 VIG支持编解码方式 3和 4， 所以 MGCF和 VIG只能够通过编解码方式 3进行互通。 这就要求 MGCF自身内部需要能 够将编解码方式 1和 3两种编解码进行互通， 这样的结果是 MGCF支持编 解码方式 1和编解码方式 3的转换。 然而呼叫的过程中尽量使用同一个编解 码， 在使用相同视频编解码进行互通时， IM-MGW可以不对视频流进行编 码、 解码， 而只是进行解包、 打包， 这样的话可以减少对数据流编解码操 作， 从而减少数据的误差， 增强准确性。 由于需要同时传递音频和视频流， 需要尽量确保音频和视频流的同歩。 要求 MGCF控制的两端端点 （即入局侧和出局侧的承载音频数据的端 点） ， 在进行视频呼叫时， 音频编解码尽量使用同样的编解码， 防止音频在 IM-MGW上进行转换， 产生语音的延时， 从而导致语音、 视频不同歩。 如 果入局侧和出局侧的承载音频数据的端点使用的编解码不同， 在 IM-MGW 上音频必须要转换， 则使用唇音同歩的功能， 保证语音和视频的同歩。 另 夕卜， 由于存在 VIG, MGCF与 CS域的局向连接中， 存在通过 VIG连接 MSC的局向， 也存在直连 MSC的局向， 通过路由配置， 能够将 IMS域过 来的视频呼叫通过 VIG转接到 CS域， 将 IMS域过来的音频呼叫直接发送 到 CS域的 MSC, 如图 3所示。
在视频呼叫中， MGCF在建立承载端点时， 对音频和视频分别建立端 点， 用来传递音频流和视频流， 如图 4所示。 MGCF在 IM-MGW上进行建 立视频承载时， 一个视频呼叫只建立一个物理的 C (context, 上下文） ， 如 图 4中的虚线， 建立 4个物理的 T (端点） 。 其中 TI、 Τ2承载音频流， 如 图 4中的细实线； Τ3、 Τ4承载视频流， 如图 4中的粗实线。 以 IMS入局呼 叫 CS域用户为例， 承载端点建立的过程如图 5所示， 进程包括以下歩骤： 歩骤 s501， 当 MGCF收到 IMS域的入局 INVITE消息后， 需要建立与 IMS连接的承载， 此时通过 ADD消息通知 IM-MGW建立了两个端点 Tl、 Τ3。 在给 IM-MGW下发 ADD REQ消息时， 需要置流模式为 inactive。
歩骤 s502， 在 MGCF发送出局的 INVITE之前， 会通知 IM-MGW建立 出局侧的承载， 通过 ADD消息建立 T2、 Τ4。 此时的流模式也为 inactive。
歩骤 s503， MGCF在收到 INVITE的响应消息后， 如果响应消息中带有 对端的媒体信息， 则 MGCF通过 MOD REQ消息将 T2、 Τ4的流模式修改为 sendrecvo
歩骤 s504， 最后 MGCF将 Tl、 Τ3流模式修改为 sendrecv。 在上述承载端点建立的过程中， 只是将 T1和 T2之间的流模式修改为 sendrecv, 将 T3和 T4之间的流模式修改为 sendrecv, 但 T1与 T3之间、 T1 与 T4、 Τ2与 Τ3、 以及 Τ2与 Τ4端点之间是不能够互通的。 在上述承载建 立以后，
对于 IMS域到 CS域发起的视频呼叫， IMS域先通过 SIP信令到达
MGCF, 由 MGCF将 SIP信令转发到 VIG; VIG将 SIP信令转换为 ISUP或 BICC信令发送到 CS域。 对于该视频呼叫的响应， 由 CS域通过 ISUP/BICC 信令到达 VIG, VIG将该响应转换为 SIP信令发送到 MGCF, 然后 MGCF 将该响应发送到 IMS域。
对于 CS域到 IMS域发起的视频呼叫， CS域先通过 ISUP/BICC信令到 达 VIG, VIG将信令转换为 SIP信令发送到 MGCF, 然后 MGCF将信令发 送到 IMS域。 对于该视频呼叫的响应， 由 IMS域通过 SIP信令送到
MGCF, 由 MGCF将响应转发到 VIG; VIG将该响应转换为 ISUP或 BICC 信令发送到 CS域。 至此， MGCF实现了 IMS域和 CS域之间的信令互通。
在承载建立的过程中， 例如在 IMS域呼叫 CS域时， 如果 MGCF兼作 关口局， MGCF在收到 IMS的 INVITE消息后， 会向 HLR (Home Location Register, 归属地位置寄存器） 发送 SRI ( Send Routing Information, 发送路 由信息） ， 由于 INVITE消息中携带视频编解码， 此时取路由信息时， 携带 视频的承载信息。 如果通过视频承载信息取路由信息失败， 表示被叫不支持 视频呼叫， 此时可以发起视频的回落。 视频呼叫可以通过编解码重协商过程 及通过对 SDP的修改来进行视频回落操作， 即通过承载 IP、 PORT, 流属性 (a=sendrecv/inactive) 来表示是否发起视频回落。 视频回落后的呼叫为音频 呼叫。
本发明实施例一中提供一种实现 IMS域与 CS域视频互通的方法， 应用 于呼叫建立过程完成后视频回落场景中， 如图 6所示， 包括以下歩骤： 歩骤 s601， MGCF收到 IMS发送过来的 relnvite消息后， 判断视频流方 向为 inactive、 视频流端口为 0或者 IP无效 （0或者全 F) ， 表示需要发起 视频回落。
歩骤 s602、 MGCF将发送 relnvite消息到 VIG， 携带收到的 relnvite消 息中同样的视频流属性， 指示 VIG视频回落。
歩骤 s603、 MGCF收到 VIG的 200响应消息后， 通过 MOD REQ消息 修改网关上的承载属性， 将流方向修改为 inactive。 同时修改出入局两端的 媒体属性。
歩骤 s604、 MGCF将 200响应消息发送到 IMS域。
对于视频回落的呼叫， 还可以进行视频的恢复， 该流程与视频回落流程 相同， 只是 SDP中的视频流方向为 sendrecv, 端口和 IP都为有效值， 表示 需要进行视频恢复的操作； 而且 MGCF同样修改承载属性， 将视频流方向 修改为 bothway。
本发明实施例二中， 提供一种实现 IMS域与 CS域视频互通的方法， 应 用于呼叫建立过程中视频回落的场景， 如图 7所示， 视频回落分 A~D四种 情况进行端点模型的建立。
A: 在 IMS域呼叫 CS域时， 如果 MGCF兼作关口局， MGCF在收到 IMS的 INVITE消息后， 会向 HLR发送 SRI, 由于 INVITE消息中携带视频 编解码， 此时取路由信息时， 携带视频的承载信息。 如果通过视频承载信息 取路由信息失败， 表示被叫不支持视频呼叫， 此时可以发起视频的回落。 或 者 MGCF在取用户路由信息时， 在 SRI中打包多媒体业务 BC和语音业务 BC, 由 HLR判断能够支持的业务类型， 如果 HLR判断用户不支持多媒体 业务， 返回的用户路由数据中携带的 BC为语音业务 BC (或者携带两个 BC, 语音业务 BC放在前面） 。 此时需要修改使用的编解码中的视频编解 码， 将视频流方向修改为 inactive (或者修改视频承载 IP为 0， 或者修改视 频端口号为 0) 。 入局侧建立端点时并不建立视频端点； 出局局向选择能够 直达 CS域的局向即可， 此时端点模型为图 7A。
B: 获取到路由信息后， 如果被叫能够支持视频呼叫， 则选择 VIG局向 出局。 此时如果 VIG局向不通， 则可以发起视频回落。 重新选择一个直达 CS域的局向， 只接通音频呼叫。 入局侧建立端点时并不建立视频端点， 此 时端点模型表现形式同图 7A—样。
C: 如果到 VIG的局向是通的， 如果 INVITE消息中的视频编解码和入 局局向能够支持的视频编解码无交集， 此时需要拆除呼叫； 如果 INVITE消 息中的视频编解码和出局局向能够支持的视频编解码无交集， 表示需要在出 局侧进行编解码转换， 而 MGCF控制下的 IM-MGW不支持编解码转换， 此 时需要发起视频回落， 此时端点模型为图 7B。 在这种情况下， 也可以重新 选择出局的局向， 选择直达 CS域的局向， 只接通音频呼叫， 入局侧建立端 点时并不建立视频端点， 此时端点模型表现形式同图 7A—样。
D: 收到 VIG的 183消息后， 判断视频编解码是否有效 （承载 IP不为 0， 端口不为 0， 流方向为收发） ， 如果有一条不满足， 表示 VIG侧发起了 视频回落的操作， SIP需要修改相应的属性， 并把属性通知到入局侧， 此时 端点模型表现形式同图 7B—样。
在图 7中， 端点模型建立完成后通过 200和 ACK进行控制信令交互， 以实现 IMS、 MGCF, 和 VIG的协同作业。
本发明实施例三提供一种实现 IMS域与 CS域视频互通的方法， 应用于 视频监听场景中， 分只监听音频、 监听音频和视频、 DTMF监听、 以及 MGCF与 LIC (Lawful Interception Center, 合法监听中心） 之间中继使用 SIP信令四种情况进行论述。
一、 只监听音频： 在视频呼叫中， 由于 MGCF上视频和音频流是分开的， 如果需要在 MGCF上监听该呼叫， 可以只监听音频流， 此时监听端点模型如图 8所示， 在入局侧端点直接建立监听端点。
二、 监听视频：
对于视频监听， 在不能使用 SIP做监听中继的情况， 需要考虑通过其他 的方法将监听到的信息送到监听中心。 由于有 VIG的存在， 考虑到将两个 RTP数据流通过 VIG合成一条 H.324M服用数据量， 以对该数据流进行监 听。
IMS域呼叫 CS域视频监听 （建立迂回的路径， 通过该路径上进行监 听） 端点模型如图 9所示： 在 IMS发起到 CS域的呼叫中， 在 MGCF上可 以判断出呼叫是否为视频呼叫； 在视频呼叫的情况下， 如果用户被监听， 此 时需要监听视频的话， 在没有直接走 SIP监听中继的情况下， 先不建立监听 端点， 选择到出局的 SIP局向后， 将号码进行变换 （比如在号码开头增加特 殊前缀等） ； 在 VIG侧进行号码分析的配置， 对于被叫为特殊前缀的号 码， 将其路由回 MGCF上， 并将其前缀去掉， 使 VIG通过 ISUP信令与 MGCF连接。 MGCF收到入局的消息后， 当作一般的呼叫处理， 根据号码 的分析， 直接将呼叫路由到 CS域上的 MSC。 此时在 MGCF上建立对呼叫 的监听端点。
在 CS域用户呼叫 IMS域用户时， 视频监听端点模型如图 10所示， 如 果入局 ISUP信令指示为视频呼叫， 且号码分析能够选择到 VIG的局向， 在 此时建立监听端点监听呼叫。 在出局到 VIG的被叫号码前面增加特殊前 缀， 在 VIG上能够根据该前缀， 将该呼叫再路由回 MGCF上， 并将前缀去 掉。 在 CS域用户呼叫 IMS域用户时， 如果入局是通过 VIG入局， 则此 时， 不能够再应用迂回策略， 此时只监听音频。 三、 DTMF (Dual Tone Multi— Frequency, 双音多频） 监听： 对于视频呼叫的过程中， 如果需要监听 DTMF信号音的话， 可以通过 以下两种方式进行：
方式一、 直接将 DTMF信号音通过事件上报到监听中心； 方式二、 将 DTMF信号音混合在数据流中发送到监听中心， 由监听中心进行分离操作。
四、 MGCF与 LIC之间监听中继使用 SIP信令：
MGCF与 LIC之间通过 SIP信令连接， 此时视频呼叫业务可以直接出监 听话路到 LIC。 采用 SIP信令建立监听话路时， SIP监听端点在 MGCF上为 两个端点， 分别承载语音和话路， 对应在 LIC上， 也要有两个承载端点来 承载语音和话路。 具体流程如图 11所示， 包括以下步骤： MGCF向 LIC发送 INVITE请求消息， LIC向 MGCF返回 183响应消息； MGCF向 LIC发送对 183的确认消息 PRACK; LIC向 MGCF返回 200响应消息； MGCF将监听 事件上报给 LIC; MGCF向 LIC发送结束请求 BYE, LIC向 MGCF返回对 结束请求的 200响应消息。
本发明实施例在 SIP视频呼叫过程中， 视频呼叫的编解码中需要包含音 频流和视频流， 只有当音频和视频都能够协商成功时， 才能够进行视频互 通。
在 SIP入局慢启 （INVITE中不带 SDP) 的情况下， 需要 MGCF自动生 成本端的编解码。 在与 VIG对接的过程中， 一般情况下是将 CS域过来的有 视频能力的呼叫， 通过 VIG转接到 MGCF上。 此时 MGCF在生成编解码 时， 需要同时生成视频编解码和音频编解码， 通过自身生成的编解码和 VIG进行 0/A协商。 这样可以保证 VIG慢启时的视频呼叫也能够顺利进行 互通。
本发明实施例还提供了一种 IM-MGW, 如图 12所示， 包括： RTP流建 立单元 10， 用于建立视频承载时接收 MGCF的指示， 建立音频 RTP流和视 频 RTP流； 承载端点建立单元 20， 用于建立入局侧和出局侧的承载音频数 据和视频数据的端点， 将所述端点流方向置为 inactive, 所述端点建立完成 后， 修改端点流方向为 sendrecv。 编解码协商单元 30， 用于 MGCF支持的 编解码与 IMS侧支持编解码存在交集， 也与 VIG侧支持编解码存在交集 时， 使用 MGCF支持的编解码与 IMS侧支持编解码的交集编解码、 MGCF 支持的编解码与 VIG侧支持编解码的交集编解码互通， 即将 MGCF支持的 编解码与 IMS侧支持编解码的交集编解码、 MGCF支持的编解码与 VIG侧 支持编解码的交集编解码作为编解码信息通知 RTP流建立单元 10。 RTP流 建立单元 10在建立音频 RTP流和视频 RTP流时， 根据编解码信息建立音 频 RTP流和视频 RTP流， RTP流建立单元 10获得编解码信息的方法为： 确定 MGCF支持的编解码与 IMS侧支持编解码存在的交集， 以及 MGCF支 持的编解码与 VIG侧支持编解码存在的交集， 获得 MGCF支持的编解码与 IMS侧支持编解码的交集编解码、 MGCF支持的编解码与 VIG侧支持编解 码的交集编解码作为编解码信息。
本发明实施例还提供了一种 MGCF, 如图 13所示， 包括： 指示单元 100， 用于建立视频承载时， 指示 IM-MGW建立音频 RTP流和视频 RTP 流， 并创建承载端点。 视频回落业务判断单元 200， 用于通过视频编解码属 性、 是否支持视频编解码、 被叫是否签约视频业务， 出局局向来判断是否发 起视频回落业务。 监听单元 300， 用于监听单音频、 监听音频和视频、 监听 DTMF或直接出监听话路到 LIC。
本发明实施例还提供了一种视频回落的方法， 包括以下歩骤：
1、 MGCF确定需要发起视频回落业务。 其中， 所述 MGCF确定需要发 起视频回落业务具体方式包括： 所述 MGCF收到 IMS的 INVITE消息后， 从归属地位置寄存器 HLR取用户路由信息 SRI, 如果通过视频承载信息取 路由信息失败； 或获取到路由信息后， 如果被叫支持视频呼叫， 则选择 VIG局向出局， 如果 VIG局向不通， 则发起视频回落； 或如果到 VIG的局 向是通的， 如果 INVITE消息中的视频编解码和入局局向能够支持的视频编 解码无交集， MGCF控制下的 IM-MGW不支持编解码转换； 或 MGCF收到 IMS发送消息， 通过该消息中的承载 IP、 PORT, 流属性判断是否发起视频 回落， 当所述承载 IP、 PORT或流属性无效。
2、 所述 MGCF指示 IM-MGW建立音频实时传输协议 RTP流， 并建立 入局侧和出局侧的承载音频数据的端点， 将所述端点流方向置为去激活 inactive, 所述端点建立完成后， 修改端点流方向为收发方式 sendrecv。
本发明实施例还提供了一种监听方法， 包括以下歩骤：
1、 MGCF接收监听请求；
2、 所述 MGCF指示 IM-MGW建立音频实时传输协议 RTP流和视频 RTP流。
歩骤 2之后还可以包括：
MGCF在入局侧端点直接建立监听端点对音频进行监听； 或
所述 MGCF监听音频和视频： 将两个 RTP数据流通过 VIG合成一条 H.324M复用数据流， 对所述复用数据流进行监听； 或
所述 MGCF监听双音多频： 直接将 DTMF信号音上报到监听中心； 或 将 DTMF信号音混合在数据流中发送到监听中心， 由监听中心进行分离操 作。
本发明实施例中， 通过 MGCF和 VIG的结合， 实现了在现有网元配合 的情况下实现 IMS域和 CS域视频互通的场景； 在使用相同编解码时， 会减 少 MGCF与 IM-MGW之间的消息交互； 如果无法使用相同的编解码， 也可 以进行编解码的转换。
通过以上的实施方式的描述， 本领域的技术人员可以清楚地了解到本发 明可借助软件加必需的通用硬件平台的方式来实现， 当然本发明也可以通过 硬件来实现， 但很多情况下前者是更佳的实施方式。 基于这样的理解， 本发 明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形 式体现出来， 该计算机软件产品存储在一个存储介质中， 包括若干指令用以 使得一台计算机设备 （可以是个人计算机， 服务器， 或者网络设备等）执行本发明 各个实施例所述的方法。
以上公开的仅为本发明的几个具体实施例， 但是， 本发明并非局限于 此， 任何本领域的技术人员能思之的变化都应落入本发明的保护范围。

Claims

权利要求书
1、 一种实现 IP多媒体子*** IMS域与电路交换 CS域互通的方法， 其 特征在于， 包括以下歩骤：
接收媒体网关控制功能 MGCF的建立视频承载指示， 建立音频实时传 输协议 RTP流和视频 RTP流 ·'
分别建立入局侧和出局侧的承载音频数据和视频数据的端点， 将所述端 点流方向置为去激活 inactive, 所述端点建立完成后， 修改端点流方向为收 发方式 sendrecvo
2、 如权利要求 1所述实现 IMS域与 CS域互通的方法， 其特征在于， 根据编解码信息进行所述建立音频实时传输协议 RTP流和视频 RTP流的歩 骤， 获得所述编解码信息的方法为： 确定所述 MGCF支持的编解码与 IMS 侧支持编解码存在的交集， 以及所述 MGCF支持的编解码与 VIG侧支持编 解码存在的交集， 获得所述 MGCF支持的编解码与 IMS侧支持编解码的交 集编解码、 MGCF支持的编解码与 VIG侧支持编解码的交集编解码作为所 述编解码信息。
3、 如权利要求 1所述实现 IMS域与 CS域互通的方法， 其特征在于， 还包括： MGCF判断所述入局侧和出局侧的承载音频数据的端点使用的编 解码是否相同， 如不同则使用唇音同歩功能实现语音和视频的同歩。
4、 如权利要求 1所述实现 IMS域与 CS域互通的方法， 其特征在于， 所述分别建立入局侧和出局侧的承载音频数据和视频数据的端点具体包括： 当 MGCF收到入局请求消息后， 向 IM-MGW建立入局侧的承载， 通知 IM-MGW建立了第一端点和第三端点；
当 MGCF发送出局请求消息之前， 向 IM-MGW建立出局侧的承载， 通 知 IM-MGW建立了第二端点和第四端点； 所述第一端点和所述第二端点用 于承载音频流， 所述第三端点和所述第四端点用于承载视频流。
5、 如权利要求 1所述实现 IMS域与 CS域互通的方法， 其特征在于， 所述 MGCF通过视频编解码属性、 是否支持视频编解码、 被叫是否签 约视频业务或出局局向判断是否发起视频回落业务。
6、 如权利要求 5所述实现 IMS域与 CS域互通的方法， 其特征在于， 所述 MGCF收到 IMS的 INVITE消息， 从归属地位置寄存器 HLR取用 户路由信息 SRI, 如果通过视频承载信息取路由信息失败， 则确定被叫未签 约视频业务， 发起视频的回落； 或
获取到路由信息后， 如果被叫支持视频呼叫， 则选择 VIG局向出局， 如果 VIG局向不通， 则发起视频回落； 或如果到 VIG的局向是通的， 如果 INVITE消息中的视频编解码和入局局向能够支持的视频编解码无交集， MGCF控制下的 IM-MGW不支持编解码转换， 发起视频回落； 或
MGCF收到 IMS发送消息， 通过该消息中的承载 IP、 PORT, 流属性判 断是否发起视频回落， 当所述承载 IP、 PORT或流属性无效时， 发起视频回 落。
7、 如权利要求 6所述实现 IMS域与 CS域互通的方法， 其特征在于， 所述发起视频回落之后还包括：
MGCF收到 IMS发送消息， 通过该消息中的承载 IP、 PORT, 流属性判 断是否发起视频恢复， 当所述承载 IP、 PORT或流属性有效时， 发起视频恢 复。
8、 如权利要求 1所述实现 IMS域与 CS域互通的方法， 其特征在于， 所述 MGCF监听单音频： 在入局侧端点建立监听端点对音频进行监 听。
9、 如权利要求 1所述实现 IMS域与 CS域互通的方法， 其特征在于， 所述 MGCF监听音频和视频： 将两个 RTP数据流通过 VIG合成一条
H.324M复用数据流， 对所述复用数据流进行监听。
10、 如权利要求 1所述实现 IMS域与 CS域互通的方法， 其特征在于， 所述 MGCF监听双音多频： 将 DTMF信号音上报到监听中心； 或将 DTMF信号音混合在数据流中发送到监听中心， 由监听中心进行分离操作； 所述直接出 SIP监听话路到 LIC具体为： SIP监听端点在 MGCF上为两 个端点， 分别承载语音和话路， 对应在 LIC上， 也要有两个承载端点来承 载语音和话路。
11、 一种 IM-MGW, 其特征在于， 包括：
RTP流建立单元， 用于建立视频承载时接收 MGCF的指示， 建立音频 RTP流和视频 RTP流；
承载端点建立单元， 用于建立入局侧和出局侧的承载音频数据和视频数 据的端点， 将所述端点流方向置为 inactive, 所述端点建立完成后， 修改端 点流方向为 sendrecvo
12、 如权利要求 11所述 IM-MGW, 其特征在于， 还包括：
编解码协商单元， 用于 MGCF支持的编解码与 IMS侧支持编解码存在 交集， 也与 VIG侧支持编解码存在交集时， 将 MGCF支持的编解码与 IMS 侧支持编解码的交集编解码、 MGCF支持的编解码与 VIG侧支持编解码的 交集编解码作为编解码信息通知所述 RTP流建立单元；
所述 RTP流建立单元， 用于在建立音频 RTP流和视频 RTP流时， 根据 编解码信息建立音频 RTP流和视频 RTP流。
13、 一种 MGCF, 其特征在于， 包括：
指示单元， 用于建立视频承载时， 指示 IM-MGW建立音频 RTP流和视 频 RTP流， 并创建承载端点。
14、 如权利要求 13所述 MGCF, 其特征在于， 还包括：
视频回落业务判断单元， 用于通过视频编解码属性、 是否支持视频编解 码、 被叫是否签约视频业务， 出局局向来判断是否发起视频回落业务。
15、 如权利要求 13所述 MGCF, 其特征在于， 还包括： 监听单元， 用于监听单音频、 监听音频和视频、 监听 DTMF或直接出 监听话路到 LIC。
16、 一种视频回落的方法， 其特征在于， 包括以下歩骤：
MGCF确定需要发起视频回落业务；
所述 MGCF指示 IM-MGW建立音频实时传输协议 RTP流， 并建立入 局侧和出局侧的承载音频数据的端点， 将所述端点流方向置为去激活 inactive, 所述端点建立完成后， 修改端点流方向为收发方式 sendrecv。
17、 如权利要求 16所述视频回落的方法， 其特征在于， 所述 MGCF确 定需要发起视频回落业务具体方式包括：
所述 MGCF收到 IMS的 INVITE消息后， 从归属地位置寄存器 HLR取 用户路由信息 SRI, 如果通过视频承载信息取路由信息失败， 则确定被叫未 签约视频业务， 发起视频的回落； 或
获取到路由信息后， 如果被叫支持视频呼叫， 则选择 VIG局向出局， 如果 VIG局向不通， 则发起视频回落； 或如果到 VIG的局向是通的， 如果 INVITE消息中的视频编解码和入局局向能够支持的视频编解码无交集，
MGCF控制下的 IM-MGW不支持编解码转换； 或
MGCF收到 IMS发送消息， 通过该消息中的承载 IP、 PORT, 流属性判 断是否发起视频回落， 当所述承载 IP、 PORT或流属性无效。
18、 一种监听方法， 其特征在于， 包括以下歩骤：
MGCF接收监听请求；
所述 MGCF指示 IM-MGW建立音频实时传输协议 RTP流和视频 RTP 流。
19、 如权利要求 18所述监听方法， 其特征在于， 还包括：
MGCF在入局侧端点直接建立监听端点对音频进行监听； 或
所述 MGCF监听音频和视频： 将两个 RTP数据流通过 VIG合成一条
H.324M复用数据流， 对所述复用数据流进行监听； 或 所述 MGCF监听双音多频： 直接将 DTMF信号音上报到监听中心； 或 将 DTMF信号音混合在数据流中发送到监听中心， 由监听中心进行分离操 作。
PCT/CN2009/070785 2008-03-14 2009-03-13 一种实现ims域与cs域互通的方法及设备 WO2009111991A1 (zh)

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 (zh) 2009-09-17

Family

ID=41064770

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/070785 WO2009111991A1 (zh) 2008-03-14 2009-03-13 一种实现ims域与cs域互通的方法及设备

Country Status (2)

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

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 (de) * 2005-10-21 2007-04-26 Siemens Aktiengesellschaft Verfahren zum weiterleiten von signalisierungsdaten in einer netzübergangseinheit und in einer steuereinheit sowie zugehörige einheiten
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 (de) * 2005-10-21 2007-04-26 Siemens Aktiengesellschaft Verfahren zum weiterleiten von signalisierungsdaten in einer netzübergangseinheit und in einer steuereinheit sowie zugehörige einheiten
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 (en) Improvements in mobile telecommunication
JP2007318343A (ja) ゲートウェイ装置及び再ネゴシエーション方法
US20120075406A1 (en) Method And System For Handling A Multi-Media Call Setup Request
WO2012174904A1 (zh) 一种ims会议接入的方法、装置及***
WO2009111991A1 (zh) 一种实现ims域与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 (en) System and method for three-party call service
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
WO2012171290A1 (zh) 询问转接实现方法、应用服务器、业务终端和***
JP2004173051A (ja) ＶｏＩＰパケット情報蓄積システム
JP2005252939A (ja) インタワーク装置
KR101208119B1 (ko) 스마트 카드를 이용한 ｓｉｐ 기반 영상통화 서비스 시스템 및 그 방법
JP5120813B2 (ja) Ｓｉｐ電話交換システムおよびｓｉｐ電話交換方法

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