[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

CN1937620A - 一种媒体流传输地址的协商方法 - Google Patents

一种媒体流传输地址的协商方法 Download PDF

Info

Publication number
CN1937620A
CN1937620A CN200510106295.1A CN200510106295A CN1937620A CN 1937620 A CN1937620 A CN 1937620A CN 200510106295 A CN200510106295 A CN 200510106295A CN 1937620 A CN1937620 A CN 1937620A
Authority
CN
China
Prior art keywords
equipment
address
message
code
sdp
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN200510106295.1A
Other languages
English (en)
Inventor
徐培利
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
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 CN200510106295.1A priority Critical patent/CN1937620A/zh
Priority to PCT/CN2006/002495 priority patent/WO2007033606A1/zh
Publication of CN1937620A publication Critical patent/CN1937620A/zh
Pending legal-status Critical Current

Links

Images

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/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了一种媒体流传输地址的协商方法，该方法由第一设备向第二设备发送包含会话描述协议(SDP)信息的消息，在该SDP信息中针对第一设备希望建立的媒体流的部分或全部编解码格式分别指定有对应的传输地址；第二设备从接收到的消息的SDP信息中获取希望建立的媒体流的各编解码格式及对应的传输地址，确定本设备希望的编解码格式并返回包含该编解码格式及对应的传输地址的SDP信息的响应消息。

Description

一种媒体流传输地址的协商方法
技术领域
本发明涉及通信技术领域，尤其涉及基于会话描述协议(SDP)媒体流传输地址的协商方法。
背景技术
目前基于IP网络的多媒体业务正在得到越来越广泛的应用。从技术上来讲，该业务的实现主要包含信令控制部分、媒体处理及传输两个方面。其中信令部分用于在通信实体之间建立会话关系，并且完成双方通信参数的协商。媒体处理部分主要根据信令协商的结果采用特定的媒体流打包和传输方式进行媒体流的通信。对于音频或者视频等实时媒体流的传输主要采用实时传输协议(RTP协议)，对于电子白板等数据业务的媒体流传输则通常采用TCP等可以保证可靠传输的协议。
目前在信令协商过程中对媒体流参数的描述主要基于SDP协议，双方通过SDP协商完成通信地址，媒体流类型，编解码能力等参数的协商。其中通信地址协商的一般方法是：提供SDP的一方携带自己所支持的媒体流能力以及每一条媒体流所对应的通信地址。双方完成SDP协商后，媒体流就发送到指定的地址。
SDP协议是基于文本的媒体能力描述协议，它采用“属性名＝参数...”的方式来描述通信实体的媒体能力。主要定义如下：
Session description
       v＝(protocol version)
       o＝(owner/creator and session identifier)
       s＝(session name)
     c＝*(connection information-not required if included in all media)
     Zero or more media descriptions(see below)
Media description
     m＝(media name and transport address)
     c＝*(connection information-optional if included at session-level)
     a＝*(zero or more media attribute lines)
其中和媒体流通信地址相关的参数说明如下：
c＝<network type><address type><connection address>
可用于表示连接地址的通常是IPV4，IPV6或者域名(不包括传输层端口号)，如果“c＝”属性行放在SDP的会话描述部分，则对后续的所有媒体流都有效，除非某条媒体流拥有自己的“c＝”属性；如果“c＝”属性行放在SDP的媒体描述部分则表示该地址只针对他所对应的特定的那条媒体流(m行)有效。
SIP协议中定义了如何利用SDP来进行媒体能力(包括媒体通信地址)协商的方法，其典型过程如下(省略了与本发明不相关的头域)：
步骤1：主叫SIP用户(a@domain.com)通过INVITE消息向被叫(b@domain.com)发起会话请求，其中包含主叫的媒体能力(包括媒体通信地址)。消息如下：
INVITE sip：b@domain.com SIP/2.0
    From：a<sip：a@domain.com>；tag＝1234567
    To：b<sip：b@domain.com>
    Content-Type：application/sdp
    Content-Length：...
    v＝0
    o＝a 2890844526 2890844526 IN IP4 10.0.0.1
    s＝Session SDP
    c＝IN IP4 10.0.0.1
     t＝0 0
     m＝audio 49170 RTP/AVP 0
其中c行的信息表示，主叫的媒体流接收地址是10.0.0.1；m行的信息表示，主叫希望建立一条音频媒体流，编解码是0(PCMU)，该媒体的接收端口号是49170。也就是说，主叫方希望对端将媒体流发送到端口号为49170，IP地址为10.0.0.1的地址。
步骤2：被叫SIP用户(b@domain.com)接收到INVITE后如果愿意接受本次呼叫，则通过200 OK消息向被叫(b@domain.com)应答，其中包含被叫的媒体能力。消息如下：
SIP/2.0 200 OK
      From：a<sip：a@domain.com>；tag＝1234567
      To：b<sip：b@domain.com>；tag＝137480
      Content-Type：application/sdp
      Content-Length：...
      v＝0
      o＝b 4702834 3847012 IN IP4 10.0.0.2
      s＝Session SDP
      c＝IN IP4 10.0.0.2
      t＝0 0
      m＝audio 1234 RTP/AVP 0
其中c行的信息表示，被叫的媒体流接收地址是10.0.0.2；m行的信息表示，被叫同意建立一条音频媒体流，编解码是0(PCMU)，该媒体的接收端口号是1234。也就是说，被叫方希望对端将媒体流发送到端口号为1234，IP地址为10.0.0.2的地址。
步骤3：主叫SIP用户(a@domain.com)接收到200后向被叫发送一个ACK消息表示确认收到了200 OK。消息如下：
ACK b@domain.com SIP/2.0
     From：a<sip：a@domain.com>；tag＝1234567
     To：b<sip：b@domain.com>；tag＝137480
步骤4：以上过程完成后，主被叫双方完成会话建立和媒体协商过程，各自根据协商确定的媒体流参数分别向对端提供的用于媒体流传输的IP地址和端口号发送媒体流。
在现有流程中，双方进行媒体流打包时长能力协商是通过SDP协议中定义的m＝行，c＝行携带的参数完成的，其语法格式如下：
m＝<media><port><transport><fmt list>
其中<port>表示一条媒体流所对应的媒体接收端口号；
c＝<network type><address type><connection address>
c＝行可用于表示本端连接地址，通常是IPV4，IPV6或者域名(注意：不包括传输层端口号)如果c＝放在SDP的会话描述部分，则对下面的所有媒体流(m行)都有效，除非某条媒体流拥有自己的c＝属性；如果c＝放在SDP的媒体描述部分则表示该地址只针对他所对应的特定的那条媒体流(m行)有效。
例如：
(1)多条媒体流共享一个连接地址的情况
    v＝0
    o＝b 4702834 3847012 IN IP4 10.0.0.2
    s＝Session SDP
    c＝IN IP4 10.0.0.2
    m＝audio 1234 RTP/AVP 0 4 8
    m＝video 5678 RTP/AVP 31 32
第一条媒体流的接收端口号是1234，第二条是5678，但IP地址都是10.0.0.2
(2)媒体流拥有自己的特定连接地址的情况
   v＝0
   o＝b 4702834 3847012 IN IP4 10.0.0.2
     s＝Session SDP
     c＝IN IP4 10.0.0.2
     m＝audio 1234 RTP/AVP 0 4 8
     c＝IN IP4 10.0.0.3
     m＝video 5678 RTP/AVP 31 32
第一条媒体流的接收端口号是1234，由于后面跟随着一个c＝行，因此它的IP地址是10.0.0.3；第二条媒体流的接收端口号是5678，IP地址由于后面没有用c＝特殊指定，则还是采用会话表示部分的c＝行表示的缺省连接地址10.0.0.2。
从上可知，目前的媒体流地址协商机制存在如下问题：
(1)由于在一条媒体流(m行)描述中只能填写一个端口号，因此，终端在一条媒体流可以支持多种编解码，并希望根据不同的编解码选择不同的接收端口下，利用现有的协商机制无法实现。
(2)由于一条媒体流(m行)只能采用一个c＝行表示连接地址参数，对于某一条媒体流，终端希望根据不同的编解码选择不同的IP地址来进行传输时，同样无法得到支持。
发明内容
本发明提供一种媒体流传输地址协商方法，以解决现有媒体流传输地址协商中无法支持针对媒体流的不同编解码格式指定传输地址的问题。
本发明提供以下技术方案：
一种媒体流传输地址的协商方法，包括如下步骤：
第一设备向第二设备发送包含会话描述协议(SDP)信息的消息，并且在该SDP信息中针对该第一设备需要建立的媒体流的部分或全部编解码格式分别指定对应的传输地址；
第二设备从接收到的消息的SDP信息中获取需要建立的媒体流的各编解码格式及对应的传输地址，确定本设备希望的编解码格式并返回包含该编解码格式及对应的传输地址的响应消息。
其中：
所述第二设备在接收到第一设备发送的消息或该消息的响应消息后，提供的本网络设备支持的编解码格式及对应的传输地址信息可以是唯一确定的一种编解码及其传输地址，也可一是本端所有支持的或者可能采用的多种编解码及其对应的传输地址。
第一设备与第二设备之间传送所述消息的网络设备在接收到第一设备发送的消息或该消息的响应消息后，将本网络设备支持媒体流的各编解码格式及对应的传输地址加入到消息的SDP信息中。
所述网络设备确定第二设备选择的编解码格式为第一设备支持的编解码格式，则直接在第一设备与第二设备之间建立希望的媒体流。
所述网络设备确定第二设备选择的编解码格式为本网络设备支持但第一设备不支持的编解码格式，则分别与第一设备和第二设备建立媒体流并完成编解码转换。
所述消息为SIP信令消息；或者，所述消息为MGCP信令消息；或者，所述消息为H.248信令消息。
在SDP的媒体描述部分扩展至少包含媒体流编解码格式的属性定义，由该属性定义描述编解码格式和对应的传输地址。
若所述属性定义中未显式的指定传输地址，则按SDP规范从相应的属性定义中获取。
本发明由于支持了基于编解码级别的传输地址协商，转换网关可以通过简单在SDP中添加自己所支持的编解码信息及其传输地址，以此来根据主被叫双方是否具有匹配的媒体能力达到灵活控制需要编解码转换的会话流程。
采用本发明，使采用基于SDP协议的SIP，MGCP，H.248协议的通信网络中的通信设备，能对媒体流中不同编解码所对应的媒体传输地址进行协商。
附图说明
图1为主叫与被叫之间协商媒体流地址的处理流程图；
图2为智能编解码转换网关参与会话媒体能力协商的示意图；
图3为主被叫能力不匹配的情况下媒体能力协商的流程图；
图4为主被叫能力匹配的情况下媒体能力协商的流程图。
具体实施方式
为了在一条媒体流可以支持多种编解码，并希望根据不同编解码选择不同传输地址的情况下，使参与媒体流传输的设备之间能够完成媒体流传输地址的协商，本发明在SIP消息所包含的会话描述协议(SDP)信息中，针对希望或愿意建立的媒体流的部分或全部编解码格式分别指定对应的传输地址，使参与协商的设备能够根据不同编解码格式选择相应的传输地址。
对于发起协商的一方，在SIP信令消息的SDP部分，针对希望建立的媒体流的部分或全部编解码格式分别指定对应的传输地址；接收SIP信令消息的一方，可以从中选择一种自己希望的编解码格式并通过响应消息通知对方，也可以在发送给对方的响应消息的SDP部分，针对愿意建立的媒体流的部分或全部编解码格式分别指定对应的传输地址，然后发起协商的一方选择一种希望的编解码格式并通知对方，对方给予确认。
一般情况下，位于两个不同网络域之间的边界网关(这里逻辑上包含信令互通和/或媒体互通的处理功能)可以具有编解码转换的功能，跨网络域的网关之间需要通过边界网关传送媒体流，当设备之间的媒体能力不匹配时可以通过媒体转换功能来完成会话的建立。因此，网关转发两个设备之间与媒体流地址协商相关的SIP消息时，在向该消息中添加自己支持的编解码时把自身新增的编解码对应的传输地址也添加到消息中。如果选择编解码格式的一方设备选择了不支持另一端设备的编解码格式，则选择的是转换网关所提供的编解码格式，由于转换网关新增的编解码对应的是它的传输地址，因此选择编解码格式的一方设备就会建立和转换网关之间的媒体连接，由转换网关在设备之间完成编解码格式转换；如果选择的是另一端设备支持的编解码格式(这时不需要进行转换)，则设备之间直接建立媒体连接。
本发明在SDP的媒体描述部分扩展至少包含媒体流编解码格式的定义行，由该定义行描述编解码格式和对应的传输地址。根据设备的编解码格式，一条媒体流的描述可以有一个或多个这样的定义行。
本实施例以SIP会话建立过程的媒体能力协商为例对本发明进行详细说明，在后续的描述的消息示例中省略了与本发明有关编解码格式及传输地址定义不相关的头域。
本实施例中，采用如下方式扩展SDP协议中针对媒体流地址信息的描述，来表示某一种特定的编解码所采用的地址信息：
a＝fmtp：<format>[addrtype＝<addrtype>][c＝<connection attribute>][port＝<port>]
其中addrtype可以指定本地址是rtp，rtcp或者其他类型，如果不填默认为是该媒体流的缺省地址类型。
其中“c＝”的格式可以沿用RFC2327中针对“c＝”行的语法定义；该“c＝”是可选的，如果不填则表示该编解码对应的传输地址仍根据原有SDP规范从SDP的“c＝”行中获取；其中“port＝”也是可选的，如果不填则表示该编解码对应的端口号仍根据原有SDP规范从对应m＝行中获取。
例如：
m＝audio 1234 RTP/AVP 0 4 8 18；
c＝IN IP4 10.0.0.0；
a＝fmtp：0 c＝IN IP4 10.0.0.1 port＝1235//指定该编解码有特定的连接地址和端口；
a＝fmtp：0 addrtype＝rtcp c＝IN IP4 10.0.0.1 port＝1236//指定该编解码有特定的rtcp连接地址和端口号；
a＝fmtp：4 c＝IN IP4 10.0.0.2//指定该编解码有特定的连接地址；
a＝fmtp：8 port＝5678//指定该编解码有特定的端口号。
参阅图1所示，典型的主叫与被叫之间协商媒体流地址的处理流程如下：
步骤1：主叫SIP用户(a@domain.com)通过INVITE消息向被叫(b@domain.com)发起会话请求，其中包含主叫的媒体能力(包括媒体通信地址)。消息如下：
      INVITE sips：b@domain.com SIP/2.0
      From：a<sip：a@domain.com>；tag＝1234567
      To：b<sip：b@domain.com>
      Content-Type：application/sdp
      Content-Length：...
      v＝0
      o＝a 2890844526 2890844526 IN IP4 10.0.0.1
      s＝Session SDP
      c＝IN IP4 10.0.0.1
      t＝0 0
      m＝audio 49170 RTP/AVP 0 4 8
      a＝fmtp：0 port＝50000
      a＝fmtp：8 port＝55000
其中c行的信息表示，主叫的媒体流接收地址是10.0.0.1；m行的信息表示，主叫希望建立一条音频媒体流，编解码可以是0(PCMU)，4(G.723)，8(PCMA)，该媒体的缺省接收端口号是49170。下面的a＝行分别另行指定了编解码0(PCMU)的接收端口号是50000，编解码8(PCMA)的接收端口号是55000。而编解码4(G.723)未特别指定所以端口号还是采用该媒体流的缺省端口号49170。
步骤2：被叫SIP用户(b@domain.com)接收到INVITE后如果愿意接受本次呼叫，则通过200 OK消息向被叫(b@domain.com)应答，其中包含被叫的媒体能力。消息如下：
     SIP/2.0 200 OK
     From：a<sip：a@domain.com>；tag＝1234567
     To：bsip：b@domain.com>；tag＝137480
     Content-Type：application/sdp
     Content-Length：...
     v＝0
     o＝b 4702834 3847012 IN IP4 10.0.0.2
     s＝Session SDP
     c＝IN IP4 10.0.0.2
     t＝0 0
     m＝audio 1234 RTP/AVP 0
其中c行的信息表示，被叫的媒体流接收地址是10.0.0.2；m行的信息表示，被叫同意建立一条音频媒体流，编解码是0(PCMU)，该媒体的接收端口号是1234。也就是说，被叫方希望对端将媒体流发送到端口号为1234，IP地址为10.0.0.2的地址。
步骤3：主叫SIP用户(a@domain.com)接收到200后向被叫发送一个ACK消息表示确认收到了200 OK。消息如下：
  ACK b@domain.com SIP/2.0
   From：a<sip：a@domain.com>；tag＝1234567
   To：b<sip：b@domain.com>；tag＝137480
步骤4：以上过程完成后，主被叫双方完成会话建立和媒体协商过程，各自根据协商确定的媒体流参数分别向对端提供的用于媒体流传输的IP地址和端口号发送媒体流。
上述协商后，被叫选择的是编解码0(PCMU)，根据主叫提供的SDP信息，它应该将媒体流发送到主叫的50000号端口。如果被叫选择编解码8(PCMA)，那就应该发送到主叫的55000端口。
下面以智能编解码转换网关参与会话媒体能力协商的应用为实施例进行说明，参阅图2所示。
由于在SDP描述部分能够描述具体的每个编解码的特定传输地址，因此转换网关在向SIP消息添加自己支持的编解码时把自身新增的编解码对应的传输地址也添加进来。当主叫和被叫的媒体能力不匹配时可以通过媒体转换功能来完成会话的建立，例如：主叫支持codec1；被叫支持codec2，而转换网关支持两者之间的转换，那么实际的媒体通道建立情况是主叫将codec1的媒体发送给网关转换为codec2之后转发给被叫，反之亦然。而如果两者能力匹配则可以不需要进行编解码转换，媒体流仍然可以直接在主被叫之间建立。
参阅图3所示，对于主被叫能力不匹配的情况，其协商的主要流程如下(其中省略了与协商不相关的SIP和SDP消息头域)：
步骤1：主叫SIP用户(a@domain.com)通过INVITE消息向被叫(b@domain.com)发起会话请求，该消息经过转换网关，其中包含主叫侧的媒体能力(包括媒体通信地址)。消息如下：
    INVITE sip：b@domain.com SIP/2.0
    From：a<sip：a@domain.com>；tag＝1234567
    To：b<sip：b@domain.com>
    Content-Type：application/sdp
    Content-Length：...
    v＝0
    o＝a 2890844526 2890844526 IN IP4 10.0.0.1
    s＝Session SDP
    t＝0 0
    m＝audio 1234 RTP/AVP 0
    a＝frntp：0 c＝IN IP4 10.0.0.1
其中SDP的信息表示，主叫希望建立一条编解码为0(PCMU)的媒体流，其接收地址是10.0.0.1，端口是1234。
步骤2：转换网关向被叫侧转发该INVITE消息，但是考虑到由于主被叫双方能力不匹配而可能发生的编解码转换，转换网关在SDP中添加自己所支持的更多的编解码能力(包括媒体通信地址)。消息如下：
     INVITE sips：b@domain.com SIP/2.0
     From：a<sip：a@domain.com>；tag＝1234567
     To：b<sip：b@domain.com>
     Content-Type：application/sdp
     Content-Length：...
     v＝0
     o＝a 2890844526 2890844526 IN IP4 10.0.0.1
     s＝Session SDP
     t＝0 0
     m＝audio 1234 RTP/AVP 0 4
     a＝fmtp：0 c＝IN IP4 10.0.0.1
     a＝fmtp：4 c＝IN IP4 11.0.0.1 port＝2345
其中转换网关增加了自己所支持的编解码4(G.723)以及传输地址11.0.0.1端口号为2345。
步骤3：被叫SIP用户(b@domain.com)接收到INVITE后如果愿意接受本次呼叫，则通过200 OK消息向被叫(b@domain.com)应答，消息返回给转换网关。由于被叫只支持编解码4，因此它返回自己的媒体能力消息如下：
      SIP/2.0 200 OK
      From：a<sip：a@domain.com>；tag＝1234567
      To：b<sip：b@domain.com>；tag＝137480
      Content-Type：application/sdp
      Content-Length：...
     v＝0
     o＝b 4702834 3847012 IN IP4 10.0.0.8
     s＝Session SDP
     c＝IN IP4 10.0.0.8
     t＝0 0
     m＝audio 3456 RTP/AVP 4
其中c行的信息表示，被叫的媒体流接收地址是10.0.0.8；m行的信息表示，被叫同意建立一条音频媒体流，编解码是4(G.723)，该媒体的接收端口号是3456。也就是说，被叫方希望对端将媒体流发送到端口号为3456，IP地址为10.0.0.8的地址。
步骤4：转换网关向主叫SIP用户(a@domain.com)转发应答消息。由于被叫选择的是自己增加的编解码4，而主叫只支持编解码0，判断需要进行编解码转换，由于主叫只支持编解码0，因此它返回自己的分配的用于编解码转换的处理编解码0的媒体通道地址信息。消息如下：
     SIP/2.0 200 OK
     From：a<sip：a@domain.com>；tag＝1234567
     To：b<sip：b@domain.com>；tag＝137480
     Content-Type：application/sdp
     Content-Length：...
     v＝0
     o＝b 4702834 3847012 IN IP4 10.0.0.8
     s＝Session SDP
     c＝IN IP4 11.0.0.1
     t＝0 0
     m＝audio 4567 RTP/AVP 0
其中c行的信息表示，被叫的媒体流接收地址是11.0.0.1；m行的信息表示，被叫同意建立一条音频媒体流，编解码是0(PCMU)，该媒体的接收端口号是4567。也就是说，被叫方希望对端将媒体流发送到端口号为4567，IP地址为11.0.0.1的地址。
步骤5：主叫SIP用户(a@domain.com)接收到200后向被叫侧发送一个ACK消息表示确认收到了200 OK。消息发送给转换网关，如下：
ACK b@domain.com SIP/2.0
     Via：SIP/2.0/UDP a@domain.com：5061；branch＝z9hG4bK74bf9
     From：a<sip：a@domain.com>；tag＝1234567
     To：b<sip：b@domain.com>；tag＝137480
步骤6：转换网关向被叫转发ACK，消息如下：
ACK b@domain.com SIP/2.0
     From：a<sip：a@domain.com>；tag＝1234567
     To：b<sip：b@domain.com>；tag＝137480
步骤7：以上过程完成后，主被叫双方实际上分别和转换网关建立了媒体连接，主叫侧与转换网关之间采用编解码0，被叫侧与转换网关之间采用编解码4。
参阅图4所示，对于主被叫能力匹配的情况，其协商的主要流程如下(其中省略了与协商不相关的SIP和SDP消息头域)：
该处理流程与图3所示流程的差别在于，虽然转换网关增加了自己支持的能力，但是由于被叫侧和主叫侧之间具有共同的能力，因此被叫最终选择主叫支持的能力，从而直接建立与主叫之间的媒体连接。
步骤1-2：主叫->转换网关，转换网关->被叫的处理过程与图3流程中的处理相同。
步骤3：被叫SIP用户(b@domain.com)接收到INVITE后如果愿意接受本次呼叫，则通过200 OK消息向被叫(b@domain.com)应答，消息返回给转换网关。由于被叫支持编解码0，因此它返回自己的媒体能力消息如下：
   SIP/2.0 200 OK
     From：a<sip：a@domain.com>；tag＝1234567
     To：b<sip：b@domain.com>；tag＝137480
     Content-Type：application/sdp
     Content-Length：...
     v＝0
     o＝b 4702834 3847012 IN IP4 10.0.0.8
     s＝Session SDP
     c＝IN IP4 10.0.0.8
     t＝0 0
     m＝audio 3456 RTP/AVP 0
其中c行的信息表示，被叫的媒体流接收地址是10.0.0.8；m行的信息表示，被叫同意建立一条音频媒体流，编解码是0(PCMU)，该媒体的接收端口号是3456。也就是说，被叫方希望对端将媒体流发送到端口号为3456，IP地址为10.0.0.8的地址。
步骤4：转换网关向主叫SIP用户(a@domain.com)转发应答消息。由于被叫选择的不是自己增加的编解码4，而是主叫支持的编解码0，判断不需要进行编解码转换，它直接将被叫的SDP信息返回给主叫侧。消息如下：
     SIP/2.0 200 OK
      From：a<sip：a@domain.com>；tag＝1234567
      To：b<sip：b@domain.com>；tag＝137480
      Content-Type：application/sdp
      Content-Length：...
      v＝0
      o＝b 4702834 3847012 IN IP4 10.0.0.8
      s＝Session SDP
      c＝IN IP4 10.0.0.8
      t＝0 0
      m＝audio 3456 RTP/AVP 0
其中c行的信息表示，被叫的媒体流接收地址是10.0.0.8；m行的信息表示，被叫同意建立一条音频媒体流，编解码是0(PCMU)，该媒体的接收端口号是4567。也就是说，被叫方希望对端将媒体流发送到端口号为4567，IP地址为10.0.0.8的地址。
步骤5-6：主叫向被叫发送ACK消息。
步骤7：以上过程完成后，主被叫双方由于编解码能力一致，不需要由转换网关进行媒体转换，媒体流是直接在主被叫之间建立的。
本发明的方法同样适用于媒体设备支持多网络地址的应用。若主叫媒体处理设备是支持多IP地址的网关设备，不同的板卡提供对不同类型的编解码支持，不同的板卡提供不同的网络接口(具有独立的网络地址)。这时就需要在媒体能力协商过程中针对不同的编解码能力指定对应板卡的网络地址。同样也可以根据实现的策略来指定不同的端口号。如：
编解码0(PCMU)和8(PCMA)的连接地址为10.0.0.1
编解码4(G.723)的连接地址为10.0.0.2
编解码18(G.729)的连接地址为10.0.0.3
多网络地址应用中实现协商的流程如下(请参阅图1所示)：
步骤1：主叫SIP用户(a@domain.com)通过INVITE消息向被叫(b@domain.com)发起会话请求，其中包含主叫侧网关的媒体能力(包括媒体通信地址)。消息如下：
     INVITE sips：b@domain.com SIP/2.0
     From：a<sip：a@domain.com>；tag＝1234567
     To：b<sip：b@domain.com>
     Content-Type：application/sdp
     Content-Length：...
     v＝0
     o＝a 2890844526 2890844526 IN IP4 10.0.0.1
     s＝Session SDP
     t＝0 0
     m＝audio 1234 RTP/AVP 0 8 4 18
     c＝IN IP4 10.0.0.1
     a＝fmtp：4 c＝IN IP4 10.0.0.2
     a＝fmtp：8 c＝IN IP4 10.0.0.3
其中c行的信息表示，主叫的媒体流缺省接收地址是10.0.0.1；m行的信息表示，主叫希望建立一条音频媒体流，编解码可以是0(PCMU)，4(G.723)，8(PCMA)，18(G.729)。该媒体流的缺省接收端口号是1234。下面的a＝行分别另行指定了编解码4(G.723)的接收IP地址是10.0.0.2，编解码18(G.729)的接收IP地址是10.0.0.3。而编解码0(PCMU)，8(PCMA)未特别指定，所以IP地址还是采用该媒体流的缺省地址10.0.0.1。
步骤2：被叫SIP用户(b@domain.com)接收到INVITE后如果愿意接受本次呼叫，则通过200 OK消息向被叫(b@domain.com)应答，其中包含被叫的媒体能力。消息如下：
      SIP/2.0 200 OK
       From：a<sip：a@domain.com>；tag＝1234567
       To：b<sip：b@domain.com>；tag＝137480
       Content-Type：application/sdp
       Content-Length：...
       v＝0
       o＝b 4702834 3847012 IN IP4 10.0.0.8
       s＝Session SDP
       c＝IN IP4 10.0.0.8
       t＝0 0
       m＝audio 5678 RTP/AVP 0
其中c行的信息表示，被叫的媒体流接收地址是10.0.0.8；m行的信息表示，被叫同意建立一条音频媒体流，编解码是0(PCMU)，该媒体的接收端口号是1234。也就是说，被叫方希望对端将媒体流发送到端口号为1234，IP地址为10.0.0.2的地址。
步骤3：主叫SIP用户(a@domain.com)接收到200后向被叫发送一个ACK消息表示确认收到了200 OK。消息如下：
  ACK b@domain.com SIP/2.0
   From：a<sip：a@domain.com>；tag＝1234567
   To：b<sip：b@domain.com>；tag＝137480
步骤4：以上过程完成后，主被叫双方完成会话建立和媒体协商过程，各自根据协商确定的媒体流参数分别向对端提供的用于媒体流传输的IP地址和端口号发送媒体流。
对于被叫在响应消息中携带本端支持的多种或全部编解码格式及对应的传输地址的协商过程与上述同理，不再赘述。
上述虽然以SIP协议消息对本发明说明，但并不限于此，本发明同样适用于采用基于SDP协议的MGCP，H.248协议的通信网络中，通过MGCP或H.248协议实现与上述同理。本发明中关于编解码传输地址的协商过程可以是包含在相应的应用层协议(SIP，MGCP，H.248等)所允许的各种SDP协商场景过程中，这些过程包括但不限于：会话建立，会话修改，重新发起能力协商等。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若对本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1、一种媒体流传输地址的协商方法，其特征在于，包括如下步骤：
第一设备向第二设备发送包含会话描述协议(SDP)信息的消息，并且在该SDP信息中针对该第一设备需要建立的媒体流的部分或全部编解码格式分别指定对应的传输地址；
第二设备从接收到的消息的SDP信息中获取需要建立的媒体流的各编解码格式及对应的传输地址，并返回包含本设备希望的编解码格式及对应的传输地址的响应消息。
2、如权利要求1所述的方法，其特征在于，第二设备希望的编解码格式为第二设备支持的编解码格式中的部分或全部编解码格式。
3、如权利要求1所述的方法，其特征在于，第一设备与第二设备之间传送所述消息的网络设备在接收到第一设备发送的消息或该消息的响应消息后，将本网络设备支持媒体流的各编解码格式及对应的传输地址加入到消息的SDP信息中。
4、如权利要求3所述的方法，其特征在于，所述网络设备确定第二设备选择的编解码格式为第一设备支持的编解码格式，则直接在第一设备与第二设备之间建立希望的媒体流。
5、如权利要求3所述的方法，其特征在于，所述网络设备确定第二设备选择的编解码格式为本网络设备支持但第一设备不支持的编解码格式，则分别与第一设备和第二设备建立媒体流并完成编解码转换。
6、如权利要求1所述的方法，其特征在于，所述传输地址为IP地址；或者，所述的传输地址为端口号；或者，所述的传输地址为IP地址和端口号。
7、如权利要求1所述的方法，其特征在于，所述消息为SIP信令消息；或者，所述消息为MGCP信令消息；或者，所述消息为H.248信令消息。
8、如权利要求1所述的方法，其特征在于，第一设备与第二设备进行编解码传输地址的协商过程可以包含在相应的应用层协议所允许的各种SDP协商过程中。
9、如权利要求1至8任一项所述的方法，其特征在于，在SDP的媒体描述部分扩展至少包含媒体流编解码格式的属性定义，由该属性定义描述编解码格式和对应的传输地址。
10、如权利要求9所述的方法，其特征在于，若所述属性定义中未显式的指定传输地址，则按SDP规范从相应的属性定义中获取。
CN200510106295.1A 2005-09-23 2005-09-30 一种媒体流传输地址的协商方法 Pending CN1937620A (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN200510106295.1A CN1937620A (zh) 2005-09-23 2005-09-30 一种媒体流传输地址的协商方法
PCT/CN2006/002495 WO2007033606A1 (fr) 2005-09-23 2006-09-22 Procede de negociation destine a l'adresse de transmission du flux multimedia

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN200510104899.2 2005-09-23
CN200510104899 2005-09-23
CN200510106295.1A CN1937620A (zh) 2005-09-23 2005-09-30 一种媒体流传输地址的协商方法

Publications (1)

Publication Number Publication Date
CN1937620A true CN1937620A (zh) 2007-03-28

Family

ID=37888559

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200510106295.1A Pending CN1937620A (zh) 2005-09-23 2005-09-30 一种媒体流传输地址的协商方法

Country Status (2)

Country Link
CN (1) CN1937620A (zh)
WO (1) WO2007033606A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101141807B (zh) * 2007-08-25 2011-10-26 中兴通讯股份有限公司 一种编解码协商方法
CN110062056A (zh) * 2018-01-19 2019-07-26 中兴通讯股份有限公司 网络地址转换方法及装置

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI20011962A0 (fi) * 2001-10-09 2001-10-09 Nokia Corp Koodinmuunninjärjestely
CN1306779C (zh) * 2003-03-18 2007-03-21 华为技术有限公司 一种ip网络中的媒体流处理方法
KR20050080619A (ko) * 2004-02-10 2005-08-17 주식회사 케이티 접속 설정 프로토콜 가입자 코덱제공서버를 이용한 호처리 시스템 및 그 코덱 매칭 방법

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101141807B (zh) * 2007-08-25 2011-10-26 中兴通讯股份有限公司 一种编解码协商方法
CN110062056A (zh) * 2018-01-19 2019-07-26 中兴通讯股份有限公司 网络地址转换方法及装置

Also Published As

Publication number Publication date
WO2007033606A1 (fr) 2007-03-29

Similar Documents

Publication Publication Date Title
US7301913B2 (en) Transcoding arrangement in a session initiation
EP1853037B1 (en) Method and system of forwarding capability information of user equipment in internet protocol multimedia subsystem network
KR100802641B1 (ko) 패킷 교환 방식 네트워크 시그날링을 통해 회선 교환 방식통신을 설정하는 시스템, 장치, 및 방법
JP3633546B2 (ja) シグナリング中継システムおよびシグナリング中継方法
Camarillo et al. Grouping of media lines in the session description protocol (SDP)
KR101114072B1 (ko) 무선통신 시스템의 정보 전달방법 및 이를 지원하는 무선통신 단말기
JP5185827B2 (ja) 少なくとも１つのペイロードデータコネクションを少なくとも１つのマルチプレックスコネクションへ割り当てるための方法
EP2052522B1 (en) Interworking with media fallback
US20080165787A1 (en) Method for negotiating about the media stream packet time length
JP2007512727A (ja) インタフェース呼シグナリングプロトコル
CN101257435B (zh) 基于nat-pt的sip应用层网关的实现方法
CN100586107C (zh) 传输实时传输协议报文的方法和通讯设备
CN101166178A (zh) 会话描述协议版本协商/信息获取方法、系统及网络实体
US7310665B2 (en) Method, gateway system and arrangement in a communication network
CN101087302A (zh) 进行媒体资源控制的方法以及呼叫建立方法
CN1937620A (zh) 一种媒体流传输地址的协商方法
CN101594623B (zh) 一种互联网协议语音呼叫的监听方法及设备
CN101119212A (zh) 传递及应用用户-用户应用信息的方法和系统
Stephens et al. SIP and H. 323—interworking VoIP networks
CN101960817B (zh) 通信客户之间的优化编码资源协商
CN101754409B (zh) 一种ip承载的建立方法及所采用的软交换
US8009664B2 (en) Method for exchanging media description information between user agents using session initiation protocol
KR101063706B1 (ko) 차세대 통신망에서 멀티-ｓｄｐ를 이용한 회의통화부가서비스 제공방법
Jacobs Investigating Call Control Using MGCP in Conjuction with SIP and H. 323
KR20050000025A (ko) Ｓｉｐ 기반의 망에서 가입자의 미디어 정보를 이용한 호처리 시스템 및 방법

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C12 Rejection of a patent application after its publication
RJ01 Rejection of invention patent application after publication

Open date: 20070328