CN101087302B

CN101087302B - 呼叫建立方法

Info

Publication number: CN101087302B
Application number: CN200610141146.3A
Authority: CN
Inventors: 祝宁
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2006-06-05
Filing date: 2006-10-13
Publication date: 2010-12-01
Anticipated expiration: 2026-10-13
Also published as: US20090080449A1; EP2034664A4; EP2034664A1; WO2007143920A1; CN101087302A; US7948971B2

Abstract

本发明公开了一种呼叫建立方法，其核心思想是在进行媒体资源控制时，由媒体网关控制器在主、被叫媒体网关之间交换收发媒体的目的属性和源属性。由于端点提供媒体的源属性能得到描述，因此在端点提供媒体的目的与源属性不一致时，也能够方便的通知到对端；并且由于网关能够通过媒体网关控制器的指示获得对媒体源属性的描述，因此能够根据收到的承载媒体包的源地址和端口等信息来判断该承载媒体包的合法性，有效避免处理垃圾报文，防止攻击。

Description

呼叫建立方法

技术领域

本发明涉及通讯技术领域，具体是涉及一种呼叫建立方法。

背景技术

随着电信技术的发展，传统的以电路交换为主的公共交换电话网(PSTN，Public Switched Telephone Network)正逐渐向以分组交换为主的下一代电信网络(NGN，Next Generation Network)转变。分组网络基于因特网协议(IP，Internet Protocol)/异步传输模式(ATM，Asynchronous Transfer Mode)等方式传输，能够将PSTN网络中大量的数据传输卸载到IP网络中以减轻PSTN网络的重荷。并且分组网络还可以IP技术的新特性增加和增强许多新老业务，使得在通讯网络上实现语音、视频、数据等综合业务成为可能。

为了进行分组网络上的通讯，在呼叫连接建立、业务切换等过程中都需要进行媒体资源控制。例如在进行媒体流传输之前需要进行传输双方的媒体能力协商，以获得对端的接收地址以及编解码(codec，coding and decoding)类型等信息。现有的媒体资源控制方法主要是基于传输双方的媒体的目的属性进行，以普遍采用的H.248协议为例，H.248协议中定义了携带本端接收媒体的目的属性的Local描述符和携带本端发送媒体的目的属性的Remote描述符。Local、Remote描述符所携带的媒体目的属性与承载方式有关，比如在IP承载的情况下，通常包括本端用于接收媒体的IP地址、端口号、编解码类型及其参数等。反映呼叫双方接收媒体能力和属性的Local、Remote描述符以消息的方式通过用户归属的媒体网关(MGW，Media Gateway)上报给媒体网关控制器(MGC，Media Gateway Controller)，再经由MGC的下发操作实现媒体资源能力的交换。

上述媒体资源控制方法由于Local和Remote描述符仅涉及传输双方的媒体的目的属性，存在如下缺陷：一、若某个端点提供媒体的目的与源属性并不一致，例如，具备显示视频的能力但不具备发送视频的能力，或者发送媒体和接收媒体使用不同的地址等，就难以通过现有控制方法中的协商过程令对端获知；二、基本呼叫建立之后，在所属MGW上使用实时传输协议(RTP，Real-TimeTransport Protocol)以及其它协议的IP端点有可能受到IP攻击包或者垃圾IP包的攻击，处理这些IP包需要占用大量的系统资源，但是因为在现有媒体资源控制方法中没有涉及交换协商源地址，所以如果编解码等其它属性相同，就无法区分攻击IP包和合法的IP包，造成网关无法拒绝非法的IP包；三、对于单向的媒体流，例如组播源发出的媒体流，目的地址为组播地址，而又不需要接受媒体流，无法执行基于源地址的操作。

发明内容

本发明的目的在于提供一种便于在端点使用的媒体目的属性与源属性不一致时进行媒体资源控制的呼叫建立方法。

为达到本发明的目的，所采取的技术方案是：一种呼叫建立方法，包括，

媒体网关控制器在主叫用户归属的媒体网关上增加主叫端点；

主叫媒体网关在应答中向媒体网关控制器上报本端接收媒体的目的属性和发送媒体的源属性；

媒体网关控制器在被叫用户归属的媒体网关上增加被叫端点，并将主叫媒体网关上报的本端接收媒体的目的属性和发送媒体的源属性作为本端发送媒体的目的属性和接收媒体的源属性指示给被叫媒体网关；

被叫媒体网关在应答中向媒体网关控制器上报本端接收媒体的目的属性和发送媒体的源属性；

