CN100459722C - 在电信系统中管理呼叫的方法和系统 - Google Patents

Abstract

本发明一般涉及电信服务，尤其涉及一种特别是相对承载特性修改来管理呼叫的系统和方法。一方面，本发明提供了一种在电信系统中管理呼叫的方法和系统，所述电信系统包括一个网络，该网络具有至少一个实现呼叫控制功能的呼叫控制器以及至少一个实现承载控制功能的承载控制器，呼叫控制器与承载控制器由一个垂直控制协议接口分离，其中包括在电信系统内传递的至少一个消息中提供一个关于该至少一个承载控制器修改承载特性的能力的指示；以及接收所述指示并且将其存储在该至少一个呼叫控制器中。另一方面，本发明提供了一个媒体网关控制器，所述媒体网关控制器可操作，以便请求指示并且从至少一个媒体网关接收指示，所述指示表示的是该至少一个媒体网关对由所述至少媒体网关所建立的承载的特性进行修改的能力。在优选实施例中，本发明提供了一个媒体网关控制器，所述媒体网关控制器可操作，以便接收对一个指示的请求，所述指示表明了该至少一个媒体网关修改由所述媒体网关建立的承载的特性的能力。

Description

在电信系统中管理呼叫的方法和系统

技术领域

本发明一般涉及电信业务，尤其涉及一种具体相对修改承载特性的、对呼叫进行管理的系统和方法。

背景技术

对电信网络架构来说，最近存在这样一种趋势，那就是将交换节点分解成呼叫控制功能性和承载控制功能性。本领域技术人员可以了解，多种呼叫控制功能和承载控制功能都是已知的，这些功能可以由驻留在一个或多个电信网络节点内的计算机软件程序实现。对于将交换节点分解成呼叫控制功能性和承载控制功能性，需要一种垂直控制协议，以便在相应的呼叫控制与承载控制功能之间进行通信。一个例示的垂直控制协议是媒体网关控制协议，该协议使媒体网关控制器能够对媒体网关进行外部控制和管理。媒体网关控制协议消息在MGC与MG之间传递控制和管理信息。MG通常在多服务分组网络边缘进行操作并且MG的实例包含IP上话音的网关、ATM上的话音的网关、调制解调器库、电缆调制解调器以及机顶盒。呼叫控制和承载控制功能同样适用于这种情况，其中呼叫控制功能驻留在媒体网关控制器(MGC)或是CSF、CSM或CSN之类的呼叫服务功能内，而承载控制功能则驻留于媒体网关(MG)或是BIWF、BCF或BCU之类的承载互通功能内。

本领域技术人员还应该了解的是，承载是载送某个呼叫的用户平面信息的连接。举例来说，承载可以是一个载送话音呼叫的ATM(异步传输模式)连接或是一个载送数据呼叫的IP(网际协议)连接。在分解的交换节点的实例中，该承载控制功能为一个呼叫来管理物理承载的建立、修改和释放。在建立呼叫的时候，该呼叫控制功能请求承载控制功能使用那些具有满足呼叫需求的特征的承载来建立一个呼叫。而承载特性则涉及该承载的物理特性，例如带宽、分组化、分组大小、编码类型或者是成帧。

在不同的时间有可能需要或请求去修改一个已建立的呼叫连接中的承载特征。然而，承载控制功能通常不支持承载修改信令，并且如果支持承载修改信令，则呼叫控制功能通常是不知道这种能力的。在这方面，承载控制功能的能力指的是与承载相关联的承载控制协议的能力。例如，承载是否使其特性被修改或者承载是否具有释放过程，这些全都依赖于相关的承载控制功能的能力。无论出于何种理由，如果相关的承载控制功能无法接纳一个修改承载特性的请求，那么通常会从实现该承载控制功能的实体向实现该呼叫控制功能的实体发送一个表明无法满足所述请求的错误消息。

在现有系统中，对来自呼叫控制功能的修改承载特性的请求做出响应的错误消息通常并不指明错误的确切原因。在某些情况下，承载控制功能可以支持一个修改信令协议，但是也可以出于别的原因而发送错误消息，例如拥塞。

一旦从实现承载控制功能的实体接收到错误消息，则呼叫控制功能可以通过寻求与具有恰当特性的备选承载建立一个备选承载连接，而尝试去满足一个修改请求。

