WO2009079810A1 - Procédé de négociation de transmission redondante - Google Patents

Procédé de négociation de transmission redondante Download PDF

Info

Publication number
WO2009079810A1
WO2009079810A1 PCT/CN2007/003495 CN2007003495W WO2009079810A1 WO 2009079810 A1 WO2009079810 A1 WO 2009079810A1 CN 2007003495 W CN2007003495 W CN 2007003495W WO 2009079810 A1 WO2009079810 A1 WO 2009079810A1
Authority
WO
WIPO (PCT)
Prior art keywords
bearer
media gateway
redundant transmission
passive
message
Prior art date
Application number
PCT/CN2007/003495
Other languages
English (en)
French (fr)
Inventor
Xiang Li
Xiang Chen
Original Assignee
Zte Corporation
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 Zte Corporation filed Critical Zte Corporation
Priority to US12/746,733 priority Critical patent/US20100262698A1/en
Priority to CN2007801017474A priority patent/CN101878628B/zh
Priority to PCT/CN2007/003495 priority patent/WO2009079810A1/zh
Priority to EP07845853A priority patent/EP2226985A4/en
Publication of WO2009079810A1 publication Critical patent/WO2009079810A1/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/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
    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • 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/80—Responding to QoS

Definitions

  • the present invention relates to the field of communications technologies, and in particular, to a redundant transmission negotiation method for IP bearer establishment process of two media gateways in a circuit domain based on the RFC 2198 standard, and a method Redundant transmission negotiation method for IP bearer modification of two media gateways in a circuit domain based on the RFC2198 standard.
  • BACKGROUND OF THE INVENTION In the core network circuit domains of the third generation wireless communication networks (WCDMA, CDMA2000, TD-SCDMA) and NGN (Next Generation Network), the idea of separation of bearer and control and the networking mode are adopted.
  • the primary network elements are the Media Gateway (MGW) and the Gateway Controller (MGC).
  • the media gateway provides the control function of the media stream, mainly for the establishment and maintenance of the bearer, the connection control, the speech coding processing and the conversion, and the like.
  • the gateway controller provides functions such as call control and mobility management, including call control flow, user authentication, and accounting.
  • the H.248/Megaco protocol contacts MGC and MGW and is currently the mainstream media gateway control protocol.
  • the MGC controls the process of establishing, modifying, and releasing calls through the Bearer Independent Call Control Protocol (BICC).
  • BICC Bearer Independent Call Control Protocol
  • the most common media surface data transmission between MGWs is RTP/IP.
  • IPBCP IP Bearer Control Protocol
  • the IP Bearer Control Protocol (IPBCP) is the main control protocol for RTP/IP bearers between WCDMA and TD-SCDMA core network MGW. It transmits RTP/IP bearer parameters between the MGWs through the tunneling mechanism provided by the H.248 and BICC protocols to complete bearer control. Since IP is a best-effort transmission strategy, packet loss may occur due to network quality problems in actual operation. Data loss due to packet loss reduces audio and video quality for voice and video calls. For data services, the impact is greater and may result in business failure.
  • the standards organization IETF developed the RFC2198 standard to mitigate the adverse effects of packet loss.
  • the main idea is that the data that has already been transmitted will be transmitted again or several times during subsequent data transmission. Such lost packets are compensated for by subsequent redundant transmissions.
  • the relevant parameters of the redundant transmission of the data packet are indicated by the SDP. Bearer connection between body gateways.
  • the method may also include: setting the SDP information in the 7-establishment request tunnel message between the two media gateways to conform to the format requirement of the RFC2198 parameter.
  • the SDP information includes at least: a media declaration and a media attribute.
  • the following processing may also be performed in S206:
  • the IP bearer control module determines whether the passive media gateway supports redundant transmission.
  • step S206 when receiving the bearer setup request tunnel message, the passive media gateway parses the bearer setup request tunnel message; and the passive media gateway passes the IP bearer control module to the RTP/
  • the IP protocol processing module sends a passive end bearer setup request, where the passive end bearer setup request includes at least: an IP address parameter, and a redundant transmission parameter in the bearer setup request tunnel message.
  • the IP bearer control module returns the bearer setup request tunnel message as the bearer setup response tunnel message to the active media gateway as it is.
  • step S206 when receiving the bearer setup request tunnel message, the passive media gateway parses the bearer setup request tunnel message; and the passive media gateway passes the IP
  • the bearer control module sends a passive bearer setup request to the RTP/IP protocol processing module, where the passive bearer setup request includes at least an IP address parameter, and does not include a redundant transmission parameter in the bearer setup request tunnel message.
  • the IP bearer control module modifies the bearer setup request tunnel message and removes the redundant transmission parameter; and the IP bearer control module returns the modified bearer setup request tunnel message as the bearer setup response tunnel message to the active Media gateway.
  • a redundant transmission negotiation method for implementing negotiation of redundant transmission in an IP bearer modification process of two media gateways in a circuit domain based on the RFC 2198 standard, including the following steps S402:
  • the IP bearer control module determines whether to modify the redundant transmission function of the current service according to the current service requirement, and according to the judgment result of the IP bearer control module, the active media gateway sends a bearer modification request message to the passive media gateway;
  • the passive media gateway analyzes the bearer modification request message, and sends a bearer modification request message to the RTP/IP protocol processing module according to the analysis result;
  • S406 the passive media gateway adopts the IP bearer control module to actively The media gateway sends a bearer modification response message;
  • S408 according to the bearer modification response message, the active media gateway performs a modification process, where the bearer repair
  • the BICC signaling for call management between the MGCs does not have the SDP negotiation capability, whether the MGW
  • the RFC2198 capability related configuration is set on the relevant MGW. This reduces the flexibility and greatly increases the difficulty of maintaining the system. Because the configuration is inconsistent between the two MGWs, the data transmission will be incorrect.
  • the IPBCP protocol provides the tunneling mechanism in the ⁇ .248 and the BICC protocol, so that the two MGWs can send SDP information to each other to achieve the purpose of transmitting bearer-related information. This also makes it possible to pass RFC2198 related parameters between MGWs.
  • IPBCP does not currently have the ability to support RFC2198 negotiations.
  • the present invention provides a redundant transmission negotiation method for IP bearer establishment process of two media gateways in a circuit domain based on the RFC2198 standard, and a method for using the RFC2198-based standard A redundant transmission negotiation method in the IP bearer modification process of the two media gateways in the circuit domain.
  • the present invention can enable the two inter-office MGWs to send SDP information to each other to achieve the purpose of transmitting bearer related information, which is also RFC2198. It is possible to pass relevant parameters between MGWs.
  • a redundant transmission negotiation method for implementing negotiation of redundant transmission in an IP bearer establishment process of two media gateways in a circuit domain based on the RFC2198 standard, including the following steps: S202 When the active media gateways of the two media gateways initiate a bearer connection establishment process between the media gateway offices according to the service requirement, the IP bearer control module determines whether the active media gateway supports redundant transmission; S204, if the active media gateway supports redundancy And transmitting, and the service needs redundant transmission, carrying the redundant transmission parameter in the bearer setup request tunnel message, and sending the bearer setup request tunnel message to the passive media gateway in the two media gateways; S206, when receiving the bearer When the request tunnel message is established, the passive media gateway parses the bearer setup request tunnel message, and sends a passive end bearer setup request to the RTP/IP protocol processing module by using the IP bearer control module; S208, after receiving the passive end bearer setup request, RTP /IP protocol control module establishes passive end bearer connection, and
  • the method further includes: determining whether the active media gateway has a redundant transmission function. If the active media gateway has a redundant transmission function, the following processing is performed in S402: When the redundant transmission function is not enabled in the service and the IP bearer control module determines that the redundant transmission function needs to be enabled, the IP bearer control module sends the RTP/IP to the RTP/IP. The protocol processing module requires the redundancy transmission function to be enabled; and if the activation is successful, the active media gateway sends a bearer modification request carrying the redundant transmission information to the passive media gateway, and if the startup fails, the modification processing is terminated.
  • the passive media gateway analysis bearer modification request message carries redundant transmission information; and the IP bearer control module checks whether the passive media gateway supports the redundant transmission function; If the passive media gateway supports the redundant transmission function, a redundant transmission function open request is sent to the RTP/IP protocol processing module, and if not, no message is sent to the RTP/IP protocol processing module.
  • the active media gateway has a redundant transmission function, the following processing is performed in S402: when the redundant transmission function is enabled for the service and the IP bearer control module determines that the redundant transmission function is not required to be enabled, the active media gateway A bearer modification request that does not carry redundant transmission information is sent to the passive media gateway.
  • the passive media gateway analyzes the bearer modification request message without carrying redundant transmission information; the IP bearer control module sends a redundant transmission function to the RTP/IP protocol processing module. Turn off the request to turn off the redundant transfer function.
  • the following processing may be specifically performed in S406: if the redundant transmission information is carried in the bearer modification request message, and the passive media gateway does not support the redundant transmission function, the passive media gateway passes the IP bearer control module to the active media gateway.
  • a bearer modification response message indicating rejection if the bearer modification request message carries redundant transmission information, and the passive media gateway supports the redundant transmission function, the passive media gateway returns an accepted bearer to the active media gateway through the IP bearer control module. Modifying the response message; if the redundant transmission information is not carried in the bearer modification request message, and the passive media gateway successfully disables the redundancy function, the passive media gateway returns an bearer modification response message indicating acceptance to the active media gateway through the IP bearer control module; Or if the redundant transmission information is not carried in the bearer modification request message, and the passive media gateway does not successfully disable the redundant transmission function, the passive media gateway returns a representation to the active media gateway through the IP bearer control module. The rejected modification response message.
  • the following processing is performed in S408: If the tampering process is to enable the redundant transmission function, the current modification process ends; or if the tampering process is turned off. For the remaining transmission function, the active media gateway sends a request to turn off the redundant transmission function to the RTP/IP protocol processing module to turn off the redundant transmission function, thereby ending the modification process.
  • the bearer modification response message indicating the rejection is returned, the following processing is performed in S408: If the modification processing is to enable the redundant transmission function, the active media gateway sends the redundancy to the RTP/IP protocol processing module.
  • the request for the transfer function is enabled to enable the redundant transfer function, thereby ending the tampering process; or if the 4 tampering process is to turn off the redundant transfer function, the 1 tampering process ends.
  • the invention effectively enables the inter-office MGWs to send SDP information to each other to achieve the purpose of transmitting bearer related information. This also makes it possible to pass RFC2198 related parameters between MGWs.
  • FIG. 1 is a schematic diagram of an IPBCP tunnel message mechanism according to the present invention
  • FIG. 2 is a flowchart of a redundant transmission negotiation method according to an aspect of the present invention
  • FIG. 3 is an IP bearer established in an embodiment of the present invention.
  • FIG. 4 is a flowchart of a redundant transmission negotiation method according to another aspect of the present invention
  • FIG. 5 is an RFC 2198 redundancy negotiation in an IP bearer modification process according to an embodiment of the present invention.
  • Schematic diagram of the process. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The preferred embodiments of the present invention are described with reference to the accompanying drawings. In the present invention, the following mainly relates to the following aspects: 1.
  • the tunnel message of the IPBCP supports the requirement of the SDP format of the RFC2198 (as shown in FIG. 1);
  • the RFC2198 parameter is carried in the tunnel message of the IP Bearer establishment process of the IPBCP for negotiation (as shown in Figure 2 and Figure 3);
  • FIG. 1 is a schematic diagram of an IPBCP tunnel message mechanism according to the present invention. As shown in Figure 1, the IPBCP tunnel message format is defined as the parameter negotiation of RFC 2198. First, the SDP information format in the IPBCP tunnel message needs to be clearly defined.
  • the RFC2198 related information only affects the following parts of the SDP in the IPBCP tunnel message:
  • Media Announcement m ⁇ media> ⁇ port> ⁇ transport> ⁇ fmtlist>, where ⁇ fint 1> can be of multiple load types ( Payload Type), the first payload type in the list is the redundant payload type.
  • the media attribute is a media attribute.
  • you need to support the redundant codec priority list declarations required by RFC2198: a fmtp: ⁇ redundant payload> ⁇ format 1 >/ ⁇ format2>[/ ⁇ format3> ] All ⁇ 1"0111131> above must have been declared in the media declaration ⁇ ftnt list>.
  • ⁇ £"0011311 > The main encoding and decoding type for the actual media stream, and the rest of the encoding and decoding types for redundant data. 2 is a flow chart of a redundant transmission negotiation method in accordance with an aspect of the present invention. As shown in Figure 2, the following steps are included:
  • the IP bearer control module determines whether the active media gateway supports redundant transmission; S204, if the active media gateway supports redundancy If the transmission is redundant, and the service needs to be redundantly transmitted, the redundant transmission parameter is carried in the bearer setup request tunnel message, and the bearer setup request tunnel message is sent to the passive media gateway in the two media gateways;
  • the passive media gateway parses the bearer setup request tunnel message, and sends a passive bearer setup request to the RTP/IP protocol processing module by using the IP7 bearer control module.
  • the RTP/IP protocol control module After receiving the passive bearer setup request, the RTP/IP protocol control module establishes a passive bearer connection, and the IP bearer control module sends a bearer setup response tunnel message carrying the redundant transmission parameter to the active media gateway;
  • the active media gateway After receiving the bearer setup response tunnel message, the active media gateway sends an active end bearer setup request to the RTP/IP protocol processing module by using the IP bearer control module to establish an active end bearer connection, thereby implementing the active end media gateway.
  • a bearer connection to the passive media gateway Before S202, the method may further include: setting the SDP information in the bearer setup request tunnel message between the two media gateways to conform to the format requirement of the RFC2198 parameter.
  • the SDP information includes at least: a media declaration and a media attribute.
  • the IP bearer control module determines whether the passive media gateway supports redundant transmission.
  • step S206 Upon receiving the bearer setup request tunnel message, the passive media gateway parses the bearer setup request tunnel message; and the passive media gateway sends a passive end bearer setup request to the RTP/IP protocol processing module through the IP bearer control module, where the passive end bearer
  • the setup request includes at least: an IP address parameter, and a redundant transmission parameter in the bearer setup request tunnel message.
  • the IP bearer control module returns the bearer setup request tunnel message as the bearer setup response tunnel message to the active media gateway as it is.
  • step S206 when receiving the bearer setup request tunnel message, the passive media gateway parses the bearer setup request tunnel message; and the passive media gateway passes the IP
  • the bearer control module sends a passive bearer setup request to the RTP/IP protocol processing module, where the passive bearer setup request includes at least an IP address parameter, and does not include a redundant transmission parameter in the bearer setup request tunnel message.
  • the IP bearer control module modifies the bearer setup request tunnel message and removes the redundant transmission parameter; and the IP bearer control module returns the modified bearer setup request tunnel message as the bearer setup response tunnel message to the active source as it is.
  • FIG. 3 is a schematic diagram of an RFC 2198 redundancy negotiation process in an IP bearer setup process according to an embodiment of the present invention. As shown in Figure 3, the following steps are included:
  • the IPBCP on the MGW1 starts to initiate the establishment of the MGW inter-office RTP/IP bearer, reserves the required resources, and obtains the capability information of whether the MGW1 supports the redundancy of the RFC2198; If the IPBCP finds that the MGW1 supports the RFC2198 redundancy, and the call service needs 4 redundancy to ensure the transmission, the RFC2198 information is carried in the tunnel message carrying the request.
  • the IPBCP first obtains the capability information of the MGW to see if the redundancy function is supported.
  • the following two processes are as follows: 1. MGW2 supports RFC2198 redundancy, IPBCP sends a request to the RTP/IP protocol, carries IP address and other parameters, and RFC2198 information in the MGW1 tunnel message to establish a bearer connection; 2. MGW2 does not support RFC2198 redundancy. IPBCP sends a request to the RTP/IP protocol, carries parameters such as an IP address, and establishes a bearer connection. Do not pass RFC2198 information;
  • MGW2 does not support RFC2198 redundancy. IPBCP modifies the media declaration and media attributes in the tunnel message sent by MGW1, and removes RFC2198 information. Only other codec information is sent back to MGW1 with the reply tunnel message.
  • the tunnel message carries the RFC2198 information, indicating that MGW2 supports RFC2198 redundancy, and the IPBCP sends a request to the RTP/IP protocol to carry the IP.
  • the address and other parameters and the RFC2198 information in the MGW2 tunnel message establish a bearer connection; and 2.
  • the tunnel message does not carry the RFC2198 information, indicating that the MGW2 does not support the RFC2198 redundancy, and the IPBCP sends a request to the RTP/IP protocol to carry the IP address and other parameters. , establish a bearer connection, do not pass RFC2198 information.
  • 4 is a flow chart of a redundant transmission negotiation method in accordance with another aspect of the present invention. As shown in Figure 4, the method includes the following steps: S402.
  • the IP bearer control module determines whether to modify the redundant transmission function of the current service according to the current service requirement, and according to the judgment result of the IP bearer control module, the active media gateway sends a bearer modification request message to
  • the passive media gateway After receiving the bearer modification request message, the passive media gateway analyzes the bearer modification request message, and sends a bearer modification request message to the RTP/IP protocol processing module according to the analysis result.
  • the passive media gateway sends a bearer modification response message to the active media gateway by using an IP bearer control module;
  • the active media gateway performs a modification process according to the bearer modification response message.
  • the bearer modification request message and the bearer modification response message carry redundant transmission parameters.
  • the method further includes: determining whether the active media gateway has a redundant transmission function. If the active media gateway has a redundant transmission function, the following processing is performed in S402: When the redundant transmission function is not enabled in the service and the IP bearer control module determines that the redundant transmission function needs to be enabled, the IP bearer control module sends the RTP/IP to the RTP/IP.
  • the protocol processing module requires the redundancy transmission function to be enabled; and if the startup is successful, the active media gateway sends the bearer modification request carrying the redundant transmission information to the passive media gateway, and if the startup fails, the 4 tampering process is terminated. Then, the following processing is performed in S404: after receiving the bearer modification request message, the passive media gateway analyzes the bearer modification request message and carries the redundant transmission information; the IP bearer control module checks whether the passive media gateway supports the redundant transmission function; And if the passive media gateway supports the redundant transmission function, the redundant transmission function open request is sent to the RTP/IP protocol processing module, and if not, no message is sent to the RTP/IP protocol processing module.
  • the active media gateway has a redundant transmission function
  • the following processing is performed in S402: when the redundant transmission function is enabled for the service and the IP bearer control module determines that the redundant transmission function is not required to be enabled, the active media gateway A bearer modification request that does not carry redundant transmission information is sent to the passive media gateway.
  • the following processing is performed in S404: after receiving the bearer modification request message, the passive media gateway analyzes the bearer modification request message without carrying redundant transmission information; the IP bearer control module sends the redundant transmission to the RTP/IP protocol processing module.
  • the feature close request closes the redundant transfer function.
  • the following processing may be specifically performed in S406: if the redundant transmission information is carried in the bearer modification request message, and the passive media gateway does not support the redundant transmission function, the passive media gateway passes the IP bearer control module to the active media.
  • the gateway returns a bearer modification response message indicating rejection; if the bearer modification request message carries redundant transmission information, and the passive media gateway supports the redundant transmission function, the passive media gateway returns an indication to the active media gateway through the IP bearer control module.
  • the bearer modification response message if the bearer modification request message does not carry the redundant transmission information, and the passive media gateway successfully disables the redundancy function, the passive media gateway returns an bearer modification response indicating acceptance to the active media gateway through the IP bearer control module.
  • the passive media gateway Message; or if the redundant transmission information is not carried in the bearer modification request message, and the passive media gateway does not successfully disable the redundant transmission function, the passive media gateway returns a bearer indicating rejection to the active media gateway through the IP bearer control module. Change reply message.
  • the following processing is performed in S408: If the tampering process is to enable the redundant transmission function, the tampering process ends; or if the modification process is to turn off the redundancy For the remaining transmission function, the active media gateway sends a request to turn off the redundant transmission function to the RTP/IP protocol processing module to turn off the redundant transmission function, thereby ending the modification process.
  • FIG. 5 is a schematic diagram of an RFC2198 redundancy negotiation process in an IP bearer modification process according to an embodiment of the present invention. As shown in FIG. 5, the method includes the following steps:
  • the IPBCP on the MGW1 determines that the switch state of the RFC2198 redundancy function needs to be changed, and then initiates the modification of the MGW inter-office RTP/IP bearer, reserves the required resources, and obtains whether the MGW supports the RFC2198. Redundant capability information, there may be more than one case where the RFC2198 redundancy function needs to be switched. The more common possibility is that when a call is switched between voice service and data service, the switch redundancy function is required. Data services are more sensitive to data loss due to packet loss. Therefore, redundancy is required for protection. Voice services will not cause too much impact on calls because they are dropped.
  • the present invention initiates such bearer modification by the initiator at the time of the bearer establishment; S504: Send a bearer modification request message according to different situations, where if the call does not currently enable RFC2198 redundancy, and the IPBCP needs to use redundancy according to the judgment, and the MGW1 supports the RFC2198 function, first perform redundancy to the RTP/IP protocol processing request. Function, if the connection is successful, send a bearer modification request message to MGW2, carrying RFC2198 redundancy information.
  • the process is terminated.
  • IPBCP does not judge according to the judgment. If the redundancy is required, the bearer modification request message is sent to the MGW2, and the RFC2198 redundancy information is not carried, and only the actual media codec information is carried;
  • the IPBCP on the MGW2 has the following different processing according to whether the RFC2198 information is carried in the following: If there is no RFC2198 information in the tunnel message, the IPBCP sends a request to the RTP/IP protocol to close the RFC2198 redundancy. If the tunnel message carries RFC2198 information, the IPBCP checks the MGW capability information, and if the MGW supports RFC2198 redundancy, sends a request to the RTP/IP protocol to enable the RFC2198 redundancy function, and if not, Do not do anything with RTP/IP protocol processing;
  • the IPBCP on the MGW2 sends the response tunnel message to the MGW1, and the following situations are met:
  • the MGW1 carries the RFC2198 redundancy information in the tunnel message, but the MGW2 does not support, or the support but the modification is successful, the IPBCP of the MGW2 responds to the MGW1.
  • the IPBCP shell 1 J MGW2 receiving a response to the MGW1 (the Accept) message tunnel; MGW 1, and does not carry the RFC2198 redundant information in the tunnel message, but the MGW2 off redundancy If it fails, the IPBCP of MGW2 replies to MGW1 with a Reject tunnel message;
  • the IPBCP of the MGW1 receives the response tunneling message sent by the MGW2, according to whether the message accepts or refuses to do the following different processing:
  • the tunnel message is "accepted”, if the current modification is to enable the RFC2198 redundancy function, then The process ends, and if this time, instead of turning off the RFC2198 redundancy function, the request to close the function is sent to the RTP/IP protocol processing, so that the modification process ends; and the tunnel message is "rejected", if this time is changed to When the RFC2198 redundancy function is enabled, the request to turn off this function is sent to the RTP/IP protocol processing, so that the modification process ends, and if the current modification is to turn off the RFC2198 redundancy function, the tampering process ends.
  • the redundancy function needs to consume more resources, turning off the redundancy function will only lead to a decrease in resource consumption. Therefore, it is generally considered that turning on the redundancy function is more likely to fail, and turning off this function generally does not fail. Therefore, in the two cases of turning the redundancy function on and off, it is different whether or not the switching operation is performed before the tunnel message is sent. The principle is, if it is on, operate as early as possible, if it is off, operate as late as possible.
  • the present invention enables the two MGWs to send SDP information to each other to achieve the purpose of transmitting related information, and provides a possibility for RFC2198 related parameters to be transmitted between the MGWs.

