CN101601224B - 在下一代网络中固定ip载体流的路由 - Google Patents

Abstract

用于扩展NGN的IMS/SIP体系结构以向通用载体流提供QoS服务的方法和系统。更特别地，提供一种在其中带外信令协议被用于建立通信会话的多域通信网络中建立通信会话的载体端对端路径的方法。该方法包括接收带外信令消息，所述消息包括代表所述端对端路径的第一载体段的至少相对端点的信息。该信息被用于定义通过所述网络的节点的交叉连接映射，所述节点在由该节点所主管的第一载体段和第二载体段的各自本地端点之间。代表该交叉连接映射的信息然后被插入到带外信令消息中，并且该带外信令消息被转发。

Description

在下一代网络中固定IP载体流的路由

技术领域

本发明涉及下一代网络，并且尤其涉及在下一代网络中固定(pin)互联网协议(IP)载体流的路由。

背景技术

目前，各种国际标准体和国际标准协会——诸如第三代合作伙伴项目(3GPP)、欧洲电信标准学会(ETSI)和国际电信联盟(ITU)——都参与到发起定义下一代网络。根据ITU-T，下一代网络(NGN)是基于分组的网络，其能够提供包括电信服务在内的服务以及能够利用多宽带、QoS使能的传送技术，并且在该网络中服务相关的功能与底层传送相关的技术无关。NGN提供对不同服务供应商的无限制的用户访问。它还支持广泛的移动性，其允许向用户供应一致和普遍的服务。

下一代网络大体上基于互联网多媒体子系统(IMS)体系结构，并利用会话初始化协议(SIP)来管理多方之间的通信会话的建立和拆卸。这种设置的有利之处在于，IMS/SIP提供一种以防欺诈的方式建立包括基于互联网协议的话音(VoIP)电话呼叫的多媒体会话的互联网协议(IP)网络框架，，并且其允许使用非常类似于那些当前由公共交换电话网(PSTN)和蜂窝网络运营商所采用的方法来从事随后的记账和域间结算。就是说，可以针对每个单独的呼叫/会话为用户开具有与所传送的服务相关费用的账单，并且这些费用可以被适当分配给由呼叫/会话所穿过的每个载体网络(或管理域)。

如PSTN那样，设想NGN由许多运营商/管理域组成，并且IMS体系结构为一个运营商的订户提供基础以与另一运营商的订户建立语音呼叫或多媒体会话，其中两个运营商(以及任何中间运营商)都在他们各自的管理域中保留了必要的网络资源以支持为载体分组流所需要的服务质量(QoS)，所述载体分组流载有与该会话相关联的语音或多媒体流。另外，IMS体系结构完全支持终端用户的漫游，其中访问域如主域一样以相同的方式支持载体流QoS。

图1示意性地示出有代表性的下一代网络体系结构。如在PSTN和互联网中一样，希望NGN是多个管理域网络的集合体。管理域的业务可能主要是服务终端客户或主要是向其它管理域提供传输。对本申请来说，提供传输的管理域的网络被称为传输网络(TN)2。服务终端客户的管理域由两种类型的网络组成：核心IP网络(CN)4和一个或多个附着(或“接入”)网络(AN)6，该附着网络6经由附着网关将终端客户的终端设备(TE)8“附着”到核心网络4上，从而他们可以接收到IMS服务。通常认为AN与其所连接的CN在相同的管理域中，即使在这些AN由CN运营商购买“批发接入(wholesale access)”的分离业务实体(AN运营商)操作时也是如此。注意到，当传输网络和核心网络都基于每个分组报头中的目标IP地址路由IP分组时，AN在TE和CN的附着点之间传送分组，而不考虑IP地址。虽然附着网络可以如有线电路或时域复用(TDM)电路一样简单，但它通常由特定于媒介的第一英里网络和更一般的分组回程网络组成(在3GPP无线术语中，该回程网络由术语“核心”表示，但它仍是AN的一部分并不会和CN混淆)。

在图1所示的网络体系结构中，通过由每个网络中的传输边界网关(TBG)14所主管的交换链接12在各个核心网络和传输网络之间传送分组。对任何的网络对来说，交换链接可以是物理链接或某种形式的虚拟电路。本领域的技术人员会知道，还可以将多个网络通过无连接的交换网络(XN)进行互联。XN可在从单以太网交换机到全球IP网络或虚拟专用网络的范围内变化。

IMS被指定使用会话初始化协议(SIP)来建立和拆卸多媒体呼叫或会话。IMS体系结构指定多个分布在整个网络中的、根据SIP消息进行处理和动作的呼叫状态控制功能(CSCF)16。在建立特定的会话时，SIP消息传递需要由至少与会话的发起方相关联的发起服务CSCF(S-CSCF)来处理，并且建立与会话的对象或目标相关联的目标S-CSCF。然而，SIP客户端通常不直接与他们关联的S-CSCF对等，并且在SIP客户端和他们关联的S-CSCF之间以及在发起CSCF和目标CSCF之间存在路由并转发SIP消息的中间CSCF。与本申请特别相关的是负责在管理域之间转发SIP消息的对等CSCF。在本说明书中，我们将任何这样的CSCF指定为边界CSCF(b-CSCF)：其是在管理域中将SIP消息转发给另一域的最后一个CSCF，或是在管理域中从另一域接收SIP消息的第一个CSCF。那些熟悉3GPP和/或其它NGN标准要点的人会知道，存在一些关于如何架构边界控制功能的争论。术语“b-CSCF”意图包含这样的功能组件，如询问CSCF(I-CSCF)、互联边界控制功能(IBCF)和中断网关控制功能(BGCF)的方面。当边界控制不是运营商的强烈要求时，则甚至S-CSCF都可以是b-CSCF。

在附着网络中不存在CSCF——所谓的代理CSCF(P-CSCF)的对等体实际上是终端设备的SIP客户端功能。因为SIP客户端、尤其是在应用服务器(AS)8b中的SIP客户端可直接对等于S-CSCF，因此在本说明书中，我们使用术语周边CSCF(p-CSCF)来指代第一个/最后一个处理来自/发向SIP客户端8的SIP消息的CSCF。图1描绘了在漫游TE 8(附着到被访问核心网络)和应用服务器AS 8b之间建立会话时的相关CSCF，其中主核心网络被传输网络2分开。

会话的媒体流作为载体(分组)流而传输穿过网络。在IP分组环境中，载体流路径不是自动地与由SIP信令所穿越的路径相同，因为不要求载体流路径穿过主管CSCF功能的节点。域间载体流存在并且在节点处进入管理域，所述节点在此被指定为传输边界网关(TBG)14。再次，在附着网络和核心网络之间的情况是不同的：在核心网络中与附着网络对接(interface)的节点被不同地称为服务边缘、核心网络边缘、边界节点、接入媒体网关、接入路由器或者特定于接入网络类型的术语，诸如GPRS网关支持节点(GGSN)或宽带远程接入服务器(BRAS)。在本说明书中，我们将使用术语附着网关(AG)10。AG跨接AN 6和CN4之间的边界。指定载体流QoS要求

正如本领域已知的，发起会话的SIP消息载有将与该会话相关联的载体流(或者多个载体流，如果需要的话)的描述，这种描述在形式上是会话描述协议(SDP)的参数。例如参见Handley，M.和V.Jacobson，“SDP：session description protocal”，Request forComments 2327，1998年4月。目前，SIP消息的SDP部分给出载体流会包括什么(也就是，语音或视频以及会使用什么编解码器和比特率)的完整描述。这个信息最初意图使得终端系统能够指定它们想如何将语音或者视频数据编码成实时协议(RTP)分组。

在IMS解决方案中，SDP参数还可被介于终端系统之间的不同网络域中的CSCF解释，以便于确定载体路径网络特性如何。通常，从媒体线(media line)(始于m＝)SDP导出这个信息。例如在m＝audio8004RTP/AVP 9中的最后一个参数指示根据视听资料(AVP)9所编码的音频载体流，其刚好是G.722，其是64kb/s流(网络要求必须包括分组报头等，并且使其逼近100kb/s左右)。

基于SDP参数，CSCF执行被称作连接允许控制(CAC)的过程，虽然该过程更准确地被称为会话允许控制。CAC过程确定载体流的资源要求，从而可以用期望的QoS来传递嵌入式媒体流。如果域没有支持新载体流的资源，则相关CSCF将中止会话建立。在3GPP文献《3GPP TS23.207》中提供对此(针对p-CSCF和AG)的描述。业务类别

业务类别是由不同业务管理模型中的不同术语获得的稍微有点模糊的概念。在IETF IntServ模型中，存在三个业务类别：“有保证的”、“受控负载”和“尽力服务”。稍有相似，IETF DiffServ模型提供三种类型的业务转发行为：加快转发(EF)、确保转发(AF)(虽然可以存在高达4类AF业务)和默认(Default)或尽力服务。ITU研究组根据延迟和抖动(以及吞吐量)加上诸如分组丢失率以及怎么处理超出规格或者滞后的分组的因素来定义用于服务的业务类别。

在NGN的实际部署中，将会存在一种待用于实时对话的其中延迟和抖动都将是可能最小的业务类别(或者运营商可挑选若干这样的类别：一种用于语音对话、一种用于视频电话、一种用于游戏)，以及另一种适用于媒体流播放的保证有限抖动的吞吐量的类别(再次地，运营商可选择在语音和视频之间进行区分)。因为从没有任何专用于尽力服务业务的资源，所以使用SIP来建立尽力服务载体流的实用性很小，但是为了完整性目的，可定义这样的码点。QoS控制和处理的范围

图2示出被分成多段20的载体流18。载体流的每一段20都穿过单个分组传输网络2-6并且被终端装置或网关14划界。可以由在其上传输载体流20的网络的类型来命名载体流20：对于穿过附着网络的载体流的部分命名为附着段，等等。

向载体流分组提供专门处理的需要可以不从一端延伸至另一端。所广泛接收的是，如果特定的分组传输网络被过量供应，则对所有分组的QoS处理将足以支持任何特定的载体流。本领域的技术人员还将知道，可使用Diffserv来模拟具体业务类别的过量供应。设想，一些或者所有核心网络都被过量供应(或者使用Diffserv来模拟IMS分组的过量供应)，其结果是不需要为穿过这种被过量供应的核心网络的载体流的核心段储备资源。然而，很可能的是，将必须为附着段储备资源，以便于保证那些段上的流分组的传输不会使端端流的QoS降低到对于该流所支持的服务可接收的QoS之下。资源及允许控制功能(RACF)

为载体流保留资源的功能与对载体流是其组成部分的会话的允许控制密切相关。如果对现有会话假设当前承诺，链接上的带宽容量、节点处的转发容量不足或者缺少为新会话的载体流传递被要求QoS而所需的其它资源，则中止会话建立并且释放为该会话已经保留的任何资源。

