Network Working Group                                      D. Malas, Ed.
Request for Comments: 5486                                     CableLabs
Category: Informational                                    D. Meyer, Ed.
                                                              March 2009
        
Network Working Group                                      D. Malas, Ed.
Request for Comments: 5486                                     CableLabs
Category: Informational                                    D. Meyer, Ed.
                                                              March 2009
        

Session Peering for Multimedia Interconnect (SPEERMINT) Terminology

多媒体互连会话对等(SPEERMINT)术语

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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下,不得在IETF标准流程之外修改本文件,也不得在IETF标准流程之外创建其衍生作品,除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。

Abstract

摘要

This document defines the terminology that is to be used in describing Session PEERing for Multimedia INTerconnect (SPEERMINT).

本文档定义了用于描述多媒体互连会话对等(SPEERMINT)的术语。

Table of Contents

目录

   1. Introduction ....................................................2
   2. SPEERMINT Context ...............................................3
   3. General Definitions .............................................4
      3.1. Signaling Path Border Element ..............................4
      3.2. Data Path Border Element ...................................4
      3.3. Session Establishment Data .................................4
      3.4. Call Routing ...............................................5
      3.5. PSTN .......................................................5
      3.6. IP Path ....................................................5
      3.7. Peer Network ...............................................5
      3.8. Service Provider ...........................................5
      3.9. SIP Service Provider .......................................6
   4. Peering .........................................................6
      4.1. Layer 3 Peering ............................................6
      4.2. Layer 5 Peering ............................................6
           4.2.1. Direct Peering ......................................7
           4.2.2. Indirect Peering ....................................7
           4.2.3. On-Demand Peering ...................................7
           4.2.4. Static Peering ......................................7
      4.3. Functions ..................................................7
           4.3.1. Signaling Function ..................................7
           4.3.2. Media Function ......................................8
           4.3.3. Look-Up Function ....................................8
           4.3.4. Location Routing Function ...........................8
   5. Federations .....................................................8
   6. Security Considerations .........................................9
   7. Acknowledgments .................................................9
   8. Informative References .........................................10
        
   1. Introduction ....................................................2
   2. SPEERMINT Context ...............................................3
   3. General Definitions .............................................4
      3.1. Signaling Path Border Element ..............................4
      3.2. Data Path Border Element ...................................4
      3.3. Session Establishment Data .................................4
      3.4. Call Routing ...............................................5
      3.5. PSTN .......................................................5
      3.6. IP Path ....................................................5
      3.7. Peer Network ...............................................5
      3.8. Service Provider ...........................................5
      3.9. SIP Service Provider .......................................6
   4. Peering .........................................................6
      4.1. Layer 3 Peering ............................................6
      4.2. Layer 5 Peering ............................................6
           4.2.1. Direct Peering ......................................7
           4.2.2. Indirect Peering ....................................7
           4.2.3. On-Demand Peering ...................................7
           4.2.4. Static Peering ......................................7
      4.3. Functions ..................................................7
           4.3.1. Signaling Function ..................................7
           4.3.2. Media Function ......................................8
           4.3.3. Look-Up Function ....................................8
           4.3.4. Location Routing Function ...........................8
   5. Federations .....................................................8
   6. Security Considerations .........................................9
   7. Acknowledgments .................................................9
   8. Informative References .........................................10
        
1. Introduction
1. 介绍

The term "Voice over IP Peering" (VoIP Peering) has historically been used to describe a wide variety of practices pertaining to the interconnection of service provider networks and to the delivery of Session Initiation Protocol (SIP [2]) call termination over those interconnections.

术语“IP语音对等”(VoIP对等)历来被用于描述与服务提供商网络的互连和通过这些互连的会话发起协议(SIP[2])呼叫终止的交付有关的各种实践。

The discussion of these interconnections has at times been confused by the fact that the term "peering" is used in various contexts to describe interconnection at different levels in a protocol stack. Session Peering for Multimedia Interconnect focuses on how to identify and route real-time sessions (such as VoIP calls) at the session layer, and it does not (necessarily) cover the exchange of packet-routing data or media sessions. In particular, "layer 5 network" is used here to refer to the interconnection between SIP