媒体网关控制器将被叫媒体网关上报的本端接收媒体的目的属性和发送媒体的源属性作为本端发送媒体的目的属性和接收媒体的源属性更新到主叫媒体网关。

本发明中媒体的源属性可包括发送端使用的媒体类型、和/或网络地址和端口、和/或编解码类型等，媒体的目的属性可包括接收端使用的媒体类型、和/或网络地址和端口、和/或编解码类型等。

采用上述技术方案，本发明有益的技术效果在于：

1)本发明采用在进行媒体资源控制时，对媒体的源属性进行上报和/或指示操作的方法。由于端点使用的媒体源属性能得到描述，因此在端点使用的媒体的目的属性与源属性不一致时，也能够方便的通知到对端；在仅需要描述源属性，不需要描述目的属性的场景下也可以方便的进行控制；并且由于网关能够通过媒体网关控制器的指示获得对媒体源属性的描述，因此能够根据收到的媒体包的源地址和端口等信息来判断该媒体包的合法性，有效避免处理垃圾报文，防止攻击。

2)媒体网关控制器向媒体网关指示本端接收媒体的源属性时，可以指定也可以使用对端媒体网关上报的本端发送媒体的源属性，不受当前呼叫所处阶段的限制，能够满足门控等要求，控制方式灵活。

3)本发明还针对普遍使用的H.248协议，提供了几种具体的媒体的源属性描述方法，便于根据实际应用情况进行选择。

附图说明

下面通过具体实施方式并结合附图对本发明作进一步的详细说明。

图1是本发明实施例二呼叫建立方法的流程示意图；

图2是实施例二中呼叫建立过程采用H.248协议的信令流程示意图。

具体实施方式

本发明提供了一种进行媒体资源控制的方法，其核心思想是在进行媒体资源控制时，对媒体的源属性进行上报和/或指示操作。对于媒体资源控制中的协商过程，媒体网关控制器向媒体网关指示本端接收媒体的源属性时，可以使用对端媒体网关上报的本端发送媒体的源属性；对于媒体资源控制中的非协商过程，媒体网关控制器也可以随时向媒体网关指定本端接收媒体的源属性，以满足门控等要求。对媒体源属性的操作可与对媒体目的属性的操作同时或者单独进行。针对普遍使用的H.248协议，对媒体的源属性的携带可通过多种方式进行，例如，扩展H.248协议的结构，增加相应的描述符；或者，扩展H.248消息中的包，利用包的属性或信号来携带；或者扩展原有描述符的定义，仍用原有描述符来携带，只是增加新的属性标识来区别等。本发明还提供采用上述媒体资源控制过程的呼叫建立方法。以下分别对本发明方法的过程以及应用于具体协议的实现方法进行详细说明。

实施例一、一种进行媒体资源控制的方法，包括，

媒体网关向媒体网关控制器上报本端发送和/或接收媒体的源属性；媒体的源属性所包含的具体内容与媒体的承载方式有关。例如，媒体承载在IP上时，媒体的源属性可包括媒体发送的源IP地址，端口号、媒体类型、编解码方式及其参数等；媒体承载在ATM上时，媒体的源属性可包括媒体发送的源地址、骨干网连接标识(BNC-ID)、媒体类型、编解码方式及其参数等；媒体承载在TDM上时，媒体的源属性可包括媒体类型、编解码方式及其参数等。当然，可以选择某种承载方式下全部或部分媒体相关参数作为媒体的源属性。

对收发媒体的源属性的上报可单独进行，也可与现有收发媒体的目的属性的上报过程同时进行。媒体的目的属性所包含的内容具有与源属性相似的范围，本端发送媒体的源属性与本端接收媒体的目的属性可以相同也可以不同；

媒体网关控制器向媒体网关指示本端发送和/或接收媒体的源属性。媒体网关控制器通过指示操作来执行对媒体资源的控制，例如，媒体网关控制器可以使用主叫媒体网关上报的本端发送媒体的源属性向被叫媒体网关指示本端接收媒体的源属性，以进行能力的协商；又如，媒体网关控制器可以指定媒体网关本端接收媒体的源属性，以达到门控等目的；再如媒体网关控制器可以根据媒体网关上报的本端接收媒体的目的属性为其指定相应的本端发送媒体的源属性，以实现灵活控制等。

与源属性的上报过程相似，对收发媒体的源属性的指示可单独进行，也可与现有收发媒体的目的属性的指示过程同时进行。