更一般地，在建立会话之前，需要就是否允许该会话做出多个策略决策。在IMS体系结构中，这些决策源自CSCF、通过对会话建立中的第一消息(SIP INVITE消息)的处理来触发。一些策略决策的执行局限于CSCF，但是关于载体流QoS的那些由进行控制的CSCF发信号给将处理载体流的网关。图3示出针对包含两个域的会话、分别由p-CSCF和b-CSCF在附着网关(AG)10和传送边界网关(TBG)14中对RACF功能的控制。那些熟悉NGN标准的人会知道，在IMS体系结构中，在CSCF和网关之间存在中间策略决策功能(PDF)，形成RACS(资源及允许控制子系统)网络层。除了在请求QoS载体流的不同应用之间进行仲裁之外，PDF也可为CSCF呈现附着网络QoS控制细节的抽象视图以及隐藏AG和TBG的拓扑。

尽管具有优点，NGN在下述方面受到限制：由载体流的互联网协议(IP)分组所穿过的路由通过常规的分组转发技术来确定，因此可以或者可以不遵循由用于建立该流的SIP消息传递所穿过的路由。这为NGN的部署提供了障碍，因为对于网络供应商来说不可能把穿过他们网络域的IP分组与特定的载体流进行适当的关联，而这反过来防止了与当前由公共交换电话网(PSTN)和蜂窝网络运营商所使用的那些账单结算相似的适当账单结算。

因此，仍然非常期望能够在下一代网络中固定互联网协议(IP)载体流的路由的方法和技术。

发明内容

本发明的目的是提供能够在下一代网络中固定互联网协议(IP)载体流的路由的方法和技术。

因此，本发明的一方面提供一种在其中带外信令协议被用来建立通信会话的多域通信网络中建立通信会话的载体端对端路径的方法。所述方法包括接收带外信令消息，所述消息包括代表端对端路径的第一载体段的至少相对端点的信息。所述信息被用于定义通过网络节点的交叉连接映射，所述节点在由所述节点所主管的第一载体段和第二载体段的各自本地端点之间。代表交叉连接映射的信息然后被插入到带外信令消息中，并且所述带外信令消息被转发。

本发明不特定于任何特别的业务管理模型，而是只假设存在由运营商议定的某多个业务类别，并且载体流的期望业务类别可以被指定为SDP中的参数。

本发明假设，对于每个AG都存在p-CSCF(并且同样地，对于每个TBG都存在b-CSCF)，所述p-CSCF可以请求对通过那个网关的载体流进行QoS处理，而不考虑用于其交互通信的中间PDF、节点和特定协议选择的数量(如果有的话)。特别载体流的载体段的QoS处理可以单端方式通过将策略推向在该段的一端处的网关来设置，或者以双端方式通过将策略推向在该段的两端处的网关来设置。如上面所定义的，网关是载体流的一个载体段的端点和其下一载体段的开始：推向网关的单个策略可用于为两个段请求QoS资源。

本领域的技术人员会知道，存在几种用于请求网关为载体段提供QoS的不同方法：所谓的“推”方法导致网关直接从CSCF(或者通过策略决策功能的层次)来接收“策略决策”以向载体段提供指定的QoS，然后网关答复CSCF，该网关具有资源来“推行”策略或者该网关不具有资源。后面的描述根据RACS的“推”模型来表述，但是本发明意图不依赖于QoS请求如何传送网关进行工作。事实上，如本领域的技术人员会知道的，“带宽中间装置(broker)”可能对链接或者网络上的带宽资源保持跟踪，而不向端点处的网关发送信号。然而，假如段在域间边界开始或者结束，则存在网关将把新载体段的规范发信号给这些网关的额外原因：管理监督载体流、改变Diffserv标记、生成记账记录。虽然不可能需要在交换链接或者网络上进行实际资源储备，但是RAC功能将很可能被b-CSCF调用，以便检查每个管理域与其准备从其它管理域接收的流的类型和数量有关的策略遵守。

附图说明

根据以下详细描述并结合附图，本发明的进一步特征和优点将变得明显，在附图中：

图1是示意性示出有代表性的下一代网络的框图，在该下一代网络中可实施本发明的方法；图2是示意性示出在图1网络中的载体流段的框图；图3是示意性示出针对包含两个域的会话、对资源及允许控制功能的控制的框图；图4是示意性示出根据本发明的方面使用网络地址映射来固定载体段的框图；图5是示意性示出根据本发明的方面使用网络地址映射来在包括多个载体段的网络中固定载体段的框图；图6是示意性示出根据本发明的方面使用网络地址映射来在包括多个IP地址范围的网络中固定载体段的框图；图7是示意性示出根据本发明的方面的支持非SIP客户端的方法的框图；图8是示意性示出根据本发明的方面的在包括多个IP地址范围的网络中支持非SIP客户端的方法的框图；图9是示意性示出根据本发明的方面的与遗留协议交互工作的方法的框图；图10是示意性示出根据本发明的方面的RSVP到SIP交互工作的方法的消息流图；图11是示意性示出根据本发明的方面的RSVP到SIP交互工作的方法的消息流图；图12是示意性示出根据本发明的方面的操作服务器以支持与遗留协议交互工作的框图；图13是示意性示出根据本发明的方面的操作服务器以支持RSVP到SIP交互工作的消息流图；图14是示意性示出根据本发明的方面的操作服务器以支持RTSP到SIP交互工作的消息流图。

要注意的是，在整个附图中类似特征由类似的参考数字标识。

具体实施方式

本发明提供能够在下一代网络中进行通用载体流的QoS处理的方法和技术。本发明的实施例在下面参考图4-14仅以示例方式进行描述。

大体上，本发明提供可以单独用来或者可以组合用来扩展NGN的IMS/SIP体系结构以为通用载体流提供QoS服务的方法和系统。这些方法和系统可以概括地分为四类，即：将SIP扩展到通用载体流；将通信会话的载体流固定到由用于建立该会话的SIP信令所穿过的AG和TBG；对非SIP客户端的支持；以及用于遗留IP信令的网关功能。这些类中的每一个都将以有代表性示例的方式在以下描述中进行解释。

应注意，本申请主要针对用于将载体流固定到由用于建立会话的SIP信令所穿过的AG和TBG的技术。用于支持非SIP客户端的技术和用于遗留IP信令的网关功能分别是申请人的共同待决的美国专利申请号xx/xxx,xxx、题为“Serving Gateway Proxies for Non-SIPSpeakers in a Next Generation Network”和yy/yyy,yyy、题为“Providing SIP Interworking in a Next Generation Network”的重点，这两个申请都与本申请同时提交。通用载体流

如当前所定义的，SIP和IMS所受的限制在于它们只能处理为多媒体流的载体流。然而，许多其它有益应用可以利用IMS基础结构，如果它们的载体流被IMS识别的话。

根据本发明的一个方面，可以通过将描述通用载体流的QoS请求的明确业务规范(T-Spec)参数添加到SIP信令中的SDP以及扩展IMS中的RACS机制以解释新的T-Spec参数来克服这个限制。将明确的T-Spec参数添加到SIP信令中的SDP部分使得两个SIP端点能够请求网络为任意流(通用载体流)执行资源分配和/或连接允许控制。因此，尽管对于RTP或多媒体载体流而言IMS功能元件从媒体编码和其它媒体描述SDP参数中推断资源要求，但是对于通用载体流而言CSCF将使用明确的T-Spec参数作为资源及允许控制过程的基础。

例如，考虑一个其中采取ITU建议Y.1541的服务指定类别的网络。在这种情况下，按照准则RFC 2327，明确的T-Spec可以由两个媒体层级属性线组成：一个指定服务的Y.1541类别，而另一个指定所需要的容量或带宽。因此，可以使用：a＝ITU-CLassOfService：0a＝ITU-Capacity：100来指定所需要载体流100kb/s和服务类别0(也就是按照Y.1541，端对端延迟少于100毫秒等)。

如果期望的话，可使用其它方法来表达明确的T-Spec参数。例如，在上述的表示实施中，运营商可选择对带宽和业务类别的组合指定名称，这使得能够使用单个SDP属性(也就是所指定的名称)来提供明确的T-Spec。示例性使用：

旅行中的企业员工使用VPN客户端以从她的膝上型电脑建立回到其企业VPN服务器的IPSec隧道，从而她可以访问企业网络的设施，包括它的IP PBX以发出和接收电话呼叫。如果通过尽力服务互联网建立这个IPSec隧道，则加密分组的延迟、抖动和丢失率将是不确定的并且可能不足以支持在她的膝上型电脑的软客户端和企业IP PBX之间的VoIP会话。为了得到适合于IPSec隧道中的语音分组的保证QoS，需要将IPSec隧道作为通用载体来处理。

支持通用载体的运营商可选择针对每个业务类别的有限带宽量(传输容量)进行定价，然后为传输容量和业务类别的每种组合给出标准名称。示例可以是：vote1(语音电话)＝100kb/s最小延迟，最小抖动，每分钟费用$0.02，vidte1(视频电话)＝1Mb/s最小延迟，最小抖动，$0.10.sdtv(标准清晰度电视)＝1.5Mb/s下行，保证吞吐量，$0.03；hdtv(高清晰度电视)＝8Mb/s下行，保证吞吐量，$0.06；分别是针对语音电话、视频电话、标准清晰度视频流和高清晰度视频流而设计的。然后，标准名称将用作SIP消息的SDP部分中的唯一T-Spec参数。在这个示例中，将“vote1”QoS分配给通用载体将足以支持用户VoIP会话。

企业网站的VPN服务器附着到某个运营商的NGN网络，并且用该域来注册。针对本说明书假设：如果在VPN客户端和VPN服务器之间存在多个管理域，则VPN客户端和VPN服务器之间的IP分组的正常路由行为如SIP信令一样穿过相同的域链；并且关于分组使用哪些TBG14不存在不确定性(在下面详细描述固定载体流以使用特定的TBG)。

VPN客户端8的SIP客户端部分22在公共IMS域中注册。结果，根据IMS的正常操作，主s-CSCF现在可以发送客户端SIP信令消息。(注意，VPN客户端8的SIP客户端部分22与膝上型电脑上的软电话SIP客户端有所不同——它们可共享公共代码，但是最终软电话SIP客户端将用企业IP PBX注册。可替换的实现形式可使用能被双重注册的单个SIP客户端)。

VPN客户端8和VPN服务器之间的安全关联的建立则以使用IKE(互联网密匙交换)协议序列的正常方式来进行，附加条件是由VPN客户端在其IKE消息中确定的身份必须可由VPN服务器翻译成VPN客户端的SIP身份(URI)。这可以通过使VPN客户端的身份作为其SIP URI来保证，但是对于甚至更高的安全性而言，客户端的SIP地址可以作为授权过程的结果而被返回(例如，部分半径或直径响应)。