对这些互连的讨论有时会被“对等”一词在不同上下文中用于描述协议栈中不同级别的互连这一事实所混淆。用于多媒体互连的会话对等主要关注如何在会话层识别和路由实时会话(如VoIP呼叫),而它(不一定)涵盖分组路由数据或媒体会话的交换。这里特别使用“第5层网络”来指SIP之间的互连

servers, as opposed to interconnection at the IP layer ("layer 3"). The term "peering" will be used throughout the remainder of the document for the purpose of indicating a layer 5 interconnection.

服务器,而不是IP层(“第3层”)的互连。术语“对等”将在本文件其余部分中使用,以表示第5层互连。

This document introduces standard terminology for use in characterizing real-time session peering. Note however, that while this document is primarily targeted at the VoIP peering case, the terminology described here is applicable to those cases in which service providers peer using SIP signaling (defined as SIP Service Providers; see Section 3.9) for non-voice or quasi-real-time communications like instant messaging.

本文档介绍用于描述实时会话对等的标准术语。然而,请注意,虽然本文档主要针对VoIP对等情况,但此处描述的术语适用于服务提供商使用SIP信令(定义为SIP服务提供商;请参见第3.9节)进行非语音或准实时通信(如即时消息)的对等情况。

The remainder of this document is organized as follows: Section 2 provides the general context for the Session PEERing for Multimedia INTerconnect working group (SPEERMINT). Section 3 provides the general definitions for real-time, SIP-based communication, with initial focus on the VoIP peering case, and Section 4 defines the terminology describing the various forms of peering. Finally, Section 5 introduces the concept of federations.

本文档的其余部分组织如下:第2节提供了多媒体互连会话对等工作组(SPEERMINT)的一般上下文。第3节提供了基于SIP的实时通信的一般定义,初始重点是VoIP对等案例,第4节定义了描述各种对等形式的术语。最后,第5节介绍了联邦的概念。

2. SPEERMINT Context
2. 特殊语境

SPEERMINT provides a peering framework that leverages the building blocks of existing IETF-defined protocols such as SIP [2] and ENUM [4]. While the SPEERMINT working group describes the use of these protocols in peering, it does not redefine how these protocols use input or output variables necessary for creating Session Establishment Data (SED) or the methods in which this data will be used during the peering process. See Section 3.3 for additional detail on SED and its principal variables such as Uniform Resource Identifiers (URIs) [3] and telephone numbers of E.164 numbers [5]. For example, while the SPEERMINT working group is not limited to the use of telephone numbers, an E.164 number may be used as a key in an E.164-to-URI mapping using ENUM. This mapping involves looking up Naming Authority Pointer (NAPTR) records in the DNS, and results in a SIP URI. The process for deriving this information has already been defined in [4], but is used as a building block for SPEERMINT SED, on which the subsequent call routing is based. Note that the call-routing step does not depend on the presence of an E.164 number. Indeed, the URI resulting from an ENUM query may no longer even contain numbers of any type. In particular, the SIP URI can be advertised in various other ways, such as on a web page.

SPEERMINT提供了一个对等框架,该框架利用现有IETF定义的协议(如SIP[2]和ENUM[4])的构建块。虽然SPEERMINT工作组描述了这些协议在对等过程中的使用,但它没有重新定义这些协议如何使用创建会话建立数据(SED)所需的输入或输出变量,或者在对等过程中使用这些数据的方法。有关SED及其主要变量(如统一资源标识符(URI)[3]和E.164号码的电话号码[5])的更多详细信息,请参见第3.3节。例如,虽然SPEERMINT工作组不限于使用电话号码,但E.164号码可以用作使用ENUM的E.164到URI映射中的密钥。此映射涉及在DNS中查找命名机构指针(NAPTR)记录,并生成SIPURI。在[4]中已经定义了获取此信息的过程,但它被用作SPEERMINT SED的构建块,后续呼叫路由基于此构建块。请注意,呼叫路由步骤并不取决于是否存在E.164号码。事实上,枚举查询产生的URI甚至可能不再包含任何类型的数字。特别地,SIP URI可以以各种其他方式进行广告,例如在网页上。

