CN101606353A - 在下一代网络中提供sip交互工作 - Google Patents

Abstract

方法和系统用于扩展NGN的IMS/SIP架构以提供QoS服务给普通承载流。支持在通信会话中提供承载流的QoS处理，使用不同的带内信令协议在两个端设备之间建立该通信会话。在两个端设备之间的带内信令的路径中提供了信令交互工作功能(SIWF)。该SIWF操作用于：检测带内信令的至少一个信号状态；以及基于检测到的信号状态，建立具有承载流的QoS处理的通信会话，该承载流跨越两个端点之间的端到端路径的至少一部分。

Description

在下一代网络中提供SIP交互工作

技术领域

本发明涉及下一代网络，并且尤其涉及下一代网络中SIP交互工作(interworking)的提供。

背景技术

目前，各种国际标准团体和协会(例如第三代合作计划(3GPP)、欧洲电信标准协会(ETSI)和国际电信联盟(ITU))正在参与定义下一代网络的项目。根据ITU-T，下一代网络(NGN)是基于包的网络，可以提供包括电信服务的服务并且可以使用多个宽带的、允许QoS的传输技术，并且在其中服务相关功能独立于底层的传输相关的技术。NGN提供了用户到不同服务供应商的无限制接入。它还支持普通的移动性，其可以使得向用户提供一致的、无处不在的服务。

下一代网络总体上基于互联网多媒体子系统(IMS)架构，并且采用会话发起协议(SIP)用于管理建立和拆除各方间的通信会话。这种布置的优势在于，IMS/SIP提供互联网协议(IP)网络的框架来以下列方式建立包括互联网协议(VoIP)电话呼叫的多媒体会话，该方式防止了欺骗并且允许使用跟目前公共交换电话网络(PSTN)和蜂窝网络运营商采用的方法非常相似的方法进行后续的记账和域间结算。也就是说，用户可以与按交付的服务类型相关的收费，为每个单独的的呼叫/会话付账，并且这些收费可以被合适地分配给呼叫/会话经过的每个承载网络(或者管理域)。

如同在PSTN中的情况一样，可以想象，NGN将由多个运营商/管理域组成，并且IMS架构为一个运营商的用户提供了基础，以与另一个运营商的用户建立语音呼叫或多媒体会话，其方式是使得双方运营商(和任何中间运营商)在它们各自的管理域内保留必要的网络资源来支持运送与该会话关联的语音或多媒体流的承载包流所需的服务质量(QoS)。进一步，IMS架构全面支持端用户的漫游，其方式是使得访问域以与主域相同的方式支持承载流QoS。

图1示意性地示出了典型的下一代网络架构。如同在PSTN和互联网中一样，NGN被期望为多个管理域网络的聚集。管理域的业务可以主要是服务于最终用户的或者是向其他管理域提供转接(transit)的。对于本申请来说，提供管理域的转接的网络被称为转接网络(TN)2。服务于最终用户的管理域由两种类型的网络组成：核心IP网络(CN)4和一个或多个配属(attachment)(或“接入”)网络(AN)6，其通过配属网关10将最终用户的终端设备(TE)8“连接”到核心网络4，使得他们可以接收IMS服务。AN们通常被认为与它们连接的CN在相同的管理域内，即使它们由分立的商业实体(AN运营商)运行(CN运营商从它们那里购买“批发接入”)。注意，虽然转接网络和核心网络都基于每个包报头内的目标IP地址来路由IP包，但是AN在TEs和CN配属点之间传输包而与IP地址无关。当配属网络可以如同有线或时域多路复用(TDM)电路那样简单时，它通常由特定介质的最后一英里网络(media specific first mile network)和更广泛的包回程网络(packet backhaul network)组成(在3GPP无线专门名词中，这种回程网络用术语“核心”表示，但是它仍然是AN的一部分并且不与CN混淆)。

在图1所示的网络架构中，通过由每个网络中的传输边界网关(TBG)14掌控(host)的交换链路12，在各种核心和转接网络之间传输包。对于任何一对网络，交换链路可以是物理链路或者某些形式的虚拟电路。本领域中的技术人员将认识到，多个网络也可以在非连接交换网络(XN)上进行互连。XN的范围可以从单个以太网交换机到全球IP网络或虚拟专用网络。

IMS被规定为使用会话发起协议(SIP)建立和拆除多媒体呼叫或会话。IMS架构规定了多个遍布网络的呼叫状态控制功能(CSCF)，其处理SIP消息并根据SIP消息动作。在特定会话的建立中，SIP消息传递需要被至少与会话的发起方关联的发起服务CSCF(S-CSCF)和与会话建立的对象或目标关联的目标S-CSCF处理。但是，通常SIP客户端并不直接对等(peer)与它们关联的S-CSCF，并且还有中间CSCFs，它们在SIP客户端和与它们关联的S-CSCF之间以及在发起和目标CSCF之间路由和转发SIP消息。与本申请特别相关的是负责在管理域之间转发SIP消息的对等CSCF。在本描述中，我们将任何一个CSCF(只要是管理域中最后将SIP消息转发到其他域的那个，或者只要是管理域中最先从其他域接收SIP消息的那个)指定为边界CSCF(b-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描述在会话建立中，漫游TE8(配属于(attached to)访问的核心网络)和应用服务器AS8b之间的相关的CSCF，其中主核心网络被转接网络2分隔。

会话的媒体流作为承载(包)流在网络上传输。在IP包环境中，由于承载流路径不要求经过掌控(hosting)CSCF功能的节点，所以承载流路径并不自动地与SIP信令经过的路径相同。域间承载流在节点(这里称为传输边界网关(TBG)14)处离开和进入管理域。同样，配属网络和核心网络之间的情况是有区别的：核心网络中与配属网络接口的节点有各种称呼：服务边缘、核心网络边缘、边界节点、接入媒体网关、接入路由器或者接入网络类型专门术语，例如GPRS网关支持节点(GGSN)或者宽带远程接入服务器(BRAS)。在本描述中，我们将使用术语配属网关(AG)10。AG跨越AN6和CN4之间的边界。

规定承载流QoS需求

如本领域中所知的，发起会话的SIP消息运送与该会话关联的承载流(如果需要的话，多个承载流)的描述。该描述采用会话描述协议(SDP)的参数的形式。参见，例如，Handley，M.和V.Jacobson的“SDP：session description protocol”，评论请求2327，1998年4月。目前，SIP消息的SDP部分给出承载流要包含的信息(即，语音或视频和所使用的编解码器和比特率)的完整描述。该信息最初的目的在于使得端系统指定它们希望如何将语音或视频数据编码成实时协议包(real time protocol)。

在IMS解决方案中，SDP参数还可以由各种网络域(位于端系统之间)中的CSCF解释，以确定承载路径网络的特性。通常这种信息源自SDP的媒体行(以m＝开始)。例如下式中的最后一个参数：

m＝audio 8004RTP/AVP 9

表示音频承载流是根据音频视觉概要audio visual profile，AVP)9进行编码的，其刚好是G.722，其是64kb/s的流(网络需求同样必须包括包头等，从而使它增大至大约100kb/s)。

基于SDP参数，CSCF执行以连接许可控制(CAC)名义进行的过程，尽管该过程更准确地应被称为会话许可控制(SessionAdmission Control)。CAC过程确定承载流的资源需求，使得可以以期望的QoS传递嵌入的媒体流。如果域没有支持新承载流的资源，那么相关的CSC F将终止会话建立。3GPP文档《3GPPTS 23.207》中提供了这点(对于p-CSCF和AG)的描述。

业务类别(Traffic Classes)

业务类别在某种程度上是不确定的概念，在不同业务管理模型中其以不同的术语表示(capture)。在IETF IntServ模型中有三种业务类别：“保证的”(guaranteed)、“控制负载的”(controlled load)和“尽力而为的”(best effort)。有点类似的，IETF DiffServ模型提供了三种业务量转发行为：加速转发(EF)、确保转发(尽管AF业务可以有多至4个的类别)和默认或尽力转发。ITU研究组根据延时和转接(还有吞吐量)加上各种因素(例如，包损失比率和如何处理规范以外或者延时的包)来定义服务的业务类别。

在NGN的实际部署中，有一种使延时和抖动二者尽可能小的业务量类别，用于实时通话(或者运营商可以选择若干这样的类别，一种用于语音通话，一种用于视频电话，一种用于游戏)，还有另一种类别，其以一定范围的抖动来确保吞吐量，适用于媒体流的播放(同样，运营商可以选择在语音和视频之间作区分)。由于从来没有任何专用于尽力而为业务的资源，所以使用SIP建立尽力而为流几乎没有实用性，但是为完整起见，可能有这样被定义的编码点。

QoS控制和处理的范围

图2示出被划分成片段20的承载流18。承载流的每个片段20经过单个包传输网络2-6并且被端设备或网关14定界。承载流片段20可以由它们在上面传输的网络的类型命名：对于穿越配属网络的承载流的部分就是配属片段，等等。

可能不需要向承载流包提供的特定处理扩展到端到端。被广泛接受的是，如果特定的包传输网络被提供过多的包(is overprovisioned)，那么对所有包的QoS处理将足以支持任何特定的承载流。本领域的技术人员还将认识到，Diffserv可以被用于模拟特定业务类别的过度提供。可以想象一些或所有的核心网路将会被过度提供(或使用Diffserv来为IMS包模仿过度提供)，其结果是将不需要为经过了这些被过度提供的核心网络的承载流的核心片段保留资源。但是，很可能的是，资源将不得不为配属片段而保留，以确保在那些片段上的流的包的传输不会使端到端流的QoS降低到该流所支持的服务的可接受水平之下。

资源和许可控制功能(RACF)

为承载流而保留资源的功能与会话的许可控制紧密相关，其中承载流是会话的组成部分。在对现有对话的当前给出的服务质量水平承诺下，如果链路上的带宽容量、节点上的转发容量不足或者缺少为新会话的承载流而传递请求的QoS所需的其他资源，那么该会话建立被终止并且为那个会话已经保留的任何资源被释放。