一旦VPN服务器验证了客户端(事实上在IKE的两个阶段都完成之后)，该VPN服务器通过在公共域中发布SIP INVITE消息来给VPN客户端打“电话”。SDP中的F-Spec识别已经达成一致的隧道端点。(注意，标准IPSec分组在它们的报头中没有端口号，而是具有对给定的地址对之间的每个隧道独有的安全参数索引字段。这个字段可以用在F-Spec中，但事实上因为网络中存在NAT，为VPN接入的操作方式建立隧道(tunneling)的正常模式是把IPSec分组封装在UDP数据报中，因此F-Spec的正常方式用来识别分组的IPsec隧道流。)在一个操作模式中，VPN客户端的T-Spec被作为授权过程的一部分返回给VPN服务器，也就是，每个VPN客户端总是具有由管理员设置的固定QoS层级。在这种情况下，T-Spec被作为SDP的一部分包括在来自VPN服务器的INVITE消息中。

在IMS的正常方式中，SIP INVITE信令消息被通过公共IMSCSCF转发给VPN客户端的SIP客户端部分。

客户端首先需要将输入信令与安全关联相结合(我们假设，安全参数索引即使不是F-Spec的一部分也包括在SDP中，参见上文)。在VPN客户端用户开始选择所需要的服务类别的操作模式中(例如，用户可以指定他们是否意图发出/接收语音呼叫或者视频呼叫)，VPN客户端将为该隧道创建T-Spec并将其包括在回到VPN服务器的SIP响应中。(据推测，该响应将是200OK消息)

IMS系统建立会话，以通知AG和TBG IPSec隧道穿过其F-Spec并且指示它们提供如T-Spec所指定的QoS处理。IMS系统还将生成所需要的记账记录，从而随后可以将服务账单送给企业。

VPN服务器到客户端之间的IPSec隧道现在是通用载体路径：由客户端或者服务器所发送的与F-spec匹配的分组被保证在它们穿过的每个域中进行所指定的QoS处理。注意到，因为加密隐藏了隧道中所有分组的真实报头，所以所有分组都得到一致的QoS处理。同样地，因为IPSec可依赖于序列完整性，所以将原diff-serv标记转换成IPSec分组报头并使用它们以对不同的分组类别提供不同的QoS处理不是好主意。相反，如果实施方式想将IPSec通用载体中的业务限制为仅(加密的)多媒体流，则该实施方式将不得不为多媒体流和尽力服务业务建立单独的IPSec隧道——不需要使用SIP为尽力服务隧道请求QoS处理，但是可以为不同类型的流建立不同的IPSec隧道，每个都用单独的T-Spec参数发信号。

安全建立刚一丢失，VPN服务器就结束SIP会话。

本领域的技术人员会知道，上面存在许多种变型。具体而言，可能的情况是不在隧道建立期间从网络请求对IPSec隧道的QoS处理，而只在实际启动语音呼叫时或者甚至只在尽力服务传送的受监控性能在呼叫期间低于某个阈值时才从网络请求对IPSec隧道的QoS处理。IP-Sec隧道刚一启动，进一步的提高就可以使服务器建立具有最小QoS处理的通用载体流，但是然后服务器可以响应于隧道内的探听消息(例如在软电话客户端和IP PBX之间的SIP消息)和/或应企业域内服务器的请求而使用SIP reINVITE来修改流的服务类别/带宽。固定载体流

如图1所示，会话的端点可用穿过几个域的会话的SIP信令和载体流而附着到不同的(核心)网络上。目前，在IMS中没有将太多注意力放在载体流中的分组所遵循的路径上——一般假设，这些分组将遵循由IP路由确定的路径。另一方面，SIP信令的路由被至少部分地定义为经由一系列CSCF，其中CSCF是相互成对的对等体。在NGN中，在每个CSCF处对SIP消息的转发选择由策略规定(基于商业传输协议等。)。因此，在发起方和终止方在不同域的情况下，SIP信令穿过的中间域不必全部是相同域，从发起方发送并传递给终止方的分组在IP转发规则的正常操作下穿过所述相同域。

然而，有两个好的理由来解释为什么载体流的路径不应只由IP路由来确定，而是要被明确地设置成穿过特定域和特定传输边界网关(TBG)。首先，从商业的角度，由于如果域不知道流属于什么会话则该域就不能为其生成记账记录，所以可能强烈要求会话的流不应穿过不参与该会话信令的域。其次，QoS到载体流的传递通常要求通知路径上的网络元件授权载体流接收QoS。因此为了核心网络上和/或交换链接上的QoS，载体流的路径必须受限于通过(固定到)由b-CSCF在会话建立时所选择的TBG，因为b-CSCF只可以将授权发送给它们所控制的TBG。

除了上面两个之所以固定载体流的原因，建立会话时所涉及的CSCF可确定载体流需要通过某种类型的媒体网关。可在载体流路径中要求媒体网关执行对媒体样本的译码，因为会话端点相互间不具有共同的编解码器。媒体网关的另一用途可以是：因为端点之一服从合法拦截(LI)命令，并且会话的媒体流需要通过LI网关，从而可以制作这些媒体流的副本以安全地转发给相关的合法机关。

本发明的第二方面为会话的载体流提供一种路径固定机制以使载体分组穿过在会话建立时所确定特定的网关链。下面的描述和图4-6集中讨论将载体流固定到传送边界网关(TBG)上，但是基于本文所提供的描述，其扩展为覆盖固定到其它网关(媒体翻译、合法拦截等)对于本领域的技术人员来说是显而易见的。如先前所述以及在图2中所描绘的，可以将载体流分成载体(流)段20的串行级联。除了第一流段的起点以及最后一段的终点之外，这些载体段在网关14处开始和结束。当要将载体流固定到TBG 14时，中间载体段20的起点和终点是TBG14。

注意，因为附着网络6不跟随IP转发，所以在特定AG 10附着到网络期间针对特定终端8或者服务器8b的业务被固定到该AG，也就是第一载体段和最后一个载体段总在适当的位置。所公开的机制使得在AG 10之间固定载体路径。网络元件性能：

下面在三部分中公开用于固定载体流的机制。首先描述，当所有网络元件都在相同的IP地址范围内时，该机制如何工作；然后描述，当客户端TE在专用IP地址范围内但是所有运营商域都在单个IP地址范围内时，该机制将如何工作；最后描述，当不同的核心网络属于不同的IP地址范围时的工作方式。在所有三种情况下，假设了相同的性能，即：网关(包括TBG、AG和特殊媒体网关)可以对载体流分组的报头执行NAT翻译；并且CSCF是SIP应用层网关(ALG)，其可以翻译SIP消息中的SDP中的IP地址和端口号(F-Spec)，并且可以控制由它们所控制的网关执行的NAT翻译。如图1所示，p-CSCF控制AG，b-CSCF控制TBG——媒体网关很可能由S-CSCF或者代表控制。

存在两种可能的方案来调节CSCF对F-Spec的更改以及网关中NAT映射的设置。在第一方案中，CSCF确定映射并将其推向网关，该网关或者安装该映射或者如果该映射不可用的话(例如翻译表已满)则返回错误响应。可替换地，CSCF可以通过提交原IP地址和端口而从网关请求映射，并且从该网关接收作为响应的完整映射。

在任一种方案中，CSCF在将SIP消息继续转发给下一CSCF之前更改SDP中的F-spec部分。注意，安装NAT映射可以是从CSCF到网关的更大的一般策略推动(例如，安装QoS策略)。

注意，该公开不讨论选择哪些特定TBG来形成固定点的链的方法(这是SIP路由问题的一部分)，而只是描述这样的机制：通过该机制更改正常的IP路由行为以确保载体流的分组通过所选的TBG。基础机制

这部分公开了一种针对域集合(confederation)实现载体流的固定的方法，所述域全都是相同IP地址范围的部分(例如，或者是IPv4或者是IPv6的公共地址域)。如上所述，载体流的SDP参数隐含地包括载体流的F-Spec，该F-Spec通过源IP地址和目标IP地址、分组类型以及源端口号和目标端口号来识别该流。严格来讲，F-Spec识别单向流，但是显然，反向流的F-Spec可以简单地从原F-Spec生成，所以当期望建立双向流时，我们仍将讨论单个F-Spec。在该第一实现中，所有的F-Spec IP地址都属于相同的IP地址范围。

该方法的实质在于，在SIP信令路径上的CSCF通过更改继续传输给下一CSCF的F-Spec而将载体流分成载体段，从而经过修改的F-Spec只描述由所包含的CSCF所控制的网关之间的载体段。然后，CSCF在那些网关中安装双向“交叉连接”映射，从而输入载体段中的分组通过网关转发到下一载体段上。在这里所描述的具体实例中，“交叉连接”映射是NAT映射，并且分组到下一载体段的转发通过以下步骤来实现：对输入分组报头中的地址和端口执行NAT翻译以便使它们转变为载体路径的下一段的分组，然后根据正常的IP路由程序将分组转发。

参照图4，首先针对包含两个域的会话初始化来更详细地描述该机制，为了标注方便这两个域示为左侧域和右侧域：在图4中，会话初始化由SIP客户端TE 8在左侧域中发起并且在右侧域中终止于SIP客户端AS 8b，所以SIP INVITE消息从左至右地穿过，并且诸如200OK的响应从右至左传播。要描述的处理应用在域之间的每个边界处，从而当存在所涉及的多余两个域时，则左侧域是最接近发起方的一个(将INVITE消息转发给右侧域)，而右侧域是最接近终端方的一个(将200OK消息转发给左侧域)。

在图4中，在要建立会话初始化的载体流中，载体流的TE端被指定为在IP地址A和端口a处发起/终止，对于所述的IP地址A和端口a，我们使用术语Aa。在SIP会话初始化的开始，用于载体流的AS端的地址和端口号不为TE 8所知，因此由TE 8发布的SIP INVITE消息24的SDP中的F-Spec是不完整的，并可被表示为[Aa，？？]。

当由TE 8发布的SIP INVITE消息到达左侧域的边界处的b-CSCF时，该b-CSCF选择TBG 14以固定经过的载体路径，并且为该TBG请求或生成映射(在26处)以应用于Aa。假设结果是 $\mathrm{Aa}\⇒\mathrm{Bb}$ 的映射，则b-CSCF修改F-Spec，将TE的原IP地址和端口Aa用RBG的IP和端口Bb替换，并且将INVITE(在28处)转发给其在右侧域中的对等体。当INVITE消息到达对等b-CSCF时，该b-CSCF可选择在右侧域边缘处的哪个TBG 14将形成其交换载体段的末端(注意到在图4中，不像其它图，域间的分组传输被示出为交换网络XN，而不只是交换链——如果在对等TBG对之间只存在单个交换链，则由左侧域b-CSCF对TBG的选择将指定右侧域中的TBG)。