上述各属性的上报和指示过程在具体协议中通过在相应命令或消息内携带相关属性或者信号来进行，以H.248协议为例，本端接收、发送媒体的目的属性可分别采用Local、Remote描述符进行携带，描述符内的属性一般采用会话描述协议(SDP，Session Description Protocol)所规定的格式来表达，常见形式为：

Local{

v＝0

c＝IN IP4 10.11.1.1

m＝audio 10000 RTP/AVP 4

a＝ptime:30

}

其中“v”代表“version”，表示所采用SDP的版本号；“c”代表“connection”，表示连接属性，“c＝”后的“IN IP4”表示网络层协议使用Internet IPV4，“10.11.1.1”为IP地址；“m”代表“media”，表示媒体属性，“m＝”后的字段“audio”表示媒体类型为音频(还可以是视频“video”等)，“10000”表示IP端口号，“RTP/AVP”标识使用RTP/AVP协议。“4”表示codec类型为G.723；“a”代表“attribute”，表示属性，“a＝”后的字段“ptime”表示该属性为打包时长，“:”号后的“30”表示该属性值为30，即该端点音频流的打包时长为30ms。Remote描述符所采用的表示方式与Local描述符相同。

为最大程度减少对现有协议的改动，本发明中本端接收、发送媒体的目的属性的携带仍可采用上述Local、Remote描述符的形式，而本端接收、发送媒体的源属性的携带则可采用多种方案进行，以下分别对几种主要方案进行详细说明：

方案一、扩展H.248协议的结构，相应于Local、Remote描述符，增加携带本端发送、接收媒体的源属性的Localfrom、Remotefrom描述符，Localfrom、Remotefrom描述符采用与Local、Remote描述符相同的表达形式，例如：

Localfrom{

v＝0

c＝IN IP4 10.11.1.1

m＝audio 10000RTP/AVP 4

a＝ptime:30

}

在本方案中，为实现和扩展前的协议兼容，可规定，如果在协商过程中不使用Localfrom和Remotefrom描述符，则表示MGW使用与Local相同的本端发送媒体的源地址以及与Remote相同的本端接收媒体的源地址，或者表示无需协商由MGW自行决定本端发送媒体的源属性以及判断本端接收媒体的源属性是否合法。这样就可以和不扩展这两个描述符前的H.248协议完全兼容。

此外，也可允许媒体网关控制器在请求消息中不带Localfrom和/或Remotefrom描述符，但是媒体网关可以在应答消息中携带Localfrom和/或Remotefrom描述符，在这两个描述符中可以使用部分或者全部的local和/或remote描述符中的属性。

方案二、扩展包来实现在H.248消息中携带本端发送、接收媒体的源属性。具体实现方案是，定义一个包来描述媒体源属性，将其中的两个属性分别定义为Localfrom、Remotefrom。这些属性可以放在localControlDescriptor描述符内。属性数据类型可以是字串类型，可以直接使用SDP字串格式，也可以使用其它格式，携带与方案一中Localfrom、Remotefrom描述符中相同的信息或者其部分信息(例如只描述源地址和端口等)即可。当然，也可以定义多个属性对所需要携带的媒体源属性所包含的各种信息分别进行携带。此方案的好处在于，可以不必修改H.248协议的结构。由于H.248协议中的包是可开放定义的，只要MGC和双方MGW能够识别并处理该属性定义即可实现。在方案一的具体实现中使用Localfrom和Remotefrom描述符的地方，使用该包的属性来携带相同的信息，即可完成和方案一相同的效果。媒体网关控制器可以通过审计的方式获知媒体网关是否支持该扩展包。该包中还可以定义一个属性用来描述媒体网关接收媒体报文时是否检查源地址，以及定义一个属性用来描述是否要求媒体网关上报源属性。这两个属性都可以通过媒体网关控制器下发给媒体网关。

在方案二中，还可以用信号及其参数的方式代替属性来完成上述携带过程，其使用方法与上述新增属性的方法完全一样。

方案三、扩展Local、Remote描述符的定义，通过在SDP中的命令行来指明某组(group)属性描述的是媒体的源属性还是媒体的目的属性。在此方案下Local描述符用于携带本端接收媒体的目的属性和本端发送媒体的源属性，在SDP中具体指明媒体属性是源属性还是目的属性；Remote描述符同样进行相似的定义。为了与现有H.248协议中的描述兼容，可以默认Local中的不加指明的SDP是描述本端接收媒体的目的属性，如果是用于描述本端发送媒体的源属性，则用扩展的新的SDP语法，例如增加新的属性行来指明。在Remote描述符中类似，默认Remote描述符中的不加指明的SDP是本端发送媒体的目的属性，如果是用于描述本端接收媒体的源属性，则用扩展的新的SDP语法，例如增加新的属性行来指明，例如：