Finally, note that the term "call" is being used here in the most general sense, i.e., call routing and session routing are used interchangeably.

最后,请注意,这里使用的术语“呼叫”是最一般意义上的,即呼叫路由和会话路由可以互换使用。

3. General Definitions
3. 一般定义
3.1. Signaling Path Border Element
3.1. 信令路径边界元素

A signaling path border element (SBE) is located on the administrative border of a domain through which inter-domain session layer messages will flow. It typically provides signaling functions such as protocol inter-working (for example, H.323 to SIP), identity and topology hiding, and Session Admission Control for a domain.

信令路径边界元素(SBE)位于域的管理边界上,域间会话层消息将通过该边界流动。它通常提供信令功能,例如协议互通(例如,H.323到SIP)、身份和拓扑隐藏以及域的会话许可控制。

3.2. Data Path Border Element
3.2. 数据路径边界元素

A data path border element (DBE) is located on the administrative border of a domain through which flows the media associated with an inter-domain session. It typically provides media-related functions such as deep packet inspection and modification, media relay, and firewall-traversal support. The DBE may be controlled by the SBE.

数据路径边界元素(DBE)位于域的管理边界上,与域间会话相关联的媒体通过该边界流动。它通常提供与媒体相关的功能,如深度数据包检查和修改、媒体中继和防火墙穿越支持。DBE可由SBE控制。

3.3. Session Establishment Data
3.3. 会话建立数据

Session Establishment Data, or SED, is the data used to route a call to the next hop associated with the called domain's ingress point. A domain's ingress point might, for example, be the location derived from various types of DNS records (NAPTR, SRV, or A record) [1] that resulted from the resolution of the SIP URI.

会话建立数据(SED)是用于将呼叫路由到与被叫域入口点关联的下一跳的数据。例如,域的入口点可能是从各种类型的DNS记录(NAPTR、SRV或记录)[1]派生的位置,这些记录是由SIP URI的解析产生的。

More specifically, the SED is the set of parameters that the outgoing SBEs need to complete the call, and may include:

更具体地说,SED是出站sbe完成呼叫所需的一组参数,可以包括:

o A destination SIP URI

o 目标SIPURI

o A SIP proxy or ingress SBE to send the INVITE to, including:

o 要向其发送邀请的SIP代理或入口SBE,包括:

- Fully Qualified Domain Name (FQDN)

- 完全限定域名(FQDN)

- Port

- 港口城市

- Transport Protocol (UDP [8], TCP [9], and TLS [7])

- 传输协议(UDP[8]、TCP[9]和TLS[7])

o Security parameters, including:

o 安全参数,包括:

- TLS certificate to use

- 要使用的TLS证书

- TLS certificate to expect

- 预期的TLS证书

- TLS certificate verification setting

- TLS证书验证设置

o Optional resource control parameters such as:

o 可选的资源控制参数,例如:

- Limits on the total number of call initiations to a peer

- 对对等方呼叫发起总数的限制

- Limits on SIP transactions per second

- 每秒SIP事务的限制

3.4. Call Routing
3.4. 呼叫路由

Call routing is the set of processes and rules used to route a call and any subsequent mid-dialog SIP requests to their proper (SIP) destination. More generally, call routing can be thought of as the set of processes and rules that are used to route a real-time session to its termination point.

呼叫路由是用于将呼叫和任何后续中间对话SIP请求路由到其适当(SIP)目的地的一组过程和规则。更一般地说,呼叫路由可以被认为是用于将实时会话路由到其终止点的一组进程和规则。

3.5. PSTN
3.5. 公用电话网

The term "PSTN" refers to the Public Switched Telephone Network. In particular, the PSTN refers to the collection of interconnected, circuit-switched, voice-oriented public telephone networks, both commercial and government-owned. In general, PSTN terminals are addressed using E.164 numbers; however, various dial-plans (such as emergency services dial-plans) may not directly use E.164 numbers.