Landscapes

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

Description

冗余传输协商方法 技术领域 本发明涉及通信技术领域， 更具体地涉及一种用于在基于 RFC2198标 准的电路域的两个媒体网关的 IP承载建立过程中的冗余传输协商方法、以及 一种用于在基于 RFC2198标准的电路域的两个媒体网关的 IP承载修改过程 中的冗余传输协商方法。 背景技术 在第三代无线通信网络（ WCDMA, CDMA2000, TD-SCDMA )和 NGN ( Next Generation Network,下一代网络） 的核心网电路域中 , 都采用了承载 与控制分离的思想和组网方式。 如图 1所示， 主要网元为媒体网关 （MGW ) 和网关控制器 （MGC )。 媒体网关提供媒体流的控制功能， 主要为承载的建 立与维护， 接续控制， 语音编码处理和转换等等。 网关控制器提供呼叫控制 和移动性管理等功能， 主要包括呼叫控制流程， 用户鉴权， 计费等。
H.248/Megaco协议联系 MGC和 MGW, 是目前主流的媒体网关控制协议。
MGC之间通过承载无关呼叫控制协议（BICC )对呼叫的建立、 修改和释放 等流程进行控制。 MGW之间的媒体面数据传输目前用的最多的是 RTP/IP承 栽。 IP承载控制协议（ IPBCP )是 WCDMA和 TD-SCDMA核心网 MGW之 间 RTP/IP承载的主要控制协议。它通过由 H.248和 BICC协议提供的隧道机 制在 MGW之间传输 RTP/IP承载参数， 以完成承载控制。 由于 IP是采用尽力而为的传输策略， 在实际运行中可能由于网络质量 问题导致存在丢包的现象。 丢包造成的数据丢失， 对语音和视频呼叫来说， 会降低音频和视频的质量。 对于数据业务来说， 则影响更大， 可能造成业务 失败。 针对这个问题，标准组织 IETF制定了 RFC2198标准用以緩解丢包带来 的不良影响。 主要思想是已经传输过的数据会在后续数据传输时被再次传输 一次或者数次。 这样丟失的数据包由于后续的冗余传输而得到了弥补。 数据 包冗余传输的相关参数通过 SDP来指示。 体网关之间的承载连接。 在 S202之前， 该方法还可以包 4舌： 将在两个媒体网关之间的 7 栽建立 请求隧道消息中的 SDP信息设置成符合 RFC2198参数的格式要求。 在本发明中， SDP信息至少包括： 媒体声明和媒体属性。 在 S206中还可以执行以下处理： IP承载控制模块判断被动媒体网关是 否支持冗余传输。 当被动媒体网关支持冗余传输时， 在步骤 S206中执行以下处理： 当接 收到承载建立请求隧道消息时， 被动媒体网关解析承载建立请求隧道消息； 以及被动媒体网关通过 IP 载控制模块向 RTP/IP协议处理模块发送被动端 承栽建立请求， 其中， 被动端承栽建立请求中至少包括： IP地址参数、 和承 载建立请求隧道消息中的冗余传输参数。 然后， 在 S208 中， IP承载控制模 块将承载建立请求隧道消息作为承载建立应答隧道消息原样返回给主动媒体 网关。 另夕卜， 当被动媒体网关不支持冗余传输时， 在步骤 S206中执行以下处 理： 当接收到承载建立请求隧道消息时， 被动媒体网关解析承载建立请求隧 道消息； 以及被动媒体网关通过 IP承栽控制模块向 RTP/IP协议处理模块发 送被动端承载建立请求，其中，被动端承载建立请求中至少包括 IP地址参数， 而不包括承载建立请求隧道消息中的冗余传输参数。 然后， 在 S208中， IP承栽控制模块对承载建立请求隧道消息进行修改 并去除冗余传输参数；以及 IP承载控制模块将修改后的承载建立请求隧道消 息作为承载建立应答隧道消息原样返回给主动媒体网关。 根据本发明的另一个方面， 还提供了一种冗余传输协商方法， 用于在基 于 RFC2198标准的电路域的两个媒体网关的 IP承载修改过程中， 实现冗余 传输的协商， 包括以下步骤： S402, 根据当前业务的需要， IP承栽控制模块 判断是否要修改当前业务的冗余传输功能，并且根据 IP承载控制模块的判断 结果， 主动媒体网关向被动媒体网关发送承载修改请求消息； S404, 在接收 到承载修改请求消息之后， 被动媒体网关对承载修改请求消息进行分析 , 并 根据分析结果向 RTP/IP 协议处理模块发送承载修改请求消息； S406, 被动 媒体网关通过 IP承载控制模块向主动媒体网关发送承载修改应答消息；以及 S408, 根据承载修改应答消息， 主动媒体网关执行修改处理， 其中， 承载修 但是由于 MGC之间用于呼叫管理的 BICC信令没有 SDP的协商能力， 因此一个呼叫涉及的 MGW是否支持 RFC2198以及相关参数无法在 MGC之 间得到协商。 目前只能靠一些依靠人为保障的方法来解决。例如在相关 MGW 上设置 RFC2198能力相关的配置。 这既降氐了灵活度， 同时也大大增加了系 统的维护难度。 因为一旦两个 MGW之间配置不一致， 就会造成数据传输不 正确。 由于 IPBCP协议通过在 Η.248和 BICC协议中提供隧道机制， 使得局 间两个 MGW之间可以相互发送 SDP信息以达到传递承载相关信息的目的。 这也为 RFC2198相关参数在 MGW之间传递提供了可能。 但是目前 IPBCP 并没有支持 RFC2198协商的能力。 发明内容 鉴于上述问题， 本发明提供了一种用于在基于 RFC2198标准的电路域 的两个媒体网关的 IP承栽建立过程中的冗余传输协商方法、以及一种用于在 基于 RFC2198标准的电路域的两个媒体网关的 IP承载修改过程中的冗余传 输协商方法， 通过本发明， 可以使局间两个 MGW 之间可以相互发送 SDP 信息以达到传递承载相关信息的目的 ,也为 RFC2198相关参数在 MGW之间 传递提供了可能。 根据本发明的一个方面， 提供了一种冗余传输协商方法， 用于在基于 RFC2198标准的电路域的两个媒体网关的 IP 载建立过程中， 实现冗余传 输的协商， 包括以下步骤： S202, 当两个媒体网关中的主动媒体网关根据业 务需要发起在媒体网关局间的承载连接建立流程时， IP承载控制模块判断主 动媒体网关是否支持冗余传输； S204, 如果主动媒体网关支持冗余传输， 并 且本次业务需要冗余传输，则在承载建立请求隧道消息中携带冗余传输参数， 并将承载建立请求隧道消息发送给两个媒体网关中的被动媒体网关； S206, 当接收到承载建立请求隧道消息时， 被动媒体网关解析承载建立请求隧道消 息， 并通过 IP承载控制模块向 RTP/IP协议处理模块发送被动端承载建立请 求； S208， 在接收到被动端承栽建立请求之后， RTP/IP协议控制模块建立被 动端承载连接，并且 IP承载控制模块向主动媒体网关发送携带有冗余传输参 数的承载建立应答隧道消息；以及 S210,在接收到承载建立应答隧道消息后， 主动媒体网关通过 IP承栽控制模块向 RTP/IP协议处理模块发送主动端 载 建立请求来建立主动端承载连接， 从而实现了在主动端媒体网关和被动端媒
2 ？丈请求消息和承载修改应答消息中携带有冗余传输参数。 在 S402之前， 本方法还包括： 判断主动媒体网关是否具有冗余传输功 能。 如果主动媒体网关具有冗余传输功能， 则在 S402中执行以下处理： 当 此次业务没有开启冗余传输功能并且 IP 承载控制模块判断需要开启冗余传 输功能时， IP承载控制模块向 RTP/IP协议处理模块要求开启冗余传输功能； 以及如果开启成功， 则主动媒体网关将携带有冗余传输信息的承载修改请求 发送给被动媒体网关， 而如果开启失败， 则终止修改处理。 然后， 在 S404中执行以下处理： 在接收到承载修改请求消息之后， 被 动媒体网关分析承载修改请求消息中携带有冗余传输信息； IP承载控制模块 检查被动媒体网关是否支持冗余传输功能； 以及如果被动媒体网关支持冗余 传输功能， 则向 RTP/IP协议处理模块发送冗余传输功能开启请求， 而如果不 支持， 则不对 RTP/IP协议处理模块发送任何消息。 另夕卜， 如果主动媒体网关具有冗余传输功能， 则在 S402中执行以下处 理： 当此次业务已开启冗余传输功能并且 IP承载控制模块判断不需要开启冗 余传输功能时， 主动媒体网关将没有携带冗余传输信息的承载修改请求发送 给被动媒体网关。 然后， 在 S404中执行以下处理： 在接收到承载修改请求消息之后， 被 动媒体网关分析承载修改请求消息中没有携带冗余传输信息； IP承载控制模 块向 RTP/IP协议处理模块发送冗余传输功能关闭请求来关闭冗余传输功能。 本发明中， 在 S406中可以具体执行以下处理： 如果在承载修改请求消 息中携带冗余传输信息， 并且被动媒体网关不支持冗余传输功能， 则被动媒 体网关通过 IP 承载控制模块向主动媒体网关返回表示拒绝的承载修改应答 消息； 如果在承载修改请求消息中携带冗余传输信息， 并且被动媒体网关支 持冗余传输功能，则被动媒体网关通过 IP承载控制模块向主动媒体网关返回 表示接受的承载修改应答消息； 如果在承载修改请求消息中没有携带冗余传 输信息， 并且被动媒体网关成功关闭冗余功能 , 则被动媒体网关通过 IP承载 控制模块向主动媒体网关返回表示接受的承载修改应答消息； 或如果在承载 修改请求消息中没有携带冗余传输信息， 并且被动媒体网关没有成功关闭冗 余传输功能，则被动媒体网关通过 IP承载控制模块向主动媒体网关返回表示 拒绝的承栽修改应答消息。 当返回的是表示接受的承载修改应答消息时，在 S408中执行以下处理： 如果此次爹改处理为开启冗余传输功能， 则此次 改处理结束； 或如果此次 爹改处理为关闭冗余传输功能，则主动媒体网关向 RTP/IP协议处理模块发送 关闭冗余传输功能的请求来关闭冗余传输功能， 从而结束此次修改处理。 可选地， 返回的是表示拒绝的承载修改应答消息时， 在 S408中执行以 下处理： 如果此次修改处理为开启冗余传输功能， 则主动媒体网关向 RTP/IP 协议处理模块发送开启冗余传输功能的请求来开启冗余传输功能， 从而结束 此次爹改处理； 或如果此次 4爹改处理为关闭冗余传输功能， 则此次 1爹改处理 结束。 通过本发明， 有效使局间两个 MGW之间可以相互发送 SDP信息以达 到传递承载相关信息的目的。这也为 RFC2198相关参数在 MGW之间传递提 供了可能。 本发明的其它特征和优点将在随后的说明书中阐述， 并且， 部分地从说 明书中变得显而易见， 或者通过实施本发明而了解。 本发明的目的和其他优 点可通过在所写的说明书、 权利要求书、 以及附图中所特别指出的结构来实 现和获得。 附图说明 附图用来提供对本发明的进一步理解， 并且构成说明书的一部分， 与本 发明的实施例一起用于解释本发明， 并不构成对本发明的限制。 在附图中： 图 1为本发明所涉及的 IPBCP隧道消息机制的示意图； 图 2为根据本发明一个方面的冗余传输协商方法的流程图； 图 3为 居本发明实施例的 IP 栽建立过程中的 RFC2198冗余协商过 程的示意图； 图 4为根据本发明另一个方面的冗余传输协商方法的流程图； 以及 图 5为根据本发明实施例的 IP承载修改过程中的 RFC2198冗余协商过 程的示意图。 具体实施方式 以下结合附图对本发明的优选实施例进行说明， 应当理解， 此处所描述 的优选实施例仅用于说明和解释本发明， 并不用于限定本发明。 在本发明中， 主要涉及以下几个方面： 1、 IPBCP的隧道消息支持 RFC2198对 SDP格式的要求（如图 1所示）；
2、 在 IPBCP的 IP承载建立 （ IP Bearer establishment )过程的隧道消息 中携带 RFC2198参数进行协商 （如图 2和图 3所示）； 以及
3、 在 IPBCP的 IP 栽修改（ IP Bearer modification ) 过程的隧道消息 中携带 RFC2198参数进行协商 （如图 4和图 5所示）。 另夕卜， 还涉及 MGW上的 IPBCP协议处理部分将协商后的 RFC2198相 关参数下发给 RTP/IP协议栈处理以支持相应的 RFC2198冗余功能。 图 1为本发明所涉及的 IPBCP隧道消息机制的示意图。 如图 1所示， IPBCP隧道消息格式定义为实现 RFC2198的参数协商，首先需要清晰的定义 IPBCP隧道消息中的 SDP信息格式。 RFC2198相关信息只影响 IPBCP隧道 消息中 SDP的以下部分： 媒体声明 ( Media Announcement ) m=<media> <port> <transport> <fmt list>, 其中， <fint 1>可以为多个 栽荷类型（ Payload Type )的声明列表， 列表中第一个载荷类型为冗余载荷类 型。 媒体属 4生 ( Media attributes ) 每个 <fmt list> 的动态栽荷类型需要有一个媒体属性说明， 格式如下： a=rtpmap:<payload><encoding name>/<clock rate> [/<encoding parameters>]， 其中 <encoding parameters>为可选项目，特别的，对于冗余载荷类型的声明格 式 为 ： a=rtpmap:< redundant payload> red/<clock rate> [/<encoding parameters>]。 另外， 还需支持 RFC2198需要的冗余编解码优先列表声明: a=fmtp： <redundant payload> <format 1 >/<format2> [/<format3> ] 以上所有<1"0111131>都必须是在媒体声明的 <ftnt list>已经声明过的。 其中 <£"0011311 >为实际媒体流的主编解码类型，其余后面的的为冗余数据的编解码 类型。 图 2为 居本发明一个方面的冗余传输协商方法的流程图。如图 2所示， 包括以下步骤：
S202 ,当两个媒体网关中的主动媒体网关根据业务需要发起在媒体网关 局间的承载连接建立流程时， IP承载控制模块判断主动媒体网关是否支持冗 余传输； S204, 如果主动媒体网关支持冗余传输， 并且本次业务需要冗余传输， 则在承栽建立请求隧道消息中携带冗余传输参数， 并将承载建立请求隧道消 息发送给两个媒体网关中的被动媒体网关；
S206, 当接收到承载建立请求隧道消息时， 被动媒体网关解析承载建立 请求隧道消息， 并通过 IP 7 栽控制模块向 RTP/IP协议处理模块发送被动端 承载建立请求；
S208, 在接收到被动端承载建立请求之后， RTP/IP 协议控制模块建立 被动端承载连接，并且 IP承载控制模块向主动媒体网关发送携带有冗余传输 参数的承载建立应答隧道消息； 以及
S210, 在接收到承载建立应答隧道消息后， 主动媒体网关通过 IP承载 控制模块向 RTP/IP 协议处理模块发送主动端 7 载建立请求来建立主动端承 栽连接， 从而实现了在主动端媒体网关和被动端媒体网关之间的承载连接。 在 S202之前， 该方法还可以包括： 将在两个媒体网关之间的承载建立 请求隧道消息中的 SDP信息设置成符合 RFC2198参数的格式要求。 在本发明中， SDP信息至少包括： 媒体声明和媒体属性。 在 S206中还可以执行以下处理： IP承栽控制模块判断被动媒体网关是 否支持冗余传输。 当被动媒体网关支持冗余传输时， 在步骤 S206中执行以下处理： 当接 收到承栽建立请求隧道消息时， 被动媒体网关解析承载建立请求隧道消息； 以及被动媒体网关通过 IP承载控制模块向 RTP/IP协议处理模块发送被动端 承栽建立请求， 其中， 被动端承栽建立请求中至少包括： IP地址参数、 和承 载建立请求隧道消息中的冗余传输参数。 然后， 在 S208 中， IP承载控制模 块将承载建立请求隧道消息作为承载建立应答隧道消息原样返回给主动媒体 网关。 另夕卜， 当被动媒体网关不支持冗余传输时， 在步骤 S206中执行以下处 理： 当接收到承栽建立请求隧道消息时， 被动媒体网关解析承载建立请求隧 道消息； 以及被动媒体网关通过 IP承栽控制模块向 RTP/IP协议处理模块发 送被动端承载建立请求，其中，被动端承载建立请求中至少包括 IP地址参数， 而不包括承载建立请求隧道消息中的冗余传输参数。 然后， 在 S208中， IP承载控制模块对承载建立请求隧道消息进行修改 并去除冗余传输参数；以及 IP承载控制模块将修改后的承栽建立请求隧道消 息作为承载建立应答隧道消息原样返回给主动媒体网关。 图 3为根据本发明实施例的 IP承载建立过程中的 RFC2198冗余协商过 程的示意图。 如图 3所示， 包^以下步骤：
S302, ·据呼叫业务的需求， MGW1 (主动媒体网关） 上的 IPBCP开 始发起 MGW局间 RTP/IP承载的建立， 预留所需资源， 获取本 MGW1是否 支持 RFC2198冗余的能力信息； S304, 如果 IPBCP发现本 MGW1 支持 RFC2198冗余， 且本次呼叫业 务需要 4故冗余以确保传输， 则在 载建立请求的隧道消息中携带 RFC2198 信息， 其中， 一个 WCDMA CN中的隧道消息举例如下： v=0 o=- 0 1 IN IP4 1.2.3.4 s=0 c=IN IP4 1.2.3.4 t=0 0 a=ipbcp: l Request m=audio 1234 RTP/AVP 121 96 a=rtpmap:121 red/8000 a=rtpmap:96 VND.3GPP.IUFP/16000 a=fmtp:121 96/96; S306, MGW2 (被动媒体网关）上的 IPBCP收到发过来的隧道消息后， 解析消息发现对端要求此次呼叫支持 RFC2198 冗余， 这种情况下， IPBCP 首先获取本 MGW的能力信息， 看是否支持冗余功能， 其中， 根据支持情况， 有以下两种处理： 1、 MGW2支持 RFC2198冗余， IPBCP向 RTP/IP协议处 理发送请求， 携带 IP地址等参数以及 MGW1隧道消息中的 RFC2198信息， 建立 载连接； 2、 MGW2不支持 RFC2198冗余， IPBCP向 RTP/IP协议处 理发送请求， 携带 IP地址等参数， 建立承栽连接。 不传递 RFC2198信息；
S308, IPBCP成功的要求 RTP/IP协议处理建立了？ 载连接后，向 MGW1 发送应答隧道消息， 其中， 根据本 MGW是否支持 RFC2198冗余， 有以下两 种处理情况： 一、 MGW2支持 RFC2198冗余， IPBCP在应答隧道消息中将收到的隧 道消息中媒体声明和媒体属性信息原样发回到 MGW1 , 例如， 对于②中请求 消息事例， 应答隧道消息为： v=0 o=- 0 1 IN IP4 10.11.12.13 s=0 c=IN IP4 10.11.12.13 t=0 0 a=ipbcp:l Accept m=audio 5678 RTP/AVP 121 96 a=rtpmap: 121 red/8000 a=rtpmap:96 VND.3GPP.IUFP/16000 a=fmtp:121 96/96 二、 MGW2不支持 RFC2198冗余， IPBCP对 MGW1发来的隧道消息 中的媒体声明和媒体属性加以修改， 去除 RFC2198信息， 仅将其他编解码信 息随应答隧道消息传回 MGW1 , 例如， 对于②中请求消息事例， 应答隧道消 息为： v=0 o=- 0 1 IN IP4 10.11.12.13 s=0 c=IN IP4 10.11.12.13 t=0 0 a=ipbcp: l Accept m=audio 5678 RTP/AVP 96 a=rtpmap:96 VND.3GPP.IUFP/16000; 以及 S310, MGW1的 IPBCP收到 MGW2发来的应答隧道消息。 根据 S310中的应答隧道消息是否携带回了 RFC2198信息，存在以下两 种处理： 一、 隧道消息中携带回了 RFC2198信息， 说明 MGW2支持 RFC2198 冗余， IPBCP向 RTP/IP协议处理发送请求， 携带 IP地址等参数以及 MGW2 隧道消息中的 RFC2198信息， 建立承载连接； 以及 二、 隧道消息中没有携带 RFC2198信息，说明 MGW2不支持 RFC2198 冗余， IPBCP向 RTP/IP协议处理发送请求， 携带 IP地址等参数， 建立承载 连接， 不传递 RFC2198信息。 图 4 为 居本发明另一个方面的冗余传输协商方法的流程图。 如图 4 所示， 该方法包括以下步骤： S402, 根据当前业务的需要， IP 承载控制模块判断是否要修改当前业 务的冗余传输功能， 并且根据 IP承载控制模块的判断结果， 主动媒体网关向 被动媒体网关发送承载修改请求消息；
S404, 在接收到承载修改请求消息之后，被动媒体网关对承载修改请求 消息进行分析，并根据分析结果向 RTP/IP协议处理模块发送承载修改请求消 息；
S406 , 被动媒体网关通过 IP承载控制模块向主动媒体网关发送承载修 改应答消息； 以及
S408 , 根据承栽修改应答消息， 主动媒体网关执行修改处理。 其中， 承载修改请求消息和承载修改应答消息中携带有冗余传输参数。 在 S402之前， 本方法还包括： 判断主动媒体网关是否具有冗余传输功 能。 如果主动媒体网关具有冗余传输功能， 则在 S402中执行以下处理： 当 此次业务没有开启冗余传输功能并且 IP 承载控制模块判断需要开启冗余传 输功能时， IP承载控制模块向 RTP/IP协议处理模块要求开启冗余传输功能； 以及如果开启成功， 则主动媒体网关将携带有冗余传输信息的承栽修改请求 发送给被动媒体网关， 而如果开启失败， 则终止 4爹改处理。 然后， 在 S404中执行以下处理： 在接收到承载修改请求消息之后， 被 动媒体网关分析承栽修改请求消息中携带有冗余传输信息； IP承载控制模块 检查被动媒体网关是否支持冗余传输功能； 以及如果被动媒体网关支持冗余 传输功能， 则向 RTP/IP协议处理模块发送冗余传输功能开启请求， 而如果不 支持， 则不对 RTP/IP协议处理模块发送任何消息。 另夕卜， 如果主动媒体网关具有冗余传输功能， 则在 S402中执行以下处 理： 当此次业务已开启冗余传输功能并且 IP承载控制模块判断不需要开启冗 余传输功能时， 主动媒体网关将没有携带冗余传输信息的承载修改请求发送 给被动媒体网关。 然后， 在 S404中执行以下处理： 在接收到承载修改请求消息之后， 被 动媒体网关分析承栽修改请求消息中没有携带冗余传输信息； IP承载控制模 块向 RTP/IP协议处理模块发送冗余传输功能关闭请求来关闭冗余传输功能。 本发明中， 在 S406中可以具体执行以下处理： 如果在承载修改请求消 息中携带冗余传输信息， 并且被动媒体网关不支持冗余传输功能， 则被动媒 体网关通过 IP 承栽控制模块向主动媒体网关返回表示拒绝的承栽修改应答 消息； 如果在承载修改请求消息中携带冗余传输信息， 并且被动媒体网关支 持冗余传输功能，则被动媒体网关通过 IP承载控制模块向主动媒体网关返回 表示接受的承载修改应答消息； 如果在承载修改请求消息中没有携带冗余传 输信息， 并且被动媒体网关成功关闭冗余功能， 则被动媒体网关通过 IP承载 控制模块向主动媒体网关返回表示接受的承载修改应答消息； 或如果在承载 修改请求消息中没有携带冗余传输信息， 并且被动媒体网关没有成功关闭冗 余传输功能，则被动媒体网关通过 IP承载控制模块向主动媒体网关返回表示 拒绝的承栽修改应答消息。 当返回的是表示接受的承载修改应答消息时，在 S408中执行以下处理： 如果此次爹改处理为开启冗余传输功能， 则此次爹改处理结束； 或如果此次 修改处理为关闭冗余传输功能，则主动媒体网关向 RTP/IP协议处理模块发送 关闭冗余传输功能的请求来关闭冗余传输功能， 从而结束此次修改处理。 可选地， 返回的是表示拒绝的承载修改应答消息时， 在 S408中执行以 下处理： 如果此次修改处理为开启冗余传输功能， 则主动媒体网关向 RTP/IP 协议处理模块发送开启冗余传输功能的请求来开启冗余传输功能， 从而结束 此次 改处理； 或如果此次爹改处理为关闭冗余传输功能， 则此次 改处理 结束。 图 5为根据本发明实施例的 IP承载修改过程中的 RFC2198冗余协商过 程的示意图， 如图 5所示， 包括以下步骤：
S502, 根据呼叫业务的需求， MGW1上的 IPBCP判断需要改变此呼叫 RFC2198冗余功能的开关状态， 则开始发起 MGW局间 RTP/IP承载的修改， 预留所需资源， 获取本 MGW是否支持 RFC2198冗余的能力信息， 需要开关 RFC2198冗余功能的情况可能不止一种， 比较常见的可能性是， 当一个呼叫 在语音业务和数据业务之间切换的时候， 需要开关冗余功能， 另外， 因为数 据业务对数据因丢包造成的损失更加敏感， 因此需要冗余来进行保护， 语音 业务因为丢个别的包不会对呼叫造成太大影响， 一般只会导致短暂的质量下 降， 而且由于冗余功能会占用更多的带宽， 所以一般不使用冗余， 为防止两 个 MGW同时发起修改请求， 本发明由承载建立时的发起端发起此种承载修 改； S504, 根据不同的情况发送承载修改请求消息， 其中， 如果呼叫当前没 有开启 RFC2198 冗余， IPBCP根据判断需要使用冗余， 且本 MGW1 支持 RFC2198功能， 则先向 RTP/IP协议处理要求开启冗余功能， 如果开启成功， 则发送承载修改请求消息到 MGW2, 携带 RFC2198冗余信息， 如果开启失 败， 则 ' "？文流程终止， 另夕卜， 如果呼叫当前已开启 RFC2198 冗余， IPBCP 根据判断不再需要使用冗余， 则发送承载修改请求消息到 MGW2, 不携带 RFC2198冗余信息， 只携带实际媒体编解码信息；
S506, MGW2上的 IPBCP收到发过来的隧道消息后， 根据其中是否携 带了 RFC2198信息， 有以下不同处理： 如果隧道消息中没有 RFC2198信息， 则 IPBCP向 RTP/IP协议处理发送请求， 关闭 RFC2198冗余功能； 如果隧道 消息中携带有 RFC2198信息， 则 IPBCP检查本 MGW能力信息， 并且如果 本 MGW支持 RFC2198冗余，则向 RTP/IP协议处理发送请求，开启 RFC2198 冗余功能， 而如果不支持， 则不对 RTP/IP协议处理做任何动作；
S508, MGW2上的 IPBCP向 MGW1发送应答隧道消息， 有以下几种 情况： MGW1在隧道消息中携带了 RFC2198冗余信息，但是 MGW2不支持， 或者支持但是没有修改成功， 则 MGW2的 IPBCP向 MGW1应答一个拒绝 ( Reject )隧道消息； MGW1在隧道消息中携带了 RFC2198冗余信息， MGW2 支持冗余且修改成功，则 MGW2的 IPBCP向 MGW1应答一个接受（ Accept ) 隧道消息； MGW1在隧道消息中没有携带 RFC2198冗余信息， 且 MGW2关 闭冗余功能成功， 贝1 J MGW2的 IPBCP向 MGW1应答一个接受 ( Accept )隧 道消息； 以及 MGW 1在隧道消息中没有携带 RFC2198冗余信息， 但 MGW2 关闭冗余功能失败， 则 MGW2的 IPBCP向 MGW1应答一个拒绝 （ Reject ) 隧道消息； 以及
S510, MGW1 的 IPBCP收到 MGW2发来的应答隧道消息， 据此消 息是接受还是拒绝做如下不同的处理： 隧道消息为 "接受"， 如果本次修改为 开启 RFC2198冗余功能，则^"改流程结束， 而如果本次 ί爹改为关闭 RFC2198 冗余功能，则向 RTP/IP协议处理发送关闭此功能的请求，从而修改流程结束； 以及隧道消息为 "拒绝"， 如果本次爹改为开启 RFC2198 冗余功能， 则向 RTP/IP协议处理发送关闭此功能的请求， 从而修改流程结束， 而如果本次修 改为关闭 RFC2198冗余功能， 则爹改流程结束。 应了解， 由于开启冗余功能需要消耗更多的资源， 而关闭冗余功能只会 导致资源消耗的下降。因此一般认为开启冗余功能相比较而言更加容易失败， 而关闭此功能一般不会失败。 因此在开启和关闭冗余功能这两种情况中， 发 隧道消息前是否就进行开关操作是有区别的。 原则是， 如果是开启， 则尽早 操作， 如果是关闭， 则尽可能晚的操作。 综上所述， 本发明使得局间两个 MGW之间可以相互发送 SDP信息以 达到传递 载相关信息的目的，为 RFC2198相关参数在 MGW之间传递提供 了可能。解决了基于 RFC2198的电路域媒体网关之间的数据冗余机制在媒体 网关之间无法协商的问题。 以上仅为本发明的优选实施例而已， 并不用于限制本发明， 对于本领域 的技术人员来说， 本发明可以有各种更改和变化。 凡在本发明的精神和原则 之内， 所作的任何修改、 等同替换、 改进等， 均应包含在本发明的保护范围 之内。