Remote{

v＝0

c＝IN IP4 $

m＝audio $ RTP/AVP 4

a＝ptime:30

v＝0

c＝IN IP4 $

m＝audio $ RTP/AVP 4

a＝ptime:30

a＝remotefrom

}

上述SDP中的第一组媒体描述“v、c、m、a”与现有协议中相同，默认为本端发送媒体的目的属性；第二组媒体描述包括了一个扩展的属性行“a＝remotefrom”，因此，第二组媒体描述即为本端接收媒体的源属性描述。

如果H.248消息使用二进制编码，而且Local和Remote不使用SDP编码，而是使用H.248.1的附录C的C.11以外的标识(tag)来描述媒体属性，则可以使用新增tag值的方式来区分源属性和目的属性。

方案四、强制定义本端发送媒体的源属性与本端接收媒体的目的属性的部分或者全部相同，本端接收媒体的源属性与本端发送媒体的目的属性的部分或者全部相同。例如，强制要求端点发送和接收媒体必须使用相同的IP地址和端口(在ATM承载的情况下，为ATM地址和BNC-ID)，这样，在描述媒体的目的属性的时候，同时也就描述了发送媒体必须使用的IP地址和端口(在ATM承载的情况下，为ATM地址和BNC-ID)。本方案不允许发送和接收使用不同的地址，但在绝大多数情况下仍是适宜使用的。

本发明媒体资源控制方法可应用于协商过程，实现呼叫建立或业务切换等过程中的媒体能力协商，具体描述为：媒体网关控制器在主、被叫媒体网关之间交换主、被叫端点的接收媒体的目的属性、发送媒体的源属性，即，将一方媒体网关上报的端点的接收媒体的目的属性和发送媒体的源属性作为发送媒体的目的属性和接收媒体的源属性指示给另一方媒体网关的端点。当上述媒体协商过程发生于呼叫建立过程中时，媒体网关控制器需要在主、被叫媒体网关上增加相应的端点；当上述媒体协商过程发生于业务切换过程中时，媒体网关控制器通过属性交换对之前增加的端点进行属性修改。

本发明媒体资源控制方法也可应用于非协商过程，例如，媒体网关控制器在呼叫的任意阶段向媒体网关指示本端接收媒体的源属性，以实现门控等。

以下，为便于进一步理解本发明，给出本发明媒体资源控制的协商过程在呼叫建立过程中的一个应用例。

实施例二、一种呼叫建立方法，流程如图1所示，包括：

1)MGC在主叫用户归属的媒体网关MGW1上增加主叫端点T1以及IP端点；

2)MGW1在应答中向MGC上报上下文标记(context ID)、IP端点ID以及该IP端点的本端接收媒体的目的属性和发送媒体的源属性；

3)MGC在被叫用户归属的媒体网关MGW2上增加被叫端点T2以及IP端点，MGC并将主叫侧的IP端点的本端接收媒体的目的属性和发送媒体的源属性指示给MGW2；

4)MGW2在应答中向MGC上报上下文ID、IP端点ID以及该IP端点的本端接收媒体的目的属性和发送媒体的源属性；

5)MGC将被叫侧的IP端点的本端接收媒体的目的属性和发送媒体的源属性指示给MGW1。这样主叫和被叫用户的IP端点彼此就获得了对端关于发送源属性和接收目的属性的描述，媒体能力协商过程完成，T1和T2之间即可进行媒体流传输。

本实施例提供了将本发明媒体资源控制的协商过程应用于呼叫建立的一个典型例子，应当说明的是，上述呼叫连接端点建立以及具体进行主被叫媒体的源属性和目的属性交换的过程和顺序，仅提供对本发明具体应用过程的一种理解，基于通讯网络中所采用的不同协议和规范架构，本领域技术人员还可根据本发明的核心思想采用具有其他形式的实现流程以符合相应的实际需要。例如，可以先增加被叫端点再增加主叫端点，或者，先把被叫方的媒体属性指示给主叫方再将主叫方的媒体属性指示给被叫方等。因此上述流程中的步骤和顺序不应理解为对本发明的限制。

若采用H.248协议，上述呼叫建立过程的信令流程如图2所示，包括：