更普遍地，在会话建立之前，需要做出关于是否许可该会话的多个策略决定。在IMS架构中，这些确定在CSCF发起，由会话建立中的第一消息的处理触发：SIP邀请(SIP INVITE)消息。一些策略决定的执行被限制在CSCF，但是与承载流QoS相关的那些由控制CSCF以信号方式发送到网关。图3示出对于包含两个域的会话，在配属网关(AG)10和传输边界网关(TBG)14中分别由p-CSCF和b-CSCF进行的对RACF功能的控制。那些熟悉NGN标准的专业人员将认识到，在IMS架构中，在CSCF和网关之间存在中间策略决定功能(PDF)，其形成(资源和许可控制子系统)RACS网络层。象在请求QoS承载流的不同应用之间的仲裁那样，PDF可以向CSCF出示配属网络QoS控制规范的抽象图，也可以隐藏AG和TBG的拓扑。

不管有优点，但是NGN受到一些限制，因为IMS被设计成向通过实时包(RTP)包流传输的多媒体业务(包括视频和/或VoIP)提供QoS处理。但是，有许多其他业务类型将从QoS处理的应用中获益。另外，没有了由IMS支持的记账和结算功能，网络服务供应商几乎没有动机在还支持除多媒体和VoIP以外业务类型所需的NGN技术上投资。INS的进一步的限制是通信会话的双方必需是SIP客户端。这造成了NGN部署的障碍，因为单个最终用户必须迁移到“SIP可用的”应用。

因此，支持下一代网络中SIP和遗留协议之间的交互工作的方法和技术仍然是非常需要的。

发明内容

本发明的一个目标是提供在下一代网络中SIP和遗留协议之间交互工作的方法和技术。

因此，本发明的一个方面是，在使用会话发起协议(SIP)建立具有承载流的QoS处理的通信会话的通信网络中，在使用不同的带内信令协议在两个端设备之间建立的通信会话内，提供一种承载流的QoS处理的方法。在两个端设备之间的带内信令的路径中提供信令交互工作功能(SIWF)。该SIWF操作用于：检测带内信令的至少一个信号状态；以及基于检测到的信号状态，建立具有承载流的QoS处理的通信会话，该承载流跨越(spanning)两个端点之间的端到端路径的至少一部分。

本发明并不特别针对任何具体的业务管理模型，但仅仅假定存在多个由运营商协定的业务类别，并且期望的承载流的业务类别可以作为SDP中的参数被规定。

本发明假定对于每个AG，有p-CSCF(同样地，对于每个TBG，有p-CSCF)，它可以为经过那个网关的承载流请求QoS处理，不管用于它们交互通信的中间PDF、节点和专有协议选择的数量(如果有的话)。具体承载流的承载片段的QoS处理可以通过向在该片段的一端的网关推行策略，以单端的方式设置，或者可以通过向在该片段的两端的网关推行策略，以双端的方式设置。如上所定义的，网关是承载流的一个承载片段的端点和它的下一个片段的起点：推行到该网关的单个策略可以用于为两者的片段请求QoS资源。

本领域中的专业技术人员将认识到，有几种不同的方法用于请求网关为承载片段提供QoS：所谓的“推行(PUSH)”方法导致网关从CSCF(或者通过策略决定功能的分层)直接接收“策略决定”来提供具有指定的QoS的承载片段，并且网关然后向CSCF回复它具有资源来“强制执行”策略或者它不具有该资源。之后的描述依照RACS的“推行”模式来阐述，但是本发明意在使其工作与如何将QoS需求通信至网关无关。事实上，如本领域中的专业技术人员将认识到的，“带宽代理”可以保持对链路或网络上的带宽资源的跟踪，而无需发送信令到处于端点的网关。但是，假定片段开始于或结束于域间边界，则存在下列额外的理由使网关具有以信号方式发送给它们的新的承载片段的规范：制订承载流的策略，改变Diffserv标记，生成记账记录。虽然不可能在交换链路或网络上需要进行实际的资源保留，但是RAC功能将很可能被b-CSCF调用以检查每个管理域对策略的遵守，该策略涉及它准备从其他处接受的流的类型和数量。

附图说明

本发明的其他特点和优点将因为以下结合所附附图的详细描述而变得更显而易见。

图1是示意性地示出了典型的下一代网络架构的框图，在该下一代网络架构中可以实施本发明的方法；

图2是示意性地示出图1的网络中的承载流片段的框图；

图3是示意性地示出对于包含两个域的会话，对资源和许可控制功能的控制的框图；

图4是示意性地示出根据本发明的一个方面的使用对锁定式(pin)承载片段的网络地址映射的框图；

图5是示意性地示出根据本发明的一个方面的在包含多个承载偏度的网络中使用对锁定式承载片段的网络地址映射的框图；

图6是示意性地示出根据本发明的一个方面的在包含多个IP地址域的网络中使用对锁定式承载片段的网络地址映射的框图；

图7是示意性地示出根据本发明的一个方面的支持非SIP客户端的方法的框图；

图8是示意性地示出根据本发明的一个方面的在包含多个IP地址域的网络中支持非SIP客户端的方法的框图；

图9是示意性地示出根据本发明的一个方面的与遗留协议交互工作的方法的框图；

图10是示意性地示出根据本发明的一个方面的RSVP到SIP交互工作的方法的消息流图；

图11是示意性地示出根据本发明的一个方面的RTSP到SIP交互工作的方法的消息流图；

图12是示意性地示出根据本发明的一个方面的支持与遗留协议交互工作的服务器的操作的框图；

图13是示意性地示出根据本发明的一个方面的用于支持RSVP到SIP交互工作的服务器的操作的消息流图；以及

图14是示意性地示出根据本发明的一个方面的用于支持RTSP到SIP交互工作的服务器的操作的消息流图。

注意，在所有附图中，相同的特征以相同的参考数字标识。

具体实施方式

本发明提供在下一代网络中能够对普通承载流作QoS处理的方法和技术。以下参照图4-14，仅以实例的方式描述本发明的实施例。

总体上，本发明提供的方法和系统可单独或者组合使用来扩展NGN的IMS/SIP系统，以向普通承载流提供QoS服务。这些方法和系统可以被宽泛地分成4个类别，即：SIP到普通承载流的扩展；把通信会话的承载流到用于建立会话的SIP信令所经过的AG和TBG上的锁定(pinning)；非SIP客户端的支持；和用于遗留IP信令的网关功能性。这些类别的每一个将通过典型的例子在以下描述中进行解释。

应当注意，本申请主要针对用于普通承载流的遗留信令的网关功能性。用于把通信会话的承载流锁定到被用于建立会话的SIP信令经过的AG和TBG上以及对非SIP客户端的支持的技术分别是申请人的共同未决的美国专利申请号xx/xxx,xxx(题为Pinning the Route of IP Bearer Flows in a Next GenerationNetwork)和yy/yyy，yyy(题为Serving Gateway Proxies fornon SIP speakers in a Next Generation Network)关注的焦点，这两者随本申请同时提交。

普通承载流

当前定义的SIP和IMS受限于它们只能处理作为多媒体流的承载流。但是如果许多其它的应用的承载流能够被IMS识别，那么它们可以利用IMS架构。

根据本发明的一个方面，通过下列方式可以客户该限制：加入描述普通承载流的QoS要求的显式业务规范(T-Spec)参数到SIP信令中的SDP；并且扩展IMS中的RACS机制以解释新的T-Spec参数。在SIP信令的SDP部分加入显式T-Spec参数可使得两个SIP端点为下列任何任意的流请求网络执行资源分配和/或连接许可控制：普通承载流。因此，尽管对于RTP或多媒体承载流，IMS功能单元从媒体编码和其他媒体描述性SDP参数中推导出资源需求，但是对于普通承载流，CSCF将使用显式T-Spec参数作为资源和许可控制处理的基础。

例如，考虑在其中采用ITU推荐Y.1541的服务指定类别的网络。在该例中，根据RFC2327的指南，显式T-Spec可以由两个媒体层面的属性行组成，一个指定Y.1541服务类别并且另一个指定要求的容量或带宽.因此：

a＝ITU-CLassOfService:0

a＝ITU-Capacity:0

上式可以被用于指定承载流要求的100kb/s和服务类别0(即，根据Y.1541，端到端的延时少于100毫秒等)。

如果需要的话，可以使用其它方法来表达显式T-Spec参数。例如，下面描述的表示方案中，运营商可以选择分配名称给带宽和业务类别的组合，其使得可以使用单个SDP属性(即，分配的名称)来提供显式T-Spec。

例子使用：

一个旅游企业雇员使用VPN客户端建立从她的膝上型计算机返回到她的企业VPN服务器的IPSec隧道，使得她可以接入企业网络的设施，包括它的IP PBX以拨打和接收电话呼叫。如果该IPSec隧道是在尽力而为型互联网上被建立的，那么加密包的延时、抖动和损失比率将会不确定并且将不足以支持其膝上型计算机上的软客户端和企业IP PBX之间的VoIP会话。为保证QoS对于IPSec隧道中的语音包时合适的，要求将IPSec隧道作为普通承载来对待。

支持普通承载的运营商可以为每个业务类别的有限数量的带宽(传输容量)选择收费标准，然后对传输容量和业务类别的每个组合赋予标准的名称。例子可以是：

votel＝100kb/s最小延时、最小抖动、收费标准$0.02每分钟，

vidtel＝1Mb/s最小延时、最小抖动、$0.10。

sdtv＝1.5Mb/s下游、保证的吞吐量、$0.03；

hdtv＝8Mb/s下游、保证的吞吐量、$0.06；

它们分别用于语音电话、视频电话、标准清晰度视频流和高清晰度视频流的目的。标准名称然后可以被用作SIP消息的SDP部分中的独有的T-Spec参数。在该例中，将“votel”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服务器之间的安全机制(securityassociation)，然后使用IKE(互联网密钥交换，Internet KeyExchange)协议序列以常规方式执行，条件是由VPN客户端在它的IKE消息中宣称的身份必须可被VPN服务器翻译成VPN客户端的SIP身份(URI)。这一点可以通过让VPN客户端的身份成为它的SIP URI来确保，但是对于更强的保护，客户端的SIP地址可以作为授权过程(例如，RADIUS或DIAMETER响应的部分)的结果返回。