术语“PSTN”指公共交换电话网。特别是,PSTN是指商业和政府所有的互连、电路交换、面向语音的公共电话网络的集合。通常,PSTN终端使用E.164号码寻址;但是,各种拨号计划(如紧急服务拨号计划)可能不会直接使用E.164号码。

3.6. IP Path
3.6. IP路径

For the purposes of this document, an IP path is defined to be a sequence of zero or more IP router hops.

在本文档中,IP路径定义为零个或多个IP路由器跃点的序列。

3.7. Peer Network
3.7. 对等网络

This document defines a peer network as the set of SIP user agents (UAs) (customers) that are associated with a single administrative domain and can be reached via some IP path. Note that such a peer network may also contain end-users who are located on the PSTN (and hence may also be interconnected with the PSTN) as long as they are also reachable via some IP path.

本文档将对等网络定义为一组SIP用户代理(UAs)(客户),这些代理与单个管理域关联,并可通过某些IP路径访问。注意,这样的对等网络还可以包含位于PSTN上的最终用户(因此也可以与PSTN互连),只要它们也可以通过一些IP路径到达。

3.8. Service Provider
3.8. 服务提供商

A Service Provider (SP) is defined to be an entity that provides layer 3 (IP) transport of SIP signaling and media packets. Example services may include, but are not limited to, Ethernet Private Line (EPL), Frame Relay, and IP Virtual Private Network (VPN). An example of this may be an Internet Service Provider (ISP).

服务提供商(SP)被定义为提供SIP信令和媒体分组的第3层(IP)传输的实体。示例服务可以包括但不限于以太网专用线(EPL)、帧中继和IP虚拟专用网(VPN)。例如,互联网服务提供商(ISP)。

3.9. SIP Service Provider
3.9. SIP服务提供商

A SIP Service Provider (SSP) is an entity that provides session services utilizing SIP signaling to its customers. In the event that the SSP is also a function of the SP, it may also provide media streams to its customers. Such an SSP may additionally be peered with other SSPs. An SSP may also interconnect with the PSTN. An SSP may also be referred to as an Internet Telephony Service Provider (ITSP). While the terms ITSP and SSP are frequently used interchangeably, this document and other subsequent SIP peering-related documents should use the term SSP. SSP more accurately depicts the use of SIP as the underlying layer 5 signaling protocol.

SIP服务提供商(SSP)是利用SIP信令向其客户提供会话服务的实体。如果SSP也是SP的一项功能,它还可以向其客户提供媒体流。此类SSP还可与其他SSP进行对等。SSP还可以与PSTN互连。SSP也可称为互联网电话服务提供商(ITSP)。虽然术语ITSP和SSP经常互换使用,但本文档和其他后续SIP对等相关文档应使用术语SSP。SSP更准确地描述了SIP作为底层第5层信令协议的使用。

4. Peering
4. 窥视

While the precise definition of the term "peering" is the subject of considerable debate, peering in general refers to the negotiation of reciprocal interconnection arrangements, settlement-free or otherwise, between operationally independent service providers.

虽然“对等”一词的确切定义引起了相当大的争议,但对等一般指的是在运营独立的服务提供商之间进行的互惠互连安排的谈判,无论是免结算还是其他方式。

This document distinguishes two types of peering, layer 3 peering and layer 5 peering, which are described below.

本文档区分两种类型的对等,第3层对等和第5层对等,如下所述。

4.1. Layer 3 Peering
4.1. 第三层对等

Layer 3 peering refers to interconnection of two service providers' networks for the purposes of exchanging IP packets that are destined for one (or both) of the peer's networks. Layer 3 peering is generally agnostic to the IP payload, and is frequently achieved using a routing protocol such as the Border Gateway Protocol (BGP) [6] to exchange the required routing information.

第3层对等指的是两个服务提供商网络的互连,目的是交换目的地为一个(或两个)对等网络的IP数据包。第3层对等通常与IP有效负载无关,并且通常使用诸如边界网关协议(BGP)[6]之类的路由协议来实现,以交换所需的路由信息。