Claims

权 利 要 求 书 一种冗余传输协商方法，用于在基于 RFC2198标准的电路域的两个媒体 网关的 IP承栽建立过程中， 实现冗余传输的协商， 其特征在于， 包括以 下步骤：
步骤一， 当所述两个媒体网关中的主动媒体网关根据业务需要发起 在媒体网关局间的承载连接建立流程时， IP承栽控制模块判断所述主动 媒体网关是否支持冗余传输；
步骤二， 如果所述主动媒体网关支持所述冗余传输， 并且本次业务 需要所述冗余传输， 则在承载建立请求隧道消息中携带冗余传输参数， 并将所述承栽建立请求隧道消息发送给所述两个媒体网关中的被动媒体 网关；
步骤三， 当接收到所述 栽建立请求隧道消息时， 所述被动媒体网 关解析所述承载建立请求隧道消息， 并通过所述 IP 承载控制模块向 RTP/IP协议处理模块发送被动端 栽建立请求；
步骤四， 在接收到所述被动端承载建立请求之后， 所述 RTP/IP协 议控制模块建立被动端承载连接，并且所述 IP承载控制模块向所述主动 媒体网关发送携带有所述冗余传输参数的承载建立应答隧道消息； 以及 步骤五， 在接收到所述承栽建立应答隧道消息后， 所述主动媒体网 关通过所述 IP承栽控制模块向所述 RTP/IP协议处理模块发送主动端承 栽建立请求来建立主动端承载连接， 从而实现了在所述主动端媒体网关 和所述被动端媒体网关之间的承载连接。 根据权利要求 1所述的方法， 其特征在于， 在所述步骤一之前， 还包括： 将在所述两个媒体网关之间的承栽建立请求隧道消息中的 SDP信 息设置成符合所述 RFC2198参数的格式要求。 根据权利要求 1所述的方法， 其特征在于， 所述 SDP信息至少包括： 媒 体声明和媒体属性。
4. 根据权利要求 3所述的方法， 其特征在于， 在所述步骤三中还执行以下 处理：
所述 IP承载控制模块判断所述被动媒体网关是否支持所述冗余传 输。
5. 根据权利要求 4所述的方法， 其特征在于， 当所述被动媒体网关支持所 述冗余传输时， 在所述步骤三中执行以下处理：
当接收到所述承载建立请求隧道消息时，所述被动媒体网关解析所 述承栽建立请求隧道消息； 以及
所述被动媒体网关通过所述 IP 载控制模块向 RTP/IP协议处理模 块发送被动端承载建立请求，
其中， 所述被动端承载建立请求中至少包括： IP地址参数、 和所述 承栽建立请求隧道消息中的所述冗余传输参数。
6. 根据权利要求 5所述的方法， 其特征在于， 在所述步骤四中，
所述 IP承栽控制模块将所述承载建立请求隧道消息作为所述承栽 建立应答隧道消息原样返回给所述主动媒体网关。
7. 根据权利要求 4所述的方法， 其特征在于， 当所述被动媒体网关不支持 所述冗余传输时， 在所述步骤三中执行以下处理：
当接收到所述承栽建立请求隧道消息时，所述被动媒体网关解析所 述承栽建立请求隧道消息； 以及
所述被动媒体网关通过所述 IP 7?c载控制模块向 RTP/IP协议处理模 块发送被动端承载建立请求，
其中， 所述被动端 7 栽建立请求中至少包括 IP地址参数， 而不包 括所述承载建立请求隧道消息中的所述冗余传输参数。
8. 根据权利要求 7所述的方法， 其特征在于， 在所述步骤四中，
所述 IP承载控制模块对所述承栽建立请求隧道消息进行修改并去 除所述冗余传输参数； 以及
所述 IP承栽控制模块将修改后的所述承载建立请求隧道消息作为 所述承载建立应答隧道消息原样返回给所述主动媒体网关。
9. 一种冗余传输协商方法，用于在基于 RFC2198标准的电路域的两个媒体 网关的 IP承载修改过程中， 实现冗余传输的协商， 其特征在于， 包括以 下步骤：
步骤一，根据当前业务的需要， IP承载控制模块判断是否要修改当 前业务的冗余传输功能， 并且根据所述 IP承栽控制模块的判断结果， 所 述主动媒体网关向被动媒体网关发送承载修改请求消息；
步骤二， 在接收到所述承栽修改请求消息之后， 所述被动媒体网关 对所述承栽修改请求消息进行分析，并根据分析结果向 RTP/IP协议处理 模块发送所述承载修改请求消息；
步骤三， 所述被动媒体网关通过所述 IP承载控制模块向所述主动 媒体网关发送承载修改应答消息； 以及
步骤四， 根据所述承载修改应答消息， 所述主动媒体网关执行修改 处理，
其中，所述承载修改请求消息和所述承载修改应答消息中携带有冗 余传输参数。
10. 根据权利要求 9所述的方法， 其特征在于， 在所述步骤一之前还包括： 判断所述主动媒体网关是否具有所述冗余传输功能。
11. 根据权利要求 10所述的方法， 其特征在于， 如果所述主动媒体网关具有 所述冗余传输功能， 则在所述步骤一中执行以下处理：
当此次业务没有开启所述冗余传输功能并且所述 IP承载控制模块 判断需要开启所述冗余传输功能时，所述 IP承栽控制模块向所述 RTP/IP 协议处理模块要求开启所述冗余传输功能； 以及
如果开启成功，则所述主动媒体网关将携带有冗余传输信息的所述 7?栽修改请求发送给所述被动媒体网关， 而如果开启失败， 则终止 改 处理。
12. 根据权利要求 11所述的方法， 其特征在于， 在所述步骤二中执行以下处 理：
在接收到所述承载修改请求消息之后，所述被动媒体网关分析所述 承载修改请求消息中携带有所述冗余传输信息； 所述 IP承载控制模块检查所述被动媒体网关是否支持所述冗余传 输功能； 以及
如果所述被动媒体网关支持所述冗余传输功能， 则向所述 RTP/IP 协议处理模块发送冗余传输功能开启请求， 而如果不支持， 则不对所述 RTP/IP协议处理模块发送任何消息。
13. 根据权利要求 10所述的方法， 其特征在于， 如果所述主动媒体网关具有 所述冗余传输功能， 则在所述步骤一中执行以下处理：
当此次业务已开启所述冗余传输功能并且所述 IP承载控制模块判 断不需要开启所述冗余传输功能时 , 所述主动媒体网关将没有携带冗余 传输信息的所述承载修改请求发送给所述被动媒体网关。
14. 根据权利要求 13所述的方法， 其特征在于， 在所述步骤二中执行以下处 理： 在接收到所述承载修改请求消息之后，所述被动媒体网关分析所述 承载修改请求消息中没有携带所述冗余传输信息； 以及
所述 IP承载控制模块向所述 RTP/IP协议处理模块发送冗余传输功 能关闭请求来关闭所述冗余传输功能。
15. 根据权利要求 11至 14中任一项所述的方法， 其特征在于， 在所述步骤 三中执 4亍以下处理：
如果在所述承栽修改请求消息中携带所述冗余传输信息， 并且所述 被动媒体网关不支持所述冗余传输功能， 则所述被动媒体网关通过所述 IP 承载控制模块向所述主动媒体网关返回表示拒绝的承载修改应答消 息；
如果在所述承载修改请求消息中携带所述冗余传输信息，并且所述 被动媒体网关支持所述冗余传输功能， 则所述被动媒体网关通过所述 IP 承载控制模块向所述主动媒体网关返回表示接受的承载修改应答消息； 如果在所述承载修改请求消息中没有携带所述冗余传输信息，并且 所述被动媒体网关成功关闭所述冗余功能， 则所述被动媒体网关通过所 述 IP 承栽控制模块向所述主动媒体网关返回表示接受的承载修改应答 消息； 或 如果在所述承载修改请求消息中没有携带所述冗余传输信息，并且 所述被动媒体网关没有成功关闭所述冗余传输功能， 则所述被动媒体网 关通过所述 IP 承栽控制模块向所述主动媒体网关返回表示拒绝的承载 修改应答消息。
16. 根据权利要求 15所述的方法， 其特征在于， 当返回的是表示接受的承栽 爹丈应答消息时， 在所述步骤四中执行以下处理：
如果此次爹改处理为开启所述冗余传输功能， 则此次 <爹改处理结 束 或
如果此次修改处理为关闭所述冗余传输功能，则所述主动媒体网关 向所述 RTP/IP 协议处理模块发送关闭所述冗余传输功能的请求来关闭 所述冗余传输功能， 从而结束此次 改处理。
17. 根据权利要求 15所述的方法， 其特征在于， 当返回的是表示拒绝的承载
？丈应答消息时， 在所述步骤四中执行以下处理：
如果此次 改处理为开启所述冗余传输功能， 则所述主动媒体网关 向所述 RTP/IP 协议处理模块发送开启所述冗余传输功能的请求来开启 所述冗余传输功能， 从而结束此次 ~改处理； 或
如果此次 f爹改处理为关闭所述冗余传输功能， 则此次 ~改处理结 束。
PCT/CN2007/003495 2007-12-07 2007-12-07 Procédé de négociation de transmission redondante WO2009079810A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US12/746,733 US20100262698A1 (en) 2007-12-07 2007-12-07 Method for negotiating redundant transmission
CN2007801017474A CN101878628B (zh) 2007-12-07 2007-12-07 冗余传输协商方法
PCT/CN2007/003495 WO2009079810A1 (fr) 2007-12-07 2007-12-07 Procédé de négociation de transmission redondante
EP07845853A EP2226985A4 (en) 2007-12-07 2007-12-07 METHOD FOR NEGOTIATING REDUNDANT TRANSMISSION

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2007/003495 WO2009079810A1 (fr) 2007-12-07 2007-12-07 Procédé de négociation de transmission redondante