一旦VPN服务器对客户端作了鉴权(实际上在IKE的两个阶段完成后)，它通过在公共域中发布SIP邀请消息将“呼叫”放至VPN客户端。SDP中的F-Spec识别已经协商一致的隧道端点。(注意，标准的IPSec包在它们的报头没有端口号码，但是具有安全参数索引域，其对于给定地址对之间的每个隧道是唯一的。该域可以被用于F-Spec，但实际上，由于网络中网络地址转换(NAT)的存在，操作的VPN接入类型的数据封装(tunneling)的正常模式用于在UDP数据报中封装IPSec包，因此，正常类型的F-Spec用于识别包的IPsec隧道流。)在操作的一种模式中，VPN客户端的T-Spec作为授权过程的一部分返回到VPN服务器，即，每个VPN客户端总是具有由管理员设置的固定的QoS级别。在该例中，T-Spec作为来自VPN服务器的邀请(INVITE)消息中的SDP的一部分被包含在内。

在IMS的正常形式中，SIP邀请信令消息通过公共IMS CSCF被转发到VPN客户端的SIP客户端部分。

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

IMS系统建立会话，通知AG和TBG，它的F-Spec的IPSec隧道经过，并且指令它们提供由T-Spec指定的QoS处理。IMS系统还将产生要求的记账记录，从而随后可以向企业收取服务的费用。

VPN服务器到客户端之间的IPSec隧道现在是普通承载路径：由客户端或服务器发送的匹配F-spec的包被确保在它们经过的每个域具有指定的QoS处理。注意，由于加密隐藏了隧道中的所有包的真正报头，因此所有包得到统一的QoS处理。另外，因为IPSec可以依赖序列的完整性，所以向IPSec包报头传输原始diff-serv标记并且使用它们来给不同包的类别以不同的QoS处理并不是一个好主意。相反地，如果实施方案想限制IPSec普通承载中的业务来调节(加密的)多媒体流，那么它将不得不为多媒体流和尽力而为业务建立单独的IPSec隧道-没有必要为尽力而为隧道使用SIP请求QoS处理，但是可以为不同的流的类型建立不同的IPSec隧道，每一个用单独的T-Spec消息发送信号。

一旦安全建立丢失，VPN服务器立刻终止SIP会话。

本领域的专业技术人员将认识到以上所述可以有各种变化。尤其是，可以不是在隧道建立期间从网络请求IPSec隧道的QoS处理，而是仅仅当真正发起了语音呼叫时或者甚至仅仅当监视的尽力而为传输的性能在呼叫期间低于某阈值时。进一步的增强可以使服务器在IP-Sec隧道被发起后，立即建立具有最小QoS处理的普通承载流，但是然后服务器可以使用SIP重邀请来修改流的服务类别/带宽以响应隧道内的探查(snooping)消息(例如，软电话客户端和IP PBX之间的SIP消息)和/或企业域内服务器的请求。

锁定承载流

如图1所示，会话的端点可以使用用于经过几个域的会话的SIP信令和承载流被连接到不同的(核心)网络。目前，在IMS中，对于承载流中的包所沿路径并没有很多关注-通常假定它们将沿由IP路由确定的路径。另一方面，SIP信令的路由通过一系列的CSCF至少部分地被定义，其中CSCF互相之间是成对的对等体。在NGN中，在每个CSCF上SIP消息的转发选择由策略指定(基于转接的商业协定等)。因此，在发起者和终止者在不同的域的情况下，由SIP信令经过的中间域不需要完全一致于在IP转发规则的正常操作下，IP包从发起者发送并寻址到终止方所经历的域。

但是，承载流的路径为何不应仅由IP路由确定并且还应被显式设定为经过指定的域和指定的传输边界网关(TBG)有两个好的理由。第一，从商业的角度，因为如果域不知道流属于哪个会话，则它就不能为它生成记账记录，很可能迫切要求会话的承载流不要经过未参与该会话的信令传送的域。第二，向承载流的QoS的提供经常要求将承载流的授权通知路径上的网络单元以接收QoS。因此对于在核心网络和/或交换链路上的QoS，承载流的路径必须被限制为通过(被锁定)在会话建立时由b-CSCF选择的TBG，因为b-CSCF可以只发送授权到它们控制的TBG上。

除了锁定承载流的上述两个原因以外，涉及建立会话的CSCF可以确定承载流需要经过某种类型的媒体网关。由于会话端点没有相互共有的编解码器，所以在承载流路径中可能需要媒体网关执行媒体样本的代码转换。媒体网关的另一个用法可能是因为端点之一被合法侦听(LI)命令的控制并且会话的媒体流需要被通过LI网关，从而它们的拷贝可以被安全地转发到相关的法律当局。

本发明的第二方面是为会话的承载流提供路径锁定机制，使得承载包经过在会话建立时确定的特定的网关链。以下的描述和图4-6专注于将承载流锁定到传输边界网关(TBG)，但是对于本领域的专业技术人员来说，根据这里的描述，涵盖到其他网关(媒体转换、合法截取等)的锁定的扩展看来是显然的。如前所述以及如在图2中所描述的，承载流可以被分割为承载(流)片段的串联级联。除了第一流片段的起点和最后片段的终点以外，这些承载片段在网关14开始和结束。当要将承载流锁定到TBG14时，中间承载片段20的起点和终点是TBG14。

注意，由于配属网络6不跟随IP转发，所以特定终端8或服务器8b的业务在它们配属到网络的期间内被锁定在特定AG10，也即，第一和最后的承载片段一直在适当的位置。披露的机制用于在AG10之间锁定承载路径。

网络单元能力

下面分三部分披露锁定承载流的机制。首先描述的是当所有网络单元位于相同IP地址域时它如何工作；然后描述当客户端TE位于私有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的机制。

基本机制

本部分披露了一种实现用于作为相同IP地址域的所有部分的联合域(例如，公共地址域，IPv4或IPv6)的承载流锁定的方法。如上所述，承载流的SDP参数隐含地包含承载流的F-Spec，其通过源和目标IP地址、包类型及源和目标端口号识别流。严格地讲，F-Spec识别单向的流，但是很明显，反向流的F-Spec可以从原始的F-Spec轻易地(trivially)生成，所以当期望建立双向流时，我们仍然将讨论单个F-Spec。在该首次实现中，所有F-Spec IP地址属于相同的IP地址域。

该方法的本质是，SIP信令路径上的CSCF通过改变传输到下一个CSCF的F-Spec，将承载流分成承载片段，从而修改的F-Spec仅仅描述由相关的CSCF控制的网关之间的承载片段。然后，CSCF在那些网关中安装双向“交叉连接”映射，使得进入的承载片段中的包被网关转发到下一个承载片段。这里描述的特定示例中，“交叉连接”映射是NAT映射并且包到下一个承载片段的转发是通过下列方式完成的，执行进入包的报头中的地址和端口的NAT转换从而使它们成为承载路径的下一片段的包，并且然后根据正常IP路由程序转发包。

参考图4，首先对于包含两个域的会话发起来详细描述该机制，为符号表示方便以左边域和右边域示出：在图4中，会话发起由SIP客户端TE8在左边域发起并且在右边域中在SIP客户端AS 8b终止，所以SIP邀请消息从左向右穿过并且响应(例如200OK)从右向左通过。描述的过程应用于域之间的每个边界，使得当包含多于两个域时，那么左边域是最接近发起者的一个(转发邀请消息到右边域)并且右边域是最接近终止者的一个(转发200OK消息到左边域)。

在图4中，在会话发起要建立的承载流中，承载流的TE端被指定为在IP地址A和端口a发起和终止，为其我们使用术语Aa。在SIP会话发起开始时，承载流的AS端的地址和端口号对于TE8是未知的，因此由TE8发布的SIP邀请消息24的SDP中的F-Spec是不完整的并且可以表示为[Aa，？？]。

当由TE8发布的SIP邀请消息到达在左边域的边界的b-CSCF16时，该b-CSCF选择TBG14来锁定通过的承载路径并且为TBG请求或生成映射(在26处)以应用到Aa。假定结果是映射 $\mathrm{Aa}\⇒\mathrm{Bb},$ 则b-CSCF修改F-Spec，将TE的发起IP地址和端口Aa替换为RBG的IP和端口Bb，并且转发该邀请(在28处)到右边域的它的对等实体。当邀请消息到达对等b-CSCF时，该b-CSCF可以选择在右边域的边缘的哪个TBG14将形成它的交换承载片段端(注意，在图4中，不像其他图，域之间的包传输以交换网络XN示出而不仅仅是交换链路，如果在对等TBG对之间仅有单个交换链路，那么左边域b-CSCF对TBG的选择将支配右边域中的TBG)。

右边域中的b-CSCF为选择的TBG14请求或生成映射(在30)以应用到Bb。再一次假定结果是 $\mathrm{Bb}\⇒\mathrm{Cc},$ 那么F-Spec被修改为[Cc，？？]。在图4中仅包含两个域的会话发起下，SIP邀请消息然后将前进(在32)经过右边域中的CSCF直到它到达目标SIP客户端22(在图4中，以应用服务器AS示出)。在更普遍的情况下，SIP邀请被转发到与下一个域对等的b-CSCF。

