WO2008000188A1 - Procédé et système pour réaliser une interaction de flux multimédia, contrôleur de passerelle multimédia, et passerelle multimédia - Google Patents

Procédé et système pour réaliser une interaction de flux multimédia, contrôleur de passerelle multimédia, et passerelle multimédia Download PDF

Info

Publication number
WO2008000188A1
WO2008000188A1 PCT/CN2007/070157 CN2007070157W WO2008000188A1 WO 2008000188 A1 WO2008000188 A1 WO 2008000188A1 CN 2007070157 W CN2007070157 W CN 2007070157W WO 2008000188 A1 WO2008000188 A1 WO 2008000188A1
Authority
WO
WIPO (PCT)
Prior art keywords
address
public network
network address
mgc
media
Prior art date
Application number
PCT/CN2007/070157
Other languages
English (en)
French (fr)
Inventor
Ning Zhu
Original Assignee
Huawei Technologies Co., Ltd.
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 Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to EP07721775A priority Critical patent/EP2034666B1/en
Publication of WO2008000188A1 publication Critical patent/WO2008000188A1/zh
Priority to US12/338,223 priority patent/US20090097477A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1043—Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854—Wide area networks, e.g. public data networks
    • H04L12/2856—Access arrangements, e.g. Internet access
    • H04L12/2858—Access network architectures
    • H04L12/2861—Point-to-multipoint connection from the data network to the subscribers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854—Wide area networks, e.g. public data networks
    • H04L12/2856—Access arrangements, e.g. Internet access
    • H04L12/2869—Operational details of access network equipments
    • H04L12/2898—Subscriber equipments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2575—NAT traversal using address mapping retrieval, e.g. simple traversal of user datagram protocol through session traversal utilities for NAT [STUN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42017—Customized ring-back tones

Landscapes

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

Description

实现媒体流交互方法和系统及媒体网关控制器和媒体网关 本申请要求于 2006 年 6 月 22 日提交中国专利局、 申请号为 200610090061.7、 发明名称为"一种实现媒体流交互的方法 "的中国专利申请的 优先权， 以及要求于 2006 年 7 月 21 日提交中国专利局、 申请号为 200610099246.4、 发明名称为 "实现媒体流交互方法和系统及媒体网关控制器 和媒体网关"的中国专利申请的优先权，其全部内容通过引用结合在本申请中。 技术领域
本发明涉及通信技术领域，特别是指实现媒体流交互方法和系统及媒体网 关控制器（ MGC )和媒体网关 （ MG )。
背景技术
下一代网络（NGN, Next Generation Network )是电信史一块里程碑， 标 志着新一代电信网络时代的到来。 NGN是基于时分复用 （TDM ) 的 PSTN语 音网络和基于因特网协议 /异步传输模式（IP/ATM ) 的分组网络融合的产物， 其使得在新一代网络上语音、 视频、 数据等综合业务成为了可能。
参见图 1 , 其是现有网络结构示意图。媒体网关（MGW, Media Gateway, 也简写为 MG )用于将一种网络类型中的媒体流转换为另一种网络所要求的格 式， 例如将电路交换网中的 E1时隙转换为 IP网络中的实时传输协议 ( RTP ) 媒体流。 媒体网关控制器（MGC, Media Gateway Controller )用于实现呼叫状 态的管理，以及对媒体网关承载资源的控制。 MGC和 MG之间传送控制信令， 以使 MG完成具体媒体流的建立、 修改、 释放和资源管理。
图 1中， 如果 MG1和 MG2所处的承载网是同一个私有网络或者同一个 公有网络， 则 MG1和 MG2的 IP 文都可以直达对方。 如果 MG1和 MG2中 的一个处于公有网络而另一个处于私有网络， 或者这两个网关处于 IP报文不 能直达的两个不同的私有网络，则可能会出现媒体流单向导通或者彼此不同的 情况。 同样的问题也存在于媒体流两端中的一端是媒体网关， 而另外一端是 SIP终端、 H323终端、 其它电路域（CS )域或者分组网络等的情况下。 转换 ( NA(P)T, Network Address and optional Port Translation )是一种比较基 本的技术。 网络地址转换（NAT )是用于将一个地址域（如： 专用 Intranet ) 映射到另一个地址域（如： Internet )的标准方法。 NAT允许一个机构专用 Intranet 中（即私有网络中）的终端透明地连接到公共域 (即公有网络)中的终端， 无需私 网内部终端拥有注册的 （以及越来越缺乏的） Internet地址。 网络地址端口转 换是在 NAT的基础上将地址和端口号一起作为需要转换项， 那么就可以允许 多台私有网络的终端同时共享一个单独的公有网络的网 IP地址了。
NAT分为 4种类型 ,即 Full Cone, Restricted Cone, Port Restricted Cone和 Symmetric 前面 3种类型， 统称为 Cone NAT, 有一个共同点： 只要是从同一 个内部地址和端口出来的包， NAT都将它转换成同一个外部地址和端口。 但 是 Symmetric有点不同， 具体表现在： 只要是从同一个内部地址和端口出来， 且到同一个外部目标地址和端口 , 则 NAT也都将它转换成同一个外部地址和 端口。但如果从同一个内部地址和端口出来，是到另一个外部目标地址和端口， 则 NAT将使用不同的映射 , 转换成不同的地址和端口。 而且和 Port Restricted Cone—样， 只有曾经收到过内部地址发来包的外部地址， 才能通过 NAT映射 后的地址向该内部地址发包。
NAT穿越技术是指私有网络上的终端采用私有 IP地址通过出口的 NAT或 者 NAPT接入公网。 这里要特别指出的是， NAT穿越并不仅仅适用于 NAT设 备， 同样也适用于 NAPT设备。 基于 H323、 会话初始协议 (SIP)、 媒体网关控 制协议 ( MGCP )和 H248等协议的语音和视频应用需通过信令消息中的 IP地 址和端口参数来实现目的地寻址，因此 NAT穿越时不仅需要对 TCP/UCP层的 端口信息以及 IP层的源地址和目的地址进行变换， 还需对 IP包载荷 (即信令) 中的相关地址信息进行变换。
STUN和 TURN是两种常用的 NAT穿越方式。
STUN方式
私网中的终端通过某种机制预先得到出口 NAT上的对外地址， 然后在 IP 包载荷 (即信令)中所填写的地址信息直接填写出口 NAT上的对外地址，而不是 私网内终端的私有 IP地址，这样 IP包载荷 (即信令)中的内容在经过 NAT时就 无需被修改了 ,只需按普通 NAT流程转换报文头的 IP地址即可， IP包载荷 (即 信令)中的 IP地址信息和报文头地址信息是一致的。 STUN协议就是基于此思 路来解决应用层地址的转换问题。
STUN 的全称是 Simple Traversal of UDP Through Network Address Translators, 即用户数据报协议 ( UDP )对 NAT的简单穿越方式。 应用程序即 STUN客户端（ STUN CLIENT )向 NAT外的 STUN服务器（ STUN SERVER ) 通过 UDP发送请求 STUN 消息， STUN SERVER收到请求消息， 产生响应消 息， 响应消息中携带请求消息的源端口， 即 STUN CLIENT在 NAT上对应的 外部端口。 然后响应消息通过 NAT发送给 STUN CLIENT, STUN CLIENT通 过响应消息体中的内容得知其 NAT上的外部地址， 并将其填入以后呼叫协议 的 UDP负载中， 告知对端 , 本端的 RTP接收地址和端口号为 NAT外部的地 址和端口号。由于通过 STUN协议已在 NAT上预先建立媒体流的 NAT映射表 项， 故媒体流可顺利穿越 NAT。
STUN协议最大的优点是无需现有 NAT/FW设备做任何改动。采用 STUN 方式无需改动 NAT/FW, 这是其最大优势， 同时 STUN方式可在多个 NAT串 联的网络环境中使用。
STUN的局限性在于需要私网中的终端支持 STUN CLIENT的功能， 不支 持对称 NAT ( Symmetric NAT )类型穿越， 而在安全性要求较高的企业网中， 出口 NAT通常是这种类型。
TURN方式
TURN方式解决 NAT问题的思路与 STUN相似，也是私网中的 VOIP(Voice over IP)终端通过某种机制预先得公网上的服务地址（注意： STUN方式得到的 地址为出口 NAT上外部地址， TURN方式得到地址为 TURN Server上的公网 地址 )，然后在 IP包载荷 (即信令)中所要求的地址信息就直接填写该公网地址。
TURN的全称为 Traversal Using Relay NAT , 即通过中继 （ Relay )方式穿 越 NAT。 TURN应用模型通过分配 TURN Server 的地址和端口作为私网中 VOIP 终端对外的接受地址和端口， 即私网终端发出的报文都要经过 TURN Server进行 Relay转发， 这种方式除了具有 STUN方式的优点外， 还解决了 STUN应用无法穿透对称 NAT ( Symmetric NAT ) 以及类似的 Firewall设备的 缺陷， 同时 TURN支持基于 TCP的应用。 此外 TURN Server控制分配地址和 端口 , 能分配 RTP/RTCP地址对（ RTCP端口号为 RTP端口号加 1 )作为私网 终端用户的接收地址， 避免了 STUN方式中出口 NAT对 RTP/RTCP地址端口 号的任意分配， 使得客户端无法收到对端发来的 RTCP报文（对端发 RTCP报 文时， 目的端口号缺省按 RTP端口号加 1发送）。
TURN的局限性在于需要 VOIP终端支持 TURN Client, 这一点同 STUN 一样对网络终端有要求。 此外，媒体流经过 TURN Server转发， 增大了包的延 迟和丢包的可能性。
RSIP的全称为 Realm Specific IP, 即特定域 IP, 其也是一种穿越方式。 其原理和 NAT类似。 RSIP网关包含两个或多个地址域， 类似于 NAT设备。 当一个私网内的终端想要与自己所在的私用网络空间以外的节点通信时，它首 先要登记到 RSIP服务器（网关）， 由 RSIP网关分配一个公用的地址或者一个与 别人共享的公用 IP地址及端口集， 并把私有地址与之绑定。 该终端使用这个 地址发送数据包， 直到租用到期或被释放为止。 该终端在 IP载荷中直接使用 被分配的共用地址和端口 ,但是必须先把要发送的使用公用地址的数据包封装 在一个使用私用地址的数据包里， 并把这个数据包发送到 RSIP服务器。 这个 过程可以使用任何标准的通道协议： ip-in-ip, gre, 12tp等。 然后， RSIP服务 器去掉数据包的封装， 把使用公用地址的数据包装发到 internet上。 RSIP的优 势在于不需要 RSIP对 IP载荷作修改， 比如修改端口号， 这样比较容易支持 IPSEC。 对于 RSIP协议作一些扩展， 把 IPSEC的 SPI等参数加入和 IP头中携 带的 IP地址信息组合， 用于对于 RSIP隧道的标识和查找。这样能够实现端对 端的 IPSEC。
现有的基于 H.248协议的实现 NAT穿越的方法如下：
媒体网关控制器在发给公网内的网关 2 的 H.248 消息中指定 RTP端点 RTP/2的远端 (remote)SDP中携带的 CPE2是处在 NAT设备后的私网中的媒体 流对端的私网地址。
处于私网中的对端 (地址为 CPE2)发出的媒体流在通过 NAT时， NAT将其 地址转换成公网地址 CPE1 , 但是按照 H.248协议（即前面提到的 RTP/2的远 端 (remote)SDP中携带的 CPE2 ), 端点 RTP/2会将媒体流发送到 CPE2, 而该 CPE2是一个私网地址， 对于端点 RTP/2实际是不可到达的。 所以 H.248.37新 增了一个 H.248信号下发给端点 RTP/2指示作 NAT穿越。 端点 RTP/2会用实 际收到的媒体流的公网地址 CPE1替代远端 SDP 中的私网地址 CPE2。 端点 RTP/2发出的媒体会发送到 CPE1， NAT根据之前已建立的地址映射关系， 将 CPE1收到的媒体流发送到私网的 CPE2地址。
由于 H.248.37定义的 NAT穿越包要求私网中的端点先往公网上的 IP端点 上发送媒体流， 激发 NAT设备产生地址映射， 而公网上的端点根据收到的媒 体流的源地址作为发送媒体的目的地址。发明人在实现过程中发现：很多情况 下会有单向媒体的需求， 比如需要对端播放的回铃音或者彩铃等，此时因为被 叫还没有摘机， 因而私网中的主叫不会有媒体流发出，从而导致该私网中的主 叫无法接收媒体流。 另外:当静音检测被激活时， 如果私网中的用户静音， 则 也没有从私网发往公网的媒体流， 公网也无法把媒体发送到私网。 也就是说， 在 H.248.37定义的规范下， 私网中的端点必须先往公网媒体网关上的 IP端点 上发送媒体流， 否则就无法实现媒体流的互通。
H.248.37的 NAT穿越还有一个缺陷就是必须首先保证单向可通。 如果呼 叫两端处在两个不同的私网中， 双向地址都不可达， H.248.37的机制就无法产 生效果。
H.248.37的机制无法适用于公网内的设备不是媒体网关，而对端在私网中 的情况， 比如公网内的设备是 SIP终端或者 H.323终端， SIP协议和 H.323协 议还不支持类似 H.248.37的功能。
以上是以 H.248.37为例进行说明， 对于 MGCP等协议， 同样存在类似问 题。
发明内容
本发明实施例在于提供一种实现媒体流交互的方法和系统及一种媒体网 关控制器和媒体网关 ,以解决私网中的媒体网关与对端的公网或者不同域的私 网中的设备进行媒体流交互时媒体流单通或者不通的问题。
本发明实施例的技术方案包括： 一种实现媒体流交互的方法， 欲交互媒体流的两端所在媒体承载网为 IP 网域， 其中至少一个 IP网域为需要通过网络转换设备映射地址的私网， 该方 法包括：
媒体网关控制器 MGC获取私网中的媒体网关 MG本地媒体地址所对应的
MGC将所述公网地址发送给所 亍端； 所 亍端根据所述公网地址实现与 私网中的 MG的媒体流交互。
一种实现媒体流交互的系统， 欲交互媒体流的两端所在媒体承载网为 IP 网域， 其中至少一个 IP网域为需要通过网络转换设备映射地址的私网域， 该 系统包括： 媒体网关控制器 MGC, 私网中的媒体网关 MG以及需要与所述私 网中的 MG进行媒体流交互的对端；
所述 MGC内还包括：
公网地址获取单元 ,用于获取私网中的媒体网关 MG本地媒体地址所对应 的公网地址， 将所述公网地址发送给所述公网地址传送单元； 所述公网地址是 用于作为所述 MG对端的远端地址的公网地址；
公网地址传送单元， 用于将接收到的所述公网地址发送给所 亍端； 所述私网 MG中还包括：
公网地址上报单元， 用于根据接收到来自 MGC的上报公网地址的指示， 发起穿越协议消息，获取用于作为对端的远端地址的公网地址，将包含所述公 网地址的列表上报给 MGC; 或者， 从自身已保存的信息中直接获取所述公网 地址， 上报给所述 MGC。
一种媒体网关控制器， 包括： 公网地址获取单元和公网地址传送单元； 所述公网地址获取单元，用于获取私网中的媒体网关 MG本地媒体地址所 对应的公网地址， 将所述公网地址发送给所述公网地址传送单元； 所述公网地 址是用于作为所述 MG对端的远端地址的公网地址；
所述公网地址传送单元， 用于将接收到的所述公网地址发送给所 亍端。 一种私网内的媒体网关， 包括：
公网地址上报单元， 用于根据接收到来自 MGC的上报公网地址的指示， 发起穿越协议消息，获取用于作为对端的远端地址的公网地址，将包含所述公 网地址的列表上报给 MGC; 或者， 从自身已保存的信息中直接获取所述公网 地址， 上报给所述 MGC。
本发明实施例与现有技术相比， MGC 获取私网中的媒体网关 MG通过 NA(P)T, RSIP以及 TURN等所对应的公网地址， 该公网地址是用于作为所述 MG对端的远端地址的公网地址；之后， MGC将所述公网地址发送给所述对端； 所述对端通过所述公网地址实现与私网中的 MG的媒体流交互。 这样， 解决了 私网中的端点必须先往公网上的支持 H.248.37的媒体网关端点上发送媒体流， 否则就无法实现媒体流的互通的问题，即避免了媒体流的互通必须由私网内的 端点先发起这个限制， 从而在媒体网关上实现了不同 IP域的媒体流穿越， 使 得媒体流可以在任何方向先发起。 而且， 即使两端在不同私网中， 也能实现穿 越。
再有， 由于本发明实施例不需要对网络转换设备设备进行更新， 并避免了 5 )入边界网关造成的系统开销 ,而所使用的方式对现有系统所占用的开销又很 小， 因而不但与现有系统有很好地兼容性， 而且最大可能地节约了系统资源。 附图说明
图 1是现有网络结构示意图；
图 2是根据本发明一实施例的主叫侧 MG在私网采用 STUN方式进行地 址协商的实现流程图；
图 3是根据本发明一实施例的被叫侧 MG在私网采用 STUN方式进行地 址协商的实现流程图；
图 4是根据本发明一实施例的主叫侧 MG在私网采用 TURN方式进行地 址协商的实现流程图；
图 5是根据本发明一实施例的被叫侧 MG在私网采用 TURN方式进行地 址协商的实现流程图；
图 6是根据本发明一实施例的主被叫侧 MG均在私网采用 STUN方式进 行地址协商的实现流程图；
图 7是根据本发明一实施例的 STUN服务器应答 STUN binding request 消 息到 MGC的实现流程图。
具体实施方式
本发明实施例中由 MGC控制媒体网关的媒体流进行 NAT穿越。
本发明实施例中所涉及的欲交互媒体流的两终端所在媒体承载网处于不 同的 IP域， 且需要传递的 IP报文即媒体流需要通过一级或多级 NAT设备的 中转。
本文中，定义处在 NA(P)T设备后需要 NA(P)T设备映射地址的 IP域称为 私网域 (也可以称为私有域或私域）， 私网域的地址被一级或者多级 NAT映射 到的对端的 IP域称为公网域（也可称为公有域或公域）。 也就是说， 本发明实 内外而言的。
被控制的处于私网的 MG要进行 NA(P)T转换或者 RSIP转换后才能和公 网地址进行媒体流交互。 而媒体流对端的设备包括但不限于 SIP终端、 H323 终端、 MG或者其他电路域（CS )域或者分组网络。 后面实施例中的对端都是 网关， 其是为了便于说明， 实际应用中并不限定， 对端可以是 SIP终端、 H323 终端、 其它 CS域或者分组网络等。 网关控制协议可以采用 H.248协议或者 MGCP协议， 其机制相同。 流程图中采用 H.248协议， 使用 MGCP协议的流 程类似， 而且机制相同。
本发明实施例的实现过程包括：当欲交互媒体流的两端所在媒体承载网处 于不同的 IP域， 且其中的第一 IP域为需要通过网络转换设备映射地址的私网 域时， MGC获取私网中的 MG本地媒体地址所对应的公网地址， 该公网地址 是用于作为所述 MG对端的远端地址的公网地址； MGC将所述公网地址发送 给所述对端； 所述对端通过所述公网地址实现与私网中的 MG的媒体流交互。 这样，在私网端点向公网发送媒体流前，对端就可以知道待发送媒体流的目的 地址和端口即前面通过 MGC传递的公网地址。 可以有以下几种方式：
方式一： MGC给私网内的 MG发送上报公网地址的指示； 该 MG根据接 收到的指示.
公网地址， MGC从接收到的上报信息中获取所述公网地址。 再有， 私网中的 MG接收到来自 MGC的上报地址的指示后， 还可以上报自身的私网地址， 此 时 MGC可以从接收到的上报信息中获取 MG的私网地址 , 以备以后应用。
方式二： MG接收到来自 MGC的进行穿越并且应答目的地址为 MGC的 指示后，发起穿越协议消息，该消息中包含指定应答消息发送到 MGC的信息； MGC根据接收到的穿越协议消息应答获取所述公网地址。
方式三： MG主动发起穿越协议消息， 该消息中包含指定应答消息发送到 MGC的信息； MGC根据接收到的穿越协议消息应答获取所述公网地址。
方式四： MG主动发起穿越协议消息， 上报从应答中获得的用于作为对端 的远端地址的公网地址， MGC从接收到的上报信息中获取所述公网地址。
针对上述四种实现方式，后面会通过具体的 H.248/MGCP包扩展以及 SDP 扩展中再详细说明。
另外， 如果两端之间的媒体流有多个， 涉及到私网内网关上的多个地址 + 端口， 以及 /或者私网内相同的地址 +端口的媒体发送的目的地址不同， 则要多 次使用前述机制获得公网地址， 使每个媒体流都能够实现 NAT穿越。
上述穿越方式包括但不限于 STUN、 TURN或 RSIP等。
当穿越方式为 STUN方式时，上述用于作为对端的远端地址的公网地址是 私网内的 MG 的本地媒体地址在 NAT 的公网侧映射的地址。 当穿越方式为 TURN方式时， 上述用于作为对端的远端地址的公网地址是 TURN服务器为 本次请求分配的公网地址。 当穿越方式为 RSIP方式时， 上述用于作为对端的
Figure imgf000011_0001
MGC给私网内的 MG发送上报公网地址的指示可以是通过信号， 属性， 事件， 信号参数， 事件参数或者在本地 SDP中描述的方式下发。
下面以 H.248扩展包的方式为例进行说明。 定义扩展 nattp包。
H.248扩展包包括：
I、 属性 stmgbindreq
该属性用于描述进行 NAT穿越的方式。 其值为 "STUNSHA E"表示要求网关实现带 SHARED-SECRET的 STUN 穿越， "STUNNOSHA F，表示不带 SHARED-SECRET, 直接发送绑定请求的 STUN方式， "TURN"表示使用 TURN的方式进行穿越， "RSIP"表示使用 RSIP 的方式进行穿越。 "NONAT"代表不需要 NAT穿越， 使用媒体网关在私网中分 配的本地媒体地址。配合该属性的当前值以及 H.248/MGCP请求消息中是否要 求应答消息中携带本端 SDP,以及应答消息中携带网关分配的私网地址还是映 射后的公网地址的设置或者默认值， 以及是否设置了上报事件， 网关可以确定 是否需要上 以及通过那种途径上 对应的公网地址和 /或私网地址。 上艮的 公网地址可以是本次要求上报公网地址以前已经通过 STUN等方式获得后保 存在本地的地址。
该属性可以是列表形式， 描述多个穿越方式。
2. 属性 traAttr
该参数进一步描述用于穿越的其它属性。不带该参数表示 MG使用默认配 置。 本属性指定本地私网地址， 相应服务器的类型， 地址， 具体穿越参数 (例 如前述的 STUNSHARE, STUNNOSHA E , TURN和 LOCAL ADDRESS)和 优先级的部分或者全部。同一个私网地址可以指定多个不同的 STUN, TURN等 服务器， 表示该私网地址可以通过多种途径获得映射的公网地址。 对应 IETF 定义的 ICE技术。
该属性可以是列表形式， 描述多个穿越属性。
本属性实际上可以实现属性 stmgbindreq的功能， 不过功能更强， 适用于 更加复杂的应用。
3. 属性 Nattype
该参数描述 MG所在私网的出口 NAT的类型。 有 Full Cone, Restricted Cone, Port Restricted Cone和 Symmetric四种。 同时也可以描述 NAT地址。 该参数用于 MG 自选穿越类型时作为参考。 不带该参数表示网关不需要该参 数，或者使用 MG上的默认配置。 如果网关所处的私网域有多个 NAT连接到 一个或者多个其它 IP域，则该参数需要结合 traAttr属性描述多个 NAT的类型 和 /或各自的 IP地址。 4. 属性 SDPReply
该属性是开关类型， 用于设置 MG 是否在本消息的应答消息中通过 H.248/MGCP信令消息中本地 SDP上报公网地址。 如果本属性指定 MG在应 答消息的本地 SDP中上报公网地址，而且在请求消息中要求网关上报本地 SDP, 则网关可以在收到该消息后，先不应答该消息，而是按照指示发出 SUTN等请 求， 获取公网地址后直接在本地 SDP中使用这些公网地址作为本地地址。 由 于 STUN消息交互需要一定时间，如果涉及到多个地址映射，则需要时间更久， 所以 MG可以通过发送 pending消息让 MGC等候应答。
如果将 MG在应答消息的本地 SDP中上 公网地址作为默认选项， 而且 只采取这种方式， 那么这个属性可以不要。
5. 属性 MGSTUNServer
该属性用于设置对端 MG是否作为 STUN服务器。 如果开关值为开， 则 网关根据 remote描述苻中 SDP描述的远端地址发送 STUN请求。 这样做的好 处在于： 媒体流和 STUN请求应答的路径完全相同， 所以对于各种 NAT都可 以穿越。 缺点是对端设备要具备 STUN服务器的功能。 因为 STUN报文的报 头可以和 RTP等区分开， 所以对端设备可以识别 STUN报文并且进行正确的 处理。
该属性用于统一指定本地媒体地址是否用 remote描述符中对应媒体流的 对端作为 STUN服务器的地址。也可以将这个属性定义成列表形式对各个本地 媒体地址单独设置是否用 remote描述符中对应媒体流的对端作为 STUN服务 器的地址。
上述各属性可以作为端点的属性或者网关级 (ROOT)的属性。 MGC可以通 过审计获取这些属性的值。 因为 H.248/MGCP协议的灵活性， 实现相同目的， 可以采用事件，信号以及事件信号的参数的方式，但是其机制和使用 H.248属 性的方式类似， 这里就不——列举了。
另夕卜，上述 stmgbindreq属性也不一定直接触发网关发送 STUN等 NAT穿 越协议消息。 MG可以根据当前各个属性的取值， 以及 H.248/MGCP请求消息 里面是否要求应答中上报本地 (local) SDP 等来判断是否需要通过发送 STUN 等 NAT穿越协议消息获取公网地址。 例如， MG被要求上报本端 SDP, MG 根据 stmgbindreq属性值判断当前 MGC要求的是私网地址还是通过 STUN等 获得的公网地址， 然后在应答消息的本端 SDP中按照要求上报地址。 如果要 求的是公网地址， 网关还可以选择将之前保存的公网地址上报， 而不会重新发 送 STUN等 NAT穿越协议消息。
如果网关发现 stmgbindreq属性被改变， MGC需要新的本端地址， MG也 可以通过事件的方式上报新的本地地址。
还有一种情况，网关也可以完全根据自身的配置或者逻辑自行决定是否发 送 STUN等 NAT 穿越协议消息获取公网地址。 例如： MG只要发现自身在 NA(P)T后，就默认发送 STUN等 NAT穿越协议消息获取公网地址，该网关地 址在本地 SDP中上 上艮公网地址的同时也可以将 RTP端点的私网地址一 起在 SDP中上报， 便于 MGC根据实际情况选用私网地址或者公网地址。
如果两端都在私网中， 可以都通过私网地址进行媒体流交互， 也可以用本 实施例中的方法将两端映射出公网地址后进行媒体流交互。
如果网关未能够获得所有公网地址， 则应答错误码给 MGC。
6、 信号 stmgcbindreq
MGC下发该信号给网关指示网关发送 STUN请求， 在该 STUN绑定请求 消息中通过 RESPONSE-ADDRESS属性指定返回应答到 MGC的指定地址， 这样 MGC就可以获取 NA(P)T映射的公网地址。
该信号带如下参数：
( 1 ) STUNAddr
该参数描述 STUN 服务器的的地址。 格式是地址加端口。 例 如:" 202.1.1.2:1000"。 如果没有该参数， 则网关选用默认配置的 STUN服务器。
( 2 ) PrivateAddr
该参数描述发送 STUN消息的源地址。为私网地址。 因为呼叫媒体协商时 可能协商出多个本地地址，所以要指定该 STUN消息从哪个地址发出。从不同 地址发出的 STUN绑定请求具有不同的 STUN事务号， 这样 MGC就可以从 STUN服务器应答的多个 STUN消息中的 STUN事务号来区分 STUN应答消 息中携带的公网地址是哪个私网地址的映射。该参数的格式是地址加端口， 例 如：" 192.168.1.2:2000"。
这里需要说明的是， 增加 IP端点时， 该地址还没有分配， 所以可以采用 其它方法达到同样的结果。 例如， 使用地址编号的方式， 将请求消息的本地 SDP中的地址进行编号， 比如用 <X，Y>的格式， X表示组 (group)号， Y表示在该 组中的地址序号。 例如" <2，1> "表示是本地 SDP的第二组的第一个地址。 不同 的编号对应不同的 STUN事务号，用于 MGC从获得的多个 STUN应答消息中 获得公网地址和私网地址的对应关系。
本参数的目的还可以通过其它途径获得， 这里就不——累述了。
( 3 ) Brmess
该参数为 MGC为 MG构造的 STUN请求消息。 MG将该消息从 PrivateAddr 指定的地址发送到 STUNAddr 指定的 STUN。 该请求消 息的 RESPONSE-ADDRESS属性指向 MGC。 MGC可以从收到的 STUN应答消息 中获取 NAT为 MG映射的公网地址。
MGC在发送 stmgcbindreq信号前可以先向 STUN服务器发送 Shared Secret 请求获得用户名。 如果 MGC本身在私网， 还可以发送 Binding到 TURN服务 器获得 NAT为 MGC分配的 IP地址和端口。该地址和端口可以放置在 Brmess 参数中携带的 SUTN消息的 RESPONSE-ADDRESS属性内。 STUN事务号也 由 MGC分配后在该参数中发送给 MG。不同的绑定请求的 STUN事务号不同。
如果一次呼叫要为私网内的多个地址获得公网地址， 则可以多次发送 stmgcbindreq信号， 或者重新定义 stmgcbindreq信号或者定义新的信号， 通过 列表的方式在一个信号中指示 MG发送多个 STUN的绑定请求， MGC收集到 所有应答后， 就获得了本次呼叫所有私网地址通过 NAT/TURN对应的公网地 址。
还有一种情况， MG只要发现自身在 NA(P)T后， 就默认发送 STUN消息 并且指定应答消息发送到 MGC, MGC从应答消息中获得 NA(P)T映射的公网 地址。 也就是说， 不需要 stmgcbindreq信号， 但是 MG可以自发实现该功能。
由于 H.248/MGCP协议的灵活性，为实现该信号的目的 ,还可以通过属性， 事件参数等其它形式， 这里就不一一累述了。
7、 事件 reportaddr
该事件可以用于 MG上报通过 STUN, TURN及 RSIP等协议获取的公网地 址。 MG通过该事件上报信息可以仅包括用于作为对端的远端地址的公网地址， 公网地址，还可以包括私网 MG的本地媒体地址及相应媒体属性及其对应的用 于作为对端的远端地址的公网地址。 该事件也可以用于不进行 NAT穿越时上报 MG的媒体私网地址。 如果网关获取公网地址失败， 则还可以通过该事件发送错 误码给 MGC。
其中， 媒体地址包括本地媒体的 IP地址， 或者， 包括本地媒体的 IP地址 和端口号； 公网地址包括公网的 IP地址， 或者， 公网的 IP地址和端口号。 其 余类似描述同。
MGC下发该事件时不携带参数， 私网中的 MG上报时该事件中的参数如 下：
( 1 ) 错误信息 err
如果无法通过 TURN/STUN/RSIP获得用于作为对端的远端地址的公网地 址， 则通过该^:返回错 因。
( 2 ) 地址 addr
如果只需要上报一组 IP地址或一组 IP地址 +端口， 则用该参数， 其内容 为 IP地址加端口的形式， 例如: "202.1.1.2:2000" 。
( 3 ) 地址列表 addrlist
如果涉及到多个私网地址需要映射， 而且这些私网地址有些相同，有些不 同，甚至对应的目的地址也可能有些相同有些不同，可以通过私网地址来对应 公网地址的方式， 例 p:
"192.168.1.1:1000 202.1.1.1:3000
192.168.1.2:2000 202.1.1.1 :4000"。
上例表示私网地址 192.168.1.1:1000映射的公网地址是 202.1.1.1:3000， 私网地址 192.168.1.2:2000映射的公网地址是 202.1.1.1:4000。 如果相同的私网地址因为目的地址不同， 映射到不同的公网地址， 则地 址列表可以私网地址加目的地址来对应公网地址的方式， 例如：
"192.168.1.1:1000 202.9.1.1 :1100 202.1.1.1 :3000
192.168.1.1:1000 202.9.1.1 :1200 202.1.1.1:4000"。
表示私网地址 192.168.1.1:1000 的媒体流对端地址为 202.9.1.1 :1100 时
NAT映射的地址是 202.1.1.1:3000，私网地址 192.168.1.1:1000的媒体流对端地 址为 202.9.1.1 :1200时 NAT映射的地址是 202.1.1.1:4000。
还有一种标识私网地址的方法是借用面前描述的 <χ，γ>格式， 用组号和组 内序号来标识映射的公网地址是对应哪个私网地址。
同一个私网地址通过不同的 STUN/TURN设备获得的多个映射地址可以 都上报， 由 MGC选择一个， 或者都发送到对端。
还可以用 SDP字符串的方式上报公网地址， 该参数的内容相同于映射后 的本地 (local) SDP，例如：
"v=0
c=IN IP4 202.1.1.1
m=audio 10000 RTP/AVP 0 4
v=0
c=IN IP4 202.1.1.2
m=audio 20000 RTP/AVP 0 18"
本段 SDP描述的含义如下：
媒体使用语音 (audio)类型， 使用 IP V4,媒体承载使用 RTP协议 (RFC3551 定义)。
媒体分为两个组 (group)：
第一组地址是 202.1.1.1，端口是 10000，使用编解码为 G.711和 G.723。
第二组地址是 202.1.1.2，端口是 20000，使用编解码为 G.711和 G.729。
其中， 18表示用于语音的 G.729 的载荷类型 （payload type );
0表示用于语音的 PCMU的 pay load type;
4表示用于语音的 G.723 的 payload type。 可以理解， 如果上述地址映射列表 addrlist中只包括一项， 实际就是前面 ( 1 )所描述的情况。 此处之所以分为 （1 )和（2 )描述是为了便于说明。
如果网关在应答消息的 SDP中携带映射的公网地址， 则 H.249/MGCP的 本地 SDP的格式如该 SDP示例所述， 公网地址在本地 SDP中携带。
对于 MGC来说， 获取的该 SDP可以不作修改地直接作为远端 (remote)发 给对端。
再有，私网中的 MG还可以通过扩展 H.248属性在应答消息中上报公网地 址列表。
当通过扩展 H.248事件的方式上报时， 可以将 SDP作为该事件中的一个 参数进行上报，也可以直接将所需上报内容按照前面描述的格式放入该事件参 数中进行上报； 当通过扩展 H.248属性在应答消息中上报时， 可以将 SDP作 为该属性的值进行上报，也可以直接将所需上报内容按照前面描述的格式放入 该属性中进行上报。
用非 SDP的格式上报公网地址还可以用其它格式， 这里不——累述。 如果 MGC所下发的属性 stmgbindreq被修改成不使用 NAT穿越， 而之前 为使用 NAT穿越， 并且该事件有效， 则该事件上报的是 MG的媒体私网地址。
事件上报和 MG通过 H.248/MGCP应答消息中的本地 SDP上报实现的是 同样的功能， 实际使用时可以只选用其中一种， 定义扩展包时， 也可以只包括 这两种机制中的一种。
8、 属性 mapaddrlist
如果对端设备也是媒体网关， 而且 NA(P)T后的网关或者其它设备对于 单个的私网地址上报了多个映射公网地址，则此属性用于下发这多个映射公网 地址。 该 list中每项的个数如下：
<list position>:<address:port>
例如 :"1,202.10.1.1 :1000"， "1,202.11.1.1:1000"
SDP中的地址进行编号的方式在后面有描述。
这两个字符串表示在 SDP中的地址的位置为 1的私网地址的映射公网地 址有" 202.10.1.1:1000"和" 202.11.1.1:1000"。 SDP扩展的方式可以实现前面 H.248扩展包的大部分功能，而且更便于描 述更加复杂的应用。
例如：
"v=0
c=IN IP4 $
m=audio $ RTP/AVP 0
a=natt 1.0 stun 202.1.1.9:1000
a=natt 0.9 stun 202.1.2.9:1000
a=natt 0.9 turn 202.1.1.8:2000"
a=nattrelpy:yes
本段 SDP描述的含义如下：
媒体使用语音 (audio)类型， 使用 IP V4,媒体承载使用 RTP协议 (RFC3551 定义)。 编码译码器（ Codec )使用 PCMU。
通过扩展的属性" natt"指示可以通过 STUN的方式穿越， 优先级别为 1.0，
STUN服务器地址为 202.1.1.9:1000。也可以通过另外一个地址为 202.1.2.9:1000 的 STUN服务器进行穿越， 优先级为 0.9。 也可以通过 TURN的方式穿越， 优 先级别为 0.9。 TURN服务器地址为 202.1.1.8:2000。 ，，a= nattrelpy:yes，，表示在 H.248/MGCP应答消息的 SDP中携带通过 STUN或者 TURN获得的公网地址。
SDP可以不指定具体的 STUN/TURN服务器地址， 而是简单指示要进行
NAT穿越。网关可以通过地址解析服务器（ DNS )查询等方式获得 STUN/TURN 服务器地址和端口。
NAT类型也可以通过 SDP描述， 例如: "a=NATType:f llcone"，表示是 foil cone的 NAT.
因为 STUN/TURN/RSIP的请求和应答发生在本端和 STUN/TURN/RSIP服 务器之间， 消息并不是到达媒体流对端。所以网关可以对于相同媒体流上报多 个通过不同途径获得的公网地址， MGC将这多个公网地址通知对端。 两端可 以对这多组公网地址进行探测（比如向对端发送握手消息， 等待应答， 如果收 到应答， 说明两端可以彼此到达)。 使用可以互相到达， 并且优先级最高或者 网关默认配置优先选择的公网地址进行媒体流交互。 要实现网关对同一个私网地址上报或者下发多组公网地址， 也需要扩展 SDP协议。
例如：
"v=0
c=IN IP4 10.1.1.1
m=audio 1000 RTP/AVP 0 18
a=nattcd 0 1.0 202.1.1.9:8000
a=nattcd 0 0.9 202.1.1.8:9000
a=nattcd 18 1.0 202.1.1.8:1000"
本段 SDP描述的含义如下：
媒体使用语音 (audio)类型， 使用 IP V4,媒体承载使用 RTP协议 (RFC3551 定义)。 编码译码器（ Codec ) 使用 PCMU。
通过扩展的属性" nattcd"获得的三组公网地址分别是用于 PCMU (playload type 为 0)的，， 202.1.1.9:8000"和，， 202.1.1.8:9000"， 以及适用于 G.729(playload type 为 18)的" 202.1.1.8:1000"。 优先级分别是 1.0， 0，9和 1.0。 该段 SDP可放 置在 H.248/MGCP的应答消息的 LOCAL SDP或者前述的 nattp/reportaddr事件 的 addrlist参数中。 MGC可以将其作为 remote SDP发送到对端， 也可以选择 其中的一部分发送给对端。 扩展中的 playload type如果不指定或者全指定， 则表示本行所带的公网地址适用于本组的所有 codec type。 总之， 相同的地址 如果适用于多个 codec，而且不同 codec的对端地址不同时，可能在对称式的 NAT 映射到不同的公网地址，因此，可能需要对不同 codec指明其对应的公网地址。 MG可以对两端地址相同的同一个私网地址对应的多组公网地址选取其中的 一个最终用来传递媒体流。
通常情况下， 网关只对每一个私网地址上艮一个对应的公网地址。特别是 对端地址相同而且 NAT类型为 cone类型时，一个对应的公网地址通常就能满 足需要。
本种格式还可以用于同时上报公网地址和私网地址的场合。 例如，还没有 确定对端是在公网上还是和本端属于同一个私网，则网关将公网地址和私网地 址一起上报， 后续过程中根据对端的实际情况选择使用私网地址或者公网地 址。
私网中发送 STUN/TURN/RSIP请求的 MG必须具备 STUN/TURN/RSIP 客户端的功能。 公网中放置 STUN/TURN/RSIP服务器。 由于 RSIP和 NA(P)T 类似， 以下仅以 STUN和 TURN为例进行说明。
对于独立的 STUN服务器而言， 如果 Full Cone类型的 NAT, 在 STUN服 务器应答消息后， NAT上产生了地址映射 (XI :X2, Y1 :Y2)， XI为私网 IP地 址， X2为私网端口。 Y1为公网 IP地址， Y2为公网端口。 那么公网网关的任 的私网地址端口对 (XI :X2)。 在媒体流从私网到达公网网关前， 对于 Port Restricted Cone, 公网网关的和 STUN服务器地址相同（端口允许不同）的端点 可以通过 (Y1 :Y2)访问（X1:X2)。 对于 Restricted Cone和 Symmetric, 公网网关 无法通过 (Y1： Y2)访问 (XI :X2)。
因为 TURN服务器自身转发媒体流，所以对于四种 NAT类型都可以支持。 如果公网上的网关同时具备 STUN服务器的功能， 则 STUN的消息和媒 体流的传递路径相同， 这样可以保证在不同类型的 NAT下， 只要 STUN消息 能够走通， 则媒体流也可以走通。 在呼叫流程中， 必须先获取公网端点使用的 地址和端口，私网端口才往这些端口发送 STUN请求。属性 traAttr可以将 STUN 服务器的地址指向对端媒体流的本地地址。 因为 STUN协议的报文是 0B00开 始 , 和 RTP不一样， 所以媒体网关可以区分出 SUTN报文和 RTP报文。 在这 种情况下，可以定义一个新的 H.248/MGCP包，定义一个属性或者信号用于指 示该网关是否作为 STUN server使用。
是否把 remote SDP中地址作为 STUN服务器地址也可以通过 SDP来描 述，例如:" a=MGAsSTUNSrv:yes，，，表示把 remote SDP中地址作为 STUN服务 器地址。 在使用新扩展的包前， MGC可以通过审计了解网关是否支持本申请扩展 的包。
另外需要说明一点， 本发明实施例中所说的 NAT穿越通常是指 NAT穿越 或 NAPT穿越这两种情况， 而 NAT穿越已经是本领域中约定俗成的说法。 因 此，穿越的是 NAT设备，则本发明实施例中所提到的公网地址只包括 IP地址， 如果穿越的是 NAPT设备， 本发明实施例中所提到的公网地址包括 IP地址和 端口号。 再有， 由于实际的 NAT穿越需要占用大量的 IP地址， 因此通常采用 NAPT穿越的方式， 但基于上述约定俗成的说法， 无论实际采用哪种方式本文 还是将其通称为 NAT穿越以及 NAT转换等。 另外， 本发明实施例中将 RSIP 实现的穿越也归入 NAT穿越， 因此前面提到的网络转换设备不仅可以是 NAT 设备和 NAPT设备 , 还可以是 RSIP设备。
另外， 考虑到网关上可能配置了所在私网的 NAT的类型， 地址以及 NAT 的绑定生命周期。 可以扩展 H.248/MGCP包， MGC通过审计或者事件上报的 方式从 MG获得 MG使用的 NAT类型 , 地址以及 NAT的绑定周期。 另外，还 可以通过属性信号等通知网关其使用的 NAT类型，地址以及 NAT的绑定周期。 NA(P)T设备内的地址转换映射表有一定的生命周期， 超时之后要删除映射。 STUN协议还提供了 STUN客户端检测 NA(P)T生命周期的机制， 以便 STUN 客户端决定刷新的频率。 所以可以还新增一个信号等指示网关去获取 NA(P)T 的生命周期。
前面提到用属性的方式获得 NA(P)T或者 TRUN服务器给本地私网地址映 射的公网地址， 这里列举一个具体方案。
将请求消息的本地 SDP 中的地址进行编号， 比如用 <N，X，Y>的格式来说 明， N表示序号， 从 1开始顺序排列， X表示组 (group)号， Y表示在该组中的 地址序号。 例如" <2，2，1> "表示序号为 2的地址是本地 SDP的第二组的第一个 地址。 这样 , 本地 SDP中的所有地址都可以有一个唯一序号。
针对 STUN协议， 定义属性 stunaddr。 类型是字符串列表。 在 MGC发给 MG的请求消息中， 该列表中的每一项可以如下取值：
L: "Local Address"，代表需要本地地址。 B:"Binding request"，代表需要发送 STUN binding request获取映射地址。
S:，， Shared Secret / Binding Request "，代表要先发送 Shared Secret STUN消 息 , 后通过发送 STUN binding request获取映射地址。
该字符串列表中的每一项对应前面描述的本地私网地址的唯一序号。也就 是说明该序号位置的私网地址做何种操作。
在 MG的应答消息中， 在属性 stunaddr字符串列表的相应的位置返回通 过该位置的请求中说明的方式获得的映射地址，或者返回错误码。如果请求消 息中该属性为 L，则应答消息的该位置为空字符串。
如果 NAT类型是 Symmetric,且相同的私网地址所对应对端地址不同 ,则 会在 NAT上映射出不同的公网地址。 如果使用 STUN协议， 使用远端 SDP中 的地址为 STUN服务器的地址造成对端地址不同 , 则可能相同的私网地址 (该 私网地址用于多个 codec, 例如" m=audio 1000 RTP/AVP 0 18")可能对应多个 映射地址。 所以在该情况下， 属性 stunaddr还要进一步指出某编号的私网地址 对应的 codec的序号。 例如： 请求消息中字符串列表中的字符串 "1，2，B"代表序 号为 1的私网地址对应的 "m="行的第二个静荷类型 (Payload type，即 codec类型） 对应的私网地址通过发送 binding request获取映射的公网地址。 应答消息中字 符串列表中的字符串 "1，2，202丄 1.1 : 1000"返回该静荷类型进行媒体流交互时对 应的公网地址为" 202.1.1.1 :1000"。
针对 TURN协议， 定义属性 tumaddr。 类型是字符串列表。 在 MGC发给 MG的请求消息中， 该列表中的每一项可以如下取值：
L: "Local Address", 代表需要本地地址。
A:" Allocate Request"，代表需要发送 TURN allocate request获取 TURN上 的映射地址。
该字符串列表中的每一项对应前面描述的本地私网地址的唯一序号。也就 是说明该序号位置的私网地址做何种操作。
在 MG的应答消息中， 在属性 tumaddr字符串列表的相应位置返回通过 该位置的请求中说明的方式获得的映射地址，或者返回错误码。如果请求消息 中该属性为 L,则应答消息的该位置为空字符串。 由于通过不同的 TURN服务 器可以获取不同的映射地址， 所以应答消息中要带上本地私网地址序号。
例如： "1,202.1.1.1:1000" , "1,202.1.1.2:1000"， "2,202.1.1.3:3000", 这标 识通过两个 TURN服务器序号为 1的本地私网地址获得了两个不同的映射地 址。
如果媒体流对端也是网关， 则 MG应答消息的 stunaddr属性和 tumaddr 属性中的内容可以被 MGC在发给对端的请求消息中通过属性下发， 将映射的 公网地址的部分或者全部通知对端。 MGC也可以先做选择， 将每个本地地址 只保留一个映射公网地址通过属性或者 SDP等发送到对端。
STUN/TURN应答消息中可以携带绑定生命周期（ binding-lifetime )，另夕卜， 在 RFC3489中还定义了 STUN客户端检测 NAT绑定生命周期的方式， MGC 可以通过信号等方式要求私网中的媒体网关进行 NAT绑定生命周期的检测。 MGC可以通过属性等方式要求 MG上报 NAT绑定生命周期。
IETF的 ICE草稿 (draft-ietf-mmusic-ice-09.txt)中定义检测 STUN的联通性 性（Connectivity Checks ), 也就是说， 通过 STUN Binding Request来检测媒 体通道是否导通。 进行联通性检测的同时实际上也保证了相应的 NAT绑定的 激活状态。 前面也描述过， STUN消息和 RTP消息的消息头不同， 所以对端 容易将两种类型的消息区分开处理。 MGC 可以下发信号等指示网关发送 STUN联通检测包， 按照协议规定， 可以具体指定源地址为 local, reflexive,或 者 relayed, 其分别代表源地址为本地地址， 用于从 STUN获得的 NAT映射地 地址。
MGC 还可以指示网关发送 TURN send Indication 消息 , Set Active Destination请求 , Connect Status Indication消息 , Open Binding请求 , Close Binding请求等 STUN/TURN消息， 并且收集应答消息中的信息上报到 MGC。 以实现 MGC对 MG的 STUN/TURN过程的完全控制。
RTCP(RTP Control Protocol)报文通常使用与被控制的 RTP流相同的 IP地 址，但是端口加 1， 媒体流两端都遵守这个规则。 但是， RTP和 RTCP的地址和 端口经过 NAT映射后 ,其映射后的公网 IP地址和端口可能并不遵守这个规则 , 这样可能会导致私网中的网关无法接收到 RTCP报文。
要解决这个问题， 可以把 RTCP的地址和端口也用前述的方法通过 STUN 或者 TRUN等获取映射公网地址后上报。
MGC 可以指示网关去获取 RTCP 地址的映射地址， 例如前面所述的 stunaddr属性， 如果需要映射 RTCP地址， 则请求消息中用类似 "2，C，B"的字符 串表示序号为 2的私网地址对应的 RCTP地址需要用 binding request的方式获 得映射公网地址。 在应答消息中， 字符串列表中的" 2，C， 202.1.1.1:1001"表示序 号为 2 的私网地址对应的 RTCP 地址被 NAT 映射后的公网地址是 "202.1.1.1:1001"。
在 RFC3605中描述了如何在 SDP中携带 RTCP端口号。
另外， 指示网关去获取 RTCP地址的映射地址也可以通过 MGC 下发给 MG的本地 SDP中指示。例如在 SDP中增加" a=natt 1.0 rtcp stun 10.11.1.1:2000 202.1.1.9:1000",表示 "10.11.1.1:2000"这个 RTCP 的源地址需要向 " 202.1.1.9:1000"这个 STUN服务器发送请求，获取映射公网地址。优先级为 1.0。 应答消息的本地 SDP中可以携带映射后的 RTCP公网地址。
另外， RFC2833，RFC2198，以及舒适噪音 (CN)等静荷类型的 RTP 流以及 UDPTL ( UDP传送层， UDP Transport Layer )， TCP等类型的媒体流都可以归 类于媒体流， 通过本申请描述的方法进行 NAT穿越。
基于 H.248协议下面结合实现流程进行伴细说明。
图 2所示为根据本发明一实施例的主叫侧 MG在私网采用 STUN方式进 行地址协商的实现流程图。 本实施例中， MG1 为主叫侧 MG, 位于私网中； MG2为被叫侧 MG, 位于公网中。 实际上， 本申请涉及的 H.248/MGCP扩展 包和 SDP扩展都不会作用到公网侧的设备， 被叫侧可以是 SIP终端、 H323终 端、 MG或者其他 CS域或者分组网络等。 对于图 3， 4, 5和 7的流程， 也并 不限定公网中的设备是 MG,公网侧可以不使用 MG而使用前面列举的其它设 备， 这些设备并不需要知晓对端私网内的 MG为了进行 NAT穿越而对本地私 网地址做了映射处理， 就象对端也在公网内一样。
步骤 1 , 根据 H.248协议的规定， MGC向 MG1下发为主叫侧增加端点的 请求， 该请求中的上下文标识（contextid )为选择（choose ), 所增加的端点是 A1和一个 RTP端点。并且，在该请求中 MGC还指示在 RTP端点上下发 nattp/ stmgbindreq 属性和 nattp/addr 事件 , nattp/ stmgbindreq 属性值为 STUNNOSHA E。 以通知 MG1发送绑定 (binding)STUN请求并且上报 STUN 应答中携带的映射地址。
步骤 2, MG1给 MGC返回应答消息， 该应答消息中 contextid为 1 , 增加 的 RTP端点为 RTP/1 , SDP中本地媒体网关地址为 10.11.1.1 :1000。
步骤 3 , MG1发送 STUN请求到 NAT。该请求中包含私网中 MG1的本地 地址 10.11.1.1:1000。
步骤 4, NAT将该请求消息转发到 STUN服务器。 该转发的消息中包括
NAT为 MG1的本地地址映射的公网地址 202.1.1.1:2000。
步骤 5 , STUN服务器根据接收到的请求返回应答消息 , 该应答消息中包 含 NAT的公网侧映射地址 202.1.1.1 :2000。
步骤 6, NAT根据自身已保存的 10.11.1.1:1000和 202.1.1.1 :2000的映射， 将接收到的应答转发给 MG1。 该转发的应答中包含 MG1在 NAT的公网侧映 射地址 202.1.1.1:2000。
步骤 7 ~ 8， MG1 将 STUN服务器返回的地址用 nattp/addr事件上报给 MGC, 即将 MG1 本地的媒体地址 10.11.1.1:1000被 NAT 映射的公网地址 202.1.1.1:2000上报给 MGC, 并接收来自 MGC的应答。
步骤 9，根据 H.248协议 MGC向 MG2发送增加被叫侧端点的请求，此时， 该请求的 remote描述符中携带的是 202.1.1.1 :2000 , 而不是 MG1上报的私网 地址 10.11.1.1:1000。 这样 MG2 的媒体流就可以发送到公网地址 202.1.1.1:2000, 而 NAT使用其已经保存的映射关系， 将媒体流传发到 MG1 实际的媒体源地址 10.11.1.1:1000。
步骤 10, MG2给 MGC返回应答消息， 该应答消息中 contextid为 2, 增 加的 RTP端点为 RTP/2, SDP中本地媒体地址为 202.1.2.2:9000。
步骤 11 ~ 12， MGC将 MG2的媒体地址 202.1.2.2:9000在 modify命令的 remote SDP中通知 MG1 , 并接收来自 MG1的应答消息。 至此， 地址协商完毕。 此时， MG1和 MG2的本次呼叫的媒体流可以通过 STUN建立好的通道互通， 即 MG1和 MG2中的任一方均可先发送媒体流到 NAT映射的公网地址 202.1.1.1 :2000 , 并由 NAT转发到对方 , 避免了媒体流必 须由私网内的端点首先发起这样的缺陷。
另夕卜，如果 NAT类型不是 Full Cone ,则可以考虑被叫侧的网关支持 STUN 服务器的功能。 那么， 在执行步骤 3的时候， 还不知道公网媒体使用的地址， 所以步骤 3到 8要移到步骤 12之后， 而 nattp/ stmgbindreq属性和 nattp/addr 事件也要在步骤 11的 modify命令中下发。 也就是说， MG1通过 remote SDP 获得被叫的媒体地址后， 该媒体地址作为 STUN服务器的地址， 即此时 STUN 服务器的地址与 MG2上媒体流对端的地址相同。在 STUN协商完毕以后， MGC 还需要向 MG2发送 modify命令修改 remote SDP的值， 将 remote地址指向 STUN应答中返回的 NAT给 MG1上该收发媒体流的本端映射的公网地址。
另外， 在某些情况下， 在主叫侧的 MG1上增加端点的时候， MGC还并 不知道被叫侧是否与 MG1在同一个 IP域，所以可以把发送 STUN请求放在步 骤 11进行， 此时 MGC已经确认呼叫对端在公网。 MG1上报的公网地址还需 要在 MG2侧通过 modify消息当作远端地址下发。 后面的图 4， 图 6的流程中 也可以将 STUN/TURN请求发送的位置挪后到被叫增加端点后。
当然 ,在主叫和被叫网关处于同一个私网域时 ,主叫被叫可以都通过 NAT 穿越获取公网地址， 然后通过这两个公网地址进行媒体流交互。在这种情况下 媒体流可以互通， 但是显然不是一种很好地解决方案。 如果 MGC能够判断出 主叫被叫网关是同一个私网域， 应该避免这种情况出现。
另外， 本流程中， 通过 STUN 协议获得的映射公网地址是通过事件 nattp/addr上报的， 避免影响 H.248的请求应答过程。 但是， 还有一种可以采 用的方法是:步骤 3到 6可以移到步骤 1和 2之间 , 即 MG收到 ADD请求后， 先不应答， 而是通过 STUN交互获得 NAT映射公网地址后， 在 ADD应答消 息的本地 SDP中直接采用映射的公网地址或者携带映射的公网地址。 这样， 步骤 7， 8可以去掉。 造成的可能的问题是， 如果 STUN过程花费较多时间， ADD请求可能会超时。 这个问题可以通过 MG先应答 pending解决。 无论 STUN 交互放在 ADD应答的前面还是后面， 都必须在获得映射公网地址后 H.248呼叫流程才能继续进行。 但是放在 ADD应答前， 可以省掉 nattp/addr 事件的设置和上报。
在 H.248应答消息的本地 SDP中上 ^艮公网地址的方法可以适用于图 3到 图 7的所有例子。类似地，可以由 MGCP协议为例来实现本流程，通过 MGCP 应答消息的本地 SDP中上 公网地址的方法也可以适用于图 2到图 7的所有 实施例。
图 3所示为根据本发明一实施例的被叫侧 MG在私网采用 STUN方式进 行地址协商的实现流程图。 本实施例中， MG1 为被叫侧 MG, 位于私网中； MG2为主叫侧 MG, 位于公网中。 在该实施例中， 不通过事件上报映射的公 网地址， 而是使用 H.248应答消息中的本地 SDP携带映射的公网地址。
步骤 1 , 根据 H.248协议的规定， MGC向 MG2发送为主叫侧增加端点的 请求， 该请求中的 contextid为 choose , 所增加的端点是 A2和一个 RTP端点。
步骤 2 , MG2给 MGC返回应答消息 , 该应答消息中 contextid为 2 , 增加 的 RTP端点为 RTP/2, SDP中本地媒体网关地址为 202.1.2.2:9000。
步骤 3，根据 H.248协议 MGC向 MG1发送增加被叫侧端点的请求，该请 求中的 contextid为 choose,所增加的端点是 A1和一个 RTP端点 , Remote SDP 中携带 202.1.2.2:9000 , 在该请求中 MGC 还指示 RTP 端点上下发 nattp/ stmgbindreq 属 生和 nattp/SDPReply 属 'I"生 , nattp/ stmgbindreq 属 生的值 为" STUNNOSHARE", nattp/SDPReply属性的值为 YES。如果通过 H.248/MGCP 应答消息中的本地 SDP上报公网地址是一种默认行为， 则消息中不包含该属 性。 以通知 MG1发送 STUN绑定 (binding)请求并且上报 STUN应答中携带的 映射地址。
步骤 4， MG1发送 STUN请求到 NAT。该请求中包含私网中 MG1的本地 地址 10.11.1.1:1000。
步骤 5, NAT将该请求消息转发到 STUN服务器。 该转发的消息中包括 NAT为 MG1的本地地址映射的公网地址 202.1.1.1:2000。
步骤 6， STUN服务器根据接收到的请求返回应答消息， 该应答消息中包 含 NAT的公网侧映射地址 202.1.1.1 :2000。
步骤 7, NAT根据自身已保存的 10.11.1.1:1000和 202.1.1.1 :2000的映射， 将接收到的应答转发给 MG1。 该转发的应答中包含 MG1在 NAT的公网侧映 射地址 202.1.1.1:2000。
步骤 8 , MG1给 MGC返回应答消息 , 该应答消息中 contextid为 1 , 增加 的 RTP端点为 RTP/1 , SDP中本地媒体地址为 202.1.1.1:2000。
步骤 9 ~ 10， MGC将 MG1的媒体地址 202.1.1.1 :2000在 modify命令的 remote SDP中通知 MG2 , 并接收来自 MG2的应答消息。
至此， 地址协商完毕。 此时， MG1和 MG2的本次呼叫的媒体流可以通过 STUN建立好的通道互通， 即 MG2可以发送媒体流到 NAT映射的公网地址 202.1.1.1 :2000 , 并由 NAT转发到对方 , 避免了媒体流必须由私网内的端点首 先发起这样的缺陷。
另外， 在实际应用中， STUN服务器可能就是 MG2。
图 4所示为根据本发明一实施例的主叫侧 MG在私网采用 TURN方式进 行地址协商的实现流程图。 本实施例中， MG1 为主叫侧 MG, 位于私网中； MG2为被叫侧 MG , 位于公网中。
步骤 1 , 根据 H.248协议的规定， MGC向 MG1下发为主叫侧增加端点的 请求， 该请求中的 contextid为选择 choose, 所增加的端点是 A1和一个 RTP 端点。 并且， 在该请求中 MGC还指示在 RTP端点上下发 nattp/ stmgbindreq 属性和 nattp/addr事件 , nattp/ stmgbindreq属性的值为 "TURN"以通知 MG1发 送 TURN请求并且上报 TURN应答中携带的映射地址。
步骤 2, MG1给 MGC返回应答消息， 该应答消息中 contextid为 1 , 增加 的 RTP端点为 RTP/1 , SDP中本地媒体网关地址为 10.11.1.1 :1000。
步骤 3 , MG1发送 TURN分配请求到 NAT。 该请求中包含私网中 MG1 的本地地址 10.11.1.1:1000。
步骤 4， NAT将该请求消息转发到 TURN服务器。 该转发的消息中包括 NAT为 MG1的本地地址映射的公网地址 202.1.1.1:2000。
步骤 5 , TURN服务器根据接收到的请求返回应答消息， 该应答消息中包 含 TURN服务器为本次请求分配的映射地址 202.1.2.3:3000。
步骤 6, NAT根据自身已保存的 10.11.1.1:1000和 202.1.1.1 :2000的映射， 将接收到的应答转发给 MG1。 该转发的应答中包含 TURN服务器为本次请求 分配的映射地址 202.1.2.3:3000。
步骤 7 ~ 8， MG1 将 TURN服务器返回的地址用 nattp/addr事件上报给
MGC , 即将 MG1本地的媒体地址 10.11.1.1： 1000被 NAT映射后 ,被 TURN服 务器分配的公网地址 202.1.2.3:3000上报给 MGC, 并接收来自 MGC的应答。
步骤 9，根据 H.248协议 MGC向 MG2发送增加被叫侧端点的请求，此时， 该请求的 remote描述符中携带的是 202.1.2.3:3000, 而不是 MG1上报的私网 地址 10.11.1.1： 1000。这样 MG2的媒体流就可以发送到 TURN服务器上，再由 TURN服务器通过 NAT转发到私网。
步骤 10, MG2给 MGC返回应答消息， 该应答消息中 contextid为 2, 增 加的 RTP端点为 RTP/2, SDP中本地媒体地址为 202.1.2.2:9000。
步骤 11 ~ 12， MGC将 MG2的媒体地址 202.1.2.2:9000在 modify命令的 remote SDP中通知 MG1 , 并接收来自 MG1的应答消息。
至此， 地址协商完毕。 这样 MG2发出的媒体发送到 TURN服务器的 202.1.2.3:3000。 TURN服务器沿着 TURN消息交互建立的 NAT映射， 将媒体 发送到 NAT 为 MG1 映射的 202.1.1.1 :2000 , NAT 将其再转给私网地址 10.11.1.1:1000。
图 5所示为根据本发明一实施例的被叫侧 MG在私网采用 TURN方式进 行地址协商的实现流程图。 本实施例中， MG1 为被叫侧 MG, 位于私网中； MG2为主叫侧 MG, 位于公网中。
步骤 1 , 根据 H.248协议的规定， MGC向 MG2发送为主叫侧增加端点的 请求， 该请求中的 contextid为 choose , 所增加的端点是 A2和一个 RTP端点。
步骤 2 , MG2给 MGC返回应答消息 , 该应答消息中 contextid为 2 , 增加 的 RTP端点为 RTP/2, SDP中本地媒体网关地址为 202.1.2.2:9000。
步骤 3 ,根据 H.248协议 MGC向 MG1发送增加被叫侧端点的请求，该请 求中的 contextid为 choose ,所增加的端点是 A1和一个 RTP端点 , Remote SDP 中携带 202.1.2.2:9000 , 在该请求中 MGC 还指示 RTP 端点上下发 nattp/ stmgbindreq属性和 nattp/addr事件， nattp/ stmgbindreq的值为 "TURN"以通知 MGl发送 TURN请求并且上报 TURN应答中携带的映射地址。
步骤 4, MG1给 MGC返回应答消息， 该应答消息中 contextid为 1 , 增加 的 RTP端点为 RTP/1 , SDP中本地媒体地址为 10.11.1.1： 1000。
步骤 5, MG1发送 TURN分配请求到 NAT。 该请求中包含私网中 MG1 的本地地址 10.11.1.1:1000。
步骤 6， NAT将该请求消息转发到 TURN服务器。 该转发的消息中包括 NAT为 MG1的本地地址映射的公网地址 202.1.1.1:2000。
步骤 7， TURN服务器根据接收到的请求返回应答消息， 该应答消息中包 含 TURN服务器为本次请求分配的映射地址 202.1.2.3:3000。
步骤 8, NAT根据自身已保存的 10.11.1.1 :1000和 202.1.1.1 :2000的映射， 将接收到的应答转发给 MG1。 该转发的应答中包含 TURN服务器为本次请求 分配的映射地址 202.1.2.3:3000。
步骤 9 ~ 10, MG1将 TURN服务器返回的地址用 nattp/addr事件上报给
MGC , 即将 MG1本地的媒体地址 10.11.1.1： 1000被 NAT映射后 ,被 TURN服 务器分配的公网地址 202.1.2.3:3000上报给 MGC, 并接收来自 MGC的应答。
步骤 11 ~ 12，MGC将 TURN服务器为 MG1分配的映射地址 202.1.2.3:3000 在 modify命令的 remote SDP中通知 MG2, 并接收来自 MG2的应答消息。
由于 TURN方式需要 TURN服务器转发媒体， 会影响效率， 增加丢包， 所以通常不推荐使用， 其主要用于 NAT为对称 (SYMMETRIC)类型的情况下。
对于图 2至图 5所示实施例， 均有一端处于公网， 而该处于公网的一端有 可能是 SIP终端、 H323终端、 网关或者连接到其它 CS域或者 IP网络等。
图 6所示为根据本发明一实施例的主被叫侧 MG均在私网采用 STUN方 式进行地址协商的实现流程图。 本实施例中， MG1 为主叫侧 MG, 位于私网 中； MG2为被叫侧 MG, 位于与 MG1不同的私网中。
步骤 1 , 根据 H.248协议的规定， MGC向 MG1下发为主叫侧增加端点的 请求， 该请求中的上下文标识（contextid )为选择（choose ), 所增加的端点是 Al和一个 RTP端点。并且，在该请求中 MGC还指示在 RTP端点上下发 nattp/ stmgbindreq 属性和 nattp/addr 事件 , nattp/ stmgbindreq 属性值为 " STUNNOSHARE"以通知 MG1发送 STUN绑定 (binding)请求并且上报 STUN 应答中携带的映射地址。
步骤 2 , MG1给 MGC返回应答消息 , 该应答消息中 contextid为 1 , 增加 的 RTP端点为 RTP/1 , SDP中本地媒体网关地址为 10.11.1.1 :1000。
步骤 3 , MG1发送 STUN请求到 NAT。该请求中包含私网中 MG1的本地 地址 10.11.1.1:1000。
步骤 4, NAT将该请求消息转发到 STUN服务器。 该转发的消息中包括 NAT为 MG1的本地地址映射的公网地址 202.1.1.1:2000。
步骤 5 , STUN服务器根据接收到的请求返回应答消息 , 该应答消息中包 含 NAT的公网侧映射地址 202.1.1.1:2000。
步骤 6, NAT根据自身已保存的 10.11.1.1:1000和 202.1.1.1 :2000的映射， 将接收到的应答转发给 MG1。 该转发的应答中包含 MG1在 NAT的公网侧映 射地址 202.1.1.1:2000。
步骤 7 ~ 8， MG1 将 STUN服务器返回的地址用 nattp/addr事件上报给 MGC, 即将 MG1 本地的媒体地址 10.11.1.1:1000被 NAT 映射的公网地址 202.1.1.1:2000上报给 MGC, 并接收来自 MGC的应答。
步骤 9，根据 H.248协议 MGC向 MG2发送增加被叫侧端点的请求，该请 求中的 contextid为 choose ,所增加的端点是 A2和一个 RTP端点 , Remote SDP 中携带 202.1.1.1:2000， 在该请求中 MGC 还指示 RTP 端点上下发 nattp/ stmgbindreq 属性和 nattp/addr 事件 , nattp/ stmgbindreq 属性的值为 STUNNOSHA E。 以通知 MG2发送绑定 (binding)STUN请求并且上报 STUN 应答中携带的映射地址。
步骤 10, MG2给 MGC返回应答消息， 该应答消息中 contextid为 2, 增 加的 RTP端点为 RTP/2, SDP中本地媒体地址为 192.168.1.1 :1000。
步骤 11， MG2发送 STUN请求到 NAT。 该请求中包含私网中 MG1的本 地地址 192.168.1.1:1000。 步骤 12， NAT将该请求消息转发到 STUN服务器。 该转发的消息中包括 NAT为 MG1的本地地址映射的公网地址 202.1.3.3:8000。
步骤 13 , STUN服务器根据接收到的请求返回应答消息，该应答消息中包 含 NAT的公网侧映射地址 202.1.3.3:8000。
步骤 14, NAT根据自身已保存的 192.168.1.1:1000和 202.1.3.3:8000的映 射， 将接收到的应答转发给 MG2。 该转发的应答中包含 MG2在 NAT的公网 侧映射地址 202.1.3.3:8000。
步骤 15 ~ 16, MG2将 STUN服务器返回的地址用 nattp/addr事件上报给 MGC, 即将 MG2本地的媒体地址 192.168.1.1:1000被 NAT映射的公网地址 202.1.3.3:8000上报给 MGC, 并接收来自 MGC的应答。
步骤 17 ~ 18， MGC将 MG2的媒体地址 202.1.3.3:8000在 modify命令的 remote SDP中通知 MG1 , 并接收来自 MG1的应答消息。
至此， 地址协商完毕。 此时， MG1和 MG2的本次呼叫的媒体流可以通过 STUN建立好的通道互通，即 MG1和 MG2彼此将媒体流的目的地址指向对方 私网地址通过 NAT映射的公网地址， 并由 NAT转发到对方， 避免了媒体流必 须由私网内的端点首先发起这样的缺陷。
对于图 6所示实施例， MG1和 MG2所使用的穿越协议消息可以相同也可 以不同， 例如， 如果 MG1采用 STUN方式的穿越协议消息， 则 MG2可以采 用 STUN方式的穿越协议消息或采用 RSIP等方式的穿越协议消息。
图 7 所示为根据本发明一实施例的 STUN服务器应答 STUN binding request 消息到 MGC的实现流程图。 本实施例中， MG1为被叫侧 MG, 位于 私网中； MG2为主叫侧 MG, 位于公网中。 在该实施例中， MGC指示网关发 送 STUN绑定请求， 但是目的地址为 MGC, MGC获得公网地址后发送到对 端。
步骤 1 , 根据 H.248协议的规定， MGC向 MG2发送为主叫侧增加端点的 请求， 该请求中的 contextid为 choose , 所增加的端点是 A2和一个 RTP端点。
步骤 2, MG2给 MGC返回应答消息 , 该应答消息中 contextid为 2, 增加 的 RTP端点为 RTP/2, SDP中本地媒体网关地址为 202.1.2.2:9000。 步骤 3 ,根据 Η.248协议 MGC向 MG1发送增加被叫侧端点的请求，该请 求中的 contextid为 choose ,所增加的端点是 A1和一个 RTP端点 , Remote SDP 中携带 202.1.2.2:9000 , 在该请求中 MGC 还指示 RTP 端点上下发 nattp/ stmgcbindreq信号， 以通知 MG1发送 STUN绑定 (binding)请求， 并且本信号 的 Brmess 参数中指明 RESPONSE- ADDRESS 中携带的目的地址是指定的 MGC地址。
步骤 4, MG1给 MGC返回应答消息， 该应答消息中 contextid为 1 , 增加 的 RTP端点为 RTP/1 , SDP中本地媒体网关地址为 10.11.1.1 :1000。
步骤 5, MG1发送 STUN请求到 NAT。该请求中包含私网中 MG1的本地 地址 10.11.1.1:1000。
步骤 6, NAT将该请求消息转发到 STUN服务器。 该转发的消息中包括 NAT为 MG1的本地地址映射的公网地址 202.1.1.1:2000。
步骤 7， STUN服务器根据接收到的请求返回应答消息， 该应答消息中包 含 NAT的公网侧映射地址 202.1.1.1 :2000。 该应答消息 ^送到 MGC。
步骤 8 ~ 9, MGC将 MG1 的媒体地址 202.1.1.1:2000在 modify命令的 remote SDP中通知 MG2, 并接收来自 MG2的应答消息。
至此， 地址协商完毕。 此时， MG1和 MG2的本次呼叫的媒体流可以通过 STUN建立好的通道互通， 即 MG2可以发送媒体流到 NAT映射的公网地址 202.1.1.1 :2000 , 并由 NAT转发到对方。
可见，本发明实施例是对私网中的媒体网关做功能扩展，对端的公网设备 可以是现有的 SIP终端、 H323终端、 MG或者其他 CS域或者分组网络等。 而 且对端的公网设备可以不必针对 NAT穿越做任何相应的特殊处理， 这样可以 更好地兼容现网设备。
本发明实施例还公开了一种实现媒体流交互的系统，欲交互媒体流的两端 所在媒体承载网为 IP网域， 其中一个 IP网域为需要通过网络转换设备映射地 址的私网域， 该系统包括： 媒体网关控制器 MGC, 私网中的媒体网关 MG以 及需要与所述私网中的 MG进行媒体流交互的对端； 其中，
MGC内还包括公网地址获取单元和公网地址传送单元； 公网地址获取单元 ,用于获取私网中的媒体网关 MG本地媒体地址所对应 的公网地址， 将所述公网地址发送给所述公网地址传送单元； 所述公网地址是 用于作为所述 MG对端的远端地址的公网地址；
公网地址传送单元， 用于将接收到的所述公网地址发送给所述对端； 私网内的 MG还包括：
公网地址上报单元， 用于根据接收到来自 MGC的上报公网地址的指示， 发起穿越协议消息，获取用于作为对端的远端地址的公网地址，将包含所述公 网地址的列表上报给 MGC; 或者， 从自身已保存的信息中直接获取所述公网 地址， 上报给所述 MGC。
上述 MGC中的公网地址获取单元内包括：指示下发单元，信息获取单元； 其中，
指示下发单元， 用于给所述 MG发送上报公网地址的指示； 或者， 用于给 所述 MG发送进行穿越并且应答目的地址为 MGC的指示；
所述信息获取单元，用于从接收到的来自 MG的上报信息中获取所述公网 地址； 或者， 用于根据接收到的穿越协议消息应答获取所述公网地址。
上述信息获取单元，进一步用于从接收到的上报信息中获取所述 MG本地 媒体地址的私网地址。
上述 MGC中指示下发单元发送的上报公网地址的指示中包括： 穿越方式 标识， 和 /或穿越协议请求消息的目的地址和端口， 和 /或发送穿越协议请求消 息的源地址， 和 /或穿越协议消息是否使用加密方式， 和 /或是否所述对端具备 STUN服务器的功能；
所述穿越协议请求消息的目的地址和端口包括 STUN服务器的地址和端 口， TURN服务器的地址和端口， RSIP服务器的地址和端口。
上述 MGC中的指示下发单元发送的上报公网地址的指示中进一步包括一 个或者多个网络转换设备的类型； 所述类型包括 Full Cone、 Restricted Cone、 Port Restricted Cone和 Symmetric;
所述网络转换设备的类型的设置的方式包括属性， 信号， 信号参数， 事件 参数和在 SDP中描述的方式。 上述 MGC 中的指示下发单元发送的上报公网地址的指示中进一步包括 MG是否通过 H.248/MGCP应答消息中的本地 SDP进行上报的指示； 该指示 的设置的方式包括属性， 信号， 信号参数， 事件参数和在 SDP中描述的方式。
上述 MGC中指示下发单元发送的指示是通过信号， 属性， 事件， 信号参 数， 事件参数或者在 SDP中描述的方式下发。
上述私网内 MG 中的公网地址上报单元上报公网地址列表或公网地址的 方式为： 直接通过 H.248/MGCP应答消息中的本地 SDP上报， 或者， 根据接 收到的来自 MGC的通过 H.248/MGCP应答消息中的本地 SDP进行上报的指 示， 采用 H.248/MGCP应答消息中的本地 SDP上报。
网络转换设备为网络地址转换设备 NAT或网络地址端口转换设备 NAPT 或 RSIP设备。 私网内的 MG的对端包括 SIP终端、 H323终端、 MG或者 CS 域网络或者分组域网络。
本发明实施例还公开了一种媒体网关控制器， 包括：公网地址获取单元和 公网地址传送单元；
所述公网地址获取单元 ,用于获取私网中的媒体网关 MG本地媒体地址所 对应的公网地址， 将所述公网地址发送给所述公网地址传送单元； 所述公网地 址是用于作为所述 MG对端的远端地址的公网地址；
上述公网地址传送单元， 用于将接收到的所述公网地址发送给所 亍端。 MGC中的公网地址获取单元内包括： 指示下发单元， 信息获取单元； 上述指示下发单元， 用于给所述 MG发送上报公网地址的指示； 或者， 用 于给所述 MG发送进行穿越并且应答目的地址为 MGC的指示；
上述信息获取单元，用于从接收到的来自 MG的上报信息中获取所述公网 地址； 或者， 用于根据接收到的穿越协议消息应答获取所述公网地址。
上述信息获取单元，进一步用于从接收到的上报信息中获取所述 MG本地 媒体地址的私网地址。
上述指示下发单元发送的上报公网地址的指示中包括： 穿越方式标识，和 /或穿越协议请求消息的目的地址和端口， 和 /或发送穿越协议请求消息的源地 址， 和 /或穿越协议消息是否使用加密方式， 和 /或是否所述对端具备 STUN服 务器的功能；所述穿越协议请求消息的目的地址和端口包括 STUN服务器的地 址和端口， TURN服务器的地址和端口， RSIP服务器的地址和端口。
上述 MGC中的指示下发单元发送的上报公网地址的指示中进一步包括一 个或者多个网络转换设备的类型； 所述类型包括 Full Cone、 Restricted Cone、 Port Restricted Cone和 Symmetric; 所述网络转换设备的类型的设置的方式包 括属性， 信号， 信号参数， 事件参数和在 SDP中描述的方式。
上述 MGC 中的指示下发单元发送的上报公网地址的指示中进一步包括 MG是否通过 H.248/MGCP应答消息中的本地 SDP进行上报的指示； 该指示 的设置的方式包括属性， 信号， 信号参数， 事件参数和在 SDP中描述的方式。
MGC中指示下发单元发送的指示是通过信号， 属性， 事件， 信号参数， 事件参数或者在 SDP中描述的方式下发。
本发明实施例还公开了一种私网内的媒体网关， 包括：
公网地址上报单元， 用于根据接收到来自 MGC的上报公网地址的指示， 发起穿越协议消息，获取用于作为对端的远端地址的公网地址，将包含所述公 网地址的列表上报给 MGC; 或者， 从自身已保存的信息中直接获取所述公网 地址， 上报给所述 MGC。 直接通过 H.248/MGCP应答消息中的本地 SDP上报， 或者， 根据接收到的来 自 MGC的通过 H.248/MGCP应答消息中的本地 SDP进行上报的指示， 采用 H.248/MGCP应答消息中的本地 SDP上报。
以上所述仅为本发明的较佳实施例而已， 并非用于限定本发明的保护范 围。 凡在本发明的精神和原则之内所作的任何修改、 等同替换、 改进等， 均包 含在本发明的保护范围内。

