下一代网络中用于非SIP讲述者的服务网关代理.pdf

本发明提供下一代网络中用于非SIP讲述者的服务网关代理。用于扩展NGN的IMS/SIP体系结构以向一般承载流量提供QoS服务的方法和系统。对于目的地是经连接到附接网关的附接段附接到网络的非SIP客户端的承载流量，支持其QoS处理。接收有关承载流量的SIP邀请消息。SIP邀请消息包含将非SIP客户端标识为承载流量的目的地的通用资源标识符(URI)。根据SIP邀请消息中标识的业务规范(T-Spec)，尝试在附接段上安装QoS策略，并且检测安装尝试的结果。代表非SIP客户端生成适当的SIP讯息以基于检测到的结果接受或拒绝承载流量。

权利要求书一种在通信网络中使用的呼叫状态控制功能CSCF设备，在该通信网络中会话启动协议SIP用于建立带有承载流量的QoS处理的通信会话，所述CSCF设备被配置成通过如下各项提供目的地是经连接到附接网关的附接段附接到所述网络的非SIP客户端的承载流量的QoS处理：接收有关所述承载流量的SIP邀请消息，所述SIP邀请消息包含通用资源标识符URI，所述通用资源标识符将所述非SIP客户端标识为所述承载流量的目的地；尝试根据所述SIP邀请消息中标识的业务规范T‑Spec，在所述附接段上安装QoS策略；检测安装所述QoS策略的所述尝试的结果；以及 代表所述非SIP客户端生成适当的SIP讯息，以基于检测到的结果接受或拒绝所述承载流量。如权利要求1所述的CSCF设备，其中标识所述SIP邀请消息中所述非SIP客户端的所述URI是服务网关URI，该服务网关URI解析成为到达所述非SIP客户端而由所述附接网关通告的因特网协议IP地址。如权利要求1所述的CSCF设备，其中所述CSCF控制所述附接网关，所述CSCF被进一步配置成接收所述SIP邀请消息，尝试安装所述QoS策略和检测安装所述QoS策略的所述尝试的结果。如权利要求3所述的CSCF设备，其中所述CSCF被进一步配置成在安装所述QoS策略的所述尝试不成功时，代表所述非SIP客户端生成适当的SIP讯息。如权利要求3所述的CSCF设备，其中所述CSCF被进一步配置成在安装所述QoS策略的所述尝试成功时，通过将所述SIP邀请消息转发到所述非SIP客户端的一般客户端代理，代表所述非SIP客户端生成适当的SIP讯息，所述一般客户端代理响应所述SIP邀请消息的接收，代表所述非SIP客户端生成所述SIP讯息。如权利要求5所述的CSCF设备，其中所述一般客户端代理是所述CSCF功能性的扩展。如权利要求1所述的CSCF设备，其中所述SIP邀请消息包括所述承载流量的所期望的QoS处理的显式标识。如权利要求7所述的CSCF设备，其中所期望的QoS处理的所述显式标识包括至少标识所需带宽的信息。 如权利要求8所述的CSCF设备，其中所述信息包括至少代表预定带宽的标识符。如权利要求7所述的CSCF设备，其中所期望的QoS处理的所述显式标识还包括标识所需业务类的信息。

说明书下一代网络中用于非SIP讲述者的服务网关代理
 本申请是申请人北方电讯网络有限公司申请日为2009年8月12日的同名中国专利申请No.200780051232.8的分案申请。
技术领域
本发明涉及下一代网络，并且具体地说，涉及在下一代网络中向一般承载流量提供QoS处理。
发明背景
目前，诸如第三代合作伙伴项目(3GPP)、欧洲电信标准协会(ETSI)和国际电信联盟(ITU)等各种国际标准团体和联盟正在参与定义下一代网络的倡议。根据ITU‑T，下一代网络(NGN)是基于分组的网络，该网络能够提供包括电信服务的服务，并能够利用多个宽带、启用QoS的传输技术，并且其中服务相关功能独立于基础传输相关技术。NGN为用户提供对不同服务提供商的无限制接入。它也支持通用移动性，该移动性将允许向用户提供一致和无所不在的服务。
下一代网络一般基于因特网多媒体子系统(IMS)体系结构，并且利用会话启动协议(SIP)管理双方之间通信会话的建立和拆除(tear‑down)。此布置有利之处在于IMS/SIP为因特网协议(IP)网络以防欺诈的方式建立包括话音IP(VoIP)电话呼叫在内的多媒体会话提供了框架，并且该框架允许使用极其类似于公共交换电话网(PSTN)和蜂窝网络运营商当前采用的那些方法来进行随后的计费和域间结算。也就是说，能够为每个单独的呼叫/会话向用户开单并带有与提供的服务类型有关的费用，并且这些费用能适当地分配到呼叫/会话遍历的每个承载网络(或管理域)。
如同PSTN一样，设想是NGN将包括许多运营商/管理域，并且IMS体系结构为一个运营商的订户与另一运营商的订户建立话音呼叫或多媒体会话提供基础，两个运营商(及任何中间运营商)保留其各自管理域中的必需网络资源以支持传送与该会话相关联的话音或多媒体流的承载分组流量所需的服务质量(QoS)。此外，IMS体系结构完全支持终端用户的漫游，受访域以与归属域相同的方式支持承载流量QoS。
图1以示意图方式示出代表性下一代网络体系结构。如在PSTN和因特网中一样，NGN预期为多个管理域的网络的集聚(conglomeration)。管理域的业务可主要是服务终端客户的业务或主要是向其它管理域提供转接的业务。对本申请来说，提供转接的管理域的网络称为转接网络(TN)2。服务终端客户的管理域由两种类型的网络组成：核心IP网络(CN)4和经附接网关10将终端客户的终端设备(TE)8“附接”到核心网络4使得终端客户能接收IMS服务的一个或多个附接(或“接入”)网络(AN)6。即使在AN由单独业务实体(AN运营商)操作时(CN运营商从该单独业务实体购买“全部接入”)，AN一般也被认为是与它们连接到的CN在同一管理域中。注意，虽然转接网络和核心网络基于每个分组的报头中的目的地IP地址路由IP分组，但AN在TE与CN的附接点之间传输分组，而不考虑IP地址。虽然附接网络能与导线或时域复用(TDM)电路一样简单，但它通常由媒体特定的第一英里网络和更通常的分组回程网络组成(在3GPP无线术语中，此回程网络由术语“核心”表示，但它仍是AN的一部分，而不要与CN混淆)。
在图1所示的网络体系结构中，分组在各种核心与转接网络之间通过每个网络中的传输边界网关(TBG)14托管的交换链路12传输。对于任意对网络，交换链路可以是物理链路或某一形式的虚拟电路。本领域的技术人员将认识到多个网络也能通过无连接交换网络(XN)互连。XN的范围可以从单个以太网交换机到全球IP网络或虚拟专用网络不等。
IMS被指定为使用会话启动协议(SIP)建立和拆卸(take down)多媒体呼叫或会话。IMS体系结构指定遍布于网络的多个呼叫状态控制功能(CSCF)16，该呼叫状态控制功能16处理SIP消息并对它起作用。在特定会话的建立中，SIP讯息(SIP messaging)需要由与会话发起者相关联的至少一个始发服务CSCS(S‑CSCF)和与会话建立的目标或目的地相关联的目的地S‑CSCF处理。然而，通常SIP客户端不直接与其相关联S‑CSCF对等(peer)，并且存在在SIP客户端与其相关联S‑CSCF之间及始发与目的地CSCF之间路由和转发SIP消息的中间CSCF。与本申请特别相关的是负责在管理域之间转发SIP消息的对等CSCF。在本描述中，我们指定在管理域中最后一个将SIP消息转发到另一域或在管理域中第一个从另一域接收SIP消息的任何CSCF为边界CSCF(b‑CSCF)。熟悉3GPP和/或其它NGN标准要点的人将认识到关于将如何构建边界控制功能性有一些争论。术语“b‑CSCF”旨在涵盖诸如查询CSCF(I‑CSCF)、互连边界控制功能(IBCF)和出口网关控制功能(BGCF)的方面等功能组件。在边界控制不是很强的运营商要求时，甚至S‑CSCF可以为b‑CSCF。
在附接网络中无CSCF ‑ 所谓的代理CSCF(P‑CSCF)的对等实际上是终端设备的SIP客户端功能。由于SIP客户端(特别是在应用服务器(AS)8b中)可能直接与S‑CSCF对等，因此，在本描述中，我们使用术语周边CSCF(p‑CSCF)来表示处理来自/至SIP客户端的SIP消息的第一个/最后一个CSCF。图1示出在漫游TE 8(附接到受访核心网络)与应用服务器AS 8b之间的会话建立中的相关CSCF，其中，归属核心网络通过转接网络2分隔。
会话的媒体流作为承载(分组)流量跨网络传输。在IP分组环境中，承载流量路径不是自动与SIP信令遍历的路径相同，这是因为承载流量路径不需要经过托管CSCF功能的节点。域间承载流量在本文中表示为传输边界网关(TBG)14的节点处退出和进入管理域。同样地，在附接网络与核心网络之间的情况是不同的：核心网络中接口到附接网络的节点有各种称谓，如服务边缘、核心网络边缘、边界节点、接入媒体网关、接入路由器或诸如GPRS网关支持节点(GGSN)或宽带远程接入服务器(BRAS)等接入网络类型特定的术语。在本描述中，我们将使用术语附接网关(AG)10。AG横跨(straddle)AN 6与CN 4之间的边界。
指定承载流量QoS要求
 正如本领域所熟知的一样，启动会话的SIP消息传送要与会话相关联的承载流量(或需要时的多个承载流量)的描述。此描述为会话描述协议(SDP)的参数形式。例如，参阅“SDP：会话描述协议”(Handley，M.和V. Jacobson，“SDP: session description protocol”，Request for Comments 2327，April 1998)。目前，SIP消息的SDP部分给出承载流量要包含的内容(即，话音或视频及要使用的编解码器和比特率)的完整描述。此信息最初旨在允许终端系统(end system)指定它们希望如何将话音或视频数据编码成实时协议(RTP)分组。
