Internet Engineering Task Force (IETF) A. Uzelac, Ed.
Request for Comments: 6405 Global Crossing
Category: Informational Y. Lee, Ed.
ISSN: 2070-1721 Comcast Cable
November 2011
Internet Engineering Task Force (IETF) A. Uzelac, Ed.
Request for Comments: 6405 Global Crossing
Category: Informational Y. Lee, Ed.
ISSN: 2070-1721 Comcast Cable
November 2011
Voice over IP (VoIP) SIP Peering Use Cases
IP语音（VoIP）SIP对等用例
Abstract
摘要
This document depicts many common Voice over IP (VoIP) use cases for Session Initiation Protocol (SIP) peering. These use cases are categorized into static and on-demand, and then further sub-categorized into direct and indirect. These use cases are not an exhaustive set, but rather the most common use cases deployed today.
本文档描述了会话启动协议（SIP）对等的许多常见IP语音（VoIP）用例。这些用例分为静态用例和按需用例，然后进一步细分为直接用例和间接用例。这些用例并不是详尽的集合，而是今天部署的最常见的用例。
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/rfc6405.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6405.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Reference Architecture ..........................................3
4. Contexts of Use Cases ...........................................4
5. Use Cases .......................................................4
5.1. Static Peering Use Cases ...................................5
5.2. Static Direct Peering Use Case .............................5
5.2.1. Administrative Characteristics .....................10
5.2.2. Options and Nuances ................................10
5.3. Static Direct Peering Use Case - Assisting LUF and LRF ....11
5.3.1. Administrative Characteristics .....................12
5.3.2. Options and Nuances ................................12
5.4. Static Indirect Peering Use Case - Assisting LUF and LRF ..12
5.4.1. Administrative Characteristics .....................19
5.4.2. Options and Nuances ................................19
5.5. Static Indirect Peering Use Case ..........................19
5.5.1. Administrative Characteristics .....................20
5.5.2. Options and Nuances ................................21
5.6. On-Demand Peering Use Case ................................21
5.6.1. Administrative Characteristics .....................21
5.6.2. Options and Nuances ................................21
6. Acknowledgments ................................................22
7. Security Considerations ........................................22
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................23
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Reference Architecture ..........................................3
4. Contexts of Use Cases ...........................................4
5. Use Cases .......................................................4
5.1. Static Peering Use Cases ...................................5
5.2. Static Direct Peering Use Case .............................5
5.2.1. Administrative Characteristics .....................10
5.2.2. Options and Nuances ................................10
5.3. Static Direct Peering Use Case - Assisting LUF and LRF ....11
5.3.1. Administrative Characteristics .....................12
5.3.2. Options and Nuances ................................12
5.4. Static Indirect Peering Use Case - Assisting LUF and LRF ..12
5.4.1. Administrative Characteristics .....................19
5.4.2. Options and Nuances ................................19
5.5. Static Indirect Peering Use Case ..........................19
5.5.1. Administrative Characteristics .....................20
5.5.2. Options and Nuances ................................21
5.6. On-Demand Peering Use Case ................................21
5.6.1. Administrative Characteristics .....................21
5.6.2. Options and Nuances ................................21
6. Acknowledgments ................................................22
7. Security Considerations ........................................22
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................23
This document describes important Voice over IP (VoIP) use cases for SIP-based [RFC3261] peering. These use cases are determined by the Session PEERing for Multimedia INTerconnect (SPEERMINT) working group and will assist in identifying requirements and other issues to be considered for future resolution by the working group.
本文档描述了基于SIP的[RFC3261]对等的重要IP语音（VoIP）用例。这些用例由Session PEERing for Multimedia INTerconnect（SPEERMINT）工作组确定，将有助于确定需求和其他问题，供工作组将来解决。
Only use cases related to VoIP are considered in this document. Other real-time SIP communications use cases, like Instant Messaging (IM), video chat, and presence are out of scope for this document.
本文档仅考虑与VoIP相关的用例。其他实时SIP通信用例，如即时消息（IM）、视频聊天和状态，不在本文档的范围内。
The use cases contained in this document are described as comprehensive as possible, but should not be considered the exclusive set of use cases.
本文档中包含的用例尽可能全面地描述，但不应被视为唯一的用例集。
This document uses terms defined in [RFC5486]. Please refer to it for definitions.
本文件使用[RFC5486]中定义的术语。请参考它的定义。
The diagram below provides the reader with a context for the VoIP use cases in this document. Terms such as SIP Service Provider (SSP), Lookup Function (LUF), Location Routing Function (LRF), Signaling Path Border Element (SBE), and Data Path Border Element (DBE) are defined in [RFC5486].
下图为读者提供了本文档中VoIP用例的上下文。[RFC5486]中定义了SIP服务提供商（SSP）、查找功能（LUF）、位置路由功能（LRF）、信令路径边界元素（SBE）和数据路径边界元素（DBE）等术语。
The Originating SSP (O-SSP) is the SSP originating a SIP request. The Terminating SSP (T-SSP) is the SSP terminating the SIP request originating from the O-SSP. The assisting LUF and LRF Provider offer LUF and LRF services to the O-SSP. The Indirect SSP (I-SSP) is the SSP providing indirect peering service(s) to the O-SSP to connect to the T-SSP.
发起SSP（O-SSP）是发起SIP请求的SSP。终止SSP（T-SSP）是终止源自O-SSP的SIP请求的SSP。辅助LUF和LRF提供商向O-SSP提供LUF和LRF服务。间接SSP（I-SSP）是向O-SSP提供间接对等服务以连接到T-SSP的SSP。
+--------------------+------------------------+--------------------+
| Originating SSP | Assisting LUF and LRF | Terminating SSP |
| Domain | Provider Domain | Domain |
| | | |
| +-----+ +-----+ | +------+ +------+ | +-----+ +-----+ |
| |O-LUF| |O-LRF| | |A-LUF | | A-LRF| | |T-LUF| |T-LRF| |
| +-----+ +-----+ | +------+ +------+ | +-----+ +-----+ |
| | | |
| +-------+ +-----+ +------------------------+ +-----+ +-------+ |
| |O-Proxy| |O-SBE| | Indirect SSP Domain | |T-SBE| |T-Proxy| |
| +-------+ +-----+ | | +-----+ +-------+ |
| | +-----+ +-----+ | |
| +---+ +-----+ | |O-SBE| |O-DBE| | +-----+ +---+ |
| |UAC| |O-DBE| | +-----+ +-----+ | |T-DBE| |UAS| |
| +---+ +-----+ | | +-----+ +---+ |
| | | |
+--------------------+------------------------+--------------------+
+--------------------+------------------------+--------------------+
| Originating SSP | Assisting LUF and LRF | Terminating SSP |
| Domain | Provider Domain | Domain |
| | | |
| +-----+ +-----+ | +------+ +------+ | +-----+ +-----+ |
| |O-LUF| |O-LRF| | |A-LUF | | A-LRF| | |T-LUF| |T-LRF| |
| +-----+ +-----+ | +------+ +------+ | +-----+ +-----+ |
| | | |
| +-------+ +-----+ +------------------------+ +-----+ +-------+ |
| |O-Proxy| |O-SBE| | Indirect SSP Domain | |T-SBE| |T-Proxy| |
| +-------+ +-----+ | | +-----+ +-------+ |
| | +-----+ +-----+ | |
| +---+ +-----+ | |O-SBE| |O-DBE| | +-----+ +---+ |
| |UAC| |O-DBE| | +-----+ +-----+ | |T-DBE| |UAS| |
| +---+ +-----+ | | +-----+ +---+ |
| | | |
+--------------------+------------------------+--------------------+
General Overview
概述
Figure 1
图1
Note that some elements included in Figure 1 are optional.
请注意，图1中包含的一些元素是可选的。
Use cases are sorted into two general groups: static and on-demand peering [RFC5486]. Each group can be further sub-divided into Direct Peering and Indirect Peering [RFC5486]. Although there may be some overlap among the use cases in these categories, there are different requirements between the scenarios. Each use case must specify a basic set of required operations to be performed by each SSP when peering.
用例被分为两大类：静态和按需对等[RFC5486]。每个组可进一步细分为直接对等和间接对等[RFC5486]。尽管这些类别中的用例之间可能有一些重叠，但场景之间的需求不同。每个用例必须指定对等时每个SSP要执行的基本操作集。
These can include:
这些措施可包括：
o Peer Discovery - Peer discovery via a Lookup Function (LUF) to determine the Session Establishment Data (SED) [RFC5486] of the request. In VoIP use cases, a request normally contains a phone number. The O-SSP will input the phone number to the LUF and the LUF will normally return a SIP address of record (AOR) [RFC3261] that contains a domain name.
o 对等发现-通过查找功能（LUF）进行对等发现，以确定请求的会话建立数据（SED）[RFC5486]。在VoIP用例中，请求通常包含电话号码。O-SSP将向LUF输入电话号码，LUF通常会返回包含域名的SIP记录地址（AOR）[RFC3261]。
o Next-Hop Routing Determination - Resolving the SED information is necessary to route the request to the T-SSP. The LRF is used for this determination. After obtaining the SED, the O-SSP may use the standard procedure defined in [RFC3263] to discover the next-hop address.
o 下一跳路由确定-解析SED信息是将请求路由到T-SSP所必需的。LRF用于该测定。在获得SED后，O-SSP可以使用[RFC3263]中定义的标准程序来发现下一跳地址。
o Call setup - SSPs that are interconnecting to one another may also define specifics on what peering policies need to be used when contacting the next hop in order to a) reach the next hop at all and b) prove that the sender is a legitimate peering partner. Examples: hard-code transport (TCP/UDP/TLS), non-standard port number, specific source IP address (e.g., in a private Layer 3 network), which TLS client certificate [RFC5246] to use, and other authentication schemes.
o 呼叫设置-相互互连的SSP还可以定义在联系下一个跃点时需要使用哪些对等策略的细节，以便a）完全到达下一个跃点，b）证明发送方是合法的对等伙伴。示例：硬代码传输（TCP/UDP/TLS）、非标准端口号、TLS客户端证书[RFC5246]要使用的特定源IP地址（例如，在专用第3层网络中）以及其他身份验证方案。
o Call reception - This step ensures that the type of relationship (static or on-demand, indirect or direct) is understood and acceptable. For example, the receiving SBE needs to determine whether the INVITE it received really came from a trusted member.
o 呼叫接收-此步骤确保关系类型（静态或按需、间接或直接）被理解和接受。例如，接收SBE需要确定其接收的邀请是否确实来自受信任的成员。
Please note there are intra-domain message flows within the use cases to serve as supporting background information. Only inter-domain communications are germane to this document.
请注意，用例中有域内消息流作为支持背景信息。只有域间通信与本文档密切相关。
Static peering [RFC5486] describes the use case when two SSPs form a peering relationship with some form of association established prior to the exchange of traffic. Pre-association is a prerequisite to static peering. Static peering is used in cases when two peers want a consistent and tightly controlled approach to peering. In this scenario, a number of variables, such as an identification method (remote proxy IP address) and Quality-of-Service (QoS) parameters, can be defined upfront and known by each SSP prior to peering.
静态对等[RFC5486]描述了当两个SSP与交换流量之前建立的某种形式的关联形成对等关系时的用例。预关联是静态对等的先决条件。静态对等用于两个对等方需要一致且严格控制的对等方法的情况。在这种情况下，许多变量，例如标识方法（远程代理IP地址）和服务质量（QoS）参数，可以预先定义，并在对等之前由每个SSP知道。
This is the simplest form of a peering use case. Two SSPs negotiate and agree to establish a SIP peering relationship. The peer connection is statically configured and the peer SSPs are directly connected. The peers may exchange interconnection parameters such as Differentiated Service Code Point (DSCP) [RFC2474] policies, the maximum number of requests per second, and proxy location prior to establishing the interconnection. Typically, the T-SSP only accepts traffic originating directly from the trusted peer.
这是对等用例的最简单形式。两个SSP协商并同意建立SIP对等关系。对等连接是静态配置的，对等SSP是直接连接的。对等方可以在建立互连之前交换互连参数，例如区分服务码点（DSCP）[RFC2474]策略、每秒最大请求数和代理位置。通常，T-SSP只接受直接来自受信任对等方的流量。
+--------------------+ +---------------------+
| O-SSP | | T-SSP |
| +-----+ | | +-----+ |
| |O-LUF| | | |T-LUF| |
| |O-LRF| | | /|T-LRF| |
| /+-----+\ | | / +-----+ |
| (2) (4,5,6) | | / |
| / \ | | /(8,9) |
|+-------+ +-----+ +-----+ +-------+|
||O-Proxy|-(3)-|O-SBE+-----(7)-----+T-SBE|-(10)-|T-Proxy||
|+-------+ +-----+ +-----+ +-------+|
| | | | | |
| (1) | | (11) |
| | | | | |
| +-----+ +-----+ +-----+ +-----+ |
| | UAC +======|O-DBE+=====(12)====+T-DBE|=======+ UAS | |
| +-----+ +-----+ +-----+ +-----+ |
+--------------------+ +---------------------+
example.com example.net
+--------------------+ +---------------------+
| O-SSP | | T-SSP |
| +-----+ | | +-----+ |
| |O-LUF| | | |T-LUF| |
| |O-LRF| | | /|T-LRF| |
| /+-----+\ | | / +-----+ |
| (2) (4,5,6) | | / |
| / \ | | /(8,9) |
|+-------+ +-----+ +-----+ +-------+|
||O-Proxy|-(3)-|O-SBE+-----(7)-----+T-SBE|-(10)-|T-Proxy||
|+-------+ +-----+ +-----+ +-------+|
| | | | | |
| (1) | | (11) |
| | | | | |
| +-----+ +-----+ +-----+ +-----+ |
| | UAC +======|O-DBE+=====(12)====+T-DBE|=======+ UAS | |
| +-----+ +-----+ +-----+ +-----+ |
+--------------------+ +---------------------+
example.com example.net
Static Direct Peering Use Case
静态直接对等用例
Figure 2
图2
The following is a high-level depiction of the use case:
以下是用例的高级描述：
1. The User Agent Client (UAC) initiates a call via SIP INVITE to O-Proxy. O-Proxy is the home proxy for UAC.
1. 用户代理客户端（UAC）通过SIP INVITE向O-Proxy发起呼叫。O-Proxy是UAC的主代理。
INVITE sip:+19175550100@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP client.example.com:5060
;branch=z9hG4bK74bf9
Max-Forwards: 10
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=12345
To: Bob <sip:+19175550100@example.com;user=phone>
Call-ID: abcde
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@client.example.com;user=phone;
transport=tcp>
</allOneLine>
INVITE sip:+19175550100@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP client.example.com:5060
;branch=z9hG4bK74bf9
Max-Forwards: 10
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=12345
To: Bob <sip:+19175550100@example.com;user=phone>
Call-ID: abcde
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@client.example.com;user=phone;
transport=tcp>
</allOneLine>
Note that UAC inserted its Fully Qualified Domain Name (FQDN) in the VIA and CONTACT headers. This example assumes that UAC has its own FQDN.
请注意，UAC将其完全限定域名（FQDN）插入了VIA和联系人头中。本例假设UAC有自己的FQDN。
2. UAC knows the User Agent Server's (UAS's) TN, but does not know UAS's domain. It appends its own domain to generate the SIP URI in the Request-URI and TO header. O-Proxy checks the Request-URI and discovers that the Request-URI contains the user parameter "user=phone". This parameter signifies that the Request-URI is a phone number. So O-Proxy will extract the TN from the Request-URI and query the LUF for SED information from a routing database. In this example, the LUF is an ENUM [RFC6116] database. The ENUM entry looks similar to this:
2. UAC知道用户代理服务器（UAS）的TN，但不知道UAS的域。它附加自己的域以在请求URI和头中生成SIPURI。O-Proxy检查请求URI并发现请求URI包含用户参数“user=phone”。此参数表示请求URI是电话号码。因此，O-Proxy将从请求URI中提取TN，并从路由数据库中查询LUF中的SED信息。在本例中，LUF是一个ENUM[RFC6116]数据库。枚举项与此类似：
$ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa. IN NAPTR ( 10 100 "u" "E2U+SIP" "!^.*$!sip:+19175550100@example.net!" . )
$ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa。在NAPTR中（10 100“u”E2U+SIP）！^.*$！SIP:+19175550100@example.net!" . )
This SED data can be provisioned by O-SSP or populated by the T-SSP.
此SED数据可由O-SSP提供或由T-SSP填充。
3. O-Proxy examines the SED and discovers the domain is external. Given the O-Proxy's internal routing policy, O-Proxy decides to use O-SBE to reach T-SBE. O-Proxy routes the INVITE request to O-SBE and adds a Route header that contains O-SBE.
3. O-Proxy检查SED并发现域是外部的。给定O-Proxy的内部路由策略，O-Proxy决定使用O-SBE到达T-SBE。O-Proxy将INVITE请求路由到O-SBE，并添加包含O-SBE的路由头。
INVITE sip:+19175550100@example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP o-proxy.example.com:5060
;branch=z9hG4bKye8ad
Via: SIP/2.0/TCP client.example.com:5060
;branch=z9hG4bK74bf9;received=192.0.1.1
Max-Forwards: 9
Route: <sip:o-sbe1.example.com;lr>
Record-Route: <sip:o-proxy.example.com;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=12345
To: Bob <sip:+19175550100@example.com;user=phone>
Call-ID: abcde
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@client.example.com;user=phone;
transport=tcp>
</allOneLine>
INVITE sip:+19175550100@example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP o-proxy.example.com:5060
;branch=z9hG4bKye8ad
Via: SIP/2.0/TCP client.example.com:5060
;branch=z9hG4bK74bf9;received=192.0.1.1
Max-Forwards: 9
Route: <sip:o-sbe1.example.com;lr>
Record-Route: <sip:o-proxy.example.com;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=12345
To: Bob <sip:+19175550100@example.com;user=phone>
Call-ID: abcde
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@client.example.com;user=phone;
transport=tcp>
</allOneLine>
4. O-SBE receives the requests and pops the top entry of the Route header that contains "o-sbe1.example.com". O-SBE examines the Request-URI and does an LRF for "example.net". In this example, the LRF is a Naming Authority Pointer (NAPTR) DNS query [RFC3403] of the domain name. O-SBE receives a NAPTR response from the LRF. The response looks similar to this:
4. O-SBE接收请求并弹出包含“O-sbe1.example.com”的路由头的顶部条目。O-SBE检查请求URI并为“example.net”执行LRF。在此示例中，LRF是域名的命名机构指针（NAPTR）DNS查询[RFC3403]。O-SBE从LRF接收NAPTR响应。响应与此类似：
IN NAPTR ( 50 50 "S" "SIP+D2T" "" _sip._tcp.t-sbe.example.net. )
在NAPTR中（50 50“S”SIP+D2T“\u SIP.\u tcp.t-sbe.example.net）
IN NAPTR ( 90 50 "S" "SIP+D2U" "" _sip._udp.t-sbe.example.net. )
在NAPTR中（90 50“S”SIP+D2U“SIP.\u udp.t-sbe.example.net）
5. Given the lower order for TCP in the NAPTR response, O-SBE decides to use TCP as the transport protocol, so it sends an SRV DNS query for the SRV record [RFC2782] for "_sip._tcp.t-sbe.example.net." to O-LRF.
5. 鉴于NAPTR响应中TCP的顺序较低，O-SBE决定使用TCP作为传输协议，因此它向O-LRF发送一个针对“_sip._TCP.t-SBE.example.net.”的SRV记录[RFC2782]的SRV DNS查询。
;; priority weight port target IN SRV 0 2 5060 t-sbe1.example.net. IN SRV 0 1 5060 t-sbe2.example.net.
;; SRV 0 2 5060 t-sbe1.example.net中的优先级权重端口目标。在SRV 0 1 5060 t-sbe2.example.net中。
6. Given the higher weight for "t-sbe1.example.net", O-SBE sends an A record DNS query for "t-sbe1.example.net." to get the A record:
6. 给定“t-sbe1.example.net”的更高权重，O-SBE发送“t-sbe1.example.net”的A记录DNS查询以获取A记录：
;; DNS ANSWER t-sbe1.example.net. IN A 192.0.2.100 t-sbe1.example.net. IN A 192.0.2.101
;; DNS应答t-sbe1.example.net。在192.0.2.100 t-sbe1.example.net中。在192.0.2.101中
7. O-SBE sends the INVITE to T-SBE. O-SBE is the egress point to the O-SSP domain, so it should ensure subsequent mid-dialog requests traverse via itself. If O-SBE chooses to act as a back-to-back user agent (B2BUA) [RFC3261], it will generate a new INVITE request in next step. If O-SBE chooses to act as a proxy, it should record-route to stay in the call path. In this example, O-SBE is a B2BUA.
7. O-SBE向T-SBE发送邀请。O-SBE是O-SSP域的出口点，因此它应该确保后续的mid对话请求通过自身进行遍历。如果O-SBE选择充当背靠背用户代理（B2BUA）[RFC3261]，它将在下一步生成新的INVITE请求。如果O-SBE选择充当代理，它应该记录留在呼叫路径中的路由。在此示例中，O-SBE是B2BUA。
INVITE sip:+19175550100@example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP o-sbe1.example.com:5060
;branch= z9hG4bK2d4zzz
Max-Forwards: 8
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde-osbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@o-sbe1.example.com;user=phone;
transport=tcp>
</allOneLine>
INVITE sip:+19175550100@example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP o-sbe1.example.com:5060
;branch= z9hG4bK2d4zzz
Max-Forwards: 8
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde-osbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@o-sbe1.example.com;user=phone;
transport=tcp>
</allOneLine>
Note that O-SBE may re-write the Request-URI with the target domain in the SIP URI. Some proxy implementations will only accept the request if the Request-URI contains their own domains.
注意，O-SBE可以在SIP URI中使用目标域重新写入请求URI。某些代理实现仅在请求URI包含自己的域时才接受请求。
8. T-SBE determines the called party home proxy and directs the call to the called party. T-SBE may use ENUM lookup or other internal mechanism to locate the home proxy. If T-SSP uses ENUM lookup, this internal ENUM entry is different from the external ENUM entry populated for O-SSP. In this example, the internal ENUM query returns the UAS's home proxy.
8. T-SBE确定被叫方归属代理并将呼叫定向到被叫方。T-SBE可以使用枚举查找或其他内部机制来定位主代理。如果T-SSP使用枚举查找，则此内部枚举项与为O-SSP填充的外部枚举项不同。在本例中，内部枚举查询返回UAS的主代理。
$ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa. IN NAPTR ( 10 100 "u" "E2U+SIP" "!^.*$!sip:+19175550100@t-proxy.example.net!" . )
$ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa。在NAPTR中（10 100“u”E2U+SIP）！^.*$！SIP:+19175550100@t-proxy.example.net！）
9. T-SBE receives the NAPTR record, and following the requirements in [RFC3263], queries DNS for the SRV records indicated by the NAPTR result. Not finding any, the T-SBE then queries DNS for the A record of domain "t-proxy.example.net.".
9. T-SBE接收NAPTR记录，并按照[RFC3263]中的要求，查询DNS以获取NAPTR结果指示的SRV记录。没有找到任何，T-SBE然后向DNS查询域“T-proxy.example.net.”的A记录。
;; DNS ANSWER t-proxy.example.net. IN A 192.0.2.2
;; DNS应答t-proxy.example.net。在192.0.2.2中
10. T-SBE is a B2BUA, so it generates a new INVITE and sends it to UAS's home proxy:
10. T-SBE是B2BUA，因此它会生成一个新的邀请，并将其发送到UAS的主代理：
INVITE sip:bob@t-proxy.example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP t-sbe1.example.net:5060
;branch= z9hG4bK28uyyy
Max-Forwards: 7
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@t-proxy.example.net;user=phone>
Call-ID: abcde-tsbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@t-sbe1.example.net;user=phone;
transport=tcp>
</allOneLine>
INVITE sip:bob@t-proxy.example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP t-sbe1.example.net:5060
;branch= z9hG4bK28uyyy
Max-Forwards: 7
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@t-proxy.example.net;user=phone>
Call-ID: abcde-tsbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@t-sbe1.example.net;user=phone;
transport=tcp>
</allOneLine>
11. Finally, UAS's home proxy forwards the INVITE request to the UAS.
11. 最后，UAS的主代理将INVITE请求转发给UAS。
INVITE sip:+19175550100@server.example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP t-proxy.example.net:5060
;branch= z9hG4bK28u111
Via: SIP/2.0/TCP t-sbe1.example.net:5060
;branch= z9hG4bK28uyyy; received=192.2.0.100
Max-Forwards: 6
Record-Route: <sip:t-proxy.example.net:5060;lr>,
<sip:t-sbe1.example.net:5060;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@t-proxy.example.net;user=phone>
Call-ID: abcde-tsbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@t-sbe1.example.net;user=phone;
transport=tcp>
</allOneLine>
INVITE sip:+19175550100@server.example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP t-proxy.example.net:5060
;branch= z9hG4bK28u111
Via: SIP/2.0/TCP t-sbe1.example.net:5060
;branch= z9hG4bK28uyyy; received=192.2.0.100
Max-Forwards: 6
Record-Route: <sip:t-proxy.example.net:5060;lr>,
<sip:t-sbe1.example.net:5060;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@t-proxy.example.net;user=phone>
Call-ID: abcde-tsbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@t-sbe1.example.net;user=phone;
transport=tcp>
</allOneLine>
12. RTP is established between the UAC and UAS. Note that the media shown in Figure 2 passes through O-DBE and T-DBE, but the use of DBE is optional.
12. 在UAC和UAS之间建立RTP。请注意，图2中所示的介质通过O-DBE和T-DBE，但DBE的使用是可选的。
The static direct peering use case is typically implemented in a scenario where there is a strong degree of trust between the two administrative domains. Both administrative domains typically sign a peering agreement that states clearly the policies and terms.
静态直接对等用例通常在两个管理域之间存在高度信任的场景中实现。两个管理域通常都会签署一份对等协议，明确说明策略和条款。
In Figure 2, O-SSP and T-SSP peer via SBEs. Normally, the operator will deploy the SBE at the edge of its administrative domain. The signaling traffic will pass between two networks through the SBEs. The operator has many reasons to deploy an SBE. For example, the O-SSP may use [RFC1918] addresses for their UA and proxies. These addresses are not routable in the target network. The SBE can perform a NAT function. Also, the SBE eases the operation cost for deploying or removing Layer 5 network elements. Consider the deployment architecture where multiple proxies connect to a single SBE. An operator can add or remove a proxy without coordinating with the peer operator. The peer operator "sees" only the SBE. As long as the SBE is maintained in the path, the peer operator does not need to be notified.
在图2中，O-SSP和T-SSP通过SBE对等。通常，运营商将在其管理域的边缘部署SBE。信令业务将通过SBE在两个网络之间传递。运营商部署SBE有很多原因。例如，O-SSP可以为其UA和代理使用[RFC1918]地址。这些地址在目标网络中不可路由。SBE可以执行NAT功能。此外，SBE降低了部署或移除第5层网元的运营成本。考虑部署架构，其中多个代理连接到单个SBE。操作员可以添加或删除代理，而无需与对等操作员协调。对等操作员仅“看到”SBE。只要SBE保持在路径中，就不需要通知对等操作员。
When an operator deploys SBEs, the operator is required to advertise the SBE to the peer LRF so that the peer operator can locate the SBE and route the traffic to the SBE accordingly.
当运营商部署SBE时，要求运营商向对等LRF播发SBE，以便对等运营商能够定位SBE并相应地将流量路由到SBE。
SBE deployment is a decision within an administrative domain. Either one or both administrative domains can decide to deploy SBE(s). To the peer network, most important is to identify the next-hop address. This decision does not affect the network's ability to identify the next-hop address.
SBE部署是管理域内的一项决策。一个或两个管理域都可以决定部署SBE。对于对等网络，最重要的是识别下一跳地址。此决定不会影响网络识别下一跳地址的能力。
This use case shares many properties with the Static Direct Peering Use Case Section 5.2. There must exist a pre-association between the O-SSP and T-SSP. The difference is O-SSP will use the Assisting LUF/ LRF Provider for LUF and LRF. The LUF/LRF Provider stores the SED to reach T-SSP and provides it to O-SSP when O-SSP requests it.
此用例与静态直接对等用例第5.2节共享许多属性。O-SSP和T-SSP之间必须存在预关联。区别在于，O-SSP将使用LUF和LRF的辅助LUF/LRF提供商。LUF/LRF提供商存储SED以到达T-SSP，并在O-SSP请求时将其提供给O-SSP。
+-----------------+
|LUF/LRF Provider |
| |
| +-------+ |
| +-+ A-LUF | |
| / | A-LRF | |
+--------------------+ / ++-------+ +---------------------+
| O-SSP |/ / | T-SSP |
| +------------/(4,5,6) | +-----+ |
| / | / | |T-LUF| |
| (2) +-+/ | +-|T-LRF| |
| / / | | / +-----+ |
| / / | | /(8,9) |
|+-------+ +-----+ +-----+ +-------+|
||O-Proxy|-(3)-|O-SBE+-------(7)-------+T-SBE|-(10)-|T-Proxy||
|+-------+ +-----+ +-----+ +-------+|
| | | | | |
| (1) | | (11) |
| | | | | |
| +-----+ +-----+ +-----+ +-----+ |
| | UAC +======|O-DBE+=======(12)======+T-DBE+=======+ UAS | |
| +-----+ +-----+ +-----+ +-----+ |
+--------------------+ +---------------------+
example.com example.net
+-----------------+
|LUF/LRF Provider |
| |
| +-------+ |
| +-+ A-LUF | |
| / | A-LRF | |
+--------------------+ / ++-------+ +---------------------+
| O-SSP |/ / | T-SSP |
| +------------/(4,5,6) | +-----+ |
| / | / | |T-LUF| |
| (2) +-+/ | +-|T-LRF| |
| / / | | / +-----+ |
| / / | | /(8,9) |
|+-------+ +-----+ +-----+ +-------+|
||O-Proxy|-(3)-|O-SBE+-------(7)-------+T-SBE|-(10)-|T-Proxy||
|+-------+ +-----+ +-----+ +-------+|
| | | | | |
| (1) | | (11) |
| | | | | |
| +-----+ +-----+ +-----+ +-----+ |
| | UAC +======|O-DBE+=======(12)======+T-DBE+=======+ UAS | |
| +-----+ +-----+ +-----+ +-----+ |
+--------------------+ +---------------------+
example.com example.net
Static Direct Peering with Assisting LUF and LRF
辅助LUF和LRF的静态直接对等
Figure 3
图3
The call flow looks almost identical to Static Direct Peering Use Case except that Steps 2, 4, 5, and 6 involve the LUF/LRF Provider instead of happening in O-SSP domain.
除了步骤2、4、5和6涉及LUF/LRF提供者而不是发生在O-SSP域中之外，调用流看起来几乎与静态直接对等用例相同。
Similar to Static Direct Peering Use Case, the O-DBE and T-DBE in Figure 3 are optional.
与静态直接对等用例类似，图3中的O-DBE和T-DBE是可选的。
The LUF/LRF Provider supplies the LUF and LRF services for the O-SSP. Taken together, the LUF/LRF Provider, O-SSP, and T-SSP form a trusted administrative domain. To reach the T-SSP, the O-SSP must still require pre-arranged agreements for the peer relationship with the T-SSP. The Layer 5 policy is maintained in the O-SSP and T-SSP domains, and the LUF/LRF Provider may not be aware of any Layer 5 policy between the O-SSP and T-SSP.
LUF/LRF供应商为O-SSP提供LUF和LRF服务。总之，LUF/LRF提供程序、O-SSP和T-SSP构成一个受信任的管理域。为了达成T-SSP，O-SSP仍必须要求就与T-SSP的对等关系达成预先安排的协议。第5层策略维护在O-SSP和T-SSP域中，LUF/LRF提供商可能不知道O-SSP和T-SSP之间的任何第5层策略。
A LUF/LRF Provider can serve multiple administrative domains. The LUF/LRF Provider typically does not share SED from one administrative domain to another administrative domain without appropriate permission.
LUF/LRF提供程序可以服务于多个管理域。未经适当许可，LUF/LRF提供程序通常不会将SED从一个管理域共享到另一个管理域。
The LUF/LRF Provider can use multiple methods to provide SED to the O-SSP. The most commonly used are an ENUM lookup and a SIP Redirect. The O-SSP should negotiate with the LUF/LRF Provider regarding which query method it will use prior to sending a request to the LUF/LRF Provider.
LUF/LRF提供商可以使用多种方法向O-SSP提供SED。最常用的是枚举查找和SIP重定向。在向LUF/LRF提供商发送请求之前，O-SSP应与LUF/LRF提供商协商将使用哪种查询方法。
The LUF/LRF Providers must be populated with the T-SSP's AORs and SED. Currently, this procedure is non-standardized and labor intensive. A more detailed description of this problem has been documented in the work in progress [DRINKS].
LUF/LRF供应商必须填写T-SSP的AOR和SED。目前，该程序是非标准化和劳动密集型的。关于此问题的更详细描述已记录在正在进行的工作[饮料]中。
The difference between a Static Direct Use Case and a Static Indirect Use Case lies within the Layer 5 relationship maintained by the O-SSP and T-SSP. In the Indirect use case, the O-SSP and T-SSP do not have direct Layer 5 connectivity. They require one or multiple Indirect Domains to assist with routing the SIP messages and possibly the associated media.
静态直接用例和静态间接用例之间的区别在于O-SSP和T-SSP维护的第5层关系。在间接用例中，O-SSP和T-SSP没有直接的第5层连接。它们需要一个或多个间接域来协助路由SIP消息和可能的相关媒体。
In this use case, the O-SSP and T-SSP want to form a peer relationship. For some reason, the O-SSP and T-SSP do not have direct Layer 5 connectivity. The reasons may vary, for example,
在此用例中，O-SSP和T-SSP希望形成对等关系。由于某些原因，O-SSP和T-SSP没有直接的第5层连接。原因可能会有所不同，例如，
business demands and/or domain policy controls. Due to this indirect relationship, the signaling will traverse from the O-SSP through one or multiple I-SSPs to reach the T-SSP.
业务需求和/或域策略控制。由于这种间接关系，信令将从O-SSP穿过一个或多个I-SSP到达T-SSP。
In addition, the O-SSP is using a LUF/LRF Provider. This LUF/LRF Provider stores the T-SSP's SED pre-populated by the T-SSP. One important motivation to use the LUF/LRF Provider is that the T-SSP only needs to populate its SED once to the provider. Using an LUF/ LRF Provider allows the T-SSP to populate its SED once, while any O-SSP T-SSP's SED can use this LUF/LRF Provider. Current practice has shown that it is rather difficult for the T-SSP to populate its SED to every O-SSP who must reach the T-SSP's subscribers. This is especially true in the Enterprise environment.
此外，O-SSP使用LUF/LRF提供程序。该LUF/LRF提供程序存储由T-SSP预填充的T-SSP的SED。使用LUF/LRF提供程序的一个重要动机是T-SSP只需向提供程序填充一次SED。使用LUF/LRF提供程序允许T-SSP填充其SED一次，而任何O-SSP T-SSP的SED都可以使用此LUF/LRF提供程序。目前的实践表明，T-SSP很难将其SED填充到每个必须到达T-SSP订户的O-SSP。在企业环境中尤其如此。
Note that the LUF/LRF Provider and the I-SSP can be the same provider or different providers.
请注意，LUF/LRF提供程序和I-SSP可以是相同的提供程序，也可以是不同的提供程序。
+------------------+
| LUF/LRF Provider |
| I-SSP |
| +-------+ |
| ---+ A-LUF | |
| / | A-LRF | |
+--------------------+ / +-------+ +---------------------+
| O-SSP |/ / | T-SSP |
| +-------------/ / | +-----+ |
| / |(4,5,6) | |T-LUF| |
| / | / | +----+T-LRF| |
| (2) + +--- | / +-----+ |
| / / | | /(9,10) |
|+-------+ +-----+ +-----+ +-----+ +-------+|
||O-Proxy|-(3)-|O-SBE+-(7)-+I-SBE+-(8)--+T-SBE+-(11)-|T-Proxy||
|+-------+ +-----+ +-----+ +-----+ +-------+|
| | | | | |
| (1) | | (12) |
| | | | | |
| +-----+ +-----+ +-----+ +-----+ +-----+ |
| | UAC +=(13)=|O-DBE+=====+I-DBE+======+T-DBE+=======+ UAS | |
| +-----+ +-----+ +-----+ +-----+ +-----+ |
+-------------------------------------------------------------+
example.com example.org example.net
+------------------+
| LUF/LRF Provider |
| I-SSP |
| +-------+ |
| ---+ A-LUF | |
| / | A-LRF | |
+--------------------+ / +-------+ +---------------------+
| O-SSP |/ / | T-SSP |
| +-------------/ / | +-----+ |
| / |(4,5,6) | |T-LUF| |
| / | / | +----+T-LRF| |
| (2) + +--- | / +-----+ |
| / / | | /(9,10) |
|+-------+ +-----+ +-----+ +-----+ +-------+|
||O-Proxy|-(3)-|O-SBE+-(7)-+I-SBE+-(8)--+T-SBE+-(11)-|T-Proxy||
|+-------+ +-----+ +-----+ +-----+ +-------+|
| | | | | |
| (1) | | (12) |
| | | | | |
| +-----+ +-----+ +-----+ +-----+ +-----+ |
| | UAC +=(13)=|O-DBE+=====+I-DBE+======+T-DBE+=======+ UAS | |
| +-----+ +-----+ +-----+ +-----+ +-----+ |
+-------------------------------------------------------------+
example.com example.org example.net
Indirect Peering via an LUF/LRF Provider and I-SSP (SIP and Media)
通过LUF/LRF提供程序和I-SSP（SIP和媒体）进行间接对等
Figure 4
图4
The following is a high-level depiction of the use case:
以下是用例的高级描述：
1. The UAC initiates a call via SIP INVITE to the O-Proxy. The O-Proxy is the home proxy for the UAC.
1. UAC通过SIP INVITE向O-Proxy发起呼叫。O代理是UAC的主代理。
INVITE sip:+19175550100@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP client.example.com:5060
;branch=z9hG4bK74bf9
Max-Forwards: 10
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=12345
To: Bob <sip:+19175550100@example.com;user=phone>
Call-ID: abcde
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@client.example.com;user=phone;
transport=tcp>
</allOneLine>
INVITE sip:+19175550100@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP client.example.com:5060
;branch=z9hG4bK74bf9
Max-Forwards: 10
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=12345
To: Bob <sip:+19175550100@example.com;user=phone>
Call-ID: abcde
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@client.example.com;user=phone;
transport=tcp>
</allOneLine>
2. The UAC knows the UAS's TN, but does not know the UAS's domain. It appends its own domain to generate the SIP URI in the Request-URI and TO header. The O-Proxy checks the Request-URI and discovers that the Request-URI contains the user parameter "user=phone". This parameter indicates that the Request-URI is a phone number. So, the O-Proxy will extract the TN from the Request-URI and query the LUF for SED information from a routing database. In this example, the LUF is an ENUM database. The ENUM entry looks similar to this:
2. UAC知道UAS的TN，但不知道UAS的域。它附加自己的域以在请求URI和头中生成SIPURI。O-Proxy检查请求URI并发现请求URI包含用户参数“user=phone”。此参数表示请求URI是电话号码。因此，O-Proxy将从请求URI中提取TN，并从路由数据库中查询LUF中的SED信息。在本例中，LUF是一个枚举数据库。枚举项与此类似：
$ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa. IN NAPTR ( 10 100 "u" "E2U+SIP" "!^.*$!sip:+19175550100@example.org!" . )
$ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa。在NAPTR中（10 100“u”E2U+SIP）！^.*$！SIP:+19175550100@example.org!" . )
Note that the response shows the next-hop is the SBE in I-SSP. Alternatively, the O-SSP may have a pre-association with the I-SSP. As such, the O-SSP will forward all requests that contain an external domain in the Request-URI or an unknown TN to the I-SSP. The O-SSP will rely on the I-SSP to determine the T-SSP and route the request correctly. In this configuration, the O-SSP can skip Steps 2, 4, 5, and 6 and forward the request directly to the I-SBE. This configuration is commonly used in the Enterprise environment.
注意，响应显示下一跳是I-SSP中的SBE。或者，O-SSP可与I-SSP预关联。因此，O-SSP将把请求URI中包含外部域或未知TN的所有请求转发给I-SSP。O-SSP将依靠I-SSP确定T-SSP并正确路由请求。在此配置中，O-SSP可以跳过步骤2、4、5和6，并将请求直接转发给I-SBE。此配置通常在企业环境中使用。
3. Given the O-Proxy's internal routing policy, the O-Proxy decides to use the O-SBE to reach the I-SBE. The O-Proxy routes the INVITE request to the O-SBE and adds a Route header that contains the O-SBE.
3. 给定O-Proxy的内部路由策略，O-Proxy决定使用O-SBE到达I-SBE。O-Proxy将INVITE请求路由到O-SBE，并添加包含O-SBE的路由头。
INVITE sip:+19175550100@example.org;user=phone SIP/2.0
Via: SIP/2.0/TCP o-proxy.example.com:5060
;branch=z9hG4bKye8ad
Via: SIP/2.0/TCP client.example.com:5060
;branch=z9hG4bK74bf9;received=192.0.1.1
Max-Forwards: 9
Route: <sip:o-sbe1.example.com;lr>
Record-Route: <sip:o-proxy.example.com;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=12345
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@client.example.com;user=phone;
transport=tcp>
</allOneLine>
INVITE sip:+19175550100@example.org;user=phone SIP/2.0
Via: SIP/2.0/TCP o-proxy.example.com:5060
;branch=z9hG4bKye8ad
Via: SIP/2.0/TCP client.example.com:5060
;branch=z9hG4bK74bf9;received=192.0.1.1
Max-Forwards: 9
Route: <sip:o-sbe1.example.com;lr>
Record-Route: <sip:o-proxy.example.com;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=12345
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@client.example.com;user=phone;
transport=tcp>
</allOneLine>
4. The O-SBE receives the requests and pops the top entry of the Route header that contains "sip:o-sbe1.example.com". The O-SBE examines the Request-URI and does an LRF for "example.org". In this example, the LRF is a NAPTR DNS query of the domain. The O-SBE receives a response similar to this:
4. O-SBE接收请求并弹出包含“sip:O-sbe1.example.com”的路由头的顶部条目。O-SBE检查请求URI并为“example.org”执行LRF。在本例中，LRF是域的NAPTR DNS查询。O-SBE接收到与此类似的响应：
IN NAPTR ( 50 50 "S" "SIP+D2T" "" _sip._tcp.i-sbe.example.org. )
在NAPTR中（50 50“S”SIP+D2T“_SIP._tcp.i-sbe.example.org.）
IN NAPTR ( 90 50 "S" "SIP+D2U" "" _sip._udp.i-sbe.example.org. )
在NAPTR中（90 50“S”SIP+D2U“SIP.\u udp.i-sbe.example.org.）
5. Given the lower order for TCP in the NAPTR response, the O-SBE decides to use TCP for transport protocol, so it sends an SRV DNS query for the SRV record for "_sip._tcp.i-sbe.example.org." to the O-LRF.
5. 鉴于NAPTR响应中TCP的顺序较低，O-SBE决定使用TCP作为传输协议，因此它向O-LRF发送一个SRV DNS查询，以查询“_sip._TCP.i-SBE.example.org.”的SRV记录。
;; priority weight port target IN SRV 0 2 5060 i-sbe1.example.org. IN SRV 0 1 5060 i-sbe2.example.org.
;; SRV 0 2 5060 i-sbe1.example.org中的优先级权重端口目标。在SRV 0 1 5060 i-sbe2.example.org中。
6. Given the higher weight for "i-sbe1.example.org", the O-SBE sends a DNS query for an A record of "i-sbe1.example.org." to get the A record:
6. 鉴于“i-sbe1.example.org”的权重较高，O-SBE会发送一个DNS查询，查询“i-sbe1.example.org”的a记录，以获取a记录：
;; DNS ANSWER i-sbe1.example.org. IN A 192.0.2.200 i-sbe1.example.org. IN A 192.0.2.201
;; DNS应答i-sbe1.example.org。在192.0.2.200 i-sbe1.example.org中。在192.0.2.201中
7. The O-SBE sends the INVITE to the I-SBE. The O-SBE is the entry point to the O-SSP domain, so it should ensure subsequent mid-dialog requests traverse via itself. If the O-SBE chooses to act as a B2BUA, it will generate a new back-to-back INVITE request in the next step. If the O-SBE chooses to act as proxy, it should record-route to stay in the call path. In this example, the O-SBE is a B2BUA.
7. O-SBE向I-SBE发送邀请。O-SBE是O-SSP域的入口点，因此它应该确保后续的mid对话请求通过自身进行遍历。如果O-SBE选择充当B2BUA，它将在下一步生成新的背对背邀请请求。如果O-SBE选择充当代理，它应该记录留在呼叫路径中的路由。在此示例中，O-SBE是B2BUA。
INVITE sip:+19175550100@example.org;user=phone SIP/2.0
Via: SIP/2.0/TCP o-sbe1.example.com:5060
;branch= z9hG4bK2d4zzz
Max-Forwards: 8
Route: <sip:i-sbe1.example.org;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde-osbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@o-sbe1.example.com;user=phone;
transport=tcp>
</allOneLine>
INVITE sip:+19175550100@example.org;user=phone SIP/2.0
Via: SIP/2.0/TCP o-sbe1.example.com:5060
;branch= z9hG4bK2d4zzz
Max-Forwards: 8
Route: <sip:i-sbe1.example.org;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde-osbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@o-sbe1.example.com;user=phone;
transport=tcp>
</allOneLine>
8. The I-SBE receives the request and queries its internal routing database on the TN. It determines that the target belongs to the T-SSP. Since the I-SBE is a B2BUA, the I-SBE generates a new INVITE request to the T-SSP.
8. I-SBE接收请求并在TN上查询其内部路由数据库。它确定目标属于T-SSP。由于I-SBE是B2BUA，因此I-SBE会向T-SSP生成一个新的INVITE请求。
INVITE sip:+19175550100@.example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP i-sbe1.example.org:5060
;branch= z9hG4bK2d4777
Max-Forwards: 7
Route: <sip:t-sbe1.example.net;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde-isbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@i-sbe1.example.org;user=phone;
transport=tcp>
</allOneLine>
INVITE sip:+19175550100@.example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP i-sbe1.example.org:5060
;branch= z9hG4bK2d4777
Max-Forwards: 7
Route: <sip:t-sbe1.example.net;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde-isbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@i-sbe1.example.org;user=phone;
transport=tcp>
</allOneLine>
Note that if the I-SSP wants the media to traverse through the I-DBE, the I-SBE must modify the Session Description Protocol (SDP) in the Offer to point to its DBE.
请注意，如果I-SSP希望介质穿过I-DBE，I-SBE必须修改报价中的会话描述协议（SDP）以指向其DBE。
9. The T-SBE determines the called party home proxy and directs the call to the called party. The T-SBE may use ENUM lookup or another internal mechanism to locate the home proxy. If the T-SSP uses ENUM lookup, this internal ENUM entry is different from the external ENUM entry populated for O-SSP. This internal ENUM entry will contain the information to identify the next hop to reach the called party. In this example, the internal ENUM query returns the UAS's home proxy.
9. T-SBE确定被叫方归属代理并将呼叫定向到被叫方。T-SBE可以使用枚举查找或其他内部机制来定位主代理。如果T-SSP使用枚举查找，则此内部枚举项与为O-SSP填充的外部枚举项不同。此内部枚举条目将包含标识到达被叫方的下一个跃点的信息。在本例中，内部枚举查询返回UAS的主代理。
$ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa. IN NAPTR ( 10 100 "u" "E2U+SIP" "!^.*$!sip:+19175550100@t-proxy.example.net!" . )
$ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa。在NAPTR中（10 100“u”E2U+SIP）！^.*$！SIP:+19175550100@t-proxy.example.net！）
Note that this step is optional. If the T-SBE has other ways to locate the UAS home proxy, the T-SBE can skip this step and send the request to the UAS's home proxy. We show this step to illustrate one of the many possible ways to locate UAS's home proxy.
请注意，此步骤是可选的。如果T-SBE有其他方法来定位UAS主代理，T-SBE可以跳过此步骤并将请求发送到UAS的主代理。我们展示此步骤是为了说明定位UAS主代理的多种可能方法之一。
10. The T-SBE receives the NAPTR record and, following the requirements in [RFC3263], queries the DNS for the SRV records indicated by the NAPTR result. Not finding any, the T-SBE then queries DNS for the A record of domain "t-proxy.example.net.".
10. T-SBE接收NAPTR记录，并按照[RFC3263]中的要求，向DNS查询NAPTR结果指示的SRV记录。没有找到任何，T-SBE然后向DNS查询域“T-proxy.example.net.”的A记录。
;; DNS ANSWER t-proxy.example.net. IN A 192.0.2.2
;; DNS应答t-proxy.example.net。在192.0.2.2中
11. T-SBE sends the INVITE to UAS's home proxy:
11. T-SBE向UAS的主代理发送邀请：
INVITE sip:+19175550100@t-proxy.example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP t-sbe1.example.net:5060
;branch= z9hG4bK28uyyy
Max-Forwards: 6
Record-Route: <sip:t-sbe1.example.net:5060;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde-tsbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@t-sbe1.example.com;user=phone;
transport=tcp>
</allOneLine>
INVITE sip:+19175550100@t-proxy.example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP t-sbe1.example.net:5060
;branch= z9hG4bK28uyyy
Max-Forwards: 6
Record-Route: <sip:t-sbe1.example.net:5060;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde-tsbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@t-sbe1.example.com;user=phone;
transport=tcp>
</allOneLine>
12. Finally, the UAS's home proxy forwards the INVITE request to the UAS.
12. 最后，UAS的主代理将INVITE请求转发给UAS。
INVITE sip:+19175550100@server.example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP t-proxy.example.net:5060
;branch= z9hG4bK28u111
Via: SIP/2.0/TCP t-sbe1.example.net:5060
;branch= z9hG4bK28uyyy; received=192.2.0.100
Max-Forwards: 5
Record-Route: <sip:t-proxy.example.net:5060;lr>,
<sip:t-sbe1.example.net:5060;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde-tsbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@t-sbe1.example.com;user=phone;
transport=tcp>
</allOneLine>
INVITE sip:+19175550100@server.example.net;user=phone SIP/2.0
Via: SIP/2.0/TCP t-proxy.example.net:5060
;branch= z9hG4bK28u111
Via: SIP/2.0/TCP t-sbe1.example.net:5060
;branch= z9hG4bK28uyyy; received=192.2.0.100
Max-Forwards: 5
Record-Route: <sip:t-proxy.example.net:5060;lr>,
<sip:t-sbe1.example.net:5060;lr>
From: Alice <sip:+14085550101@example.com;user=phone>
;tag=54321
To: Bob <sip:+19175550100@example.net;user=phone>
Call-ID: abcde-tsbe1
CSeq: 1 INVITE
<allOneLine>
Contact: <sip:+19175550100@t-sbe1.example.com;user=phone;
transport=tcp>
</allOneLine>
13. In Figure 4, RTP is established between the UAC and UAS via the O-DBE, I-DBE and T-DBE. The use of DBE is optional.
13. 在图4中，通过O-DBE、I-DBE和T-DBE在UAC和UAS之间建立RTP。DBE的使用是可选的。
This use case looks very similar to the Static Direct Peering Use Case with Assisting LUF and LRF. The major difference is the O-SSP and T-SSP do not have direct Layer 5 connectivity. Instead, O-SSP connects to the T-SSP indirectly via the I-SSP.
这个用例看起来非常类似于辅助LUF和LRF的静态直接对等用例。主要区别在于O-SSP和T-SSP没有直接的第5层连接。相反，O-SSP通过I-SSP间接连接到T-SSP。
Typically, an LUF/LRF Provider serves multiple O-SSPs. Two O-SSPs may use different I-SSPs to reach the same T-SSP. For example, O-SSP1 may use I-SSP1 to reach T-SSP, but O-SSP2 may use I-SSP2 to reach T-SSP. Given the O-SSP and T-SSP pair as input, the LUF/LRF Provider will return the SED of I-SSP that is trusted by O-SSP to forward the request to T-SSP.
通常，LUF/LRF提供者为多个O-SSP提供服务。两个O-SSP可以使用不同的I-SSP来达到相同的T-SSP。例如，O-SSP1可使用I-SSP1到达T-SSP，但O-SSP2可使用I-SSP2到达T-SSP。给定O-SSP和T-SSP对作为输入，LUF/LRF提供程序将返回O-SSP信任的I-SSP的SED，以将请求转发给T-SSP。
In this use case, there are two levels of trust relationship. The first trust relationship is between the O-SSP and the LUF/LRF Provider. The O-SSP trusts the LUF/LRF to provide the T-SSP's SED. The second trust relationship is between the O-SSP and I-SSP. The O-SSP trusts the I-SSP to provide Layer 5 connectivity to assist the O-SSP in reaching the T-SSP. The O-SSP and I-SSP have a pre-arranged agreement for policy. Note that Figure 4 shows a single provider to supply both LUF/LRF and I-SSP, but O-SSP can choose two different providers.
在这个用例中，有两个级别的信任关系。第一个信任关系是O-SSP和LUF/LRF提供商之间的信任关系。O-SSP信任LUF/LRF提供T-SSP的SED。第二种信任关系是O-SSP和I-SSP之间的信任关系。O-SSP信任I-SSP提供第5层连接，以协助O-SSP到达T-SSP。O-SSP和I-SSP有预先安排的政策协议。请注意，图4显示了一个提供LUF/LRF和I-SSP的提供商，但O-SSP可以选择两个不同的提供商。
Similar to the Static Direct Peering Use Case, the O-SSP and T-SSP may deploy SBE and DBE for NAT traversal, security, transcoding, etc. The I-SSP can also deploy the SBE and DBE for similar reasons (as depicted in Figure 4).
与静态直接对等用例类似，O-SSP和T-SSP可以部署SBE和DBE用于NAT穿越、安全、转码等。I-SSP也可以出于类似原因部署SBE和DBE（如图4所示）。
This use case shares many properties with the Static Indirect Use Case with Assisting LUF and LRF. The difference is that the O-SSP uses its internal LUF/LRF to control the routing database. By controlling the database, the O-SSP can apply different routing rules and policies to different T-SSPs. For example, the O-SSP can use I-SSP1 and Policy-1 to reach T-SSP1, and use I-SSP2 and Policy-2 to reach T-SSP2. Note that there could be multiple I-SSPs and multiple SIP routes to reach the same T-SSP; the selection process is out of scope of this document.
该用例与辅助LUF和LRF的静态间接用例共享许多属性。不同之处在于O-SSP使用其内部LUF/LRF控制路由数据库。通过控制数据库，O-SSP可以对不同的T-SSP应用不同的路由规则和策略。例如，O-SSP可以使用I-SSP1和策略-1到达T-SSP1，并使用I-SSP2和策略-2到达T-SSP2。注意，可能有多个I-SSP和多个SIP路由来到达同一个T-SSP；选择过程超出了本文档的范围。
+--------------------+-------------------+---------------------+
| O-SSP | I-SSP | T-SSP |
| +-----+ | | +-----+ |
| -+O-LUF| | | |T-LUF| |
| / |O-LRF+\ | | +----+T-LRF| |
| / +-----+ \ | | / +-----+ |
| /(2) \(4,5,6) | /(9,10) |
|+-------+ +-----+ +-----+ +-----+ +-------+|
||O-Proxy|-(3)-|O-SBE+--(7)-+I-SBE+-(8)--+T-SBE+-(11)-|T-Proxy||
|+-------+ +-----+ +-----+ +-----+ +-------+|
| | | | | |
| (1) | | (12) |
| | | | | |
| +-----+ +-----+ +-----+ +-----+ +-----+ |
| | UAC +=(13)=+O-DBE+======+I-DBE+======+T-DBE+=======+ UAS | |
| +-----+ +-----+ +-----+ +-----+ +-----+ |
+--------------------------------------------------------------+
example.com example.org example.net
+--------------------+-------------------+---------------------+
| O-SSP | I-SSP | T-SSP |
| +-----+ | | +-----+ |
| -+O-LUF| | | |T-LUF| |
| / |O-LRF+\ | | +----+T-LRF| |
| / +-----+ \ | | / +-----+ |
| /(2) \(4,5,6) | /(9,10) |
|+-------+ +-----+ +-----+ +-----+ +-------+|
||O-Proxy|-(3)-|O-SBE+--(7)-+I-SBE+-(8)--+T-SBE+-(11)-|T-Proxy||
|+-------+ +-----+ +-----+ +-----+ +-------+|
| | | | | |
| (1) | | (12) |
| | | | | |
| +-----+ +-----+ +-----+ +-----+ +-----+ |
| | UAC +=(13)=+O-DBE+======+I-DBE+======+T-DBE+=======+ UAS | |
| +-----+ +-----+ +-----+ +-----+ +-----+ |
+--------------------------------------------------------------+
example.com example.org example.net
Indirect Peering via I-SSP (SIP and Media)
通过I-SSP间接对等（SIP和媒体）
Figure 5
图5
The Static Indirect Peering Use Case is implemented in cases where no direct interconnection exists between the originating and terminating domains due to either business or physical constraints.
静态间接对等用例是在由于业务或物理约束而在发起域和终止域之间不存在直接互连的情况下实现的。
O-SSP <---> I-SSP = Relationship O-I
O-SSP <---> I-SSP = Relationship O-I
In the O-I relationship, typical policies, features, or functions that deem this relationship necessary are number portability, ubiquity of termination options, security certificate management, and masquerading of originating VoIP network gear.
在O-I关系中，认为这种关系必要的典型策略、特性或功能是号码可移植性、普遍存在的终止选项、安全证书管理以及原始VoIP网络设备的伪装。
T-SSP <---> I-SSP = Relationship T-I
T-SSP <---> I-SSP = Relationship T-I
In the T-I relationship, typical policies, features, or functions observed consist of codec "scrubbing", anonymizing, and transcoding. The I-SSP must record-route and stay in the signaling path. The T-SSP will not accept any message sent directly from the O-SSP.
在T-I关系中，观察到的典型策略、特性或功能包括编解码器“清理”、匿名化和转码。I-SSP必须记录路由并停留在信令路径中。T-SSP将不接受直接从O-SSP发送的任何消息。
In Figure 5, we show an I-DBE. Using an I-DBE is optional. For example, the I-DBE can be used when the O-SSP and T-SSP do not have a common codec. To involve an I-DBE, the I-SSP should know the list of codecs supported by the O-SSP and T-SSP. When the I-SBE receives the INVITE request, it will make a decision to invoke the I-DBE. An I-DBE may also be used if the O-SSP uses Secure Real-time Transport Protocol (SRTP) [RFC3711] for media and T-SSP does not support SRTP.
在图5中，我们展示了一个I-DBE。使用I-DBE是可选的。例如，当O-SSP和T-SSP没有公共编解码器时，可以使用I-DBE。要涉及I-DBE，I-SSP应了解O-SSP和T-SSP支持的编解码器列表。当I-SBE收到INVITE请求时，它将决定调用I-DBE。如果O-SSP对介质使用安全实时传输协议（SRTP）[RFC3711]，并且T-SSP不支持SRTP，则也可以使用I-DBE。
On-demand peering [RFC5486] describes how two SSPs form the peering relationship without a pre-arranged agreement.
按需对等[RFC5486]描述了两个SSP如何在没有预先安排的协议的情况下形成对等关系。
The basis of this use case is built on the fact that there is no pre-established relationship between the O-SSP and T-SSP. The O-SSP and T-SSP do not share any information prior to the dialog initiation request. When the O-Proxy invokes the LUF and LRF on the Request-URI, the terminating user information must be publicly available. When the O-Proxy routes the request to the T-Proxy, the T-Proxy must accept the request without any pre-arranged agreement with the O-SSP.
该用例的基础是O-SSP和T-SSP之间没有预先建立的关系。在对话框启动请求之前，O-SSP和T-SSP不共享任何信息。当O-Proxy调用请求URI上的LUF和LRF时，终止用户信息必须是公开的。当O-Proxy将请求路由到T-Proxy时，T-Proxy必须接受请求，而无需与O-SSP达成任何事先安排的协议。
The On-demand Peering Use Case is uncommon in production. In this memo, we capture only the high-level descriptions. Further analysis is expected when this use case becomes more popular.
按需对等用例在生产中并不常见。在本备忘录中，我们仅捕获高层描述。当这个用例变得更加流行时，我们将进行进一步的分析。
The On-demand Direct Peering Use Case is typically implemented in a scenario where the T-SSP allows any O-SSP to reach its serving subscribers. The T-SSP administrative domain does not require any pre-arranged agreement to accept the call. The T-SSP makes its subscribers information publicly available. This model mimics the Internet email model. The sender does not need an pre-arranged agreement to send email to the receiver.
按需直接对等用例通常在T-SSP允许任何O-SSP到达其服务订户的场景中实现。T-SSP管理域不需要任何预先安排的协议来接受呼叫。T-SSP公开其用户信息。此模型模仿Internet电子邮件模型。发件人不需要预先安排的协议即可向收件人发送电子邮件。
Similar to the Static Direct Peering Use Case, the O-SSP and T-SSP can decide to deploy the SBE. Since the T-SSP is open to the public, the T-SSP is considered to be a higher security risk than static model because there is no trusted relationship between the O-SSP and T-SSP. The T-SSP should protect itself from any attack launched by an untrusted O-SSP.
与静态直接对等用例类似，O-SSP和T-SSP可以决定部署SBE。由于T-SSP向公众开放，T-SSP被认为比静态模型具有更高的安全风险，因为O-SSP和T-SSP之间没有可信关系。T-SSP应保护自身免受不受信任的O-SSP发起的任何攻击。
Michael Haberler, Mike Mammer, Otmar Lendl, Rohan Mahy, David Schwartz, Eli Katz and Jeremy Barkan are the authors of the early individual documents. Their use cases are captured in this document. Also, Jason Livingood, Daryl Malas, David Meyer, Hadriel Kaplan, John Elwell, Reinaldo Penno, Sohel Khan, James McEachern, Jon Peterson, Alexander Mayrhofer, and Jean-Francois Mule made many valuable comments related to this document. The editors would also like to extend a special thank you to Spencer Dawkins for his detailed review of this document.
Michael Haberler、Mike Mammer、Otmar Lendl、Rohan Mahy、David Schwartz、Eli Katz和Jeremy Barkan是早期个人文件的作者。它们的用例在本文档中被捕获。此外，Jason Livingood、Daryl Malas、David Meyer、Hadriel Kaplan、John Elwell、Reinaldo Penno、Sohel Khan、James McEachern、Jon Peterson、Alexander Mayrhofer和Jean-Francois Mule就本文件发表了许多有价值的评论。编辑们还要特别感谢斯宾塞·道金斯对本文件的详细审查。
Session interconnect for VoIP, as described in this document, has a wide variety of security issues that should be considered. For example, if the O-SSP and T-SSP peer through public Internet, the O-SSP must protect the signaling channel and accept messages only from an authorized T-SSP. This document does not analyze the threats in detail. [RFC6404] discusses the different security threats and countermeasures related to VoIP peering.
如本文档所述，VoIP会话互连有许多安全问题需要考虑。例如，如果O-SSP和T-SSP通过公共互联网进行对等，则O-SSP必须保护信令信道并仅接受来自授权T-SSP的消息。本文档未详细分析这些威胁。[RFC6404]讨论了与VoIP对等相关的不同安全威胁和对策。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[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月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC 3263，2002年6月。
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[RFC3403]Mealling，M.“动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库”，RFC34032002年10月。
[RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia Interconnect (SPEERMINT) Terminology", RFC 5486, March 2009.
[RFC5486]Malas，D.和D.Meyer，“多媒体互连的会话对等（SPEERMINT）术语”，RFC 54862009年3月。
[RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 6116, March 2011.
[RFC6116]Bradner，S.，Conroy，L.，和K.Fujiwara，“E.164到统一资源标识符（URI）动态委托发现系统（DDDS）应用程序（ENUM）”，RFC 6116，2011年3月。
[RFC6404] Seedorf, J., Niccolini, S., Chen, E., and H. Scholz, "Session PEERing for Multimedia INTerconnect (SPEERMINT) Security Threats and Suggested Countermeasures", RFC 6404, November 2011.
[RFC6404]Seedorf，J.，Niccolini，S.，Chen，E.，和H.Scholz，“多媒体互连的会话对等（SPEERMINT）安全威胁和建议对策”，RFC 6404，2011年11月。
[DRINKS] Channabasappa, S., "Data for Reachability of Inter/ tra-NetworK SIP (DRINKS) Use cases and Protocol Requirements", Work in Progress, August 2011.
[饮料]Channabasappa，S.，“内部/tra网络SIP（饮料）用例和协议要求的可达性数据”，正在进行的工作，2011年8月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
Authors' Addresses
作者地址
Adam Uzelac (editor) Global Crossing U.S.A.
Adam Uzelac（编辑）环球穿越美国。
EMail: adam.uzelac@globalcrossing.com
URI: http://www.globalcrossing.com
EMail: adam.uzelac@globalcrossing.com
URI: http://www.globalcrossing.com
Yiu L.Lee (editor) Comcast Cable U.S.A.
李耀禄（编辑）美国康卡斯特有线电视公司。
EMail: yiu_lee@cable.comcast.com
URI: http://www.comcast.com
EMail: yiu_lee@cable.comcast.com
URI: http://www.comcast.com