Publications (1)

Publication Number Publication Date
WO2009079810A1 true WO2009079810A1 (fr) 2009-07-02

Family

ID=40800635

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2007/003495 WO2009079810A1 (fr) 2007-12-07 2007-12-07 Procédé de négociation de transmission redondante

Country Status (4)

Country Link
US (1) US20100262698A1 (zh)
EP (1) EP2226985A4 (zh)
CN (1) CN101878628B (zh)
WO (1) WO2009079810A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101577864B (zh) * 2008-05-08 2013-04-17 华为技术有限公司 数据传输的方法、系统及基站子系统和移动交换中心
CN104283863B (zh) * 2013-07-12 2018-08-14 华为技术有限公司 一种实现数据包重组的方法和装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1917509A (zh) * 2005-08-19 2007-02-21 中兴通讯股份有限公司 一种基于ipbcp协议的ip承载建立方法
CN1972305A (zh) * 2006-11-06 2007-05-30 华为技术有限公司 一种协商方法及系统

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2408119A1 (en) * 2000-05-04 2001-11-08 Shwu-Yan Chang Scoggins Method and apparatus for negotiating bearer control parameters using property sets
WO2006071092A1 (en) * 2004-12-31 2006-07-06 Samsung Electronics Co., Ltd. A method for bearer independent call control (bicc) optimization for ip bearer support
CN1921478B (zh) * 2005-08-26 2011-09-14 华为技术有限公司 基于网际协议的业务信号传输方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1917509A (zh) * 2005-08-19 2007-02-21 中兴通讯股份有限公司 一种基于ipbcp协议的ip承载建立方法
CN1972305A (zh) * 2006-11-06 2007-05-30 华为技术有限公司 一种协商方法及系统

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"BICC IP Bearer Control Protocol (IPBCP)", ATIS T1.676, 1 August 2001 (2001-08-01) *
"Gateway Control Protocol: H.248 SDP parameter identification and wildcarding", ITU-T H.248.39, 1 May 2006 (2006-05-01) *
See also references of EP2226985A4 *