在IMS解决方案中，SDP参数也可由介于终端系统之间的各种网络域中的CSCF解释，以便确定网络表征的承载路径。通常，此信息从SDP的媒体行(以m=开始)得出。例如，
m= audio 8004 RTP/AVP 9
中的最后参数指示根据正好为G.722的音频可视化规范概要(AVP)9编码的音频承载流量，它是64kb/s流(网络要求必须包括分组报头等并将它向上推进到大约100kb/s)。
基于SDP参数，CSCF执行被称为连接许可控制(CAC)的过程，但该过程将更准确地称为会话许可控制。CAC过程确定承载流量的资源要求，使得嵌入的媒体流能以预期的QoS提供(deliver)。如果域没有支持新承载流量的资源，则相关CSCF将中止会话建立。3GPP文档《3GPP TS 23.207》中提供了有关此的描述(用于p‑CSCF和AG)。
业务类
业务类是有些难以归类(amorphous)的概念，在不同的业务管理模型中表示为不同术语。在IETF IntServ模型中，有三个业务类：“保证”(“guaranteed”)、“受控负载”(“controlled load”)和“尽力服务”(“best effort”)。有点类似的是，IETF DiffServ模型提供三种类型的业务转发行为：加速转发(EF)、确保转发(AF)(但能有最多4类的AF业务)和默认或尽力服务。ITU研究组在延迟和抖动(及吞吐量)外加诸如分组丢失率和如何处理超出规范或迟到的分组等因素方面为服务定义了业务类。
在NGN的可行部署中，将存在用于实时交谈的业务类，在该业务类中，延迟和抖动均将为可能的最小值(或者运营商可选择若干此种类，一个用于话音交谈，一个用于视频电话，一个用于游戏)，并且将存在保证吞吐量而带有受约束抖动的另一个类，该类适于媒体流播出(同样地，运营商可选择区分话音与视频)。由于决不存在专用于尽力服务业务的资源，因此，使用SIP建立尽力服务型承载流量实用性很少，但为保证完整性，可定义此类码点。
QoS控制和处理的范围
图2示出分成段20的承载流量18。承载流量的每段20遍历单个分组传输网络2‑6，并且通过终端装置或网关14定界。承载流量段20能根据传输它们的网络的类型命名：对于穿过附接网络的承载流量部分命名为附接段等。
对承载流量分组提供特殊处理的需要可能不是端对端扩展。广泛接受的是如果特定分组传输网络过量提供，则给予所有分组的QoS处理将足以支持任何特定承载流量。本领域的技术人员也将认识到Diffserv可用于为特定类的业务模拟过量提供。设想一些或所有核心网络将过量提供(或使用Diffserv来为IMS分组模拟过量提供)，结果是将无需为遍历此类过量提供的核心网络的承载流量的核心段保留资源。然而，极可能是将必须为附接段保留资源以便确保那些段上的流量的分组的传输不会将端对端流量的QoS降到低于流量在支持的服务可接受的质量。
资源和许可控制功能(RACF)
为承载流量保留资源的功能与承载流量是其组成的会话的许可控制密切相关。在现有会话的当前承诺条件下，如果链路上的带宽容量不足，节点处的转发容量不足，或缺少为新会话的承载流量提供请求的QoS所需的其它资源，则会话建立中止，并且已经为该会话保留的任何资源被释放。
更一般地说，在会话建立前，需要做出有关是否许可会话的多个策略决定。在IMS体系结构中，这些决定在CSCF处发起，由会话建立中的第一消息(SIP邀请消息)的处理触发。一些策略决定的执行被限于CSCF，但有关承载流量QoS的那些决定由控制CSCF通过信号发送到将处理承载流量的网关。图3为涉及两个域的会话示出在附接网关(AG)10和传输边界网关(TBG)14中分别由p‑CSCF和b‑CSCF进行的RACF功能控制。熟悉NGN标准的人将认识到在IMS体系结构中，在CSCF与网关之间，存在形成RACS(资源和许可控制子系统)网络层的中间策略决定功能(PDF)。PDF可向CSCF呈现附接网络QoS控制细节的抽象视图并隐藏AG和TBG的拓扑及在请求QoS承载流量的不同应用之间仲裁。
无论其优点如何，NGN具有限制，因为IMS被设计为向通过实时分组(RTP)分组流量传输的多媒体业务(包括视频和/或VoIP)提供QoS处理。然而，存在将从QoS处理的应用中受益的许多其它类型的业务。另外，在无IMS支持的计费和结算功能性的情况下，网络服务提供商对投资支持多媒体和VoIP外的业务类型所需的NGN技术积极性不高。IMS的又一限制在于通信会话的双方必须是SIP客户端。由于单独的终端用户必须迁移(migrate)到“启用SIP”的应用，因此，这对NGN的部署提供了障碍。
相应地，仍非常希望有在下一代网络中允许一般承载流量的QoS处理的方法和技术。
发明内容
本发明的目的是在下一代网络中提供允许一般承载流量的QoS处理的方法和技术。
因此，本发明的方面在会话启动协议(SIP)用于建立带有承载流量的QoS处理的通信会话的通信网络中，提供一种为目的地是经连接到附接网关的附接段附接到网络的非SIP客户端的承载流量提供QoS处理的方法。接收有关承载流量的SIP邀请消息。SIP邀请消息包含将非SIP客户端标识为承载流量的目的地的通用资源标识符(URI)。根据SIP邀请消息中标识的业务规范(T‑Spec)，尝试在附接段上安装QoS策略，并且检测安装尝试的结果。代表非SIP客户端生成适当的SIP讯息以基于检测到的结果接受或拒绝承载流量。
本发明未专用于任何特定业务管理模型，而是只假设将存在运营商对其达成一致的多个业务类，并且承载流量的所期望的业务类能被指定为SDP中的参数。
本发明假设对于每个AG，存在能为经过该网关的承载流量请求QoS处理的p‑CSCF(及类似地，对于每个TBG，存在b‑CSCF)，而不考虑用于其内部通信的中间PDF、节点和特定的协议选择的数量(若有的话)。特定承载流量的承载段的QoS处理可通过将策略推进(push)到该段一端处的网关而以单端方式设置，或者可通过将策略推进到在该段两端处的网关而以双端方式设置。如上文所定义，网关是承载流量的一个承载段的端点和其下一段的起点：推进到网关的单个策略可用于为两个段请求QoS资源。
本领域的技术人员将认识到存在用于请求网关为承载段提供QoS的若干不同方法：所谓的“推进”方法导致网关从CSCF(或通过策略决定功能的分层)直接接收“策略决定”以便向承载段提供指定的QoS，并且导致网关随后向CSCF回复它具有“实行”策略的资源，或它不具有该资源。下面的描述根据RACS的“推进”模型阐述，但本发明旨在独立于QoS要求如何传递到网关而起作用。实际上，正如本领域的技术人员将认识到的一样，“带宽代理”可能跟踪链路或网络上的带宽资源而不曾向在端点的网关发送信号。然而，假定段在域内部边界开始或结束，则网关将对通过信号发送到它们的新承载段有具体要求存在额外的原因：控制(police)承载流量，更改Diffserv标志，生成计费记录。虽然实际的资源保留不可能需要在交换链路或网络上进行，但RAC功能将可能被b‑CSCF调用以便检查每个管理域对有关它准备从其它域接受的流量的类型和数量的策略遵从性。
附图说明
结合附图，从下面的详细描述中将明白本发明的其它特性和优点，其中：
图1是以示意图方式示出其中可实现本发明的方法的代表性下一代网络的框图；
图2是以示意图方式示出在图1的网络中承载流量段的框图；
图3是为涉及两个域的会话以示意图方式示出资源和许可控制功能的控制的框图；
图4是根据本发明的一方面，以示意图方式示出使用网络地址映射钉扎承载段的框图；
图5是根据本发明的一方面，以示意图方式示出使用网络地址映射在包括多个承载段的网络中钉扎承载段的框图；
图6是根据本发明的一方面，以示意图方式示出使用网络地址映射在包括多个IP地址域的网络中钉扎承载段的框图；
图7是根据本发明的一方面，以示意图方式示出支持非SIP客户端的方法的框图；
图8是根据本发明的一方面，以示意图方式示出在包括多个IP地址域的网络中支持非SIP客户端的方法的框图；
图9是根据本发明的一方面，以示意图方式示出与遗留协议互配的方法的框图；
图10是根据本发明的一方面，以示意图方式示出RSVP到SIP互配的方法的消息流程图；
图11是根据本发明的一方面，以示意图方式示出RTSP到SIP互配的方法的消息流程图；
图12是根据本发明的一方面，以示意图方式示出用于支持与遗留协议互配的服务器操作的框图；
图13是根据本发明的一方面，以示意图方式示出用于支持RSVP到SIP互配的服务器操作的消息流程图；以及
图14是根据本发明的一方面，以示意图方式示出用于支持RTSP到SIP互配的服务器操作的消息流程图。
注意，在所有附图中，类似的特性通过类似的标号标识。
具体实施方式
本发明提供在下一代网络中启用目的地为非SIP客户端的承载流量的QoS处理的方法和技术。本发明的实施例在下面仅通过示例，参照图4‑14进行描述。
一般而言，本发明提供能单独或组合用于扩展NGN的IMS/SIP体系结构以便向一般承载流量提供QoS服务的方法和系统。这些方法和系统能在广义上分成四个类别，即：SIP到一般承载流量的扩展；通信会话的承载流量到用于建立会话的SIP信令遍历的AG和TBG的钉扎；对非SIP客户端的支持；以及用于遗留IP信令的网关功能性。在下面的描述中，将通过代表性示例解释这些类别的每个类别。
应注意，本申请主要针对用于实现服务器网关代理以在NGN中支持非SIP客户端的技术。将承载流量钉扎到用于建立会话的SIP信令遍历的AG和TBG的技术和用于遗留IP信令的网关功能性分别是申请人的题为“在下一代网络中钉扎IP承载流量的路由”(Pinning the Route of IP Bearer Flows in a Next Generation Network)的共同待定美国专利申请xx/xxx,xxx和题为“在下一代网络中提供SIP互配”(Providing SIP Interworking in a Next Generation Network)的共同待定美国专利申请yy/yyy,yyy的重点，两个申请与本申请同时提交。
一般承载流量
如目前定义的一样，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的服务指定类。此类情况下，按照RFC 2327的准则，显式T‑Spec能由两个媒体层属性行组成，一行指定Y.1541服务类，而另一行指定所需的容量或带宽。因此：
a = ITU‑CLassOfService:0
a = ITU‑Capacity: 100
能用于指定承载流量需要100 kb/s和服务类0(即，根据Y.1541，小于100 msec的端对端延迟等)。
需要时，其它方法可用于表示显式T‑Spec参数。例如，在下面所述的代表实现中，运营商可选择将名称指配到带宽和业务类的组合，这允许使用单个SDP属性(即，指配的名称)来提供显式T‑Spec。
示例使用：
一名出差的企业员工使用VPN客户端建立从其膝上型计算机返回到其企业的VPN服务器的IPSec隧道(tunnel)，使得她能接入企业网络的设施(包括其IP PBX)以拨打和接收电话呼叫。如果此IPSec隧道通过尽力服务型因特网建立，则加密分组的延迟、抖动和丢失率将是不定的，并且可能不足以支持其膝上型计算机上的软客户端与企业IP PBX之间的VoIP会话。为了获得适合IPSec隧道中话音分组的保证的QoS，要求将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信令将遍历的相同域链，并且假设关于分组使用哪些TBG 14不存在模糊性(钉扎承载流量以使用特定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消息中声称(assert)的身份必须可由VPN服务器转换成VPN客户端的SIP身份(URI)。这能够通过让VPN客户端的身份成为其SIP URI而得以保证，但要获得甚至更高的安全，客户端的SIP地址能作为授权过程的结果而返回(例如，RADIUS或DIAMETER响应的一部分)。
一旦VPN服务器已对客户端鉴权(实际上，在IKE的两个阶段完成后)，它便通过在公共域中发出SIP邀请消息而向VPN客户端拨打“呼叫”。SDP中的F‑Spec标识已被达成一致的隧道端点。(注意，标准IPSec分组在其报头中没有端口号，而是具有对给定地址对之间的每个隧道唯一的安全参数索引字段。此字段能在F‑Spec中使用，但实际上，由于网络中存在NAT，因此，对于VPN接入操作样式，隧穿的正常模式是在UDP数据报中封装IPSec分组，因此，F‑Spec的正常样式用于标识分组的IPSec隧道流量。)在一种操作模式中，用于VPN客户端的T‑Spec作为授权过程的一部分返回到VPN服务器，即，每个VPN客户端始终具有管理员设置的固定QoS级别。在此情况下，T‑Spec作为SDP的一部分包括在来自VPN服务器的邀请消息中。
在IMS的正常方式中，SIP邀请信令消息通过公共IMS CSCF转发到VPN客户端的SIP客户端部分。
客户端先需要将输入信令与安全关联相关联(我们假设安全参数索引即使不是F‑Spec的一部分也包括在SDP中，参阅上述内容)。在VPN客户端用户开始选择所需服务类的一种操作模式中(例如，用户能指定他们是否要拨打/接收话音呼叫或视频呼叫)，VPN客户端将为隧道创建T‑Spec，并且将它包括在返回到VPN服务器的SIP响应中。(假设响应将是200 OK消息。) IMS系统建立会话，将其F‑Spec通知IPSec隧道遍历的AG和TBG，并指示它们根据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处理。其它增强能够是IP‑Sec隧道一被启动，就使服务器建立带有最低QoS处理的一般承载流量，但随后服务器能响应在隧道内探听消息(如在软电话客户端与IP PBX之间的SIP消息)和/或在企业域内的服务器请求时，使用SIP重新邀请来修改流量的服务类/带宽。
钉扎承载流量
如图1所示，会话的端点可附接到不同(核心)网络，会话的SIP信令和承载流量遍历若干个域。目前，IMS中未对承载流量中分组行进的路径给予太多关注 ‑ 通常假设它们将沿IP路由确定的路径行进。另一方面，SIP信令的路由至少部分被定义为经过一系列的CSCF，其中，CSCF是相互的成对对等体。在NGN中，在每个CSCF处的SIP消息的转发选择由策略支配(dictate)(基于转接的商业协定等)。因此，事实是在发起者和终接者在不同域中的情况下，SIP信令遍历的中间域无需完全为在IP转发规则的正常操作下从发起者发送并寻址到终接方的IP分组将遍历的相同域。
然而，有两个充分理由解释为什么承载流量的路径不应只由IP路由确定，而是明确设为遍历特定域和特定传输边界网关(TBG)。首先，从商业角度而言，可能强烈要求会话的承载流量不遍历未分享(participate in)会话的信令的域，理由是如果域不知道流量所属的会话，则它无法为其生成计费记录。其次，对承载流量的QoS提供通常要求将承载流量的授权通知路径上的网络元件以接收QoS。因此，对于核心网络上和/或交换链路上的QoS，承载流量的路径必须被约束为经过(钉扎到)会话建立时b‑CSCF选择的TBG，这是因为b‑CSCF只能将授权发送到它们控制的TBG。
除上述两个钉扎承载流量的原因外，涉及建立会话的CSCF可确定承载流量需要经过某一类型的媒体网关。承载流量路径中可能需要媒体网关以执行媒体样本的代码转换，这是因为会话端点没有相互共同的编解码器。媒体网关的另一使用可能是因为端点之一要服从合法侦听(LI)令，并且会话的媒体流需要经过LI网关，使得能使它们的副本安全地转发到相关法律部门。
本发明的第二方面为会话的承载流量提供路径钉扎机制，以促使承载分组遍历通过在会话建立时确定的特定的网关链。下面的描述和图4‑6集中在将承载流量钉扎到传输边界网关(TBG)，但基于本文中提供的描述，本领域的技术人员将容易理解包括钉扎到其它网关(媒体转换、合法侦听等)的其扩展。如上所述，并且如图2所示，承载流量可分割成承载(流量)段20的串行级联。除第一个流量段开始和最后段的结束点外，这些承载段在网关14开始和结束。在承载流量要钉扎到TBG 14时，中间承载段20的开始和结束点是TBG 14。
注意，由于附接网络6不遵从IP转发，因此，对于特定终端8或服务器8b而言，在其附接到网络的持续时间内，其业务被钉扎到特定AG 10，即，第一和最后的承载段始终在适当的位置上。公开的机制用于在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的机制。
基本机制
本节公开为全部是同一IP地址域一部分的域的联合(例如，公共地址域IPv4或IPv6)实现承载流量的钉扎的方法。如上所述，用于承载流量的SDP参数隐含地包括通过源和目的地IP地址、分组类型及源和目的地端口号来标识流量的承载流量的F‑Spec。严格地说，F‑Spec标识单向流量，但明显的是用于反向流量的F‑Spec能从原F‑Spec普通地生成，因此，在期望建立双向流量时，我们将仍讨论单个F‑Spec。在此第一实现中，所有F‑Spec IP地址属于同一IP地址域。
方法的本质在于，通过改变发射到下一CSCF上的F‑Spec，SIP信令的路径上的CSCF将承载流量分割成承载段，使得修改的F‑Spec只描述在由涉及的CSCF控制的网关之间的承载段。随后，CSCF在那些网关中安装双向“交叉连接”映射，使得在输入承载段中的分组由网关转发到下一承载段上。在此处所述的特定实例化中，“交叉连接”映射是NAT映射，并且分组到下一承载段上的转发通过执行输入分组报头中地址和端口的NAT转换以便使它们成为承载路径的下一段的分组，然后根据正常IP路由过程转发分组而实现。
参照图4，先更详细描述用于涉及两个域的会话启动的机制，为方便用符号表示，两个域示为左侧域和右侧域：在图4中，会话启动由SIP客户端TE 8在左侧域中发起，并且要在右侧域在SIP客户端AS 8b处终止，因此，SIP邀请消息从左向右遍历，并且诸如200 OK等响应从右向左传播。要描述的过程在域之间的每个边界处应用，使得当有不止两个域涉及时，则左侧域是最靠近发起者的一个域(转发邀请消息到右侧域)，并且右侧域是最靠近终接者的一个域(转发200 OK消息到左侧域)。
在图4中，在会话启动要建立的承载流量中，承载流量的TE端被指定为在IP地址A和端口a始发/终止，为此我们使用术语Aa。在SIP会话启动开始时，用于承载流量的AS端的地址和端口号对TE 8是未知的，因此，由TE 8发出的SIP邀请消息24的SDP中的F‑Spec不完整，并且可表示为[Aa, ??]。
在TE 8发出的SIP邀请消息到达在左侧域边界处的b‑CSCF 16时，该b‑CSCF选择TBG 14来钉扎通过承载路径，并为该TBG请求或生成映射(在26)以应用到Aa。假设结果是映射Aa => Bb，则b‑CSCF修改F‑Spec，将TE的始发IP地址和端口Aa替换为RBG的IP和端口Bb，并将邀请转发(在28)到右侧域中的其对等体。在邀请消息到达对等b‑CSCF时，该b‑CSCF可选择在右侧域的边缘处的哪个TBG 14将形成其交换承载段的末端(注意，在图4中，不同于其它图形，在域之间的分组传输示为交换网络XN，而不只是交换链路 ‑ 如果在成对对等TBG之间只存在单个交换链路，则左侧域b‑CSCF的TBG选择将支配右侧域中的TBG)。
右侧域中的b‑CSCF为所选的TBG 14请求或生成映射(在30)以应用到Bb。同样地，假设结果是Bb => Cc，则F‑Spec修改为[Cc,??]。图4中会话启动只涉及两个域的情况下，SIP邀请消息将随后前进(在32)通过右侧域中的CSCF，直至它到达目的地SIP客户端22(在图4中示为应用服务器AS)。在更普遍的情况下，SIP邀请向与下一域对等的b‑CSCF转发。
从AS 8b的角度而言，它接收的SIP邀请正请求带有端点Cc的承载流量。假设AS通过200 OK消息回复，则它将指定其承载流的末端(例如，为Zz)，因此，200 OK消息34的SDL中的F‑Spec将为[Cc, Zz]。(本领域的技术人员将认识到传送目的地F‑spec部分的响应消息可以为180振铃消息。) 200 OK消息遍历邀请的反向路径，并回到右侧域b‑CSCF。该b‑CSCF将在36请求或生成另一映射(例如，Yy <= Zz)，并随后在TBG 14中激活Bb<=>Cc，Yy<=>Zz的完全IP报头双向网络地址转换。最后，b‑CSCF修改200 OK消息中的F‑Spec以将承载流量源地址和端口显示为Yy，并且将目的地显示为Bb，并将它转发(在38)到左侧域中的其对等体。在左侧域的对等b‑CSCF，200 OK消息的接收促使请求或生成映射Xx<=Yy、左侧域TBG中双向映射Aa<=>Bb、Xx<=>Yy(在40)的激活，及最终带有[Aa, Xx]的F‑Spec的200 OK消息向始发SIP客户端的传播(在42)。从TE SIP客户端22的角度而言，会话的承载流量的另一端点是在左侧域TBG 14的Xx。
上述公开过程所做的实际上是将承载流量分段成三个承载流量段，并在TBG中安装映射以“重新标记”分组，使得它们被转发到下一段上。在它将承载分组发送到AS 8b时，TE 8在它们上放置Xx的目的地地址，它是在200 OK F‑Spec中接收该目的地地址。Xx是TE的核心域中TBG 14服务的地址和端口号：第一承载流量段是在TE(地址A)与TBG(左侧核心网络上地址X的通告者)之间附接段和最左侧核心段的级联。第二段是在左侧TBG(交换网络上的地址B)与右侧TBG(交换网络上的地址Y)之间的交换段。第三段同样是附接段和核心段的级联，在右侧TBG(右侧核心网络上地址C的通告者)与AS(地址Z)之间。分组根据正常IP路由规则，沿每个单独的承载段转发到承载段的端点，这是因为分组报头中的目的地地址是段端点的IP地址。在TBG处，分组报头被改写以将分组放置在下一承载段的开始处。熟知标签交换路径的人员可认识到这是标签交换的一种形式，其中，标签字段是整个IP报头源和目的地地址和端口字段。在始发与终接域之间存在多个域时，能利用查看存在机制的此方案以解释其应用的结果。图5用定义每个承载段的NAT映射补充了图2。
也可能观察到，在通过单个IP地址域操作时，只需要重新映射目的地地址，因为分组中的源地址不影响其路由。然而，由于在各种安全检查中使用源地址，如防火墙中和用于安装QoS策略，因此，需要一致的方案。在涉及多个地址域(参阅下述内容)时，源地址必须重新映射，因此，我们采用它始终应重新映射的方案。
还应注意的是，在单个IP地址域中，只有在无法依赖IP转发将分组转发到下一承载段的节点处需要NAT“标签交换”。承载流量只在网关处需要分段，该网关可能不是始终在IP转发流量路径上。通常，域间交换链路的包含拓扑可能够保证网关将始终在IP转发流量路径上，并因此无需是承载段端点。例如，如果有互连两个域的单对TBG，并且保证它们之间的最短路径不遍历第三个域，则从TE到AS的单个承载段将足以确保分组始终经过该对TBG。
多个IP地址域
上述NGN组织不要求每个管理域是同一IP地址域的一部分。相反，由于被叫方在SIP消息中根据URI而不是IP地址标识，因此，CSCF的链能跨IP地址域边界向被叫方转发SIP消息。这确实要求在b‑CSCF从不在同一地址域的其对等体接收SIP信令时，它们能使SIP信令适应其自己的IP地址域，例如，在图6中，在IPv6域的b‑CSCF将从在公共IPv4域的其对等体接收IPv4格式的SIP消息，并且在将它们转发到其自己域中的其它CSCF上前，将必须将该消息重新格式化为IPv6形式。如上所述，SIP消息在SDP部分中包含用于要建立的承载流量的暗含的流量规范(F‑Specs)。在承载流量要遍历多个地址域时，SIP消息中的F‑specs需要在地址区域边界更改以反映将在承载流量上实现的网络地址和端口转换。重新格式化SIP消息和改变F‑Specs经常被称为SIP ALG(应用层网关)功能。
图6示出使用三个IP地址域的两个管理域：服务终端(TE)的管理域为终端指配专用IPv4地址(可能是因为它未指配给它足够的公共IPv4地址，无法为每个终端赋予其自己的公共IP地址)，但在核心网络中使用公共地址，而另一管理域全部使用公共IPv6地址。互连两个NGN域的交换网络在图6中示为IPv4网络，是公共IPv4地址域的一部分。这是任意的选择，并且交换网络能同样已是IPv6地址域的一部分。
比较图4和图6，将观察到在左侧AG处存在地址区域边界。在分组穿过(cross)附接网络与核心网络之间时，此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路由和默认路由的人员将观察到，所示的Ww<=Xx映射不是绝对需要的，这是因为专用和公共IPv4地址不重叠，并且无论如何，附接网络将把分组转发到AG。然而，不在承载分组上进行完全IP报头重新映射将在承载流量前向和后向分割成承载段中产生不对称，并且这可能导致微妙的维护问题。
图6中的另一地址域边界是在右侧域TBG处。此TBG具有在IPv4地址域操作的一个或多个接口，并且具体而言，地址Y是接口(之一)的IPv4地址。它也具有在IPv6地址域操作的一个或多个接口，地址D是TBG IPv6接口地址。如上所述，从左侧域b‑CSCF到达右侧域b‑CSCF的SIP消息将是以IPv4格式，带有IPv4报头和所有v4嵌入式IP地址。在将消息转发到下一CSCF上之前，b‑CSCF必须转换这些消息以具有IPv6报头和嵌入式IP地址。对于SIP邀请消息的SDP中的F‑Spec，转换必须匹配将在TBG中安装的NAT映射，也就是说公开的路由钉扎过程无更改。
在客户侧的隐藏NAT
意识到公共VoIP服务的实际部署问题的人员将认识到经常存在在TE与附接网络(AN)之间执行的NAT功能。此功能发生在带有专用IP地址域的住所或企业边界处。现在，此NAT功能不是SIP感知型(即，不包括SIP应用层网关(ALG))。然而，此现象不会在实质上影响上述机制；现在允许VoIP工作的相同解决方案能继续使用。因此，客户端通过先查询STUN(NAT的UDP简单穿越)服务器来确定应用什么NAT映射来“固定”SIP信令(参阅RFC 3489)；或者p‑CSCF检测到NAT转换已在来自客户端的SIP信令上执行(因为邀请或回复消息的SDP中嵌入的客户端IP地址与消息报头中的IP源地址不匹配)，并在处理承载流量时指示AG对此进行补偿。
将来，执行NAT功能的客户边缘设备的家用网关可得到增强以包括p‑CSCF功能或由p‑CSCF控制，使得住所内的承载流量段完全在SIP会话建立过程的控制下。
对承载流量进行NAT的其它益处
上面公开的路由钉扎机制的优点在于它使用在TBG(和AG)中经常存在的一种能力(NAT)，并且它不要求核心网络中其它路由器的任何支持。该机制导致NAT功能被应用到穿过管理域的所有承载路径。即使附接网络与核心网络处在同一IP地址域中，它也允许NAT功能在AG应用。下面简要地描述始终对承载流量进行NAT的两个其它益处，这些益处使它成为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讲述者(SIP speaker)的客户端的承载流量。与在应用能利用新NGN提供的QoS传输前应用客户端(远多于服务器)必须升级以具有SIP功能性时将发生的情况相比，此类能力将更迅速地扩展NGN IMS网络支持的有用服务和应用的范围。
根据本发明的第三方面，非应用感知型客户端代理与控制附接网关10的CSCF相关联，通过该附接网关10，非SIP客户端附接到网络。客户端代理代表客户端响应来自应用服务器的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将客户端的服务域示为通过转接链路与服务器归属域分开了零个或更多个将它们互连的转接域，但本发明也适用于应用服务器和客户端在同一域中的网络。为简单起见，下面的描述先假设域(服务器的归属域、客户端的服务域和任何转接域)全部是同一IP地址域的一部分，处理在不同IP地址域中的域的另外机制在本节末尾公开。
由于应用服务器8b要将分组(在承载流量中)发送到客户端8，它必须能够生成承载流量的F‑Spec(否则，它将不能生成分组的IP报头)。通常，在需要建立承载流量前，在客户端与服务器之间将已经存在一些交互：示例有在IPSec隧道建立前的因特网密钥交换(IKE)交互或在视频剪辑向客户端进行流传送前选择视频剪辑的导航。从初始交换中的IP报头中，服务器将获得承载流量的客户端末端的IP地址和端口号。服务器了解的客户端的IP地址是AG 10通告的地址，而客户端8通过该AG10附接到核心网络4。实际上，F‑Spec描述从应用服务器10到AG 8b的承载段。AG 10使用输入分组中的客户端IP地址将它们指引(steer)到附接承载段，该附接承载段使到客户端8的流量路径变得完整。
本发明考虑了一种新的SIP URI(通用资源标识符)形式，我们将它指定为服务网关URI，用作应用服务器8b生成的SIP邀请消息的邀请目的地参数(并插入“TO”子句中)。此URI中的标识符是IP地址的表示：此URI的预期语义是此URI命名的目的地(被叫方)是能将策略推进到在URI中通告IP地址的AG 10的p‑CSCF 16。
有多个机制可用于路由将此新服务网关URI作为其目的地的SIP邀请消息。例如，如果b‑CSCF与它们所处的AS(自主子系统)相关联，并且AS编号在其对等b‑CSCF的转发表中提供，则在b‑CSCF接收邀请消息时，它只需确定到目标IP地址的BGP‑4路由的“下一跳”AS以标识要将邀请转发到的新管理域和对等b‑CSCF。一旦邀请到达了目的地管理域，则它能被转发到特殊指定的S‑CSCF，域中的所有p‑CSCF向该S‑CSCF注册了它们控制的网关的地址范围。此指定的S‑CSCF随后将服务网关URI与地址范围进行匹配以确定要将邀请消息转发到的p‑CSCF。根据需要，也可使用其它转发方法。
根据上述假设，在应用服务器与客户端之间的承载流量的建立如下所述进行：
在第一步骤，应用服务器8b向位于其归属域中的其S‑ CSCF(经其p‑CSCF)发送带有TO子句的SIP邀请，该子句包含指定客户端的IP地址的服务网关URI，并在SDP部分中包括到客户端的承载流量的F‑spec和服务器希望应用的T‑spec。(由于是服务器将为会话而被开单，因此，指定T‑Spec是服务器的特权。)
一旦S‑CSCF对邀请执行了正常起源处理，它便向客户端的服务域转发邀请。如果客户端的服务域不同于服务器的归属域，则邀请将例如使用上面概述的转发决定过程经b‑CSCF转发，可能经过若干域边界，直至它在客户端的服务域边界到达b‑CSCF。
一旦邀请到达在客户端服务域中的b‑CSCF，它便要被转发到控制客户端8实际附接的AG 10(调用AG10的策略决定功能)的p‑CSCF。同样地，上述概述的示例机制可能使用，但本领域的技术人员将认识到存在多个可能的机制。
在收到邀请消息时，p‑CSCF请求AG 10(的RACF)在符合为邀请消息的SDP中F‑Spec标识的承载流量指定的T‑Spec的附接网络中安装QoS策略。正是在此时在包含服务网关URI的TO子句和尝试安装QoS策略的结果的触发下，p‑CSCF的修改行为开始出现(kick in)。在常规系统中，p‑CSCF将转发邀请到客户端8，在本例中(客户端是非SIP客户端)，客户端8将不知道如何处理它。因此，根据本发明，为客户端8例示的一般代理44(或等同地，充当一般代理的p‑CSCF)代表客户端8将适当的SIP回复发送回应用服务器8b。如果尝试在AG上安装QoS策略成功，则一般代理将接受(例如，“200 OK”)消息沿邀请的反向路径发送回应用服务器8b。备选，如果QoS策略安装请求失败，则来自一般代理44的返回消息将是BYE消息，向服务器8b指示在附接网络中资源不足，无法为承载流量支持请求的T‑Spec。在此操作中，将注意到QoS处理应用到附接承载段和为完成承载流量的建立而生成的SIP信令，而b‑CSCF(或一般代理44)对客户端应用无任何感知。因此，一般代理44确实是一般性，它能用于为任何客户端应用建立带有QoS处理的承载流量。
一旦应用服务器8b完成了SIP会话建立，它发送到符合F‑Spec的客户端8的分组将以普通尽力服务方式遍历各种中间域，但将以指定的QoS遍历接入/附接网络6。
在应用服务器8b结束为客户端8服务时，它能通过沿原邀请的路径发送SIP BYE消息而释放QoS资源。它到达p‑CSCF时，BYE消息将促使用于承载流量的QoS策略以普通方式释放，但同样地，生成SIP确认讯息的将是p‑CSCF(或一般代理44)，而不是客户端应用本身。
注意，附接网络中的QoS策略由所谓“拉”(pull)机制安装时，上面公开的机制将对未修改的应用客户端不起作用，这是因为“拉”机制要求在该过程中涉及客户端，而所述方法的本质是在附接网络中安装QoS策略而不涉及客户端。
处理NAT：多个IP地址域
如上所述，在TE 8和AS 8b处于不同的IP地址域时，有两种情况要处理。这两种情况的第一情况是在TE 88在专用IP地址域中并且核心网络是单个公共IP地址域的一部分时。AG 8b执行NAT功能，将正进入核心网络4中的分组上的IP报头转换，使得在分组到达应用服务器8b时，来自客户端8的分组中的源地址是由AG 10通告的公共地址。假设应用服务器8b在构建服务网关URI和F‑Spec中使用此公共地址(并且不是控制分组内的未转换地址)，则邀请消息将如上所述到达控制p‑CSCF。p‑CSCF使用公共IP地址域F‑spec进行其RACF请求：意识到它在对来自客户端8的业务进行NAT处理的AG 10需要在附接网络中安装任何IP层“门”前映射F‑spec中的客户端IP地址。) 在核心网络14之间存在IP地址域边界时，事情变得有点更棘手：承载流量路径实际上在执行内部地址域NAT的TBG 14处被分段成两部分。在图8中，左侧IP地址域与右侧IP地址域之间的边界示为在服务器的归属域的边缘(但它可能在任何域的边界)，并且该处的TBG 14是在所有业务上执行NAT的TBG。从生成服务网关URI的应用服务器8b的角度而言，该TBG 14是服务网关(即，从TE客户端到达的分组中源地址的该通告者，在图8中应用服务器看到B的源地址，这是右侧IP地址域中的地址。) SIP邀请消息能路由到使用例如上述相同的机制控制NAT TBG 14的b‑CSCF。如上所述，控制地址域边界TBG的b‑CSCF必须能够执行SIP ALG功能。这种情况下，在SIP邀请消息到达控制网关前，关注的F‑Spec的NAT映射将已在NAT TBG中安装。b‑CSCF的第一个动作必须是轮询(poll)TBG 14以了解NAT映射，以便它随后能够为客户端侧(左侧)IP地址域构建邀请消息，带有用于TE 8附接到的AG 10的服务网关URI和用于客户端侧承载段的F‑Spec。在图8中，新服务网关URI将包含地址A。从这一点开始，过程如上所述继续，b‑CSCF对回复SIP消息执行所需的ALG功能。
在处理核心网络之间的IP地址域边界时，有一个中止申请(caveat)。如上所述，承载流量的路由IP路径可不遍历与SIP信令相同的域。具体而言，可存在一些网络，在这些网络中路由IP路径可通过未参与NGN的域。如果NAT转换发生在不是NGN一部分(即，不在b‑CSCF控制下)的边界网关，则上述机制将失效。对这种情况的对策是使用如下一部分中所述的完全路由钉扎。
示例
本发明的使用的典型示例将是用于遗留(即，pre SIP)流传送视频服务。视频服务提供商可能希望以大于大多数接入/附接网络在“尽力服务型”服务级别能可靠支持的质量级别提供流传送视频。一旦本发明在NGN中部署，视频服务提供商便将升级其服务器以具备SIP能力(包括能够生成服务网关URI)，并随后协商来自本地运营商的IMS服务。本地运营商将设置使用费，该使用费可按每部电影，或基于时间，或按在特定QoS类传送的每兆字节来收取。此形式的使用费将取决于竞争因素，并且对于保持“按净计算”(“on‑net”)的会话(客户端附接到运营商自己的网络)，将可能低于对于运营商必须与一个或多个其它运营商共享费用的会话。使用费也可以对应用客户端在使用的附接网络类型是特定的，对无线收取高于有线的费用。视频服务提供商与NGN运营商之间的SLA也将包括在会话失败时的退款问题。
视频服务的潜在客户端按通常一样继续，与视频应用服务器交互以浏览和选择电影。在浏览响应的一部分显示时，观看电影的价格将向用户呈现：视频服务提供商将可能设置价格以包括运送(delivery)费用的成本。可能电影将附带有不同的清晰度，以不同的价格，适合不同的客户端附接网络。一旦用户选择完成，视频服务器便启动SIP会话，邀请的TO子句包含带有客户端的IP地址的服务网关URI和用于视频流的T‑Spec。这将促使在为客户端服务的AG在客户端当前正使用的附接网络中安装QoS策略，使得从服务器到客户端的视频内容分组接收视频服务器在邀请消息中请求的QoS处理。
承载流量的端对端QoS处理
如上所述，NGN网络能向承载流量的所有段提供QoS处理，承载流量“钉扎”通过参与SIP信令交换的管理域的TBG。TE客户端不是SIP讲述者时，此机制和结果端对端QoS能力能与服务器网关URI的使用组合在一起。与用于只在客户端附接段上提供QoS的机制相比，组合机制使每个p‑和b‑CSCF(在服务器的邀请消息被路由到控制TE的服务网关的p‑CSCF时，处理该消息)也让网关准备好以进行NAT转换来钉扎承载流量，使得它接收请求的QoS处理。
除在附接段上QoS所需的条件和假设外，提供端对端QoS需要有一个额外的规定：在发送是承载流量的一部分的分组时，应用服务器必须使用从在SIP回复“200 OK”消息中收到的最终F‑Spec得出的目的地地址和端口号，而不是它从遗留协议中了解的原客户端地址和端口号(它将其放置在原F‑Spec中)。
由于CSCF生成的最终F‑Spec定义用于应用服务器的附接承载段，因此，使用分组报头中的其地址确保：即使当应用服务器具有在适当位置的多个网络附接链路，应用服务器也将向SIP信令已“准备好”的AG转发承载分组，以提供QoS和映射分组报头以便将分组转发到下一承载段上；并且在有不止一个IP地址域要遍历时，路由钉扎操作促使使用通过控制b‑CSCF来设置其NAT映射的NAT网关。
益处
本方法的益处能从遗留视频流传送服务的上述示例明白。未使用本发明时，视频服务提供商对遗留(即，非SIP)客户端确保QoS的唯一方式将是视频服务提供商与其订户使用的每个附接网络提供商建立(enter into)特殊的关系，使得来自其视频服务器的所有业务被给予(accord)那些附接网络上的增强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等人所著“实时流传送协议(RTSP)”(Real Time Streaming Protocol (RTSP))，RFC 2326，1998年4月]和RSVP [R. Braden (ed.)等人所著“资源保留协议(RSVP)”(Resource Reservation Protocol (RSVP))，RFC 2205，1997年9月]。本发明的第四方面提供一种网关装置，该装置提供遗留IP信令到SIP信令互配。因此，能提供托管信令互配功能(SIWF)的互配网关，该功能在网络边缘处终止RTSP和/或RSVP信令，并生成跨核心网络的SIP消息以建立(启用QoS的)端对端承载路径。
图9是互配网关的部署的图示。在此图中，信令互配功能(SIWF)示为在用于要与承载流量互连的两个应用实体(TE上的客户端和AS上的服务器)的服务AG上托管。始终在往来终端系统的分组路径中的AG是托管信令互配功能的优先选择，这是因为通过使用深度分组检查，它们能检测带内遗留信令分组(“带内”指信令分组与其它业务混合)。然而，AG不是唯一可能的选择。另一种可能实现将AG的职责约束为检测信令分组并将它们以某种形式的隧道转发到与AG的控制p‑CSCF共处在同一平台上的信令互配功能。
SIWF的操作能简要概述如下
每个SIWF建立与p‑CSCF的关联，并将自身注册为用于它服务的终端系统的SIP客户端。如在服务网关(发明3)的情况中一样，注册的客户端地址可仅是AG为附接到它的终端系统通告的IP地址。备选，并且更多为了符合商业考虑，应用服务器可具有在运营商授权使用SIWF功能性建立跨NGN网络的启用QoS的承载路径时通过管理过程指配的名称。
在检测到遗留信令消息，该消息是源于它服务的终端系统的建立承载流量的请求时，SIWF从消息中提取承载流量的F‑Spec和T‑Spec，并构建寻址到遗留消息寻址到的同一实体的SIP邀请消息。然而，遗留信令协议的名称可用作URI的第一部分，而不是对邀请请求URI的方案部分进行“sip：”处理，以向目的地指示邀请消息确实来自SIWF。此外，源IP遗留信令消息可以以在SIP‑I(也称为SIP‑T)中传送ISUP消息的相同方式作为字段“SIP消息正文”传送。
NGN网络向将其目的地URI作为名称注册的SIWF转发SIP邀请消息(假设通过支持注册其名称或IP地址的SIWF功能的AG，目的地附接到NGN)。邀请消息到达注册了目的地的SIWF时，该SIWF(直接从邀请中传送的消息的封装版本，或通过反向执行生成邀请中F‑Spec和T‑Spec的过程)重新构成遗留信令消息。重新构成的遗留消息随后被转发到目的地实体。在本发明的一个实现中，SIWF将辞去(leave)作为实际始发实体的遗留消息的明显源，但在其它实现中，特别是始发和目的地实体在不同地址域中的那些实现中，SIWF将显示为遗留信令消息的发起者。(此后一方案使得SIWF易于接收遗留信令回复，这是因为它将被定向到该回复，但由于它是无ALG的NAT的一种形式，因此，它也可造成应用中断。)
适当的时候，目的地实体将生成遗留协议响应。这将被服务AG捕获并引导到SIWF。SIWF将把对重新构成的原消息的响应和对原邀请的响应进行匹配。SIWF将遗留响应转换成SIP响应(例如，200 OK)，并在返回信令路径上将它转发到为发起者服务的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地址以及端口号(及协议)的完整元组，称为固定滤波器，这意味着在源发送出“路径”消息前，该源需要知道目的地IP地址和端口号。
“路径”消息寻址到承载流量的预期接收方，因此沿发送方与接收方之间的IP路由路径行进。在简单的单播情况下，“路径”消息的主要效应是在具有遍历的RSVP能力的路由器中记录前一跳地址，使得返回消息“resv”消息能以相同路径从接收方遍历回到发送方。接收方通过“resv”消息回复，该消息反向沿“路径”消息的逐跳路径行进。在它处理“resv”消息时，每个具有RSVP能力的路由器基于“resv”消息中的T‑Spec(有点混淆地称为flowspec)将网络资源指定(commit)用于承载流量。
使用RSVP到SIP SIWF网关
图10是概括消息序列图，示出在从应用服务器(AS)到客户端终端设备(TE)跨NGN的承载流量建立中的信令互配，AS和TE均使用RSVP请求网络为承载流量提供QoS。SIWF功能位于从AS和TE两者的第一IP跳处，根据图1所述的NGN体系结构，这暗示SIWF功能性在附接网关(AG)上托管。(如上所述，通过例如在与托管控制AG的p‑CSCF相同的平台上让AG认识并隧穿RSVP信令消息到在网络中进一步托管的SIWF功能，可扩展此第一跳。) 假设AS提供到TE的应用由它们之间的消息交换启动。在某个点(例如，电影已选定并且付款细节已解决)，AS确定它需要将分组流量(承载流量)提供到TE，并构成“路径”消息，该“路径”消息指定流量的源和目的地IP地址和端口号(F‑Spec)及用于流量的T‑Spec。它将此消息寻址到TE，并在S2将它寄出。“路径”消息被SIWF截取(intercept)并转换成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“路径”消息能作为邀请消息中的不透明字段封装和传送。在另一实施例中，邀请消息中将只传送“路径”消息的内部字段而不传送其报头。此外，如上所述，本发明的实施例可选择更改URI的“方案”，产生象如下所示的邀请消息的第一行：
INVITE rsvp :xxx.xxx.xxx.xxx SIP/2.y
其中，xxx.xxx.xxx.xxx是IP(v4)地址。
NGN网络将把SIP邀请消息以上述方式转发到为AG服务的p‑CSCF，而该AG为TE服务。根据SIWF已执行的注册它能够执行其互配功能的IP地址(或地址范围)的注册功能，p‑CSCF将是有能力的。在更改URI中的方案的实施例中，那将足以改变p‑CSCF以将邀请转发到服务SIWF。
SIWF随后在封装(部分)的原路径消息包括在内时使用该消息从邀请消息重新生成RSVP“路径”消息，并将其自己的IP地址作为“前一跳”添加到消息中。它将“路径”消息转发到TE 8(在S6)上。TE 8将通过寻址到托管SIWF功能的节点(其前一跳)的“resv”消息S8进行响应。SIWF功能将使“resp”消息(S8)与在接收邀请消息时它安装的状态相配，并从中它将生成对邀请的响应，例如，200 OK消息S10。由于RSVP的规则允许TE将“resp”中的T‑Spec参数更改为它在“路径”消息中收到的不同值，因此，SIWF将不得不为响应重新生成SDP的T‑Spec部分，而不是只回应(echo back)它在邀请中收到的相同值。200 OK消息通过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会话在进行，但SIWF不得不生成匹配的刷新消息，使得发送方和接收方不会认为承载路径已失去其保留。
像允许资源保留作废一样，RSVP确实规定了显式拆除。在图10中，发送方示出通过发出”pathtear”消息S16来终止承载路径，作为与接收方的会话结束。在SIWF从RSVP发送方(或接收方)接收“pathtear”(或“resvtear”)消息时，它发出SIP BYE消息S18。BYE消息被确认(通过200 OK响应S20)，而RSVP“tear”消息不被确认。
本领域的技术人员将认识到不要求TE和AS离其服务SIWF一个IP跳。具体而言，AS和/或TE能连接到RSVP支持网络(例如，带有启用RSVP的路由器的企业网络)，并且在NGN边界处的SIWF功能可能间隔几个IP跳。
RTSP
像SIP一样，RTSP是基于文本的应用协议。并且，像SIP一样，它使用SDP来描述媒体流。在语义学(semantics)中有相当大的重叠。然而，由于比SIP更早开发，它针对的是SIP支持的应用子集。RTSP的主要应用领域是包括存储和直播型的多媒体演示。网上直播及其从储存器的随后重放是RTSP的一种使用，音频或视频的因特网流传送是另一使用。RTSP消息的语义学不直接与SIP相等。一种类型的消息“描述(DESCRIBE)响应消息”传送描述可能几个承载流量的演示的SDP(并且从中不得不推断每个流量的T‑Spec)，而另一类型的消息“建立(SETUP)消息”传送用于一个承载流量的F‑Spec。每个承载流量需要单独的建立消息。更糟糕的是，RSTP不要求使用描述消息：应用客户端能通过任何技术了解承载流量的媒体初始化参数。
因此，必须认识到将难以产生有效的SIP‑RTSP SIWF来处理RTSP的所有可能使用。由于实际上极少量的RTSP媒体服务器和播放器(即，REAL、Quicktime、Windows)支配了因特网上RTSP的使用，因此，设计为处理其RTSP使用模式的SIWF将是最有益的。下面描述本发明的一个实施例，该实施例针对在已交换描述消息后在会话中建立承载流量的应用。
使用RTSP到SIP SIWF网关
图11示出用于RSTP客户端或播放器(在TE上托管)的消息流程，该RSTP客户端或播放器跨在其边缘具有截取来自TE和AS的RTSP消息的RTSP到SIP SIWF功能的NGN向RSTP讲述应用服务器(AS)请求媒体流。
希望启动RSTP会话的RTSP客户端将知道应用服务器的URL，因此，它能生成描述请求消息的请求URI，并将该消息发送(在S22)到服务器。在图11中，描述请求消息示为直接经过托管SIWF功能的节点。只有响应RTSP 200 OK(S24)是它们关注的，并且实际上只有为客户端服务的SIWF需要缓冲对描述的响应的SDP正文部分。应注意的是，描述会话的媒体流的应用服务器无需是提供媒体流的相同实体，因此，将不保证服务应用服务器的SIWF将是与服务媒体服务器相同的SIWF。
客户端的SIWF(即，在TE附接的AG处托管的SIWF)需要能够检测引导到客户端的消息流中的RTSP 200 OK消息。具体而言，它需要检测和缓存在消息正文中传送的媒体流的描述。实际上，SIWF能指定为检查“内容‑类型：应用/sdp”行的所有形式的200 OK消息，并缓存正文内容来针对来自客户端的可能将来RTSP建立请求。具体而言，这将包括使用HTTP响应输送用于会话的SDP参数的情况。
客户端收到的SDP参数描述构成会话的一个或多个媒体流源。为每个源包括的是其URI。因此，客户端向每个媒体流源发出建立请求，并带有它从描述响应中了解的请求URI(图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 200 OK响应消息S34的其它部分从邀请消息的内容构建。在200 OK响应通过邀请的反向路径传回时，各种CSCF在网关中安装QoS策略以确保F‑Spec描述的承载路径接收T‑Spec指示的QoS处理。
客户端的SIWF将SIP 200 OK响应S34转换成对原建立消息的响应(RSTP 200 OK响应S36)，并将该响应发送到客户端上。不同于SIP，RTSP也具有控制媒体流播出(例如，启动快进序列)的方法(命令)集。这些命令只涉及服务器，并且无需由SIWF解释。在此命令集中包括的是播放(PLAY)请求，服务器在收到播放请求前，实际上不发送任何承载流分组。然而，TEARDOWN请求S38由SIWF截取并转换成SIP BYE消息S40。RTSP的TEARDOWN和SIP的BYE消息均要求确认(200 OK)S42、S44。
授权和计费
IMS体系结构的主要益处之一在于用户(以SIP客户端的形式)得到鉴权(在注册(REGISTRATION)步骤期间)，并且NGN生成计费信息，将用户与他们请求的QoS承载流量联系在一起。如上所述，在NGN中提供SIWF网关会削弱这些控制，这是因为它们允许未注册端点来请求和使用网络资源。在实际的商业部署中，运营商将需要预授权承载流量的一端(可能是应用服务器)，这是因为存在与其协商帐务安排的极少的应用服务器。运营商将管理地提供应用服务器的地址到其服务SIWF中，并明确允许互配功能。SIWF能得到它向s‑CSCF注册的服务器的URL，使得SIP消息能使用该URL作为目的地URI而不是服务网关IP地址方法路由到SIWF。
QoS的选择性应用
然而，即使当应用服务器被安全标识，并且商业安排到位以便为它建立的QoS承载流量向它开单时，服务器也不能选择在发送给它的流量上特定的客户端是接收QoS处理还是尽力服务处理。(这可取决于客户端用户是否具有向应用服务器提供商的预订。) 适用于诸如通过URI标识媒体流的RTSP等遗留协议的本发明的进一步改进可让应用使用不同的URI，根据媒体流是否要接受QoS处理来标识其它相同的媒体流。NGN中的所有SIWF将必须能够区分两种类型的URI。参照图11，在建立消息到达服务SIWF的客户端时，它将检查目的地URI，并只在URI指示应用服务器“请求”了QoS处理时才将建立消息转换为SIP邀请消息。否则，SIWF功能忽略建立消息，并且它以标准遗留方式行进到应用服务器而无进一步的网络涉及。本领域的技术人员将认识到有许多方案能用于区分URI：一个示例将是使用服务器的服务域的IMS域名作为附加到应用服务器自己的URL后的URI的域部分。
在上述的本发明的第三方面，为建立QoS承载流量，服务器需要是SIP讲述者，但服务器与客户端之间的协议被忽略。另一方面，在上述第四方面，客户端与服务器之间的协议被转换成SIP。正如可理解的一样，组合这两种方法是可能的。图12示出提供用于在应用服务器与客户端之间的QoS承载路径的NGN实施例，其中，应用服务器使用到本地SIWF网关的遗留信令协议以请求QoS，并且SIWF网关将信令转换成到客户端TE的服务网关(p‑CSCF控制)的SIP消息。
有两种情况要考虑。
在一种情况下，客户端不是遗留信令协议的讲述者。服务器使用遗留信令协议，这是因为它比SIP更易于实现。这在用于RSVP情况的图13中示出。注意，虽然在此情况下，在使用RSVP时，SIWF功能(或至少RSVP消息的检测)必须在服务器的服务AG中托管，但对于诸如允许配置代理(即，消息是通过IP寻址到代理)的RTSP等其它协议，SIWF功能无需在服务器与客户端之间的分组的直接路径中。具体而言，SIWF功能能包括在服务器的服务p‑CSCF中。
在另一情况下，遗留信令协议在客户端与服务器之间交换，但它也由服务器的SIWF进行检查而不是修改。对于RTSP的情况，这通过图14示出。这种情况下，SIWF功能充当透明代理(即，RTSP分组不要寻址到它)，并且因此必须是服务AG的一部分。
本文中所述的方法和系统因而克服了现在IMS的限制，该限制是只处理通过SIP讲述端点之间的RTP提供的多媒体。本文中一起描述和声明的发明允许任何内容在从任何内容源到任何目的地的QoS承载流量上提供，同时保持了IMS的安全和收费框架，为下一代网络的运营商从客户和应用服务提供商扩大了新的收入来源。
上述本发明的实施例仅旨在说明。因此，本发明的范围将只受随附权利要求的范围的限制。