然而，与上述的、在尝试满足一个修改已建立呼叫连接中的承载特性的请求中的过程相关的时延非常大，并且由于无法在时间约束以内满足所述修改请求，因此所述时延实质上增加了超时的风险，而这将会导致丢弃现有的呼叫连接。有关这个问题的更多实例是丢弃或延迟的分组，由此产生可以在呼叫中察觉的静默或微小静电噪声(clicking)。所有这些影响都会促成该网络的不令人满意的性能。

因此，本领域技术人员应该了解，对已建立的呼叫连接而言，呼叫控制功能无法以一个在所要求的时间约束内实现修改的合理概率来管理对承载特性的平滑和有效的修改。

发明内容

本发明的一个目的是改善或克服现有技术中的一个或多个缺陷。

本发明的另一个目的是提供一种用于对修改承载特性的请求做出响应的改良系统和方法，从而与现有系统和方法相比，所述改进使得能够以更高的效率做出一个判定，该判定有关要查明和/或实现的请求的能力。

根据本发明的在电信系统中管理呼叫的方法，所述系统包括一个网络，该网络具有至少一个实现呼叫控制功能的呼叫控制器和至少一个实现承载控制功能的承载控制器，该至少一个呼叫控制器和该至少一个承载控制器由一个垂直控制协议接口分离，所述方法包括以下步骤：在该电信系统内从该至少一个承载控制器传递到该至少一个呼叫控制器的至少一个消息中提供一个表明该至少一个承载控制器修改承载特性的能力的指示；以及将所述指示存储在该至少一个呼叫控制器中；以及在该至少一个呼叫控制器接收到表明应该修改承载特性的呼叫控制消息时，对所述存储的指示进行检查，以便确定是否可以修改承载特性。

本发明还提供一种电信系统，包括一个网络，所述网络具有至少一个实现呼叫控制功能的呼叫控制器以及至少一个实现承载控制功能的承载控制器，所述呼叫控制器和承载控制器由垂直控制协议接口分离，所述系统可操作用来从所述系统内传递的至少一个消息中获取与该至少一个承载控制器在呼叫的活动阶段期间修改承载特性的能力有关的信息，此外所述系统还可操作用来接收一个在呼叫的活动阶段期间修改承载特性的请求，所述系统包括：第一装置，用于检索所述获取的信息，以便确定是否可以满足所述请求；第二装置，用于在至少一个承载控制器包括承载特性修改信令的能力时修改一个现有承载的承载特性；以及第三装置，用于在至少一个承载控制器不包括承载特性修改信令的能力时选择具有所要求的承载特性的多个承载中的至少一个承载；其中所述第一装置刚一确定可以满足一个请求，就使用第二和第三装置来满足所述请求。

本发明还提供一种媒体网关控制器，包括：用于在电信系统内从至少一个媒体网关传递的至少一个消息中接收一个表明该至少一个媒体网关修改承载特性的能力的指示的装置；用于将所述指示存储的装置；以及用于在接收到表明应该修改承载特性的呼叫控制消息时对所述存储的指示进行检查以便确定是否可以修改承载特性的装置。

一方面，本发明提供了一种在电信系统中管理呼叫的方法，所述系统包括一个网络，该网络具有至少一个实现呼叫控制功能的呼叫控制器以及至少一个实现承载控制功能的承载控制器，该至少一个呼叫控制器和至少一个承载控制器由一个垂直控制协议接口分开，所述方法包括如下步骤：

在电信系统内从该至少一个承载控制器传递到该至少一个呼叫控制器的至少一个消息中提供一个表明至少一个承载控制器修改承载特性的能力的指示；以及

将所述指示存储在该至少一个呼叫控制器中；以及

在该至少一个呼叫控制器接收到表明应该修改承载特性的呼叫控制消息时，对所述存储的指示进行检查，以便确定是否可以修改该承载特性。

优选的，所述指示涉及的是承载控制器在呼叫的活动阶段期间修改承载特性的能力。一个呼叫的活动阶段即为在通信实体之间建立连接之后且在释放呼叫或是断开呼叫之前的呼叫周期。而所述消息可以包括一个媒体网关控制协议消息。