从AS 8b的角度看，它接收的SIP邀请正在请求具有Cc端点的承载流。假定AS以200OK消息回复，则它将指定它的承载流的端(例如，Zz)，从而200OK消息34的SDL中的F-Spec将会是[Cc，Zz]。(本领域中的技术人员将认识到，携带目标F-spec部分的响应消息可以是180响铃(Ringing)消息。)200OK消息经过邀请的相反路径并且返回到达在右边域b-CSCF。该b-CSCF将在36请求或生成另一个映射(例如 $\mathrm{Yy}\⇐\mathrm{Zz}$ )并且然后在TBG14中激活 $\mathrm{Bb}\⇔\mathrm{Cc},$ $\mathrm{Yy}\⇔\mathrm{Zz}$ 的全部IP报头双向网络地址转换。最后，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)以及最后具有[Aa，Xx]的200OK消息向发起SIP客户端的传播(在42)。从TE SIP客户端22的角度看，会话的承载流的其它端点是Xx，在左边域TBG14。

以上披露的过程所做的，实际上是将承载流分段成3个承载流片段并且在TBG中安装到“重标记”包的包，使得它们被转发到下一个片段。当它发送承载包到AS 8b时，TE8在它们上面放置Xx的目标地址，它在200OK F-Spec接收到目标地址。Xx是由TE的核心域中的TBG14供应的地址和端口号：第一承载流片段是在TE(地址A)和TBG(左边核心网络上地址X的信号装置)之间的配属片段和最左核心片段的级联。第二片段是左边TBG(交换网络上的地址B)和右边TBG(交换网络上的地址Y)之间的交换片段。第三片段，还是配属片段和核心片段的级联，位于右边TBG(右边核心网络上的地址C的信号装置)和AS(地址Z)之间。由于包报头中的目标地址是片段端点的IP地址，所以根据正常IP路由规则，包沿着每个单独承载片段被转发到承载片段的端点。在TBG上，包报头被重写以将包置于下一个承载片段的开始处。那些熟悉标记交换路径的技术人员可以认识到这是标记交换的一种形式，其中标记域是整个IP报头源和目标地址和端口域。当在发起和终止域之间有多个域时，这种观察本机制的方法可以被应用于解释其应用的结果。图5在图2中增加了定义每个承载片段的NAT映射.

还可以观察到，当在单个IP地址域上操作时，仅仅目标地址需要被重映射，这是由于包中的源地址并不影响它们的路由。但是，由于源地址在各种安全检查(例如在防火墙中)下被使用，因此对于安装QoS策略，需要一致的方法。当包含了多个地址域(见下)时，源地址必须被重映射，所以我们采取了始终应该这样的方法。

还应该注意到在单个IP地址域中，NAT“标记交换”仅仅在一些节点需要，在这些节点上可能不依赖IP转发将包转发到下一承载片段。承载流仅仅需要在网关(它可能并不总在IP转发流路径上)被分段。通常，域间交换链路包含的拓扑可以保证网关将始终在IP转发流路径上并且因此不需要是承载片段端点。例如，如果有单对互连两个域的TBG并且确保它们之间的最短路径不经过第三个域，那么从TE到AS的单个承载片段将足以确保那些包总是经过TBG对。

多IP地址域

上述的NGN组织不要求每个管理域都是同一IP地址域的一部分。相反，由于被叫方通过URI而不是IP地址在SIP消息中被识别，所以CSCF链可以跨越IP地址域边界向被叫方转发SIP消息。这要求当b-CSCF从不在同一个地址域的它们的对等实体接收SIP信令时，它们能使SIP信令适合于它们自己的IP地址域。例如在图6中，IPv6域中的b-CSCF将从在公共IPv4域中的它的对等实体接收IPv4格式的SIP消息并且在转发它们到它的自己域中的CSCF之前，将不得不将该消息重新格式化成IPv6形式。如前所述，SIP消息在SDP部分包含了要建立的承载流的隐含的流规范(F-Specs)。当承载流要经过多个地址域时，SIP消息中的F-spec需要在地址域边界处被改变以反映将要对承载流产生作用的网络地址和端口的转换。重新格式化SIP消息和改变F-Specs经常称为SIP ALG(应用层网关，Application LayerGateway)功能。

图6描述使用3个IP地址域的两个管理域：服务于终端(TE)的管理域为终端分配私有IPv4地址(可能是因为它没有足够的公共IPv4地址进行分配以给每个终端一个自己的公共IP地址)，但在核心网络中使用公共地址，虽然其他管理域全部使用IPv6地址。互连两个NGN域的交换网络在图6中以IPv4网络、部分公共IPv4地址域示出。这是一个随意的选择并且交换网络可以同样是IPv6地址域的一部分。

比较图4与图6，可以观察到在左边AG有地址域边界。当这些包在连接网络和核心网络之间穿过时，该AG需要在包上执行NAT功能。因此控制AG的p-CSCF、与配属于AG10的TE8中的SIP客户端22对等的p-CSCF16需要转换SIP消息中的SDP中的F-Spec(使得承载流看起来是在AG发起)，并且在AG中安装必需的NAT映射以终止配属承载片段和发起核心承载片段。具体地，如图6中示出的地址是私有IP地址和端口分配，而Bb是由AG10在核心网络内通告的公共IP地址(和端口号)。再一次，熟悉私有和公共IPv4路由和默认路由的技术人员将注意到，由于私有和公共IPv4地址并不重叠并且任何情况下都将包转发到AG，所以所示的映射 $\mathrm{Ww}\⇐\mathrm{Xx}$ 不是严格需要的。但是不在承载包上进行完整的IP报头重映射在将承载流正向和反向划分为承载片段中产生不对称，并且这会造成难解的维护问题。

图6中的其它地址域边界在右边域TBG。该TBG具有一个或多个运行在IPv4地址域内的接口，并且明确地，地址Y是这些接口(或这些接口之一)的IPv4地址。它还具有一个或多个运行在IPv6地址域中的接口，其中地址D是TBG IPv6接口地址。如前所述，从左边域b-CSCF到达右边域b-CSCF的SIP消息将是IPv4格式，具有IPv4报头和所有嵌入IP地址的v4。b-CSCF在转发消息到下一CSCF前必须转换这些消息以具有IPv6报头和嵌入的IP地址。对于SIP邀请消息的SDP中的F-Spec，转换必须匹配将要被安装在TBG中的NAT映射，即与披露的路由锁定过程比没有改变。

在用户范围隐藏的NAT

知道公共VoIP服务的实际部署议题的技术人员将认识到，在TE和连接网络(AN)之间经常执行NAT功能。该功能在具有私有IP地址域的住所或企业的边界发生。现今，该NAT功能并不是SIP察觉(SIP aware)的(即，并不包含SIP应用层网关(ALG))。但是，这种现象并不实质上影响到上述机制；现今使得VoIP工作的相同的解决方案可以继续被使用。因此，客户端通过确定什么NAT映射被应用(通过首先询问STUN(经过NAT的UDP的简单历程)服务器)来“修复”SIP信令，(见RFC 3489)；或者p-CSCF检测在来自客户端的SIP信令上已经执行了NAT转换(由于嵌入在邀请或回复消息的SDP中的客户端IP地址与消息报头中的IP源地址不匹配)，并且当处理该承载流时指示AG为此做补偿。

在将来，执行NAT功能的用户边缘设备的住所网关可以被加强为包含p-CSCF功能或者被p-CSCF控制，使得住所内的承载流的片段完全在SIP会话建立过程的控制之下。

网络地址转换的(NATting)承载流的其他好处

以上披露的路由锁定机制的优势是它使用在TBG(和AG)中频繁出现的能力(NAT)并且它不要求任何来自在核心网络中其他路由器的支持。该机制使得NAT功能被应用于跨越管理域的所有承载路径.它还使得NAT功能在AG被应用，即使当配属网络与核心网络位于相同的IP地址域。以下是始终作网络地址转换的承载流的两种另外的好处的简单描述，其使得它成为IMS中的承载流的路由锁定的优选方法。

匿名

在PSTN中，呼叫方可以请求不向被叫方显示呼叫着的电话号码。SIP信令支持呼叫方的SIP地址的抑制但是承载包的源IP地址对于被叫方来说足以确定呼叫方的身份或呼叫方的位置。起码，拥有呼叫方的IP地址将使得被叫方易于针对呼叫者发动拒绝服务的攻击或者进行一些其他形式的互联网骚扰。如果，照例，承载流被破解成承载片段并且每一方只看到它们本地AG的IP地址，那么进行或接收SIP呼叫将不会向任一方暴露其他方的IP地址，也不会在完全授权方的IMS框架以外展开与那一方的任何方式的通信。

屏蔽合法侦听

需要方法来实现合法侦听，即侦听的目标不能够检测到她的通信正在被侦听。实现合法侦听的另一约束是除了直接负责完成侦听那些人以外的操作人员不能检测到侦听就绪，这种约束通常导致在目标的主核心网络中部署特定目的的侦听媒体网关。当如上所述使用NAT时，展示给端客户端的SDP描述和承载流的实际包报头不包含其他方的IP地址而包含中间网关的IP地址，然后用户无法辨别(从IP地址中检查)她的承载路径是否已经被转移到侦听媒体网关以制作承载路径包的拷贝。

非SIP客户端的支持

IMS的开发基于这样的假设：即会话的两端的实体(例如，图1中的客户端和应用服务器)为了能够建立承载流，使用SIP协议(懂SIP的)。以上描述的方法将IMS的应用能力扩展到对于承载流(不一定必须是多媒体流)要求有QoS处理的应用，但是该应用仍然需要是有SIP能力的。虽然合理假设应用服务器具有SIP功能性，但是期望的是能够建立至不懂SIP的客户端的承载流。如果在应用可以充分利用新的NGN提供的QoS传输之前，应用客户端(其比服务器的数量多得多)必须被升级到具有SIP功能性，那么这种能力将更快地(比起将要发生的情况)展现由NGN IMS网络支持的有用的服务和应用的范围。

根据本发明的第三方面，应用-未知客户端代理与控制配属网关10的CSCF关联，非SIP客户端通过配属网关10配属到网络。客户端代理代表客户端，响应来自应用服务器的SIP邀请消息，使得可以提供经过至少是连接片段的承载流的QoS处理。在以下描述的实施例中，应用服务器可以是有SIP知觉的并且能够调用这里所描述的机制的服务器。替代地，可以部署具有所要求的功能性的应用服务器代理以代替升级应用服务器。在任一情况下，本技术消除了为所有可能的应用客户端类型部署应用知觉的特定代理的需要(其在多域网络内将会是非常困难的过程)。本发明可以通过使对应用客户端所配属的AG进行控制的p-CSCF得到加强来实施，以为客户端提供一般应用的独立代理功能。