右侧域中的b-CSCF为所选择TBG 14请求或者生成映射(在30处)以应用于Bb。再次假设结果是 $\mathrm{Bb}\⇒\mathrm{Cc},$ 则F-Spec被修改为[Cc，？？]。对于在图4中只涉及两个域的会话初始化，SIP INVITE消息然后将前进(在32处)通过右侧域中的CSCF，直到其到达目标SIP客户端22(在图4中示为应用服务器，AS)。在更一般的情况中，SIP INVITE被转发给与下一域对等的b-CSCF。

从AS 8b的角度，其所接收的SIP INVITE是请求具有端点为Cc的载体流。假设As用200OK消息答复，其将具体指定其载体流的末端(例如为Zz)，从而200OK消息34的SDL中的F-Spec将是[Cc，Zz]。(本领域的技术人员会知道，载有目标F-spec部分的响应消息可以是180 Ringing(铃声)消息)。200OK消息穿过INVITE的反向路径，并且返回到右侧域的b-CSCF。该b-CSCF将在36处请求或生成另一映射(例如 $\mathrm{Yy}\⇐\mathrm{Zz}$ )，并在TBG 14中激活整个IP报头双向的网络地址翻译 $\mathrm{Bb}\⇔\mathrm{Cc},$ $\mathrm{Yy}\⇔\mathrm{Zz}.$ 最后，b-CSCF修改200OK消息中的F-Spec以示出载体流源地址和端口为Yy而目标为Bb，并且将其(在38处)转发给其在左侧域中的对等体。在左侧域中的对等b-CSCF处，200OK消息的接收引起请求或者生成映射 $\mathrm{Xx}\⇐\mathrm{Yy},$ 在左侧域TBG中激活双向映射 $\mathrm{Aa}\⇔\mathrm{Bb},$ $\mathrm{Xx}\⇔\mathrm{Yy}$ (在40处)以及最后利用F-Spec[Aa，Xx]向发信SIP客户端传播200OK消息(在42处)。从TE SIP客户端的角度，用于会话的载体流的另一端点是在左侧域的TBG 14处的Xx。

上面所公开过程所做的事实上是将载体流分割成三个载体流段并且在TBG中安装映射以“重新标记”分组，从而这些分组被转发到下一段上。当TE 8将载体分组发送给AS 8b时，TE 8在这些载体分组上放置Xx的目标地址，所述目标地址由TE 8在200OK F-Spec中所接收到。Xx是由TE核心域中的TBG 14所服务的地址和端口号：第一载体流段在TE(地址A)和TBG(左侧核心网络上的地址X的信号装置(advertiser))之间，是附着段和最左边核心段的连结。第二段是左侧TBG(交换网络上的地址B)和右侧TBG(交换网络上的地址Y)之间的交换段。第三段，又是附着段和核心段的连结，其在右侧TBG(右侧核心网络上的地址C的信号装置)和AS(地址Z)之间。分组根据正常IP路由规则沿着每个单独的载体段转发到载体段的端点，因为分组报头中的目标地址是段端点的IP地址。在TBG处，分组报头被重写以将该分组放置在下一载体段的开头。那些熟悉标签交换路径(label swappedpath)的人可将这认为是一种标签交换形式，其中标签字段是整个IP报头源和目标地址和端口字段。当在发起域和终止域之间存在多个域时，观察本机制的这种方案可以应用于解释该机制应用的结果。图5用定义每个载体段的NAT映射扩大了图2。

还可以观察到，当在只有目标地址需要被重新映射的单个IP地址范围内进行操作时，分组中的源地址不影响这些分组的路由。然而，因为源地址被用于各种安全检验、诸如用于防火墙中以及用于安装QoS策略，因此需要一致性方案。当涉及多个地址范围(参见下文)时，源地址必须被重新映射，因此我们采取的方案应当总是一致。

还应该注意，在单个IP地址范围内，只在这样的节点处需要NAT“标签交换”，即在所述节点处不能依赖于IP转发以将分组转发到下一载体段上。只需要在网关处分割载体流，所述网关可能不总是在IP转发流的路径上。一般地，所包括的域间交换链拓扑可能够保证网关将总是在IP转发流的路径上，因此不需要是载体段端点。作为示例，如果存在互连两个域的单个TBG对并且这两个域之间的最短路径保证不穿过第三域，则从TE到AS的单个载体段将足以确保分组总是通过TBG对。多个IP地址范围

上面所述的NGN机构不要求每个管理域都是相同IP地址范围的一部分。相反，因为被呼叫方在SIP消息中由URI而不是IP地址识别，所以CSCF的链可以越过IP地址范围边界将SIP消息转发给被呼叫方。这确实要求当这些b-CSCF从它们的不在相同地址范围内的对等体接收该SIP信令时b-CSCF可以使SIP信令适应于这些b-CSCF自己的IP地址范围。例如在图6中，IPv6范围中的b-CSCF将以IPv4格式从该b-CSCF在公共IPv4范围中的对等体接收SIP消息，并且在将这些消息继续转发给其自己域中的其它CSCF之前将不得不将这些消息重新格式化成IPv6形式。如先前所注意到的，SIP消息在SDP部分中包括用于建立载体流的隐含流规范(F-Spec)。当载体流要穿过多个地址范围时，需要在地址范围边界处改变SIP消息中的F-Spec以反映将在载体流上受到影响的网络地址和端口翻译。重新格式化SIP消息的格式以及更改F-Spec通常被称为SIP ALG(应用层网关)功能。

图6描绘了使用三个IP地址范围的两个管理域：给终端(TE)提供服务的管理域为终端分配专用IPv4地址(也许因为该管理域没有所分配给该管理域的足够的公共IPv4地址来为每个终端给出它自己的公共IP地址)，但是使用核心网络中的公共地址，而另一管理域自始至终使用公共IPv6地址。互连两个NGN域的交换网络在图6中示为IPv4网络，是公共IPv4地址范围的一部分。这是任意的选择并且交换网络同样可以是IPv6地址范围的一部分。

将图4与图6比较，将观察到在左侧AG处存在地址范围边界。当分组穿过附着网络和核心网络之间时，该AG需要对分组执行NAT功能。因此，控制AG的p-CSCF即与在附着到AG 10的TE 8中的SIP客户端22对等的p-CSCF 16，需要翻译SIP消息的SDP中的F-Spec(从而载体流看起来在AG处发起)，并且在AG中安装必要的NAT映射以终止附着载体段并发起核心载体段。具体而言，图6所示的地址Aa是专用IP地址和端口分配，而Bb是由AG 10公布进入核心网络的公共IP地址(和端口号)。再次，那些熟悉专用和公共IPv4路由和默认路由的人将观察到，所示的 $\mathrm{Ww}\⇐\mathrm{Xx}$ 映射不是严格所需的，因为专用和公共IPv4地址不重叠并且附着网络可用任何方式将分组转发给AG。然而，不对载体分组进行全部IP报头重映射会产生载体流到载体段的前向和后向划分的不对称，并且这可以引起敏感的维护问题。

图6中的另一地址范围边界在右侧域TBG处。这个TBG具有一个或多个接口，所述接口在IPv4地址范围内进行操作，并且具体而言地址Y是所述接口(之一)的IPv4地址。也具有一个或多个在IPv6地址范围内工作的接口，其中地址D是TBG IPv6接口地址。如先前所提到的，从左侧域b-CSCF到达右侧域b-CSCF的SIP消息将以IPv4的格式，其中IPv4报头和所有v4嵌入IP地址。b-CSCF在将消息转发到下一CSCF之前必须翻译这些消息以具有IPv6报头和嵌入式IP地址。对于SIP INVITE消息的SDP中的F-Spec，翻译不得不与将在TBG中安装的NAT映射相匹配，也就是与所公开的路径固定过程相比没有改变。客户所在地(premise)的隐藏NAT

那些意识到公共VoIP服务的实际部署问题的人将知道，通常在TE和附着网络(AN)之间存在执行的NAT功能。该功能存在于带有专用IP地址范围的住宅或企业的边界处。现今，该NAT功能是SIP感知的(SIP aware)(即不包括SIP应用层网关(ALG))。然而，该现象实质上不影响上述机制；现今允许VoIP工作的相同解决方法可以继续被使用。因此，或者客户端通过首先询问STUN(Simple Traversal of UDPThrough NAT，NAT的UDP简单穿越)服务器(参见RFC 3489)确定正在应用什么NAT映射来“固定”SIP信令；或者p-CSCF检测到已经对来自客户端的SIP信令执行NAT翻译(因为嵌入到INVITE或者答复消息的SDP中的客户端IP地址与消息报头中的IP源地址不匹配)，并且指示AG在处理载体流时为此做出补偿。

将来，执行NAT功能的客户边缘设备的住宅网关可被增强为包括p-CSCF功能或者被增强为由p-CSCF控制，从而住宅中的载体流的段完全在SIP会话建立过程的控制下。对载体流进行NAT的其它益处：

上面所公开的路由固定机制的优点在于，其使用频繁呈现在TBG(和AG)中的性能(NAT)，并且其不要求来自核心网络中的其它路由器的任何支持。该机制导致NAT功能被应用于穿过管理域的所有载体路径。该机制还允许NAT功能被应用在AG处，甚至当附着网络处于与核心网络相同的IP地址范围中时也可如此。下面简要描述总对载体流进行NAT的两个附加益处，这两个附加益处使该机制成为在IMS中路由固定载体流的优选方法。匿名

在PSTN中，呼叫者可以请求不向被呼叫方呈现该呼叫者的电话号码。SIP信令支持对呼叫方SIP地址的抑制，但是载体分组的源IP地址可能对于被呼叫方来说足以识别呼叫者或者呼叫者的位置。至少，拥有呼叫者的IP地址将使得被呼叫方(如果想的话)能够安装拒绝呼叫者的服务攻击或者执行某种其它形式的互联网骚扰。当然，如果载体流被分成载体段并且每方只看到他们本地AG的IP地址，则发出或者接收SIP呼叫将不会向任何一方泄露另一方的IP地址，也不会超出完全认证方的IMS框架之外开启与该方通信的任何方式。掩盖合法监听

实现合法监听的方法的要求是监听目标不能检测到其通信正在被监听。关于实现合法监听的另一限制在于，除了那些直接承担执行监听的人之外的操作人员不能够检测到监听是在合适的位置——这个限制通常导致在目标的主核心网络中部署特定于目的的监听媒体网关。当NAT如上所述被使用时，呈现给终端客户端的载体流的SDP描述和实际分组报头不包括另一方的IP地址，而是包括中间网关的IP地址，则该用户不能(根据检查IP地址)辨别其载体路径是否已经被转到监听媒体网关以便于制作载体路径分组的副本。支持非SIP客户端

