Network Working Group H. Sinnreich, Ed.
Request for Comments: 5638 Adobe
Category: Informational A. Johnston
E. Shim
Avaya
K. Singh
Columbia University Alumni
September 2009
Network Working Group H. Sinnreich, Ed.
Request for Comments: 5638 Adobe
Category: Informational A. Johnston
E. Shim
Avaya
K. Singh
Columbia University Alumni
September 2009
Simple SIP Usage Scenario for Applications in the Endpoints
端点中应用程序的简单SIP使用场景
Abstract
摘要
For Internet-centric usage, the number of SIP-required standards for presence and IM and audio/video communications can be drastically smaller than what has been published by using only the rendezvous and session-initiation capabilities of SIP. The simplification is achieved by avoiding the emulation of telephony and its model of the intelligent network. 'Simple SIP' relies on powerful computing endpoints. Simple SIP desktop applications can be combined with rich Internet applications (RIAs). Significant telephony features may also be implemented in the endpoints.
对于以互联网为中心的使用，与仅使用SIP的会合和会话启动功能发布的标准相比，存在、IM和音频/视频通信所需的SIP标准数量可能会大大减少。这种简化是通过避免模拟电话及其智能网络模型来实现的。”“简单SIP”依赖于强大的计算端点。简单的SIP桌面应用程序可以与富Internet应用程序（RIA）结合使用。端点中还可以实现重要的电话功能。
This approach for SIP reduces the number of SIP standards with which to comply -- from roughly 100 currently, and still growing, to about 11.
SIP的这种方法减少了需要遵守的SIP标准的数量——从目前的大约100个，并且还在增长，减少到大约11个。
References for NAT traversal and for security are also provided.
还提供了NAT遍历和安全性的参考。
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 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 BSD License.
包括信托法律条款第4.e节所述的简化BSD许可证文本，且不提供BSD许可证中所述的担保。
Table of Contents
目录
1. Introduction ....................................................3
2. The Endpoint in the SIP and Web Architectures ...................5
2.1. The Telephony Gateway as a SIP Endpoint ....................6
3. Applicability for Simple SIP in the Endpoints ...................7
3.1. What Simple SIP Can Accomplish .............................7
3.2. Baseline for Simple SIP ....................................7
3.3. What Simple SIP May or May Not Accomplish ..................8
3.4. What Is Out of Scope for Simple SIP ........................8
3.5. Borderline Cases ...........................................9
4. Mandatory SIP References for Internet-Centric Usage .............9
4.1. RFC 3261: "SIP: Session Initiation Protocol" ..............10
4.2. RFC 4566: "SDP: Session Description Protocol" .............10
4.3. RFC 3264: "An Offer/Answer Model with Session
Description Protocol (SDP)" ...............................10
4.4. RFC 3840: "Indicating User Agent Capabilities in
the Session Initiation Protocol (SIP)" ....................10
4.5. RFC 3263: "Session Initiation Protocol (SIP):
Locating SIP Servers" .....................................11
4.6. RFC 3265: "Session Initiation Protocol
(SIP)-Specific Event Notification" ........................11
4.7. RFC 3856: "A Presence Event Package for the
Session Initiation Protocol (SIP)" ........................11
4.8. RFC 3863: "Presence Information Data Format (PIDF)" .......11
4.9. RFC 3428: "Session Initiation Protocol (SIP)
Extension for Instant Messaging" ..........................12
4.10. RFC 4474: "Enhancements for Authenticated
Identity Management in the Session Initiation
Protocol (SIP)" ..........................................12
4.11. RFC 3581: "An Extension to the Session Initiation
Protocol (SIP) for Symmetric Response Routing" ...........12
4.12. Updates to SIP-Related Protocols .........................12
5. SIP Applications in the Endpoints ..............................12
6. NAT Traversal ..................................................14
7. Security Considerations ........................................14
8. Acknowledgements ...............................................15
9. References .....................................................16
9.1. Normative References ......................................16
9.2. Informative References ....................................17
1. Introduction ....................................................3
2. The Endpoint in the SIP and Web Architectures ...................5
2.1. The Telephony Gateway as a SIP Endpoint ....................6
3. Applicability for Simple SIP in the Endpoints ...................7
3.1. What Simple SIP Can Accomplish .............................7
3.2. Baseline for Simple SIP ....................................7
3.3. What Simple SIP May or May Not Accomplish ..................8
3.4. What Is Out of Scope for Simple SIP ........................8
3.5. Borderline Cases ...........................................9
4. Mandatory SIP References for Internet-Centric Usage .............9
4.1. RFC 3261: "SIP: Session Initiation Protocol" ..............10
4.2. RFC 4566: "SDP: Session Description Protocol" .............10
4.3. RFC 3264: "An Offer/Answer Model with Session
Description Protocol (SDP)" ...............................10
4.4. RFC 3840: "Indicating User Agent Capabilities in
the Session Initiation Protocol (SIP)" ....................10
4.5. RFC 3263: "Session Initiation Protocol (SIP):
Locating SIP Servers" .....................................11
4.6. RFC 3265: "Session Initiation Protocol
(SIP)-Specific Event Notification" ........................11
4.7. RFC 3856: "A Presence Event Package for the
Session Initiation Protocol (SIP)" ........................11
4.8. RFC 3863: "Presence Information Data Format (PIDF)" .......11
4.9. RFC 3428: "Session Initiation Protocol (SIP)
Extension for Instant Messaging" ..........................12
4.10. RFC 4474: "Enhancements for Authenticated
Identity Management in the Session Initiation
Protocol (SIP)" ..........................................12
4.11. RFC 3581: "An Extension to the Session Initiation
Protocol (SIP) for Symmetric Response Routing" ...........12
4.12. Updates to SIP-Related Protocols .........................12
5. SIP Applications in the Endpoints ..............................12
6. NAT Traversal ..................................................14
7. Security Considerations ........................................14
8. Acknowledgements ...............................................15
9. References .....................................................16
9.1. Normative References ......................................16
9.2. Informative References ....................................17
The Session Initiation Protocol (SIP) has become the global standard for real-time multimedia communications over the Internet and in private IP networks, due to its adoption by service providers and in enterprise networks alike. The cost of this success has been a continuing increase in complexity to accommodate the various requirements for such networks. At the same time, the World Wide Web has become the platform for a boundless variety of rich Internet applications (RIAs), both in the browser and on the desktop. For SIP to be useful for RIAs, requirements for legacy voice-service providers that add unnecessary complexity may be avoided by delegating the interworking to telephony gateway endpoints. This usage scenario for SIP requires following the end-to-end principle of the Internet architecture at the application level or, in other words, placing SIP applications in the endpoints.
会话发起协议（SIP）已成为Internet和专用IP网络上实时多媒体通信的全球标准，因为它被服务提供商和企业网络采用。这一成功的代价是复杂性的不断增加，以适应此类网络的各种需求。与此同时，万维网已经成为浏览器和桌面上各种丰富互联网应用程序（RIA）的平台。为了使SIP对RIA有用，可以通过将互通委托给电话网关端点来避免对增加不必要复杂性的传统语音服务提供商的要求。SIP的这种使用场景要求在应用程序级别遵循Internet体系结构的端到端原则，或者换句话说，将SIP应用程序放置在端点中。
There are several reasons, from the Web service's perspective, to place most or all SIP applications in the endpoints and just use the client-server (CS) or peer-to-peer (P2P) rendezvous function for SIP:
从Web服务的角度来看，将大部分或所有SIP应用程序放置在端点中，并仅使用客户端-服务器（CS）或对等（P2P）汇聚功能进行SIP有几个原因：
1. Value proposition: SIP applications in the endpoints can be easily mixed with RIAs and thus enable service providers to offer new services in a scalable and flexible manner. Mixing SIP applications with RIAs also significantly enhances the value of SIP applications. Rich Internet applications support unrestricted user choice as an alternative that is beyond what is traditionally prepackaged as network-based communication service plans.
1. 价值主张：端点中的SIP应用程序可以轻松地与RIA混合，从而使服务提供商能够以可扩展和灵活的方式提供新服务。将SIP应用程序与RIA混合使用还可以显著提高SIP应用程序的价值。富Internet应用程序支持无限制的用户选择，这是传统上预先打包为基于网络的通信服务计划之外的另一种选择。
2. Eliminating the problems associated with distributed SIP applications in various feature servers across the network allows us to greatly simplify SIP. There is also the Internet end-to-end principle, which argues that network intermediaries cannot completely understand the applications and their state in the endpoints.
2. 消除与网络中各种功能服务器中的分布式SIP应用程序相关的问题，可以大大简化SIP。还有互联网端到端原则，它认为网络中介无法完全理解应用程序及其在端点中的状态。
'Simple SIP' in this document refers the SIP functions necessary to support only the rendezvous and session-setup functions of SIP, voice, video, basic presence, instant messaging, and also security. Simple SIP is focused on providing a basic multimedia, real-time communications "call". This includes presence, instant messaging, voice, and video for point-to-point and various conference applications. One or a very small number of additional servers may also be provided; for example, a voice-mail server may be provided as an auxiliary to make a simple one-to-one call to voice mail if the callee does not answer or to check voice mail.
本文档中的“简单SIP”指仅支持SIP、语音、视频、基本状态、即时消息和安全的会合和会话设置功能所需的SIP功能。Simple SIP专注于提供基本的多媒体实时通信“呼叫”。这包括点对点和各种会议应用程序的状态、即时消息、语音和视频。还可提供一台或少量额外服务器；例如，可以提供语音邮件服务器作为辅助设备，以便在被叫人不应答时对语音邮件进行简单的一对一呼叫或检查语音邮件。
Once the applications in the endpoints have established basic communications, it is up to them to support available features selected by users. This paper is targeted to such scenarios. In telephony, most of the value to users and service providers alike is added by signaling. By contrast, on the Web, RIAs add most of the value. The integrated use of SIP and RIAs in the endpoints can combine the best of both.
一旦端点中的应用程序建立了基本通信，就由它们来支持用户选择的可用功能。本文就是针对这样的场景。在电话技术中，对用户和服务提供商来说，大部分价值都是通过信令增加的。相比之下，在网络上，RIA增加了大部分价值。在端点中集成使用SIP和RIA可以将两者的优点结合起来。
This approach limits the number of SIP standards to roughly 11 that are listed here as the core for simple SIP. At the time of this writing, the Real-Time Applications and Infrastructure (RAI) area of the IETF is focused on a dedicated working group for the core SIP protocol, separate from various SIP applications. We anticipate this emerging work will also be the core of what is termed here as simple SIP and will actually further reduce the number of references that reflect the present core SIP standards.
这种方法将SIP标准的数量限制在大约11个，这些标准在这里被列为简单SIP的核心。在撰写本文时，IETF的实时应用程序和基础设施（RAI）领域专注于核心SIP协议的专用工作组，独立于各种SIP应用程序。我们预计，这项新兴工作也将成为这里所称的简单SIP的核心，并将进一步减少反映当前核心SIP标准的参考文献数量。
This memo aims to shield Web application developers from the need to know or understand more than the core SIP protocol. The total number of references has been kept to a minimum and includes other related topics, such as examples for providing telephony services in the endpoints, NAT traversal, and security. The referenced papers are, however, entry points to these knowledge resources. Readers interested in a more detailed list of SIP topics, especially telephony, can follow up the short list here with the extensive list in "A Hitchhikers' Guide to SIP", RFC 5411 [12]. The guide has over 140 references for understanding most, but not all, of the published features of SIP in the IETF and elsewhere. There is also a Web site that automatically tracks the number of SIP-related RFCs [13]. Other standards and commercial organizations have greatly enlarged the published features of SIP as well. We could not actually provide a complete count on everything that has been published as some form of SIP-standard document.
本备忘录旨在使Web应用程序开发人员不再需要了解或理解核心SIP协议以外的内容。引用的总数保持在最低限度，并包括其他相关主题，例如在端点中提供电话服务的示例、NAT遍历和安全性。然而，参考文献是这些知识资源的入口点。对SIP主题的更详细列表感兴趣的读者，尤其是对电话感兴趣的读者，可以在“SIP搭便车指南”RFC 5411[12]中的详细列表中进一步了解短列表。该指南有140多篇参考文献，用于理解IETF和其他地方发布的大部分（但不是全部）SIP功能。还有一个网站可以自动跟踪SIP相关RFC的数量[13]。其他标准和商业组织也极大地扩展了SIP的公开特性。实际上，我们不能完全统计作为某种形式的SIP标准文档发布的所有内容。
NAT traversal is also a basic requirement for simple SIP. However, given the potential option of using the Host Identity Protocol (HIP) in SIP-enabled endpoints, as shown in Section 4, simple SIP may not require any standards other than those mentioned here. The alternative to HIP is to use SIP-specific protocols for NAT traversal, such as STUN (Simple Traversal of the UDP Protocol through NAT), TURN (Traversal Using Relay NAT), and ICE (Interactive Connectivity Establishment), as discussed in Section 4.
NAT遍历也是简单SIP的基本要求。然而，考虑到在支持SIP的端点中使用主机标识协议（HIP）的潜在选项，如第4节所示，简单SIP可能不需要除此处提到的标准之外的任何标准。HIP的替代方案是使用特定于SIP的协议进行NAT遍历，如第4节中讨论的STUN（通过NAT简单遍历UDP协议）、TURN（使用中继NAT进行遍历）和ICE（交互式连接建立）。
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 RFC 2119.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
SIP has been defined in RFC 3261 for rendezvous and session initiation. The usual example is the trapezoid model for communications between two endpoints placed in two different SIP service-provider domains. SIP is also flexible, since SIP applications beyond the rendezvous function can reside either in the SIP networks in additional feature and media servers or in the endpoints. SIP endpoints are our focus in this memo.
RFC 3261中定义了SIP，用于会合和会话启动。通常的例子是位于两个不同SIP服务提供商域中的两个端点之间的通信的梯形模型。SIP也很灵活，因为集合功能之外的SIP应用程序可以驻留在附加功能和媒体服务器的SIP网络中，也可以驻留在端点中。SIP端点是我们在本备忘录中的重点。
Since SIP has been invented, with much initial similarity between SIP and HTTP, the Web has evolved from a global access mechanism to static documents to a universal platform with rich interaction between the user and client. In most cases, the client is the browser, though recently dedicated Web desktop clients have emerged as well.
自从SIP被发明以来，SIP和HTTP之间有了很大的相似性，Web已经从一个全局访问机制演变为一个在用户和客户端之间具有丰富交互的通用平台。在大多数情况下，客户端是浏览器，尽管最近也出现了专用的Web桌面客户端。
The Web provides access to applications as well as to documents. It is beyond the scope of this memo to describe the application and network architectures of the Web. We will note, however, some of the new application and communication forms that have emerged on the Web as a result of a Darwinian evolution [30] rather than as a result of being defined in standards organizations. They are referred to as Rich Internet Applications.
Web提供对应用程序和文档的访问。描述Web的应用程序和网络体系结构超出了本备忘录的范围。然而，我们将注意到，一些新的应用程序和通信形式是达尔文进化[30]的结果，而不是在标准组织中定义的结果。它们被称为富互联网应用程序。
Examples of RIAs include social networks, blogs, wikis, web-based office and collaboration tools, as well as task-related apps for creating to-do lists, tracking time, combining geographic information with various applications (such as tracking exercise paths and recording the metrics), tracking airline flights, combining live video from events with results and comments, etc.
RIA的示例包括社交网络、博客、Wiki、基于网络的办公室和协作工具，以及用于创建待办事项列表、跟踪时间、将地理信息与各种应用程序相结合（如跟踪锻炼路径和记录指标）、跟踪航空航班、以及，将活动现场视频与结果和评论等相结合。
More information can be found at [31] and in the vast collection of books about RIAs.
更多信息可以在[31]和大量关于RIA的书籍中找到。
RIAs have positioned the browser (and associated Web desktop applications) as the dominant platform for a large variety of applications. They are universal application platforms, independent of network location, operating system, processor, or display size.
RIA将浏览器（以及相关的Web桌面应用程序）定位为各种应用程序的主导平台。它们是通用的应用程序平台，与网络位置、操作系统、处理器或显示器大小无关。
Behind the better-known Web applications are a wealth of new technologies that can enhance SIP-based communications, for example, the aggregation of data at runtime from several resources on the Internet. A variety of RIA components, such as found on interactive Web pages, can significantly improve the user experience of SIP-based communications. This is in contrast to the fixed interfaces found in most SIP user agents (UA), such as phones and desktop clients.
在更知名的Web应用程序背后，有大量新技术可以增强基于SIP的通信，例如，在运行时从Internet上的多个资源聚合数据。各种RIA组件（如交互式网页上的RIA组件）可以显著改善基于SIP的通信的用户体验。这与大多数SIP用户代理（UA）中的固定接口形成对比，如电话和桌面客户端。
The Web network and application architecture is very different from SIP service-provider networks at present, but the one point where they both meet is the end-user device of any shape: fixed or mobile.
Web网络和应用程序体系结构与目前的SIP服务提供商网络有很大不同，但它们的一个共同点是任何形状的最终用户设备：固定或移动。
The desire of SIP service providers to support new services in a scalable and flexible manner is incidentally easier to implement by the loose service coupling on the Web, as it is possible to characterize a service, or actually a mix of several service components (such as in a mash-up), with a URI. This is in contrast to network services registration being done by a central registrar. The Web architecture is also better suited for users to select and configure their applications and interaction mode with the client. The boundless variety of configurations of services and client settings on the Web is in contrast with the prepackaged services and fixed user-agent configurations in present SIP services.
顺便说一句，SIP服务提供商以可伸缩和灵活的方式支持新服务的愿望更容易通过Web上的松散服务耦合来实现，因为可以用URI来表征服务，或者实际上是几个服务组件的混合（例如在mashup中）。这与由中央注册机构进行的网络服务注册形成对比。Web体系结构也更适合用户选择和配置其应用程序以及与客户端的交互模式。Web上服务和客户端设置的各种配置与当前SIP服务中的预打包服务和固定用户代理配置形成对比。
Last but not least, program execution locally on the client is faster if the interaction with servers across the network is minimized.
最后但并非最不重要的一点是，如果网络中与服务器的交互最小化，则在客户端本地执行程序的速度会更快。
The motivation behind this memo is the potential of integrating SIP-based multimedia communications with access to RIAs on the Web. To mention a few scenarios: adding SIP- and RTP-based real-time communications to RIAs, integrating (from a user perspective) the SIP location service (not to be confused with geographic location services) with other desktop- and network-based geographic location services, using social networks as part of the contact list, etc.
本备忘录背后的动机是将基于SIP的多媒体通信与访问Web上的RIA集成在一起的潜力。提到几个场景：将基于SIP和RTP的实时通信添加到RIA中，将SIP位置服务（不要与地理位置服务混淆）与其他基于桌面和网络的地理位置服务集成（从用户角度来看），将社交网络作为联系人列表的一部分，等等。
In order to accomplish interoperability with the installed base of telephone networks of various kinds, integrating SIP communications into RIAs precludes, in our opinion, carrying legacy telephony features over to the Web. Interoperability between the Internet and telephone networks is best left to gateways that look to the Web as special endpoints serving large numbers of users. Plain one-to-one phone calls are already supported by Internet-to-telephony gateways. If added, PSTN (Public Switched Telephone Network) or ISDN telephony features must be exposed to Web users; visual Web display and interaction with the user is preferable to carrying the extremely complex SIP equivalents over into the Internet. On the Internet side of telephony gateways, simple SIP is all that needs to be deployed, in our opinion. Additional telephony features can be just another RIA hosted in the gateway. The market is the best indicator to show if such an effort is worthwhile to be productized.
为了实现与各种电话网络的安装基础的互操作性，我们认为，将SIP通信集成到RIA中排除了将传统电话功能传送到Web的可能性。互联网和电话网络之间的互操作性最好留给那些将Web视为服务于大量用户的特殊端点的网关。Internet到电话网关已经支持普通的一对一电话呼叫。如果增加，PSTN（公共交换电话网）或ISDN电话功能必须向网络用户公开；与将极其复杂的SIP等价物传送到Internet相比，可视化Web显示和与用户的交互更可取。我们认为，在电话网关的互联网端，只需要部署简单的SIP。附加的电话功能可以是网关中承载的另一个RIA。市场是表明这种努力是否值得生产的最佳指标。
Overloading simple SIP with telephony features is a non-objective, as detailed in Section 3.
如第3节所述，使用电话功能重载简单SIP不是一个目标。
This section aims to clarify the scope of applicability by considering what can be done better in the endpoints, what simple SIP for user agents can and cannot accomplish, and what is out of scope. We will use emergency calls as an example to illustrate these points on applicability. Emergency calls are also a good example for considering if and when SIP-plus-RIA applications could be used as emergency telephony enhancements or even replacements.
本节旨在通过考虑在端点中可以做得更好的方面、用户代理的简单SIP可以完成和不能完成的方面以及超出范围的方面来澄清适用范围。我们将以紧急呼叫为例来说明这些适用性要点。紧急呼叫也是一个很好的例子，可以用来考虑SIP plus RIA应用程序是否以及何时可以用作紧急电话功能增强甚至替换。
The main goal for SIP applications on the desktop or in the browser is to support the integration of SIP- and RTP-based real-time communications with RIAs. This assumes powerful endpoints, such as PC/laptop, smart mobile phones, or various dedicated devices.
桌面或浏览器中SIP应用程序的主要目标是支持基于SIP和RTP的实时通信与RIA的集成。这需要强大的端点，如PC/笔记本电脑、智能移动电话或各种专用设备。
Example of better functionality: emergency calls not limited to a Public Safety Access Point (PSAP), but extended to a medical service taking care of patients or elderly people.
更好的功能示例：紧急呼叫不限于公共安全接入点（PSAP），而是扩展到照顾患者或老人的医疗服务。
In this example, besides alerting the right medical provider of the emergency, vital body-sign data and video can also be transmitted. In the opposite direction, the caller may get visual and audio information and instructions for instant self-help. In this scenario, there is no need to invoke a PSAP service. A dedicated device for such scenarios may actually have an emergency medical call button, though for telephone calls to a PSAP this is not recommended [14]. Powerful endpoints may also have various means to determine the geographic location of the caller and transmit it to the emergency care provider. In this and other examples, SIP voice may be a component of several other communications means, but not always the central one; some emergency communications and data transfer may actually be performed without voice, such as instances when the "caller" cannot speak for some reason.
在本例中，除了向正确的医疗提供者发出紧急警报外，还可以传输生命体征数据和视频。相反，呼叫者可能会获得视觉和音频信息以及即时自助的指示。在这种情况下，不需要调用PSAP服务。这种情况下的专用设备实际上可能有紧急医疗呼叫按钮，但对于PSAP的电话呼叫，不建议这样做[14]。功能强大的端点还可以有各种方法来确定呼叫者的地理位置，并将其传输给急救提供者。在该示例和其他示例中，SIP语音可以是若干其他通信手段的组件，但并不总是中心通信手段；一些紧急通信和数据传输实际上可能在没有语音的情况下执行，例如“呼叫者”由于某种原因无法说话的情况。
The focus of the memo is to define the baseline for simple SIP: the establishment of a one-to-one real-time multimedia communication session for presence, IM, voice, and video. Adequate security must also be provided; authentication and encryption for the media and for parts of the signaling should be done in a manner consistent with the routing of SIP messages.
备忘录的重点是定义简单SIP的基线：为状态、IM、语音和视频建立一对一的实时多媒体通信会话。还必须提供充分的安全保障；媒体和部分信令的身份验证和加密应以与SIP消息路由一致的方式进行。
There are border cases where simple SIP may or may not accomplish some necessary legacy function. Example: an emergency call to a PSAP over the Internet may be supported using the SOS URN [15] and the LoST protocol [16] to determine where to route the call. If, however, emergency calls must be routed over the PSTN to a country-specific telephone number, the assistance of a SIP proxy and also of a SIP-PSTN gateway is required to recognize and route the emergency call. Depending on the local jurisdiction, emergency calls from a SIP UA may require other features that are beyond the scope of this memo.
在某些情况下，简单的SIP可能完成也可能无法完成某些必要的遗留功能。示例：可以使用SOS URN[15]和LoST协议[16]来支持通过互联网对PSAP进行紧急呼叫，以确定呼叫路由。但是，如果紧急呼叫必须通过PSTN路由到特定于国家/地区的电话号码，则需要SIP代理以及SIP-PSTN网关的协助来识别和路由紧急呼叫。根据当地管辖权的不同，SIP UA的紧急呼叫可能需要本备忘录范围以外的其他功能。
The simple usage of SIP is applicable when avoiding the traditional voice-provider approaches for charging (or monetizing) that aim to provide, manage, and charge for what is referred to as services (not applications); some examples of such approaches to charging are listed here. Simple SIP means to avoid placing any functions in the network other than the rendezvous function of SIP. This includes avoiding:
SIP的简单用法适用于避免传统的语音提供商收费（或货币化）方法，其目的是提供、管理和收费所谓的服务（而不是应用）；这里列出了一些此类收费方法的示例。简单SIP意味着避免在网络中放置SIP的会合功能以外的任何功能。这包括避免：
o support of legacy telephony functions, such as emulating public-telephone-switch services and voice-only private branch exchanges.
o 支持传统电话功能，例如模拟公用电话交换机服务和仅语音专用分支交换机。
o SIP network architectures designed to support telephony-type network models. Examples include long chains of SIP proxies and feature servers (more than the two SIP servers shown in RFC 3261) that may be encountered inside and between closed Voice over IP (VoIP) networks and in-transit VoIP networks in between. Long chains of intermediaries of any type not only add complexity, they pose a security risk that increases with the number of SIP network elements. Complex server-based networks also make it more difficult to introduce new services. A special problem in SIP server chains is forking, which leads to the well-known problems of concurrency in computing; the so-called race conditions in telephony. This is amplified by redesigning the whole network every time there is a new SIP routing requirement.
o 设计用于支持电话类型网络模型的SIP网络体系结构。示例包括SIP代理和功能服务器的长链（RFC 3261中所示的两个以上的SIP服务器），它们可能在封闭的IP语音（VoIP）网络内部和之间以及在传输中的VoIP网络之间遇到。任何类型的长链中介体不仅增加了复杂性，还带来了随着SIP网络元素数量增加而增加的安全风险。复杂的基于服务器的网络也使得引入新服务更加困难。SIP服务器链中的一个特殊问题是分叉，这导致了众所周知的计算并发问题；电话中所谓的竞争条件。每当出现新的SIP路由需求时，通过重新设计整个网络，这一点就被放大了。
o support for legacy telephony models, such as identifying end-user devices for the purpose of differentiated charging by type of service or for charging for roaming between networks.
o 支持传统电话模型，例如识别终端用户设备，以便按服务类型进行区分计费或在网络之间漫游收费。
o policies and the associated policy servers and network elements for Quality of Service (QoS) to enforce service-rate-specific policies for real-time communications.
o 用于服务质量（QoS）的策略以及相关策略服务器和网络元素，以强制执行实时通信的特定于服务速率的策略。
o design considerations for SIP for compatibility with legacy telephony networks, traditional telephony services, and various telephone numbering plans. This pushes the responsibility of mapping the URI to telephone numbers to edge networks where the IP-PSTN gateway functions are performed. The handling of telephony-specific functions, such as early media, are also pushed to edge gateway networks. Other design considerations for interworking with the PSTN and 'looking like the PSTN' are also avoided.
o SIP的设计考虑与传统电话网络、传统电话服务和各种电话编号计划的兼容性。这将URI映射到电话号码的责任推到执行IP-PSTN网关功能的边缘网络。电话特定功能（如早期媒体）的处理也推送到边缘网关网络。还避免了与PSTN互通和“看起来像PSTN”的其他设计考虑。
This list is not exhaustive, but conveys the concept of what to avoid when using SIP as a simpler protocol to understand and to implement.
此列表并非详尽无遗，但传达了将SIP用作更简单的协议来理解和实现时应避免的概念。
There are also some interesting borderline cases for what to avoid, such as Provisional Response Acknowledgements (PRACKs), specified in RFC 3262. PRACK is targeted for multi-hop SIP server networks and PSTN interworking, especially to assure reliable early media. PRACK can be delegated, albeit with some limitations to the SIP-PSTN gateway. PRACK does little to improve the user experience and has no relevance on true broadband networks with minimal SIP hop counts. Using PRACK may therefore be a decision best left to designers.
还有一些有趣的临界情况需要避免，例如RFC 3262中指定的临时响应确认（PRACK）。PRACK的目标是多跳SIP服务器网络和PSTN互通，尤其是确保可靠的早期媒体。PRACK可以被委派，尽管对SIP-PSTN网关有一些限制。PRACK在改善用户体验方面做得很少，在真正的宽带网络中，SIP跳数最少，这与PRACK无关。因此，使用PRACK可能是最好留给设计师的决定。
Another interesting example of a borderline case are the issues with SIP's Non-Invite transactions as discussed in RFC 4320 [17]. Long chains of SIP intermediaries complicate the handling of provisional responses and may create several problems, such as storms of late responses from forked SIP forwarding paths. We mentioned that long chains of SIP intermediaries are out of scope for simple SIP, but since designers may encounter various scenarios, even those they don't like, the decision to conform the user agent (UA) to RFC 4320 is best left to them.
另一个有趣的边缘案例是RFC 4320[17]中讨论的SIP的非邀请事务问题。SIP中介的长链使临时响应的处理复杂化，并可能产生一些问题，例如来自分叉SIP转发路径的延迟响应风暴。我们提到，SIP中介的长链超出了简单SIP的范围，但由于设计者可能会遇到各种场景，甚至是他们不喜欢的场景，因此将用户代理（UA）符合RFC 4320的决定最好留给他们。
The list of borderline cases is also not exhaustive and the above are only examples. So where is the borderline? We believe that SIP usage on the Internet, without any intermediaries designed to support closed VoIP networks, eliminates the borderline cases. Enterprise SIP networks are also most useful when designed to work with the Internet model in mind, by giving enterprise users the benefit of SIP-enhanced Web applications for productivity. Handling of SIP in enterprise firewalls is out of the scope of this memo.
边界案件清单也并非详尽无遗，以上只是例子。那么边界在哪里呢？我们认为，在互联网上使用SIP，没有任何旨在支持封闭式VoIP网络的中介，消除了边缘案例。企业SIP网络在设计时考虑到Internet模型，通过为企业用户提供SIP增强的Web应用程序以提高生产力的好处，也是最有用的。在企业防火墙中处理SIP不在本备忘录的范围之内。
Here is the minimal set of mandatory references to support the Internet-centric approach to SIP, outlined above. The minimal set of references defines simple SIP.
下面是支持以互联网为中心的SIP方法的最少一组强制性参考，如上所述。最小的引用集定义了简单的SIP。
The proposed change process [29] for SIP in the IETF RAI area will define the updated SIP core specification and thus reduce even more the required SIP standards for what is referred to here as simple SIP.
IETF RAI区域内SIP的拟议变更过程[29]将定义更新后的SIP核心规范，从而进一步降低此处所指的简单SIP所需的SIP标准。
RFC 3261 [1] is the core specification for SIP. The trapezoid model for SIP, found in RFC 3261, is only an example and a use case applicable to two service providers featuring an outgoing SIP proxy and an incoming SIP proxy in each domain respectively. However, SIP can also work in peer-to-peer (P2P) communications without SIP servers.
RFC 3261[1]是SIP的核心规范。RFC3261中的SIP梯形模型只是一个示例和一个用例，适用于两个服务提供商，分别在每个域中具有一个传出SIP代理和一个传入SIP代理。然而，SIP也可以在没有SIP服务器的对等（P2P）通信中工作。
SDP [2] is the standard format for the representation of media parameters, transport addresses, and other session data irrespective of the protocol used to transport the SDP data. SIP is one of the protocols used to transport SDP data, to enable the setting up of multimedia communication sessions. Other Internet application protocols use SDP as well.
SDP[2]是表示媒体参数、传输地址和其他会话数据的标准格式，与用于传输SDP数据的协议无关。SIP是用于传输SDP数据的协议之一，用于建立多媒体通信会话。其他互联网应用程序协议也使用SDP。
4.3. RFC 3264: "An Offer/Answer Model with Session Description Protocol (SDP)"
4.3. RFC 3264：“具有会话描述协议（SDP）的提供/应答模型”
Though SDP has the capability to describe SIP sessions, how to arrive at a common description by two SIP endpoints requires a negotiation procedure to agree on common media codecs, along with IP addresses and ports where the media can be received. This negotiation procedure is specified in RFC 3264 [3]. As will be seen in Section 6, this negotiation is usually considerably complicated due to the existence of NAT between the SIP endpoints.
尽管SDP具有描述SIP会话的能力，但如何通过两个SIP端点获得公共描述，需要一个协商过程来商定公共媒体编解码器，以及可以接收媒体的IP地址和端口。RFC 3264[3]中规定了该协商程序。如第6节所示，由于SIP端点之间存在NAT，这种协商通常相当复杂。
4.4. RFC 3840: "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)"
4.4. RFC 3840：“指示会话启动协议（SIP）中的用户代理功能”
A SIP UA can convey its capability in the Contact header field, indicating if it can support presence, IM, audio, or video, and if the device is fixed, mobile, or other, such as the endpoint being an automaton (voice mail for example). Which SIP methods are supported may also be indicated as specified in RFC 3840 [4]. SIP registrars (SIP servers or the P2P SIP overlay) can be informed of endpoint capabilities. Missing capabilities can be displayed for the user by, for example, grayed out or missing icons.
SIP UA可以在联系人报头字段中传送其能力，指示其是否可以支持存在、IM、音频或视频，以及设备是否是固定的、移动的或其他的，例如端点是自动机（例如语音邮件）。支持哪些SIP方法也可以按照RFC 3840[4]中的规定进行指示。SIP注册器（SIP服务器或P2P SIP覆盖）可以被告知端点功能。缺失的功能可以通过（例如）灰显或缺失的图标为用户显示。
4.5. RFC 3263: "Session Initiation Protocol (SIP): Locating SIP Servers"
4.5. RFC 3263:“会话启动协议（SIP）：定位SIP服务器”
RFC 3263 [5] adds key clarifications to the base SIP specification in RFC 3261 by specifying how a SIP user agent (UA) or SIP server can determine with DNS queries not only the IP addresses of the target SIP servers, but also which SIP servers can support UDP or TCP transport, as required. TCP may be required to support secure SIP (SIPS) using Transport Layer Security (TLS) transport or when SIP messages are too large to fit into UDP packets without fragmentation. Successive DNS queries yield finer-grain location by providing NAPTR, SRV, and A type records. Note that finding a SIP server requires several successive DNS queries to access these records.
RFC 3263[5]通过指定SIP用户代理（UA）或SIP服务器如何通过DNS查询不仅确定目标SIP服务器的IP地址，而且根据需要确定哪些SIP服务器可以支持UDP或TCP传输，从而为RFC 3261中的基本SIP规范添加了关键澄清。TCP可能需要使用传输层安全性（TLS）传输来支持安全SIP（SIPS），或者当SIP消息太大而无法装入UDP数据包而没有碎片时，TCP可能需要支持安全SIP（SIPS）。连续的DNS查询通过提供NAPTR、SRV和A类型记录产生更精细的位置。请注意，查找SIP服务器需要几个连续的DNS查询才能访问这些记录。
Locating SIP servers is also required for P2P SIP when a peer node wishes to communicate with a SIP UA outside its own P2P SIP overlay network.
当对等节点希望在其自己的P2P-SIP覆盖网络之外与SIP-UA通信时，P2P-SIP也需要定位SIP服务器。
4.6. RFC 3265: "Session Initiation Protocol (SIP)-Specific Event Notification"
4.6. RFC 3265：“会话启动协议（SIP）-特定事件通知”
RFC 3265 [6] provides an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. The most prominent event notifications are those used for presence, though SIP events are used for many other SIP services, some of which can be useful for simple SIP.
RFC 3265[6]提供了一个可扩展的框架，通过该框架，SIP节点可以从远程节点请求通知，指示某些事件已经发生。最显著的事件通知是用于状态的通知，尽管SIP事件用于许多其他SIP服务，其中一些对于简单SIP很有用。
4.7. RFC 3856: "A Presence Event Package for the Session Initiation Protocol (SIP)"
4.7. RFC 3856：“会话启动协议（SIP）的状态事件包”
RFC 3856 [7] defines the usage of SIP as a presence protocol and makes use of the SUBSCRIBE and NOTIFY methods for presence events. SIP location services already contain presence information in the form of registrations and, as such, can be reused to establish connectivity for subscriptions and notifications. This can enable either endpoints or servers to support rich applications based on presence.
RFC 3856[7]将SIP定义为存在协议，并使用SUBSCRIBE和NOTIFY方法处理存在事件。SIP位置服务已经包含注册形式的状态信息，因此，可以重用这些信息来建立订阅和通知的连接。这可以使端点或服务器支持基于状态的丰富应用程序。
RFC 3863 [8] defines the Presence Information Data Format (PIDF) and the media type "application/pidf+xml" to represent the XML MIME entity for PIDF. PIDF is used by SIP to carry presence information.
RFC 3863[8]定义了状态信息数据格式（PIDF）和媒体类型“application/PIDF+xml”，以表示PIDF的xml MIME实体。SIP使用PIDF来携带状态信息。
4.9. RFC 3428: "Session Initiation Protocol (SIP) Extension for Instant Messaging"
4.9. RFC 3428：“即时消息的会话启动协议（SIP）扩展”
The SIP extension for IM in RFC 3428 [9] consists in the MESSAGE method (defined in RFC 3428) only for the pager model of IM, based on the assumption that an IM conversation state exists in the client interface in the endpoints or in the mind of the users.
RFC 3428[9]中IM的SIP扩展包含消息方法（在RFC 3428中定义），该方法仅适用于IM的寻呼机模型，基于以下假设，即IM会话状态存在于端点的客户端接口或用户的头脑中。
4.10. RFC 4474: "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)"
4.10. RFC 4474：“会话启动协议（SIP）中身份验证管理的增强功能”
RFC 4474 [10] defines (1) an identity header and (2) an identity info header for SIP requests that carry, respectively, the signature of the issuer over parts of the SIP request and the signed identity information. The signature includes the FROM header and the identity of the sender. The associated identity info header identifies the sender of the SIP request, such as INVITE. The issuer of the signature can present their certificate as well. It is assumed the issuer may be the domain owner. Strong authentication is thus provided for SIP requests. Authentication for SIP responses is not defined in this document.
RFC 4474[10]为SIP请求定义了（1）标识头和（2）标识信息头，这些SIP请求分别在部分SIP请求和已签名标识信息上携带发卡机构的签名。签名包括发件人标头和发件人的身份。关联的标识信息标头标识SIP请求的发送方，例如INVITE。签名的颁发者也可以出示他们的证书。假定颁发者可能是域所有者。因此，为SIP请求提供了强身份验证。本文档中未定义SIP响应的身份验证。
4.11. RFC 3581: "An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing"
4.11. RFC 3581：“用于对称响应路由的会话启动协议（SIP）的扩展”
RFC 3581 [11] specifies an extension to SIP called "rport" so that responses are sent back to the source IP address and port from which the request originated. This correction to RFC 3261 is helpful for NAT traversal, debugging, and support of multi-homed hosts.
RFC 3581[11]指定了一个名为“rport”的SIP扩展，以便将响应发送回发起请求的源IP地址和端口。对RFC3261的此更正有助于NAT遍历、调试和支持多宿主主机。
Several of the above are being updated to benefit from the experience of large deployments and frequent interoperability testing. We recommend readers to constantly check for revisions. One update example is "Correct Transaction Handling for 200 Responses to the Session Initiation Protocol INVITE Requests" [18]. This is an update to RFC 3261; the added security risk for misbehaving SIP UAs is handled in the forwarding SIP proxy.
以上几项正在更新，以受益于大型部署和频繁互操作性测试的经验。我们建议读者经常检查修订。一个更新示例是“会话启动协议邀请请求的200个响应的正确事务处理”[18]。这是对RFC 3261的更新；行为不端的SIP UAs增加的安全风险在转发SIP代理中处理。
Although the present adoption of SIP is mainly due to telephony applications, its roots are in the Web and it has initial similarity to HTTP. As a result, SIP may play other roles in adequately powerful endpoints (their number keeps increasing with Moore's law). SIP-based multimedia communications may be linked with various other applications on the Web. Either some non-SIP application or the
虽然目前SIP的采用主要是由于电话应用，但它的根源在于Web，并且它最初与HTTP相似。因此，SIP可能在功能足够强大的端点中扮演其他角色（它们的数量随着摩尔定律不断增加）。基于SIP的多媒体通信可以与Web上的各种其他应用程序链接。一些非SIP应用程序或
communication feature may be perceived as the primary usage. An example is mixing SIP-based real-time communications with some Web content of high interest to the user.
通信功能可被视为主要用途。例如，将基于SIP的实时通信与用户感兴趣的一些Web内容混合在一起。
Examples:
示例：
1. In a conversation between a consumer and the contact center, a Web conference can be invoked to present to the user buying options or help information. This information can make use of mashups to combine real-time data from various sources on the Web.
1. 在消费者与呼叫中心之间的对话中，可以调用Web会议向用户展示购买选项或帮助信息。这些信息可以利用mashup来组合来自Web上各种来源的实时数据。
2. In a social network, multimedia conversations combined with Web mashups can be invoked, thus strengthening the bond between its members.
2. 在社交网络中，可以调用多媒体对话和Web mashup，从而加强其成员之间的联系。
3. Conversations can be invoked while watching some events on the Web in real time. However, the main beneficiary in this case may be the Web site, since the conversation can prolong the time for users watching that Web site.
3. 可以在实时观看Web上的某些事件时调用对话。然而，这种情况下的主要受益者可能是网站，因为对话可以延长用户观看该网站的时间。
This shows the value of combining RIAs with SIP-based communications.
这显示了将RIA与基于SIP的通信相结合的价值。
It is a matter for the end user's judgment whether the Web content or the associated communication capability is more important, or if a mix of both is most attractive.
最终用户需要判断Web内容或相关的通信能力是否更重要，或者两者的组合是否最具吸引力。
Example: a Web-based enterprise directory where employees can find a wealth of data. Adding SIP multimedia communications to the enterprise directory to call someone (if online and not too busy) enhances its usefulness, but is not critical to the directory.
示例：基于Web的企业目录，员工可以在其中查找大量数据。将SIP多媒体通信添加到企业目录以呼叫某人（如果在线且不太忙），可以增强其有用性，但对目录并不重要。
SIP applications in the endpoints can, however, accomplish most telephony functions as well. This has been amply documented in SIP-related work in the IETF, such as:
然而，端点中的SIP应用程序也可以完成大多数电话功能。IETF中与SIP相关的工作中充分记录了这一点，例如：
o "A Call Control and Multi-party usage framework for SIP" [19] presents a large assortment of telephony applications where the call control resides in the participating endpoints that use the peer-to-peer feature invocation model. The peer-to-peer design and its principles are based on multiparty call control.
o “SIP的呼叫控制和多方使用框架”[19]介绍了大量电话应用程序，其中呼叫控制驻留在使用对等功能调用模型的参与端点中。对等设计及其原理基于多方呼叫控制。
o "Session Initiation Protocol Service Examples" [20] contains a collection of SIP call flows for traditional telephony, many of which require no server support for the respective features. The SIP service examples for telephony are extremely useful since they illustrate in detail the concepts and applications supported by the core simple SIP references.
o “会话启动协议服务示例”[20]包含传统电话的SIP呼叫流集合，其中许多呼叫流不需要服务器对各自功能的支持。电话SIP服务示例非常有用，因为它们详细说明了核心简单SIP参考支持的概念和应用程序。
In conclusion, SIP applications in the endpoints can support both a mix of real-time communications with new rich Internet applications and traditional telephony features as well.
总之，端点中的SIP应用程序既可以支持与新的富Internet应用程序的实时通信，也可以支持传统的电话功能。
SIP devices behind one or more NATs are, at present, the rule rather than the exception.
目前，一个或多个NAT背后的SIP设备是规则，而不是例外。
"Best Current Practices for NAT Traversal for SIP" [22] comprehensively summarizes the use of STUN, TURN, and ICE, and provides a definitive set of 'Best Common Practices' to demonstrate the traversal of SIP and its associated RTP media packets through NAT devices.
“针对SIP的NAT遍历的最佳当前实践”[22]全面总结了STUN、TURN和ICE的使用，并提供了一组确定的“最佳通用实践”，以演示通过NAT设备遍历SIP及其相关RTP媒体包。
The use of ICE has been developed mainly for SIP. Other proposals, such as NICE (generic for non-SIP) and "D-ICE" for Real Time Streaming Protocol (RTSP) streaming media, have also been proposed. Internet games have different NAT traversal techniques of their own. This list is not exhaustive and such approaches are based on different NAT traversal protocols for each application protocol, separately.
冰的使用主要是为了SIP。还提出了其他建议，如NICE（非SIP通用）和实时流协议（RTSP）流媒体的“D-ICE”。网络游戏有自己不同的NAT穿越技术。该列表并非详尽无遗，这些方法分别基于每个应用程序协议的不同NAT遍历协议。
A general, non-application-protocol-specific approach for NAT traversal is therefore highly desirable.
因此，非常需要一种通用的、非特定于应用程序协议的NAT遍历方法。
One approach for NAT traversal that is generic and applicable for all application protocols is to deploy the Host Identity Protocol (HIP) and solve NAT traversal only once, at the HIP level. HIP has many other useful features (such as support for the IPv6 transition in endpoints, mobility, and multihoming) that are beyond the scope of this paper. "Basic HIP Extensions for Traversal of Network Address Translators" [23] provides an extensive coverage of the use of HIP for NAT traversal.
NAT遍历的一种通用且适用于所有应用程序协议的方法是部署主机标识协议（HIP）并在HIP级别仅解决一次NAT遍历。HIP还有许多其他有用的功能（例如支持端点中的IPv6转换、移动性和多宿主），这些功能超出了本文的范围。“用于网络地址转换器遍历的基本HIP扩展”[23]广泛介绍了使用HIP进行NAT遍历。
Using HIP-enabled endpoints can provide the functions required for NAT traversal [24] for all applications, for both IPv4 and IPv6. HIP can thus simplify the SIP UA since it takes away the burden of NAT traversal from the SIP UA and moves it to the HIP protocol module in the endpoint.
使用支持HIP的端点可以为所有应用程序（IPv4和IPv6）提供NAT遍历[24]所需的功能。HIP因此可以简化SIP-UA，因为它消除了SIP-UA的NAT遍历负担，并将其移动到端点中的HIP协议模块。
All protocols discussed in this paper have their own specific security requirements that MUST be considered. The special security considerations for SIP signaling security and RTP media security are discussed here.
本文讨论的所有协议都有其特定的安全需求，必须加以考虑。这里讨论了SIP信令安全和RTP媒体安全的特殊安全注意事项。
SIP security has two main parts: transport security and identity.
SIP安全有两个主要部分：传输安全和身份。
o Transport security for SIP is specified in RFC 3261. Secure SIP has the notation SIPS in the request URI and uses TLS over TCP. Note that SIP over UDP cannot be secured in this way. Transport security works only hop by hop. Specifying SIPS requires the user to trust all intermediate servers and no end-to-end media encryption is assumed. There is no insurance for misbehaving intermediaries in the path. SIPS is therefore really adequate only in single-hop scenarios.
o RFC 3261中规定了SIP的传输安全性。安全SIP在请求URI中具有符号SIPS，并通过TCP使用TLS。请注意，UDP上的SIP不能以这种方式进行安全保护。交通安全只能一步一步地工作。指定SIPS要求用户信任所有中间服务器，并且假定没有端到端媒体加密。在这条道路上，行为不端的中介机构没有保险。因此，SIPS仅在单跳场景中才足够。
o RFC 4474, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", which is mentioned previously, specifies the use of certificates for secure identification of the parties involved in SIP signaling requests.
o RFC 4474，“会话发起协议（SIP）中认证身份管理的增强功能”，如前所述，规定了使用证书来安全标识SIP信令请求中涉及的各方。
o The Datagram Transport Layer Security (DTLS) specified in RFC 4347 [25] has wide applicability for other applications that require UDP transport. DTLS has been designed to have maximum commonality with TLS, yet does not require TCP transport and works over UDP. The DTLS-SRTP (Secure Realtime Transport Protocol) Framework [26] can support encrypted communications between endpoints using self-signed certificates whose fingerprints are exchanged over an integrity-protected SIP signaling channel. The SRTP master secret is derived using the DTLS exchange as described in [27].
o RFC 4347[25]中规定的数据报传输层安全性（DTLS）广泛适用于需要UDP传输的其他应用程序。DTLS被设计为与TLS具有最大的通用性，但不需要TCP传输，并且在UDP上工作。DTLS-SRTP（安全实时传输协议）框架[26]可以使用自签名证书支持端点之间的加密通信，自签名证书的指纹通过完整性保护的SIP信令信道进行交换。SRTP主密钥是使用DTLS交换导出的，如[27]所述。
o ZRTP [28] provides key agreement for SRTP for multimedia communication with voice without depending on SIP signaling, though it can utilize an integrity-protected SIP signaling path for authentication. ZRTP does not require the use of certificates or any Public Key Infrastructure (PKI). ZRTP provides best-effort SRTP encryption without any additional SIP extensions.
o ZRTP[28]为SRTP提供密钥协议，用于与语音进行多媒体通信，而不依赖SIP信令，尽管它可以利用完整性保护的SIP信令路径进行身份验证。ZRTP不需要使用证书或任何公钥基础设施（PKI）。ZRTP提供尽最大努力的SRTP加密，无需任何额外的SIP扩展。
The authors would like to thank Cullen Jennings, Ralph Droms, and Adrian Farrel for helpful comments in the most recent stage of this memo.
作者要感谢Cullen Jennings、Ralph Droms和Adrian Farrel在本备忘录的最新阶段所作的有益评论。
Special thanks are due to Paul Kyzivat for challenging the authors to clarify the role of telephony network gateways and also to Keith Drage for challenging them to discuss the use of emergency calls using simple SIP.
特别感谢Paul Kyzivat挑战作者澄清电话网络网关的作用，也感谢Keith Drage挑战他们讨论使用简单SIP的紧急呼叫。
Robert Sparks has pointed to some missing references, which we have added.
罗伯特·斯帕克斯（Robert Sparks）指出了一些缺失的参考资料，我们已经补充了这些参考资料。
The authors would also like to thank Jiri Kuthan, Adrian Georgescu, and others for the detailed discussion on the SIPPING WG list. As a result, we have added clarification of what simple SIP can do, what it does not aim to do, and some scenarios in between. We would also like to thank Wilhelm Wimmreuter for the detailed review of the initial draft and to Arjun Roychaudhury for the comments regarding the need to clarify the difference between network-based services and endpoint applications.
作者还要感谢Jiri Kuthan、Adrian Georgescu和其他人对啜饮工作组名单的详细讨论。因此，我们增加了对simple SIP可以做什么、它不打算做什么以及两者之间的一些场景的说明。我们还要感谢Wilhelm Wimmruter对初稿的详细审查，并感谢Arjun Roychaudhury就澄清基于网络的服务和端点应用之间的差异的必要性发表的意见。
[1] 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.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[2] Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[3] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[4] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[4] Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[5] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC3263，2002年6月。
[6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[6] Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[7] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[7] Rosenberg，J.，“会话启动协议（SIP）的状态事件包”，RFC3856，2004年8月。
[8] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[8] Sugano，H.，Fujimoto，S.，Klyne，G.，Batman，A.，Carr，W.，和J.Peterson，“状态信息数据格式（PIDF）”，RFC 38632004年8月。
[9] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[9] Campbell，B.，Ed.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.，和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 34282002年12月。
[10] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[10] Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年8月。
[11] Rosenberg, J. and H. Schulzrinne, "An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing", RFC 3581, August 2003.
[11] Rosenberg，J.和H.Schulzrinne，“对称响应路由会话启动协议（SIP）的扩展”，RFC 3581，2003年8月。
[12] Rosenberg, J., "A Hitchhiker's Guide to the Session Initiation Protocol (SIP)", RFC 5411, February 2009.
[12] Rosenberg，J.，“会话启动协议（SIP）搭便车指南”，RFC 5411，2009年2月。
[13] Ohlmeier, N., "VoIP RFC Watch", http://rfc3261.net/.
[13] Ohlmeier，N.，“VoIP RFC监视”，http://rfc3261.net/.
[14] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", Work in Progress, July 2009.
[14] Rosen，B.和J.Polk，“支持紧急呼叫的通信服务当前最佳实践”，正在进行的工作，2009年7月。
[15] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008.
[15] Schulzrinne，H.，“应急和其他知名服务的统一资源名称（URN）”，RFC 5031，2008年1月。
[16] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008.
[16] Hardie，T.，Newton，A.，Schulzrinne，H.，和H.Tschofenig，“丢失：一个位置到服务的翻译协议”，RFC 5222，2008年8月。
[17] Sparks, R., "Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4320, January 2006.
[17] Sparks，R.，“解决会话启动协议（SIP）非邀请事务已识别问题的措施”，RFC 4320，2006年1月。
[18] Sparks, R. and T. Zourzouvillys, "Correct Transaction Handling for 200 Responses to Session Initiation Protocol INVITE Requests", Work in Progress, July 2009.
[18] Sparks，R.和T.Zourzouvillys，“会话启动协议邀请请求的200个响应的正确事务处理”，正在进行的工作，2009年7月。
[19] Mahy, R., Sparks, R., Rosenberg, J., Petrie, D., and A. Johnson, "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", Work in Progress, March 2009.
[19] Mahy，R.，Sparks，R.，Rosenberg，J.，Petrie，D.，和A.Johnson，“会话启动协议（SIP）的呼叫控制和多方使用框架”，正在进行的工作，2009年3月。
[20] Johnston, A., Ed., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", BCP 144, RFC 5359, October 2008.
[20] Johnston，A.，Ed.，Sparks，R.，Cunningham，C.，Donovan，S.，和K.Summers，“会话启动协议服务示例”，BCP 144，RFC 5359，2008年10月。
[22] Boulton, C., Rosenberg, J., Camarillo, G. and F. Audet, "Best Current Practices for NAT Traversal for Client-Server SIP", Work in Progress, September 2008.
[22] Boulton，C.，Rosenberg，J.，Camarillo，G.和F.Audet，“客户端服务器SIP NAT遍历的最佳当前实践”，正在进行的工作，2008年9月。
[23] Komu, M., Henderson, T., Tschofenig, H., Melen, J. and A. Keraenen, "Basic HIP Extensions for Traversal of Network Address Translators", Work in Progress, June 2009.
[23] Komu，M.，Henderson，T.，Tschofenig，H.，Melen，J.和A.Keraenen，“网络地址转换器穿越的基本髋关节伸展”，正在进行的工作，2009年6月。
[24] Moskowitz, R., "HIP Experimentation using Teredo", July 2008, http://www.ietf.org/proceedings/08jul/slides/HIPRG-3.pdf.
[24] Moskowitz，R.，“使用Teredo进行髋关节实验”，2008年7月，http://www.ietf.org/proceedings/08jul/slides/HIPRG-3.pdf.
[25] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[25] Rescorla，E.和N.Modadugu，“数据报传输层安全”，RFC 4347，2006年4月。
[26] Fischl, J., Tschofenig, H. and E. Rescorla, "Framework for Establishing an SRTP Security Context using DTLS", Work in Progress, March 2009.
[26] Fischl，J.，Tschofenig，H.和E.Rescorla，“使用DTL建立SRTP安全上下文的框架”，正在进行的工作，2009年3月。
[27] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", Work in Progress, February 2009.
[27] McGrew，D.和E.Rescorla，“为安全实时传输协议（SRTP）建立密钥的数据报传输层安全性（DTLS）扩展”，正在进行的工作，2009年2月。
[28] Zimmerman, P., Johnston, A. and J. Callas, "ZRTP: Media Path Key Agreement for Secure RTP", Work in Progress, March 2009
[28] Zimmerman，P.，Johnston，A.和J.Callas，“ZRTP：安全RTP的媒体路径密钥协议”，正在进行的工作，2009年3月
[29] Peterson, J., Jennings, C. and R. Sparks, "Change Process for the Session Initiation Protocol (SIP)", Work in Progress, July 2009.
[29] Peterson，J.，Jennings，C.和R.Sparks，“会话启动协议（SIP）的更改过程”，正在进行的工作，2009年7月。
[30] Raman, T.V., "Toward 2 exp(W), Beyond Web 2.0", Communications of the ACM, Vol. 52, No.2, p. 52-59, February 2009.
[30] Raman，T.V.，“走向2 exp（W），超越Web 2.0”，《ACM通讯》，第52卷，第2期，第页。2009年2月52日至59日。
[31] Wikipedia, "Rich Internet application", http://en.wikipedia.org/wiki/Rich_Internet_Applications.
[31] 维基百科，“富互联网应用程序”，http://en.wikipedia.org/wiki/Rich_Internet_Applications.
Authors' Addresses
作者地址
Henry Sinnreich Adobe Systems, Inc. 601 Townsend Street, San Francisco, CA 94103, USA
亨利SnnReic Adobe系统公司，601汤森德街，旧金山，CA 94103，美国
EMail: henrys@adobe.com
EMail: henrys@adobe.com
Alan Johnston Avaya Saint Louis, MO, USA
美国密苏里州圣路易斯市艾伦·约翰斯顿·阿瓦亚
EMail: alan@sipstation.com
EMail: alan@sipstation.com
Eunsoo Shim Avaya Labs Research 233 Mount Airy Road Basking Ridge, NJ 07920 USA
美国新泽西州太阳岭艾里山路233号Eunsoo Shim Avaya实验室研究中心，邮编：07920
EMail: eunsooshim@gmail.com
EMail: eunsooshim@gmail.com
Kundan Singh Columbia University Alumni 1214 Amsterdam Ave., MC0401 New York, NY, USA
昆丹·辛格哥伦比亚大学校友，美国纽约州纽约市阿姆斯特丹大道1214号，MC0401
EMail: kns10@cs.columbia.edu
EMail: kns10@cs.columbia.edu