Claims

权 利 要 求
1、 一种实现媒体流交互的方法， 欲交互媒体流的两端所在媒体承载网为 IP网域， 其中至少一个 IP网域为需要通过网络转换设备映射地址的私网， 其 特征在于， 该方法包括：
媒体网关控制器 MGC获取私网中的媒体网关 MG本地媒体地址所对应的
MGC将所述公网地址发送给所 亍端； 所 亍端根据所述公网地址实现与 私网中的 MG的媒体流交互。
2、 根据权利要求 1所述的方法， 其特征在于， 所述 MGC获取私网中的 MG本地媒体地址所对应的公网地址的过程包括：
所述 MGC给所述 MG发送上报公网地址的指示；所述 MG根据接收到的 指示上 ^艮用于作为对端的远端地址的所述公网地址， 所述 MGC从接收到的上 报信息中获取所述公网地址； 或者，
所述 MG接收到来自 MGC的进行穿越并且应答目的地址为 MGC的指示 后，发起穿越协议消息，该消息中包含指定应答消息发送到所述 MGC的信息； 所述 MGC根据接收到的穿越协议消息应答获取所述公网地址； 或者 ,
所述 MG主动发起穿越协议消息 ,该消息中包含指定应答消息发送到所述 MGC的信息； 所述 MGC根据接收到的穿越协议消息应答获取所述公网地址： 或者，
所述 MG主动发起穿越协议消息，上报从应答中获得的用于作为对端的远 端地址的所述公网地址 ,所述 MGC从接收到的上 信息中获取所述公网地址。
3、 根据权利要求 2所述的方法， 其特征在于， 所述私网中的 MG接收到 来自 MGC的上报公网地址的指示后， 进一步包括： 上报自身本地媒体的私网 地址 ,所述 MGC从接收到的上报信息中获取所述 MG本地媒体地址的私网地 址。
4、根据权利要求 3所述的方法， 其特征在于， 所述 MG接收到来自 MGC 的上报公网地址的指示， 上报用于作为对端的远端地址的所述公网地址过程 为： MG发起穿越协议消息， 获取用于作为对端的远端地址的公网地址， 将包 含所述公网地址的列表上报给 MGC, 所述 MGC从接收到的所述公网地址列 表中获取所述公网地址； 或者，
MG从自身已保存的信息中直接获取所述公网地址， 上报给所述 MGC。
5、 根据权利要求 4所述的方法， 其特征在于， 所述私网中的 MG将包含 公网地址的列表信息上报给 MGC的方式为：
通过扩展 H.248/MGCP事件的方式上报， 或者， 通过 H.248/MGCP应答 消息中本地 SDP上报， 或者， 通过扩展 H.248属性在应答消息中上报。
6、 根据权利要求 5所述的方法， 其特征在于，
所述通过扩展 H.248/MGCP事件的方式上报时， 将 SDP字符串作为该事 件中的一个参数进行上报，或者，直接将所需上报内容作为该事件的参数上报； 所述通过扩展 H.248属性在应答消息中上报时， 将 SDP字符串作为该属 性的值进行上报,或者，直接将所需上报内容作为一个或者多个属性进行上报。
7、 根据权利要求 4所述的方法， 其特征在于， 所述包含公网地址的列表 中还包括： 私网内 MG的本地媒体地址和 /或对应本媒体流的远端地址。
8、 根据权利要求 7所述的方法， 其特征在于，
所述包含公网地址的列表中包含至少一组公网地址信息；
当所述列表中包含一组以上公网地址时，本地媒体地址包括了多个本地私 网地址， 和 /或所述公网地址由 MG通过相同或不同的穿越方式获取， 且同一 个媒体私网地址对应一个或一个以上公网地址。
9、根据权利要求 8所述的方法， 其特征在于， MGC接收到所述公网地址 列表后，进一步包括： 从所述公网地址列表中选择出至少一个用于媒体交互公 网地址， 将所选择出的公网地址发送给对端。
10、 根据权利要求 2所述的方法， 其特征在于， 所述 MGC发送的上报公 网地址的指示中包括： 穿越方式标识， 和 /或穿越协议请求消息的目的地址和 端口， 和 /或发送穿越协议请求消息的源地址， 和 /或穿越协议消息是否使用加 密方式， 和 /或是否所述对端具备 STUN服务器的功能；
所述穿越协议请求消息的目的地址和端口包括 STUN服务器的地址和端 口， TURN服务器的地址和端口， RSIP服务器的地址和端口。
11、 根据权利要求 10所述的方法， 其特征在于， 所述 MGC发送的上报 公网地址的指示中进一步包括一个或者多个网络转换设备的类型；
所述类型包括 Full Cone ^ Restricted Cone ^ Port Restricted Cone 和 Symmetric;
所述网络转换设备的类型的设置方式包括属性， 信号， 信号参数， 事件参 数和在 SDP中描述的方式。
12、 根据权利要求 2 所述的方法， 其特征在于， 所述 MG 直接通过 H.248/MGCP应答消息中的本地 SDP上报公网地址，或者， MG才 据接收到的 来自 MGC的通过 H.248/MGCP应答消息中的本地 SDP进行上报的指示， 采 用 H.248/MGCP应答消息中的本地 SDP上报公网地址。
13、 根据权利要求 2或 10所述的方法， 其特征在于， 所述 MGC发送的 的上报公网地址的指示中进一步包括 MG是否通过 H.248/MGCP应答消息中 的本地 SDP进行上报的指示； 该指示的设置的方式包括属性， 信号， 信号参 数， 事件参数和在 SDP中描述的方式。
14、 根据权利要求 4所述的方法， 其特征在于， 所述 MGC发送的上报公 网地址的指示中包含一种穿越方式标识；
所述私网中的 MG发送穿越协议消息的过程包括：选择所述穿越方式标识 中所指定的穿越方式发送穿越协议消息。
15、 根据权利要求 4所述的方法， 其特征在于， 所述 MGC发送的上报公 网地址的指示中包含至少两种穿越方式标识；
所述私网中的 MG发送穿越协议消息的过程包括： 根据 MG 自身的策略 发送至少一个穿越协议消息，根据接收到的应答选择所述上报公网地址的指示 中的一个或一个以上作为当前的穿越方式。
16、根据权利要求 14或 15所述的方法， 其特征在于， 所述穿越方式标识 的设置方式包括属性， 信号， 信号参数， 事件参数和在 SDP中描述的方式。
17、 根据权利要求 4所述的方法， 其特征在于， 所述 MGC发送的上报公 网地址的指示中未包含穿越方式标识； 所述私网中的 MG发送穿越协议消息的过程包括:选择自身默认配置的穿 越方式， 发送穿越协议消息。
18、根据权利要求 15或 17所述的方法， 其特征在于， 如果 MG本地单个 媒体私网地址映射为一个以上公网地址，且所述 MG上·¾该多个公网地址；则 MGC从所述公网地址中选择一个或者多个公网地址传递到所述对端。
19、 根据权利要求 14、 15或 17所述的方法， 其特征在于， 所述穿越方式 包括 STUN方式、 和 /或 TURN方式， 和 /或 RSIP方式。
20、根据权利要求 19所述的方法，其特征在于， 当所述穿越方式为 STUN 方式， 且通过 MG上报所述公网地址时， 所述私网内的 MG获取用于作为对 端的远端地址的公网地址的过程包括：
私网内的 MG发送 STUN请求， 所述 STUN请求被所述网络转换设备转 发到 STUN服务器；该转发的消息的源地址为网络转换设备为所述私网内 MG 的本地地址所映射的公网地址；
STUN服务器通过 NAT返回应答， 该返回的应答中携带网络转换设备为 该私网内的 MG的本地地址所映射的公网地址；
私网内的 MG从接收到的应答中获取所述 MG的本地地址所映射的公网 地址， 将其作为对端的远端地址的公网地址。
21、根据权利要求 20所述的方法，其特征在于，所述对端与所述 STUN服 务器拥有相同或不同的 IP地址和端口。
22、根据权利要求 19所述的方法，其特征在于， 当所述穿越方式为 TURN 方式时，所述私网内的 MG获取用于作为对端的远端地址的公网地址的过程包 括：
私网内的 MG发送 TURN请求 , 所述 TURN请求被所述网络转换设备转 发到 TURN服务器；
TURN服务器通过网络转换设备返回应答， 该返回的应答中携带 TURN 服务器为本次请求分配的公网地址；
私网内的 MG从接收到的应答中获取 TURN服务器为本次请求分配的公 网地址， 将其作为对端的远端地址的公网地址。
23、 根据权利要求 19所述的方法， 其特征在于， 当所述穿越方式为 RSIP 方式时，所述私网内的 MG获取用于作为对端的远端地址的公网地址的过程包 括：
私网内的 MG发送 RSIP请求， 接收到该请求的 RSIP服务器为其返回应 答， 该应答中包含为其分配公网地址；
私网内的 MG从接收到的应答中获取 RSIP服务器为其分配的公网地址， 将其作为对端的远端地址的公网地址。
24、 根据权利要求 1所述的方法， 其特征在于， 所述另一个 IP域为公网 域， 或为需要通过网络转换设备映射地址的不同于前述一 IP域的私网域， 或 为与前述一 IP域相同的私网域。
25、 根据权利要求 24所述的方法， 其特征在于， 当所述另一个 IP域也是 私网域， 而且两端都是 MG时， 所述私网中的 MG包括两端的 MG;
所述 MGC将分别获取两端的用于作为对端的远端地址的公网地址， 并分别 发送给所 亍端 , 所述两端通过所述两个公网地址实现媒体流交互。
26、根据权利要求 1所述的方法， 其特征在于， 所述网络转换设备为网络 地址转换设备 NAT或网络地址端口转换设备 NAPT或 RSIP设备。
27、 根据权利要求 2所述的方法， 其特征在于， 所述 MGC发送指示是通 过信号， 属性， 事件， 信号参数， 事件参数或者在 SDP中描述的方式下发。
28、根据权利要求 1所述的方法， 其特征在于， 所述私网内的 MG的对端 包括 SIP终端、 H323终端、 MG或者电路域交换网络或者分组域交换网络。
29、根据权利要求 1所述的方法， 其特征在于， 所述穿越包括 NAT穿越， NAPT穿越和 RSIP穿越。
30、根据权利要求 2所述的方法，其特征在于，所述 MG接收到来自 MGC 的进行穿越并且应答目的地址为 MGC的指示后， 发起穿越协议消息， 发起的 所述穿越协议消息是 STUN 的 绑定请求 binding request消息， 该请求消息指 定 STUN服务器将应答消息发送到 MGC的指定地址。
31、根据权利要求 30所述的方法， 其特征在于， MGC指示网关发送多个 STUN绑定请求消息， 让 MGC从应答消息中获得多个本地媒体地址被 NAT 或 NAPT映射的公网地址；
同一个呼叫中过程中使用所述多个本地媒体地址进行媒体流交互。
32、根据权利要求 1所述的方法， 其特征在于， 所述本地媒体地址包括本 地媒体的 IP地址， 或者， 本地媒体的 IP地址和端口号； 所述公网地址包括公 网的 IP地址， 或者， 公网的 IP地址和端口号。
33、 根据权利要求 1所述的方法， 其特征在于， 该方法进一步包括： 所述 MGC指示 MG进行联通性检测；
所述联通性检测的方法为发送 STUN绑定请求消息。
34、 根据权利要求 1所述的方法， 其特征在于， 该方法进一步包括： 所述 MGC指示 MG上报 NAT或 NAPT的绑定生命周期，和 /或者指示网关检测 NAT 或 NAPT的绑定生命周期。
35、根据权利要求 1所述的方法， 其特征在于， 所述媒体流中承载的媒体 包括 RTP "¾文， RTCP ^ , TCP媒体报文和 UDPTL媒体报文。
36、一种实现媒体流交互的系统，欲交互媒体流的两端所在媒体承载网为 IP网域， 其中至少一个 IP网域为需要通过网络转换设备映射地址的私网域， 该系统包括： 媒体网关控制器 MGC, 私网中的媒体网关 MG以及需要与所述 私网中的 MG进行媒体流交互的对端； 其特征在于，
所述 MGC内还包括：
公网地址获取单元，用于获取私网中的媒体网关 MG本地媒体地址所对应 的公网地址， 将所述公网地址发送给所述公网地址传送单元； 所述公网地址是 用于作为所述 MG对端的远端地址的公网地址；
公网地址传送单元， 用于将接收到的所述公网地址发送给所 亍端； 所述私网 MG中还包括：
公网地址上报单元， 用于根据接收到来自 MGC的上报公网地址的指示， 发起穿越协议消息，获取用于作为对端的远端地址的公网地址，将包含所述公 网地址的列表上报给 MGC; 或者， 从自身已保存的信息中直接获取所述公网 地址， 上报给所述 MGC。
37、 根据权利要求 36所述的系统， 其特征在于， 所述 MGC中的公网地 址获取单元内包括： 指示下发单元， 信息获取单元；
所述指示下发单元， 用于给所述 MG发送上报公网地址的指示； 或者， 用 于给所述 MG发送进行穿越并且应答目的地址为 MGC的指示；
所述信息获取单元，用于从接收到的来自 MG的上报信息中获取所述公网 地址； 或者， 用于根据接收到的穿越协议消息应答获取所述公网地址。
38、 根据权利要求 37所述的系统， 其特征在于，
所述信息获取单元 ,进一步用于从接收到的上 信息中获取所述 MG本地 媒体地址的私网地址。
39、 根据权利要求 37所述的系统， 其特征在于， 所述 MGC中指示下发 单元发送的上报公网地址的指示中包括： 穿越方式标识， 和 /或穿越协议请求 消息的目的地址和端口， 和 /或发送穿越协议请求消息的源地址， 和 /或穿越协 议消息是否使用加密方式， 和 /或是否所述对端具备 STUN服务器的功能； 所述穿越协议请求消息的目的地址和端口包括 STUN服务器的地址和端 口， TURN服务器的地址和端口， RSIP服务器的地址和端口。
40、 根据权利要求 39所述的系统， 其特征在于， 所述 MGC中的指示下 发单元发送的上报公网地址的指示中进一步包括一个或者多个网络转换设备 的类型；
所述类型包括 Full Cone ^ Restricted Cone ^ Port Restricted Cone 和 Symmetric;
所述网络转换设备的类型的设置的方式包括属性， 信号， 信号参数， 事件 参数和在 SDP中描述的方式。
41、 根据权利要求 39或 40所述的系统， 其特征在于， 所述 MGC中的指 示下发单元发送的上报公网地址的指示中进一步包括 MG 是否通过 H.248/MGCP应答消息中的本地 SDP进行上报的指示； 该指示的设置的方式 包括属性， 信号， 信号参数， 事件参数和在 SDP中描述的方式。
42、 根据权利要求 37所述的方法， 其特征在于， 所述 MGC中指示下发 单元发送的指示是通过信号， 属性， 事件， 信号参数， 事件参数或者在 SDP 中描述的方式下发。
43、 ^居权利要求 36所述的系统， 其特征在于， 所述 MG中的公网地址 上报单元上报公网地址列表或公网地址的方式为：直接通过 H.248/MGCP应答 消息中的本地 SDP上报， 或者，根据接收到的来自 MGC的通过 H.248/MGCP 应答消息中的本地 SDP进行上报的指示， 采用 H.248/MGCP应答消息中的本 地 SDP上报。
44、 根据权利要求 36所述的系统， 其特征在于， 所述网络转换设备为网 络地址转换设备 NAT或网络地址端口转换设备 NAPT或 RSIP设备。
45、 根据权利要求 36所述的系统， 其特征在于， 所述私网内的 MG的对 端包括 SIP终端、 H323终端、 MG、 电路域交换网络或者分组域交换网络。
46、 一种媒体网关控制器， 其特征在于， 包括： 公网地址获取单元和公网 地址传送单元；
所述公网地址获取单元 ,用于获取私网中的媒体网关 MG本地媒体地址所 对应的公网地址， 将所述公网地址发送给所述公网地址传送单元； 所述公网地 址是用于作为所述 MG对端的远端地址的公网地址；
所述公网地址传送单元， 用于将接收到的所述公网地址发送给所 亍端。
47、 根据权利要求 46所述的媒体网关控制器， 其特征在于， 所述 MGC 中的公网地址获取单元内包括： 指示下发单元， 信息获取单元；
所述指示下发单元， 用于给所述 MG发送上报公网地址的指示； 或者， 用 于给所述 MG发送进行穿越并且应答目的地址为 MGC的指示；
所述信息获取单元，用于从接收到的来自 MG的上报信息中获取所述公网 地址； 或者， 用于根据接收到的穿越协议消息应答获取所述公网地址。
48、 根据权利要求 47所述的媒体网关控制器， 其特征在于，
所述信息获取单元，进一步用于从接收到的上报信息中获取所述 MG本地 媒体地址的私网地址。
49、 一种私网内的媒体网关， 其特征在于， 包括：
公网地址上报单元， 用于根据接收到来自 MGC的上报公网地址的指示， 发起穿越协议消息，获取用于作为对端的远端地址的公网地址，将包含所述公 网地址的列表上报给 MGC; 或者， 从自身已保存的信息中直接获取所述公网 地址， 上^艮给所述 MGC。
50、 根据权利要求 49所述的媒体网关， 其特征在于， 所述 MG中的公网 地址上报单元上报公网地址列表或公网地址的方式为： 直接通过 H.248/MGCP 应答消息中的本地 SDP 上报， 或者， 根据接收到的来自 MGC 的通过 H.248/MGCP应答消息中的本地 SDP进行上报的指示， 采用 H.248/MGCP应 答消息中的本地 SDP上报。
PCT/CN2007/070157 2006-06-22 2007-06-21 Procédé et système pour réaliser une interaction de flux multimédia, contrôleur de passerelle multimédia, et passerelle multimédia WO2008000188A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP07721775A EP2034666B1 (en) 2006-06-22 2007-06-21 Method and system for realizing media stream interaction and media gateway controller and media gateway
US12/338,223 US20090097477A1 (en) 2006-06-22 2008-12-18 Method and system for realizing media stream interaction and media gateway controller and media gateway

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN200610090061.7 2006-06-22
CN200610090061 2006-06-22
CN200610099246.4 2006-07-21
CN200610099246.4A CN101094171B (zh) 2006-06-22 2006-07-21 实现媒体流交互方法和系统及媒体网关控制器和媒体网关

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/338,223 Continuation US20090097477A1 (en) 2006-06-22 2008-12-18 Method and system for realizing media stream interaction and media gateway controller and media gateway