在一个实施例中，所述消息包含一个错误码，该错误码表示承载控制器没有修改承载特性的能力。在另一个实施例中，所述消息包含了一个在协议扩展包中定义的属性，此外在另一个实施例中，所述消息是由一个在协议扩展包中定义的事件来调用的。协议扩展包是一个允许通过包含该协议的新的信息单元来扩展现有电信协议的概念。所述新的信息单元可以在单独的协议文档中加以定义。新的信息单元可以用一个包身份以及信息单元身份，即属性身份来标识。例如，H.248协议是一个包含了包定义的垂直控制协议。事件则是一个在包内部定义的触发器，其中举例来说，MGC在一个MG中设定所述事件，以便在出现给定事件的时候指示该MG向MGC发出通知。

在一个优选实施例中，可以在任何时间提供所述消息，尤其可以在呼叫建立或是呼叫的活动阶段期间提供所述消息。

在一个优选实施例中，可以将所述消息作为呼叫控制信令规程的一部分来加以提供，所述呼叫控制信令规程包括一个建立承载的请求。优选地，所述消息可以是一个无线电接入网络控制消息。无线电接入网络控制消息可以包括一个控制消息，其中所述控制消息在无线电网络控制器(RNC)与驻留在移动交换中心(MSC)的MGC之间传送控制和管理信息。适合这种无线电接入网络控制消息的一个实例是第三代通用移动电话系统(UMTS)，该系统可能包括一个核心网络(CN)和一个UMTS无线电接入网络(UTRAN)，其中将CN分解成了一个包含MGC功能的MSC以及一个MG。在这个实例中，承载连接是在UTRAN的Iu接口中、在MG与RNC之间建立的。

在一个呼叫的活动阶段期间，呼叫控制器可以接收一个修改现有承载特性的请求。在这种情况下，本发明的方法还可以包括更进一步的步骤：

为现有呼叫的承载控制器去检索关于承载控制器修改承载特性并且尝试满足所述请求的能力的指示；

在承载控制器包含了一个承载特性修改信令的能力的时候，调用一个现有承载的承载特性修改；

当承载控制器不包括承载特性修改信令的能力的时候，调用一个具有所请求的承载特性的备选承载的建立。如果无法满足修改请求，那么在本发明的一个实施例中，本发明的方法还包含传递一个消息来拒绝所述修改请求的步骤。

另一方面，本发明提供了一种电信系统，其中包括一个网络，所述网络具有至少一个实现呼叫控制功能的呼叫控制器以及至少一个实现承载控制功能的承载控制器，所述呼叫控制器和承载控制器由垂直控制协议接口分开，并且所述系统可操作，以便从至少一个在所述系统内部传递的消息中获取与至少一个承载控制器在呼叫活动阶段期间修改承载特性的能力有关的信息，此外所述系统还可操作，以便接收一个在呼叫的活动阶段期间修改承载特性的请求，所述系统包括：

第一装置，用于检索所述获取的信息，以便确定是否可以满足该请求；

第二装置，用于在至少一个承载控制器包含承载特性修改信令的能力时修改现有承载的承载特性；以及

第三装置，用于在至少一个承载控制器不包括承载特性修改信令的能力时选择具有所请求的承载特性的多个承载中的至少一个承载；

其中第一装置刚一确定可以满足一个请求，就使用第二和第三装置来实现所述请求。

另一方面，本发明提供了一个媒体网关控制器，所述媒体网关控制器可操作，以便：

从至少一个媒体网关请求、接收并存储关于所述至少一个媒体网关修改由所述至少一个媒体网关所建立的承载特性的能力的指示；

接收一个表明应该对承载特性进行修改的呼叫控制消息；以及

检查所述存储的指示，以便确定是否可以修改所述承载的特性。

所述媒体网关控制器还可操作，以便接收对一个指示的请求，其中所述指示表示的是媒体网关对其建立的承载的特性进行修改的能力。在一个优选实施例中，所述指示涉及的是媒体网关在呼叫活动阶段期间修改承载特性的能力。

实质上，本发明源于这样一种实现方式，其中通过为呼叫控制功能提供一个承载控制功能修改承载特性的能力的指示，而可以在呼叫管理中显著改善呼叫控制功能的效率和有效性。