下面我们描述本发明的两种典型实施例：1)其中，仅确保了承载流的应用客户端端配属片段的QoS处理，和2)其中，向整个承载流提供QoS处理。第一种实现对于许多部署来说很可能十分有用，这是因为与核心网络相比，在配属网络中带宽受到更多的限制，尤其是具有无线最后一英里的那些配属网络。

客户端配属承载片段的QoS处理：

在该实施例中，目标是仅仅为应用客户端的配属承载片段提供QoS处理(见图7)。假定AS 8b(应用服务器或者它的代理)是向某个IMS域(服务器的主域)中的S-CSCF注册的懂SIP的实体。应用客户端配属到某个域(在图7中指示为客户端的服务域)的核心网络，从其中它接收到NGN网络的IP连接性。由于该应用客户端8不是SIP知觉的，所以它没有向任何CSCF注册。但是，应用客户端的配属点被假定为在客户端的服务域中的p-CSCF的控制之下的AG。该AG被指示为TE的服务网关。

虽然图7示出客户端的服务域被转接链路将其与服务主域隔开0个或多个互连它们的转接域，但是本发明还可应用于应用服务器和客户端处以相同域的网络。为清楚起见，以下的描述首先假定域(服务器的主域，客户端的服务域和任意转接域)都是同一IP地址域的一部分，处理位于分立的IP地址域的域的其他机制在本部分结尾披露。

由于应用服务器8b将发送包(在承载流中)到客户端8，它必须能够为承载流生成F-Spec(否则，它将不能生成包的IP报头)。通常，在有需要建立承载流之前，在客户端和服务器之间已经有一些交互：例子在IPSec隧道建立之前的互联网密钥交换(IKE)交互，或者在视频片段被流向客户端之前为选择它的巡航。从初始交换的IP报头中，服务器将获得承载流的客户端的端的IP地址和端口号。服务器得知的客户端的IP地址是由AG10(客户端8通过AG10配属于核心网络4)通告的地址。实际上，F-Spec描述应用服务器10到AG8b的承载片段。AG10使用进入包中的客户端IP地址来控制它们到配属承载片段，配属承载片段构成到客户端8的完整的流路径。

本发明构思一种新的SIP URI(统一资源定位符)的形式，我们将其称作服务网关URI，用作邀请由应用服务器8b生成的SIP邀请消息的目标参数(并且被插入到“TO”语句)。该URI中的标识符是IP地址的表示：该URI的希望表示的语义是由该URI命名的目标(被叫方)是p-CSCF16，其可以推行策略到通告该URI中的IP地址的AG10。

有多种机制可以被用于路由SIP邀请消息，其拥有这种新的服务网关URI作为它们的目标。例如，如果b-CSCF与它们所在其中的AS(自治子系统)关联，并且AS编号在它们的对等b-CSCF的转发表中被提供，则当b-CSCF接收邀请消息时，它仅需确定“下一跳”AS用于BGP-4路由到目标IP地址，以识别转发该邀请到什么新的管理域和对等b-CSCF。一旦邀请(INVITE)到达了目标管理域，它可以被转发到特殊指定的S-CSCF，域中的所有p-CSCF已经将它们控制的网关的地址范围在特殊指定的S-CSCF上作了注册。该指定的S-CSCF然后匹配服务网关URI到地址范围来确定转发邀请消息到哪个p-CSCF。如果需要，还可以使用其他转发方法。

在上述假定下，应用服务器和客户端间的承载流的建立过程如下：

在第一步骤，应用服务器8b在它的主域(通过它的p-CSCF)中向它的S-CSCF发送SIP邀请，该SIP邀请具有的TO语句，该TO语句包含指定客户端的IP地址的服务网关URI并且在SDP部分包含到客户端的承载流的F-spec和服务器想应用的T-spec。(由于是服务器对会话计费，所以指定T-Spec是服务器的特权。)

一旦S-CSCF对邀请(INVITE)执行了正常的发起处理，它向客户端的服务域转发该邀请。如果客户端的服务域区别于服务器的主域，那么例如使用上述的转发决定过程，邀请将会通过b-CSCF被转发，可能穿过几个域边界直到它到达客户端的服务域的边界处的b-CSCF。

一旦邀请到达客户端服务域中的b-CSCF，它就要被转发到控制客户端8实际配属的AG10(调用AG10的策略决定功能)的p-CSCF。再一次，上述的示例机制可以被使用，但是本领域的专业技术人员将认识有多种可能的机制。

在接收到邀请消息后，p-CSCF请求AG(AG的RACF)在配属网络中安装QoS策略，其与为承载流指定的T-Spec相符，承载流由邀请消息的SDP中的F-Spec识别。就在这一点，p-CSCF的修改的行为破门而入(kick in)，由包含服务网关URI的TO语句和尝试安装QoS策略的结果触发。在常规的系统中，p-CSCF将转发邀请到客户端8，其在本例中(该客户端是非SIP客户端)将不知道如何处理它。因此，根据本发明，为客户端8例示的普通代理44(或者，等价的，p-CSCF担任普通代理的能力)代表客户端8发送适当的SIP回复到应用服务器8b。如果在AG上安装QoS的策略的尝试成功了，那么普通代理沿着邀请的相反路径向应用服务器8b发送回接受(例如，“200OK”)消息。或者，如果QoS策略安装请求失败，那么来自普通代理44的返回消息将会以再见(BYE)消息代替，以向服务器8b指示在配属网络中没有足够的资源来支持承载流的T-Spec请求。将注意到，在该操作中，QoS处理应用于配属承载片段，并且SIP信令生成以完成承载流的建立，但是b-CSCF(或者普通代理44)对该客户端应用没有任何察觉。如此，普通代理44是真正意义上的普通的，它可以被用于为任何客户端应用建立具有QoS处理的承载流。

一旦应用服务器8b完成SIP会话建立，它发送到与F-Spec相符的客户端8的包将以通常的尽力而为的方式经过各种中间域，但将以指定的QoS经过接入/配属网络6。

当应用服务器8b完成对客户端8的服务时，它可以通过沿着最初的邀请(INVITE)的路径发送SIP再见(SIP BYE)消息释放QoS资源。当它到达p-CSCF时，再见消息将导致以正常的方式释放承载流的QoS策略，但是再一次，它将是p-CSCF(或者普通代理44)而不是客户端应用本身，其生成SIP确认通知。

注意当配属网络中的QoS策略由被称为“拉”机制安装时，以上披露的机制将不能与未修改的应用客户端工作，这是由于“拉”机制要求客户端被包含在处理中，并且描述的方法的本质是在没有涉及客户端的情况下在配属网络中安装QoS策略。

处理NAT：多个IP地址域

如上所述，当TE8和AS 8b位于不同的IP地址域时，需要处理两种情况。其中的第一种情况是当TE88在私有IP地址域并且核心网络是单个公共IP地址域的一部分时。AG 8b执行NAT功能，转换即将进入核心网络4的包上的IP报头，使得来自客户端8的包中的源地址是由AG10在包到达应用服务器8b时通告的公共地址。假定应用服务器8b使用该公共地址建立服务网关URI和F-Spec(和控制包内没有未转换的地址)，则该邀请消息将到达上述的控制p-CSCF。p-CSCF使用公共IP地址域F-spec进行它的RACF请求：察觉到它是来自客户端8的网络地址转换的业务的AG10在安装任何IP层“关”于配属网络中之前，需要映射F-spec中的IP地址。

当核心网络14之间有IP地址域边界时，事情会变得有点棘手：承载流路径实际上在执行内部地址域NAT的TBG14上被分割上了两部分。在图8中，示出的的左边IP地址域和右边IP地址域之间的边界位于服务器的主域(尽管它可以是在任何域的边界)和TBG14的边缘，其中有一个在所有业务上执行NAT。从生成服务网关URI的应用服务器8b的角度看，该TBG14为服务网关(即，来自TE客户端的到达的包中源地址的信号装置，在图8中应用服务器看到B的源地址，其是在右边IP地址域中的地址)。

使用例如与上述相同的机制，SIP邀请消息可以被路由到控制NAT TBG14的b-CSCF。如上所述，控制地址域边界TBG的b-CSCF必须可以执行控制SIP ALG功能。在该例中，用于感兴趣的F-Spec的NAT映射在SIP邀请消息到达控制网关之前将已经被安装在NAT TBG中。b-CSCF的第一行动必须是轮询用于NAT映射的TBG14，使得它然后可以使用TE8配属于的AG10的服务网关URI和客户端端承载片段的F-Spec，为客户端侧(左边)IP地址域构建邀请消息。在图8中，新的服务网关URI将包含地址A。根据上述进行的过程的这一点，借助b-CSCF对回复的SIP消息执行要求的ALG功能。

当处理核心网络之间的IP地址域边界时有一个防止误解的说明。如上所述，承载流的路由的IP路径可能不会和SIP信令经过相同的域。具体来说，可能有网络，在这些网络中路由的IP地址可能经过未作为NGN中参与方的域。如果NAT转换在不是NGN的部分(即，不在b-CSCF的控制之下)的边界网关发生，那么上述机制将会失败。围绕这种情况的工作将使用全路由锁定，在下一部分中将描述。

例子：

使用本发明的典型例子将会是用于遗留(即，先于SIP的)流视频服务。视频服务供应商可能期望以这样的质量等级传递流视频，该等级高于大多数接入/配属网络在服务的“尽力而为”的等级下可靠提供的服务质量。一旦本发明被部署在NGN中，视频服务供应商将升级它的服务器到有SIP能力的(包括可以生成服务网关URI)并且然后议定来自本地运营商的IMS服务。本地运营商将设定一个费率，其可以是以一部电影为单位的或基于时间的或者以在指定的QoS类别下传送的1兆字节为单位。这种费率的形式将依赖于竞争性因素并且对于保持“在网的(on-net)”(客户端配属到运营商拥有的网络)的会话，并且将很可能低于运营商必须与一个或多个其他运营商分享费用的会话的费率。费率还可以是专门针对应用客户端在使用的配属网络的类型，无线的收费比有线的收费高。当会话中有失败时，那么视频服务供应商和NGN运营商之间的SLA也将包含退款的议题。