An alternate, perhaps more operational, definition of layer 3 peering is that two peers exchange only customer routes, and hence any traffic between peers terminates on one of the peers' networks or the peer's customer's network.

第3层对等的另一种可能更具操作性的定义是,两个对等方仅交换客户路由,因此对等方之间的任何通信都终止于对等方的一个网络或对等方的客户网络。

4.2. Layer 5 Peering
4.2. 第5层对等

Layer 5 (session) peering refers to interconnection of two SSPs for the purposes of routing real-time (or quasi-real-time) call signaling between their respective customers using SIP methods. Such peering may be direct or indirect (see Section 4.2.1 and Section 4.2.2 below). Note that media streams associated with this signaling (if any) are not constrained to follow the same set of IP paths.

第5层(会话)对等指的是两个SSP的互连,用于使用SIP方法在各自客户之间路由实时(或准实时)呼叫信令。这种对等可以是直接的或间接的(见下文第4.2.1节和第4.2.2节)。请注意,与此信令(如果有)相关联的媒体流不受限制以遵循同一组IP路径。

4.2.1. Direct Peering
4.2.1. 直接窥视

Direct peering describes those cases in which two SSPs peer without using an intervening layer 5 network.

直接对等描述了两个SSP在不使用中间第5层网络的情况下进行对等的情况。

4.2.2. Indirect Peering
4.2.2. 间接窥视

Indirect, or transit, peering refers to the establishment of either a signaling and media path or a signaling path alone via one (or more) layer 5 transit network(s). In this case, it is generally required that a trust relationship is established between the originating SSP and the transit SSP on one side, and between the transit SSP and the termination SSP on the other side.

间接或传输对等是指通过一个(或多个)第5层传输网络单独建立信令和媒体路径或信令路径。在这种情况下,通常要求在发起SSP和中转SSP之间建立一种信任关系,并在中转SSP和终止SSP之间建立一种信任关系。

4.2.3. On-Demand Peering
4.2.3. 按需窥视

SSPs are said to peer on-demand when they are able to exchange SIP traffic without any pre-association prior to the origination of a real-time transaction (like a SIP message) between the domains. Any information that needs to be exchanged between domains in support of peering can be learned through a dynamic protocol mechanism. On-demand peering can occur as direct or indirect.

当SSP能够在域之间发起实时事务(如SIP消息)之前在没有任何预关联的情况下交换SIP通信量时,它们被称为按需对等。需要在域之间交换以支持对等的任何信息都可以通过动态协议机制学习。按需对等可以直接或间接进行。

4.2.4. Static Peering
4.2.4. 静态窥视

SSPs are said to peer statically when pre-association between providers is required for the initiation of any real-time transactions (like a SIP message). Static peering can occur as direct or indirect. An example of static peering is a federation. Each of the peers within the federation must first agree on a common set of rules and guidelines for peering, thus pre-associating with each other prior to initiating session requests.

当启动任何实时事务(如SIP消息)需要提供者之间的预关联时,SSP被称为静态对等。静态对等可以直接或间接发生。静态对等的一个例子是联合。联盟中的每个对等方必须首先就一组通用的对等规则和准则达成一致,从而在启动会话请求之前彼此预先关联。

4.3. Functions
4.3. 功能

The following are terms associated with the functions required for peering.

以下是与对等所需功能相关的术语。

4.3.1. Signaling Function
4.3.1. 信号功能

The Signaling Function (SF) performs routing of SIP requests for establishing and maintaining calls, and to assist in the discovery or exchange of parameters to be used by the Media Function (MF). The SF is a capability of SIP processing elements such as SIP proxies, SBEs, and user agents.

信令功能(SF)执行SIP请求的路由,以建立和维护呼叫,并协助发现或交换媒体功能(MF)使用的参数。SF是SIP处理元素(如SIP代理、SBE和用户代理)的能力。

4.3.2. Media Function
4.3.2. 媒体功能

The Media Function (MF) performs media-related functions such as media transcoding and media security implementation between two SSPs. The MF is a capability of SIP-session-associated media end-points such as DBEs and user agents.