已经在假设在会话两端的实体——例如图1中的客户端和应用服务器——都使用SIP协议(称为SIP)以便于能够建立载体流的情况下开发了IMS。上述方法将IMS的应用性扩展到为不必是多媒体流的载体流要求QoS处理的应用，但是所述应用仍需要是SIP感知的。虽然假设应用服务器具有SIP功能是合理的，但是期望能够为不是SIP发言方的客户端建立载体流。在该应用可以利用由新NGN所提供的QoS传输之前，与不得不将应用客户端(其比服务器多得多)升级为具有SIP功能的情况相比，这样的性能将更快地开放由NGN IMS网络所支持的有用服务和应用的范围。

根据本发明的第三方面，无应用感知(application-unaware)的客户端代理与控制附着网关10的CSCF相结合，非SIP客户端通过该附着网关10而附着到网络上。该客户端代理代表客户端响应来自应用服务器的SIP-INVITE消息，从而可以提供对至少穿过附着段的载体流的QoS处理。在下面所述的实施例中，应用服务器可以是一种SIP感知并且能够调用本文所述机制的服务器。可替换地，可以部署具有所要求功能的应用服务器代理而不对应用服务器升级。在任何情况下，本技术消除了为所有可能的应用客户端类型部署特定于应用感知的特定代理的需要(这将是多域网络中一个非常困难的程序)。本发明可以通过增强控制AG的p-CSCF来实施，以为客户端提供与一般应用无关的代理功能，其中应用客户端附着到所述AG上。

下面，我们描述本发明的两个代表性实施例：1)其中只有载体流的应用客户端终端附着段被保证进行QoS处理；和2)其中，要对整个载体流提供QoS处理。第一实现方式可能对于许多部署来说非常有用，因为与核心网络相比，在附着网络(尤其是具有无线第一英里的那些)中受到更多限制。对客户端附着载体段的QoS处理：

在该实施例中，目标是只为应用客户端的附着载体段提供QoS处理(见图7)。假设，AS 8b(应用服务器或者其代理)是在某个IMS域——服务器的主域——中用S-CSCF注册的SIP发言方。应用客户端被附着到某个域(在图7中指定为客户端服务域)的核心网络，从该域中该应用客户端接收与NGN网络的IP连接。因为，应用客户端8是无SIP感知的，所以该应用客户端8没有用任何CSCF注册。然而，假设应用客户端的附着点是受客户端的服务域中的p-CSCF控制的AG。该AG被指定为TE的服务网关。

虽然图7示出了客户端服务域与服务器主域由传输链接隔开了零个或者更多个互连它们的传输域，但是本发明还可应用于这样的网络：其中应用服务器和客户端都在相同域中。为清楚起见，下面的描述首先假设这些域(服务器主域、客户端的服务域以及任何传输域)是相同地址范围的一部分——在这部分的末尾公开了用于处理在分开的IP地址范围内的域的附加机制。

当应用服务器8b将要把载体流中的分组发送给客户端8时，该应用服务器8b必须能够为载体流生成F-Spec(否则，该应用服务器将不能够生成分组的IP报头)。通常在需要建立载体流之前，已经在客户端和服务器之间存在一些相互作用：例如建立IPSec隧道之前的互联网密匙交换(IKE)，或者在视频片段流向客户端之前用于选择该视频片段的导航。根据初始交换中的IP报头，服务器将获得载体流的客户端终端的IP地址和端口号。服务器所获知的客户端IP地址是由AG 10所公布的地址，客户端8通过该AG 10而附着到核心网络4上。实际上，F-Spec描述了从应用服务器10到AG 8b的载体段。AG 10使用输入分组中的客户端IP地址以将这些将分组引导到附着载体段，所述附着载体段完成到客户端8的流路径。

本发明考虑SIP URI(Universal Resource Identifier，通用资源标识符)的新形式——我们将其指定为服务网关URI——以用作由应用服务器8b生成的SIP INVITE消息的INVITE目标参数(并被插入到“TO”子句(clause))。该URI中的标识符是IP地址的代表：该URI的既定语义是由该URI命名的目标(被呼叫方)为p-CSCF 16，该p-CSCF16可以将策略推给发布URI中的IP地址的AG 10。

存在许多种可用于路由SIP INVITE消息的机制，所述消息把这个新的服务网关URI看成这些消息的目标。例如，如果b-CSCF与所述b-CSCF所处的AS(autonomous subsystem，独立子系统)相关联，并且在所述b-CSCF的对等b-CSCF的转发表中规定AS数，则当b-CSCF接收INVITE消息时，该b-CSCF只需要为到对象IP地址的BGP-4路由确定“下一跳”AS，以识别将INVITE转发给什么新管理域和对等b-CSCF。一旦INVITE已经到达了目标管理域，该INVITE可以被转发给具体指定的S-CSCF，通过S-CSCF该域中的所有p-CSCF都已经注册了所述p-CSCF所控制的网关的地址范围。这个指定的S-CSCF然后将服务网关URI与地址范围进行匹配以确定要将INVITE消息转发到的p-CSCF。还可以如所希望的那样使用其它转发方法。

根据上述假设，在应用服务器和客户端之间建立载体流如下进行：在第一步，应用服务器8b在其主域中(经由其p-CSCF)将SIP INVITE发送给其S-CSCF，所述SIP INVITE具有TO子句，所述TO子句包含指定客户端的IP地址的服务网关URI，并且在SDP部分中包括用于流向客户端的载体流的F-Spec以及服务器想要应用的T-spec。(因为是服务器要为通话计费，所以指定T-Spec是服务器的特权)。

一旦S-CSCF执行了对INVITE的正常发起处理，该S-CSCF将INVITE转发给客户端的服务域。如果该客户端的服务域与服务器的主域不同，则INVITE将例如使用上面概述的转发决策过程经由b-CSCF被转发，可能穿过几个域边界，直到该INVITE到达在客户端的服务域的边界处的b-CSCF。

一旦INVITE到达客户端服务域中的b-CSCF，则必须将该INVITE转发给控制AG 10(调用该AG 10的策略决策功能)的p-CSCF，客户端8实际上附着到该AG 10上。可以再次使用上面概述的示例性机制，但是本领域的技术人员会知道存在多种可能的机制。

在接收到INVITE消息的情况下，p-CSCF请求AG 10(的RACF)在附着网络中安装QoS策略，该附着网络遵守为载体流指定的T-Spec，该载体流由INVITE消息的SDP中的F-Spec所识别。正是在这时候，由TO子句触发的对p-CSCF的修改行为停止(kickin)，所述TO子句包含服务网关URI以及尝试安装QoS策略的结果。在常规系统中，p-CSCF会把INVITE转发给，在该情况下客户端8(客户端是非SIP客户端)不知道如何处理该INVITE。因此，根据本发明，为客户端8实例化的通用代理44(或者等效地，起通用代理作用的p-CSCF)代表客户端8将合适的SIP答复发送回应用服务器8b。如果在AG上尝试安装QoS策略成功，则通用代理沿着INVITE的反向路径将应答(例如“200OK”)消息发送回应用服务器8b。可替换地，如果QoS策略安装请求失败，则来自通用代理44的返回消息反之会是BYE消息，以向服务器8b指示在附着网络中没有足够资源以为载体流支持所请求的T-Spec。要注意，在该操作中，QoS处理被应用到附着载体段并且生成SIP信令来完成载体流的建立，而b-CSCF(或者通用代理44)并不没有意识到客户端应用。照这样，通用代理44是真正通用的，其可被用于为任何客户应用建立具有QoS处理的载体流。

一旦应用服务器8b完成了SIP会话建立，则该应用服务器8b发送给客户端8的、遵守F-Spec的分组将以正常尽力服务方式穿过各种中间域，但是将利用特定的QoS穿过接入/附着网路6。

当应用服务器8b完成为客户端8的服务时，该应用服务器8b可以通过沿着原INVITE的路径发送SIP BYE消息来释放QoS资源。当到达p-CSCF时，该BYE消息将以正常方式引起用于载体流的QoS策略的释放，但是再次是p-CSCF(或者通用代理44)而不是客户端应用自身来生成SIP确认消息传递。

注意，当附着网络中的QoS策略由所谓的“拉”机制来安装时，上面公开的机制将对未经修改的应用客户端不起作用，因为“拉”机制要求客户端包含在在该过程中，而所述方法的实质是在不涉及客户端的情况下在附着网络中安装QoS策略。处理NAT：多个IP地址范围

如上所述，当TE 8和AS 8b在不同的IP地址范围中时，有两种情况需要处理。这两种情况中的第一种是当TE 88在专用IP地址范围中而核心网络是单个公共I P地址范围的一部分时。AG 8b执行NAT功能以翻译进入核心网络4的分组上的IP报头，从而当这些分组到达应用服务器8b时，来自客户端8的分组中的源地址是由AG 10所公布的公共地址。假如应用服务器8b使用该公共地址来构造服务网关URI和F-Spec(而不是控制分组内的未经翻译的地址)，则INVITE消息将如上所述到达控制p-CSCF。p-CSCF使用公共IP地址范围F-spec来发出其RACF请求：AG 10——意识到其正在对来自客户端8的业务进行NAT——在附着网络中安装任何IP层“门”之前需要在F-spec中映射客户端IP地址。

当核心网络14之间存在IP地址边界时，事情变得较为复杂：载体流路径事实上在执行相互地址范围NAT的TBG 14处被分割为两部分。在图8中，左侧IP地址范围和右侧IP地址范围之间的边界被示为在服务器主域的边缘处(虽然其可以在任何域的边界处)，TBG 14对所有业务执行NAT。从生成服务网关URI的应用服务器8b的角度，该TBG14是服务网关(也就是从TE客户端到达的分组中的源地址的信号装置，在图8中，应用服务器查看了B的源地址，该源地址是右侧IP地址范围中的地址)。

将SIP INVITE消息路由到b-CSCF，该b-CSCF例如使用上述相同的机制来控制NAT TBG 14。如上面所提到的，控制地址范围边界TBG的b-CSCF必须能够执行SIP ALG功能。在这种情况下，对所感兴趣的F-Spec的NAT映射在SIP INVITE消息到达控制网关之前将已被安装在NAT TBG中。b-CSCF的第一动作必须是针对NAT映射轮询TBG 14，从而该b-CSCF就可以利用TE 8所附着到的AG 10的服务网关URI以及客户侧载体段的F-Spec来为客户端侧(左侧)IP地址范围构建INVITE消息。在图8中，新的服务网关URI将包括地址A。从此以后，该过程如上所述地进行，其中b-CSCF对答复SIP消息执行所要求的ALG功能。