Publications (1)

Publication Number Publication Date
WO2008000188A1 true WO2008000188A1 (fr) 2008-01-03

Family

ID=38845136

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2007/070157 WO2008000188A1 (fr) 2006-06-22 2007-06-21 Procédé et système pour réaliser une interaction de flux multimédia, contrôleur de passerelle multimédia, et passerelle multimédia

Country Status (4)

Country Link
US (1) US20090097477A1 (zh)
EP (1) EP2034666B1 (zh)
CN (1) CN101094171B (zh)
WO (1) WO2008000188A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2352260A1 (en) * 2008-10-30 2011-08-03 Huawei Technologies Co., Ltd. A method, device and system for performing network address translation

Families Citing this family (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101471965B (zh) * 2007-12-28 2012-01-04 华为技术有限公司 本地传输地址分配方法、媒体网关及媒体网关控制器
CN101552803B (zh) * 2008-04-03 2011-10-05 华为技术有限公司 网络地址转换地址映射表维护方法、媒体网关及其控制器
CN101336002B (zh) * 2008-07-29 2011-11-30 中兴通讯股份有限公司 一种媒体网关间的双音多频信号的参数协商方法及系统
TWI408936B (zh) * 2009-09-02 2013-09-11 Ind Tech Res Inst 網路穿透方法及網路通訊系統
CN102064994B (zh) * 2009-11-18 2013-12-18 中兴通讯股份有限公司 基于媒体网关控制协议识别网络电话流量的方法和装置
CN102075588B (zh) * 2009-11-24 2014-10-08 中国移动通信集团公司 一种实现网络地址转换nat穿越的方法、系统和设备
US8626174B2 (en) * 2009-12-09 2014-01-07 Telefonaktiebolaget L M Ericsson (Publ) Call switching in packet-based communication networks
US8606306B2 (en) 2010-04-07 2013-12-10 Apple Inc. Multiple client computing device invitations for online communication sessions
US8704863B2 (en) 2010-04-07 2014-04-22 Apple Inc. Transitioning between circuit switched calls and video calls
US8583149B2 (en) 2010-04-07 2013-11-12 Apple Inc. Registering email addresses for online communication sessions
US8751667B2 (en) 2010-04-07 2014-06-10 Apple Inc. Supporting hands-free services via a hands-free device for IP video calls
CN102316548A (zh) * 2010-07-07 2012-01-11 中兴通讯股份有限公司 信息传递方法和系统
GB2483282B (en) * 2010-09-03 2017-09-13 Advanced Risc Mach Ltd Data compression and decompression using relative and absolute delta values
US8484331B2 (en) * 2010-11-01 2013-07-09 Cisco Technology, Inc. Real time protocol packet tunneling
CN102143245B (zh) * 2010-12-01 2013-04-17 华为技术有限公司 Ip地址分配的控制方法及装置
CN103597863A (zh) * 2011-04-14 2014-02-19 中兴通讯(美国)公司 确定无线网络中的机器类型通信设备地址的方法和装置
WO2012109865A1 (zh) * 2011-07-30 2012-08-23 华为技术有限公司 私网与网外客户端之间呼叫的nat处理方法、设备和系统
CN102957618B (zh) * 2011-08-23 2017-03-29 中兴通讯股份有限公司 基于身份位置分离网络内服务器通讯方法、系统和服务器
US9742728B2 (en) 2011-08-30 2017-08-22 Sonus Networks, Inc. Determining expiration time of bindings for network address translation devices
JP2013196520A (ja) * 2012-03-21 2013-09-30 Fuji Xerox Co Ltd 組織属性推定装置及びプログラム
CN102611766A (zh) * 2012-04-09 2012-07-25 苏州工业园区云视信息技术有限公司 基于NAT实现两个VoIP实体媒体互通的方法
CN102984068B (zh) * 2012-11-23 2016-08-03 汉柏科技有限公司 实现报文穿越网络地址转换设备的方法
CN102984696B (zh) * 2012-12-04 2015-09-16 中国联合网络通信集团有限公司 基于移动终端的ip通信方法、设备和系统
CN103905669B (zh) * 2012-12-27 2016-01-20 中国移动通信集团公司 一种数据交换方法、系统及mgc
EP2782312A4 (en) * 2013-02-08 2015-04-08 Huawei Tech Co Ltd METHOD, DEVICE AND SYSTEM FOR REALIZING PRIVATE NETWORK TRAVERSATION
CN103414799B (zh) * 2013-07-31 2016-12-28 华为技术有限公司 中继地址互通方法和终端及系统
CN104660564A (zh) * 2013-11-22 2015-05-27 乐视网信息技术（北京）股份有限公司 一种建立节点之间连接关系的方法及服务器
CN104023206B (zh) * 2014-06-04 2017-06-13 浙江宇视科技有限公司 媒体流集中转发方法及装置
MX365073B (es) * 2014-10-29 2019-05-22 Kodiak Networks Inc Sistema y metodo para hacer uso de comunicacion web en tiempo real para implementar soluciones de presiona para hablar.
CN107241453B (zh) * 2016-03-28 2020-07-24 华为技术有限公司 一种网络地址转换映射保活方法及装置
CN106878259B (zh) * 2016-12-14 2020-12-11 新华三技术有限公司 一种报文转发方法及装置
CN108833513B (zh) * 2018-05-31 2021-01-26 中国联合网络通信集团有限公司 区块链节点间通信方法、装置及区块链节点
EP3588893B1 (en) * 2018-06-28 2023-03-08 Unify Patente GmbH & Co. KG Method and system for managing transmission resources in a sip-based communication system
CN108769292B (zh) * 2018-06-29 2021-04-13 北京百悟科技有限公司 报文数据处理方法及装置
US11689583B2 (en) * 2018-12-10 2023-06-27 Telefonaktiebolaget Lm Ericsson (Publ) Network node, entity and methods performed therein for handling a communication session in a communication network
CN110113675B (zh) * 2019-03-22 2021-07-02 西安电子科技大学 一种n2n-nrm视频共享系统及方法
US11956326B2 (en) * 2019-11-13 2024-04-09 Unify Patente Gmbh & Co. Kg Method of determining a location of a client in a private network and communication network
CN113098919B (zh) * 2020-01-09 2022-09-09 百度在线网络技术（北京）有限公司 一种节点间连通方法、装置、电子设备和存储介质
CN114553843A (zh) * 2022-01-28 2022-05-27 号百信息服务有限公司 实现视频单通兼话音双通的方法、装置及电子设备
CN114900502B (zh) * 2022-05-17 2024-02-27 北京奇艺世纪科技有限公司 网络注册方法、装置、电子设备及可读存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6006272A (en) * 1998-02-23 1999-12-21 Lucent Technologies Inc. Method for network address translation
CN1411220A (zh) * 2001-10-04 2003-04-16 华为技术有限公司 私有网络的ip语音业务实现方法及系统
US20030233471A1 (en) 2002-06-17 2003-12-18 Julian Mitchell Establishing a call in a packet-based communications network
CN1474566A (zh) * 2002-08-09 2004-02-11 华为技术有限公司 基于媒体网关控制协议的媒体网关间实现语音通信的方法
CN1571440A (zh) * 2003-07-25 2005-01-26 中兴通讯股份有限公司 一种跨越私网实现多媒体呼叫的系统和方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6687245B2 (en) * 2001-04-03 2004-02-03 Voxpath Networks, Inc. System and method for performing IP telephony
US7333500B2 (en) * 2002-09-24 2008-02-19 Nortel Networks Limited Methods for discovering network address and port translators
US20040064584A1 (en) * 2002-09-27 2004-04-01 Julian Mitchell Apparatus and methods of assisting in NAT traversal
US7620033B2 (en) * 2004-05-21 2009-11-17 Alcatel-Lucent Usa Inc. Method for optimal path selection in traversal of packets through network address translators
US7570636B2 (en) * 2004-06-29 2009-08-04 Damaka, Inc. System and method for traversing a NAT device for peer-to-peer hybrid communications
US7543064B2 (en) * 2004-09-30 2009-06-02 Logitech Europe S.A. Multiplayer peer-to-peer connection across firewalls and network address translators using a single local port on the local host

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6006272A (en) * 1998-02-23 1999-12-21 Lucent Technologies Inc. Method for network address translation
CN1411220A (zh) * 2001-10-04 2003-04-16 华为技术有限公司 私有网络的ip语音业务实现方法及系统
US20030233471A1 (en) 2002-06-17 2003-12-18 Julian Mitchell Establishing a call in a packet-based communications network
CN1474566A (zh) * 2002-08-09 2004-02-11 华为技术有限公司 基于媒体网关控制协议的媒体网关间实现语音通信的方法
CN1571440A (zh) * 2003-07-25 2005-01-26 中兴通讯股份有限公司 一种跨越私网实现多媒体呼叫的系统和方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
See also references of EP2034666A4
STERMAN B ET AL.: "annual review of communications, national engineering consortium", NAT TRAVERSAL IN SIP, vol. 56, 1 January 2002 (2002-01-01), pages 779 - 786

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2352260A1 (en) * 2008-10-30 2011-08-03 Huawei Technologies Co., Ltd. A method, device and system for performing network address translation
EP2352260A4 (en) * 2008-10-30 2011-08-10 Huawei Tech Co Ltd METHOD, DEVICE AND SYSTEM FOR NETWORK ADDRESS TRANSLATION

Also Published As

Publication number Publication date
EP2034666B1 (en) 2012-12-05
US20090097477A1 (en) 2009-04-16
CN101094171A (zh) 2007-12-26
CN101094171B (zh) 2011-02-16
EP2034666A1 (en) 2009-03-11
EP2034666A4 (en) 2009-07-01

Similar Documents

Publication Publication Date Title
WO2008000188A1 (fr) Procédé et système pour réaliser une interaction de flux multimédia, contrôleur de passerelle multimédia, et passerelle multimédia
EP2048832B1 (en) Method and system for connecting a media stream
EP1650916B1 (en) The system and method for realize multimedia call crossover the private network
JP5972398B2 (ja) Ｉｃｅベースｎａｔトラバーサル
EP2117190B1 (en) Method, system and device for realizing network address translation passing
KR101280281B1 (ko) 일련의 경계 게이트웨이들을 통하는 ｉｐ 멀티미디어 베어러 경로 최적화를 위한 개선된 방법 및 시스템
TWI408936B (zh) 網路穿透方法及網路通訊系統
WO2005062546A1 (fr) Procede de conversion et de traversee d&#39;une adresse reseau et son systeme
US7694127B2 (en) Communication systems for traversing firewalls and network address translation (NAT) installations
WO2007036160A1 (fr) Appareil, systeme et procede assurant la communication entre un client et un serveur
US20030233471A1 (en) Establishing a call in a packet-based communications network
US20050286538A1 (en) Method and call server for establishing a bi-directional peer-to-peer communication link
WO2015096302A1 (zh) 基于sip媒体能力重协商的nat穿越方法、代理服务器和系统
WO2010045809A1 (zh) 一种实现网络地址转换的方法、媒体网关和网络系统
KR100607993B1 (ko) 이종 네트워크간 통신 시스템 및 방법
WO2011015067A1 (zh) 实现媒体控制流报文穿越网络地址转换器的方法及系统
EP2509284B1 (en) Method and system for allocating local transport address, media gateway and media gateway controller
WO2007143920A1 (fr) Procédé et dispositif de commande de ressources de supports, procédé et système d&#39;établissement d&#39;appel
WO2008003214A1 (fr) Procédé, dispositif et système de passage de flux multimédia à travers la traduction d&#39;adresse de réseau
WO2006116933A1 (fr) Procede, systeme et equipement de realisation d&#39;une intercommunication entre les domaines ip
KR100438182B1 (ko) 게이트키퍼와 ｎａｔ－ｐｔ 연동을 위한 서로 상이한ｉｐ 주소 연동 방법
WO2008046302A1 (fr) Procédé, système et entité de réseau pour l&#39;obtention d&#39;informations de capacité d&#39;un protocole de description de session
WO2023016177A1 (zh) 一种呼叫处理方法、装置及系统
JP2003060711A (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: 07721775

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2007721775

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

NENP Non-entry into the national phase

Ref country code: RU