媒体功能(MF)执行媒体相关功能,如两个SSP之间的媒体转码和媒体安全实现。MF是SIP会话相关媒体端点(如DBE和用户代理)的一种功能。

4.3.3. Look-Up Function
4.3.3. 查找函数

The Look-Up Function (LUF) determines for a given request the target domain to which the request should be routed. An example of an LUF is an ENUM [4] look-up or a SIP INVITE request to a SIP proxy providing redirect responses for peers.

查找功能(LUF)为给定请求确定请求应路由到的目标域。LUF的一个示例是对SIP代理的枚举[4]查找或SIP INVITE请求,该SIP代理为对等方提供重定向响应。

In some cases, some entity (usually a 3rd party or federation) provides peering assistance to the originating SSP by providing this function. The assisting entity may provide information relating to direct (Section 4.2.1) or indirect (Section 4.2.2) peering as necessary.

在某些情况下,某些实体(通常是第三方或联盟)通过提供此功能向发起SSP提供对等协助。协助实体可根据需要提供与直接(第4.2.1节)或间接(第4.2.2节)窥视相关的信息。

4.3.4. Location Routing Function
4.3.4. 位置路由函数

The Location Routing Function (LRF) determines for the target domain of a given request the location of the SF in that domain, and optionally develops other SED required to route the request to that domain. An example of the LRF may be applied to either example in Section 4.3.3. Once the ENUM response or SIP 302 redirect is received with the destination's SIP URI, the LRF must derive the destination peer's SF from the FQDN in the domain portion of the URI.

位置路由功能(LRF)为给定请求的目标域确定SF在该域中的位置,并可选地开发将请求路由到该域所需的其他SED。LRF示例可适用于第4.3.3节中的任一示例。一旦接收到带有目标SIP URI的枚举响应或SIP 302重定向,LRF必须从URI的域部分中的FQDN派生目标对等方的SF。

In some cases, some entity (usually a 3rd party or federation) provides peering assistance to the originating SSP by providing this function. The assisting entity may provide information relating to direct (Section 4.2.1) or indirect (Section 4.2.2) peering as necessary.

在某些情况下,某些实体(通常是第三方或联盟)通过提供此功能向发起SSP提供对等协助。协助实体可根据需要提供与直接(第4.2.1节)或间接(第4.2.2节)窥视相关的信息。

5. Federations
5. 联合会

A federation is a group of SSPs that agree to exchange calls with each other via SIP and who agree on a set of administrative rules for such calls (settlement, abuse-handling, etc.) and specific rules for the technical details of the peering.

联合是一组SSP,它们同意通过SIP相互交换呼叫,并就此类呼叫的一组管理规则(结算、滥用处理等)和对等技术细节的特定规则达成一致。

The following provides examples of rules that the peers of a federation may agree to and enforce upon all participants:

以下提供了联盟的对等方可能同意并对所有参与者强制执行的规则示例:

o Common domain for all federation peers (e.g., bob@peer1.federation.example.com)

o 所有联盟对等方的公共域(例如。,bob@peer1.federation.example.com)

o Codec rules (e.g., all peers must use the ITU-T G.711 codec [10])

o 编解码器规则(例如,所有对等方必须使用ITU-T g.711编解码器[10])

o Authentication preference (e.g., all peers must use TLS when requesting to establish sessions with other peers)

o 身份验证首选项(例如,当请求与其他对等方建立会话时,所有对等方必须使用TLS)

o Transport protocol (e.g., all peers must use TCP)

o 传输协议(例如,所有对等方必须使用TCP)

o SIP address resolution mechanisms (e.g., all peers must use ENUM for resolving telephone numbers to SIP URIs)

o SIP地址解析机制(例如,所有对等方必须使用ENUM将电话号码解析为SIP URI)

Finally, note that an SSP can be a member of:

最后,请注意,SSP可以是以下组织的成员:

- No federation (e.g., the SSP has only bilateral peering agreements)

- 没有联盟(例如,SSP只有双边对等协议)

- A single federation

- 单一联邦

- Multiple federations

- 多个联合会

Also, an SSP can have any combination of bilateral and multilateral (i.e., federated) peers.