一个显著的优点是通过提供一个表明承载控制功能修改承载特性的能力的指示并在呼叫控制功能内部接收和保存这个指示而实现的。举例来说，如果需要修改承载特性，那么呼叫控制功能能够基于呼叫控制功能当前可用的信息来对满足这种要求的能力进行评估。在3GPP网络中，通常请求的是一个对承载特性的修改，举例来说，所述承载特性是交替的语音/传真功能性。通过为呼叫控制功能提供承载控制功能修改语音/传真之类的承载特性的能力的指示，便为呼叫控制功能提供了在控制级别对承载特性的这种修改进行管理的能力。对于承载特性修改来说，更有效和更有作用的请求管理应该降低丢弃呼叫的可能性并且由此而全面提高网络性能。

附图说明

对本领域技术人员来说，通过以下与附图结合使用的书面描述，本发明的一个或多个优选实施例的这些和其他特征和优点将是显而易见的，其中：

图1提供的是一个分为媒体网关控制器和媒体网关的分离交换节点的示意图；

图2示意性描述了根据现有技术系统来发布承载特性修改请求并从承载控制功能性中产生错误消息；

图3示意性描述了例示呼叫消息流的一个实例，其中显示了根据本发明优选实施例而在建立呼叫时对修改容许事件(Allowed Event)的请求和接收；

图4示意性描述了一个例示呼叫消息流，其中显示了根据本发明的另一个优选实施例、在建立承载之后对修改容许属性的请求和接收；

图5示意性描述了一个例示呼叫消息流，其中显示了根据本发明的另一个优选实施例的差错码的接收；

图6示意性描述了一个例示呼叫消息流，其中显示了根据本发明的另一个优选实施例、在建立承载之后对呼叫控制消息中的修改容许(Modification Allowed)的请求与接收。

图7示意性描述了一个例示呼叫消息流，其中显示了根据本发明的另一个优选实施例、在由另一个网络实体建立承载的承载建立之后对呼叫控制消息中的修改容许的请求与接收。

具体实施方式

参考图1，其中提供了一个分为媒体网关控制器和媒体网关的分解交换节点的示意图。在图1的实例中存在两个实现呼叫控制功能的实体，即媒体网关控制器MGC1和MGC2，以及两个实现承载控制功能的实体，即媒体网关MG1和MG2。此外在图1中还描述了一个驻留于这两个媒体网关MG1和MG2之间的承载，以及相应的媒体网关控制器与其媒体网关之间的链路10、12，所述媒体网关提供用于在其间依照媒体网关控制协议或H.248之类的垂直控制协议进行的通信。

参考图2，其中示意性描述了发布一个修改承载特性的请求以及从媒体网关那里产生一个错误消息。在图2的实例中，建立、修改和释放承载是经由媒体网关控制协议H.248/Megaco来实现的。同样可应用于这种信令的垂直控制协议的其他实例是因特网设备控制协议IDCP或MGCP协议。通常，媒体网关控制器(MGC)并不知道承载控制协议，并且即使这个信息为该控制器所知，它通常并不知道所用承载控制协议的确切版本。因此，在现有系统中，如果控制器请求修改承载特性，那么通常会产生一个错误消息。

举例来说，当ATM适配层的切换和信令协议Q.AAL2CS1在媒体网关(MG)上执行时，那么将会出现上述情况，因为该协议不支持承载修改信令。然而，如果在媒体网关(MG)上实施Q.AAL2CS2，那么，所述请求将会被成功地接收，因为此协议的第2版支持承载修改信令。尽管ATM切换和信令协议的第2版支持承载修改信令，但是接收到一个表示所请求的承载修改失败的错误消息将并不向媒体网关控制器指示所述错误是因为不支持承载修改信令而产生的。这样一来，不管错误的原因是什么，媒体网关控制器都会在接收到一般错误时采取行动，并且通常将会断开该呼叫。

图3显示了根据本发明一个优选实施例的例示呼叫消息流，其中显示了在建立呼叫时对修改容许事件的请求和接收。在MGC上接收一个呼叫控制消息，请求建立一个新的呼叫。然后，MGC通过使用一个ADD.request消息来请求MG1建立一个新的承载连接。在这个实例中，MGC充当一个呼叫控制器并且MG1充当一个承载控制器。在相同的消息中，MGC请求一个事件，以使MG可以指示是否允许修改承载特性。而MG1则使用承载控制消息传递来建立一个承载。在接收到承载建立的确认时，MG1将向MGC发送一个表明是否可以修改承载特性的通知消息。所述MGC将存储这个指示，以便在稍后的时间使用。