视频服务的潜在客户端如往常一样进行，与视频应用服务器交互来浏览并选择电影。作为浏览响应显示的一部分，观看电影的价格将显示给用户：假定视频服务供应商将设置价格以覆盖传递费率的成本。可能电影以不同的分辨率、不同的价格呈现，适用于不同的客户端配属网络。一旦用户选择完成，视频服务器发起具有邀请的TO语句的SIP会话，邀请包含具有客户端的IP地址的服务网关URI和视频流的T-Spec。这将导致服务于客户端的AG，该客户端在其正在使用的配属网络中安装QoS策略，使得从服务器到目的地为客户端的视频内容包接收视频服务器在邀请消息中请求的QoS处理。

承载流的端到端QoS处理

如上所述，NGN网络可以向承载流的所有片段提供QoS处理，其中承载流被“锁定”尽管参与在SIP信令交换的管理域的TBG。当TE客户端不懂SIP(not SIP speaker)时，这种机制和所得到端到端QoS能力可以与服务器网关URI的使用结合。与仅仅在客户端配属片段上传递QoS的机制相比，结合的机制具有每一个p-CSCF和b-CSCF(当服务器的邀请消息路由到控制TE的服务网关时对其进行处理)还使网关准备(prime)进行NAT转换以锁定承载流，使得它接收请求的QoS处理量。

除了配属片段上的QoS所需的条件和假设之外，传递端到端QoS还需要一个额外的条件：当发送作为承载流的一部分的包时，应用服务器必须使用来自在SIP回复“200OK”消息中接收的最终F-Spec的目标地址和端口号而不是它从遗留协议(它将其放在初始F-Spec中)得到的初始客户端地址和端口号。

由于由CSCF生成的最终F-Spec使用它的在包报头的地址为应用服务器定义了配属承载片段确保了：即使当应用服务器具有在合适位置的多个网络配属链路时，应用服务器将向AG转发承载包，其中SIP信令使AG“作准备”(primed)以传递QoS并且映射包报头，使得转发该包到下一承载片段；以及，当要经过多于一个IP地址域时，路由锁定操作导致NAT网关的使用，NAT网关具有由控制b-CSCF设置的它们的NAT映射。

好处：

本方法的好处可以从以上遗留视频流服务的例子看出。本发明没有就绪(in place)的话，视频服务供应商确保给遗留(即，非SIP)客户端的QoS的唯一方法将是视频服务供应商与其用户所使用的每个配属网络供应商建立特定的关系，使得来自他的视频服务器的所有业务在那些配属网络上是达成一致的增强的QoS。这有一个缺点是该服务将被限制在地理范围内或者该视频服务供应商必须与任何他的用户想要使用的每一个配属网络供应商协商。借助本发明，视频服务供应商仅需与作为NGN一部分的一个运营商协商并且然后可以服务于配属任何NGN运营商的网络的用户。还存在静态地保存接入网络中的资源的问题，为此接入网络供应商可能合理地想得到报酬而不管视频服务供应商是否使用他们。这将很可能导致视频服务供应商以保守的态度考虑他在每个配属网络上所保留的视频会话的容量和数量；视频服务器将必须根据这些保留的/分配前的资源运行它自己的RAC以确保没有违背SLA业务类别。

熟悉SIP操作的技术人员将认识到，即使当一端不是SIP察觉的，能够使用SIP来建立承载路径还有其他好处。例如，可能发生的是，在会话过程期间，配属网络可能不再支持在会话发起时所同意的T-Spec-例如，移动终端可能移动到离基站更远并且两者之间的可用传输比率已经被减少。在RACS子系统的适当操作中，控制p-CSCF将会被通知它推行的QoS策略可能不再满足。它然后可以发起返回到发起者的重邀请SIP信令序列，包括发送回反映当前配属链路特性的T-Spec。然后是重新建立较低QoS的会话或者终止它的应用决定。

用于遗留IP信令的网关

如上所述，所披露的在NGN上向不懂SIP的应用传递QoS的方法的替代方案是为客户端和服务器开发专用的懂SIP的代理.这种解决方案的问题是需要迎合大范围的潜在应用。但是，一些应用可能已经使用资源保存协议(遗留IP信令)的某种形式并且这些协议的数量十分有限。很可能仅两种需要被考虑，它们是RSTP[H.Schulzrinne等人，“Real Time Streaming Protocol(RTSP)”，RFC2326，1998年4月]和RSVP[R.Braden(编辑)等人，“Resource ReSerVation Protocol(RSVP)”，RFC2205，1997年9月]。本发明的第四个方面提供了一种网关装置，其提供遗留IP信令到SIP信令的交互工作。因此，可以提供交互工作网关，其负责信令交互工作功能(SIWF)，该信令交互工作功能(SIWF)在网络的边缘终止RTSP和/或RSVP信令并且生成经过核心网络的SIP消息以建立(QoS能力的)端到端承载路径。

图9是交互工作网关的部署的描述。在该图中，信令交互工作功能(SIWF)显示为安置(host)在服务的AG上，该服务的AG用于与承载流互连起来的两个应用实体(TE上的客户端和AS上的服务器)。一直在往来端系统的包的路径上的AG是用于安置(host)信令交互工作功能的优选，这是因为使用深度的包检查(deep packet inspection)，它们可以检测带内遗留信令包(“带内”表示信令包与其他业务混合在一起)。但是，AG不是唯一的可能的选择。另一种可能的实现将AG的角色限制在检测信令包并在隧道的某种形式中转发它们，和限制在共处于与AG的控制p-CSCF相同平台的信令交互工作功能。

SIWF的操作可以简单地总结如下：

每个SIWF与p-CSCF建立关联并且将其自身注册为它服务的端系统的SIP客户端。如在服务网关(发明3)的情况下，注册的客户端地址可以只是由配属其的端系统的AG通告(advertise)的IP地址。或者，与商业上的考虑更一致的是，当由运送者授权时，应用服务器可以有管理程序分配的名字以使用SIWF功能性来建立经过NGN网络的QoS能力的承载路径。

当它检测到遗留信令消息(是建立发起于它所服务的端系统的承载流的请求)时，SIWF从该消息提取承载流的F-Spec和T-Spec两者，并且构建SIP邀请消息，其被寻址到与遗留消息寻址的同一实体。但是代替使邀请请求URI的配置部分(schemepart)作为“sip：”的是，遗留信令协议的名称可以被用作URI的第一部分以向目标指示邀请消息实际上来自于SIWF。初始的IP遗留信令消息还可以作为SIP消息体的域被运送，其方式与ISUP消息在SIP-I(也称为SIP-T)中被运送的方式相同。

NGN网络向注册了它的目标URI的名称的SIWF转发SIP邀请消息(假定目标通过支持SIWF(其注册了自己的名称或IP地址)功能的AG配属到NGN)。当邀请消息到达注册目标的SIWF时，那个SIWF就重建遗留信令消息(直接从邀请中运送的消息的封装版本或者通过倒置在邀请中生成F-Spec和T-Spec的过程)。重建的遗留消息然后被转发到目标实体。在本发明的一种实现中，SIWF将使遗留消息的表观源成为实际的发起实体，但在其他实现中，尤其是那些发起和目标实体在不同地址域的实现，SIWF将作为遗留信令消息的发起者出现。(后一方法使得SIWF接收遗留信令回复更简单了，这是因为它将会被指向它，但是由于它是NAT的一种形式，所以没有ALG它仍可以造成应用的破坏)

在适当的进程中，目标实体将生成遗留协议响应。这将会被服务AG获取并导向SIWF。SIWF将该响应与重建的初始消息和初始邀请匹配。SIWF将该遗留响应转换成SIP响应(例如，200O.K.)并且将它在返回信令路径上转发到服务于发起方的SIWF。SIP响应中的一些SDP域可以从遗留响应中的域中被提取，而其他将来自在邀请中传递的SDP。基于SDP中的F-Spec和T-Spec，信令路径上的CSCF将为承载路径保留资源。

当SIP响应到达服务发起方的SIWF时，它再一次重建遗留响应消息并转发它到实际的发起方上。

由于RSVP和RTSP是十分不同的协议，因此为每个协议分别提供SIWF过程的更详细的披露。

RSVP

现有操作模式

RSVP协议的目的在于保留网络中的资源以支持单向承载流(在RSVP RFC中简称称作“数据流”)。虽然RSVP可以被用于为多播流和一般任意到任意的会议会话保留资源，但本描述将它的使用限制于单播或者仅仅两个实体之间的点到点承载流，例如图9中的AS和TE。在RSVP的操作模式下，流的源发起带有“路径”消息的保留过程，“路径”消息包括F-Spec(称作过滤器规范，filterspec)和T-Spec的形式。对于单播承载流，F-Spec是源和目标IP地址和端口号(和协议)的完全元组(tuple)，称作固定过滤器，这表示在源发出“路径”消息之前，需要知道目标IP地址和端口号。

“路径”消息被寻址到承载流的目的接收方，并且因此沿着发送方和接收方之间的IP路由路径。在简单的单播情况中，“路径”消息的主要效果是在经过的RSVP可行路径中记录先前的跳地址(hop address)以便返回的消息，即“resv”消息，可以经过相同的路径从接收方返回到发送方。接收方回复“resv”消息，该消息反向沿着“路径”消息的每一个跳跃路径传送。由于它处理“resv”消息，所以每个RSVP可行路由器基于该“resv”消息中的T-Spec(称作流规范(flows pec)某种程度上有点混乱)负责提供(commit)承载流的网络资源。