①MGC向MGW1下发H.248的ADD命令，创建一个上下文，把作为主叫的端点T1放在该上下文中，同时在该上下文中加入一个IP端点；

②MGW1向MGC返回ADD命令的应答消息REPLY，返回上下文ID为C1、IP端点ID为RTP/1，上报IP端点RTP/1的接收媒体的目的属性和发送媒体的源属性；

③MGC向MGW2下发H.248的ADD命令，创建一个上下文，把作为被叫的端点T2放在该上下文中，同时在该上下文中加入一个IP端点；该ADD命令中还携带由MGW1上报的RTP/1的接收媒体的目的属性和发送媒体的源属性；

④MGW2向MGC返回ADD命令的应答消息REPLY，返回上下文ID为C2，IP端点ID为RTP/2，上报IP端点RTP/2的接收媒体的目的属性和发送媒体的源属性；

⑤MGC向MGW1下发MOD命令，将RTP/1的发送媒体的目的属性和接收媒体的源属性分别指定为MGW2上报的RTP/2的接收媒体的目的属性和发送媒体的源属性；

⑥MGW1向MGC回复应答消息REPLY，呼叫建立过程完成。

以下，结合上述信令流程，详述实施例一中提供的方案一和方案三在具体场景中的应用(方案二通过扩展包的方式来实现方案一中扩展的描述符的功能，其过程与方案一类似，不再赘述)：

方案一应用：

在上述信令流程的步骤①中，MGC向MGW1下发的ADD命令中需要包括Local、Localfrom描述符，其SDP如下：

Local{

v＝0

c＝IN IP4 $

m＝audio $ RTP/AVP 4

a＝ptime:30

v＝0

c＝IN IP4 $

m＝audio $ RTP/AVP 0

}，

Localfrom{

v＝0

c＝IN IP4 $

m＝audio $ RTP/AVP 4

a＝ptime:30

v＝0

c＝IN IP4 $

m＝audio $ RTP/AVP 0

}

上述Local、Localfrom描述符中IP端口地址和端口号为“$”，表示这些属性值需要由MGW1上报给MGC；并且分别给出了两组具有不同codec类型的属性，表示MGC要求MGW1分别为接收/发送媒体在G711和G.723之间选择支持的codec。此外，Localfrom中的属性和Local中的属性相同时，也可以不携带Localfrom描述符，但是媒体网关应答消息中可以携带Localfrom描述符。

若MGW1准备用G.723接收媒体，接收地址为124.124.124.222，端口号为2222；用G.711发送媒体，发送地址为124.124.124.444，端口号为4444；则在步骤②返回的REPLY消息中放置的Local、Localfrom描述符SDP如下：

Local{

v＝0

c＝IN IP4 124.124.124.222

m＝audio 2222RTP/AVP 4

a＝ptime:30

}，

Localfrom{

v＝0

c＝IN IP4 124.124.124.444

m＝audio 4444 RTP/AVP 0

}

在步骤③中MGC向MGW2下发H.248的ADD命令，将已获取的MG1的本端接收媒体的目的属性和发送媒体的源属性分别放在Remote和Remotefrom描述符中下发给MGW2，同时要求MGW2上报为发送媒体和接收媒体选择的IP地址和端口。此步骤的ADD命令中Local、Localfrom、Remote、Remotefrom描述符的SDP如下：(与步骤①中Local、Localfrom略有不同的是，为了和MGW1发送和接收媒体的codec相对应，MGC在Local描述符中已选择了和Remotefrom相同的codec即G.711，在Localfrom描述符中已选择了和Remote相同的codec即G723。)

Local{

v＝0

c＝IN IP4 $

m＝audio $ RTP/AVP 0

}，

Localfrom{

v＝0

c＝IN IP4 $

m＝audio $ RTP/AVP 4

a＝ptime:30

}，

Remote{

v＝0

c＝IN IP4124.124.124.222

m＝audio 2222RTP/AVP 4

a＝ptime:30

}，

Remotefrom{

v＝0

c＝IN IP4124.124.124.444

m＝audio 4444 RTP/AVP 0

}

MGW2在步骤④返回的REPLY消息中上报为接收/发送媒体选择的IP地址和端口，若接收地址为125.125.125.111，端口号为6666；发送地址为125.125.125.333，端口号为8888；则在该REPLY消息中Local、Localfrom描述符的SDP如下：

Local{

v＝0

c＝IN IP4 125.125.125.111

m＝audio 6666RTP/AVP 0

}，

