Internet Engineering Task Force (IETF) J. Rosenberg
Request for Comments: 5897 jdrosen.net
Category: Informational June 2010
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Rosenberg
Request for Comments: 5897 jdrosen.net
Category: Informational June 2010
ISSN: 2070-1721
Identification of Communications Services in the Session Initiation Protocol (SIP)
会话启动协议（SIP）中通信服务的标识
Abstract
摘要
This document considers the problem of service identification in the Session Initiation Protocol (SIP). Service identification is the process of determining the user-level use case that is driving the signaling being utilized by the user agent (UA). This document discusses the uses of service identification, and outlines several architectural principles behind the process. It identifies perils when service identification is not done properly -- including fraud, interoperability failures, and stifling of innovation. It then outlines a set of recommended practices for service identification.
本文档考虑会话发起协议（SIP）中的服务标识问题。服务标识是确定驱动用户代理（UA）使用的信令的用户级用例的过程。本文档讨论了服务标识的使用，并概述了流程背后的几个体系结构原则。当服务识别工作做得不好时，它会识别出风险——包括欺诈、互操作性故障和扼杀创新。然后概述了一组用于服务标识的推荐实践。
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/rfc5897.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5897.
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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须
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.
包括信托法律条款第4.e节中所述的简化BSD许可证文本，且不提供简化BSD许可证中所述的担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Services and Service Identification .............................4
3. Example Services ................................................6
3.1. IPTV vs. Multimedia ........................................6
3.2. Gaming vs. Voice Chat ......................................7
3.3. Gaming vs. Voice Chat #2 ...................................7
3.4. Configuration vs. Pager Messaging ..........................7
4. Using Service Identification ....................................8
4.1. Application Invocation in the User Agent ...................8
4.2. Application Invocation in the Network ......................9
4.3. Network Quality-of-Service Authorization ..................10
4.4. Service Authorization .....................................10
4.5. Accounting and Billing ....................................11
4.6. Negotiation of Service ....................................11
4.7. Dispatch to Devices .......................................11
5. Key Principles of Service Identification .......................12
5.1. Services Are a By-Product of Signaling ....................12
5.2. Identical Signaling Produces Identical Services ...........13
5.3. Do What I Say, Not What I Mean ............................14
5.4. Declarative Service Identifiers Are Redundant .............15
5.5. URIs Are Key for Differentiated Signaling .................15
6. Perils of Declarative Service Identification ...................16
6.1. Fraud .....................................................16
6.2. Systematic Interoperability Failures ......................17
6.3. Stifling of Service Innovation ............................18
7. Recommendations ................................................20
7.1. Use Derived Service Identification ........................20
7.2. Design for SIP's Negotiative Expressiveness ...............20
7.3. Presence ..................................................21
7.4. Intra-Domain ..............................................21
7.5. Device Dispatch ...........................................21
8. Security Considerations ........................................22
9. Acknowledgements ...............................................22
10. Informative References ........................................22
1. Introduction ....................................................3
2. Services and Service Identification .............................4
3. Example Services ................................................6
3.1. IPTV vs. Multimedia ........................................6
3.2. Gaming vs. Voice Chat ......................................7
3.3. Gaming vs. Voice Chat #2 ...................................7
3.4. Configuration vs. Pager Messaging ..........................7
4. Using Service Identification ....................................8
4.1. Application Invocation in the User Agent ...................8
4.2. Application Invocation in the Network ......................9
4.3. Network Quality-of-Service Authorization ..................10
4.4. Service Authorization .....................................10
4.5. Accounting and Billing ....................................11
4.6. Negotiation of Service ....................................11
4.7. Dispatch to Devices .......................................11
5. Key Principles of Service Identification .......................12
5.1. Services Are a By-Product of Signaling ....................12
5.2. Identical Signaling Produces Identical Services ...........13
5.3. Do What I Say, Not What I Mean ............................14
5.4. Declarative Service Identifiers Are Redundant .............15
5.5. URIs Are Key for Differentiated Signaling .................15
6. Perils of Declarative Service Identification ...................16
6.1. Fraud .....................................................16
6.2. Systematic Interoperability Failures ......................17
6.3. Stifling of Service Innovation ............................18
7. Recommendations ................................................20
7.1. Use Derived Service Identification ........................20
7.2. Design for SIP's Negotiative Expressiveness ...............20
7.3. Presence ..................................................21
7.4. Intra-Domain ..............................................21
7.5. Device Dispatch ...........................................21
8. Security Considerations ........................................22
9. Acknowledgements ...............................................22
10. Informative References ........................................22
The Session Initiation Protocol (SIP) [RFC3261] defines mechanisms for initiating and managing communications sessions between agents. SIP allows for a broad array of session types between agents. It can manage audio sessions, ranging from low-bitrate voice-only up to multi-channel high-fidelity music. It can manage video sessions, ranging from small, "talking-head" style video chat, up to high-definition multipoint video conferencing and ranging from low-bandwidth user-generated content, up to high-definition movie and TV content. SIP endpoints can be anything -- adaptors that convert an old analog telephone to Voice over IP (VoIP), dedicated hardphones, fancy hardphones with rich displays and user entry capabilities, softphones on a PC, buddy-list and presence applications on a PC, dedicated videoconferencing peripherals, and speakerphones.
会话启动协议（SIP）[RFC3261]定义了用于启动和管理代理之间通信会话的机制。SIP允许代理之间有广泛的会话类型。它可以管理音频会话，从低比特率语音到多通道高保真音乐。它可以管理视频会话，从小型的“谈话头”式视频聊天，到高清多点视频会议，从低带宽用户生成的内容，到高清电影和电视内容。SIP端点可以是任何东西——将旧的模拟电话转换为IP语音（VoIP）的适配器、专用硬电话、具有丰富显示和用户输入功能的奇特硬电话、PC上的软电话、PC上的好友列表和状态应用程序、专用视频会议外围设备和扬声器。
This breadth of applicability is SIP's greatest asset, but it also introduces numerous challenges. One of these is that, when an endpoint generates a SIP INVITE for a session, or receives one, that session can potentially be within the context of any number of different use cases and endpoint types. For example, a SIP INVITE with a single audio stream could represent a Push-To-Talk session between mobile devices, a VoIP session between softphones, or audio-based access to stored content on a server.
这种广泛的适用性是SIP最大的优势，但也带来了许多挑战。其中之一是，当端点为会话生成SIP INVITE或接收到SIP INVITE时，该会话可能位于任意数量的不同用例和端点类型的上下文中。例如，具有单个音频流的SIP INVITE可以表示移动设备之间的一键通会话、软电话之间的VoIP会话或对服务器上存储内容的基于音频的访问。
Each of these different use cases represents a different service. The service is the user-visible use case that is driving the behavior of the user agents and servers in the SIP network.
这些不同的用例中的每一个都代表不同的服务。服务是用户可见的用例，它驱动SIP网络中用户代理和服务器的行为。
The differing services possible with SIP have driven implementors and system designers to seek techniques for service identification. Service identification is the process of determining and/or signaling the specific use case that is driving the signaling being generated by a user agent. At first glance, this seems harmless and easy enough. It is tempting to define a new header, "Service-ID", for example, and have a user agent populate it with any number of well-known tokens that define what the service is. It could then be consumed for any number of purposes. A token placed into the signaling for this purpose is called a service identifier.
SIP可能提供的不同服务促使实现者和系统设计者寻求服务识别技术。服务标识是确定和/或发信号通知特定用例的过程，该特定用例驱动由用户代理生成的信号。乍一看，这似乎是无害和容易的。例如，很容易定义一个新的头文件“服务ID”，并让用户代理用任意数量的定义服务的已知标记填充它。然后，它可以被用于任何目的。为此目的而放入信令中的令牌称为服务标识符。
Service identification and service identifiers, when used properly, can be beneficial. However, when done improperly, service identification can lead to fraud, systemic interoperability failures, and a complete stifling of the innovation that SIP was meant to achieve. The purpose of this document is to describe service identification in more detail and describe how these problems arise.
如果使用得当，服务标识和服务标识符可能是有益的。然而，如果操作不当，服务识别可能会导致欺诈、系统互操作性故障，并完全扼杀SIP所要实现的创新。本文档的目的是更详细地描述服务标识，并描述这些问题是如何产生的。
Section 2 begins by defining a service and the service identification problem. Section 3 gives some concrete examples of services and why they can be challenging to identify. Section 4 explores the ways in which a service identification can be utilized within a network. Next, Section 5 discusses the key architectural principles of service identification. Section 6 describes what declarative service invocation is, and how it can lead to fraud, interoperability failures, and stifling of service innovation.
第2节首先定义服务和服务标识问题。第3节给出了一些具体的服务示例，以及为什么它们很难识别。第4节探讨了在网络中使用服务标识的方式。接下来，第5节讨论服务标识的关键体系结构原则。第6节描述了什么是声明性服务调用，以及它如何导致欺诈、互操作性失败和扼杀服务创新。
Consequently, this document concludes 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.
因此，本文得出结论，声明性服务标识（用户代理将名字对象插入到定义所需服务的消息中的过程，与明确且定义良好的协议机制分离）是有害的。
Instead of performing declarative service identification, this document recommends derived service identification, and gives several recommendations around it in Section 7:
本文档建议使用派生服务标识，而不是执行声明性服务标识，并在第7节中给出了一些相关建议：
1. The identity of a service should always be derived from the explicit signaling in the protocol messages and other contextual information, and never indicated by the user through a separate identifier placed into the message.
1. 服务的标识应该总是从协议消息和其他上下文信息中的显式信令中派生出来，并且决不能由用户通过放置在消息中的单独标识符来指示。
2. The process of service identification based on signaling messages must be designed to SIP's negotiative expressiveness, and therefore handle heterogeneity and not assume a fixed set of use cases.
2. 基于信令消息的服务识别过程必须设计为SIP的协商表达能力，因此处理异构性，而不是假设一组固定的用例。
3. Presence can help in providing URIs that can be utilized to connect to specific services, thereby creating explicit indications in the signaling that can be used to derive a service identity.
3. 存在可以帮助提供可用于连接到特定服务的uri，从而在信令中创建可用于导出服务标识的显式指示。
4. Service identities placed into signaling messages for the purposes of caching the service identity are strictly for intra-domain usage.
4. 为了缓存服务标识而放入信令消息中的服务标识严格用于域内使用。
5. Device dispatch should be based on feature tags that map to well-defined SIP extensions and capabilities. Service dispatch should not be based on abstract service identifiers.
5. 设备调度应该基于映射到定义良好的SIP扩展和功能的功能标签。服务调度不应基于抽象服务标识符。
The problem of identifying services within SIP is not a new one. The problem has been considered extensively in the context of presence. In particular, the presence data model for SIP [RFC4479] defines the concept of a service as one of the core notions that presence describes. Services are described in Section 3.3 of RFC 4479.
识别SIP中的服务并不是一个新问题。该问题已在存在的背景下得到广泛考虑。具体而言，SIP的状态数据模型[RFC4479]将服务的概念定义为状态描述的核心概念之一。RFC 4479第3.3节描述了服务。
Essentially, the service is the user-visible use case that is driving the behavior of the user agents and servers in the SIP network. Being user-visible means that there is a difference in user experience between two services that are different. That user experience can be part of the call, or outside of the call. Within a call, the user experience can be based on different media types (an audio call vs. a video chat), different content within a particular media type (stored content, such as a movie or TV session), different devices (a wireless device for "telephony" vs. a PC application for "voice chat"), different user interfaces (a buddy-list view of voice on a PC application vs. a software emulation of a hardphone), different communities that can be accessed (voice chat with other users that have the same voice chat client vs. voice communications with any endpoint on the Public Switched Telephone Network (PSTN)), or different applications that are invoked by the user (manually selecting a Push-To-Talk application from a wireless phone vs. a telephony application). Outside of a call, the difference in user experience can be a billing one (cheaper for one service than another), a notification feature for one and not another (for example, an IM that gets sent whenever a user makes a call), and so on.
本质上，服务是用户可见的用例，它驱动着SIP网络中用户代理和服务器的行为。用户可见意味着两个不同的服务在用户体验上存在差异。用户体验可以是通话的一部分，也可以是通话之外的体验。在通话中，用户体验可以基于不同的媒体类型（音频通话与视频聊天）、特定媒体类型中的不同内容（存储的内容，例如电影或电视会话）、不同的设备（用于“电话”的无线设备与用于“语音聊天”的PC应用程序）、不同的用户界面（PC应用程序上语音的好友列表视图与硬电话的软件仿真）、可访问的不同社区（与具有相同语音聊天客户端的其他用户的语音聊天与与与公共交换电话网络（PSTN）上任何端点的语音通信）或用户调用的不同应用程序（从无线电话与电话应用程序中手动选择按键通话应用程序）。在通话之外，用户体验的差异可能是计费功能（一种服务比另一种服务便宜）、通知功能（例如，用户每次通话时发送的IM）等。
In some cases, there is very little difference in the underlying technology that will support two different services, and in other cases, there are big differences. However, for the purposes of this discussion, the key definition is that two services are distinct when there is a perceived difference by the user in the two services.
在某些情况下，支持两种不同服务的底层技术差别很小，而在其他情况下，差别很大。然而，出于本讨论的目的，关键定义是，当用户在两个服务中感知到差异时，两个服务是不同的。
This leads naturally to the desire to perform service identification. Service identification is defined as the process of:
这自然会导致执行服务标识的愿望。服务标识定义为以下过程：
1. determining the underlying service that is driving a particular signaling exchange,
1. 确定驱动特定信令交换的基础服务，
2. associating that service with a service identifier, and
2. 将该服务与服务标识符关联，以及
3. attaching that moniker to a signaling message (typically a SIP INVITE).
3. 将该名字对象附加到信令消息（通常是SIP INVITE）。
Once service identification is performed, the service identifier can then be used for various purposes within the network. Service identification can be done in the endpoints, in which case the UA would insert the moniker directly into the signaling message based on its awareness of the service. Or, it can be done within a server in the network (such as a proxy), based on inspection of the SIP message, or based on hints placed into the message by the user.
一旦执行了服务标识，服务标识符就可以用于网络内的各种目的。服务标识可以在端点中完成，在这种情况下，UA将基于其对服务的感知将名字对象直接插入到信令消息中。或者，它可以在网络中的服务器（例如代理）内完成，基于对SIP消息的检查，或者基于用户放入消息中的提示。
When service identification is performed entirely by inspecting the signaling, this is called derived service identification. When it is done based on knowledge possessed only by the invoking user agent, it is called declarative service identification. Declarative service identification can only be done in user agents, by definition.
当完全通过检查信令来执行服务标识时，这称为派生服务标识。当它仅基于调用用户代理所拥有的知识进行时，称为声明性服务标识。根据定义，声明性服务标识只能在用户代理中完成。
It is very useful to consider several example services, especially ones that appear difficult to differentiate from each other. In cases where it is hard to differentiate, service identification -- and in particular, declarative service identification -- appears highly attractive (and indeed, required).
考虑几个示例服务，特别是看起来难以区分的服务是非常有用的。在难以区分的情况下，服务标识——特别是声明性服务标识——看起来非常有吸引力（实际上是必需的）。
IP Television (IPTV) is the usage of IP networks to access traditional television content, such as movies and shows. SIP can be utilized to establish a session to a media server in a network, which then serves up multimedia content and streams it as an audio and video stream towards the client. Whether SIP is ideal for IPTV is, in itself, a good question. However, such a discussion is outside the scope of this document.
IP电视（IPTV）是利用IP网络访问传统电视内容，如电影和节目。SIP可用于与网络中的媒体服务器建立会话，然后媒体服务器提供多媒体内容并将其作为音频和视频流流传输到客户端。SIP是否适合IPTV本身就是一个好问题。然而，这种讨论不在本文件的范围之内。
Consider multimedia conferencing. The user accesses a voice and video conference at a conference server. The user might join in listen-only mode, in which case the user receives audio and video streams, but does not send.
考虑多媒体会议。用户在会议服务器上访问语音和视频会议。用户可以在仅收听模式下加入，在这种情况下，用户接收音频和视频流，但不发送。
These two services -- IPTV and listen-only multimedia conferencing -- clearly appear as different services. They have different user experiences and applications. A user is unlikely to ever be confused about whether a session is IPTV or listen-only multimedia conferencing. Indeed, they are likely to have different software applications or endpoints for the two services.
这两种服务——IPTV和只听多媒体会议——显然是不同的服务。他们有不同的用户体验和应用程序。用户不太可能对会话是IPTV还是只听多媒体会议感到困惑。事实上，这两个服务可能有不同的软件应用程序或端点。
However, these two services look remarkably alike based on the signaling. Both utilize audio and video. Both could utilize the same codecs. Both are unidirectional streams (from a server in the network to the client). Thus, it would appear on the surface that there is no way to differentiate them, based on inspection of the signaling alone.
然而，基于信令，这两种服务看起来非常相似。两者都利用音频和视频。两者都可以使用相同的编解码器。两者都是单向流（从网络中的服务器到客户端）。因此，从表面上看，仅基于对信号的检查，无法区分它们。
Consider an interactive game, played between two users from their mobile devices. The game involves the users sending each other game moves, using a messaging channel, in addition to voice. In another service, users have a voice and IM chat conversation using a buddy-list application on their PC.
考虑一个互动游戏，在两个用户之间从他们的移动设备上玩。游戏中，除了语音，用户还通过消息传递渠道相互发送游戏动作。在另一项服务中，用户可以使用PC上的好友列表应用程序进行语音和IM聊天。
In both services, there are two media streams -- audio and messaging. The audio uses the same codecs. Both use the Message Session Relay Protocol (MSRP) [RFC4975]. In both cases, the caller would send an INVITE to the Address of Record (AOR) of the target user. However, these represent fairly different services, in terms of user experience.
在这两种服务中，都有两种媒体流——音频和消息。音频使用相同的编解码器。两者都使用消息会话中继协议（MSRP）[RFC4975]。在这两种情况下，调用方都会向目标用户的记录地址（AOR）发送邀请。然而，就用户体验而言，这些服务代表着完全不同的服务。
Consider a variation on the example in Section 3.2. In this variation, two users are playing an interactive game between their phones. However, the game itself is set up and controlled using a proprietary mechanism -- not using SIP at all. However, the client application allows the user to chat with their opponent. The chat session is a simple voice session set up between the players.
考虑第3.2节中的示例的变化。在这个变体中，两个用户正在他们的手机之间玩一个互动游戏。然而，游戏本身是使用专有机制设置和控制的——根本不使用SIP。但是，客户端应用程序允许用户与对手聊天。聊天会话是在玩家之间设置的简单语音会话。
Compare this with a basic telephone call between the two users. Both involve a single audio session. Both use the same codecs. They appear to be identical. However, different user experiences are needed. For example, we desire traditional telephony features (such as call forwarding and call screening) to be applied in the telephone service, but not in the gaming chat service.
将其与两个用户之间的基本电话进行比较。两者都涉及一个音频会话。两者都使用相同的编解码器。他们看起来一模一样。但是，需要不同的用户体验。例如，我们希望在电话服务中应用传统的电话功能（如呼叫转接和呼叫屏蔽），而不是在游戏聊天服务中。
The SIP MESSAGE method [RFC3428] provides a way to send one-shot messages to a particular AOR. This specification is primarily aimed at Short Message Service (SMS)-style messaging, commonly found in wireless phones. Receipt of a MESSAGE request would cause the messaging application on a phone to launch, allowing the user to browse the message history and respond.
SIP消息方法[RFC3428]提供了向特定AOR发送一次性消息的方法。本规范主要针对手机中常见的短消息服务（SMS）形式的消息传递。收到消息请求将导致手机上的消息应用程序启动，从而允许用户浏览消息历史记录并作出响应。
However, a MESSAGE request is sometimes used for the delivery of content to a device for other purposes. For example, some providers use it to deliver configuration updates, such as new phone settings or parameters, or to indicate that a new version of firmware is available. Though not designed for this purpose, the MESSAGE method gets used since, in existing wireless networks, SMS is used for this purpose, and the MESSAGE request is the SIP equivalent of SMS.
但是，消息请求有时用于将内容传递到设备以用于其他目的。例如，一些提供商使用它来提供配置更新，如新的电话设置或参数，或指示新版本的固件可用。虽然不是为此目的而设计的，但是消息方法得到了使用，因为在现有的无线网络中，SMS用于此目的，并且消息请求是SMS的SIP等价物。
Consequently, the MESSAGE request sent to a phone can be for two different services. One would require invocation of a messaging app, whereas the other would be consumed by the software in the phone, without any user interaction at all.
因此，发送到手机的消息请求可以用于两种不同的服务。其中一个需要调用消息传递应用程序，而另一个则由手机中的软件使用，完全没有任何用户交互。
It is important to understand what the service identity would be utilized for, if known. This section discusses the primary uses. These are application invocation in user agents and the network, Quality of Service authorization, service authorization, accounting and billing, service negotiation, and device dispatch.
了解服务标识的用途（如果已知）非常重要。本节讨论主要用途。这些是用户代理和网络中的应用程序调用、服务质量授权、服务授权、记帐和计费、服务协商和设备调度。
In some of the examples above, there were multiple software applications executing on the host. One common way of achieving this is to utilize a common SIP user agent implementation that listens for requests on a single port. When an incoming INVITE or MESSAGE arrives, it must be delivered to the appropriate application software. When each service is bound to a distinct software application, it would seem that the service identity is needed to dispatch the message to the appropriate piece of software. This is shown in Figure 1.
在上面的一些示例中，有多个软件应用程序在主机上执行。实现这一点的一种常见方法是利用一个公共SIP用户代理实现，该实现侦听单个端口上的请求。当收到邀请或消息时，必须将其发送到相应的应用软件。当每个服务都绑定到一个不同的软件应用程序时，似乎需要服务标识来将消息分派到适当的软件块。这如图1所示。
+---------------------------------+
| |
| +-------------+ +-------------+ |
| | UI | | UI | |
| +-------------+ +-------------+ |
| +-------------+ +-------------+ |
| | | | | |
| | Service 1 | | Service 2 | |
| | | | | |
| +-------------+ +-------------+ |
| +-----------------------------+ |
| | | |
| | SIP | |
| | Layer | |
| | | |
| +-----------------------------+ |
| |
+---------------------------------+
+---------------------------------+
| |
| +-------------+ +-------------+ |
| | UI | | UI | |
| +-------------+ +-------------+ |
| +-------------+ +-------------+ |
| | | | | |
| | Service 1 | | Service 2 | |
| | | | | |
| +-------------+ +-------------+ |
| +-----------------------------+ |
| | | |
| | SIP | |
| | Layer | |
| | | |
| +-----------------------------+ |
| |
+---------------------------------+
Physical Device
物理设备
Figure 1
图1
The role of the SIP layer is to parse incoming messages, handle the SIP state machinery for transactions and dialogs, and then dispatch requests to the appropriate service. This software architecture is analogous to the way web servers frequently work. An HTTP server listens on port 80 for requests, and based on the HTTP Request-URI, dispatches the request to a number of disparate applications. The same is happening here. For the example services in Section 3.2, an incoming INVITE for the gaming service would be delivered to the gaming application software. An incoming INVITE for the voice chat service would be delivered to the voice chat application software. The example in Section 3.3 is similar. For the examples in Section 3.4, a MESSAGE request for user-to-user messaging would be delivered to the messaging or SMS app, and a MESSAGE request containing configuration data would be delivered to a configuration update application.
SIP层的作用是解析传入消息，处理事务和对话框的SIP状态机制，然后将请求发送到适当的服务。这种软件体系结构类似于web服务器经常工作的方式。HTTP服务器在端口80上侦听请求，并根据HTTP请求URI将请求分派给多个不同的应用程序。同样的情况也发生在这里。对于第3.2节中的示例服务，将向游戏应用软件发送游戏服务的传入邀请。语音聊天服务的传入邀请将发送到语音聊天应用软件。第3.3节中的示例类似。对于第3.4节中的示例，用户对用户消息传递的消息请求将发送到消息传递或SMS应用程序，包含配置数据的消息请求将发送到配置更新应用程序。
Unlike the web, however, in all three use cases, the user initiating communications has (or appears to have -- more below) only a single identifier for the recipient -- their AOR. Consequently, the SIP Request-URI cannot be used for dispatching, as it is identical in all three cases.
然而，与web不同的是，在所有三种使用情形中，发起通信的用户只有（或似乎只有——下文将详细介绍）接收者的一个标识符——他们的AOR。因此，SIP请求URI不能用于调度，因为它在所有三种情况下都是相同的。
Another usage of a service identifier would be to cause servers in the SIP network to provide additional processing, based on the service. For example, an INVITE issued by a user agent for IPTV would pass through a server that does some kind of content rights management, authorizing whether the user is allowed to access that content. On the other hand, an INVITE issued by a user for multimedia conferencing would pass through a server providing "traditional" telephony features, such as outbound call screening and call recording. It would make no sense for the INVITE associated with IPTV to have outbound call screening and call recording applied, and it would make no sense for the multimedia conferencing INVITE to be processed by the content rights management server. Indeed, in these cases, it's not just an efficiency issue (invoking servers when not needed), but rather, truly incorrect behavior can occur. For example, if an outbound call screening application is set to block outbound calls to everything except for the phone numbers of friends and family, an IPTV request that gets processed by such a server would be blocked (as it's not targeted to the AOR of a friend or family member). This would block a user's attempt to access IPTV services, when that was not the goal at all.
服务标识符的另一个用途是使SIP网络中的服务器基于服务提供额外的处理。例如，IPTV的用户代理发出的邀请将通过执行某种内容权限管理的服务器，授权用户是否允许访问该内容。另一方面，用户发出的多媒体会议邀请将通过提供“传统”电话功能的服务器，如出站呼叫屏蔽和呼叫记录。与IPTV关联的邀请应用出站呼叫屏蔽和呼叫记录是没有意义的，而由内容权限管理服务器处理多媒体会议邀请也是没有意义的。事实上，在这些情况下，这不仅仅是一个效率问题（在不需要时调用服务器），而是可能发生真正不正确的行为。例如，如果出站呼叫屏蔽应用程序被设置为阻止除朋友和家人的电话号码之外的所有出站呼叫，则由此类服务器处理的IPTV请求将被阻止（因为它不是针对朋友或家人的AOR）。这将阻止用户尝试访问IPTV服务，而这根本不是目标。
Similarly, a MESSAGE request as described in Section 3.4 might need to pass through a message server for filtering when it is associated with chat, but not when it is associated with a configuration update.
类似地，第3.4节中描述的消息请求在与聊天相关联时可能需要通过消息服务器进行过滤，但在与配置更新相关联时则不需要。
Consider a filter that gets applied to MESSAGE requests, and that filter runs in a server in the network. The filter operation prevents user Joe from sending messages to user Bob that contain the words "stock" or "purchase", due to some regulations that disallow Joe and Bob from discussing stock trading. However, a MESSAGE for configuration purposes might contain an XML document that uses the token "stock" as some kind of attribute. This configuration update would be discarded by the filtering server, when it should not have been.
考虑应用于消息请求的筛选器，并且该过滤器运行在网络中的服务器中。由于某些法规禁止Joe和Bob讨论股票交易，因此筛选操作阻止用户Joe向用户Bob发送包含“股票”或“购买”字样的消息。但是，出于配置目的的消息可能包含使用标记“stock”作为某种属性的XML文档。此配置更新将被筛选服务器丢弃，而不应被删除。
The IP network can provide differing levels of Quality of Service (QoS) to IP packets. This service can include guaranteed throughput, latency, or loss characteristics. Typically, the user agent will make some kind of QoS request, either using explicit signaling protocols (such as the Resource ReSerVation Protocol (RSVP) [RFC2205]) or through marking of a Diffserv value in packets. The network will need to make a policy decision based on whether or not these QoS treatments are authorized. One common authorization policy is to check if the user has invoked a service using SIP that they are authorized to invoke, and that this service requires the level of QoS treatment the user has requested.
IP网络可以向IP分组提供不同级别的服务质量（QoS）。此服务可以包括有保证的吞吐量、延迟或丢失特性。通常，用户代理将使用显式信令协议（例如资源预留协议（RSVP）[RFC2205]）或通过在分组中标记Diffserv值来发出某种QoS请求。网络将需要根据这些QoS处理是否得到授权做出策略决策。一个常见的授权策略是检查用户是否使用他们被授权调用的SIP调用了服务，以及该服务是否需要用户请求的QoS处理级别。
For example, consider IPTV and multimedia conferencing as described in Section 3.1. IPTV is a non-real-time service. Consequently, media traffic for IPTV would be authorized for bandwidth guarantees, but not for latency or loss guarantees. On the other hand, multimedia conferencing is in real time. Its traffic would require bandwidth, loss, and latency guarantees from the network.
例如，考虑IPTV和多媒体会议，如第3.1节所述。IPTV是一种非实时服务。因此，IPTV的媒体流量将被授权用于带宽保证，而不是延迟或丢失保证。另一方面，多媒体会议是实时的。它的流量需要网络提供带宽、损耗和延迟保证。
Consequently, if a user should make an RSVP reservation for a media stream, and ask for latency guarantees for that stream, the network would choose to be able to authorize it if the service was multimedia conferencing, but not if it was IPTV. This would require the server performing the QoS authorization to know the service associated with the INVITE that set up the session.
因此，如果用户应该为媒体流进行RSVP预约，并请求该流的延迟保证，则如果该服务是多媒体会议，则网络将选择能够对其进行授权，但如果该服务是IPTV，则不能。这将要求执行QoS授权的服务器知道与设置会话的INVITE关联的服务。
Frequently, a network administrator will want to authorize whether a user is allowed to invoke a particular service. Not all users will be authorized to use all services that are provided. For example, a user may not be authorized to access IPTV services, whereas they are authorized to utilize multimedia processing. A user might not be able to utilize a multiplayer gaming service, whereas they are authorized to utilize voice chat services.
通常，网络管理员希望授权用户是否允许调用特定服务。并非所有用户都有权使用所提供的所有服务。例如，用户可能未被授权访问IPTV服务，而他们被授权使用多媒体处理。用户可能无法使用多人游戏服务，但他们有权使用语音聊天服务。
Consequently, when an INVITE arrives at a server in the network, the server will need to determine what the requested service is, so that the server can make an authorization decision.
因此，当INVITE到达网络中的服务器时，服务器将需要确定请求的服务是什么，以便服务器可以做出授权决策。
Service authorization and accounting/billing go hand in hand. One of the primary reasons for authorizing that a user can utilize a service is that they are being billed differently based on the type of service. Consequently, one of the goals of a service identity is to be able to include it in accounting records, so that the appropriate billing model can be applied.
服务授权和会计/计费密切相关。授权用户可以使用服务的一个主要原因是，根据服务的类型，他们的计费方式不同。因此，服务标识的目标之一是能够将其包含在会计记录中，以便可以应用适当的计费模型。
For example, in the case of IPTV, a service provider can bill based on the content (US $5 per movie, perhaps), whereas for multimedia conferencing, they can bill by the minute. This requires the accounting streams to indicate which service was invoked for the particular session.
例如，在IPTV的情况下，服务提供商可以根据内容计费（也许每部电影5美元），而对于多媒体会议，他们可以按分钟计费。这需要记帐流指示为特定会话调用了哪个服务。
In some cases, when the caller initiates a session, they don't actually know which service will be utilized. Rather, they might choose to offer up all of the services they have available to the called party, and then let the called party decide, or let the system make a decision based on overlapping service capabilities.
在某些情况下，当调用方启动会话时，他们实际上不知道将使用哪个服务。相反，他们可能会选择向被叫方提供所有可用的服务，然后让被叫方决定，或者让系统根据重叠的服务能力做出决定。
As an example, a user can do both the game and the voice chat service described in Section 3.2. The user initiates a session to a target AOR, but the devices used by the target can only support voice chat. The called device returns, in its call acceptance, an indication that only voice chat can be used. Consequently, voice chat gets utilized for the session.
例如，用户可以进行第3.2节所述的游戏和语音聊天服务。用户向目标AOR发起会话，但目标使用的设备只能支持语音聊天。被叫设备在其呼叫接受中返回仅可使用语音聊天的指示。因此，语音聊天被用于会话。
When a user has multiple devices, each with varying capabilities in terms of service, it is useful to dispatch an incoming request to the right device based on whether the device can support the service that has been requested.
当用户有多个设备，每个设备在服务方面具有不同的功能时，根据设备是否能够支持已请求的服务，将传入请求分派到正确的设备是有用的。
For example, if a user initiates a gaming session with voice chat, and the target user has two devices -- one that can support the gaming service, and another that cannot -- the INVITE should be dispatched to the device that supports the gaming session.
例如，如果用户通过语音聊天启动游戏会话，并且目标用户有两个设备——一个可以支持游戏服务，另一个不能——则应将邀请发送到支持游戏会话的设备。
In this section, we describe several key principles of service identification:
在本节中，我们将介绍服务标识的几个关键原则：
1. Services are a by-product of signaling
1. 服务是信令的副产品
2. Identical signaling produces identical services
2. 相同的信令产生相同的服务
3. Declarative service identification is an example of "Do What I Mean" (DWIM)
3. 声明性服务标识是“照我的意思做”（DWIM）的一个示例
4. Declarative service identifiers are redundant
4. 声明性服务标识符是冗余的
5. URIs are a key mechanism for producing differentiated signaling
5. URI是产生差异化信号的关键机制
Declarative service identification -- the addition of a service identifier by clients in order to inform other entities of what the service is -- is a very compelling solution to solving the use cases described above. It provides a clear way for each of the use cases to be differentiated. On the other hand, derived service identification appears "hard", since the signaling appears to be the same for these different services.
声明性服务标识——客户端添加服务标识符以通知其他实体服务是什么——是解决上述用例的一个非常有说服力的解决方案。它为区分每个用例提供了一种清晰的方法。另一方面，派生服务标识似乎“困难”，因为对于这些不同的服务，信令似乎是相同的。
Declarative service identification misses a key point, which cannot be stressed enough, and which represents the core architectural principle to be understood here:
声明性服务标识忽略了一个关键点，这一点强调得不够，它代表了此处要理解的核心体系结构原则：
A service is the byproduct of the signaling and the context around it (the user profile, time of day, and so on) -- the effects of the signaling message once it is launched into the network. The service identity is therefore always derivable from the signaling and its context without additional identifiers. In other words, derived service identification is always possible when signaling is being properly handled.
服务是信令及其周围环境（用户配置文件、一天中的时间等）的副产品——信令消息一旦被发送到网络中就会产生影响。因此，服务标识始终可以从信令及其上下文派生，而无需附加标识符。换句话说，当信令被正确处理时，派生服务标识总是可能的。
When a user sends an INVITE request to the network and targets that request at an IPTV server, and includes the Session Description Protocol (SDP) for audio and video streaming, the *result* of sending such an INVITE is that an IPTV session occurs. The entire purpose of the INVITE is to establish such a session, and therefore, invoke the service. Thus, a service is not something that is different from the rest of the signaling message. A service is what the user gets after the network and other user agents have processed a signaling message.
当用户向网络发送INVITE请求并将该请求指向IPTV服务器，并且包括用于音频和视频流的会话描述协议（SDP）时，发送这样的INVITE的*结果*是发生IPTV会话。INVITE的全部目的是建立这样一个会话，从而调用服务。因此，服务与信令消息的其余部分没有什么不同。服务是用户在网络和其他用户代理处理信令消息后得到的服务。
It may seem that delayed offers (SIP INVITE requests that lack SDP) make it impossible to perform derived service identification. After all, in some of the cases above, the differentiation was done using the SDP in the request. What if it's not there? The answer is simple -- if it's not there, and the SDP is being offered by the called party, you cannot in fact know the service at the time of the INVITE. That's the whole point of delayed offer -- to give the called party the chance to offer up what it wants for the session. In cases where service identification is needed at request time, delayed offer cannot be used.
延迟的提供（缺少SDP的SIP INVITE请求）似乎使执行派生服务标识变得不可能。毕竟，在上面的一些情况下，差异是使用请求中的SDP完成的。如果它不在那里呢？答案很简单——如果它不在那里，并且SDP是由被叫方提供的，那么您实际上无法在邀请时知道服务。这就是延迟报价的全部意义——给被叫方机会在会议上提供它想要的东西。如果在请求时需要服务标识，则不能使用延迟报价。
This principle is a natural conclusion of the previous assertion. If a service is the byproduct of signaling, how can a user have different experiences and different services when the signaling message is the same? They cannot.
这一原则是先前断言的自然结论。如果服务是信令的副产品，那么当信令消息相同时，用户如何能有不同的体验和不同的服务？他们不能。
But how can that be? From the examples in Section 3, it would seem that there are services that are different, but have identical signaling. If we hold true to the assertion, there is in fact only one logical conclusion:
但这怎么可能呢？从第3节中的示例来看，似乎存在不同但具有相同信令的服务。如果我们坚持这一主张，事实上只有一个逻辑结论：
If two services are different, but their signaling appears to be the same, it is because one or more of the following is true:
如果两个服务不同，但它们的信令似乎相同，这是因为以下一个或多个是正确的：
1. there is in fact something different that has been overlooked
1. 事实上，有些不同的东西被忽视了
2. something has been implied from the signaling, when in fact it should have been signaled explicitly
2. 信号中暗示了一些东西，而事实上它应该被明确地发出信号
3. the signaling mechanism should be changed so that there is, in fact, something that is different
3. 信号机制应该改变，这样事实上就有了不同的东西
To illustrate this, let us take each of the example services in Section 3 and investigate whether there is, or should be, something different in the signaling in each case.
为了说明这一点，让我们以第3节中的每个示例服务为例，研究在每种情况下，信令中是否存在或应该存在不同的内容。
IPTV vs. Multimedia Conferencing: The two services described in Section 3.1 appear to have identical signaling. They both involve audio and video streams, both of which are unidirectional. Both might utilize the same codecs. However, there is another important difference in the signaling -- the target URI. In the case of IPTV, the request is targeted at a media server or to a particular piece of content to be viewed. In the case of multimedia conferencing, the target is a conference server. The administrator of the domain can therefore examine the Request-URI
IPTV与多媒体会议：第3.1节中描述的两种服务似乎具有相同的信令。它们都涉及音频和视频流，都是单向的。两者可能使用相同的编解码器。然而，在信令中还有另一个重要的区别——目标URI。在IPTV的情况下，请求的目标是媒体服务器或要查看的特定内容。在多媒体会议的情况下，目标是会议服务器。因此，域管理员可以检查请求URI
and figure out whether it is targeted for a conference server or a content server, and use that to derive the service associated with the request.
然后确定它是针对会议服务器还是内容服务器，并使用它派生与请求关联的服务。
Gaming vs. Voice Chat: Though both sessions involve MSRP and voice, and both are targeted to the same AOR of the called user, there is a difference. The MSRP messages for the gaming session carry content that is game specific, whereas the MSRP messages for the voice chat are just regular text, meant for rendering to a user. Thus, the MSRP session in the SDP will indicate the specific content type that MSRP is carrying, and this type will differ in both cases. Even if the game moves look like text, since they are being consumed by an automata, there is an underlying schema that dictates their content, and therefore, this schema represents the actual content type that should be signaled.
游戏与语音聊天：虽然这两个会话都涉及MSRP和语音，并且都针对被呼叫用户的同一AOR，但有区别。用于游戏会话的MSRP消息包含特定于游戏的内容，而用于语音聊天的MSRP消息只是普通文本，用于呈现给用户。因此，SDP中的MSRP会话将指示MSRP正在承载的特定内容类型，并且在这两种情况下，该类型将有所不同。即使游戏动作看起来像文本，因为它们被自动机消费，也有一个底层模式指示它们的内容，因此，该模式表示应该发出信号的实际内容类型。
Gaming vs. Voice Chat #2: In this case, both sessions involve only voice, and both are targeted at the same AOR. Indeed, there truly is nothing different -- if indeed the signaling works this way. However, there is an alternative mechanism for performing the signaling. For the gaming session, the proprietary protocol can be used to exchange a URI that can be used to identify the voice chat function on the phone that is associated with the game (for example, a Globally Routable User Agent URI (GRUU) can be used [RFC5627]). Indeed, the gaming chat is not targeting the USER -- it's targeting the gaming instance on the phone. Thus, if a special GRUU is used for the gaming chat, this makes the signaling different between these two services.
游戏与语音聊天#2：在这种情况下，两个会话都只涉及语音，并且都针对相同的AOR。事实上，如果信号确实是以这种方式工作的，那就没有什么不同了。然而，存在用于执行信令的替代机制。对于游戏会话，专有协议可用于交换URI，该URI可用于识别电话上与游戏相关联的语音聊天功能（例如，可使用全局可路由用户代理URI（GRUU）[RFC5627]）。事实上，游戏聊天并不是针对用户——而是针对手机上的游戏实例。因此，如果游戏聊天使用特殊的GRUU，这将使这两个服务之间的信令不同。
Configuration vs. Pager Messaging: Just as in the case of gaming vs. voice chat, the content type of the messages differentiates the service that occurs as a consequence of the messages.
配置与寻呼机消息：就像游戏与语音聊天一样，消息的内容类型区分了消息产生的服务。
"Do What I Mean", abbreviated as DWIM, is a concept in computer science. It is sometimes used to describe a function that tries to intelligently guess at what the user intended. It is in contrast to "Do What I Say", or DWIS, which describes a function that behaves concretely based on the inputs provided. Systems built on the DWIM concept can have unexpected behaviors, because they are driven by unstated rules.
“照我说的做”，缩写为DWIM，是计算机科学中的一个概念。它有时被用来描述一个函数，该函数试图智能地猜测用户的意图。它与“照我说的做”或DWIS形成对比，DWIS描述了一个基于所提供输入的具体行为的函数。基于DWIM概念构建的系统可能会有意外的行为，因为它们是由未声明的规则驱动的。
Declarative service identification is an example of DWIM. The service identifier has no well-defined impact on the state machinery or protocols in the system; it has various side effects based on an assumption of what is meant by the service identifier. Derived service identification, on the other hand, is an expression of the
声明性服务标识就是DWIM的一个例子。服务标识符对系统中的状态机制或协议没有明确定义的影响；基于对服务标识符含义的假设，它具有各种副作用。另一方面，派生服务标识是
principle of DWIS -- the behavior of the system is based entirely on the specifics of the protocol and are well defined by the protocol specification. The service identifier is just a shorthand for summarizing things that are well defined by signaling.
DWIS的原理——系统的行为完全基于协议的细节，并由协议规范定义。服务标识符只是一个简写，用于总结通过信令定义的内容。
As a litmus test to differentiate the two cases, consider the following question. If a request contained a service identifier, and that request were processed by a domain that didn't understand the concept of service identifiers at all, would the request be rejected if that service were not supported, or would it complete but do the wrong thing? If it is the latter case, it's DWIM. If it's the former, it's DWIS.
作为区分两种情况的试金石测试，考虑下面的问题。如果一个请求包含一个服务标识符，而该请求是由一个根本不理解服务标识符概念的域处理的，那么如果该服务不受支持，该请求是否会被拒绝，或者它是否会完成但做了错误的事情？如果是后一种情况，那就是DWIM。如果是前者，那就是DWIS。
Because a declarative service identifier is, by definition, inside of the signaling message, and because the signaling itself completely defines the behavior of the service, another natural conclusion is that a declarative service identifier is redundant with the signaling itself. It says nothing that could not or should not otherwise be derived from examination of the signaling.
因为根据定义，声明性服务标识符位于信令消息内部，并且因为信令本身完全定义了服务的行为，所以另一个自然的结论是声明性服务标识符与信令本身是冗余的。它并没有说任何不能或不应该从信号检查中得到的东西。
In the IPTV example and in the second gaming example, it was ultimately the Request-URI that was (or should be) different between the two services. This is important. In many cases where services appear the same, it is because the resource that is being targeted is not, in fact, the user. Rather, it is a resource that is linked with the user. This resource might be an instance of a software application on the particular device of a user, or a resource in the network that acts on behalf of the user.
在IPTV示例和第二个游戏示例中，两个服务之间（或应该）不同的最终是请求URI。这很重要。在许多服务看起来相同的情况下，这是因为目标资源实际上不是用户。相反，它是一种与用户链接的资源。该资源可以是用户特定设备上的软件应用程序实例，也可以是网络中代表用户的资源。
The Request-URI is an infinitely large namespace for identifying these resources. It is an ideal mechanism for providing differentiation when there would otherwise be none.
请求URI是一个无限大的名称空间，用于标识这些资源。这是一种理想的机制，可以在没有差异的情况下提供差异化。
Returning again to the example in Section 3.3, we can see that it does make more sense to target the gaming chat session at a software instance on the user's phone, rather than at the user themselves. The gaming chat session should really only go to the phone on which the user is playing the game. The software instance does indeed live only on that phone, whereas the user themselves can be contacted in many ways. We don't want telephony features invoked for the gaming chat session, because those features only make sense when someone is trying to communicate with the USER. When someone is trying to
再次回到第3.3节中的示例，我们可以看到，将游戏聊天会话的目标定位在用户手机上的软件实例上，而不是用户自己，确实更有意义。游戏聊天会话实际上应该只转到用户正在玩游戏的手机上。软件实例确实只存在于该手机上，而用户本身可以通过多种方式联系。我们不希望在游戏聊天会话中调用电话功能，因为只有当有人试图与用户通信时，这些功能才有意义。当有人试图
communicate with a software instance that acts on behalf of the user, a different set of rules apply, since the target of the request is completely different.
与代表用户的软件实例通信时，会应用一组不同的规则，因为请求的目标完全不同。
Based on these principles, several perils of declarative service identification can be described. They are:
基于这些原则，可以描述声明性服务标识的几种危险。他们是：
1. Declarative service identification can be used for fraud
1. 声明性服务标识可用于欺诈
2. Declarative service identification can hurt interoperability
2. 声明性服务标识可能会损害互操作性
3. Declarative service identification can stifle service innovation
3. 声明性服务标识会扼杀服务创新
Declarative service identification can lead to fraud. If a provider uses the service identifier for billing and accounting purposes, or for authorization purposes, it opens an avenue for attack. The user can construct the signaling message so that its actual effect (which is the service the user will receive), is what the user desires, but the user places a service identifier into the request (which is what is used for billing and authorization) that identifies a cheaper service, or one that the user is not authorized to receive. In such a case, the user will receive service, and not be billed properly for it.
声明性服务标识可能导致欺诈。如果提供商将服务标识符用于计费和记帐目的，或用于授权目的，则会打开攻击的渠道。用户可以构造信令消息，以便其实际效果（即用户将接收到的服务）是用户所期望的，但是用户将服务标识符放入请求（用于计费和授权）中，该服务标识符标识更便宜的服务，或者未授权用户接收的服务。在这种情况下，用户将收到服务，而不会为此收取适当的费用。
If, however, the domain administrator derived the service identifier from the signaling itself (derived service identification), the user cannot lie. If they did lie, they wouldn't get the desired service.
但是，如果域管理员从信令本身派生出服务标识符（派生服务标识），则用户不能撒谎。如果他们真的撒谎，他们就得不到想要的服务。
Consider the example of IPTV vs. multimedia conferencing. If multimedia conferencing is cheaper, the user could send an INVITE for an IPTV session, but include a service identifier that indicates multimedia conferencing. The user gets the service associated with IPTV, but at the cost of multimedia conferencing.
考虑IPTV与多媒体会议的例子。如果多媒体会议更便宜，用户可以发送IPTV会话的邀请，但包括指示多媒体会议的服务标识符。用户获得与IPTV相关的服务，但代价是多媒体会议。
This same principle shows up in other places -- for example, in the identification of an emergency services call [ECRIT-FRAMEWORK]. It is desirable to give emergency services calls special treatment, such as being free and authorized even when the user cannot otherwise make calls, and to give them priority. If emergency calls were indicated through something other than the target of the call being an emergency services URN [RFC5031], it would open an avenue for fraud. The user could place any desired URI in the request-URI, and indicate separately, through a declarative identifier, that the call is an emergency services call. This would then get special treatment but
同样的原则也出现在其他地方——例如，在识别紧急服务呼叫[ECRIT-FRAMEWORK]时。对紧急服务呼叫给予特殊处理是可取的，例如即使在用户无法拨打电话的情况下也可以免费和授权，并给予优先权。如果紧急呼叫不是通过紧急服务URN[RFC5031]的呼叫目标指示的，这将为欺诈打开一条渠道。用户可以在请求URI中放置任何所需的URI，并通过声明性标识符单独指示该调用是紧急服务调用。这将得到特殊处理，但
of course would get routed to the target URI. The only way to prevent this fraud is to consider an emergency call as any call whose target is an emergency services URN. Thus, the service identification here is based on the target of the request. When the target is an emergency services URN, the request can get special treatment. The user cannot lie, since there is no way to separately indicate that this is an emergency call, besides targeting it to an emergency URN.
当然会被路由到目标URI。防止这种欺诈的唯一方法是考虑急诊科呼叫，其目标是急诊科服务瓮。因此，这里的服务标识基于请求的目标。当目标是紧急服务瓮时，请求可以得到特殊处理。用户不能撒谎，因为除了将其指向紧急URN之外，没有办法单独指出这是一个紧急呼叫。
How can declarative service identification cause loss of interoperability? When an identifier is used to drive functionality -- such as dispatch on the phones, in the network, or QoS authorization -- it means that the wrong thing can happen when this field is not set properly. Consider a user in domain 1, calling a user in domain 2. Domain 1 provides the user with a service they call "voice chat", which utilizes voice and IM for real-time conversation, driven off of a buddy-list application on a PC. Domain 2 provides their users with a service they call "text telephony", which is a voice service on a wireless device that also allows the user to send text messages. Consider the case where domain 1 and domain 2 both have their user agents insert a service identifier into the request, and then use that to perform QoS authorization, accounting, and invocation of applications in the network and in the device. The user in domain 1 calls the user in domain 2, and inserts the identifier "Voice Chat" into the INVITE. When this arrives at the server in domain 2, the service identifier is unknown. Consequently, the request does not get the proper QoS treatment, even if the call itself will succeed.
声明性服务标识如何导致互操作性丧失？当一个标识符被用来驱动功能时——比如电话上的调度、网络中的调度或QoS授权——这意味着如果该字段设置不正确，可能会发生错误的事情。考虑域1中的用户，调用域2中的用户。域1为用户提供了一项他们称之为“语音聊天”的服务，该服务利用语音和IM进行实时对话，由PC上的好友列表应用程序驱动。域2为用户提供了一项他们称之为“文本电话”的服务，这是一项无线设备上的语音服务，也允许用户发送文本消息。考虑域1和域2都有其用户代理将服务标识符插入请求中的情况，然后使用该代理来执行网络和设备中的应用程序的QoS授权、计费和调用。域1中的用户呼叫域2中的用户，并在邀请中插入标识符“语音聊天”。当它到达域2中的服务器时，服务标识符未知。因此，即使调用本身会成功，请求也不会得到适当的QoS处理。
If, on the other hand, derived service identification were used, the service identifier could be removed by domain 2, and then recomputed based on the signaling to match its own notion of services. In this case, domain 2 could derive the "text telephony" identifier, and the request completes successfully.
另一方面，如果使用了派生服务标识，则服务标识可以由域2删除，然后基于信令重新计算，以匹配其自身的服务概念。在这种情况下，域2可以派生“文本电话”标识符，并且请求成功完成。
Declarative service identification, used between domains, causes interoperability failures unless all interconnected domains agree on exactly the same set of services and how to name them. Of course, lack of service identifiers does not guarantee service interoperability. However, SIP was built with rich tools for negotiation of capabilities at a finely granular level. One user agent can make a call using audio and video, but if the receiving UA only supports audio, SIP allows both sides to negotiate down to the lowest common denominator. Thus, communication is still provided. As another example, if one agent initiates a Push-To-Talk session (which is audio with a companion floor control mechanism), and the
声明性服务标识（在域之间使用）会导致互操作性失败，除非所有互连的域都同意完全相同的服务集以及如何命名它们。当然，缺少服务标识符并不能保证服务的互操作性。然而，SIP是使用丰富的工具构建的，用于在细粒度级别上进行功能协商。一个用户代理可以使用音频和视频进行呼叫，但如果接收UA仅支持音频，则SIP允许双方协商到最低公分母。因此，仍然提供通信。作为另一个示例，如果一个代理启动一键通会话（这是带有伴奏楼层控制机制的音频），则
other side only did regular audio, SIP would be able to negotiate back down to a regular voice call. As another example, if a calling user agent is running a high-definition video conferencing endpoint, and the called user agent supports just a regular video endpoint, the codecs themselves can negotiate downward to a lower rate, picture size, and so on. Thus, interoperability is achieved. Interestingly, the final "service" may no longer be well characterized by the service identifier that would have been placed in the original INVITE. For example, in this case, if the original INVITE from the caller had contained the service identifier "hi-fi video", but the video gets negotiated down to a lower rate and picture size, the service identifier is no longer really appropriate. That is why services need to be derived by signaling -- because the signaling itself provides negotiation and interoperability between different domains.
另一方只做常规音频，SIP将能够协商回到常规语音呼叫。作为另一个示例，如果呼叫用户代理正在运行高清视频会议端点，并且被呼叫用户代理仅支持常规视频端点，则编解码器本身可以向下协商到较低的速率、图片大小等。因此，实现了互操作性。有趣的是，最终的“服务”可能不再具有服务标识符的特征，而服务标识符本应放在原始邀请中。例如，在这种情况下，如果来自呼叫者的原始邀请包含服务标识符“hi-fi video”，但视频被协商到更低的速率和图片大小，则服务标识符不再真正合适。这就是为什么需要通过信令来派生服务——因为信令本身提供了不同域之间的协商和互操作性。
This illustrates another key aspect of the interoperability problem. Declarative service identification will result in inconsistencies between its service identifiers and the results of any SIP negotiation that might otherwise be applied in the session.
这说明了互操作性问题的另一个关键方面。声明性服务标识将导致其服务标识符与会话中可能应用的任何SIP协商的结果不一致。
When a service identifier becomes something that both proxies and the user agent need to understand in order to properly treat a request (which is the case for declarative service identification), it becomes equivalent to including a token in the Proxy-Require and Require header fields of every single SIP request. The very reason that [RFC4485] frowns upon usage of Require and certainly Proxy-Require is the huge impact on interoperability it causes. It is for this same reason that declarative service identification needs to be avoided.
当服务标识符成为代理和用户代理都需要理解的东西以便正确处理请求（这是声明性服务标识的情况）时，它就相当于在每个SIP请求的Proxy Require和Require header字段中包含令牌。[RFC4485]不赞成使用Require（当然还有代理Require）的原因就是它对互操作性造成的巨大影响。出于同样的原因，需要避免声明性服务标识。
The probability that any two service providers end up with the same set of services, and give those services the same names, becomes smaller and smaller as the number of providers grow. Indeed, it would almost certainly require a centralized authority to identify what the services are, how they work, and what they are named. This, in turn, leads to a requirement for complete homogeneity in order to facilitate interconnection. Two providers cannot usefully interconnect unless they agree on the set of services they are offering to their customers and each do the same thing. This is because each provider has become dependent on inclusion of the proper service identifier in the request, in order for the overall treatment of the request to proceed correctly. This is, in a very real sense, anathema to the entire notion of SIP, which is built on the idea that heterogeneous domains can interconnect and still get interoperability.
随着提供商数量的增加，任何两个服务提供商最终使用相同的服务集并给这些服务取相同名称的概率越来越小。事实上，它几乎肯定需要一个集中的权威机构来确定服务是什么、它们如何工作以及它们的名称。这反过来又要求完全同质化，以便于互连。两个提供商不能有效地互连，除非他们就向其客户提供的服务集达成一致，并且每个提供商都做相同的事情。这是因为每个提供者都依赖于在请求中包含正确的服务标识符，以便正确处理请求。从一个非常真实的意义上讲，这是对SIP整个概念的诅咒，SIP是建立在异构域可以互连并且仍然可以获得互操作性的思想之上的。
Declarative service identification leads to a requirement for homogeneity in service definitions across providers that interconnect, ruining the very service heterogeneity that SIP was meant to bring.
声明性服务标识要求互连的提供者之间的服务定义具有同质性，从而破坏了SIP本来要带来的服务异构性。
Indeed, Metcalfe's Law says that the value of a network grows with the square of the number of participants. As a consequence of this, once a bunch of large domains did get together, agree on a set of services, and then agree on a set of well-known identifiers for those services, it would force other providers to also deploy the same services, in order to obtain the value that interconnection brings. This, in turn, will stifle innovation, and quickly force the set of services in SIP to become fixed and never expand beyond the ones initially agreed upon. This, too, is anathema to the very framework on which SIP is built, and defeats much of the purpose of why providers have chosen to deploy SIP in their own networks.
事实上，梅特卡夫定律说，网络的价值随着参与者数量的平方而增长。因此，一旦一组大型域聚集在一起，就一组服务达成一致，然后就这些服务的一组众所周知的标识符达成一致，它将迫使其他提供商也部署相同的服务，以获得互连带来的价值。这反过来会扼杀创新，并迅速迫使SIP中的服务集变得固定，永远不会超出最初商定的服务集。这对于SIP构建的框架来说也是一个诅咒，并且违背了供应商选择在自己的网络中部署SIP的大部分目的。
Consider the following example. Several providers get together and standardize on a bunch of service identifiers. One of these uses audio and video (say, "multimedia conversation"). This service is successful and is widely utilized. Endpoints look for this identifier to dispatch calls to the right software applications, and the network looks for it to invoke features, perform accounting, and provide QoS. A new provider gets the idea for a new service (say, "avatar-enhanced multimedia conversation"). In this service, there is audio and video, but there is a third stream, which renders an avatar. A caller can press buttons on their phone, to cause the avatar on the other person's device to show emotion, make noise, and so on. This is similar to the way emoticons are used today in IM. This service is enabled by adding a third media stream (and consequently, a third m-line) to the SDP.
考虑下面的例子。多个提供者聚集在一起，对一组服务标识符进行标准化。其中之一使用音频和视频（比如“多媒体对话”）。这项服务是成功的，并得到广泛利用。端点查找该标识符以向正确的软件应用程序发送调用，网络查找该标识符以调用功能、执行记帐和提供QoS。一个新的提供商得到了一个新服务的想法（比如，“化身增强多媒体对话”）。在这个服务中，有音频和视频，但有第三个流，它呈现化身。来电者可以按下手机上的按钮，使对方设备上的化身显示情感、发出噪音等。这类似于今天IM中使用表情符号的方式。该服务通过向SDP添加第三媒体流（因此，第三m线）来启用。
Normally, this service would be backwards-compatible with a regular audio-video endpoint, which would just reject the third media stream. However, because a large network has been deployed that is expecting to see the token, "multimedia conversation" and its associated audio+ video service, it is nearly impossible for the new provider to roll out this new service. If they did, it would fail completely, or partially fail, when their users call users in other provider domains.
正常情况下，该服务将向后兼容常规音频视频端点，后者将拒绝第三个媒体流。然而，由于已经部署了一个大型网络，希望看到令牌“多媒体对话”及其相关的音频+视频服务，因此新提供商几乎不可能推出这项新服务。如果他们这样做了，当他们的用户调用其他提供者域中的用户时，它将完全失败，或者部分失败。
From these principles, several recommendations can be made.
根据这些原则，可以提出若干建议。
Derived service identification -- where an identifier for a service is obtained by inspection of the signaling and of other contextual data (such as subscriber profile) -- is reasonable, and when done properly, does not lead to the perils described above. However, declarative service identification -- where user agents indicate what the service is, separate from the rest of the signaling -- leads to the perils described above.
派生服务标识——通过检查信令和其他上下文数据（如用户配置文件）获得服务的标识符——是合理的，如果操作正确，不会导致上述危险。然而，声明性服务标识（其中用户代理指示服务是什么，与其他信令分离）会导致上述危险。
If it appears that the signaling currently defined in standards is not sufficient to identify the service, it may be due to lack of sufficient signaling to convey what is needed, or may be because request URIs should be used for differentiation and they are not being used. By applying the litmus tests described in Section 5.3, network designers can determine whether or not the system is attempting to perform declarative service identification.
如果标准中当前定义的信令似乎不足以识别服务，则可能是由于缺乏足够的信令来传达所需内容，或者可能是因为请求uri应用于区分，而它们未被使用。通过应用第5.3节中描述的石蕊测试，网络设计者可以确定系统是否正在尝试执行声明性服务标识。
One of SIP's key strengths is its ability to negotiate a common view of a session between participants. This means that the service that is ultimately received can vary wildly, depending on the types of endpoints in the call and their capabilities. Indeed, this fact becomes even more evident when calls are set up between domains.
SIP的关键优势之一是它能够在参与者之间协商会话的共同观点。这意味着最终接收的服务可能会有很大的差异，这取决于调用中端点的类型及其功能。事实上，当在域之间建立调用时，这一事实变得更加明显。
As such, when performing derived service identification, domains should be aware that sessions may arrive from different networks and different endpoints. Consequently, the service identification algorithm must be complete -- meaning it computes the best answer for any possible signaling message that might be received and any session that might be set up.
因此，在执行派生服务标识时，域应该知道会话可能来自不同的网络和不同的端点。因此，服务识别算法必须是完整的——这意味着它为可能接收到的任何可能的信令消息和可能设置的任何会话计算最佳答案。
In a homogeneous environment, the process of service identification is easy. The service provider will know the set of services they are providing, and based on the specific call flows for each specific service, can construct rules to differentiate one service from another. However, when different providers interconnect, or when different endpoints are introduced, assumptions about what services are used, and how they are signaled, no longer apply. To provide the best user experience possible, a provider doing service identification needs to perform a "best-match" operation, such that
在同质环境中，服务识别过程很容易。服务提供者将知道他们正在提供的服务集，并且基于每个特定服务的特定调用流，可以构造规则来区分一个服务和另一个服务。然而，当不同的提供者互连时，或者当引入不同的端点时，关于使用什么服务以及如何通知它们的假设不再适用。为了尽可能提供最佳的用户体验，进行服务标识的提供商需要执行“最佳匹配”操作，以便
any legal SIP signaling -- not just the specific call flows running within their own network amongst a limited set of endpoints -- is mapped to the appropriate service.
任何合法的SIP信令——不仅仅是在有限的一组端点之间的自己的网络中运行的特定呼叫流——都映射到适当的服务。
Presence can help a great deal with providing unique URIs for different services. When a user wishes to contact another user, and knows only the AOR for the target (which is usually the case), the user can fetch the presence document for the target. That document, in turn, can contain numerous service URIs for contacting the target with different services. Those URIs can then be used in the Request-URI for differentiation. When possible, this is the best solution to the problem.
存在可以在很大程度上帮助为不同的服务提供独特的URI。当用户希望联系另一个用户，并且只知道目标的AOR（通常是这样）时，用户可以获取目标的状态文档。该文档反过来可以包含许多服务URI，用于使用不同的服务联系目标。然后可以在请求URI中使用这些URI进行区分。如果可能，这是解决问题的最佳方案。
Service identifiers themselves are not bad; derived service identification allows each domain to cache the results of the service identification process for usage by another network element within the same domain. However, service identifiers are fundamentally useful within a particular domain, and any such header must be stripped at a network boundary. Consequently, the process of service identification and their associated service identifiers is always an intra-domain operation.
服务标识符本身也不错；派生服务标识允许每个域缓存服务标识过程的结果，以供同一域内的其他网元使用。然而，服务标识符在特定域中基本上是有用的，任何这样的报头都必须在网络边界处剥离。因此，服务标识及其相关联的服务标识符的过程始终是域内操作。
Device dispatch should be done following the principles of [RFC3841], using implicit preferences based on the signaling. For example, [RFC5688] defines a new UA capability that can be used to dispatch requests based on different types of application media streams.
设备调度应遵循[RFC3841]的原则，使用基于信令的隐式首选项。例如，[RFC5688]定义了一种新的UA功能，可用于根据不同类型的应用程序媒体流发送请求。
However, it is a mistake to try and use a service identifier as a UA capability. Consider a service called "multimedia telephony", which adds video to the existing PSTN experience. A user has two devices, one of which is used for multimedia telephony and the other strictly for a voice-assisted game. It is tempting to have the telephony device include a UA capability [RFC3840] called "multimedia telephony" in its registration. A calling multimedia telephony device can then include the Accept-Contact header field [RFC3841] containing this feature tag. The proxy serving the called party, applying the basic algorithms of [RFC3841], will correctly route the call to the terminating device.
但是，尝试将服务标识符用作UA功能是错误的。考虑一种称为“多媒体电话”的服务，它将视频添加到现有的PSTN体验中。用户有两个设备，一个用于多媒体电话，另一个用于语音辅助游戏。让电话设备在其注册中包含一种称为“多媒体电话”的UA功能[RFC3840]是很诱人的。然后，呼叫多媒体电话设备可以包括包含此功能标签的接受联系人标头字段[RFC3841]。应用[RFC3841]的基本算法，为被叫方服务的代理将正确地将呼叫路由到终端设备。
However, if the calling party is not within the same domain, and the calling domain does not know about or use this feature tag, there will be no Accept-Contact header field, even if the calling party was
但是，如果主叫方不在同一个域中，并且主叫域不知道或不使用此功能标签，则即使主叫方在同一个域中，也不会有Accept Contact header字段
using a service that is a good match for "multimedia telephony". In such a case, the call may be delivered to both devices, but it will yield a poorer user experience. That's because device dispatch was done using declarative service identification.
使用与“多媒体电话”非常匹配的服务。在这种情况下，呼叫可能同时发送到两个设备，但会产生较差的用户体验。这是因为设备调度是使用声明性服务标识完成的。
The best way to avoid this problem is to use feature tags that can be matched to well-defined signaling features -- media types, required SIP extensions, and so on. In particular, the golden rule is that the granularity of feature tags must be equivalent to the granularity of individual features that can be signaled in SIP.
避免此问题的最佳方法是使用可与定义良好的信令功能（媒体类型、所需的SIP扩展等）匹配的功能标签。特别是，黄金法则是，特征标记的粒度必须与SIP中可以发出信号的单个特征的粒度相等。
Oftentimes, the service associated with a request is utilized for purposes such as authorization, accounting, and billing. When service identification is not done properly, the possibility of unauthorized service use and network fraud is introduced. It is for this reason, discussed extensively in Section 6.1, that the usage of declarative service identifiers inserted by a UA is not recommended.
通常，与请求关联的服务用于授权、记帐和计费等目的。如果服务识别工作做得不好，可能会导致未经授权的服务使用和网络欺诈。正是由于这个原因（在第6.1节中进行了广泛讨论），不建议使用UA插入的声明性服务标识符。
This document is based on discussions with Paul Kyzivat and Andrew Allen, who contributed significantly to the ideas here. Much of the content in this document is a result of discussions amongst participants in the SIPPING mailing list, including Dean Willis, Tom Taylor, Eric Burger, Dale Worley, Christer Holmberg, and John Elwell, amongst many others. Thanks to Spencer Dawkins, Tolga Asveren, Mahesh Anjanappa, and Claudio Allochio for reviews of this document.
本文件基于与Paul Kyzivat和Andrew Allen的讨论，他们对本文的观点做出了重大贡献。本文件中的大部分内容是啜饮邮件列表参与者讨论的结果，包括迪安·威利斯、汤姆·泰勒、埃里克·伯格、戴尔·沃利、克里斯特·霍姆伯格和约翰·埃尔威尔等。感谢Spencer Dawkins、Tolga Asveren、Mahesh Anjanpa和Claudio Allochio对本文件的审阅。
[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月。
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[RFC4479]Rosenberg，J.，“存在的数据模型”，RFC 4479，2006年7月。
[RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)", RFC 4485, May 2006.
[RFC4485]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）扩展作者指南”，RFC 4485，2006年5月。
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975]Campbell，B.，Mahy，R.，和C.Jennings，“消息会话中继协议（MSRP）”，RFC 49752007年9月。
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008.
[RFC5031]Schulzrinne，H.，“应急和其他知名服务的统一资源名称（URN）”，RFC 5031，2008年1月。
[ECRIT-FRAMEWORK] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling using Internet Multimedia", Work in Progress, July 2009.
[ECRIT-FRAMEWORK]Rosen，B.，Schulzrinne，H.，Polk，J.，和A.Newton，“使用互联网多媒体进行紧急呼叫的框架”，正在进行的工作，2009年7月。
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[RFC5627]Rosenberg，J.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理URI（GRUUs）”，RFC 5627，2009年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月。
[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月。
[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月。
[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月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，B.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
Author's Address
作者地址
Jonathan Rosenberg jdrosen.net Monmouth, NJ USA
Jonathan Rosenberg jdrosen.net美国新泽西州蒙茅斯
EMail: jdrosen@jdrosen.net
URI: http://www.jdrosen.net
EMail: jdrosen@jdrosen.net
URI: http://www.jdrosen.net