此外,SSP可以具有双边和多边(即联邦)对等点的任意组合。

6. Security Considerations
6. 安全考虑

This document introduces no new security considerations. However, it is important to note that session peering, as described in this document, has a wide variety of security issues that should be considered in documents addressing both protocol and use-case analysis.

本文档没有引入新的安全注意事项。然而,需要注意的是,如本文档所述,会话对等具有各种各样的安全问题,在解决协议和用例分析的文档中都应该考虑这些问题。

7. Acknowledgments
7. 致谢

Many of the definitions were gleaned from detailed discussions on the SPEERMINT, ENUM, and SIPPING mailing lists. Scott Brim, John Elwell, Mike Hammer, Eli Katz, Gaurav Kulshreshtha, Otmar Lendl, Jason Livingood, Alexander Mayrhofer, Jean-Francois Mule, Jonathan Rosenberg, David Schwartz, Richard Shockey, Henry Sinnreich, Richard Stastny, Hannes Tschofenig, Adam Uzelac, and Dan Wing all made valuable contributions to early versions of this document. Patrik Faltstrom also made many insightful comments to early versions of this document.

许多定义都是从关于SPEERMINT、ENUM和SIPPING邮件列表的详细讨论中收集的。Scott Brim、John Elwell、Mike Hammer、Eli Katz、Gaurav Kulshreshtha、Otmar Lendl、Jason Livingood、Alexander Mayrhofer、Jean-Francois Mule、Jonathan Rosenberg、David Schwartz、Richard Shockey、Henry Sinnreich、Richard Stastny、Hannes Tschofenig、Adam Uzelac和Dan Wing都对本文件的早期版本做出了宝贵贡献。Patrik Faltstrom还对本文件的早期版本发表了许多有见地的评论。

8. Informative References
8. 资料性引用

[1] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.

[1] Gulbrandsen,A.,Vixie,P.和L.Esibov,“用于指定服务位置(DNS SRV)的DNS RR”,RFC 2782,2000年2月。

[2] 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.

[2] Rosenberg,J.,Schulzrinne,H.,Camarillo,G.,Johnston,A.,Peterson,J.,Sparks,R.,Handley,M.,和E.Schooler,“SIP:会话启动协议”,RFC 3261,2002年6月。

[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.

[3] Mealling,M.“动态委托发现系统(DDDS)第四部分:统一资源标识符(URI)”,RFC34042002年10月。

[4] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.

[4] Faltstrom,P.和M.Mealling,“E.164到统一资源标识符(URI)动态委托发现系统(DDDS)应用程序(ENUM)”,RFC 3761,2004年4月。

[5] International Telecommunications Union, "The International Public Telecommunication Numbering Plan", ITU-T Recommendation E.164, February 2005.

[5] 国际电信联盟,“国际公共电信编号计划”,ITU-T建议E.164,2005年2月。

[6] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.

[6] Rekhter,Y.,Ed.,Li,T.,Ed.,和S.Hares,Ed.,“边境网关协议4(BGP-4)”,RFC 42712006年1月。

[7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[7] Dierks,T.和E.Rescorla,“传输层安全(TLS)协议版本1.2”,RFC 5246,2008年8月。

[8] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.

[8] Postel,J.,“用户数据报协议”,STD 6,RFC 768,1980年8月。

[9] Postel, J., "DoD standard Transmission Control Protocol", RFC 761, January 1980.

[9] Postel,J.,“国防部标准传输控制协议”,RFC 761,1980年1月。

[10] ITU Recommendation G.711 (11/88) - Pulse code modulation (PCM) of voice frequencies.

[10] ITU建议G.711(11/88)-语音频率的脉冲编码调制(PCM)。

Authors' Addresses

作者地址

Daryl Malas (editor) CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA EMail: d.malas@cablelabs.com

Daryl Malas(编辑)CableLabs 858 Coal Creek Circle Louisville,CO 80027美国电子邮件:d。malas@cablelabs.com

David Meyer (editor) EMail: dmm@1-4-5.net

David Meyer(编辑)电子邮件:dmm@1-4-5.net