在接收到一个表明应该修改该承载特性的呼叫控制消息的时候，MGC会检查存储的指示，且然后则执行以下操作之一：

1.如果不支持承载特性修改-MGC通过使用呼叫控制信令来拒绝该呼叫控制修改。

2.如果支持承载特性修改-MGC通过使用一个MOD.request来请求MG1去修改承载特性。然后，MG1使用可应用的承载控制信令来修改该承载特性。

3.如果不支持承载特性修改但有一个备选承载可用-MGC通过使用一个ADD.request消息来请求MG1去建立一个新的承载连接。在这种情况下，MG1使用承载控制消息传递来建立一个承载。然后，MGC通过使用一个Sub.request消息来请求MG1去掉先前建立的承载。这个去掉消息便导致承载控制释放消息，或是在sub.request消息之前的一个消息请求发送承载控制释放消息。

图4显示的是一个例示的呼叫消息流，其中显示了在依照本发明的优选实施例建立承载之后进行的修改容许属性的请求和接收。在MGC上接收一个表明应该建立一新呼叫的呼叫控制消息。然后，该MGC通过使用一个ADD.request消息来请求MG1建立一个新的承载连接。同样，对这个实例而言，MGC充当一个呼叫控制器并且MG1充当一个承载控制器。在相同的消息中，MGC请求一个事件，以使MG1可以表示何时建立承载。而MG1则使用承载控制消息传递来建立一个承载。一旦接收到建立承载的确认，则MG1将向MGC发送一个表明建立了承载的通知消息。

一接收到建立了承载的通知或者在这之后，MGC将会发送一个带有修改确认属性的MOD.request，要求MG1为之选择一个值。然后，MG1确定是否可以修改承载特性并且在MOD.response消息中返回恰当的值(是/否)。所述MGC将会保存这个指示，以便在将来使用。

在接收到一个表明应该修改承载特性的呼叫控制消息时，MGC检查所存储的指示，然后执行以下行动之一：

1.如果不支持承载特性修改-MGC通过使用呼叫控制信令来拒绝该呼叫控制修改。

2.如果支持承载特性修改-MGC通过使用一个MOD.request来请求MG1去修改承载特性。然后，MGC使用可应用的承载控制信令来按要求修改该承载特性。

3.如果不支持承载特性修改但有一个备选承载可用-MGC通过使用一个ADD.request消息来请求MG1建立一个新的承载连接。在这种情况下，MG1使用承载控制消息传递来建立一个承载。然后，MGC使用一个Sub.request消息来请求MG1去掉先前建立的承载。这个去掉消息导致承载控制释放消息，或者在sub.request消息之前的一个消息请求发送承载控制释放消息。

图5显示了一个例示的呼叫消息流，其中显示了依照本发明的优选实施例所进行的差错码的接收。在MGC上接收一个表明应该建立一新呼叫的呼叫控制消息。然后，MGC通过使用一个ADD.request消息来请求MG1建立一个新的承载连接。再次地，MGC充当呼叫控制器而MG1充当承载控制器。MG1使用承载控制消息传递来建立一个承载。

在接收到一个表明应该修改承载特性的呼叫控制消息时，MGC通过使用MOD.request来请求MG1修改承载特性。

1.如果支持承载特性修改-则MG1用一个表明“不容许进行承载特性修改”的差错码来拒绝所述消息，并且在一个MOD.reply消息中发送所述差错码。

2.如果不支持承载特性修改-那么MG1使用可应用的承载控制信令来按要求修改承载特性。

如果接收到一个差错码，表明承载特性修改不是MG1的能力，但有一个备选承载可用-则MGC通过使用一个ADD.request消息来请求MG建立一个新的承载连接。MG1使用一个承载控制消息传递来建立一个新承载。然后，MGC将使用一个Sub.request消息来请求MG1去掉先前建立的承载。这个去掉消息导致承载控制释放消息，或者在sub.request消息之前的一个消息请求发送承载控制释放消息。

图6显示的是一个例示的呼叫消息流，其中显示了根据本发明的优选实施例、在建立承载之后对呼叫控制消息中的修改容许的请求和接收。在MGC上接收了一个表明应该建立一新呼叫的呼叫控制消息。然后，MGC使用一个ADD.request消息来请求MG1建立一个新的承载连接。在这里，MGC再一次充当呼叫控制器并且MG1充当承载控制器。MG1则使用承载控制消息传递来建立一个承载。

