Internet Engineering Task Force (IETF) K. Drage
Request for Comments: 6050 Alcatel-Lucent
Category: Informational November 2010
ISSN: 2070-1721
Internet Engineering Task Force (IETF) K. Drage
Request for Comments: 6050 Alcatel-Lucent
Category: Informational November 2010
ISSN: 2070-1721
A Session Initiation Protocol (SIP) Extension for the Identification of Services
用于识别服务的会话启动协议（SIP）扩展
Abstract
摘要
This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the service of authenticated users. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport, and usage of such information. This document does NOT offer a general service identification model suitable for use between different trust domains or for use in the Internet at large.
本文档描述了会话启动协议（SIP）的专用扩展，它使可信SIP服务器网络能够断言经过身份验证的用户的服务。这些扩展的使用仅适用于具有先前约定的生成、传输和使用此类信息的策略的管理域内。本文档不提供适合在不同信任域之间使用或在整个Internet中使用的通用服务标识模型。
The document also defines a URN to identify both services and User Agent (UA) applications. This URN can be used within the SIP header fields defined in this document to identify services, and also within the framework defined for caller preferences and callee capabilities to identify usage of both services and applications between end UAs.
该文档还定义了一个URN来标识服务和用户代理（UA）应用程序。此URN可在本文档中定义的SIP头字段中用于标识服务，也可在为呼叫者首选项和被呼叫者功能定义的框架中用于标识终端UAs之间的服务和应用程序的使用情况。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6050.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6050.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability Statement . . . . . . . . . . . . . . . . . . . 5
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Syntax of the Header Fields . . . . . . . . . . . . . . . . . 6
4.1. The P-Asserted-Service Header . . . . . . . . . . . . . . 6
4.2. The P-Preferred-Service Header . . . . . . . . . . . . . . 7
4.3. Service and Application Definition . . . . . . . . . . . . 8
4.4. Registration Template . . . . . . . . . . . . . . . . . . 8
5. Usage of the P-Preferred-Service and P-Asserted-Service
Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Usage of the P-Preferred-Service and
P-Asserted-Service Header Fields in Requests . . . . . . . 10
5.1.1. Procedures at User Agent Clients (UAC) . . . . . . . . 10
5.1.2. Procedures at Intermediate Proxies . . . . . . . . . . 11
5.1.3. Procedures at User Agent Servers . . . . . . . . . . . 12
5.2. Usage of the P-Preferred-Service and
P-Asserted-Service Header Fields in Responses . . . . . . 12
6. Examples of Usage . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1. P-Asserted-Service and P-Preferred-Service Header
Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.2. Definition of Service-ID Values . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability Statement . . . . . . . . . . . . . . . . . . . 5
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Syntax of the Header Fields . . . . . . . . . . . . . . . . . 6
4.1. The P-Asserted-Service Header . . . . . . . . . . . . . . 6
4.2. The P-Preferred-Service Header . . . . . . . . . . . . . . 7
4.3. Service and Application Definition . . . . . . . . . . . . 8
4.4. Registration Template . . . . . . . . . . . . . . . . . . 8
5. Usage of the P-Preferred-Service and P-Asserted-Service
Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Usage of the P-Preferred-Service and
P-Asserted-Service Header Fields in Requests . . . . . . . 10
5.1.1. Procedures at User Agent Clients (UAC) . . . . . . . . 10
5.1.2. Procedures at Intermediate Proxies . . . . . . . . . . 11
5.1.3. Procedures at User Agent Servers . . . . . . . . . . . 12
5.2. Usage of the P-Preferred-Service and
P-Asserted-Service Header Fields in Responses . . . . . . 12
6. Examples of Usage . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1. P-Asserted-Service and P-Preferred-Service Header
Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.2. Definition of Service-ID Values . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the service, possibly subject to the user being entitled to that service. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport, and usage of such information. This document does NOT offer a general service model suitable for use between different trust domains or for use in the Internet at large.
本文档描述了会话启动协议（SIP）的专用扩展，该扩展使受信任的SIP服务器网络能够断言服务，这可能取决于用户有权使用该服务。这些扩展的使用仅适用于具有先前约定的生成、传输和使用此类信息的策略的管理域内。本文档不提供适合在不同信任域之间使用或在Internet上使用的通用服务模型。
The concept of "service" within SIP has no hard and fast rules. RFC 5897 [RFC5897] provides general guidance on what constitutes a service within SIP and what does not.
SIP中的“服务”概念没有硬性规定。RFC 5897[RFC5897]提供了关于SIP中哪些构成服务以及哪些不构成服务的一般指导。
This document also makes use of the terms "derived service identification" and "declarative service identification" as defined in RFC 5897 [RFC5897].
本文件还使用了RFC 5897[RFC5897]中定义的术语“派生服务标识”和“声明性服务标识”。
It should be noted that RFC 5897 [RFC5897] clearly states that declarative service identification -- the process by which a user agent inserts a moniker into a message that defines the desired service, separate from explicit and well-defined protocol mechanisms -- is harmful.
应该注意的是，RFC 5897[RFC5897]明确指出声明性服务标识（用户代理将名字对象插入定义所需服务的消息中的过程，与明确且定义良好的协议机制分离）是有害的。
During a session setup, proxies may need to understand what service the request is related to in order to know what application server to contact or other service logic to invoke. The SIP INVITE request contains all of the information necessary to determine the service. However, the calculation of the service may be computational and database intensive. For example, a given trust domain's definition of a service might include request authorization. Moreover, the analysis may require examination of the Session Description Protocol (SDP).
在会话设置期间，代理可能需要了解请求与哪个服务相关，以便知道要联系哪个应用程序服务器或调用其他服务逻辑。SIP INVITE请求包含确定服务所需的所有信息。然而，服务的计算可能是计算和数据库密集型的。例如，给定信任域的服务定义可能包括请求授权。此外，分析可能需要检查会话描述协议（SDP）。
For example, an INVITE request with video SDP directed to a video-on-demand Request-URI could be marked as an IPTV session. An INVITE request with push-to-talk over cellular (PoC) routes could be marked as a PoC session. An INVITE request with a Require header field containing an option tag of "foogame" could be marked as a foogame session.
例如，具有指向视频点播请求URI的视频SDP的INVITE请求可以标记为IPTV会话。通过蜂窝网络（PoC）路由进行按键通话的INVITE请求可以标记为PoC会话。具有包含选项标记“foogame”的Require标头字段的INVITE请求可以标记为foogame会话。
NOTE: If the information contained within the SIP INVITE request is not sufficient to uniquely identify a service, the remedy is to extend the SIP signaling to capture the missing element. RFC 5897 [RFC5897] provides further explanation.
注意：如果SIP INVITE请求中包含的信息不足以唯一标识服务，那么补救方法是扩展SIP信令以捕获缺少的元素。RFC 5897[RFC5897]提供了进一步的解释。
By providing a mechanism to compute and store the results of the domain-specific service calculation, i.e., the derived service identification, this optimization allows a single trusted proxy to perform an analysis of the request and authorize the requestor's permission to request such a service. The proxy may then include a service identifier that relieves other trusted proxies and trusted UAs from performing further duplicate analysis of the request for their service identification purposes. In addition, this extension allows user agent clients outside the trust domain to provide a hint of the requested service.
通过提供一种机制来计算和存储特定于域的服务计算的结果，即派生的服务标识，该优化允许单个可信代理对请求执行分析，并授权请求者请求此类服务的权限。然后，代理可以包括服务标识符，该服务标识符免除其他受信任代理和受信任ua为其服务标识目的对请求执行进一步的重复分析。此外，此扩展允许信任域之外的用户代理客户端提供请求服务的提示。
This extension does not provide for the dialog or transaction to be rejected if the service is not supported end-to-end. SIP provides other mechanisms, such as the option-tag and use of the Require and Proxy-Require header fields, where such functionality is required. No explicitly signaled service identification exists, and the session proceeds for each node's definition of the service in use, on the basis of information contained in the SDP and in other SIP header fields.
如果不支持端到端服务，此扩展不允许拒绝对话框或事务。SIP提供了其他机制，如选项标记以及Require和Proxy Require头字段的使用，其中需要此类功能。不存在显式发信号的服务标识，会话根据SDP和其他SIP报头字段中包含的信息，针对每个节点所使用服务的定义进行。
This mechanism is specifically for managing the information needs of intermediate routing devices between the calling user and the user represented by the Request-URI. In support of this mechanism, a URN is defined to identify the services. This URN has wider applicability to additionally identify services and terminal applications. Between end users, caller preferences and callee capabilities as specified in RFC 3840 [RFC3840] and RFC 3841 [RFC3841] provide an appropriate mechanism for indicating such service and application identification. These mechanisms have been extended by RFC 5688 [RFC5688] to provide further capabilities in this area.
该机制专门用于管理呼叫用户和由请求URI表示的用户之间的中间路由设备的信息需求。为了支持这种机制，定义了一个URN来标识服务。此URN具有更广泛的适用性，可额外识别服务和终端应用程序。在最终用户之间，RFC 3840[RFC3840]和RFC 3841[RFC3841]中规定的呼叫者首选项和被呼叫者功能提供了指示此类服务和应用程序标识的适当机制。RFC 5688[RFC5688]对这些机制进行了扩展，以在该领域提供进一步的功能。
The mechanism proposed in this document relies on a new header field called 'P-Asserted-Service' that contains a URN. This is supported by a further new header field called 'P-Preferred-Service' that also contains a URN and that allows the UA to express preferences regarding the decisions made on service within the trust domain.
本文档中提出的机制依赖于一个名为“P-Asserted-Service”的新标题字段，该字段包含一个URN。这由另一个名为“P-Preferred-Service”的新标题字段支持，该字段还包含一个URN，并允许UA表示有关信任域内服务决策的首选项。
An example of the P-Asserted-Service header field is:
P-Asserted-Service报头字段的示例如下：
P-Asserted-Service: urn:urn-7:3gpp-service.exampletelephony.version1
P-Asserted-Service: urn:urn-7:3gpp-service.exampletelephony.version1
A proxy server that handles a request can, after authenticating the originating user in some way (for example: digest authentication) to ensure that the user is entitled to that service, insert such a P-Asserted-Service header field into the request and forward it to
处理请求的代理服务器可以在以某种方式对发起用户进行身份验证（例如：摘要身份验证）以确保用户有权使用该服务后，将这样一个P-Asserted-service报头字段插入请求并将其转发给
other trusted proxies. A proxy that is about to forward a request to a proxy server or UA that it does not trust removes all the P-Asserted-Service header field values.
其他受信任的代理。即将向其不信任的代理服务器或UA转发请求的代理将删除所有P-Asserted-Service标头字段值。
This document labels services by means of an informal URN. This provides a hierarchical structure for defining services and subservices, and provides an address that can be resolvable for various purposes outside the scope of this document, e.g., to obtain information about the service so described.
本文档通过非正式URN为服务添加标签。这提供了用于定义服务和子服务的层次结构，并提供了一个地址，该地址可用于本文档范围之外的各种目的，例如，获取有关所述服务的信息。
This document describes private extensions to SIP (see RFC 3261 [RFC3261]) that enable a network of trusted SIP servers to assert the service of end users or end systems. The use of these extensions is only applicable inside a 'trust domain' as defined in "Short Term Requirements for Network Asserted Identity" (see RFC 3324 [RFC3324]). Nodes in such a trust domain are explicitly trusted by its users and end systems to publicly assert the service of each party, and that they have common and agreed-upon definitions of services and homogeneous service offerings. The means by which the network determines the service to assert is outside the scope of this document (though it commonly entails some form of authentication).
本文档描述了SIP的专用扩展（参见RFC 3261[RFC3261]），该扩展使可信SIP服务器网络能够断言最终用户或最终系统的服务。这些扩展的使用仅适用于“网络断言标识的短期要求”中定义的“信任域”（参见RFC 3324[RFC3324]）。此类信任域中的节点受到其用户和终端系统的明确信任，以公开声明各方的服务，并且它们具有共同且一致的服务和同类服务产品定义。网络确定要断言的服务的方法不在本文档的范围内（尽管它通常需要某种形式的身份验证）。
The mechanism for defining a trust domain is to provide a certain set of specifications known as 'Spec(T)', and then specify compliance to that set of specifications. Spec(T) MUST specify behavior as documented in RFC 3324 [RFC3324].
定义信任域的机制是提供称为“Spec（T）”的特定规范集，然后指定对该规范集的遵从性。规范（T）必须规定RFC 3324[RFC3324]中记录的行为。
This document does NOT offer a general service model suitable for inter-domain use or use in the Internet at large. Its assumptions about the trust relationship between the user and the network may not apply in many applications. For example, these extensions do not accommodate a model whereby end users can independently assert their service by use of the extensions defined here. End users assert their service by including the SIP and SDP parameters that correspond to the service they require. Furthermore, since the asserted services are not cryptographically certified, they are subject to forgery, replay, and falsification in any architecture that does not meet the requirements of RFC 3324 [RFC3324].
本文档不提供适用于域间使用或在Internet中广泛使用的通用服务模型。它关于用户和网络之间信任关系的假设可能不适用于许多应用程序。例如，这些扩展不适应最终用户可以通过使用此处定义的扩展独立断言其服务的模型。最终用户通过包含与其所需服务相对应的SIP和SDP参数来维护其服务。此外，由于断言的服务未经加密认证，因此在任何不符合RFC 3324[RFC3324]要求的体系结构中，它们都会受到伪造、重播和伪造的影响。
The asserted services also lack an indication of who specifically is asserting the service, and so it must be assumed that a member of the trust domain is asserting the service. Therefore, the information is only meaningful when securely received from a node known to be a member of the trust domain.
断言的服务也没有明确表示谁在断言服务，因此必须假定信任域的一个成员正在断言服务。因此，只有从已知为信任域成员的节点安全地接收信息时，信息才有意义。
Despite these limitations, there are sufficiently useful specialized deployments, that meet the assumptions described above and can accept the limitations that result, to warrant informational publication of this mechanism.
尽管存在这些限制，但仍有足够有用的专门部署，这些部署满足上述假设，并且可以接受由此产生的限制，以保证该机制的信息发布。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
Throughout this document, requirements for or references to proxy servers or proxy behavior apply similarly to other intermediaries within a trust domain (for example, back-to-back user agents (B2BUAs)).
在本文档中，对代理服务器或代理行为的要求或引用同样适用于信任域中的其他中介机构（例如，背靠背用户代理（B2BUA））。
The term trust domain in this document has the meaning as defined in RFC 3324 [RFC3324].
本文件中的术语“信任域”具有RFC 3324[RFC3324]中定义的含义。
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 5234 [RFC5234].
以下语法规范使用RFC 5234[RFC5234]中所述的增广巴科斯诺尔形式（BNF）。
The P-Asserted-Service header field is used among trusted SIP entities (typically intermediaries) to carry the service information of the user sending a SIP message.
P-Asserted-Service报头字段在受信任的SIP实体（通常是中介）之间使用，以携带发送SIP消息的用户的服务信息。
The P-Asserted-Service header field carries information that is derived service identification. While a declarative service identification can assist in deriving the value transferred in this header field, this should be in the form of streamlining the correct derived service identification.
P-Asserted-Service报头字段携带从服务标识派生的信息。虽然声明性服务标识有助于派生此标头字段中传输的值，但这应该以简化正确的派生服务标识的形式出现。
PAssertedService = "P-Asserted-Service" HCOLON PAssertedService-value
PAssertedService=“P-Asserted-Service”HCOLON PAssertedService值
PAssertedService-value = Service-ID *(COMMA Service-ID)
PAssertedService值=服务ID*（逗号服务ID）
See Section 4.4 for the definition of Service-ID in ABNF.
ABNF中服务ID的定义见第4.4节。
Proxies can (and will) add and remove this header field.
代理可以（并且将）添加和删除此标题字段。
Table 1 adds the header fields defined in this document to Table 2 in SIP [RFC3261], Section 7.1 of the SIP-specific event notification [RFC3265], Tables 1 and 2 in the SIP INFO method [RFC2976], Tables 1 and 2 in the reliability of provisional responses in SIP [RFC3262], Tables 1 and 2 in the SIP UPDATE method [RFC3311], Tables 1 and 2 in the SIP extension for instant messaging [RFC3428], Table 1 in the SIP REFER method [RFC3515], and Tables 2 and 3 in the SIP PUBLISH method [RFC3903]:
表1将本文件中定义的标题字段添加到SIP[RFC3261]中的表2、SIP特定事件通知[RFC3265]第7.1节、SIP信息方法[RFC2976]中的表1和表2、SIP[RFC3262]中临时响应可靠性中的表1和表2、SIP更新方法[RFC3311]中的表1和表2中，即时消息[RFC3428]SIP扩展中的表1和表2、SIP参考方法[RFC3515]中的表1以及SIP发布方法[RFC3903]中的表2和表3：
Header field where proxy ACK BYE CAN INV OPT REG SUB
_______________________________________________________________
P-Asserted-Service R admr - - - o o - o
Header field where proxy ACK BYE CAN INV OPT REG SUB
_______________________________________________________________
P-Asserted-Service R admr - - - o o - o
Header field NOT PRA INF UPD MSG REF PUB
_______________________________________________________________
P-Asserted-Service - - - - o o o
Header field NOT PRA INF UPD MSG REF PUB
_______________________________________________________________
P-Asserted-Service - - - - o o o
Table 1
表1
Syntactically, there may be multiple P-Asserted-Service header fields in a request. The semantics of multiple P-Asserted-Service header fields appearing in the same request is not defined at this time. Implementations of this specification MUST provide only one P-Asserted-Service header field value.
在语法上，一个请求中可能有多个P-Asserted-Service报头字段。此时未定义出现在同一请求中的多个P-Asserted-Service头字段的语义。此规范的实现必须只提供一个P-Asserted-Service标头字段值。
The P-Preferred-Service header field is used by a user agent sending the SIP request to provide a hint to a trusted proxy of the preferred service that the user wishes to be used for the P-Asserted-Service field value that the trusted element will insert.
P-Preferred-Service报头字段由发送SIP请求的用户代理使用，以向首选服务的受信任代理提供用户希望用于受信任元素将插入的P-Asserted-Service字段值的提示。
The P-Preferred-Service header field carries information that is declarative service identification. Such information should only be used to assist in deriving a derived service identification at the recipient entity.
P-Preferred-Service标头字段包含声明性服务标识的信息。此类信息应仅用于帮助在接收方实体获得衍生服务标识。
PPreferredService = "P-Preferred-Service" HCOLON PPreferredService-value
PPreferredService=“P-Preferred-Service”HCOLON PPreferredService值
PPreferredService-value = Service-ID *(COMMA Service-ID)
PPreferredService值=服务ID*（逗号服务ID）
See Section 4.4 for the definition of Service-ID in ABNF.
ABNF中服务ID的定义见第4.4节。
Table 2 adds the header fields defined in this document to Table 2 in SIP [RFC3261], Section 7.1 of the SIP-specific event notification [RFC3265], Tables 1 and 2 in the SIP INFO method [RFC2976], Tables 1 and 2 in Reliability of provisional responses in SIP [RFC3262],
表2将本文件中定义的标题字段添加到SIP[RFC3261]中的表2、SIP特定事件通知[RFC3265]第7.1节、SIP信息方法[RFC2976]中的表1和表2、SIP[RFC3262]中临时响应可靠性中的表1和表2中，
Tables 1 and 2 in the SIP UPDATE method [RFC3311], Tables 1 and 2 in the SIP extension for Instant Messaging [RFC3428], Table 1 in the SIP REFER method [RFC3515], and Tables 2 and 3 in the SIP PUBLISH method [RFC3903]:
SIP更新方法[RFC3311]中的表1和表2、即时消息传递SIP扩展[RFC3428]中的表1和表2、SIP参考方法[RFC3515]中的表1以及SIP发布方法[RFC3903]中的表2和表3：
Header field where proxy ACK BYE CAN INV OPT REG SUB
_______________________________________________________________
P-Preferred-Service R dr - - - o o - o
Header field where proxy ACK BYE CAN INV OPT REG SUB
_______________________________________________________________
P-Preferred-Service R dr - - - o o - o
Header field NOT PRA INF UPD MSG REF PUB
_______________________________________________________________
P-Preferred-Service - - - - o o o
Header field NOT PRA INF UPD MSG REF PUB
_______________________________________________________________
P-Preferred-Service - - - - o o o
Table 2
表2
Syntactically, there may be multiple P-Preferred-Service header fields in a request. The semantics of multiple P-Preferred-Service header fields appearing in the same request is not defined at this time. Implementations of this specification MUST only provide one P-Preferred-Service header field value.
从语法上讲，一个请求中可能有多个P首选服务头字段。此时未定义出现在同一请求中的多个P-Preferred-Service头字段的语义。本规范的实现必须只提供一个P-Preferred-Service头字段值。
Service definitions and characteristics are outside the scope of this document. Other standards organizations, vendors, and operators may define their own services and register them.
服务定义和特征不在本文档的范围内。其他标准组织、供应商和运营商可以定义自己的服务并进行注册。
A hierarchical structure is defined consisting of service identifiers or application identifiers, and subservice identifiers.
层次结构由服务标识符或应用程序标识符以及子服务标识符组成。
The service and subservice identifiers are as described in Section 1. The URN may also be used to identify a service or an application between end users for use within the context of RFC 3840 [RFC3840] and RFC 3841 [RFC3841].
服务和子服务标识符如第1节所述。URN还可用于识别最终用户之间的服务或应用程序，以便在RFC 3840[RFC3840]和RFC 3841[RFC3841]的上下文中使用。
IANA maintains a registry of service identifier values that have been assigned. This registry has been created by the actions of Section 8.2 of this document.
IANA维护已分配的服务标识符值的注册表。此注册表是根据本文件第8.2节的操作创建的。
subservice identifiers are not managed by IANA. It is the responsibility of the organization that registered the service to manage the subservices.
IANA不管理子服务标识符。注册服务的组织有责任管理子服务。
Below, we include the registration template for the URN scheme according to RFC 3406 [RFC3406]. The URN scheme is defined as an informal Namespace ID (NID).
下面，我们根据RFC 3406[RFC3406]包括URN方案的注册模板。URN方案被定义为非正式名称空间ID（NID）。
Namespace ID: urn-7
命名空间ID:urn-7
Registration Information:
Registration version: 1; registration date: 2009-03-22
Registration Information:
Registration version: 1; registration date: 2009-03-22
Declared registrant of the namespace: 3GPP Specifications Manager (3gppContact@etsi.org) (+33 (0)492944200)
名称空间的声明注册人：3GPP规范管理器(3gppContact@etsi.org) (+33 (0)492944200)
Declaration of syntactic structure: The URN consists of a hierarchical service identifier or application identifier, with a sequence of labels separated by periods. The leftmost label is the most significant one and is called 'top-level service identifier', while names to the right are called 'subservices' or 'sub-applications'. The set of allowable characters is the same as that for domain names (see RFC 1123 [RFC1123]) and a subset of the labels allowed in RFC 3958 [RFC3958]. Labels are case-insensitive and MUST be specified in all lowercase. For any given service identifier, labels can be removed right-to-left and the resulting URN is still valid, referring a more generic service, with the exception of the top-level service identifier and possibly the first subservice or sub-application identifier. Labels cannot be removed beyond a defined basic service; for example, the label w.x may define a service, but the label w may only define an assignment authority for assigning subsequent values and not define a service in its own right. In other words, if a service identifier 'w.x.y.z' exists, the URNs 'w.x' and 'w.x.y' are also valid service identifiers, but w may not be a valid service identifier if it merely defines who is responsible for defining x.
语法结构声明：URN由分层服务标识符或应用程序标识符组成，带有一系列由句点分隔的标签。最左边的标签是最重要的标签，称为“顶级服务标识符”，而右边的名称称为“子服务”或“子应用程序”。允许的字符集与域名相同（参见RFC 1123[RFC1123]），并且是RFC 3958[RFC3958]中允许的标签子集。标签不区分大小写，必须以所有小写字母指定。对于任何给定的服务标识符，标签可以从右到左移除，得到的URN仍然有效，引用的是更通用的服务，顶层服务标识符和第一个子服务或子应用程序标识符除外。标签不能在定义的基本服务之外移除；例如，标签w.x可以定义服务，但标签w可以仅定义用于分配后续值的分配机构，而不能自行定义服务。换句话说，如果服务标识符“w.x.y.z”存在，则URN“w.x”和“w.x.y”也是有效的服务标识符，但如果w仅定义了谁负责定义x，则w可能不是有效的服务标识符。
Service-ID = "urn:urn-7:" urn-service-id
urn-service-id = top-level *("." sub-service-id)
top-level = let-dig [ *26let-dig ]
sub-service-id = let-dig [ *let-dig ]
let-dig = ALPHA / DIGIT / "-"
Service-ID = "urn:urn-7:" urn-service-id
urn-service-id = top-level *("." sub-service-id)
top-level = let-dig [ *26let-dig ]
sub-service-id = let-dig [ *let-dig ]
let-dig = ALPHA / DIGIT / "-"
While the naming convention above uses the term "service", all the constructs are equally applicable to identifying applications within the UA.
尽管上述命名约定使用术语“服务”，但所有构造都同样适用于标识UA中的应用程序。
Relevant ancillary documentation: None
相关辅助文件：无
Identifier uniqueness considerations: A service identifier identifies a service, and an application identifier an application indicated in the service or application registration (see IANA Considerations (Section 8)). Uniqueness is guaranteed by the IANA registration.
标识符唯一性注意事项：服务标识符标识服务，应用标识符标识服务或应用程序注册中指示的应用程序（参见IANA注意事项（第8节））。IANA注册保证了唯一性。
Identifier persistence considerations: The service or application identifier for the same service or application is expected to be persistent, although there naturally cannot be a guarantee that a particular service will continue to be available globally or at all times.
标识符持久性注意事项：同一服务或应用程序的服务或应用程序标识符预期是持久的，尽管自然不能保证特定服务将在全局或任何时候继续可用。
Process of identifier assignment: The process of identifier assignment is described in the IANA Considerations (Section 8).
标识符分配过程：IANA注意事项（第8节）中描述了标识符分配过程。
Process for identifier resolution: There is no single global resolution service for service identifiers or application identifiers.
标识符解析过程：服务标识符或应用程序标识符没有单一的全局解析服务。
Rules for lexical equivalence: 'service' identifiers are compared according to case-insensitive string equality.
词汇等价规则：“服务”标识符根据不区分大小写的字符串相等性进行比较。
Conformance with URN syntax: The BNF in the 'Declaration of syntactic structure' above constrains the syntax for this URN scheme.
与URN语法的一致性：上述“语法结构声明”中的BNF限制了此URN方案的语法。
Validation mechanism: Validation determines whether a given string is currently a validly assigned URN (see RFC 3406 [RFC3406]). Due to the distributed nature of usage and since not all services are available everywhere, validation in this sense is not possible.
验证机制：验证确定给定字符串当前是否为有效分配的URN（请参阅RFC 3406[RFC3406]）。由于使用的分布式性质，而且并非所有服务都在任何地方都可用，因此不可能进行这种意义上的验证。
Scope: The scope for this URN can be local to a single domain, or may be more widely used.
作用域：此URN的作用域可以是单个域的本地作用域，也可以更广泛地使用。
5. Usage of the P-Preferred-Service and P-Asserted-Service Header Fields
5. P-Preferred-Service和P-Asserted-Service头字段的使用
5.1. Usage of the P-Preferred-Service and P-Asserted-Service Header Fields in Requests
5.1. 在请求中使用P-Preferred-Service和P-Asserted-Service头字段
The UAC MAY insert a P-Preferred-Service in a request that creates a dialog, or a request outside of a dialog. This information can assist the proxies in identifying appropriate service capabilities to apply to the call. This information MUST NOT conflict with other SIP or SDP information included in the request. Furthermore, the SIP or SDP information needed to signal functionality of this service MUST be present. Thus, if a service requires a video component, then the SDP has to include the media line associated with that video component; it cannot be assumed from the P-Preferred-Service header field value. Similarly, if the service requires particular SIP
UAC可以在创建对话框的请求或对话框外部的请求中插入P首选服务。此信息可帮助代理识别适用于呼叫的适当服务功能。此信息不得与请求中包含的其他SIP或SDP信息冲突。此外，必须存在表示此服务功能所需的SIP或SDP信息。因此，如果服务需要视频组件，则SDP必须包括与该视频组件相关联的媒体线；不能从P-Preferred-Service标头字段值中假定它。类似地，如果服务需要特定的SIP
functionality for which a SIP extension and a Require header field value is defined, then the request has to include that SIP signaling as well as the P-Preferred-Service header field value.
为其定义SIP扩展和Require报头字段值的功能，则请求必须包括该SIP信令以及P-Preferred-Service报头字段值。
A UAC that is within the same trust domain as the proxy to which it sends a request (e.g., a media gateway or application server) MAY insert a P-Asserted-Service header field in a request that creates a dialog, or a request outside of a dialog. This information MUST NOT conflict with other SIP or SDP information included in the request. Furthermore, the SIP or SDP information needed to signal functionality of this service MUST be present.
与向其发送请求的代理（例如，媒体网关或应用服务器）位于同一信任域内的UAC可以在创建对话框的请求中插入P-Asserted-Service标头字段，或在对话框外部插入请求。此信息不得与请求中包含的其他SIP或SDP信息冲突。此外，必须存在表示此服务功能所需的SIP或SDP信息。
A proxy in a trust domain can receive a request from a node that it trusts or a node that it does not trust. When a proxy receives a request from a node it does not trust and it wishes to add a P-Asserted-Service header field, the proxy MUST identify the service appropriate to the capabilities (e.g., SDP) in the request, MAY authenticate the originator of the request (in order to determine whether the user is subscribed for that service). Where the originator of the request is authenticated, the proxy MUST use the identity that results from this checking and authentication to insert a P-Asserted-Service header field into the request.
信任域中的代理可以接收来自其信任的节点或不信任的节点的请求。当代理从其不信任的节点接收到请求并且希望添加P-Asserted-Service报头字段时，代理必须识别与请求中的功能（例如，SDP）相适应的服务，可以认证请求的发起人（以确定用户是否订阅了该服务）。在对请求的发起人进行身份验证的情况下，代理必须使用此检查和身份验证所产生的标识将P-Asserted-Service标头字段插入到请求中。
When a proxy receives a request containing a P-Preferred-Service header field, the Proxy MAY use the contents of that header field to assist in determining the service to be included in a P-Asserted-Service header field (for instance, to prioritize the order of comparison of filter criteria for potential services that the request could match). The proxy MUST NOT use the contents of the P-Preferred-Service header field to identify the service without first checking against the capabilities (e.g., SDP) contained in the request. If the proxy inserts a P-Asserted-Service header field in the request, the proxy MUST remove the P-Preferred-Service header field before forwarding the request; otherwise, the Proxy SHOULD include the P-Preferred-Service header field when forwarding the request.
当代理接收到包含P-Preferred-Service报头字段的请求时，代理可以使用该报头字段的内容来帮助确定要包括在P-Asserted-Service报头字段中的服务（例如，对请求可能匹配的潜在服务的过滤标准的比较顺序进行优先级排序）。在未首先检查请求中包含的功能（例如SDP）之前，代理不得使用P-Preferred-Service标头字段的内容来标识服务。如果代理在请求中插入P-Asserted-Service头字段，则代理必须在转发请求之前删除P-Preferred-Service头字段；否则，在转发请求时，代理应该包括P-Preferred-Service头字段。
If the proxy receives a request from a node that it trusts, it can use the information in the P-Asserted-Service header field, if any, as if it had authenticated the user itself.
如果代理收到来自其信任的节点的请求，它可以使用P-Asserted-Service报头字段中的信息（如果有），就像它已经验证了用户本身一样。
If there is no P-Asserted-Service header field present, or it is not possible to match the request to a specific service as identified by the service identifier, a proxy MAY add one containing it using its own analysis of the information contained in the SIP request. If the proxy received the request from an element that it does not trust and
如果不存在P-Asserted-Service报头字段，或者无法将请求与由服务标识符标识的特定服务相匹配，则代理可以使用其自身对SIP请求中包含的信息的分析来添加包含该请求的服务。如果代理收到来自其不信任的元素的请求，并且
there is a P-Asserted-Service header present, the proxy MUST replace that header field's contents with a new analysis or remove that header field.
存在P-Asserted-Service标头，代理必须用新的分析替换该标头字段的内容，或删除该标头字段。
The analysis performed to identify such service identifiers is outside the scope of this document. However, it is perfectly valid as a result of the analysis not to include any service identifier in the forwarded request, and thus not include a P-Asserted-Service header field.
为识别此类服务标识符而进行的分析不在本文档的范围内。然而，作为分析的结果，在转发的请求中不包括任何服务标识符是完全有效的，因此不包括P-Asserted-service报头字段。
If a proxy forwards a request to a node outside the proxy's trust domain, there MUST NOT be a P-Asserted-Service header field in the forwarded request.
如果代理将请求转发到代理的信任域之外的节点，则转发的请求中不得有P-Asserted-Service头字段。
For a User Agent Server (UAS) outside the trust domain, the P-Asserted-Service header is removed before it reaches this entity; therefore, there are no procedures for such a device.
对于信任域之外的用户代理服务器（UAS），P-Asserted-Service头在到达该实体之前被删除；因此，没有针对此类装置的程序。
However, if a UAS receives a request from a previous element that it does not trust, it MUST NOT use the P-Asserted-Service header field in any way.
但是，如果UAS接收到来自其不信任的前一个元素的请求，则它不得以任何方式使用P-Asserted-Service头字段。
If a UA is part of the trust domain from which it received a request containing a P-Asserted-Service header field, then it can use the value freely, but it MUST ensure that it does not forward the information to any element that is not part of the trust domain.
如果UA是信任域的一部分，它从该信任域接收到包含P-Asserted-Service标头字段的请求，那么它可以自由使用该值，但它必须确保它不会将信息转发到不属于信任域的任何元素。
5.2. Usage of the P-Preferred-Service and P-Asserted-Service Header Fields in Responses
5.2. 在响应中使用P-Preferred-Service和P-Asserted-Service头字段
There is no usage of these header fields in responses.
在响应中不使用这些标题字段。
In this example, proxy.example.com creates a P-Asserted-Service header field from the user identity it discovered from SIP digest authentication, the list of services appropriate to that user, and the services that correspond to the SDP information included in the request. Note that F1 and F2 are about identifying the user and do not directly form part of the capability provided in this document. It forwards this information to a trusted proxy that forwards it to a trusted gateway. Note that these examples consist of partial SIP messages that illustrate only those header fields relevant to the authenticated identity problem.
在本例中，proxy.example.com根据从SIP摘要身份验证中发现的用户标识、适合该用户的服务列表以及与请求中包含的SDP信息相对应的服务创建一个P-Asserted-Service头字段。请注意，F1和F2是关于识别用户的，并不直接构成本文档中提供的功能的一部分。它将此信息转发给受信任的代理，该代理将其转发给受信任的网关。请注意，这些示例包括部分SIP消息，这些消息仅说明与身份验证问题相关的那些头字段。
* F1 useragent.example.com -> proxy.example.com
* F1 useragent.example.com->proxy.example.com
INVITE sip:+14085551212@example.com SIP/2.0
Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-123
To: <sip:+14085551212@example.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1 INVITE
Max-Forwards: 70
INVITE sip:+14085551212@example.com SIP/2.0
Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-123
To: <sip:+14085551212@example.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1 INVITE
Max-Forwards: 70
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=audio 3456 RTP/AVPF 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=audio 3456 RTP/AVPF 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes
* F2 proxy.example.com -> useragent.example.com
* F2 proxy.example.com->useragent.example.com
SIP/2.0 407 Proxy Authorization
Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-123
To: <sip:+14085551212@example.com>;tag=123456
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1 INVITE
Proxy-Authenticate: .... realm="sip.example.com"
SIP/2.0 407 Proxy Authorization
Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-123
To: <sip:+14085551212@example.com>;tag=123456
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1 INVITE
Proxy-Authenticate: .... realm="sip.example.com"
* F3 useragent.example.com -> proxy.example.com
* F3 useragent.example.com->proxy.example.com
INVITE sip:+14085551212@example.com SIP/2.0
Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-124
To: <sip:+14085551212@example.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 70
Proxy-Authorization: realm="sip.example.com" user="fluffy"
INVITE sip:+14085551212@example.com SIP/2.0
Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-124
To: <sip:+14085551212@example.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 70
Proxy-Authorization: realm="sip.example.com" user="fluffy"
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=audio 3456 RTP/AVPF 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=audio 3456 RTP/AVPF 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes
* F4 proxy.example.com -> proxy.pstn.example (trusted)
* F4 proxy.example.com->proxy.pstn.example（受信任）
INVITE sip:+14085551212@proxy. pstn.example SIP/2.0
Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-124
Via: SIP/2.0/TCP proxy.example.com;branch=z9hG4bK-abc
To: <sip:+14085551212@example.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 69
P-Asserted-Service: urn:urn-7:3gpp-service.exampletelephony.version1
INVITE sip:+14085551212@proxy. pstn.example SIP/2.0
Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-124
Via: SIP/2.0/TCP proxy.example.com;branch=z9hG4bK-abc
To: <sip:+14085551212@example.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 69
P-Asserted-Service: urn:urn-7:3gpp-service.exampletelephony.version1
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=audio 3456 RTP/AVPF 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=audio 3456 RTP/AVPF 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes
* F5 proxy.pstn.example -> gw.pstn.example (trusted)
* F5 proxy.pstn.example->gw.pstn.example（受信任）
INVITE sip:+14085551212@gw.pstn.example SIP/2.0
Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-124
Via: SIP/2.0/TCP proxy.example.com;branch=z9hG4bK-abc
Via: SIP/2.0/TCP proxy.pstn.example;branch=z9hG4bK-a1b2
To: <sip:+14085551212@example.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 68
P-Asserted-Service: urn:urn-7:3gpp-service.exampletelephony.version1
INVITE sip:+14085551212@gw.pstn.example SIP/2.0
Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-124
Via: SIP/2.0/TCP proxy.example.com;branch=z9hG4bK-abc
Via: SIP/2.0/TCP proxy.pstn.example;branch=z9hG4bK-a1b2
To: <sip:+14085551212@example.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 68
P-Asserted-Service: urn:urn-7:3gpp-service.exampletelephony.version1
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=audio 3456 RTP/AVPF 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=audio 3456 RTP/AVPF 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes
The mechanism provided in this document is a partial consideration of the problem of service identification in SIP. For example, these mechanisms provide no means by which end users can securely share service information end-to-end without a trusted service provider. This information is secured by transitive trust, which is only as reliable as the weakest link in the chain of trust.
本文档中提供的机制部分考虑了SIP中的服务标识问题。例如，这些机制无法提供终端用户在没有可信服务提供商的情况下安全地端到端共享服务信息的方法。此信息由传递信任保护，传递信任仅与信任链中最薄弱的环节一样可靠。
The trust domain provides a set of servers where the characteristics of the service are agreed for that service identifier value, and where the calling user is entitled to use that service. RFC 5897 [RFC5897] identifies the impact of allowing such service identifier values to "leak" outside of the trust domain, including implications on fraud, interoperability, and stifling of service innovation.
信任域提供了一组服务器，在这些服务器中，服务的特征与该服务标识符值一致，并且呼叫用户有权使用该服务。RFC 5897[RFC5897]确定了允许此类服务标识符值“泄漏”到信任域之外的影响，包括对欺诈、互操作性和扼杀服务创新的影响。
This document specifies two new SIP header fields: P-Asserted-Service and P-Preferred-Service. Their syntax is given in Section 3. These header fields are defined by the following information, which has been added to the header sub-registry under http://www.iana.org.
本文档指定了两个新的SIP头字段：P-Asserted-Service和P-Preferred-Service。第3节给出了它们的语法。这些标头字段由以下信息定义，这些信息已添加到下的标头子注册表中http://www.iana.org.
Header Name compact Reference
----------------- ------- ---------
P-Asserted-Service RFC 6050
P-Preferred-Service RFC 6050
Header Name compact Reference
----------------- ------- ---------
P-Asserted-Service RFC 6050
P-Preferred-Service RFC 6050
Top-level identifiers are identified by labels managed by IANA, according to the processes outlined in RFC 5226 [RFC5226], in a new registry called "Service-ID/Application-ID Labels". Thus, creating a new service at the top-level requires IANA action. The policy for adding service labels is 'specification required'. The following two identifiers are initially defined:
顶级标识符由IANA管理的标签标识，根据RFC 5226[RFC5226]中概述的流程，在一个名为“服务ID/应用程序ID标签”的新注册表中。因此，在顶级创建新服务需要IANA操作。添加服务标签的策略为“需要规范”。最初定义了以下两个标识符：
3gpp-service
3gpp服务
3gpp-application
3gpp应用
subservice identifiers are not managed by IANA. It is the responsibility of the organization that registered the service to manage the subservices.
IANA不管理子服务标识符。注册服务的组织有责任管理子服务。
Application identifiers are not managed by IANA. It is the responsibility of the organization that registered the service to manage the applicable applications.
应用程序标识符不由IANA管理。注册服务的组织负责管理适用的应用程序。
Entries in the registration table have the following format:
注册表中的条目具有以下格式：
Service/Application Description Reference
--------------------------------------------------------------------
3gpp-service Communication services defined by RFC 6050
3GPP for use by the IM CN subsystem
and its attached UAs. This value
in itself does not define a service
and requires subsequent labels to
define the service.
Service/Application Description Reference
--------------------------------------------------------------------
3gpp-service Communication services defined by RFC 6050
3GPP for use by the IM CN subsystem
and its attached UAs. This value
in itself does not define a service
and requires subsequent labels to
define the service.
3gpp-application Applications defined by 3GPP for RFC 6050 use by UAs attached to the IM CN subsystem. This value in itself does not define a service and requires subsequent labels to define the service.
3gpp为连接到IM CN子系统的UAs使用RFC 6050定义的3gpp应用程序。此值本身并不定义服务，需要后续标签来定义服务。
Here, the IM CN subsystem stands for the IP Multimedia Core Network subsystem.
这里，IM-CN子系统代表IP多媒体核心网络子系统。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]Braden，R.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
[RFC3324]Watson，M.，“网络断言身份的短期要求”，RFC 33242002年11月。
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002.
[RFC3406]Daigle，L.，van Gulik，D.，Iannella，R.，和P.Faltstrom，“统一资源名称（URN）命名空间定义机制”，BCP 66，RFC 3406，2002年10月。
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC3958]Daigle，L.和A.Newton，“使用SRV RRs和动态委托发现服务（DDDS）的基于域的应用程序服务定位”，RFC 3958，2005年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[RFC2976]Donovan，S.，“SIP信息方法”，RFC 29762000年10月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）中临时响应的可靠性”，RFC 32622，2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311]Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年10月。
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428]Campbell，B.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.，和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 34282002年12月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]Sparks，R.，“会话启动协议（SIP）引用方法”，RFC3515，2003年4月。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[RFC3841]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“会话启动协议（SIP）的呼叫方偏好”，RFC 38412004年8月。
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[RFC3903]Niemi，A.，“事件状态发布的会话启动协议（SIP）扩展”，RFC 3903，2004年10月。
[RFC5688] Rosenberg, J., "A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes", RFC 5688, January 2010.
[RFC5688]Rosenberg，J.，“MIME应用程序子类型的会话启动协议（SIP）媒体功能标签”，RFC 5688，2010年1月。
[RFC5897] Rosenberg, J., "Identification of Communications Services in the Session Initiation Protocol (SIP)", RFC 5897, June 2010.
[RFC5897]Rosenberg，J.，“会话启动协议（SIP）中通信服务的识别”，RFC 58972010年6月。
Author's Address
作者地址
Keith Drage Alcatel-Lucent Quadrant, Stonehill Green, Westlea Swindon, Wilts UK
基思·德拉吉·阿尔卡特·朗讯象限，英国威尔特郡斯温顿威斯特利亚斯通希尔格林
EMail: drage@alcatel-lucent.com
EMail: drage@alcatel-lucent.com