使用RSVP到SIP SIWF网关

图10是概要消息序列图，示出了从应用服务器(As)到客户端终端设备(TE)的经过NGN的承载流的建立中的信令交互工作，其中As和TE两者使用RSVP来请求网络为该承载流提供QoS。SIWF功能位于来自AS和TE两者的第一IP跳跃，就根据图1描述的NGN架构而言，其暗示SIWF功能性被安置在配属网络(AG)上。(如上所述，该第一跳跃可以通过让AG认识并以隧道方式发送RSVP信令消息到另外安置在网络中的SIWF功能(例如，在与安置控制该AG的p-CSCF的相同的平台上)被扩展)。

假定AS提供给TE的应用由它们之间消息的交换发起。在某个点(例如，选择了一部电影，并且列出了付款细节)，AS确定它需要向TE传递包流(承载流)并且构建规定流的源和目标IP地址和端口号(F-Spec)以及流的T-Spec的“路径”消息。它使该消息寻址到TE并且在S2将它发送出去。“路径”消息由SIWF截获并且转换成SIP邀请消息S4。承载流的F-Spec和T-Spec被转换成SDP参数(使用用于T-Spec的发明1)并且，假定TE由IP地址识别，SIP目标URI将是服务网关URI(如上所述)。除了将F-Spec和T-Spec从RSVP格式转换到SIP格式，还有可能将初始RSVP消息附到SIP消息上。在SIWF机制的一个实施例中，整个RSVP“路径”消息可以作为邀请消息中的不透明域(opaque field)被封装并且运送。在另一个实施例中，仅仅“路径”消息的内部域而不是它的报头将会在邀请消息中被运送。如上所述，本发明的实施例可以选择改变URI的“配置”，得到邀请消息的第一行，就像是：

邀请rsvp：xxx.xxx.xxx.xxx SIP/2.y

其中xxx.xxx.xxx.xxx是IP(v4)地址。

NGN网络将以上述方式将SIP邀请消息转发到服务AG(服务TE)的p-CSCF。根据SIWF已经执行的注册IP地址(或者地址范围)的注册功能(对于其，可以执行它的交互工作功能)，p-CSCF将会变得可行。在URI中的配置已经改变的实施例中，将足以改变p-CSCF以转发邀请到服务SIWF。

SIWF然后使用初始路径消息的封装(部分)(如果它们被包含的话)，从邀请消息重新生成RSVP“路径”消息，并且将它自己的IP地址加入到该消息作为“先前跳跃”。它转发该“路径”消息到TE8上(在S6)。TE8将使用“resv”消息S8响应，该消息被寻址到安置SIWF功能(它的先前跳跃)的节点。在接收到邀请消息时，SIWF功能将匹配该“resp”消息(S8)与它安装的状态，并且根据那点，它将生成对邀请的响应(例如，200OK消息S10)。由于RSVP规则允许TE将“resp”中的T-Spec参数改成它在“路径”消息中接收的不同的值，SIWF将不得不为响应而再生SDP的T-spec部分，而不是仅仅传回它在邀请中接收的相同的值。200OK消息经过NGN被运送回服务AS的SIWF，在消息的路径上的CSCF向网关推行合适的策略，以便由SDP中的F-Spec描述的承载流将接收由SDP中的T-Spec指定的QoS处理。在SIWF重新生成“resv”消息S12并且将它转发到AS之后，该AS可以开始发送承载流包S14。

RSVP是软状态协议，而SIP是硬状态。这表示发送方(图10中的AS)和接收方(图10中的TE)周期性地各自发布“路径”和“resv”消息来为承载路径“刷新”网络资源保留。RSVP能力的路由器如果当他们没有在“清除超时”间隔中看见这些“刷新”消息，那么将释放资源。明显地，SIWF功能应当只将新的RSVP消息转换成SIP消息并且仅使用“刷新”消息来重置计时器。如果在足够长的时间间隔内没有接收到“刷新”消息，那么SIWF将发布SIP BYE消息来拆卸该会话。另外，当SIP会话就绪(in place)时，SIWF必须生成匹配刷新消息，以让发送方和接收方不会想到承载路径已经丢失了它的保留。

不仅允许资源保留流逝一样，而且RSVP提供显式的拆卸。在图10中，发送方被描述为通过发布“路径拆卸(pathtear)”消息S16，终止承载路径作为与接收方的会话的结束。当SIWF从RSVP发送方(或接收方)接收“路径拆卸”(或“resv拆卸”)消息时，其发布SIP再见消息S18。再见消息被确认(用200OK响应S20)，而RSVP“拆卸”消息没有被确认。

本领域中的专业技术人员将认识到，并不要求TE和AS离它们的服务SIWF一个IP跳跃。具体来说，AS和/或TE可以被连接到RSVP支持网络(例如，具有RSVP能力的路由器的企业网络)，并且在NGN的边界的SIWF功能可以被移除几个IP跳跃。

RTSP

与SIP类似，RTSP是基于文本的应用协议。并且与SIP类似的，它使用SDP来描述媒体流。在语义上有相当的重叠。但是，作为早于SIP开发的协议，它的目标是SIP支持的应用的子集。RTSP的主要应用范围是多媒体表示，存储的与实时的两者。实时网络广播和它们来自存储的后续回放是RTSP的一种用途，音频或者视频的互联网流是其他用途。RTSP消息的语义与SIP不直接匹配。消息的一种类型，描述(DESCRIBE)响应消息，运送描述潜在的几个承载流(从其中必须推导出每个流的T-Spec)的表示的SDP，而其他消息类型，建立(SETUP)消息运送一个承载流的F-Spec。单独的建立(SETUP)消息是每个承载流所要求的。为了让事情更糟，RSTP不要求描述消息的使用：应用客户端可以通过任何技术得到承载流的媒体初始化参数。

然后，必须认识到，难以产生有效的SIP-RTSP SIWF来处理所有可能的RTSP的使用。因为，实际上非常少量的RTSP媒体服务器和播放器(即，REAL、Quicktime、windows)支配互联网上的RTSP的使用，被设计成处理它们的RTSP使用模式的SIWF将会是最有益的。以下描述本发明的实施例，其针对在具有交换的描述消息之后在会话中建立承载流的应用。

使用RTSP到SIP SIWF网关

图11描述RSTP客户端或者播放器(安置在TE上)的消息流，其向经过NGN的懂RSTP的应用服务器(AS)请求媒体流，其中NGN在它的边缘具有RTSP到SIP SIWF功能，该功能从TE和AS截获RTSP消息。

想要发起RSTP会话的RTSP客户端将指导应用服务器的URL，所以它可以为描述请求消息生成请求-URI并且将那个消息发送(在S22)到服务器。在图11中，描述请求消息以直接穿过安置SIWF功能的节点示出。只有响应RTSP 200OK(S24)是它们关注的，并且实际上仅服务于客户端的SIWF需要缓存对描述(DESCRIBE)的响应的SDP主体部分。应当注意，描述会话的媒体流的应用服务器不必与服务媒体流的应用服务器是相同的实体，因此不保证服务于应用服务器的SIWF与服务于媒体服务器的是相同的一个。

客户端的SIWF(即，安置在TE配属的AG上的SIWF)需要能够在导向该客户端的消息的流中检测RTSP200消息。具体地，它需要检测和缓存消息主体中运送的媒体流的描述。事实上，SIWF可以被指定为检查用于“内容-类型：应用/sdp”行的200OK消息的所有形式并且应对可能的将来来自该客户端的RTSP建立请求而缓存该主体内容。具体地，这将包含会话的SDP参数使用HTTP响应被传送的情况。

由客户端接收的SDP参数描述构建会话的一个或多个媒体流源。包含在每个源中的是它的URI。因此，客户端使用它从描述响应学习到的请求URI，向每个媒体流源发布建立(SETUP)请求。(图11示出为作为AS的媒体源发布的建立请求)。包含在设置消息中的是客户端想要接收的承载流的端口号。(本领域中的专业技术人员将认识到，对于rtp/avp简要承载流，它实际上是一对被指定的端口号，但是其中的第二个是用于RTSP业务的，其不太可能比“尽力而为”QoS处理得到更多的益处)

当客户端的SIWF识别到建立请求S26时，它首先必须将它与先前描述响应的缓存的SDP中的媒体流描述匹配。做到这一点有两处关键：客户端的IP地址，其在建立消息的包报头源域和描述响应的目标域中；以及建立消息的请求URI，其应当匹配来自描述响应的SDP的媒体流源URI。(通常仅匹配媒体流源URI就足够，但是有些情况下不同的客户端被服务于不同的编码，因此还匹配客户端将更安全)。当找到匹配时，SIWF就可以为SIP邀请消息S28构建SDP的T-Spec部分。F-Spec的接收方端，即，包类型和客户端IP地址和端口也被编码到SDP中。因为在建立消息中有请求URI，所以在邀请消息中有两种选择用于请求/目标URI，即：如果媒体服务器已经以明显不同的URI(即SIWF可以将其识别为可被SIP路由URI)被管理地注册并且已经返回那个URI作为描述响应的一部分，然后从建立消息拷贝的该URI可以被用作用于邀请的请求URI；否则，可以使用建立消息的目标IP地址来构建服务网关URI(如上所述并且与上面的RSVP情况类似)。

邀请消息以前述的方式被NGN转发到服务器并且到达服务器的SIWF(即，关联于服务器配属的AG的SIWF)。假设满足了策略检查(见下)，则SIWF重新生成建立请求S30并且将它转发到媒体服务器。再一次，如同RSVP的情况，本发明的实施例可以实际上传输封装在邀请消息中的建立消息的拷贝，但是邀请消息中的信息(排除这以外)将足以激活与由客户端发送的语义上相等的建立消息的生成。

当服务器对建立消息发布它的响应S32时，它将源端口号码包含在其中，以便当服务器的SIWF截获消息时，它能够完成对邀请消息的响应S34中的SDL的F-Spec部分。SIP 200OK响应消息S34的剩余部分根据邀请消息的内容构建。当200OK响应在邀请的相反路径上行进时，各种CSCF在网关中安装QoS策略来确保由F-Spec描述的承载路径接收由T-Spec指定的QoS处理。