当处理核心网络之间的IP地址范围边界时存在一个警告。如上面所提到的，为载体流路由的IP路径可以不穿过与SIP信令所穿过的相同域。具体而言，可能存在路由的IP路径可以通过不是NGN中的参与者的域的网络。如果NAT翻译发生在不是NGN部分的边界网关处(也就是不在b-CSCF的控制下)，则上述机制将失效。在这种情况下的处理方式是使用全路由固定，如在下面部分中所述的。示例

使用本发明的典型示例是针对合法的(例如预先SIP)流式视频服务。视频服务供应商可能希望以比大多数接入/附着网络在“尽力服务”的服务级别上能够可靠支持的更高的质量级别来传送流式视频。一旦本发明被部署在NGN中，视频服务供应商将其服务升级为具有SIP能力(包括能够生成服务网关URI)，并且然后与本地运营商协商IMS服务。本地运营商将设置费率，其可以按照电影、或者基于时间、或者按照以特定QoS等级所传输的兆字节。这种形式的费率将取决于竞争因素，并且该费率对于保持在“网上”的会话(客户端附着到运营商自己的网络上)将可能比对于运营商不得不与一个或者更多个其他运营商分享费用的会话便宜。费率还可以特定于应用客户端所使用的附着网络的类型，无线网比有线网的费率要高。当会话失败时，视频服务供应商和NGN运营商之间的SLA还将覆盖退款问题。

视频服务的潜在客户端照常与视频应用服务器进行交互以浏览和选择电影。作为浏览响应显示的一部分，观看电影的价格将被呈现给用户：视频服务供应商可能会设置价格以覆盖传送费率的费用。电影可能将适合于不同客户端附着网络而伴以不同分辨率、不同价格。一旦用户选择完成，视频服务器用INVITE的TO子句开始SIP会话，所述INVITE包括具有客户端的IP地址和视频流的T-Spec的服务网关URI。这将导致正在为客户端服务的AG在该客户端当前正在使用的附着网络中安装QoS策略，从而从服务器去往客户端的视频内容分组接收视频服务器在INVITE消息中所请求的QoS处理。对载体流的端对端QoS处理

如上所述，NGN网络可以为所有载体流段提供QoS处理，其中载体流被“固定”通过参与SIP信令交换的管理域的TBG。当TE客户端不是SIP发言方时，该机制和所产生的端对端QoS能力可以与服务器网关URI的使用相结合。与用于只在客户端附着段上传递QoS的机制相比，所结合的机制使得每个p-CSCF和b-CSCF(当服务器的INVITE消息被路由到控制TE的服务网关的p-CSCF时，其处理该消息)(也就是进行NAT翻译的主要(prime)网关)来固定载体流，从而使其接收所请求的QoS处理。

除了针对附着段上的QoS所需要的条件和假设之外，还需要一个额外条件以传递端对端QoS：当发送作为载体流的一部分的分组时，应用服务器必须使用从在SIP答复“200OK”消息中所接收的终端F-Spec中导出的目标地址和端口号，而不是该应用服务器从(其放入进原F-Spec的)合法协议所获知的原客户端地址和端口号。

因为由CSCF生成的终端F-Spec利用其在分组报头中的地址定义了应用服务器的附着载体段，这确保了：甚至当应用服务器在适当位置具有多个网络附着链时，应用服务器仍将向AG转发载体分组，所述AG已由SIP信令“指点(primed)”以传递QoS和映射分组报头，以便将分组转发到下一载体段上；并且当存在多于一个待穿过的IP地址范围时，路由固定操作导致使用NAT网关，所述NAT网关使得其NAT映射由控制b-CSCF来设置。益处：

本方法的益处可以从合法视频流式服务的上述例子中看出。如果不用本发明，视频服务供应商为合法的(也就是非SIP)客户端确保QoS的唯一方式是使视频服务供应商与其订户所使用的每个附着网络供应商建立特定关系，从而来自其视频服务器的所有业务都在那些附着网络上被授予提高的QoS。这样的缺点在于：或者该服务将受限于地理范围内，或者视频服务供应商不得不与其任何客户可能想要使用的每个附着网络供应商进行协商。利用本发明，视频服务供应商只需要与作为NGN的一部分的一个运营商进行协商，然后可以为附着到任何NGN运营商网络的订户提供服务。然后，还有在接入网络中静态储备资源的问题，为此接入网络供应商可以合理地想要被支付费用，而不管视频服务供应商是否使用了这些资源。这可能会导致视频服务供应商在其在每个附着网络上储备的视频会话容量/数方面变得保守；视频服务器将不得不为这些储备的/预分配的资源运行其自身的RAC，以确保SLA通信层级不会被破坏。

那些熟悉SIP操作的人将知道，还有其它益处：甚至在一端不是SIP感知时能够使用SIP来建立载体流。例如可能发生的是，在会话的过程期间，附着网络不能再支持在会话初始化时议定的T-Spec——例如可能已将移动终端移到离基站较远处，并且在移动终端和基站之间可用的传输率已经被减少。在对RACS子系统的适当操作中，将通知控制p-CSCF不再能满足其所推动的QoS策略。然后可以将重新邀请SIP信令序列发回发起方，包括发送回反映当前附着链特性的T-Spec。然后，应用决策是以较低的QoS重建会话还是终止该会话。用于合法IP信令的网关

上面陈述过，通过NGN传递QoS给非SIP发言(speaking)应用的所公开方法的替换方案是，为客户端和服务器发展专用的SIP发言代理。这种解决方案的问题是不得不迎合的大范围的可能应用。然而，一些应用可能已经使用某种形式的资源储备协议(合法的IP信令)，并且这些协议的数量是非常有限的。可能地，需要被考虑的仅两个协议是RSTP[H.Schulzrinne等人“Real Time Streaming Protocol(RTSP)”，RFC 2326，1998年4月]和RSVP[R.Branden(编辑)等人“ResourceReSerVation Protocol(RSVP)”，RFC 2005，1997年9月]。本发明的第四方面提供了一种网关装置，该网关装置为SIP信令交互工作提供合法的IP信令。因此，可以提供主管信令交互工作功能(SIWF)的交互工作网关，该SIWF在网络边缘处终止RTSP和/或RSVP信令并且生成穿过核心网络的SIP消息以建立(QoS使能的)端对端载体路径。

图9是对交互工作网关的部署的描绘。在该图中，所示信令交互工作功能(SIWF)的主机为服务AG以用于两个应用实体(TE上的客户端和AS上的服务器)与载体流互连。总是在进出终端系统的分组路径中的AG是主管信令交互工作功能的优先选择，因为使用深度分组检测，AG可以检测带内的合法信令分组(“带内”意思是信令分组与其他业务混合)。然而，AG不是唯一的可能选择。另一可能的实现方式将AG的作用限制为检测信令分组并且将这些分组在某种形式的隧道中转发给与AG的控制p-CSCF同处于相同平台的信令交互工作功能。

SIWF操作可以如下概述：每个SIWF建立与p-CSCF的关联，并将该SIWF自身注册为其所服务的终端系统的SIP客户端。如在服务网关(发明3)的情况中，所注册的客户端地址可以只是由AG给附着到其上的终端系统所发布的IP地址。可替换地且更符合商业考虑，当被载波授权使用SIWF功能以横跨NGN网络建立QoS使能的载体路径时，应用服务器可以具有由管理程序所指派的名称。

当SIWF检测到合法的信令消息时(所述消息是请求建立从该SIWF所服务的终端系统发起的载体流)，SIWF从该消息中提取载体流的F-Spec和T-Spec，并且构建SIP INVITE消息，该消息被发送到与合法消息被发送到的相同实体。然而，代替是“sip:”的INVITE请求URI的结构(scheme)部分，合法信令协议的名称可被用作URI的第一部分，以向目标指示INVITE消息实际来自SIWF。同样地，原IP合法信令消息可以ISUP消息在SIP-I(也被称为SIP-T)中所载体的相同方式被作为SIP消息体的字段进行载体。

NGN网络将SIP INVITE消息转发给注册了其目标URI的名称的SIWF(假设，目标通过支持SIWF功能的AG被附着到NGN上，所述SIWF功能注册了其名称或者IP地址)。当INVITE消息到达注册了目标的SIWF时，该SIWF(或者直接从INVITE中所载有的消息的压缩形式，或者通过逆转生成INVITE中的F-Spec和T-Spec的过程)重构合法的信令消息。然后将重构的合法消息转发给目标实体。在本发明的一个实现方式中，SIWF将离开遗留消息的视在源(apparent source)作为真实的发起实体，但是在其它实现方式、尤其是那些发起实体和目标实体在不同地址范围内的实现方式中，SIWF将作为合法信令消息的发起方出现。(后一种方式使得SIWF容易接收合法信令回复，因为该合法信令回复将直接指向该SIWF，但是因为其是一种没有ALG的NAT的形式，其也可能引起应用中断)。

在适当时候，目标实体将生成合法的协议响应。这将被服务AG获取并指向SIWF。SIWF将使该响应与重构的原消息匹配并且与原INVITE匹配。SIWF将合法响应转换为SIP响应(例如200OK)并将其在返回信令路径上转发给服务于发起方的SIWF。SIP响应中的一些SDP字段可从合法响应中的字段进行提取，而其它将来自在INVITE中传送的SDP。基于SDP中的F-Spec和T-Spec，信令路径上的CSCF将为载体路径储备资源。

当SIP响应到达服务于发起方的SIWF时，该SIP再次重构合法的响应消息并将该消息继续转发给实际的发起方。

因为RSVP和RTSP是相当不同的协议，所以为每个协议单独地提供更详细的SIWF程序公开。RSVP 操作的当前模式：

RSVP协议意图在网络中储备资源以支持单向的载体流(在RSVP RFC中简称为“数据流”)。虽然RSVP可以用于为多播流和任意至任意的一般会议会话储备资源，但是本说明书限于其用于单播载体流或仅两个实体(诸如图9中的AS和TE)之间的点对点的载体流。在RSVP的操作模式下，流源用包括一种形式的F-Spec(称为滤波器规范)和T-Spec的“path(路径)”消息开始储备过程。对于单播载体流来说，F-Spec是源和目标IP地址和端口号(协议)的完整元组，其被称为固定滤波器，意思是在源发出“path”消息之前该源需要知道目标IP地址和端口号。

“path”消息被发送给载体流的预期接收器，因此该消息遵循发送器和接收器之间的IP路由路径。在简单的单播情况下，“path”消息的主要作用是在所穿过的有RSVP能力的路由器中记录前跳地址，从而返回消息——“resv”消息——可以从接收器穿过相同路径返回发送器。接收器利用“resv”消息答复，该“resv”消息相反地遵循“路径”消息的逐跳路径。当其处理“resv”消息时，每个有RSVP能力的路由器为基于“resv”消息中的T-Spec(被稍微含糊地称作流规范)为载体流调拨网络资源。使用RSVP到SIP SIWF网关