Localfrom{

v＝0

c＝IN IP4 125.125.125.333

m＝audio 8888 RTP/AVP 4

a＝ptime；30

}

按照MGW2上报的Local、Localfrom描述符，在步骤⑤中MGC向MGW1下发MOD命令修改其Remote、Remotefrom属性，MOD命令中Remote、Remotefrom描述符的SDP如下：

Remote{

v＝0

c＝IN IP4 125.125.125.111

m＝audio 6666RTP/AVP 0

}，

Remotefrom{

v＝0

c＝IN IP4 125.125.125.333

m＝audio 8888 RTP/AVP 4

a＝ptime:30

}

然后在步骤⑥MGW1返回确认应答，该应答消息中可以不包含Local、Localfrom、Remote、Remotefrom描述符，呼叫建立过程完成。

方案三应用(参数值选择与方案一应用中相同)：

步骤①中，MGC向MGW1下发的ADD命令中包括Local描述符，其SDP如下：

Local{

v＝0

c＝IN IP4 $

m＝audio $ RTP/AVP 4

a＝ptime:30

v＝0

c＝IN IP4 $

m＝audio $ RTP/AVP 0

v＝0

c＝IN IP4 $

m＝audio $ RTP/AVP 4

a＝ptime:30

a＝localfrom

v＝0

c＝IN IP4 $

m＝audio $ RTP/AVP 0

a＝localfrom

}

注意上述SDP中的属性行“a＝localfrom”，即为扩展的属性行，表示本组媒体属性描述为媒体的源属性。两个“a＝localfrom”行代表第三组和第四组媒体属性描述为媒体的源属性。

步骤②中MGW1返回的REPLY消息中Local描述符的SDP如下：

Local{

v＝0

c＝IN IP4 124.124.124.222

m＝audio 2222 RTP/AVP 4

a＝ptime:30

v＝0

c＝IN IP4 124.124.124.444

m＝audio 4444 RTP/AVP 0

a＝localfrom

}

上述Local描述符与方案一应用中该步骤的Local、Localfrom描述符以不同的方式传达了相同的内容。

步骤③中MGC向MGW2下发H.248的ADD命令，包括Local、Remote描述符，SDP如下：

Local{

v＝0

c＝IN IP4 $

m＝audio $ RTP/AVP 0

v＝0

c＝IN IP4 $

m＝audio $ RTP/AVP 4

a＝ptime:30

a＝localfrom

}，

Remote{

v＝0

c＝IN IP4 124.124.124.222

m＝audio 2222 RTP/AVP 4

a＝ptime:30

v＝0

c＝IN IP4 124.124.124.444

m＝audio 4444RTP/AVP 0

a＝ptime:20

a＝remotefrom

}

步骤④中MGW2在返回的REPLY消息中的Local描述符的SDP如下：

Local{

v＝0

c＝IN IP4 125.125.125.111

m＝audio 6666 RTP/AVP 0

v＝0

c＝IN IP4 125.125.125.333

m＝audio 8888 RTP/AVP 4

a＝localfrom

}

步骤⑤中MGC向MGW1下发MOD命令修改其Remote属性，MOD命令中Remote描述符的SDP如下：

Remote{

v＝0

c＝IN IP4 125.125.125.111

m＝audio 6666 RTP/AVP 0

v＝0

c＝IN IP4 125.125.125.333

m＝audio 8888 RTP/AVP 4

a＝remotefrom

}

上述方案三的应用中通过“a＝localfrom”和“a＝remotefrom”分别标识本端发送源属性和本端接收(即对端发送)源属性。也可以使用同一个标识表示源属性，例如“a＝sourceattr”，如果被放置在Local描述符中，表示该行所在组为本端发送媒体的源属性，如果被放置在Remote描述符中，则表示该行所在组为本端接收(即对端发送)媒体的源属性。

以上对本发明所提供的一种进行媒体资源控制的方法以及呼叫建立方法进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims

1.一种呼叫建立方法，其特征在于，包括：

2.根据权利要求1所述的呼叫建立方法，其特征在于：所述媒体的源属性包括发送端使用的媒体类型、和/或网络地址和端口、和/或编解码类型；所述媒体的目的属性包括接收端使用的媒体类型、和/或网络地址和端口、和/或编解码类型。

3.根据权利要求1或2所述的呼叫建立方法，其特征在于：所述媒体网关和媒体网关控制器之间采用H.248协议，所述本端发送、接收媒体的源属性的携带方法为，

通过采用会话描述协议的描述符携带；或者

由H.248消息中某个包的相应属性或信号携带。