客户端的SIWF将SIP 200OK响应S34转换成对初始建立消息(RSTP200OK响应S36)的响应并发送那个响应到客户端。与SIP不同，RTSP还具有一组方法(命令)来控制媒体流的放出(即，启动快速转发序列)。这些命令仅仅涉及服务器并且不需要被SIWF截获。包含在该命令集中的是播放(PLAY)请求，服务器实际上并不发送任何承载流包，直到它已经接收到了播放请求。但是拆卸(TEARDOWN)请求S38由SIWF截获并且被转换成SIP再见消息S40。RTSP的拆卸和SIP的再见消息两者都需要确认(200OK)S42、S44。

授权和记账

IMS架构的一个主要好处是用户(以SIP客户端的形式)是经过鉴权(在注册(REGISTRATION)步骤期间)的并且NGN生成记账信息，该信息将用户捆定到他们请求的QoS承载流。在NGN中提供SIWF网关，如上所述，减弱了这些控制，这是因为他们允许未注册的端点请求并且使用网络资源。在实际的商业部署中，运营商将需要提前授权承载流的一端，很可能是应用服务器，这是由于与他们协商收费协定的应用服务器的数量要少得多。运营商将管理地提供应用服务器的地址到它的服务SIWF并且显式地激活交互工作功能。可以向SIWF提供向s-CSCF注册的服务器的URL，使得SIP消息可以采用该URL作为目标-URI而不是服务网关IP地址方法被路由到该SIWF。

QoS的选择性应用

但是，即使当应用服务器被安全地识别并且达成了为它建立的QoS承载流收费的商业协定时，该服务器还是不能选择特定的客户端对于发送到它的流，是接收QoS处理还是尽力而为的处理。(这可能依赖于客户端用户是否订阅了应用服务器供应商)。本发明的进一步改进(可应用于遗留协议(例如通过URI定义媒体流的RTSP))将具有根据它们是否将接收QoS处理来使用不同的URI以识别其他相等的媒体流的应用。NGN中的所有SIWF将必须能够区分两种类型的URI。参考图11，当建立消息到达服务于SIWF的客户端时，如果URI指示QoS处理是由应用服务器“请求”的，则它将检查目标URI并且仅仅将建立消息转换到SIP邀请消息。否则，SIWF功能忽略建立消息并且它以标准的遗留方式进行到应用服务器而没有涉及其他网络。本领域中的有经验的人员将认识到，有许多配置可以被用于区分URI：一个例子是使用服务器的服务域的IMS域名作为附在该应用服务器自己的URL之后的URI的域部分。

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

有两种情况要考虑。

在一种情况中，客户端不懂遗留信令协议。服务器使用遗留信令协议是因为它比SIP的实现更简单。这在图13中RSVP的例子中示出。注意，虽然在这种情况中，当使用RSVP时SIWF功能(或者至少RSVP消息的检测)必须被安置在服务器的服务AG中，但是对于允许代理被配置(即，消息被IP寻址到代理)的其他协议，例如RTSP，SIWF功能不需要在服务器和客户端之间的包的直接路径中。具体地，SIWF功能可以被包含在服务器的服务pCSCF中。

在另一情况下，遗留信令协议在客户端和服务器之间被交换，但它仍然被服务器的SIWF检查(没有修改)。这在图14的RTSP的例子中示出。在这种情况下，SIWF功能起着透明代理的作用(即，RTSP包没有被寻找到它)并且因此必须是服务AG的一部分。

因此，这里描述的方法和系统克服了现今IMS的限制，现今的IMS仅处理在懂SIP的端点之间的RTP上传递的多媒体。这里描述和主张权利要求的发明允许在从任何内容源到任何目标的QoS承载流上传递任何内容，同时维持了IMS的安全性和收费框架，为运营商打开了下一代网络从客户端和应用服务供应商获取收入的新来源。

以上描述的发明的实施例目的仅在于阐释。因此本发明的范围唯一地由所附的权利要求的范围限定。

Claims (28)

1.在使用会话发起协议(SIP)建立具有承载流的QoS处理的通信会话的通信网络中，一种在通信会话中提供承载流的QoS处理的方法，使用不同的带内信令协议在两个端设备之间建立该通信会话，该方法包括在两个端设备之间的带内信令的路径中提供信令交互工作功能(SIWF)的步骤，该SIWF操作用于：

检测带内信令的至少一个信号状态；以及

基于检测到的信号状态，建立具有承载流的QoS处理的通信会话，该承载流跨越两个端点之间的端到端路径的至少一部分。

2.如权利要求1所述的方法，其中建立通信会话的步骤包括：

接收由两个端点的第一个生成的带内信令协议消息，用于建立与两个端点的第二个的通信路径；

生成一个或多个在功能上等同于接收到的带内信令协议消息的SIP消息；

接收建立具有QoS处理的通信会话的SIP消息；以及

生成一个或多个在功能上等同于接收到的SIP消息的带内信令协议消息。

3.如权利要求2所述的方法，其中带内信令协议是资源保留协议(RSVP)和实时流协议(RTSP)中的一个。

4.如权利要求2所述的方法，其中第一端点是下列中的任意一个：

通过配属网关(AG)配属到网络的非SIP客户端；和

通过边界网关(BG)配属到网络的遗留自治系统(AS)的节点。

5.如权利要求4所述的方法，其中SIWF与控制相关的网关的呼叫状态控制功能(CSCF)相关联。

6.如权利要求2所述的方法，其中生成一个或多个在功能上等同于接收到的带内信令协议消息的SIP消息的步骤包括包含承载流的期望QoS处理的显式识别的步骤。

7.如权利要求6所述的方法，其中期望QoS处理的显式识别包括识别至少一个所需的带宽的信息。

8.如权利要求7所述的方法，其中期望QoS处理的显式识别进一步包括识别所需的业务类别的信息。

9.如权利要求7所述的方法，其中信息包括表示至少一个预定的带宽的标识符。

10.如权利要求2所述的方法，其中第二端点是连接到网络的懂SIP的端点(SIP speaker)，并且其中建立通信会话的SIP消息由第二端点生成。

11.如权利要求2所述的方法，其中第二端点是通过各自的配属网关(AG)配属到网络的非SIP客户端，并且其中建立通信会话的SIP消息由代表第二端点的普通代理生成。

12.如权利要求11所述的方法，其中普通代理与控制各自的配属网关的呼叫状态控制功能(CSCF)相关联。

13.如权利要求2所述的方法，其中第二端点是通过边界网关(BG)配属到网络的遗留自治系统(AS)的节点，并且其中建立通信会话的SIP消息由对等的信令交互工作功能(SIWF)基于从第二端点接收的带内信令消息生成。

14.如权利要求13所述的方法，其中对等的信令交互工作功能与控制边界网关(BG)的边界呼叫状态控制功能(b-CSCF)相关联。

15.在使用会话发起协议(SIP)建立具有承载流的QoS处理的通信会话的通信网络中，一种计算机可读介质，包括软件代码，用于在通信会话中提供承载流的QoS处理，使用不同的带内信令协议在两个端设备之间建立该通信会话，该软件代码实现在两个端设备之间的带内信令的路径中的信令交互工作功能(SIWF)，该SIWF操作用于：

检测带内信令的至少一个信号状态；以及

基于检测到的信号状态，建立具有承载流的QoS处理的通信会话，该承载流跨越两个端点之间的端到端路径的至少一部分。

16.如权利要求15所述的计算机可读介质，其中用于建立通信会话的软件代码包括步骤：

接收由两个端点的第一个生成的带内信令协议消息，用于建立与两个端点的第二个的通信路径；

生成一个或多个在功能上等同于接收到的带内信令协议消息的SIP消息；

接收建立具有QoS处理的通信会话的SIP消息；以及

生成一个或多个在功能上等同于接收到的SIP消息的带内信令协议消息。

17.如权利要求16所述的计算机可读介质，其中带内信令协议是资源保留协议(RSVP)和实时流协议(RTSP)中的一个。

18.如权利要求16所述的计算机可读介质，其中第一端点是下列中的任意一个：

通过配属网关(AG)配属到网络的非SIP客户端；和

通过边界网关(BG)配属到网络的遗留自治系统(AS)的节点。

19.如权利要求4所述的方法，其中SIWF与控制相关的网关的呼叫状态控制功能(CSCF)相关联。

20.如权利要求16所述的计算机可读介质，其中生成一个或多个在功能上等同于接收到的带内信令协议消息的SIP消息的步骤包括包含承载流的期望QoS处理的显式识别的步骤。

21.如权利要求20所述的计算机可读介质，其中期望QoS处理的显式识别包括识别至少一个所需的带宽的信息。

22.如权利要求21所述的计算机可读介质，其中期望QoS处理的显式识别进一步包括识别需求的业务类别的信息。

23.如权利要求21所述的计算机可读介质，其中信息包括表示至少一个预定的带宽的标识符。

24.如权利要求16所述的计算机可读介质，其中第二端点是连接到网络的懂SIP的端点，并且其中建立通信会话的SIP消息由第二端点生成。

25.如权利要求16所述的计算机可读介质，其中第二端点是通过各自的配属网关(AG)连接到网络的非SIP客户端，并且其中建立通信会话的SIP消息由代表第二端点的普通代理生成。

26.如权利要求25所述的计算机可读介质，其中普通代理与控制各自的配属网关的呼叫状态控制功能(CSCF)相关联。

27.如权利要求16所述的计算机可读介质，其中第二端点是通过边界网关(BG)配属到网络的遗留自治系统(AS)的节点，并且其中建立通信会话的SIP消息由对等的信令交互工作功能(SIWF)基于从第二端点接收的带内信令消息生成。

28.如权利要求27所述的计算机可读介质，其中对等的信令交互工作功能与控制边界网关(BG)的边界呼叫状态控制功能(b-CSCF)相关联。

Images