图10是概述消息序列图，示出了横跨NGN建立从应用服务器(AS)到客户端终端设备(TE)的载体流时的信令交互工作，其中AS和TE两者都使用RSVP来请求网络给载体流提供QoS。SIWF功能位于距AS和TE两者的第一IP跳，所述AS和TE根据图1中所描述的NGN体系结构，暗示了SIWF功能性的主机为附着网关(AG)。(如上所提到的，可以通过使AG识别RSVP信令消息并将其隧道传送到SIWF功能来扩展这个第一跳，在网络中该SIWF功能例如还被在主管控制AG的p-CSCF的相同平台上主管)。

假设AS提供给TE的应用通过交换AS和TE之间的消息来开始。在某个时刻(例如，已选择了电影并且付费细节已经被分类)，AS确定其需要传递分组流(载体流)给TE并且构建“path”消息，所述“path”消息指定了该流的源和目标IP地址和端口号(F-Spec)以及该流的T-Spec。AS将该消息传送给TE并且向其发送offat S2。“path”消息被SIWF拦截并且转换为SIP INVITE消息S4。载体流的F-Spec和T-Spec被转换成SDP参数(将发明1用于T-Spec)并且假定TE由IP地址所识别，SIP目标URI将是服务网关URI(如上所述)。除了将F-Spec和T-Spec从RSVP格式翻译为SIP格式以外，可能的是，原RSVP消息可以被附加到SIP消息上。在SIWF机制的一个实施例中，可以将整个RSVP“path”消息压缩并且将其作为不透明字段载在INVITE消息中。在另一实施例中，只有“path”消息的内部字段而不是其报头会载在INVITE消息中。同样如上面所提到的，本发明的实施例可以选择改变在INVITE消息的第一行中得出的URI的“结构”，所述INVITE消息有点像：INVITE rsvp：xxx.xxx.xxx.xxx SIP/2.y其中xxx.xxx.xxx.xxx是IP(v4)地址。

NGN网络将以上述方式转发SIP INVITE消息给服务于AG的p-CSCF，所述AG服务于TE。根据SIWF已经执行注册IP地址(或者地址范围)的注册功能——由此该SIWF能够执行其交互工作功能，p-CSCF将具有能力。在URI中的结构被改变的实施例中，那将足以更改p-CSCF以将INVITE转发给服务SIWF。

然后，SIWF使用被压缩(部分的)原路径消息(如果包括它们的话)从INVITE消息中重新生成RSVP“path”消息，并且将其自身的IP地址添加到消息中作为“前跳”。SIWF将“path”消息继续转发给TE 8(在S6处)。TE 8将利用被传送给主管SIWF功能的节点(其前跳)的“resv”消息S8来响应。SIWF功能将该“resp”消息(S8)与其在接收INVITE消息时安装的状态进行匹配，并且据此生成对INVITE的响应，例如200OK消息S10。因为RSVP的规则允许TE将“resp”中的T-Spec参数改变为其在“path”消息中所接受的不同值，所以SIWF将不得不为该响应重新生成SDP的T-Spec部分，而不是只反回其在invite中所接受的相同值。200OK消息被穿过NGN反回到服务于AS的SIWF，消息路径中的CSCF向网关推动合适的策略，从而由SDP中的F-Spec所描述的载体流将接收由SDP中的T-Spec所指定的QoS处理。在SIWF已重新生成“resv”消息S12并且将其转发给AS之后，AS可以开始发送载体流分组S14。

RSVP是软状态协议，而SIP是硬状态协议。这意味着，发送器(图10中的AS)和接收器(图10中的TE)周期性地分别发布“path”和“resv”消息以“更新”用于载体路径的网络资源储备。如果RSVP使能的路由器没有在“清除超时”间隔内发现这些“更新”消息，则所述路由器将释放资源。明显地，SIWF功能应该只将新的RSVP消息转换成SIP消息，并且只使用“更新”消息来重设时钟。如果未在足够长的间隔内接收到“更新”消息，则SIWF应该发布SIP BYE消息来拆卸会话。同样地，当SIP会话在适当的位置时，SIWF不得不生成匹配的更新消息，从而发送器和接收器不会认为载体路径已失去了其储备。

除了允许资源储备流失，RSVP确实提供了明确的拆卸。在图10中，发送器被描绘为在与接收器的会话结束时通过发布“pathtear”消息S16来终止载体路径。当SIWF从RSVP发送器(或者接收器)接收到“pathtear”(或者“resvtear”)消息时，该SIWF发出SIP BYE消息S18。BYE消息(用200OK响应S20)被确认，而RSVP“tear”消息不被确认。

本领域的技术人员将知道，不要求TE和AS是远离其服务SIWF的一个IP跳。特别是，AS和/或TE可以与支持RSVP的网络(例如具有RSVP使能的路由器的企业网络)连接，并且在NGN边界处的SIWF功能可以去除的几个IP跳。RTSP

如SIP，RTSP是基于文本的应用协议。并且如SIP，RTSP使用SDP来描述媒体流。在语义上存在相当多的重叠。然而，作为比SIP早的发展，RTSP以SIP所支持应用的子集为目标。RTSP的主要应用领域是存储的和现场的多媒体演示。现场的网上广播和它们随后根据存储器的回放是RTSP的一种用途，音频或者视频的互联网流是另一种用途。RTSP消息的语义不与SIP直接匹配。一种类型的消息——DESCRIBE响应消息——载有描述可能几个载体流的演示的SDP(并且从中不得不推测每个流的T-Spec)，而另一类型的消息——SETUP消息——载有一个载体流的F-Spec。每个载体流均要求单独的SETUP消息。更糟的是，RSTP不要求使用DESCRIBE消息：应用客户端可以通过任何技术来获知载体流的媒体初始化参数。

必须要知道，产生高效的SIP-RTSP SIWF以处理所有可能的RTSP使用将会是很困难的。因为事实上非常少量的RTSP媒体服务器和播放器(例如REAL、Quicktime、Windows)支配互联网上的RTSP使用，所以为处理其RTSP使用模式而指定的SIWF将是最有益的。下面描述本发明的实施例，其以在交换了DESCRIBE消息之后建立会话中载体流的应用为目标。使用RTSP-SIP SIWF网关

图11描绘了用于RSTP客户端或者播放器(在TE上主管)的消息流，所述RSTP客户端或者播放器跨过NGN从RSTP发言应用服务器(AS)请求媒体流，该NGN在其边缘处具有拦截来自TE和AS的RTSP消息的RTSP-SIP SIWF功能。

想要开始RSTP会话的RTSP客户端将知道应用服务器的URL，所以该RTSP客户端可以为DESCRIBE请求消息生成请求URI并且将那个消息(在S22处)发送给服务器。在图11中，DESCRIBE请求消息被示出为直接通过主管SIWF功能的节点。只有响应RTSP 200OK(S24)是它们所感兴趣的，并且事实上只有服务于客户端的SIWF需要缓存对DESCRIBE的响应的SDP体部分。应该注意，描述媒体会话流的应用服务器不必是提供媒体流的相同实体，因此不能保证服务于应用服务器的SIWF与服务于媒体服务器的SIWF相同。

客户端的SIWF(例如在TE所附着的AG处所主管的SIWF)需要能够检测指向客户端的消息流中的RTSP 200OK消息。特别是，客户端的SIWF需要检测和缓存在消息体中承载的媒体流的描述。事实上，SIWF可以被指定用于为“内容类型：应用/sdp”线检查所有形式的200OK消息并且缓存体内容以防未来可能来自客户端的RTSP SETUP请求。特别是，这将包括使用HTTP响应来传送会话的SDP参数的情况。

由客户端所接收的SDP参数描述组成该会话的一个或者多个媒体流源。每个源都包括其URI。因此，客户端利用其从DESCRIBE响应所获知的请求URI而向每个媒体流源发布SETUP请求(图11示出一个SETUP请求正被发送给是AS的媒体源)。包含在SETUP消息中的是客户端想要接收载体流的端口号(本领域的技术人员将知道，利用rtp/avp文件载体流，所特定的端口号事实上是一对端口号，但是这些端口号中的第二个用于不太可能受益于“尽力服务”QoS处理的RTSP业务)。