Also Published As

Publication number Publication date
US20100262698A1 (en) 2010-10-14
EP2226985A1 (en) 2010-09-08
CN101878628B (zh) 2013-03-06
CN101878628A (zh) 2010-11-03
EP2226985A4 (en) 2011-02-02

Similar Documents

Publication Publication Date Title
US7609673B2 (en) Packet-based conversational service for a multimedia session in a mobile communications system
JP4763800B2 (ja) マルチメディア通信セッションを確立するための方法および装置
US8982713B2 (en) Quality of service configuration for wireless communication
US7058042B2 (en) One-to-one communication
EP2458816B1 (en) Method and apparatuses for changing status of packet switched domain
JP2008541532A (ja) マルチメディアセッションのためのサービスの質（ＱｏＳ）パラメータのシグナリング
JP2012523199A (ja) セッションネゴシエーションのための方法及び装置
TW200421891A (en) Utilizing session initiation protocol for identifying user equipment resource reservation setup protocol capabilities
US20080114850A1 (en) Method and Arrangement for Communicating Multimedia Content
WO2005027417A1 (fr) Procede de soutien d&#39;acces radio a une session multimedia ip dans un reseau umts
WO2007128217A1 (en) Method of internet protocol(ip) message transmission, negotiated bandwidth saving capability and saving network bandwidth
WO2008022596A1 (fr) Procédé, système et appareil pour la remise de sms en mode de partage dynamique
WO2009012665A1 (fr) Procédé pour assurer une continuité d&#39;appel multimédia, équipement et système associés
WO2006097045A1 (fr) Procede et systeme de traitement d’appel multimedia
JP2005530428A (ja) 無線ネットワークへの配送を最適化するための、アプリケーションからの特定指令によるシグナリング・パケットの配送制御
WO2010133148A1 (zh) 软交换架构下的编解码转换控制方法、媒体网关及系统
EP1380182B1 (en) One-to-one communication in a system having different control plane and user plane logical entities
WO2007131397A1 (fr) Procédé et système de transmission avec redondance des données
WO2007098657A1 (fr) Procédé et réseau destinés à la transmission de services multiples du centre de jonction basé sur ip
WO2007143920A1 (fr) Procédé et dispositif de commande de ressources de supports, procédé et système d&#39;établissement d&#39;appel
WO2009079810A1 (fr) Procédé de négociation de transmission redondante
WO2009121310A1 (zh) 一种网关选择的方法、系统及设备
WO2010012141A1 (zh) 一种媒体网关间的双音多频信号的参数协商方法及系统
RU2446605C2 (ru) Способ, система и устройство для согласования службы данных сигнализации протокола инициации сеанса
EP1998517B1 (en) METHOD AND aPPARATUS FOR CHANGING STATUS OF PACKET SWITCHED DOMAIN

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200780101747.4

Country of ref document: CN

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

Ref document number: 07845853

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 12746733

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2007845853

Country of ref document: EP