在接收到一个表明应该修改承载特性的呼叫控制消息时，MGC在所存储的呼叫控制消息中检查所存储的承载特性修改容许指示，且然后执行以下操作之一：

1.如果不支持承载特性修改-则MGC通过使用呼叫控制信令来拒绝呼叫控制修改请求。

2.如果支持承载特性修改-则MGC通过使用一个MOD.request消息来请求MG1修改承载特性。然后MGC使用可应用的承载控制信令来按要求修改该承载特性。

3.如果不支持承载特性修改，但有一个备选承载可用-则MGC通过使用一个ADD.request消息来请求MG1建立一个新的承载连接。MG1使用承载控制消息传递来建立一个承载。然后，MGC使用一个Sub.request消息来请求MG1去掉先前建立的承载。这个去掉消息导致承载控制释放消息，或者在sub.request消息之前的一个消息请求发送承载控制释放消息。

图7示意性描述了一个例示的呼叫消息流，其中显示的是在建立承载之后对呼叫控制消息中的修改容许的请求和接收，在该承载建立中所述承载是由驻留在不同于MG1的一个节点中的另一网络实体建立的。特别地，在图7中，承载是在经过呼叫控制信令、在来自呼叫控制服务器的请求下由另一个网络实体建立的，并且所述承载描述了本发明的另一个实施例。

参考图7，在MGC上接收一个表明应该建立一新呼叫的呼叫控制消息。然后，MGC通过使用一个ADD.request消息来准备一个新承载连接。之后，MGC经过一个呼叫控制协议来请求由另一个网络节点建立所述承载。在对建立承载的请求做出的响应中，一个关于是否可以对承载特性进行后续修改的指示将会返回到MGC。

在接收到一个表明应该修改承载特性的呼叫控制消息时，MGC对在承载建立时在呼叫控制消息中返回的承载修改容许指示进行检查，且然后执行以下操作之一：

1.如果不支持承载特性修改-则MGC通过使用呼叫控制信令来拒绝该呼叫控制修改。

2.如果支持承载特性修改-则MGC通过使用一个MOD.request消息来请求MG1修改该承载特性。作为选择，MGC使用恰当的呼叫控制信令来请求另一个网络节点执行承载特性修改。

3.如果不支持承载特性修改，但有一个备选承载可用-则MGC通过使用一个ADD.request消息来请求MG1准备一个新的承载连接。然后，MGC经过呼叫控制信令来请求从另一个网络节点对新的承载连接端点进行承载特性修改。随后，所述MGC使用一个在此并未详述的Sub.request消息来去掉先前建立的端点。这个去掉消息导致承载控制释放消息，或者在sub.request消息之前的一个消息请求发送承载控制释放消息。

应该理解的是，在图3到7中描述的优选实施例并不限于那些可用于提供表明承载控制器修改承载特性的能力的指示的消息。举例来说，可以在一个MOV.request而不是MOD.request中请求修改承载特性，并且对于一个指示的请求可以是在MOD.req而不是ADD.req中。

本发明的实施例适合于固定和/或移动电信系统，尤其适合于那些符合ETSI 3GPP R4标准版本的第三代或3GPP网络。

由于可以在不脱离本发明基本特征的精神的情况下以若干种方式来实现本发明，因此应该理解的是，除非另作说明，否则上述实施例并未对本发明加以限制，而是应当在所附权利要求定义的本发明的精神和范围以内对其进行广义的说明。此外还预期将多种修改和等价方案包含在本发明和所附权利要求的精神和范围以内。

Claims (19)

1.一种在电信系统中管理呼叫的方法，所述系统包括一个网络，该网络具有至少一个实现呼叫控制功能的呼叫控制器和至少一个实现承载控制功能的承载控制器，该至少一个呼叫控制器和该至少一个承载控制器由一个垂直控制协议接口分离，所述方法包括以下步骤：

在该电信系统内从该至少一个承载控制器传递到该至少一个呼叫控制器的至少一个消息中提供一个表明该至少一个承载控制器修改承载特性的能力的指示；以及