当客户端的SIWF识别SETUP请求S26时，该SIWF首先不得不将该SETUP请求S26与在先DESCRIBE响应的所缓存SDP中的媒体流描述进行匹配。要完成这个匹配有两个关键点：客户端的IP地址，其在SETUP消息的分组报头源字段和DESCRIBE响应的目标字段中；以及SETUP消息的请求URI，其应该匹配来自DECSRIBE响应的SDP的媒体流源URI。(只匹配媒体流源URI通常就足够了，但是可能有不同客户端得到不同编码的情况，因此更加安全的是还匹配客户端)。当发现匹配时，SIWF能够为SIP INVITE消息S28构造SDP的T-Spec部分。F-Spec的接收器端(也就是分组类型，和客户端IP地址和端口号也被编码到SDP中。因为在SETUP消息中有请求URI，所以对于INVITE消息中的请求/目标URI有两个选择，即：如果媒体服务器已在管理上用明显不同的URI(即SIWF可以将其认为可由SIP路由的URI)进行注册并且已返回那个URI作为DESCRIBE响应的一部分，则从SEPUT消息中复制的该URI可被用作INVITE的请求URI；否则，SETUP消息的目标IP地址可被用于构造服务网关URI(如上所述且类似于上述RSVP的情况)。

INVITE消息被以先前描述的方式通过NGN转发给服务器，并且到达服务器的SIWF(即，与服务器所附着的AG相关联的SIWF)。假设对策略检验感到满意(见上)，则SIWF重新生成SETUP请求S30并且将其转发给媒体服务器。再次，如在RSVP的情况下，本发明的实施例事实上可以传输INVITE消息中所压缩的SETUP消息的副本，但是除此之外INVITE消息中的信息将足以能够生成与由客户端所发送的消息在语义上等同的SETUP消息。

当服务器发布其对SETUP消息的响应S32时，该服务器在该响应中包含源端口号，从而当服务器的SIWF拦截该消息时，该服务器的SIWF可以在对INVITE消息的响应S34中完成SDL的F-Spec部分。SIP 200OK响应消息S34的剩下部分从INVITE消息的内容中加以构造。当200OK响应在INVITE的反向路径上返回时，各个CSCF在网关中安装QoS策略以确保由F-Spec描述的载体路径接收由T-Spec指示的QoS处理。

客户端的SIWF将SIP 200OK响应S34转换成对原SETUP消息的响应(RSTP 200OK响应S36)，并将那个响应继续发送给客户端。不像SIP，RTSP也具有一组方法(命令)来控制媒体流的结束(play out)(例如，开始快速前向序列)。这些命令只涉及服务器，并且不需要由SIWF解释。在该命令组中包含PLAY请求，服务器实际上不发送任何载体流分组，直到该服务器接收到PLAY请求。然而，TEARDOWN请求S38被SIWF拦截，并被翻译成SIP BYE消息S40。RTSP的TEARDOWN和SIP的BYE消息都要求确认(200OK)S42、S44。授权和记账

IMS体系结构的主要益处之一是用户(以SIP客户端的形式)(在REGISTRATION(注册)阶段期间)被授权，并且NGN生成记账信息，该信息将用户与他们所请求的QoS载体流联系在一起。如上所述在NGN中提供SIWF网关减弱了这些控制，因为这些控制允许未注册的端点请求并使用网络资源。在实际的商业部署中，运营商将需要预授权载体流的一端，可能为应用服务器，因为要与之协商账单设置的应用服务器太少了。运营商将在管理上在其服务SIWF中规定应用服务器的地址，并且明确地实现交互工作功能。可以向SIWF提供服务器的URL，其中服务器用s-CSCF来注册，从而可以使用URL作为目标URL而不是使用服务网关IP地址方法将SIP消息路由到SIWF。QoS的选择性应用

然而，甚至当应用服务器被安全地识别并且商业设置在适当的位置向该应用服务器发送其所建立的QoS载体流的账单时，该服务器不能够选择特定客户端是对发送给该客户端的流接收QoS处理还是接收尽力服务处理。(这可以取决于客户端用户是否具有与应用服务器供应商的预定)。本发明的进一步改进——可应用于诸如RTSP的由URI识别媒体流的合法协议——将使该应用使用不同的URI来识别在其他方面等同的媒体流，这取决于这些应用服务器是否将接受QoS处理。NGN中的所有SIWF将不得不能够区分两种类型的URI。参照图11，当SETUP消息到达服务于SIWF的客户端时，该客户端将检查目标URI，并且只有当URI指示应用服务器“请求”QoS处理时才将该SETUP消息转换成SIPINVITE消息。否则，SIWF功能忽视SETUP消息，并且其以标准的合法方式不涉及其它网络地进入应用服务器。本领域的技术人员将知道，存在许多可以用于区分URI的方案：一个示例是使用服务器的服务域的IMS域名作为附在应用服务器自身URL之后的URI的域部分。

在上面所述的本发明的第三方面中，为了建立QoS载体流，服务器需要是SIP发言方，但是忽视服务器和客户端之间的协议。另一方面，在上面所述的第四方面中，客户端和服务器之间的协议被转换成SIP。如可被想到的，可以结合这两种方法。图12描绘了在应用服务器和客户端之间提供QoS载体路径的NGN实施例，其中应用服务器使用通向本地SIWF网关的合法信令协议来请求QoS，并且SIWF网关将信令转换成通向(p-CSCF控制)客户端TE的服务网关的SIP消息。

要考虑两种情况。在一种情况中，客户端不是合法信令协议的发言方。服务器使用合法信令协议，因为其比SIP实施起来更加简单。这在图13中针对RSVP的情况示出。注意，在这种情况下当使用RSVP时，SIWF功能(或者至少RSVP消息的检测)必须在服务器的服务AG中被主管，对于诸如RTSP的允许配置代理的其它协议(即，消息被IP发送给代理)，SIWF功能不必在服务器和客户端之间的分组的直接路径中。特别是，SIWF功能可以包括在服务器的服务p-CSCF中。在另一种情况中，合法信令协议被在客户端和服务器之间进行交换，但是该合法信令协议同样被服务器的SIWF检查但是不作修改。这由图14针对RTSP的情况示出。在这种情况下，SIWF功能起到透明代理的作用(即不向其发送RTSP分组)，因此必须是服务AG的一部分。

因此，在此描述的方法和系统克服了当今IMS的限制，所述当今IMS只处理通过SIP发言端点之间的RTP传递的多媒体流。在此一起描述和要求保护的发明允许从任何内容源将任何内容在QoS载体流上传递给任何目标，同时保持IMS的安全性和计费框架，为下一代网络的运营商从客户和应用服务供应商中开启新的收入源。

上面描述的本发明的实施例旨在只是示例性的。因此，本发明的范围只由所附权利要求的范围限制。

Claims (26)

1.一种在带外信令协议被用于建立通信会话的多域通信网络中建立通信会话的载体端对端路径的方法，该方法包括以下步骤：

接收带外信令消息，所述消息包括代表所述端对端路径的第一载体段的至少相对端点的信息；

使用所述信息来定义通过该网络的被用于建立通信会话的载体端对端路径的节点的交叉连接映射，所述节点在由所述节点主管的第一载体段和第二载体段的各自本地端点之间；

将代表所述交叉连接映射的信息插入到带外信令消息中；并且

将带外信令消息转发。

2.如在权利要求1中所要求的方法，当带外信令消息是带外信令协议的前向阶段消息时，所述方法进一步包括以下步骤：

从所述第二载体段的相对端点接收带外信令协议的返回阶段消息，响应于带外信令消息的接收，所述返回阶段消息由所述端对端路径的相对端点生成；

定义通过节点的反向阶段交叉连接映射，所述节点在第二载体段和第一载体段的各自本地端点之间；并且

将返回阶段消息转发给第一载体段的相对端点；

从而建立双向载体端对端路径。

3.如在权利要求2中所要求的方法，其中带外信令协议是会话初始化协议(SIP)，并且其中：

前向阶段消息是SIP INVITE消息；并且

返回阶段消息是由端对端路径的远端生成的SIP响应消息。

4.如在权利要求1中所要求的方法，其中定义交叉连接映射的步骤包括以下步骤：

识别第一和第二载体段的各自本地端点；并且

定义通过所识别的本地端点之间的节点的映射。

5.如在权利要求1中所要求的方法，其中将代表所述交叉连接映射的信息插入到带外信令消息中的步骤包括插入识别第二载体段的本地端点的信息的步骤。

6.如在权利要求5中所要求的方法，其中所述识别第二载体段的本地端点的信息代替了识别第一载体段的相对端点的信息。

7.如在权利要求1中所要求的方法，其中所述带外信令消息是在控制节点的呼叫状态控制功能(CSCF)处所接收的SIP-INVITE消息，并且其中定义交叉连接映射的步骤包括安装所述交叉连接映射作为那个节点的转发策略的步骤。

8.如在权利要求7中所要求的方法，其中转发所述带外信令消息的步骤包括将所述SIP-INVITE消息转发给对等CSCF的步骤。

9.如在权利要求1中所要求的方法，其中所述节点是下面的任何一个：网络的域之间的边界网关；和网络的域内的服务器。

10.如在权利要求1中所要求的方法，其中所述信息被编码在会话描述协议(SDP)中。

11.如在权利要求1中所要求的方法，其中所述信息包括IP流规范，所述IP流规范包括所述载体段的至少一个端点的各自IP地址。

12.如在权利要求1中所要求的方法，其中使用所述信息来定义交叉连接映射的步骤包括定义网络地址翻译(NAT)映射以用于将由所述节点通过所述第一载体段所接收的IP分组报头翻译成所述第二载体段的报头的步骤。

13.如在权利要求2中所要求的方法，其中定义通过所述节点的反向阶段交叉连接映射的步骤包括定义相应的反向阶段网络地址翻译(NAT)映射以用于将由所述节点通过所述第二载体段所接收的IP分组报头翻译成第一载体段的报头的步骤。

14.一种用于在带外信令协议被用于建立通信会话的多域通信网络中建立通信会话的载体端对端路径的设备，包括：

接收带外信令消息的装置，所述带外信令消息包括代表所述端对端路径的第一载体段的至少相对端点的信息；

使用所述信息来定义通过网络的被用于建立通信会话的载体端对端路径的节点的交叉连接映射的装置，所述节点在由所述节点主管的第一载体段和第二载体段的各自本地端点之间；

将代表所述交叉连接映射的信息插入到所述带外信令消息中的装置；以及

将所述带外信令消息转发的装置。

15.如在权利要求14中所要求的设备，其中，当所述带外信令消息是所述带外信令协议的前向阶段消息时，所述设备进一步包括：

从所述第二载体段的相对端点接收所述带外信令协议的返回阶段消息的装置，响应于带外信令消息的接收，所述返回阶段消息由所述端对端路径的相对端点生成；

定义通过节点的反向阶段交叉连接映射的装置，所述节点在第二载体段和第一载体段的各自本地端点之间；以及

将返回阶段消息转发给第一载体段的相对端点从而建立双向载体端对端路径的装置。

16.如在权利要求15中所要求的设备，其中带外信令协议是会话初始化协议(SIP)，并且其中：

前向阶段消息是SIP INVITE消息；并且

返回阶段消息是由所述端对端路径的远端生成的SIP响应消息。

17.如在权利要求14中所要求的设备，其中使用所述信息来定义通过网络的被用于建立通信会话的载体端对端路径的节点的交叉连接映射的装置包括：

识别第一和第二载体段的各自本地端点的装置；以及

定义通过所识别的本地端点之间的节点的映射的装置。

18.如在权利要求14中所要求的设备，其中将代表所述交叉连接映射的信息插入到带外信令消息中的装置包括用于插入识别所述第二载体段的所述本地端点的信息的装置。

19.如在权利要求18中所要求的设备，其中识别所述第二载体段的所述本地端点的所述信息代替了识别所述第一载体段的相对端点的所述信息。

20.如在权利要求14中所要求的设备，其中所述带外信令消息是在控制节点的呼叫状态控制功能(CSCF)处所接收的SIP-INVITE消息，并且其中使用所述信息来定义通过网络的被用于建立通信会话的载体端对端路径的节点的交叉连接映射的装置包括安装所述交叉连接映射作为那个节点的转发策略的装置。

21.如在权利要求20中所要求的设备，其中将所述带外信令消息转发的装置包括将所述SIP-INVITE消息转发给对等CSCF的装置。

22.如在权利要求14中所要求的设备，其中所述节点是下面的任何一个：所述网络的域之间的边界网关；和所述网络的域内的服务器。

23.如在权利要求14中所要求的设备，其中所述信息被编码到会话描述协议(SDP)中。

24.如在权利要求14中所要求的设备，其中所述信息包括IP流规范，所述IP流规范包括所述载体段的至少一个端点的各自IP地址。

25.如在权利要求14中所要求的设备，其中使用信息来定义通过网络的被用于建立通信会话的载体端对端路径的节点的交叉连接映射的装置包括用于控制CSCF来定义网络地址翻译(NAT)映射以用于将由所述节点通过所述第一载体段所接收的IP分组报头翻译成所述第二载体段的报头的装置。

26.如在权利要求15中所要求的设备，其中定义通过所述节点的反向阶段交叉连接映射的装置包括定义相应的反向阶段网络地址翻译(NAT)映射以用于将由所述节点通过所述第二载体段所接收的IP分组报头翻译成第一载体段的报头的装置。

Images