CN102016801A - Sip会话策略框架的扩展的解决方法和系统 - Google Patents

Sip会话策略框架的扩展的解决方法和系统 Download PDF

Info

Publication number
CN102016801A
CN102016801A CN200980104719.7A CN200980104719A CN102016801A CN 102016801 A CN102016801 A CN 102016801A CN 200980104719 A CN200980104719 A CN 200980104719A CN 102016801 A CN102016801 A CN 102016801A
Authority
CN
China
Prior art keywords
sip
policy
information
user agent
stem
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN200980104719.7A
Other languages
English (en)
Other versions
CN102016801B (zh
Inventor
约翰-卢克·贝克
安德鲁·艾伦
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
BlackBerry Ltd
Original Assignee
Research in Motion Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Research in Motion Ltd filed Critical Research in Motion Ltd
Publication of CN102016801A publication Critical patent/CN102016801A/zh
Application granted granted Critical
Publication of CN102016801B publication Critical patent/CN102016801B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/465—Distributed object oriented systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/46—Indexing scheme relating to G06F9/46
    • G06F2209/462—Lookup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

一种给用户代理提供策略信息的方法。该方法包括：用户代理发送与用户代理针对策略信道上的通信所支持的多个统一资源标识符(URI)方案相关的信息，并且发送与用户代理支持的策略信息的多个表示有关的信息。该方法还包括用户代理接收选择多个URI方案中的至少一个以及选择策略信息的多个版本中的至少一个的指示。该方法还包括用户代理使用所选的策略信息的表示中的至少一个并使用所选的URI方案中的至少一个来获得策略信息。

Description

SIP会话策略框架的扩展的解决方法和系统
本申请要求由Andrew Allen等于2008年2月18日提交的、题为“System and Method for Resolving Extensions for the SIP Session PolicyFramework”的美国临时专利申请No.61/029,523的优先权，其全部内容以引用的方式并入于此。
背景技术
IP(互联网协议)多媒体子系统(IMS)是给移动和固定用户代理(UA)提供包括IP电话在内的多媒体服务的标准化架构。会话发起协议(SIP)主要由互联网工程任务组(IETF)进行了标准化和管理，作为创建、修改和终止基于IMS的呼叫或会话的信令协议。在此，“用户代理”和“UA”在一些情况下指代移动设备，诸如移动电话、个人数字助理、手持或膝上型计算机和具有通信能力的类似设备。这种UA可以包括UA及其相关可拆卸存储模块，其相关可拆卸存储模块例如但不局限于通用集成电路卡(UICC)，通用集成电路卡(UICC)包括订户标识模块(SIM)应用、通用订户标识模块(USIM)应用或可拆卸用户标识模块(R-UIM)应用。可选地，这种UA可以包括不具有这种模块的设备本身。在其他情况下，术语“UA”指代具有类似能力但不可携带的设备(例如固定电话、台式计算机、机顶盒或网络节点)。当UA是网络节点时，该网络节点可以代表诸如UA或固定设备之类的另一功能进行操作，并且仿真或模拟该UA或固定设备。例如，对于一些UA，典型地位于设备上的IMS SIP客户机实际上位于网络中，并且使用优化协议将SIP消息信息中继到该设备。换言之，通常由UA执行的一些功能可以以远程UA的形式分布，其中，远程UA在网络中代表该UA。术语“UA”还可以指代可以终止通信会话的任何硬件或软件组件，所述通信会话包括但不局限于SIP会话。此外，这里，术语“用户代理”、“UA”、“用户设备”、“UE”和“节点”以相同含义使用。
附图说明
为了更完整地理解本公开，现在参照结合附图和详细描述而进行的以下简要描述，其中，类似的参考标记表示类似的部件。
图1是根据现有技术的SIP会话的建立的流程图；
图2是根据本公开实施例的策略架构的图；
图3是根据本公开实施例的用于给用户代理提供策略信息的方法的图；
图4示出了适用于实现本公开的若干实施例的处理器和相关组件。
具体实施方式
首先，应当理解，尽管以下提供了本公开的一个或多个实施例的示意性实施方式，但所公开的系统和/或方法是可以使用任意数目的技术来实现的，不论该技术是否是当前已知的或者是现有的。本公开绝不应限于示意性实施方式、附图和以下示意的技术，包括此处示意和描述的示例性设计和实施方式，但可以在所附权利要求的范围及其等同替换的全部范围内修改本公开。
SIP请求注解(RFC)3261是创建、修改和终止多媒体会话的信令协议。SIP的中心元件是代理服务器。代理服务器是负责请求路由、集合、认证和授权、移动性和其它信令服务器的中间件。然而，代理是与SIP建立的实际会话(音频、视频和会话模式消息收发)分离的。会话的细节承载在SIP消息的有效载荷中，并且通常用会话描述协议(SDP)[RFC4566]来描述。
经验表明：需要SIP中间件来影响会话的方面。典型地，通过实施会话策略来控制会话参数。例如，SIP可以用于针对媒体业务具有有限资源的无线网络。在高度活跃的时间段期间，无线网络提供商也许想要限制每个用户可用的带宽量。通过会话策略，无线网络中的中间件可以向UA通知其可用的带宽。该信息使得UA能够关于其在会话中可以成功地使用的流的数目、媒体类型及编解码器作出可靠判决。类似地，网络提供商可以与用户就服务等级达成一致，该服务等级定义了用户可以使用的媒体类型集合。网络可以将当前的会话策略集合传送给用户代理，使得用户代理能够建立会话，而不会无意地与网络策略冲突。
在另一示例中，SIP UA正在使用通过防火墙或网络边界设备与公共互联网相连的网络。网络提供商也许想要告知UA：它需要将其媒体流发送至防火墙或边界设备商的特定地址和端口，以连接到公共互联网。得知此策略使得UA能够建立穿过防火墙或网络边界的会话。与用于插入媒体中间件的其它方法不同，使用会话策略不需要对SIP消息主体进行检查或修改。
域通常需要适当实施它们所具有的会话策略。例如，域可以具有这样的策略：不允许使用视频，并且具有丢弃包含视频编码在内的所有分组的实施机制。不利地，这些实施机制通常并不告知用户它们正在实施的策略。实际上，它们保持沉默，使得用户不会做任何反对它们的事。这会引起用户不能够理解的设备故障。利用会话策略，用户知晓当前网络策略，并且可以建立遵从策略的会话，或者简单地连接到具有较少严厉策略的域。因此，会话策略提供了同意(consent)与实施的重要组合。也就是说，用户知道策略，并且需要对其采取行动，但是提供商仍然保留实施策略的权力。
存在两种会话策略：会话专用策略和会话无关策略。会话专用策略是针对特定会话所创建的策略，并且可以基于例如会话描述。这些策略使得网络中间件能够检查UA正在提出的会话描述，并且返回特别针对该会话描述的策略。例如，中间件可以在所提出的会话描述中针对每个媒体流在防火墙/网络地址转换(NAT)中开启针孔(pinhole)。然后，可以针对会话描述返回如下策略：用从外部资源可达到的、在防火墙/NAT中开启的IP地址和端口来替换UA的IP地址和端口。由于会话专用策略是针对会话而定制的，因此它们仅适用于它们被创建用于的会话。会话专用策略是在建立会话时逐个会话创建的。
另一方面，会话无关策略是独立于会话所创建的策略，并且通常适用于UA所建立的所有SIP会话。例如，会话无关策略可用于向UA通知现有的带宽限制或媒体类型限制。由于这些策略不是基于特定会话描述的，因此可以独立于建立会话的意图而创建这些策略，并且这些策略仅需要在初始化时(例如在设备加电时)以及在策略改变时传送到UA。
下面描述的机制可用于会话无关策略和会话专用策略。对于会话专用策略(即，响应于SIP请求或SIP响应而提供的策略)，可以将PolicyOffer或PolicyAnswer文档返回给UA。对于会话无关策略(即，在会话之前提供给UA的策略)，可以返回会话策略文档。
除了媒体策略之外，这里定义的机制还可用于通知UA在SDPOffer或Answer中使用不同的IP地址，以便导航防火墙或NAT，或者经由代码转换器或其它媒体中继来路由媒体。
第三代伙伴计划(3GPP)已经将IP多媒体子系统(IMS)标准化为针对移动和地面网络的多媒体服务的基于下一代SIP/IP的网络。在3GPP技术规范(TS)23.228中规定了3GPP IMS的架构。在3GPP TS23.228中规定了IMS组件的功能，包括服务呼叫会话控制功能(S-CSCF)和代理呼叫会话控制功能(P-CSCF)。如[RFC 3261]所定义的，S-CSCF同时用作SIP注册器和SIP代理。P-CSCF也用作SIP代理。3GPP IMS针对会话信令使用SIP，并且如上所述，IMS网络实体(P-CSCF和S-CSCF)可能会需要影响会话的方面(例如流的数目、媒体类型和编解码器)。
3GPP已经定义了针对执行UA接入IMS承载资源所必需的授权和审计功能的策略和收费控制(PCC)的架构。PCC架构包括策略服务器、PCRF(策略控制和收费规则功能)，基于来自各种资源的输入，PCRF基于会话的属性和特性(例如流的数目、媒体类型和编解码器)，来确定允许哪些UA接入承载。PCRF为了基于订户的策略而与用户签约信息库(SPR)接口连接，并为了应用专用输入而与应用功能(AF)接口连接。当与PCC一起使用IMS时，AF是可以基于SIP会话信令而影响PCRF的SIP代理，即P-CSCF。PCRF接口连接到策略控制实施功能(PCEF)，PCEF提供选通和滤波功能以确保实施了策略。PCEF与接入网络专用网关(例如GGSN、PDG、PDSN或CMTS)集成。这些实体可以使用DIAMETER或RADIUS协议进行通信，并形成授权认证审计(AAA)架构的一部分。
当前，3GPP已经在TS 24.229中定义了针对IMS的、基于SIP策略的会话策略监控机制，其中，如果原始SIP INVITE请求包含网络策略不允许的媒体类型或编解码器，则发送SIP 488响应。如[RFC 3261]中规定的，SIP 488响应包含被允许的媒体类型和编解码器的SDP描述，使得主叫UA可以利用被允许的SDP重试请求。然而，该方法存在的问题在于：由于SIP请求经过每个域，则每个域具有自身的策略集合。在漫游的情形下，很可能出现以下情况：单个SIP请求经过多达4个不同的IMS域，并且可能每个域都发送回SIP 488响应，导致会话建立延迟严重。此外，该机制对于在[RFC 3261]中允许的不包含SDP的SIPINVITE请求不起作用，其中，可以发送不具有SDP的初始SIP INVITE，被叫UA可以在响应时发送回SDP邀约(offer)，主叫方然后在ACK请求中返回SDP应答。由于SIP响应仅能够响应于请求而被发送，所以不会利用SIP 488响应来拒绝响应。因此，3GPP IMS通过仅允许这些无邀约SIP INVITE请求来自于网络服务器(网络服务器知道策略)以及来自于这些请求所出现的IMS网络之外，来限制这些无邀约SIP INVITE请求的使用，并且在这些无邀约SIP INVITE请求来自于IMS网络之外的情况下，如果利用与策略相反的编解码器建立了会话，则立即用BYE消息终止会话。该情况不令人满意。
利用3GPP所定义的当前会话策略机制，可能每个域中的每个代理都必须利用SIP 488响应来拒绝SIP INVITE请求，这导致主叫UA必须在SIP INVITE请求到达被叫UA之前，发送五个SIP INVITE请求(并接收四个SIP 488响应)。
在这种情况下必须发送的大量往返SIP消息和大量消息以及策略文档会消耗大量的开销，将导致机制的效率低到不可接受。除此之外还浪费信令带宽，而这将在会话建立中引起显著的延迟。此外，SIP服务器可能需要联系多个策略服务器中的每一个以获得策略信息。这进一步延迟了呼叫建立，并且会消耗UA的电池。
此外，3GPP PCC架构取决于P-CSCF根据SIP信令分析SDP以给PCRF提供输入，以便针对会话而授权承载资源。对于被叫UA，P-CSCF需要在响应中发送SDP应答，以便基于被叫UA接受的媒体类型和编解码器来授权承载资源。这意味着，被叫UA经常需要在应该发送SDP应答之前发送包含SDP应答的临时(1xx)响应。由于IMS使用先决条件框架[RFC 3312]，需要可靠地发送该临时响应。这将需要交换另外的SIP PRACK请求和200OK响应，由于需要端到端地交换附加的不必要的SIP消息，这将导致呼叫建立时间的延迟相当大。
IETF在[draft-sip-session-policy-framework-03]中定义了会话策略框架，以使得网络能够向SIP UA传送当前的策略集合，使得SIP UA能够建立会话，而不会无意地与任何网络策略相冲突。
图1是来自[draft-sip-session-policy-framework-03]的流程图，示出了具有SIP会话建立的会话策略框架的基本IETF SIP架构。在事件12处，第一UAA 110A向第一代理A 120A发送包含SDP邀约的INVITE请求。在事件14处，第一代理A 120A向第一UAA 110A发送包含Policy-Contact首部的SIP 488消息(在这里，术语“首部”可以指代SIP消息的首部或诸如Contact首部字段之类的首部字段)。然后，第一UAA 110A向第一代理A 120A返回确认消息。在事件16处，第一UAA 110A向第一策略服务器A 130A发送包含InfoOffer的PolicyChannel消息。在事件18处，第一策略服务器A 130A向第一UAA 110A发送包含PolicyOffer的PolicyChannel消息。
在事件20处，第一UAA 110A经由第一代理A 120A和第二代理B 120B向第二UAB 110B发送INVITE邀约消息。在事件22处，第二UAB 110B向第二策略服务器B 130B发送包含InfoOffer和InfoAnswer的PolicyChannel消息。在事件24处，第二策略服务器B 130B向第二UAB110B发送包含PolicyOffer和PolicyAnswer的PolicyChannel消息。在事件26处，第二UAB 110B经由第二代理B 120B和第一代理A 120A向第一UAA110A发送包含SDP应答的OK响应。然后，第一UAA 110A向第二UAB110B返回确认消息。在事件28处，第一UAA 110A向第一代理A 120A发送包含InfoAnswer的PolicyChannel消息。在事件30处，第一代理A 120A向第一UAA 110A发送包含PolicyAnswer的PolicyChannel消息。
针对会话专用策略，典型地需要以下实体：UA、代理、策略服务器以及可能的策略实施实体。图2示出了这些实体的策略架构。UA110经由SIP信令125与代理120进行通信，并经由策略信道135与策略服务器130进行通信。媒体145可以在UA 110和策略实施组件140之间交换。
代理120确保每个UA 110获得在其域中的策略服务器130的统一资源标识符(URI)、并且知道从何处获取策略。代理120在UA 110尚未接收到策略服务器URI的情况下将策略服务器URI传送到UA 110(例如，在前次呼叫中传送或通过例如配置的其它手段传送)。代理120并不向UA 110传送实际的策略。而是，代理120给UA 110提供UA 110可以从中获取策略文档或其它策略信息的策略服务器130的URI或者其它标识符。
策略服务器130是在物理上可以与代理120位于相同位置的分离的逻辑实体。策略服务器130的职责在于向UA 110传送会话策略。策略服务器130从UA 110接收会话信息，使用该信息来确定应用于该会话的策略，并将这些策略返回给UA 110。
会话策略框架定义了SIP Policy-Contact首部(可以由代理120将其包括在SIP请求和响应中)，作为UA 110从代理120接收策略服务器130的URI所使用的机制。也就是说，代理120可以将策略服务器130的URI添加到Policy-Contact首部。UA 110使用该URI来联系策略服务器130并给策略服务器130提供与当前会话有关的信息。然后，UA 110从策略服务器130接收策略更新作为响应。UA 110还可在会话进行期间从策略服务器130接收策略更新。UA 110与策略服务器130之间的通信交换被定义为策略信道135。
当前会话策略框架仅基于在[draft-ietf-sipping-policy-package-03]中定义的SIP事件框架[RFC 3265]和事件包，定义了基于SIP的机制，以使用策略信道135向UA 110传送会话策略，并且当前仅将SIP和SIPSURI定义为可以由代理120包括在SIP Policy-Contact首部中的URI。在[draft-sip-session-policy-framework-03]中定义了会话策略框架的所有细节。
SIP事件框架[RFC 3265]与底层策略和网络架构无关，并且确保所有SIP UA 110能够与所有策略服务器130进行交互。然而，由于设备具有有限功率，例如利用电池的移动设备，以及网络具有有限带宽，例如GSM(全球移动通信系统)、UMTS(通用移动通信系统)CDMA(码分多址)和E-UTRAN(演进UMTS地面无线电接入网络)，SIP事件框架[RFC 3265]在会话建立期间向UA 110传送会话策略的任务非常繁重。最少而言，SIP事件框架需要发送以下SIP消息以获得会话策略：SUBSCRIBE消息、200OK消息、NOTIFY消息和另外的200OK消息。减少交互的次数是有益的，因为这将释放资源并在处理减少的交互时需要的能量更少。
此外，这些消息(尤其是SUBSCRIBE消息和NOTIFY消息)是大尺寸的基于文本的消息，并且还包括IP和UDP首部的开销。因此，这些消息的尺寸有几百字节。NOTIFY消息由于包含以扩展标记语言(XML)编码的策略文档而可能尤其大。减小这些消息的尺寸是有益的，因为这将释放资源并且在处理减小的消息时需要的能量更少。
因此，在图1所示的会话策略流程图中所示的场景下，除了建立会话所需的9条SIP会话信令消息之外，针对策略信道上的使用SIP事件的3次策略信道交互，还需要12条SIP消息。因此，使用SIP事件框架的SIP信令开销比SIP会话建立所需的SIP信令大。除此之外，还浪费信令带宽，但是在诸如蜂窝网络之类的有限带宽的网络中，每秒仅有几千千字节的信令信道，这将引起会话建立的显著延迟。
此外，SIP事件框架是有状态的，这意味着，SIP事件框架建立SIP对话。这将对网络架构实体施加相当大的负荷。此外，策略服务器130传统上并不实现SIP而是使用其它协议(例如AAA(RADIUA和DIAMETER)或HTTP(超文本传输协议))来传送策略。
在实施例中，策略信道的会话策略框架机制是可扩展的，因此可以定义附加的机制以使用策略信道来获得会话策略。在实现这里所述的实施例时，与在上述仅用SIP的场景中使用的多个SIP消息相比，可以极大地减少UA请求和接收策略文档所需的往返消息的数目和大小。更具体地，除了基于SIP或基于SIPS的URI方案之外或者不同于基于SIP或基于SIPS的URI方案，可以在策略信道上使用URI方案。例如，可以使用定义了其它接入专用机制的HTTP、HTTPS(安全超文本传输协议)、FTP(文件传输协议)或统一资源名称(URN)作为传送策略相关数据的URI方案。在策略信道上使用这种URI方案而不是基于SIP或基于SIPS的URI方案可以减少向UA提供策略文档或其它策略信息所需的消息的尺寸和数目。过程可能针对发端UA和目的地UA有所不同。首先考虑发端UA的情况。
在实施例中，SIP首部字段的语法允许规定使用多个URI方案来协商信道。这里，术语“协商信道”可以指代与策略信道的选择有关的事件或与要在策略信道上使用的通信协议的选择有关的事件。当照这样支持信道的信道协商请求的发起方尝试交换信息时，信道协商请求的发起方向信道服务器通知其所支持的信道。信道服务器则可以选择适用于信道协商请求的发起方的方案，将所选方案包括在响应中，并将响应发送给信道协商请求的发起方。
在另一实施例中，增强SIP Policy-Contact首部的语法以允许Policy-Contact首部规定可用于通过策略信道获得会话策略文档的一个或多个URI。当照这样支持多个URI方案的第一UA尝试建立会话时，第一UA可能向第二SIP UA、SIP代理服务器、SIP注册器服务器或SIP背靠背用户代理通知其所支持的方案。下面，术语“SIP组件”可以用于指代任何这种组件。然后，SIP组件选择适用于第一UA的一个或多个方案，将所选方案包括在Policy-Contact首部中，并将Policy-Contact首部发送到第一UA。第二UA可以是端点，或者可以是中间网络节点(例如B2BUA(背靠背用户代理))。
为了SIP组件选择URI方案并将URI方案包括在SIP Policy-Contact首部中，SIP组件需要首先确定第一UA实际上支持哪个(哪些)URI方案。为了将该信息提供给SIP组件，可以创建新的SIP首部，以允许第一UA列出第一UA针对策略信道所支持的URI方案。第一UA则可以在尝试建立会话时将该首部发送到SIP组件。SIP组件将读取该首部中的URI方案列表，从列表中选择适用于策略信道的一个或多个URI方案，将所选URI方案包括在Policy-Contact首部中，并将Policy-Contact首部发送到第一UA。
更具体地，在实施例中，当UA发送SIP请求(例如SIP INVITE)或SIP响应时，UA在SIP消息中包括所支持的策略信道的URI方案的指示。在一个实施例中，该指示可以在SIP首部中，例如在为此而定义的新的SIP首部中(例如Accept-Policy-Contact首部)，并且包含UA所支持的策略信道URI方案的列表。例如，Accept-Policy-Contact首部可以是：
Accept-Policy-Contact:originator＝sip；sips；http；https；urn:gsma:apn
“发起方”参数指示接下来包含SIP消息(请求或响应)的发起方所支持的策略信道URI方案的列表。在这种情况下，UA所支持的策略信道URI方案是sip、sips、http和urn:gsma:apn，但是在其它实施例中，可以支持其它策略信道URI方案。
第一UA可以向SIP组件发送诸如Accept-Policy-Contact首部之类的首部。SIP组件可以从Accept-Policy-Contact首部或类似首部中列出的策略信道URI方案中选择第一UA和SIP组件都支持的、并且将由第一UA用于策略信道的最适当的方案。SIP组件可以在发送到第一UA的SIP消息的Policy-Contact首部中包括所选的URI。例如，如果SIP组件选择“urn:gsma:apn”，则Policy-Contact首部可以是：Policy-Contact:nrn:gsma:apn:pol-serv 12345.mnc012.mcc345.gprs
在接收到包含策略URI的Policy-Contact首部时，第一UA可以使用该URI，使用针对该URI所定义的机制来接入策略服务器。在该示范实施例中，URI是包含3GPP TS 23.003针对GPRS所定义的接入点名称(APN)的URN：
urn:gsma:apn:pol-serv 12345.mnc012.mcc345.gprs
该示范实施例包含标识策略服务器的“pol-serv12345”，作为APN网络标识符。如下面将详细描述的，也可以选择性地规定要传送的策略文档的版本。UA然后可以使用GPRS机制或基于GPRS的其它协议来建立策略信道，以获得策略文档。这仅仅是可以定义的一个可能的接入专用策略URI方案。
图2示出了该过程的实施例，其中，UA 110向代理120发送包括所支持的策略URI方案的列表220在内的Accept-Policy-Contact首部210。代理120选择方案之一并向UA 110发送包括所选方案240的Policy-Contact首部230。
上述过程可以由SIP请求或SIP响应的发起方执行。SIP请求或SIP响应的目的地UA典型地并不在向确定将由目的地UA使用的策略URI方案的代理发送SIP请求或响应之前直接在SIP请求或响应中包括首部。因此，上述过程也许并不适用于目的地UA。
为了解决该问题，在实施例中，当目的地UA执行SIP注册过程时，目的地UA在SIP Register请求中包括其所支持的策略URI方案的列表。在下面的实施例中，定义新的Contact首部字段参数“+sip.supported-policy-scheme”来向SIP注册器传送所支持的策略URI方案的列表。目的地UA则可以在SIP Register请求的SIP Contact首部中包括+sip.supported-policy-scheme Contact首部字段参数。
Contact:<sip:192.0.2.2>；+sip.supported-policy-scheme＝“sip，sips，http，https，urn:gsma:apn”
SIP注册器然后存储与所注册的记录地址(Address of Record)绑定的Contact相关联的Contact首部字段参数。当SIP请求到达注册器(或服务目的地UA的代理服务器)时，注册器或代理获得与目的地UA的Contact地址相关联的所支持策略URI方案的列表，并且将该列表包括在SIP Accept-Policy-Contact首部中。注册器或代理将Accept-Policy-Contact首部连同目的地参数一起添加到SIP请求或SIP响应，以指示接下来包含SIP消息的目的地所支持的策略信道URI方案的列表。例如，Accept-Policy-Contact首部可以是：
Accept-Policy-Contact:target＝sip；sips；http；https；urn:gsma:apn
代理服务器可以从Accept-Policy-Contact首部中列出的策略信道URI方案中选择目的地UA和策略服务器都支持的、将由目的地UA使用的最适当的方案。与发起方的情况类似，代理服务器可以将所选的URI包括在要发送到目的地UA的SIP消息中的Policy-Contact首部中。当目的地UA接收到包含Policy-Contact首部的SIP消息时，目的地UA则可以按照针对发端UA所描述的方式类似的方式，使用Policy-Contact首部中的策略URI，接入策略服务器。
应该认识到，其它实施例和变体也是可以的。例如，可以使用SIP参数代替SIP首部，并且可以改变首部或参数的名称。还可以改变语法的细节和结构。
另一实施例用于针对每个策略URI方案定义新的SIP选项标记或属性标记。这样，代替发端UA使用Accept-Policy-Contact首部，可以在现有SIP支持的首部中包括所支持的策略URI方案的选项标记。类似地，目的地UA可以在SIP注册的Contact首部中包括在[RFC 3840]中定义的现有sip扩展媒体属性标记中的、所支持的策略URI方案的选项标记，而不是+sip.supported-policy-scheme Contact首部字段参数。该实施例并不具有以下问题：选项标记只能是字母数字字符的，并因此无法容易地表示具有分隔符的URN。此外，SIP代理服务器当前并不修改所支持的首部中的选项标记，因此仍然需要Accept-Policy-Contact首部。
在另一实施例中，发端UA并不使用Accept-Policy-Contact首部来指示其所支持的策略URI方案。取而代之，发端UA使用新的Contact首部字段参数“+sip.supported-policy-scheme”，在针对会话的请求的Contact首部中传送所支持的策略URI方案的列表。
在策略信道内，适当的文档传递策略设置。例如，draft-ietf-sipping-media-policy-dataset定义了由URN“urn:ietf:params:xml:ns:mediadataset”标识的策略文档和MIME类型的应用/media-policy-dataset+xml。此外，draft-ietf-sipping-policy-package还定义了事件包，该事件包使用按照IETF RFC 3265的SIPSubscribe/Notify机制来传送会话策略文档。另外，在没有任何指示的情况下，可以假设与策略信道相对应的URN方案的选择还将可以使用该策略信道交换的策略文档确定为“给定”或预定策略文档。
上述说明描述了可以如何规定将用于传送策略文档的策略URI方案。如上所述，还可以规定要传送的策略文档。换言之，有不同的策略文档或策略文档的变体在策略信道内适用，并且上述技术可以扩展以规定将提供哪个策略文档或策略文档的变体。这里，术语“策略信息的表示”可用于指代策略文档、或策略文档的变体或扩展，或者在一些实施例中可以指代策略文档的版本。
更具体地，在实施例中，通过添加参数来进一步扩展Accept-Policy-Contact首部，该参数包含针对所规定的策略URI方案的策略信道所接受的多用途互联网邮件扩展(MIME)类型。存在策略信道所接受的多种MIME类型。如果MIME类型是XML MIME类型，则还可以添加模式版本参数(在下面的示例中标记为“sv”)来指示XML模式扩展或增强。例如，Accept-Policy-Contact首部可以是：
Accept-Policy-Contact:originator＝sip
″application/media-policy-dataset+xml，sv＝urn:ietf:params:xml:ns:mediadataset，urn:ietf
:params:xml:
ns:mediadataset:extensionB，urn:ietf:params:xml:ns:mediadataset:extensionZ″；
Sips″application/media-policy-dataset+xml，sv＝urn:ietf:params:xml:ns:mediadataset″；
http″uri.etsi.org/ngn/params/xml/simservs/xcap″；
https″uri.etsi.org/ngn/params/xml/simservs/xcap″；
urn:gsma:apn″uri.etsi.org/3gpp/policy″
在一个实施例中，当UA发送SIP请求(例如SIP INVITE)或SIP响应时，UA在SIP消息中包括所支持的策略信道URI方案的指示以及所规定的策略URI方案的策略信道所接受的一个或多个MIME类型。还可以包括定义了表示策略文档的可接受XML文档的类的可选符号集合。在一个实施例中，该指示可以在SIP首部中，例如针对该目的所定义的新的SIP首部(例如，Accept-Policy-Contact首部)，并且该新的SIP首部包含UA所支持的策略信道URI方案的列表、以及包含所规定的策略URI方案的策略信道所接受的MIME类型的参数。
还可以按照MIME类型来添加模式版本参数以指示XML模式扩展、增强或变体。模式版本参数包含定义了表示策略文档的可接受的XML文档的类的可选符号集合。模式版本参数接受若干符号(逗号或连字符号)。符号表示一系列支持/接受的XML模式(例如DTD、NGRelax、XML模式)文档。在上述示例中，对于MIME类型“application/media-policy-dataset+xml”，下面的符号表示为了UA能够理解、XML文档所能够遵循的XML模式文档的实际集合：
urn:ietf:params:xml:ns:mediadataset，
urn:ietf:params:xml:ns:mediadataset:extensionB，
urn:ietf:params:xml:ns:mediadataset:extensionZ。
人们可能认为，由于很可能在注册MIME类型时向互联网编号分配机构(IANA)进行了注册，所以“urn:ietf:params:xml:ns:mediadataset”已经是“given”(参见[draft-ietf-sipping-media-policy-dataset-05]第10.1节和[draft-ietf-sipping-media-policy-dataset-05]第10.2节)。这里，为了完整性而包括“urn:ietf:params:xml:ns:mediadataset”，并且“urn:ietf:params:xml:ns:mediadataset:extensionB”和“urn:ietf:params:xml:ns:mediadataset:extensionZ”是表示特定示例扩展的符号。这些符号并不必须按照命名空间来格式化，而可以是与XML模式文档相对应的简单数字、或者甚至可以是字符串。然而，在该示例中，命名空间是最方便的实施例。
UA可以向代理服务器发送诸如Accept-Policy-Contact首部的首部。代理服务器可以从在Accept-Policy-Contact首部中列出的策略信道URI方案和相关联的文档以及变体中选择最适当的方案、MIME类型或支持的MIME类型的变体。针对UA和策略服务器都互相理解并且将由UA用于策略信道的策略文档，代理服务器基于所支持的策略URI和MIME类型(加上按照MIME类型的、定义了表示策略文档的可接受XML文档的类的可选符号集合)进行确定。代理服务器然后将所选的URI、MIME类型或相关联的文档版本包括在发送到UA的SIP消息的Policy-Contact首部中。在接收到包含策略URI和相关联的文档版本的Policy-Contact首部时，UA可以使用该URI，使用针对该URI所定义的机制接入策略服务器，并且在根据包括其所支持的任何变体和扩展的MIME类型的文档中获得策略信息。
图2示出了该过程的实施例，其中，UA 100向代理120发送Accept-Policy-Contact首部210，Accept-Policy-Contact首部210包括所支持的策略URI方案的列表220、按照策略URI方案的所支持的MIME类型的列表245、以及按照MIME类型的所支持的变体/扩展的列表250。代理120选择一个或多个方案、一个或多个MIME类型、和/或一个或多个变体/扩展，并且向UA 110发送包括所选的方案240、所选的MIME类型255和/或所选的变体/扩展260在内的Policy-Contact首部230。
在另一实施例中，UA 110向代理120发送包括所支持的策略URI方案在内的Accept-Policy-Contact首部以及包括按照策略URI方案的所支持的MIME类型的列表或按照MIME类型的所支持的变体/扩展的列表在内的Accept首部。代理120选择一个或多个方案、一个或多个MIME类型、或一个或多个变体/扩展，并且向UA 110发送包括所选的方案在内的Policy-Contact首部和具有所选的MIME类型或所选的变体/扩展的Accept首部。UA 110然后可以将Accept首部中的项与Policy-Contact首部中的项相关联。应该注意，Accept首部字段可以并不出现在所有的SIP响应中。
应该认识到，其它实施例和变体也是可以的。例如，可以使用SIP参数代替SIP首部，并且可以改变首部或参数的名称。还可以改变语法的细节和结构。
上述过程可以由SIP请求或SIP响应的发起方执行。在实施例中，UA是请求或响应的目的地，该请求或响应通过在SIP Registration过程期间发送的SIP Register请求中包括其所支持的策略URI方案的列表以及所规定的策略URI方案的策略信道所接受的MIME类型，来指示其所接受的MIME类型或按照策略文档的MIME类型的变体/扩展。可选地，还可以添加模式版本参数来指示XML模式扩展、增强或变体。在下面的实施例中，定义新的Contact首部字段参数“+sip.supported-policy-scheme”来传送所支持的策略URI方案的列表。还可以向SIP注册器传送包含所规定的策略URI方案的策略信道所接受的MIME类型在内的参数和指示XML模式扩展或增强或变体的模式版本参数。UA可以在SIP Register请求的SIP Contact首部中包括+sip.supported-policy-scheme Contact首部字段参数。例如，Contact首部可以是：
Contact:<sip:192.0.2.2>；+sip.supported-policy-scheme＝
“sip*application％2Fmedia-policy-dataset+xml％2Csv％3Durn％3Aietf％3Aparamsxml
％3Ans％3Amediadataset，urn％3Aietf％3
Aparams％3Axml％3Ans％3Amediadataset％3AextensionB，urn％3Aietf％3Aparams％3
Axml％3Ans％3Amediadataset％3AextensionZ，sips*application％2Fmedia-policy-datas
et+xml％2Csv％3Durn％3Aietf％3Aparamsxml％3Ans％3Amediadataset，
http*uri.etsi.org％2Fngn％2Fparams％2Fxml％2Fsimservs％2Fxcap，
https*uri.etsi.org％2Fngn％2Fparams％2Fxml％2Fsimservs％2Fxcap，
urn％3Agsma％3Aapn*uri.etsi.org％2F3gpp％2Fpolicy”
为了遵循RFC 3840的语法，可以省略某些字符。此外，应该认识到，其它实施例和变体也是可以的。例如，可以使用SIP参数代替SIP首部，并且可以改变首部或参数的名称。还可以改变语法的细节和结构。
然后，SIP注册器存储与所注册的记录地址绑定的Contact相关联的Contact首部字段参数。当SIP请求到达注册器(或服务于目的地UA的代理服务器)时，注册器或代理获得与目的地UA的Contact地址相关联的所支持策略URI方案的列表以及MIME类型(加上按照MIME类型的、定义了表示策略文档的可接受XML文档的类的可选符号集合)。注册器或代理将这些包括在SIP Accept-Policy-Contact首部中，并且注册器或代理将该SIP Accept-Policy-Contact首部连同目的地参数一起添加到SIP请求或SIP响应，以指示接下来包含SIP消息的目的地所支持的策略信道URI方案的列表和MIME类型以及定义了表示策略文档的可接受XML文档的类的符号集合。例如，Accept-Policy-Contact首部可以是：
Accept-Policy-Contact:target＝sip
″application/media-policy-dataset+xml，sv＝urn:ietf:params:xml:ns:mediadataset，urn:ietf
:params:xml:
ns:mediadataset:extensionB，urn:ietf:params:xml:ns:mediadataset:extensionZ″；
Sips″application/media-policy-dataset+xml，sv＝urn:ietf:params:xml:ns:mediadataset″；
http″uri.etsi.org/ngn/params/xml/simservs/xcap″；
https″uri.etsi.org/ngn/params/xml/simservs/xcap″；
urn:gsma:apn″uri.etsi.org/3gpp/policy″
代理服务器可以从Accept-Policy-Contact首部中列出的策略信道URI和相关联的文档版本中选择所支持的最适当的方案和相关联的文档版本。针对UA和策略服务器都可以产生或(在语义上)理解并且将由UA用于策略信道的策略文档，代理服务器基于所支持的策略URI和MIME类型(加上按照MIME类型的、定义了表示策略文档的可接受XML文档的类的可选符号集合)进行确定。与发端情况类似的，代理服务器将所选的URI和相关联的文档版本包括在SIP消息的Policy-Contact首部中。在接收到包含Policy-Contact首部的消息时，按照针对发端UA所描述的方式类似的方式，目的地UA可以使用Policy-Contact首部中的策略URI，来接入策略服务器。目的地UA还可以获得其所支持的MIME类型中的策略文档。
应该认识到，其它实施例和变体也是可以的。例如，可以使用SIP参数代替SIP首部，并且可以改变首部或参数的名称。还可以改变语法的细节和结构。
图3示出了向用户代理提供策略信息的方法300。在框310处，用户代理发送与用户代理针对策略信道上的通信所支持的多个URI方案相关的信息，并且发送与用户代理支持的策略信息的多个表示有关的信息。在框320处，用户代理接收选择多个URI方案中至少一个和选择策略信息的多个表示中的至少一个的指示。在框330处，用户代理使用所选的策略信息的表示中的至少一个并使用所选的URI方案中的至少一个，获得策略信息。
UE 110和上述其它组件可以包括能够执行与上述动作相关的指令的处理组件。图4示出了包括处理组件1310的系统1300的示例，处理组件1310适用于实现这里所公开的一个或多个实施例。除了处理器1310(可以称作中央处理器单元或CPU)之外，系统1300还可以包括网络连接设备1320、随机存取存储器(RAM)1330、只读存储器(ROM)1340、辅助存储器1350和输入/输出(I/O)设备1360。这些组件可以经由总线1370彼此通信。在一些情况下，这些组件中的一些组件可以不存在，或者这些组件中的一些组件可以以各种组合方式彼此组合或与未示出的其它组件组合。这些组件可以位于单个物理实体中，或者位于不止一个物理实体中。可以由处理器1310单独或由处理器1310与图中示出或未示出的一个或多个组件(例如数字信号处理器(DSP)1380)结合来执行这里描述为由处理器1310执行的任何动作。尽管DSP1380被示出为单独的组件，但是DSP 1380可以被并入处理器1310中。
处理器1310执行其可从网络连接设备1320、RAM 1330、ROM1340或辅助存储器1350(可以包括诸如硬盘、软盘或光盘的各种基于盘的系统)访问的指令、代码、计算机程序、脚本。尽管仅示出了一个CPU 1310，但可以存在多个处理器。因此，尽管指令可能被讨论为由一处理器执行，然而该指令还可以由一个或多个处理器同时、串行或以其他方式执行。处理器1310可以被实现为一个或多个CPU芯片。
网络连接设备1320可以采用以下形式：调制解调器、调制解调器组、以太网设备、通用串行总线(USB)接口设备、串行接口、令牌环设备、光纤分布式数据接口(FDDI)设备、无线局域网(WLAN)设备、无线电收发器设备(例如码分多址(CDMA)设备、全球移动通信系统(GSM)无线电收发器设备、全球微波接入互操作性(WiMAX)设备、数字订户线(xDSL)设备、有线电缆数据服务接口规范(DOCSIS)调制解调器)和/或其他公知的与网络连接的设备。这些网络连接设备1320可以使处理器1310能够与互联网或者一个或多个电信网络或其它网络进行通信，处理器1310可以从这些网络接收信息或者处理器1310可以输出信息到这些网络。
网络连接设备1320还可以包括能够以电磁波(例如射频信号或微波频率信号)的形式无线地发射和/或接收数据的一个或多个收发器组件1325。可选地，数据可以在导电体内或其表面上、在同轴电缆中、在波导中、在诸如光纤的光介质中、或者在其它介质中传播。收发器组件1325可以包括独立的接收和发射单元或单个收发器。收发器组件1325发射或接收的信息可以包括已经由处理器1310处理的数据或者将要由处理器1310执行的指令。可以以例如计算机数据基带信号或以载波体现的信号的形式，从网络接收这种信息或将这种信息输出到网络。数据可以根据处理或产生数据、或发射或接收数据所希望的不同顺序排序。可以将当前使用的或将来开发的基带信号、以载波体现的信号或其它类型的信号称作传输介质，并且可以根据本领域技术人员已知的若干方法来产生。
RAM 1330可以用于存储易失性数据，并且还可能存储由处理器1310执行的指令。ROM 1340是非易失性存储设备，其典型地具有与辅助存储器1350的存储容量相比较小的存储容量。ROM 1340可以用于存储指令，并且还可能存储在执行指令期间读取的数据。对RAM1330和ROM 1340的访问典型地比对辅助存储器1350的访问要快。辅助存储器1350典型地包括一个或多个盘驱动器或带驱动器，并且可用于数据的非易失性存储，并在RAM 1330不够大而无法保存所有工作数据的情况下用作溢出数据存储设备。辅助存储器1350可以用于存储当选择了要执行的程序时被加载至RAM 1330中的这样的程序。
I/O设备1360可以包括液晶显示器(LCD)、触摸屏显示器、键盘、键区、开关、拨号盘、鼠标、轨迹球、语音辨认器、读卡器、纸带读取器、打印机、视频监视器或其他公知输入设备。此外，收发器1325可以被当作I/O设备1360的组件，而不是网络连接设备1320的组件，或者除了是网络连接设备1320的组件之外，收发器1325也可以被当作I/O设备1360的组件。
将下面的IETF互联网草案以引用的方式并入于此，就如将其整个复制于此一样：
http://www.ietf.org/internet-drafts/draft-ietf-sip-session-policy-framework.txt
http://www.ietf.org/internet-drafts/draft-ietf-sipping-media-policy-dataset.txt
http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework.txt
http://www.ietf.org/internet-drafts/draft-ietf-sipping-policy-package.txt
此外，将下面的SIP RFC以引用的方式并入于此，就如将其整个复制于此一样：RFC 3261、RFC 3265、RFC 3312、RFC 3840和RFC4566。
此外，将下面的3GPP TS以引用的方式并入于此，就如将其整个复制与此一样：TS 23.003、TS 23.228和TS 24.229。在一个实施例中，提供了一种给用户代理提供策略信息的方法。该方法包括：用户代理发送与用户代理针对策略信道上的通信所支持的多个统一资源标识符(URI)方案相关的信息，并且发送与用户代理支持的策略信息的多个表示有关的信息。该方法还包括：用户代理接收选择多个URI方案中的至少一个以及选择策略信息的多个表示中的至少一个的指示。该方法还包括：用户代理使用所选的策略信息的表示中的至少一个并使用所选的URI方案中的至少一个来获得策略信息。
在可选实施例中，提供了一种用户代理。该用户代理包括处理器，所述处理器被配置为发送与用户代理针对策略信道上的通信所支持的多个统一资源标识符(URI)方案相关的信息，并且发送与用户代理支持的策略信息的多个表示有关的信息。
在可选实施例中，提供了一种网络组件。该网络组件包括处理器，所述处理器被配置为从用户代理接收与用户代理针对策略信道上的通信所支持的多个统一资源标识符(URI)方案相关的信息，并且从用户代理接收与用户代理支持的策略信息的多个表示有关的信息。
尽管在本公开中已提供了若干个实施例，但应当理解，在不脱离本公开的精神或范围的情况下，可以以许多其他具体形式来体现所公开的系统和方法。本公开的示例应被视为示意性的而非限制性的，并且并不意在限制这里给出的细节。例如，可以在另一系统中组合或结合各种元件或组件，或者可以省略或不实现特定特征。
此外，在不脱离本公开的范围的情况下，在各个实施例中描述和示出为分立或单独的技术、系统、子系统和方法可以与其他系统、模块、技术或方法组合或结合。被示出或讨论为彼此耦合或直接耦合或进行通信的其他项目可以通过某种接口、设备或中间组件来(不论是电、机械还是以其他方式)间接耦合或进行通信。在不脱离这里公开的精神和范围的情况下，本领域技术人员可以确定改变、替换和变更的其他示例。

Claims (38)

1.一种用于给用户代理提供策略信息的方法，包括：
用户代理发送与用户代理针对策略信道上的通信所支持的多个统一资源标识符URI方案相关的信息，以及发送与用户代理支持的策略信息的多个表示有关的信息；
用户代理接收选择多个URI方案中的至少一个以及选择策略信息的多个表示中的至少一个的指示；以及
用户代理使用所选的策略信息的表示中的至少一个并使用所选的URI方案中的至少一个来获得策略信息。
2.根据权利要求1所述的方法，其中，所述多个URI方案包括以下中的至少一个：
超文本传输协议http；
安全超文本传输协议https；
文件传输协议ftp；
会话发起协议SIP；
安全会话发起协议SIPS；以及
统一资源名称URN。
3.根据权利要求1所述的方法，其中，使用所选的策略信息的表示中的至少一个并使用所选的URI方案中的至少一个来获得策略信息包括：使用XML配置接入协议XCAP来获得策略信息。
4.根据权利要求1所述的方法，其中，用户代理在第一会话发起协议SIP首部中向SIP组件发送与多个URI方案相关的信息和与策略信息的多个表示有关的信息。
5.根据权利要求4所述的方法，其中，第一SIP首部是SIPAccept-Policy-Contact首部。
6.根据权利要求4所述的方法，其中，SIP组件在第二SIP首部中向用户代理发送选择多个URI方案中的至少一个以及选择策略信息的多个表示中的至少一个的指示。
7.根据权利要求6所述的方法，其中，第二SIP首部是SIPPolicy-Contact首部。
8.根据权利要求1所述的方法，其中，用户代理将与多个URI方案相关的信息和与策略信息的多个表示有关的信息作为会话发起协议SIP Register请求中的SIP Contact首部中的参数发送至SIP注册器服务器。
9.根据权利要求1所述的方法，其中，用户代理将与多个URI方案相关的信息和与策略信息的多个表示有关的信息作为针对会话发起协议SIP会话的请求中的SIP Contact首部中的参数来进行发送。
10.根据权利要求1所述的方法，其中，与策略信息的多个表示有关的信息被规定为多用途互联网邮件扩展MIME类型。
11.根据权利要求1所述的方法，其中，策略信道上的通信包括返回以下中的至少一个：
Policy Offer文档；
Policy Answer文档；
Session Policy文档；以及
以可扩展标记语言XML编码的策略文档。
12.根据权利要求1所述的方法，其中，策略信道上的通信包括：交换与策略信道相对应的预定策略文档。
13.一种用户代理，包括：
处理器，所述处理器被配置用于发送与用户代理针对策略信道上的通信所支持的多个统一资源标识符URI方案相关的信息，以及发送与用户代理支持的策略信息的多个表示有关的信息。
14.根据权利要求13所述的用户代理，其中，所述处理器还被配置用于接收选择多个URI方案中的至少一个以及选择策略信息的多个表示中的至少一个的指示，以及使用所选的策略信息的表示中的至少一个并使用所选的URI方案中的至少一个来获得策略信息。
15.根据权利要求13所述的用户代理，其中，所述多个URI方案包括以下中的至少一个：
超文本传输协议http；
安全超文本传输协议https；
文件传输协议ftp；
会话发起协议SIP；
安全会话发起协议SIPS；以及
统一资源名称URN。
16.根据权利要求14所述的用户代理，其中，使用所选的策略信息的表示中的至少一个并使用所选的URI方案中的至少一个来获得策略信息包括：使用XML配置接入协议XCAP来获得策略信息。
17.根据权利要求13所述的用户代理，其中，用户代理在第一会话发起协议SIP首部中向SIP组件发送与多个URI方案相关的信息和与策略信息的多个表示有关的信息。
18.根据权利要求17所述的用户代理，其中，第一SIP首部是SIPAccept-Policy-Contact首部。
19.根据权利要求14所述的用户代理，其中，用户代理在第二SIP首部中接收选择多个URI方案中的至少一个以及选择策略信息的多个表示中的至少一个的指示。
20.根据权利要求19所述的用户代理，其中，第二SIP首部是SIPPolicy-Contact首部。
21.根据权利要求13所述的用户代理，其中，用户代理将与多个URI方案相关的信息和与策略信息的多个表示有关的信息作为会话发起协议SIP Register请求中的SIP Contact首部中的参数发送至SIP注册器服务器。
22.根据权利要求13所述的用户代理，其中，用户代理将与多个URI方案相关的信息和与策略信息的多个表示有关的信息作为针对会话发起协议SIP会话的请求中的SIP Contact首部中的参数来进行发送。
23.根据权利要求13所述的用户代理，其中，与策略信息的多个表示有关的信息被规定为多用途互联网邮件扩展MIME类型。
24.根据权利要求13所述的用户代理，其中，策略信道上的通信包括返回以下中的至少一个：
Policy Offer文档；
Policy Answer文档；
Session Policy文档；以及
以可扩展标记语言XML编码的策略文档。
25.根据权利要求13所述的用户代理，其中，策略信道上的通信包括：交换与策略信道相对应的预定策略文档。
26.一种网络组件，包括：
处理器，被配置用于从用户代理接收与用户代理针对策略信道上的通信所支持的多个统一资源标识符URI方案相关的信息，以及从用户代理接收与用户代理支持的策略信息的多个表示有关的信息。
27.根据权利要求26所述的网络组件，其中，所述处理器还被配置用于选择多个URI方案中的至少一个以及选择策略信息的多个表示中的至少一个，以及向用户代理发送所选的至少一个URI方案和所选的至少一个策略信息的表示的指示。
28.根据权利要求26所述的网络组件，其中，所述多个URI方案包括以下中的至少一个：
超文本传输协议http；
安全超文本传输协议https；
文件传输协议ftp；
会话发起协议SIP；
安全会话发起协议SIPS；以及
统一资源名称URN。
29.根据权利要求26所述的网络组件，其中，网络组件在第一会话发起协议SIP首部中接收所述信息。
30.根据权利要求29所述的网络组件，其中，第一SIP首部是SIPAccept-Policy-Contact首部。
31.根据权利要求27所述的网络组件，其中，网络组件在第二SIP首部中向用户代理发送选择多个URI方案中的至少一个以及选择策略信息的多个表示中的至少一个的指示。
32.根据权利要求31所述的网络组件，其中，第二SIP首部是SIPPolicy-Contact首部。
33.根据权利要求26所述的网络组件，其中，网络组件将与多个URI方案相关的信息和与策略信息的多个表示有关的信息作为会话发起协议SIP Register请求中的SIP Contact首部中的参数来接收。
34.根据权利要求26所述的网络组件，其中，网络组件将与多个URI方案相关的信息和与策略信息的多个表示有关的信息作为针对会话发起协议SIP会话的请求中的SIP Contact首部中的参数来接收。
35.根据权利要求26所述的网络组件，其中，与策略信息的多个表示有关的信息被规定为多用途互联网邮件扩展MIME类型。
36.根据权利要求26所述的网络组件，其中，策略信道上的通信包括返回以下中的至少一个：
Policy Offer文档；
Policy Answer文档；
Session Policy文档；以及
以可扩展标记语言XML编码的策略文档。
37.根据权利要求26所述的网络组件，其中，策略信道上的通信包括：交换与策略信道相对应的预定策略文档。
38.根据权利要求26所述的网络组件，其中，网络组件是以下之一：
会话发起协议SIP注册器服务器；
SIP代理服务器；
SIP用户代理；以及
SIP背靠背用户代理。
CN200980104719.7A 2008-02-18 2009-02-18 Sip会话策略框架的扩展的解决方法和系统 Active CN102016801B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US2952308P 2008-02-18 2008-02-18
US61/029,523 2008-02-18
PCT/US2009/034411 WO2009105477A1 (en) 2008-02-18 2009-02-18 System and method for resolving extensions for the sip session policy framework

Publications (2)

Publication Number Publication Date
CN102016801A true CN102016801A (zh) 2011-04-13
CN102016801B CN102016801B (zh) 2014-10-15

Family

ID=40521397

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200980104719.7A Active CN102016801B (zh) 2008-02-18 2009-02-18 Sip会话策略框架的扩展的解决方法和系统

Country Status (6)

Country Link
US (1) US20090210478A1 (zh)
EP (1) EP2245534B1 (zh)
KR (1) KR101114707B1 (zh)
CN (1) CN102016801B (zh)
CA (1) CA2714628C (zh)
WO (1) WO2009105477A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102494751A (zh) * 2011-11-25 2012-06-13 罗正辉 一种电子秤

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8537822B2 (en) 2008-11-10 2013-09-17 Research In Motion Limited Methods and apparatus for providing alternative paths to obtain session policy
US9641564B2 (en) 2009-05-14 2017-05-02 Qualcomm Incorporated Maintaining controllee information in collaborative sessions
US9641567B2 (en) * 2009-05-14 2017-05-02 Qualcomm Incorporated Controlling media and informing controller status in collaborative sessions
WO2011032611A1 (en) * 2009-09-17 2011-03-24 Telefonaktiebolaget L M Ericsson (Publ) Method and node in a telecommunications network
KR20130070308A (ko) * 2011-12-19 2013-06-27 삼성전자주식회사 동적 정책 제공을 위한 정책 결정 장치와 주소 변환 장치 사이의 연동을 위한 방법 및 장치
US9954904B2 (en) 2012-06-08 2018-04-24 Intel Deutschland Gmbh Communication devices and methods for operating a communication device
US10440159B2 (en) * 2017-08-03 2019-10-08 T-Mobile Usa, Inc. Header modification for supplementary services

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1117220A1 (en) * 2000-01-14 2001-07-18 Sun Microsystems, Inc. Method and system for protocol conversion
US6970869B1 (en) * 2000-05-09 2005-11-29 Sun Microsystems, Inc. Method and apparatus to discover services and negotiate capabilities
US20040111525A1 (en) * 2002-12-09 2004-06-10 International Business Machines Corporation Dynamic web service implementation discovery and selection apparatus and method
US7028101B2 (en) * 2003-03-25 2006-04-11 Nokia Corporation Optimal location service for managing next hop addressing for messages associated with multiple address schemes
CN1577251B (zh) * 2003-07-28 2012-07-18 国际商业机器公司 小服务器程序的远程协作方法和系统
FI20040577A0 (fi) * 2004-04-23 2004-04-23 Nokia Corp Tiedon toimittaminen tietoliikennejärjestelmän resurssista
US8700729B2 (en) * 2005-01-21 2014-04-15 Robin Dua Method and apparatus for managing credentials through a wireless network
US8542671B2 (en) * 2006-09-29 2013-09-24 Oracle International Corporation Service provider functionality with policy enforcement functional layer bound to SIP
US7788383B2 (en) * 2007-10-30 2010-08-31 Cisco Technology, Inc. Communicating a selection of a potential configuration

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102494751A (zh) * 2011-11-25 2012-06-13 罗正辉 一种电子秤

Also Published As

Publication number Publication date
CA2714628C (en) 2016-04-12
KR101114707B1 (ko) 2012-03-02
CA2714628A1 (en) 2009-08-27
EP2245534A1 (en) 2010-11-03
US20090210478A1 (en) 2009-08-20
CN102016801B (zh) 2014-10-15
EP2245534B1 (en) 2015-09-16
WO2009105477A1 (en) 2009-08-27
KR20100116196A (ko) 2010-10-29

Similar Documents

Publication Publication Date Title
CN102016801B (zh) Sip会话策略框架的扩展的解决方法和系统
CN102833698B (zh) 使用网络发起的数据服务技术推送内容给终端的系统和方法
CN101926152B (zh) 提供会话发起协议请求内容的方法和系统
CN1890931B (zh) 经由分组交换网络信令来建立电路交换通信的系统、设备及方法
CN100401724C (zh) 发送即时消息的方法和设备
EP2227890B1 (en) Methods for facilitating communication between Internet Protocol Multimedia Subsystem (IMS) devices and non-IMS devices
US20090049202A1 (en) System and Method for SMS/IP Interoperability
US20060230154A1 (en) Method and entities for performing a push session in a communication system
US20100110978A1 (en) IMS Device Reconfiguration
US7912042B2 (en) IMS surrogate registration
CN101223746B (zh) 寻呼模式消息收发
US20090210538A1 (en) System and Method for Indicating Supported Session Policy URI Schemes Extensions
CN100589454C (zh) 一种基于ip传输的消息路由方法和系统
EP1672866A1 (en) Method and system to the instant transfer of multimedia files between mobile radio users within the scope of combinational services
US20080247342A1 (en) Connection Setup for the Exchange of Data of an Ip-Based Service
CN102651732A (zh) 一种ims网络中的业务触发方法和系统
CN100421430C (zh) 一种基于ip网多媒体子系统的消息业务实现方法
CN101309447A (zh) 一种在终端上进行业务配置的方法及系统
JP2010516131A (ja) 電話ベースのウェブサーバを発見する方法及び、当該方法に関連する電子機器とコンピュータプログラム
JP4887366B2 (ja) インターネット通信ネットワークコアに属するサービス装置における機能の実施を制御するための装置
CN100466760C (zh) 一种基于ip网络域消息业务的实现方法
KR101043696B1 (ko) 인스턴트 메시지 서비스 시스템 및 이동통신 단말기, 및 그 서비스방법
Mashologu Performance optimization of IP Multimedia Subsystem
JP4854035B2 (ja) Ｉｍｓ／ｍｍｄシステムにおける複数のポリシー制御サーバを用いた呼接続方法及びシステム
KR20080049403A (ko) Ｉｐ 멀티미디어 서비스에서 ｓｉｐ 세션 형성 방법 및시스템

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C53 Correction of patent of invention or patent application
CB02 Change of applicant information

Address after: Voight, Ontario, Canada

Applicant after: Blackberry Ltd.

Address before: Ontario, Canada

Applicant before: Research In Motion Ltd.

COR Change of bibliographic data

Free format text: CORRECT: APPLICANT; FROM: RESEARCH IN MOTION LTD. TO: BLACKBERRY LTD.

C14 Grant of patent or utility model
GR01 Patent grant