将所述指示存储在该至少一个呼叫控制器中；以及

在该至少一个呼叫控制器接收到表明应该修改承载特性的呼叫控制消息时，对所述存储的指示进行检查，以便确定是否可以修改承载特性。

2.如权利要求1所述的方法，其中所述指示涉及该至少一个承载控制器在呼叫的活动阶段期间修改承载特性的能力。

3.如权利要求2所述的方法，其中所述至少一个消息是一个媒体网关控制协议消息。

4.如权利要求2或3所述的方法，其中所述至少一个消息包含一个错误码，所述错误码表明该至少一个承载控制器没有修改承载特性的能力。

5.如权利要求2或3中所述的方法，其中所述至少一个消息是由一个在协议扩展包中定义的事件调用的。

6.如权利要求2或3中所述的方法，其中所述至少一个消息包含一个在协议扩展包中定义的属性。

7.如权利要求1或2中所述的方法，其中所述至少一个消息是在呼叫建立期间提供的。

8.如权利要求7中所述的方法，所述至少一个消息被包含在一个呼叫控制信令规程中，所述呼叫控制信令规程包括一个建立承载的请求。

9.如权利要求8所述的方法，其中所述至少一个消息是一个无线电接入网络控制消息。

10.如权利要求1到3中任何一个权利要求所述的方法，其中所述至少一个消息是在呼叫的活动阶段期间提供的。

11.如权利要求1到3中任何一个权利要求所述的方法，其中在呼叫的活动阶段期间，由呼叫控制器接收一个修改现有承载特性的请求，所述方法还包括以下步骤：

为现有呼叫的承载控制器检索关于该承载控制器修改承载特性并且尝试满足所述请求的能力的指示；

在承载控制器包括承载特性修改信令的能力时，调用该现有承载的一个承载特性的修改程序；

当承载控制器不包括承载特性修改信令的能力时，调用一个具有所要求的承载特性的备选承载的建立程序。

12.根据权利要求11的方法，其中如果不能满足所述请求，则传递一个拒绝所述请求的消息。

13.一种电信系统，包括一个网络，所述网络具有至少一个实现呼叫控制功能的呼叫控制器以及至少一个实现承载控制功能的承载控制器，所述呼叫控制器和承载控制器由垂直控制协议接口分离，所述系统可操作用来从所述系统内传递的至少一个消息中获取与该至少一个承载控制器在呼叫的活动阶段期间修改承载特性的能力有关的信息，此外所述系统还可操作用来接收一个在呼叫的活动阶段期间修改承载特性的请求，所述系统包括：

第一装置，用于检索所述获取的信息，以便确定是否可以满足所述请求；

第二装置，用于在至少一个承载控制器包括承载特性修改信令的能力时修改一个现有承载的承载特性；以及

第三装置，用于在至少一个承载控制器不包括承载特性修改信令的能力时选择具有所要求的承载特性的多个承载中的至少一个承载；

其中所述第一装置刚一确定可以满足一个请求，就使用第二和第三装置来满足所述请求。

14.一种媒体网关控制器，包括：

用于在电信系统内从至少一个媒体网关传递的至少一个消息中接收一个表明该至少一个媒体网关修改承载特性的能力的指示的装置；

用于将所述指示存储的装置；以及

用于在接收到表明应该修改承载特性的呼叫控制消息时对所述存储的指示进行检查以便确定是否可以修改承载特性的装置。

15.如权利要求14所述的媒体网关控制器，其中所述媒体网关控制器可操作用来接收对一个指示的请求，所述指示表示的是至少一个媒体网关对由该媒体网关建立的承载的特性进行修改的能力。

16.如权利要求14或15所述的媒体网关控制器，其中所述指示涉及该至少一个媒体网关在呼叫的活动阶段期间修改承载特性的能力。

17.如权利要求14或15所述的媒体网关控制器，其中所述指示是在消息中传递的，所述消息包括一个差错码，所述差错码表示的是该至少一个媒体网关没有能力修改由所述至少一个媒体网关建立的承载的特性。

18.如权利要求14或15所述的媒体网关控制器，其中指示是在消息中传递的，所述消息是由协议扩展包中定义的事件来调用的。

19.如权利要求14或15所述的媒体网关控制器，其中指示是在消息中传递的，所述消息包括一个在协议扩展包中定义的属性。

Images