Internet Engineering Task Force (IETF) J. Hautakorpi, Ed.
Request for Comments: 5853 G. Camarillo
Category: Informational Ericsson
ISSN: 2070-1721 R. Penfield
Acme Packet
A. Hawrylyshen
Skype, Inc.
M. Bhatia
3CLogic
April 2010
Internet Engineering Task Force (IETF) J. Hautakorpi, Ed.
Request for Comments: 5853 G. Camarillo
Category: Informational Ericsson
ISSN: 2070-1721 R. Penfield
Acme Packet
A. Hawrylyshen
Skype, Inc.
M. Bhatia
3CLogic
April 2010
Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments
会话启动协议（SIP）会话边界控制（SBC）部署的要求
Abstract
摘要
This document describes functions implemented in Session Initiation Protocol (SIP) intermediaries known as Session Border Controllers (SBCs). The goal of this document is to describe the commonly provided functions of SBCs. A special focus is given to those practices that are viewed to be in conflict with SIP architectural principles. This document also explores the underlying requirements of network operators that have led to the use of these functions and practices in order to identify protocol requirements and determine whether those requirements are satisfied by existing specifications or if additional standards work is required.
本文档描述了在称为会话边界控制器（SBC）的会话启动协议（SIP）中介中实现的功能。本文件的目的是描述SBC的常用功能。特别关注那些被认为与SIP体系结构原则相冲突的实践。本文件还探讨了导致使用这些功能和实践的网络运营商的基本要求，以确定协议要求，并确定现有规范是否满足这些要求，或者是否需要额外的标准工作。
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/rfc5853.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5853.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Background on SBCs ..............................................4
2.1. Peering Scenario ...........................................6
2.2. Access Scenario ............................................6
3. Functions of SBCs ...............................................8
3.1. Topology Hiding ............................................8
3.1.1. General Information and Requirements ................8
3.1.2. Architectural Issues ................................9
3.1.3. Example .............................................9
3.2. Media Traffic Management ..................................11
3.2.1. General Information and Requirements ...............11
3.2.2. Architectural Issues ...............................12
3.2.3. Example ............................................13
3.3. Fixing Capability Mismatches ..............................14
3.3.1. General Information and Requirements ...............14
3.3.2. Architectural Issues ...............................14
3.3.3. Example ............................................15
3.4. Maintaining SIP-Related NAT Bindings ......................15
3.4.1. General Information and Requirements ...............15
3.4.2. Architectural Issues ...............................16
3.4.3. Example ............................................17
3.5. Access Control ............................................18
3.5.1. General Information and Requirements ...............18
3.5.2. Architectural Issues ...............................19
3.5.3. Example ............................................19
3.6. Protocol Repair ...........................................20
3.6.1. General Information and Requirements ...............20
3.6.2. Architectural Issues ...............................21
3.6.3. Examples ...........................................21
3.7. Media Encryption ..........................................21
3.7.1. General Information and Requirements ...............21
3.7.2. Architectural Issues ...............................22
3.7.3. Example ............................................22
4. Derived Requirements for Future SIP Standardization Work .......23
5. Security Considerations ........................................23
6. Acknowledgements ...............................................24
7. References .....................................................25
7.1. Normative References ......................................25
7.2. Informative References ....................................25
1. Introduction ....................................................4
2. Background on SBCs ..............................................4
2.1. Peering Scenario ...........................................6
2.2. Access Scenario ............................................6
3. Functions of SBCs ...............................................8
3.1. Topology Hiding ............................................8
3.1.1. General Information and Requirements ................8
3.1.2. Architectural Issues ................................9
3.1.3. Example .............................................9
3.2. Media Traffic Management ..................................11
3.2.1. General Information and Requirements ...............11
3.2.2. Architectural Issues ...............................12
3.2.3. Example ............................................13
3.3. Fixing Capability Mismatches ..............................14
3.3.1. General Information and Requirements ...............14
3.3.2. Architectural Issues ...............................14
3.3.3. Example ............................................15
3.4. Maintaining SIP-Related NAT Bindings ......................15
3.4.1. General Information and Requirements ...............15
3.4.2. Architectural Issues ...............................16
3.4.3. Example ............................................17
3.5. Access Control ............................................18
3.5.1. General Information and Requirements ...............18
3.5.2. Architectural Issues ...............................19
3.5.3. Example ............................................19
3.6. Protocol Repair ...........................................20
3.6.1. General Information and Requirements ...............20
3.6.2. Architectural Issues ...............................21
3.6.3. Examples ...........................................21
3.7. Media Encryption ..........................................21
3.7.1. General Information and Requirements ...............21
3.7.2. Architectural Issues ...............................22
3.7.3. Example ............................................22
4. Derived Requirements for Future SIP Standardization Work .......23
5. Security Considerations ........................................23
6. Acknowledgements ...............................................24
7. References .....................................................25
7.1. Normative References ......................................25
7.2. Informative References ....................................25
In the past few years, there has been a rapid adoption of the Session Initiation Protocol (SIP) [1] and deployment of SIP-based communications networks. This has often outpaced the development and implementation of protocol specifications to meet network operator requirements. This has led to the development of proprietary solutions. Often, these proprietary solutions are implemented in network intermediaries known in the marketplace as Session Border Controllers (SBCs) because they typically are deployed at the border between two networks. The reason for this is that network policies are typically enforced at the edge of the network.
在过去几年中，会话发起协议（SIP）[1]得到了迅速的采用，并部署了基于SIP的通信网络。这通常超过了协议规范的开发和实施，以满足网络运营商的要求。这导致了专有解决方案的开发。通常，这些专有解决方案在市场上称为会话边界控制器（SBC）的网络中介中实现，因为它们通常部署在两个网络之间的边界。原因是网络策略通常在网络边缘强制执行。
Even though many SBCs currently behave in ways that can break end-to-end security and impact feature negotiations, there is clearly a market for them. Network operators need many of the features current SBCs provide, and often there are no standard mechanisms available to provide them.
尽管许多SBC目前的行为方式可能会破坏端到端安全性并影响功能协商，但它们显然有市场。网络运营商需要当前SBC提供的许多功能，而且通常没有可用的标准机制来提供这些功能。
The purpose of this document is to describe functions implemented in SBCs. A special focus is given to those practices that conflict with SIP architectural principles in some way. The document also explores the underlying requirements of network operators that have led to the use of these functions and practices in order to identify protocol requirements and determine whether those requirements are satisfied by existing specifications or if additional standards work is required.
本文件旨在描述SBCs中实现的功能。特别关注那些在某种程度上与SIP体系结构原则冲突的实践。本文件还探讨了导致使用这些功能和实践的网络运营商的基本要求，以确定协议要求，并确定现有规范是否满足这些要求，或者是否需要额外的标准工作。
The term SBC is relatively non-specific, since it is not standardized or defined anywhere. Nodes that may be referred to as SBCs but do not implement SIP are outside the scope of this document.
SBC一词相对来说是非特定的，因为它在任何地方都没有标准化或定义。可称为SBC但未实现SIP的节点不在本文档范围内。
SBCs usually sit between two service provider networks in a peering environment, or between an access network and a backbone network to provide service to residential and/or enterprise customers. They provide a variety of functions to enable or enhance session-based multi-media services (e.g., Voice over IP). These functions include: a) perimeter defense (access control, topology hiding, and denial-of-service prevention and detection); b) functionality not available in the endpoints (NAT traversal, protocol interworking or repair); and c) traffic management (media monitoring and Quality of Service (QoS)). Some of these functions may also get integrated into other SIP elements (like pre-paid platforms, Third Generation Partnership Project (3GPP) Proxy CSCF (P-CSCF) [6], 3GPP I-CSCF, etc.).
SBC通常位于对等环境中的两个服务提供商网络之间，或者位于接入网络和骨干网络之间，以向住宅和/或企业客户提供服务。它们提供多种功能，以启用或增强基于会话的多媒体服务（例如，IP语音）。这些功能包括：a）周界防御（访问控制、拓扑隐藏、拒绝服务预防和检测）；b） 端点中不可用的功能（NAT遍历、协议互通或修复）；和c）流量管理（媒体监控和服务质量（QoS））。其中一些功能还可以集成到其他SIP元素中（如预付费平台、第三代合作伙伴关系项目（3GPP）代理CSCF（P-CSCF）[6]、3GPP I-CSCF等）。
SIP-based SBCs typically handle both signaling and media and can implement behavior that is equivalent to a "privacy service" (as described in [2]) performing both Header Privacy and Session Privacy). SBCs often modify certain SIP headers and message bodies that proxies are not allowed to modify. Consequently, they are, by definition, B2BUAs (Back-to-Back User Agents). The transparency of these B2BUAs varies depending on the functions they perform. For example, some SBCs modify the session description carried in the message and insert a Record-Route entry. Other SBCs replace the value of the Contact header field with the SBCs' address and generate a new Call-ID and new To and From tags.
基于SIP的SBC通常处理信令和媒体，并且可以实现相当于“隐私服务”（如[2]所述）的行为，同时执行报头隐私和会话隐私。SBC经常修改某些不允许代理修改的SIP头和消息体。因此，根据定义，它们是B2BUAs（背靠背用户代理）。这些B2BUA的透明度因其执行的功能而异。例如，某些SBC修改消息中包含的会话描述，并插入记录路由条目。其他SBC使用SBC的地址替换Contact header字段的值，并生成新的呼叫ID和新的To和From标记。
+-----------------+
| SBC |
[signaling] | +-----------+ |
<------------|->| signaling |<-|---------->
outer | +-----------+ | inner
network | | | network
| +-----------+ |
<------------|->| media |<-|---------->
[media] | +-----------+ |
+-----------------+
+-----------------+
| SBC |
[signaling] | +-----------+ |
<------------|->| signaling |<-|---------->
outer | +-----------+ | inner
network | | | network
| +-----------+ |
<------------|->| media |<-|---------->
[media] | +-----------+ |
+-----------------+
Figure 1: SBC Architecture
图1:SBC体系结构
Figure 1 shows the logical architecture of an SBC, which includes a signaling and a media component. In this document, the terms outer and inner network are used for describing these two networks. An SBC is logically associated with the inner network, and it typically provides functions such as controlling and protecting access to the inner network from the outer network. The SBC itself is configured and managed by the organization operating the inner network.
图1显示了SBC的逻辑架构，其中包括信令和媒体组件。在本文档中，术语外部网络和内部网络用于描述这两个网络。SBC在逻辑上与内部网络相关联，并且它通常提供诸如控制和保护外部网络对内部网络的访问等功能。SBC本身由运行内部网络的组织进行配置和管理。
In some scenarios, SBCs operate with users' (implicit or explicit) consent; while in others, they operate without users' consent (this latter case can potentially cause problems). For example, if an SBC in the same administrative domain as a set of enterprise users performs topology hiding (see Section 3.1), the enterprise users can choose to route their SIP messages through it. If they choose to route through the SBC, then the SBC can be seen as having the users' implicit consent. Another example is a scenario where a service provider has broken gateways and it deploys an SBC in front of them for protocol repair reasons (see Section 3.6). Users can choose to configure the SBC as their gateway and, so, the SBC can be seen as having the users' implicit consent.
在某些情况下，SBC在用户（隐式或显式）同意的情况下运行；而在其他情况下，它们在未经用户同意的情况下运行（后一种情况可能会导致问题）。例如，如果与一组企业用户位于同一管理域中的SBC执行拓扑隐藏（请参见第3.1节），则企业用户可以选择通过它路由他们的SIP消息。如果他们选择通过SBC路由，则SBC可以被视为获得用户的默许。另一个例子是一个场景，其中服务提供商破坏了网关，并且出于协议修复的原因在网关前面部署了一个SBC（参见第3.6节）。用户可以选择将SBC配置为他们的网关，因此，SBC可以被视为获得用户的默许。
A typical peering scenario involves two network operators who exchange traffic with each other. An example peering scenario is illustrated in Figure 2. An originating gateway (GW-A1) in Operator A's network sends an INVITE that is routed to the SBC in Operator B's network. Then, the SBC forward it to the softswitch (SS-B). The softswitch responds with a redirect (3xx) message back to the SBC that points to the appropriate terminating gateway (GW-B1) in Operator B's network. If Operator B does not have an SBC, the redirect message would go to the Operator A's originating gateway. After receiving the redirect message, the SBC sends the INVITE to the terminating gateway.
典型的对等场景涉及两个互相交换流量的网络运营商。图2展示了一个示例对等场景。运营商A网络中的始发网关（GW-A1）发送一个INVITE，该INVITE路由到运营商B网络中的SBC。然后，SBC将其转发给软交换机（SS-B）。软交换以重定向（3xx）消息回应SBC，该消息指向运营商B网络中的相应终端网关（GW-B1）。如果操作员B没有SBC，重定向消息将发送到操作员A的原始网关。收到重定向消息后，SBC向终止网关发送INVITE。
Operator A . Operator B
.
. 2) INVITE
+-----+ . /--------------->+-----+
|SS-A | . / 3) 3xx (redir.) |SS-B |
+-----+ . / /---------------+-----+
. / /
+-----+ 1) INVITE +-----+--/ / +-----+
|GW-A1|---------------->| SBC |<---/ 4) INVITE |GW-B1|
+-----+ +-----+---------------------->+-----+
.
+-----+ . +-----+
|GW-A2| . |GW-B2|
+-----+ . +-----+
Operator A . Operator B
.
. 2) INVITE
+-----+ . /--------------->+-----+
|SS-A | . / 3) 3xx (redir.) |SS-B |
+-----+ . / /---------------+-----+
. / /
+-----+ 1) INVITE +-----+--/ / +-----+
|GW-A1|---------------->| SBC |<---/ 4) INVITE |GW-B1|
+-----+ +-----+---------------------->+-----+
.
+-----+ . +-----+
|GW-A2| . |GW-B2|
+-----+ . +-----+
Figure 2: Peering with SBC
图2：使用SBC进行对等
From the SBC's perspective the Operator A is the outer network, and Operator B is the inner network. Operator B can use the SBC, for example, to control access to its network, protect its gateways and softswitches from unauthorized use and denial-of-service (DoS) attacks, and monitor the signaling and media traffic. It also simplifies network management by minimizing the number of ACL (Access Control List) entries in the gateways. The gateways do not need to be exposed to the peer network, and they can restrict access (both media and signaling) to the SBCs. The SBC helps ensure that only media from sessions the SBC authorizes will reach the gateway.
从SBC的角度来看，运营商A是外部网络，运营商B是内部网络。例如，运营商B可以使用SBC控制对其网络的访问，保护其网关和软交换机免受未经授权的使用和拒绝服务（DoS）攻击，并监控信令和媒体流量。它还通过最小化网关中ACL（访问控制列表）条目的数量来简化网络管理。网关不需要暴露于对等网络，它们可以限制对SBC的访问（媒体和信令）。SBC有助于确保只有SBC授权的会话中的媒体才能到达网关。
In an access scenario, presented in Figure 3, the SBC is placed at the border between the access network (outer network) and the operator's network (inner network) to control access to the operator's network, protect its components (media servers,
在图3所示的接入场景中，SBC位于接入网络（外部网络）和运营商网络（内部网络）之间的边界，以控制对运营商网络的接入，保护其组件（媒体服务器，
application servers, gateways, etc.) from unauthorized use and DoS attacks, and monitor the signaling and media traffic. Also, since the SBC is call stateful, it may provide access control functions to prevent over-subscription of the access links. Endpoints are configured with the SBC as their outbound proxy address. The SBC routes requests to one or more proxies in the operator network.
应用服务器、网关等）以防止未经授权的使用和DoS攻击，并监控信令和媒体流量。此外，由于SBC是有呼叫状态的，因此它可以提供访问控制功能以防止对访问链路的过度订阅。端点配置为SBC作为其出站代理地址。SBC将请求路由到运营商网络中的一个或多个代理。
Access Network Operator Network
接入网运营商网络
+-----+
| UA1 |<---------\
+-----+ \
\
+-----+ \------->+-----+ +-------+
| UA2 |<-------------------->| SBC |<----->| proxy |<-- -
+-----+ /--->+-----+ +-------+
/
+-----+ +-----+ /
| UA3 +---+ NAT |<---/
+-----+ +-----+
+-----+
| UA1 |<---------\
+-----+ \
\
+-----+ \------->+-----+ +-------+
| UA2 |<-------------------->| SBC |<----->| proxy |<-- -
+-----+ /--->+-----+ +-------+
/
+-----+ +-----+ /
| UA3 +---+ NAT |<---/
+-----+ +-----+
Figure 3: Access Scenario with SBC
图3:SBC的访问场景
The SBC may be hosted in the access network (e.g., this is common when the access network is an enterprise network), or in the operator network (e.g., this is common when the access network is a residential or small business network). Despite where the SBC is hosted, it is managed by the organization maintaining the operator network.
SBC可以托管在接入网络中（例如，当接入网络是企业网络时，这是常见的），或者托管在运营商网络中（例如，当接入网络是住宅或小型企业网络时，这是常见的）。无论SBC位于何处，它都由维护运营商网络的组织进行管理。
Some endpoints may be behind enterprise or residential NATs. In cases where the access network is a private network, the SBC is a NAT for all traffic. It is noteworthy that SIP traffic may have to traverse more than one NAT. The proxy usually does authentication and/or authorization for registrations and outbound calls. The SBC modifies the REGISTER request so that subsequent requests to the registered address-of-record are routed to the SBC. This is done either with a Path header field [3] or by modifying the Contact to point at the SBC.
某些端点可能位于企业或住宅NAT的后面。在接入网络是专用网络的情况下，SBC是所有流量的NAT。值得注意的是，SIP流量可能必须穿越多个NAT。代理通常对注册和出站呼叫进行身份验证和/或授权。SBC修改注册请求，以便将对已注册记录地址的后续请求路由到SBC。这可以通过路径头字段[3]或修改触点以指向SBC来完成。
The scenario presented in this section is a general one, and it applies also to other similar settings. One example from a similar setting is the one where an access network is the open internet, and the operator network is the network of a SIP service provider.
本节中介绍的场景是一般场景，也适用于其他类似设置。类似设置的一个示例是其中接入网络是开放互联网，而运营商网络是SIP服务提供商的网络。
This section lists those functions that are used in SBC deployments in current communication networks. Each subsection describes a particular function or feature, the operators' requirements for having it, explanation of any impact to the end-to-end SIP architecture, and a concrete implementation example. Each section also discusses potential concerns specific to that particular implementation technique. Suggestions for alternative implementation techniques that may be more architecturally compatible with SIP are outside the scope of this document.
本节列出了当前通信网络中SBC部署中使用的功能。每一小节都描述了一个特定的功能或特性、运营商拥有它的要求、对端到端SIP体系结构的任何影响的解释，以及一个具体的实现示例。每个部分还讨论特定于该特定实现技术的潜在关注点。关于在体系结构上与SIP更兼容的替代实现技术的建议超出了本文档的范围。
All the examples given in this section are simplified; only the relevant header lines from SIP and SDP (Session Description Protocol) [7] messages are displayed.
本节中给出的所有示例均已简化；仅显示SIP和SDP（会话描述协议）[7]消息中的相关标题行。
Topology hiding consists of limiting the amount of topology information given to external parties. Operators have a requirement for this functionality because they do not want the IP addresses of their equipment (proxies, gateways, application servers, etc.) to be exposed to outside parties. This may be because they do not want to expose their equipment to DoS attacks, they may use other carriers for certain traffic and do not want their customers to be aware of it, or they may want to hide their internal network architecture from competitors or partners. In some environments, the operator's customers may wish to hide the addresses of their equipment or the SIP messages may contain private, non-routable addresses.
拓扑隐藏包括限制提供给外部方的拓扑信息量。运营商需要此功能，因为他们不希望其设备（代理、网关、应用服务器等）的IP地址暴露于外部。这可能是因为他们不想让自己的设备暴露于DoS攻击之下，他们可能会使用其他运营商进行某些通信，并且不想让他们的客户知道这一点，或者他们可能想对竞争对手或合作伙伴隐藏其内部网络体系结构。在某些环境中，运营商的客户可能希望隐藏其设备的地址，或者SIP消息可能包含私有的、不可路由的地址。
The most common form of topology hiding is the application of header privacy (see Section 5.1 of [2]), which involves stripping Via and Record-Route headers, replacing the Contact header, and even changing Call-IDs. However, in deployments that use IP addresses instead of domain names in headers that cannot be removed (e.g., From and To headers), the SBC may replace these IP addresses with its own IP address or domain name.
拓扑隐藏最常见的形式是报头隐私的应用（见[2]第5.1节），其中包括剥离和记录路由报头、替换联系人报头，甚至更改呼叫ID。但是，在使用IP地址而不是无法删除的头中的域名（例如，从和到头）的部署中，SBC可以用自己的IP地址或域名替换这些IP地址。
For a reference, there are also other ways of hiding topology information than inserting an intermediary, like an SBC, to the signaling path. One of the ways is the UA-driven privacy mechanism [8], where the UA can facilitate the concealment of topology information.
作为参考，除了向信令路径插入中间层（如SBC）之外，还有其他隐藏拓扑信息的方法。其中一种方法是UA驱动的隐私机制[8]，其中UA可以帮助隐藏拓扑信息。
Performing topology hiding, as described above, by SBCs that do not have the users' consent presents some issues. This functionality is based on a hop-by-hop trust model as opposed to an end-to-end trust model. The messages are modified without the subscriber's consent and could potentially modify or remove information about the user's privacy, security requirements, and higher-layer applications that are communicated end-to-end using SIP. Neither user agent in an end-to-end call has any way to distinguish the SBC actions from a man-in-the-middle (MITM) attack.
如上所述，由未经用户同意的SBC执行拓扑隐藏会出现一些问题。此功能基于逐跳信任模型，而不是端到端信任模型。这些消息在未经订户同意的情况下被修改，可能会修改或删除有关用户隐私、安全要求以及使用SIP进行端到端通信的更高层应用程序的信息。端到端呼叫中的用户代理都无法区分SBC操作和中间人（MITM）攻击。
The topology hiding function does not work well with Authenticated Identity Management [4] in scenarios where the SBC does not have any kind of consent from the users. The Authenticated Identity Management mechanism is based on a hash value that is calculated from parts of From, To, Call-ID, CSeq, Date, and Contact header fields plus from the whole message body. If the authentication service is not provided by the SBC itself, the modification of the aforementioned header fields and the message body is in violation of [4]. Some forms of topology hiding are in violation, because they are, e.g., replacing the Contact header of a SIP message.
拓扑隐藏功能在SBC未获得用户任何形式的同意的情况下无法与身份验证管理[4]配合使用。经过身份验证的身份管理机制基于散列值，该散列值是从from、To、Call ID、CSeq、Date和Contact头字段的部分加上整个消息体计算得出的。如果SBC本身不提供身份验证服务，则对上述头字段和消息正文的修改违反了[4]。某些形式的拓扑隐藏是违规的，因为它们是，例如，替换SIP消息的联系人头。
The current way of implementing topology hiding consists of having an SBC act as a B2BUA (Back-to-Back User Agent) and remove all traces of topology information (e.g., Via and Record-Route entries) from outgoing messages.
当前实现拓扑隐藏的方法包括让SBC充当B2BUA（背靠背用户代理），并从传出消息中删除拓扑信息的所有跟踪（例如，通过和记录路由条目）。
Imagine the following example scenario: the SBC (p4.domain.example.com) receives an INVITE request from the inner network, which in this case is an operator network. The received SIP message is shown in Figure 4.
设想以下示例场景：SBC（p4.domain.example.com）从内部网络接收INVITE请求，在本例中，内部网络是一个运营商网络。接收到的SIP消息如图4所示。
INVITE sip:callee@u2.domain.example.com SIP/2.0
Via: SIP/2.0/UDP p3.middle.example.com;branch=z9hG4bK48jq9w174131.1
Via: SIP/2.0/UDP p2.example.com;branch=z9hG4bK18an6i9234172.1
Via: SIP/2.0/UDP p1.example.com;branch=z9hG4bK39bn2e5239289.1
Via: SIP/2.0/UDP u1.example.com;branch=z9hG4bK92fj4u7283927.1
Contact: sip:caller@u1.example.com
Record-Route: <sip:p3.middle.example.com;lr>
Record-Route: <sip:p2.example.com;lr>
Record-Route: <sip:p1.example.com;lr>
INVITE sip:callee@u2.domain.example.com SIP/2.0
Via: SIP/2.0/UDP p3.middle.example.com;branch=z9hG4bK48jq9w174131.1
Via: SIP/2.0/UDP p2.example.com;branch=z9hG4bK18an6i9234172.1
Via: SIP/2.0/UDP p1.example.com;branch=z9hG4bK39bn2e5239289.1
Via: SIP/2.0/UDP u1.example.com;branch=z9hG4bK92fj4u7283927.1
Contact: sip:caller@u1.example.com
Record-Route: <sip:p3.middle.example.com;lr>
Record-Route: <sip:p2.example.com;lr>
Record-Route: <sip:p1.example.com;lr>
Figure 4: INVITE Request Prior to Topology Hiding
图4：拓扑隐藏之前的INVITE请求
Then, the SBC performs a topology hiding function. In this scenario, the SBC removes and stores all existing Via and Record-Route headers, and then inserts Via and Record-Route header fields with its own SIP URI. After the topology hiding function, the message could appear as shown in Figure 5.
然后，SBC执行拓扑隐藏功能。在这种情况下，SBC删除并存储所有现有的Via和记录路由头，然后使用自己的SIPURI插入Via和记录路由头字段。在拓扑隐藏功能之后，消息可能会出现，如图5所示。
INVITE sip:callee@u2.domain.example.com SIP/2.0
Via: SIP/2.0/UDP p4.domain.example.com;branch=z9hG4bK92es3w230129.1
Contact: sip:caller@u1.example.com
Record-Route: <sip:p4.domain.example.com;lr>
INVITE sip:callee@u2.domain.example.com SIP/2.0
Via: SIP/2.0/UDP p4.domain.example.com;branch=z9hG4bK92es3w230129.1
Contact: sip:caller@u1.example.com
Record-Route: <sip:p4.domain.example.com;lr>
Figure 5: INVITE Request after Topology Hiding
图5：拓扑隐藏后的INVITE请求
Like a regular proxy server that inserts a Record-Route entry, the SBC handles every single message of a given SIP dialog. If the SBC loses state (e.g., SBC restarts for some reason), it may not be able to route messages properly (note: some SBCs preserve the state information also on restart). For example, if the SBC removes Via entries from a request and then restarts, thus losing state; the SBC may not be able to route responses to that request, depending on the information that was lost when the SBC restarted.
与插入记录路由条目的常规代理服务器一样，SBC处理给定SIP对话框的每条消息。如果SBC失去状态（例如，SBC因某种原因重新启动），它可能无法正确路由消息（注意：一些SBC在重新启动时也会保留状态信息）。例如，如果SBC从请求中删除Via条目，然后重新启动，从而丢失状态；SBC可能无法路由对该请求的响应，这取决于SBC重新启动时丢失的信息。
This is only one example of topology hiding. Besides topology hiding (i.e., information related to the network elements is being hidden), SBCs may also do identity hiding (i.e., information related to identity of subscribers is being hidden). While performing identity hiding, SBCs may modify Contact header field values and other header fields containing identity information. The header fields containing identity information is listed in Section 4.1 of [2]. Since the publication of [2], the following header fields containing identity information have been defined: "P-Asserted-Identity", "Referred-By", "Identity", and "Identity-Info".
这只是拓扑隐藏的一个示例。除了拓扑隐藏（即，与网元相关的信息被隐藏），sbc还可以进行身份隐藏（即，与订户身份相关的信息被隐藏）。在执行身份隐藏时，SBC可以修改联系人标头字段值和包含身份信息的其他标头字段。[2]第4.1节列出了包含身份信息的标题字段。自[2]发表以来，定义了以下包含身份信息的标题字段：“P-Asserted-identity”、“refered By”、“identity”和“identity Info”。
Media traffic management is the function of controlling media traffic. Network operators may require this functionality in order to control the traffic being carried on their network on behalf of their subscribers. Traffic management helps the creation of different kinds of billing models (e.g., video telephony can be priced differently than voice-only calls) and it also makes it possible for operators to enforce the usage of selected codecs.
媒体流量管理是控制媒体流量的功能。网络运营商可能需要此功能，以便代表其用户控制其网络上的流量。流量管理有助于创建不同类型的计费模型（例如，视频电话的定价可能不同于纯语音电话），而且它还使运营商能够强制使用选定的编解码器。
One of the use cases for media traffic management is the implementation of intercept capabilities that are required to support audit or legal obligations. It is noteworthy that the legal obligations mainly apply to operators providing voice services, and those operators typically have infrastructure (e.g., SIP proxies acting as B2BUAs) for providing intercept capabilities even without SBCs.
媒体流量管理的一个用例是实现支持审计或法律义务所需的拦截功能。值得注意的是，法律义务主要适用于提供语音服务的运营商，这些运营商通常拥有基础设施（例如，充当B2BUA的SIP代理），即使没有SBC，也能提供拦截能力。
Since the media path is independent of the signaling path, the media may not traverse through the operator's network unless the SBC modifies the session description. By modifying the session description, the SBC can force the media to be sent through a media relay which may be co-located with the SBC. This kind of traffic management can be done, for example, to ensure a certain QoS level, or to ensure that subscribers are using only allowed codecs. It is noteworthy that the SBCs do not have direct ties to routing topology and they do not, for example, change bandwidth reservations on Traffic Engineering (TE) tunnels, nor do they have direct interaction with routing protocol.
由于媒体路径独立于信令路径，除非SBC修改会话描述，否则媒体可能不会穿过运营商的网络。通过修改会话描述，SBC可以强制通过媒体中继发送媒体，媒体中继可以与SBC位于同一位置。例如，可以进行这种流量管理，以确保一定的QoS水平，或确保订阅者只使用允许的编解码器。值得注意的是，SBC与路由拓扑没有直接联系，例如，它们不会更改流量工程（TE）隧道上的带宽预留，也不会与路由协议直接交互。
Some operators do not want to manage the traffic, but only to monitor it to collect statistics and make sure that they are able to meet any business service level agreements with their subscribers and/or partners. The protocol techniques, from the SBC's viewpoint, needed for monitoring media traffic are the same as for managing media traffic.
一些运营商不想管理流量，只想监控流量以收集统计数据，并确保能够满足与订户和/或合作伙伴签订的任何业务服务级别协议。从SBC的观点来看，监控媒体流量所需的协议技术与管理媒体流量所需的协议技术相同。
SBCs on the media path are also capable of dealing with the "lost BYE" issue if either endpoint dies in the middle of the session. The SBC can detect that the media has stopped flowing and issue a BYE to both sides to clean up any state in other intermediate elements and the endpoints.
SBC在媒体路径上也能够处理“丢失的再见”问题，如果任一端点在会话中间死亡。SBC可以检测到媒体已停止流动，并向双方发出BYE，以清除其他中间元素和端点中的任何状态。
One possible form of media traffic management is that SBCs terminate media streams and SIP dialogs by generating BYE requests. This kind of procedure can take place, for example, in a situation where the
媒体流量管理的一种可能形式是SBC通过生成BYE请求来终止媒体流和SIP对话。例如，在以下情况下，可以执行此类程序：
subscriber runs out of credits. Media management is needed to ensure that the subscriber cannot just ignore the BYE request generated by the SBC and continue its media sessions.
订户的信用额度用完了。需要进行媒体管理，以确保订户不能忽略SBC生成的BYE请求并继续其媒体会话。
Implementing traffic management in this manner requires the SBC to access and modify the session descriptions (i.e., offers and answers) exchanged between the user agents. Consequently, this approach does not work if user agents encrypt or integrity-protect their message bodies end-to-end. Again, messages are modified without subscriber consent, and user agents do not have any way to distinguish the SBC actions from an attack by a MITM. Furthermore, this is in violation of Authenticated Identity Management [4], see Section 3.1.2.
以这种方式实现流量管理要求SBC访问和修改用户代理之间交换的会话描述（即，提供和应答）。因此，如果用户代理端到端加密或完整性保护其消息体，则此方法不起作用。同样，在未经订户同意的情况下修改消息，并且用户代理无法将SBC操作与MITM的攻击区分开来。此外，这违反了认证身份管理[4]，见第3.1.2节。
The insertion of a media relay can prevent "non-media" uses of the media path, for example, the media path key agreement. Sometimes this type of prevention is intentional, but it is not always necessary. For example, if an SBC is used just for enabling media monitoring, but not for interception.
插入媒体中继可以防止“非媒体”使用媒体路径，例如，媒体路径密钥协议。有时这种预防是有意的，但并不总是必要的。例如，如果SBC仅用于启用媒体监视，而不用于拦截。
There are some possible issues related to the media relaying. If the media relaying is not done in the correct manner, it may break functions like Explicit Congestion Notification (ECN) and Path MTU Discovery (PMTUD), for example. The media relays easily break such IP and transport layer functionalities that rely on the correct handling of the protocol fields. Some especially sensitive fields are, for example, ECN and Type of Service (ToS) fields and the Don't Fragment (DF) bit.
有一些可能的问题与媒体转播有关。例如，如果媒体中继没有以正确的方式完成，可能会中断显式拥塞通知（ECN）和路径MTU发现（PMTUD）等功能。媒体中继容易破坏依赖于协议字段正确处理的IP和传输层功能。一些特别敏感的字段是，例如，ECN和服务类型（ToS）字段以及不分段（DF）位。
The way in which media traffic management functions impedes innovation. The reason for the impediment is that in many cases, SBCs need to be able to support new forms of communication (e.g., extensions to the SDP protocol) before new services can be put into use, which slows the adoption of new innovations.
媒体流量管理功能的方式阻碍了创新。造成障碍的原因是，在许多情况下，SBC需要能够在新服务投入使用之前支持新的通信形式（例如SDP协议的扩展），这会减缓新创新的采用。
If an SBC directs many media streams through a central point in the network, it is likely to cause a significant amount of additional traffic to a path to that central point. This might create possible bottleneck in the path.
如果SBC引导多个媒体流通过网络中的中心点，则很可能会导致大量额外流量到达该中心点的路径。这可能会在路径中造成瓶颈。
In this application, the SBC may originate messages that the user may not be able to authenticate as coming from the dialog peer or the SIP Registrar/Proxy.
在该应用中，SBC可以发起来自对话对等方或SIP注册器/代理的用户可能无法认证的消息。
Traffic management may be performed in the following way: The SBC behaves as a B2BUA and inserts itself, or some other entity under the operator's control, in the media path. In practice, the SBC modifies the session descriptions carried in the SIP messages. As a result, the SBC receives media from one user agent and relays it to the other user agent and performs the identical operation with media traveling in the reverse direction.
流量管理可通过以下方式执行：SBC作为B2BUA，在媒体路径中插入自身或运营商控制下的其他实体。实际上，SBC修改SIP消息中携带的会话描述。结果，SBC从一个用户代理接收媒体，并将其中继到另一个用户代理，并对反向移动的媒体执行相同的操作。
As mentioned in Section 3.2.1, codec restriction is a form of traffic management. The SBC restricts the codec set negotiated in the offer/ answer exchange [5] between the user agents. After modifying the session descriptions, the SBC can check whether or not the media stream corresponds to what was negotiated in the offer/answer exchange. If it differs, the SBC has the ability to terminate the media stream or take other appropriate (configured) actions (e.g., raise an alarm).
如第3.2.1节所述，编解码器限制是流量管理的一种形式。SBC限制在用户代理之间的提供/应答交换[5]中协商的编解码器集。修改会话描述后，SBC可以检查媒体流是否对应于在提供/应答交换中协商的内容。如果不同，SBC能够终止媒体流或采取其他适当（配置）措施（例如，发出警报）。
Consider the following example scenario: the SBC receives an INVITE request from the outer network, which in this case is an access network. The received SIP message contains the SDP session descriptor shown in Figure 6.
考虑下面的示例场景：SBC从外部网络接收邀请请求，在这种情况下，该请求是接入网络。收到的SIP消息包含SDP会话描述符，如图6所示。
v=0
o=owner 2890844526 2890842807 IN IP4 192.0.2.4
c=IN IP4 192.0.2.4
m=audio 49230 RTP/AVP 96 98
a=rtpmap:96 L8/8000
a=rtpmap:98 L16/16000/2
v=0
o=owner 2890844526 2890842807 IN IP4 192.0.2.4
c=IN IP4 192.0.2.4
m=audio 49230 RTP/AVP 96 98
a=rtpmap:96 L8/8000
a=rtpmap:98 L16/16000/2
Figure 6: Request Prior to Media Management
图6：媒体管理前的请求
In this example, the SBC performs the media traffic management function by rewriting the "m=" line, and removing one "a=" line according to some (external) policy. Figure 7 shows the session description after the traffic management function.
在此示例中，SBC通过重写“m=”行并根据某些（外部）策略删除一条“a=”行来执行媒体流量管理功能。图7显示了流量管理功能之后的会话描述。
v=0
o=owner 2890844526 2890842807 IN IP4 192.0.2.4
c=IN IP4 192.0.2.4
m=audio 49230 RTP/AVP 96
a=rtpmap:96 L8/8000
v=0
o=owner 2890844526 2890842807 IN IP4 192.0.2.4
c=IN IP4 192.0.2.4
m=audio 49230 RTP/AVP 96
a=rtpmap:96 L8/8000
Figure 7: Request Body After Media Management
图7：媒体管理后的请求主体
Media traffic management has a problem where the SBC needs to understand the session description protocol and all extensions used by the user agents. This means that in order to use a new extension (e.g., an extension to implement a new service) or a new session description protocol, SBCs in the network may need to be upgraded in conjunction with the endpoints. It is noteworthy that a similar problem, but with header fields, applies to, for example, topology hiding function, see Section 3.1. Certain extensions that do not require active manipulation of the session descriptors to facilitate traffic management will be able to be deployed without upgrading existing SBCs, depending on the degree of transparency the SBC implementation affords. In cases requiring an SBC modification to support the new protocol features, the rate of service deployment may be affected.
媒体流量管理存在一个问题，SBC需要了解会话描述协议和用户代理使用的所有扩展。这意味着为了使用新的扩展（例如，实现新服务的扩展）或新的会话描述协议，网络中的sbc可能需要与端点一起升级。值得注意的是，类似的问题，但与标题字段，适用于，例如，拓扑隐藏功能，见第3.1节。某些不需要主动操纵会话描述符以促进流量管理的扩展将能够在不升级现有SBC的情况下部署，具体取决于SBC实现提供的透明度。在需要修改SBC以支持新协议功能的情况下，服务部署速率可能会受到影响。
SBCs fixing capability mismatches enable communications between user agents with different capabilities or extensions. For example, an SBC can enable a plain SIP [1] user agent to connect to a 3GPP network, or enable a connection between user agents that support different IP versions, different codecs, or that are in different address realms. Operators have a requirement and a strong motivation for performing capability mismatch fixing, so that they can provide transparent communication across different domains. In some cases, different SIP extensions or methods to implement the same SIP application (like monitoring session liveness, call history/diversion etc.) may also be interworked through the SBC.
SBC修复功能不匹配可以实现具有不同功能或扩展的用户代理之间的通信。例如，SBC可以使普通SIP[1]用户代理能够连接到3GPP网络，或者使支持不同IP版本、不同编解码器或位于不同地址域的用户代理之间能够连接。运营商有执行功能不匹配修复的需求和强烈动机，因此他们可以提供跨不同域的透明通信。在某些情况下，用于实现同一SIP应用的不同SIP扩展或方法（如监视会话活跃度、呼叫历史记录/转移等）也可以通过SBC进行互通。
SBCs that are fixing capability mismatches do it by inserting a media element into the media path using the procedures described in Section 3.2. Therefore, these SBCs have the same concerns as SBCs performing traffic management: the SBC may modify SIP messages without consent from any of the user agents. This may break end-to-end security and application extensions negotiation.
正在修复功能不匹配的SBC通过使用第3.2节中描述的程序将媒体元素插入媒体路径来完成此操作。因此，这些SBC与执行流量管理的SBC具有相同的关注点：SBC可以在未经任何用户代理同意的情况下修改SIP消息。这可能会破坏端到端的安全性和应用程序扩展协商。
The capability mismatch fixing is a fragile function in the long term. The number of incompatibilities built into various network elements is increasing the fragility and complexity over time. This might lead to a situation where SBCs need to be able to handle a large number of capability mismatches in parallel.
从长远来看，能力不匹配修复是一项脆弱的功能。随着时间的推移，各种网络元素中存在的不兼容的数量正在增加其脆弱性和复杂性。这可能导致SBC需要能够并行处理大量能力不匹配的情况。
Consider the following example scenario where the inner network is an access network using IPv4 and the outer network is using IPv6. The SBC receives an INVITE request with a session description from the access network:
考虑下面的示例场景，其中内部网络是使用IPv4的接入网络，外部网络使用IPv6。SBC从接入网络接收具有会话描述的INVITE请求：
INVITE sip:callee@ipv6.domain.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4
Contact: sip:caller@u1.example.com
INVITE sip:callee@ipv6.domain.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4
Contact: sip:caller@u1.example.com
v=0
o=owner 2890844526 2890842807 IN IP4 192.0.2.4
c=IN IP4 192.0.2.4
m=audio 49230 RTP/AVP 96
a=rtpmap:96 L8/8000
v=0
o=owner 2890844526 2890842807 IN IP4 192.0.2.4
c=IN IP4 192.0.2.4
m=audio 49230 RTP/AVP 96
a=rtpmap:96 L8/8000
Figure 8: Request Prior to Capabilities Match
图8：功能匹配前的请求
Then, the SBC performs a capability mismatch fixing function. In this scenario, the SBC inserts Record-Route and Via headers and rewrites the "c=" line from the sessions descriptor. Figure 9 shows the request after the capability mismatch adjustment.
然后，SBC执行能力不匹配修复功能。在此场景中，SBC插入记录路由和Via头，并从会话描述符重写“c=”行。图9显示了功能不匹配调整后的请求。
INVITE sip:callee@ipv6.domain.com SIP/2.0
Record-Route: <sip:[2001:DB8::801:201:2ff:fe94:8e10];lr>
Via: SIP/2.0/UDP sip:[2001:DB8::801:201:2ff:fe94:8e10]
Via: SIP/2.0/UDP 192.0.2.4
Contact: sip:caller@u1.example.com
INVITE sip:callee@ipv6.domain.com SIP/2.0
Record-Route: <sip:[2001:DB8::801:201:2ff:fe94:8e10];lr>
Via: SIP/2.0/UDP sip:[2001:DB8::801:201:2ff:fe94:8e10]
Via: SIP/2.0/UDP 192.0.2.4
Contact: sip:caller@u1.example.com
v=0
o=owner 2890844526 2890842807 IN IP4 192.0.2.4
c=IN IP6 2001:DB8::801:201:2ff:fe94:8e10
m=audio 49230 RTP/AVP 96
a=rtpmap:96 L8/8000
v=0
o=owner 2890844526 2890842807 IN IP4 192.0.2.4
c=IN IP6 2001:DB8::801:201:2ff:fe94:8e10
m=audio 49230 RTP/AVP 96
a=rtpmap:96 L8/8000
Figure 9: Request after Capability Match
图9：能力匹配后的请求
This message is then sent by the SBC to the onward IPv6 network.
然后，SBC将此消息发送到转发IPv6网络。
NAT traversal in this instance refers to the specific message modifications required to assist a user agent in maintaining SIP and media connectivity when there is a NAT device located between a user agent and a proxy/registrar and, possibly, any other user agent. The
在该实例中，NAT遍历是指当存在位于用户代理和代理/注册器以及可能的任何其他用户代理之间的NAT设备时，帮助用户代理维护SIP和媒体连接所需的特定消息修改。这个
primary purpose of NAT traversal function is to keep up a control connection to user agents behind NATs. This can, for example, be achieved by generating periodic network traffic that keeps bindings in NATs alive. SBCs' NAT traversal function is required in scenarios where the NAT is outside the SBC (i.e., not in cases where SBC itself acts as a NAT).
NAT遍历功能的主要目的是保持与NAT后面的用户代理的控制连接。例如，可以通过生成使NAT中的绑定保持活动状态的周期性网络流量来实现。在NAT位于SBC之外的情况下（即SBC本身充当NAT的情况下），需要SBCs的NAT遍历功能。
An SBC performing a NAT (Network Address Translator) traversal function for a user agent behind a NAT sits between the user agent and the registrar of the domain. NATs are widely deployed in various access networks today, so operators have a requirement to support it. When the registrar receives a REGISTER request from the user agent and responds with a 200 (OK) response, the SBC modifies such a response decreasing the validity of the registration (i.e., the registration expires sooner). This forces the user agent to send a new REGISTER to refresh the registration sooner that it would have done on receiving the original response from the registrar. The REGISTER requests sent by the user agent refresh the binding of the NAT before the binding expires.
为NAT后面的用户代理执行NAT（网络地址转换器）遍历功能的SBC位于用户代理和域的注册器之间。NAT如今广泛部署在各种接入网络中，因此运营商需要支持NAT。当注册器接收到来自用户代理的注册请求并以200（OK）响应作出响应时，SBC修改这样的响应以降低注册的有效性（即，注册提前到期）。这迫使用户代理发送一个新的注册，以便在收到注册器的原始响应时更快地刷新注册。用户代理发送的注册请求在绑定到期之前刷新NAT的绑定。
Note that the SBC does not need to relay all the REGISTER requests received from the user agent to the registrar. The SBC can generate responses to REGISTER requests received before the registration is about to expire at the registrar. Moreover, the SBC needs to deregister the user agent if this fails to refresh its registration in time, even if the registration at the registrar would still be valid.
注意，SBC不需要将从用户代理接收到的所有注册请求中继到注册器。SBC可以在注册即将在注册处过期之前生成对注册请求的响应。此外，如果用户代理未能及时刷新其注册，SBC需要注销该用户代理，即使注册处的注册仍然有效。
SBCs can also force traffic to go through a media relay for NAT traversal purposes (more about media traffic management in Section 3.2). A typical call has media streams to two directions. Even though SBCs can force media streams from both directions to go through a media relay, in some cases, it is enough to relay only the media from one direction (e.g., in a scenario where only the other endpoint is behind a NAT).
出于NAT穿越的目的，SBCs还可以强制流量通过媒体中继（关于媒体流量管理的更多信息，请参见第3.2节）。典型的呼叫有两个方向的媒体流。尽管SBC可以强制来自两个方向的媒体流通过媒体中继，但在某些情况下，仅中继来自一个方向的媒体就足够了（例如，在只有另一个端点位于NAT后面的情况下）。
This approach to NAT traversal does not work if end-to-end confidentiality or integrity-protection mechanisms are used (e.g., Secure/Multipurpose Internet Mail Extensions (S/MIME)). The SBC would be seen as a MITM modifying the messages between the user agent and the registrar.
如果使用端到端机密性或完整性保护机制（例如，安全/多用途Internet邮件扩展（S/MIME）），则NAT遍历的这种方法不起作用。SBC将被视为修改用户代理和注册器之间消息的MITM。
There is also a problem related to the method of how SBCs choose the value for the validity of a registration period. This value should be as high as possible, but it still needs to be low enough to maintain the NAT binding. Some SBCs do not have any deterministic
还有一个问题与SBC如何选择注册有效期值的方法有关。该值应尽可能高，但仍需要足够低才能保持NAT绑定。一些SBC没有任何确定的属性
method for choosing a suitable value. However, SBCs can just use a sub-optimal, relatively small value that usually works. An example from such value is 15 seconds (see [9]).
选择合适值的方法。然而，SBC只能使用一个通常有效的次优、相对较小的值。该值的示例为15秒（见[9]）。
NAT traversal for media using SBCs poses few issues as well. For example, an SBC normally guesses the recipient's public IP address on one of the media streams relayed by the SBC by snooping on the source IP address of another media stream relayed by the same SBC. This causes security and interoperability issues since the SBC can end up associating wrong destination IP addresses on media streams it is relaying. For example, an attacker may snoop on the local IP address and ports used by the SBC for media relaying the streams and send a few packets from a malicious IP address to these destinations. In most cases, this can cause media streams in the opposite directions to divert traffic to the attacker resulting in a successful MITM or DoS attack. A similar example of an interoperability issue is caused when an endpoint behind a NAT attempts to switch the IP address of the media streams by using a re-INVITE. If any media packets are re-ordered or delayed in the network, they can cause the SBC to block the switch from happening even if the re-INVITE successfully goes through.
使用SBCs的媒体NAT遍历也带来了一些问题。例如，SBC通常通过窥探由同一SBC中继的另一媒体流的源IP地址来猜测由SBC中继的其中一个媒体流上的接收方的公共IP地址。这会导致安全性和互操作性问题，因为SBC最终可能会在其中继的媒体流上关联错误的目标IP地址。例如，攻击者可能窥探SBC用于媒体中继流的本地IP地址和端口，并从恶意IP地址向这些目的地发送一些数据包。在大多数情况下，这会导致相反方向的媒体流将流量转移给攻击者，从而导致成功的MITM或DoS攻击。当NAT后面的端点尝试使用重新邀请来切换媒体流的IP地址时，会导致互操作性问题的类似示例。如果任何媒体数据包在网络中被重新排序或延迟，即使重新邀请成功通过，它们也会导致SBC阻止交换机的发生。
Consider the following example scenario: The SBC resides between the UA and Registrar. Previously, the UA has sent a REGISTER request to the Registrar, and the SBC receives the registration response shown in Figure 10.
考虑下面的示例场景：SBC驻留在UA和注册中心之间。在此之前，UA向注册官发送了注册请求，SBC收到注册响应，如图10所示。
SIP/2.0 200 OK
From: Bob <sip:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sip:bob@biloxi.example.com>;tag=34095828jh
CSeq: 1 REGISTER
Contact: <sips:bob@client.biloxi.example.com>;expires=3600
SIP/2.0 200 OK
From: Bob <sip:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sip:bob@biloxi.example.com>;tag=34095828jh
CSeq: 1 REGISTER
Contact: <sips:bob@client.biloxi.example.com>;expires=3600
Figure 10: Response Prior to NAT Maintenance Function
图10:NAT维护功能之前的响应
When performing the NAT traversal function, the SBC may rewrite the expiry time to coax the UA to re-register prior to the intermediating NAT deciding to close the pinhole. Figure 11 shows a possible modification of the response from Figure 10.
当执行NAT遍历功能时，SBC可以重写到期时间，以在中间NAT决定关闭针孔之前诱使UA重新注册。图11显示了对图10响应的可能修改。
SIP/2.0 200 OK
From: Bob <sip:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sip:bob@biloxi.example.com>;tag=34095828jh
CSeq: 1 REGISTER
Contact: <sips:bob@client.biloxi.example.com>;expires=60
SIP/2.0 200 OK
From: Bob <sip:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sip:bob@biloxi.example.com>;tag=34095828jh
CSeq: 1 REGISTER
Contact: <sips:bob@client.biloxi.example.com>;expires=60
Figure 11: Manipulated Response for NAT Traversal
图11:NAT遍历的操纵响应
Naturally, other measures could be taken in order to enable the NAT traversal (e.g., non-SIP keepalive messages), but this example illustrates only one mechanism for preserving the SIP-related NAT bindings.
当然，可以采取其他措施来启用NAT遍历（例如，非SIP keepalive消息），但该示例仅说明了一种用于保留SIP相关NAT绑定的机制。
Network operators may wish to control what kind of signaling and media traffic their network carries. There is strong motivation and a requirement to do access control on the edge of an operator's network. Access control can be based on, for example, link-layer identifiers, IP addresses or SIP identities.
网络运营商可能希望控制其网络承载何种信令和媒体流量。在运营商的网络边缘进行访问控制有着强烈的动机和要求。访问控制可以基于例如链路层标识符、IP地址或SIP身份。
This function can be implemented by protecting the inner network with firewalls and configuring them so that they only accept SIP traffic from the SBC. This way, all the SIP traffic entering the inner network needs to be routed though the SBC, which only routes messages from authorized parties or traffic that meets a specific policy that is expressed in the SBC administratively.
此功能可以通过使用防火墙保护内部网络并对其进行配置，使其仅接受来自SBC的SIP流量来实现。这样，所有进入内部网络的SIP流量都需要通过SBC进行路由，SBC只路由来自授权方的消息或符合SBC中以管理方式表示的特定策略的流量。
Access control can be applied to either only the signaling or both the signaling and media. If it is applied only to the signaling, then the SBC might behave as a proxy server. If access control is applied to both the signaling and media, then the SBC behaves in a similar manner as explained in Section 3.2. A key part of media-layer access control is that only media for authorized sessions is allowed to pass through the SBC and/or associated media relay devices.
访问控制可以仅应用于信令，也可以同时应用于信令和媒体。如果它仅应用于信令，那么SBC可能会充当代理服务器。如果访问控制同时应用于信令和媒体，则SBC的行为方式与第3.2节中解释的类似。媒体层访问控制的一个关键部分是，仅允许授权会话的媒体通过SBC和/或相关媒体中继设备。
Operators implement some functionalities, like NAT traversal for example, in an SBC instead of other elements in the inner network for several reasons: (i) preventing packets from unregistered users to prevent chances of DoS attack, (ii) prioritization and/or re-routing of traffic (based on user or service, like E911) as it enters the network, and (iii) performing a load balancing function or reducing the load on other network equipment.
运营商在SBC中实施一些功能，例如NAT穿越，而不是内部网络中的其他元素，原因如下：（i）防止来自未注册用户的数据包，以防止DoS攻击的机会，（ii）流量进入网络时的优先级和/或重新路由（基于用户或服务，如E911），以及（iii）执行负载平衡功能或减少其他网络设备上的负载。
In environments where there is limited bandwidth on the access links, the SBC can compute the potential bandwidth use by examining the codecs present in SDP offers and answers. With this information, the SBC can reject sessions before the available bandwidth is exhausted to allow existing sessions to maintain acceptable quality of service. Otherwise, the link could become over-subscribed and all sessions would experience a deterioration in quality of service. SBCs may contact a policy server to determine whether sufficient bandwidth is available on a per-session basis.
在接入链路带宽有限的环境中，SBC可以通过检查SDP报价和应答中的编解码器来计算潜在的带宽使用。利用此信息，SBC可以在可用带宽耗尽之前拒绝会话，以允许现有会话保持可接受的服务质量。否则，链接可能会被过度订阅，所有会话的服务质量都会下降。SBC可以联系策略服务器，以确定每个会话是否有足够的带宽可用。
Since the SBC needs to handle all SIP messages, this function has scalability implications. In addition, the SBC is a single point of failure from an architectural point of view. Although, in practice, many current SBCs have the capability to support redundant configuration, which prevents the loss of calls and/or sessions in the event of a failure on a single node.
由于SBC需要处理所有SIP消息，因此此函数具有可伸缩性含义。此外，从体系结构的角度来看，SBC是单点故障。尽管在实践中，许多现有SBC具有支持冗余配置的能力，这可以防止在单个节点发生故障时丢失呼叫和/或会话。
If access control is performed only on behalf of signaling, then the SBC is compatible with general SIP architectural principles, but if it is performed for signaling and for media, then there are similar problems as described in Section 3.2.2.
如果仅代表信令执行访问控制，则SBC与一般SIP体系结构原则兼容，但如果针对信令和媒体执行访问控制，则存在第3.2.2节所述的类似问题。
Figure 12 shows a callflow where the SBC is providing both signaling and media access control (ACKs omitted for brevity).
图12显示了一个呼叫流，其中SBC同时提供信令和媒体访问控制（为简洁起见，省略了ACK）。
caller SBC callee
| | |
| Identify the caller | |
|<- - - - - - - - - - - >| |
| | |
| INVITE + SDP | |
|----------------------->| |
| [Modify the SDP] |
| | INVITE + modified SDP |
| |----------------------->|
| | |
| | 200 OK + SDP |
| |<-----------------------|
| [Modify the SDP] |
| | |
| 200 OK + modified SDP | |
|<-----------------------| |
| | |
| Media [Media inspection] Media |
|<======================>|<======================>|
| | |
caller SBC callee
| | |
| Identify the caller | |
|<- - - - - - - - - - - >| |
| | |
| INVITE + SDP | |
|----------------------->| |
| [Modify the SDP] |
| | INVITE + modified SDP |
| |----------------------->|
| | |
| | 200 OK + SDP |
| |<-----------------------|
| [Modify the SDP] |
| | |
| 200 OK + modified SDP | |
|<-----------------------| |
| | |
| Media [Media inspection] Media |
|<======================>|<======================>|
| | |
Figure 12: Example Access Callflow
图12：示例访问调用流
In this scenario, the SBC first identifies the caller, so it can determine whether or not to give signaling access to the caller. This might be achieved using information gathered during registration, or by other means. Some SBCs may rely on the proxy to authenticate the user agent placing the call. After identification, the SBC modifies the session descriptors in INVITE and 200 OK messages in a way so that the media is going to flow through the SBC itself. When the media starts flowing, the SBC can inspect whether the callee and caller use the codec(s) upon which they had previously agreed.
在这种情况下，SBC首先识别呼叫者，因此它可以确定是否向呼叫者提供信令访问。这可以通过使用注册期间收集的信息或其他方式实现。一些SBC可能依赖代理来验证发出呼叫的用户代理。识别后，SBC以某种方式修改INVITE和200 OK消息中的会话描述符，以便媒体将流经SBC本身。当媒体开始流动时，SBC可以检查被叫方和呼叫者是否使用他们先前同意的编解码器。
SBCs are also used to repair protocol messages generated by not-fully-standard-compliant or badly implemented clients. Operators may wish to support protocol repair, if they want to support as many clients as possible. It is noteworthy that this function affects only the signaling component of an SBC, and that the protocol repair function is not the same as protocol conversion (i.e., making translation between two completely different protocols).
SBC还用于修复由不完全符合标准或实现不好的客户端生成的协议消息。如果运营商希望支持尽可能多的客户端，他们可能希望支持协议修复。值得注意的是，该功能仅影响SBC的信令组件，并且协议修复功能与协议转换不同（即，在两个完全不同的协议之间进行转换）。
In many cases, doing protocol repair for SIP header fields can be seen as being compatible with SIP architectural principles, and it does not violate the end-to-end model of SIP. The SBC repairing protocol messages behaves as a proxy server that is liberal in what it accepts and strict in what it sends.
在许多情况下，对SIP头字段进行协议修复可以被视为与SIP体系结构原则兼容，并且不会违反SIP的端到端模型。SBC修复协议消息的行为就像一个代理服务器，它接受的内容是自由的，发送的内容是严格的。
However, protocol repair may break security mechanism that do cryptographical computations on SIP header values. Attempting protocol repair for SIP message bodies (SDP) is incompatible with Authenticated Identity Management [4] and end-to-end security mechanisms such as S/MIME.
然而，协议修复可能会破坏对SIP头值进行加密计算的安全机制。尝试对SIP消息体（SDP）进行协议修复与身份验证管理[4]和端到端安全机制（如S/MIME）不兼容。
A similar problem related to increasing complexity, as explained in Section 3.3.2, also affects protocol repair function.
如第3.3.2节所述，与复杂性增加相关的类似问题也会影响协议修复功能。
The SBC can, for example, receive an INVITE message from a relatively new SIP UA as illustrated in Figure 13.
例如，SBC可以从相对较新的SIP UA接收INVITE消息，如图13所示。
INVITE sip:callee@sbchost.example.com
Via: SIP/2.0/UDP u1.example.com:5060;lr
From: Caller <sip:caller@one.example.com>
To: Callee <sip:callee@two.example.com>
Call-ID: 18293281@u1.example.com
CSeq: 1 INVITE
Contact: sip:caller@u1.example.com
INVITE sip:callee@sbchost.example.com
Via: SIP/2.0/UDP u1.example.com:5060;lr
From: Caller <sip:caller@one.example.com>
To: Callee <sip:callee@two.example.com>
Call-ID: 18293281@u1.example.com
CSeq: 1 INVITE
Contact: sip:caller@u1.example.com
Figure 13: Request from a Relatively New Client
图13：来自相对较新客户机的请求
If the SBC does protocol repair, it can rewrite the 'lr' parameter on the Via header field into the form 'lr=true' in order to support some older, badly implemented SIP stacks. It could also remove excess white spaces to make the SIP message more human readable.
如果SBC进行协议修复，它可以将Via header字段上的'lr'参数重写为'lr=true'形式，以支持一些较旧的、实现较差的SIP堆栈。它还可以删除多余的空格，使SIP消息更易于阅读。
SBCs are used to perform media encryption/decryption at the edge of the network. This is the case when media encryption (e.g., Secure Real-time Transport Protocol (SRTP)) is used only on the access network (outer network) side and the media is carried unencrypted in the inner network. Some operators provide the ability to do legal
SBC用于在网络边缘执行媒体加密/解密。当仅在接入网络（外部网络）侧使用媒体加密（例如，安全实时传输协议（SRTP））并且在内部网络中未加密地携带媒体时，就是这种情况。一些运营商提供了执行法律程序的能力
interception while still giving their customers the ability to encrypt media in the access network. One possible way to do this is to perform media encryption function.
拦截，同时仍让客户能够在接入网络中加密媒体。一种可能的方法是执行媒体加密功能。
While performing a media encryption function, SBCs need to be able to inject either themselves, or some other entity to the media path. It must be noted that this kind of behavior is the same as a classical MITM attack. Due to this, the SBCs have the same architectural issues as explained in Section 3.2.
在执行媒体加密功能时，SBC需要能够将自身或其他实体注入媒体路径。必须注意的是，这种行为与经典的MITM攻击相同。因此，SBC具有与第3.2节所述相同的架构问题。
Figure 14 shows an example where the SBC is performing media-encryption-related functions (ACKs omitted for brevity).
图14显示了SBC执行媒体加密相关功能的示例（为简洁起见，省略了ACK）。
caller SBC#1 SBC#2 callee
| | | |
| INVITE + SDP | | |
|------------------->| | |
| [Modify the SDP] | |
| | | |
| | INVITE + mod. SDP | |
| |------------------->| |
| | [Modify the SDP] |
| | | |
| | | INVITE + mod. SDP |
| | |------------------->|
| | | |
| | | 200 OK + SDP |
| | |<-------------------|
| | [Modify the SDP] |
| | | |
| | 200 OK + mod. SDP | |
| |<-------------------| |
| [Modify the SDP] | |
| | | |
| 200 OK + mod. SDP | | |
|<-------------------| | |
| | | |
| Encrypted | Plain | Encrypted |
| media [enc./dec.] media [enc./dec.] media |
|<==================>|<- - - - - - - - ->|<==================>|
| | | |
caller SBC#1 SBC#2 callee
| | | |
| INVITE + SDP | | |
|------------------->| | |
| [Modify the SDP] | |
| | | |
| | INVITE + mod. SDP | |
| |------------------->| |
| | [Modify the SDP] |
| | | |
| | | INVITE + mod. SDP |
| | |------------------->|
| | | |
| | | 200 OK + SDP |
| | |<-------------------|
| | [Modify the SDP] |
| | | |
| | 200 OK + mod. SDP | |
| |<-------------------| |
| [Modify the SDP] | |
| | | |
| 200 OK + mod. SDP | | |
|<-------------------| | |
| | | |
| Encrypted | Plain | Encrypted |
| media [enc./dec.] media [enc./dec.] media |
|<==================>|<- - - - - - - - ->|<==================>|
| | | |
Figure 14: Media Encryption Example
图14：媒体加密示例
First, the UAC sends an INVITE request, and the first SBC modifies the session descriptor in a way that it injects itself to the media path. The same happens in the second SBC. Then, the User Agent Server (UAS) replies with a 200 OK response and the SBCs inject themselves in the returning media path. After signaling, the media starts flowing, and both SBCs perform media encryption and decryption.
首先，UAC发送一个INVITE请求，第一个SBC修改会话描述符，将其自身注入媒体路径。同样的情况也发生在第二个SBC中。然后，用户代理服务器（UAS）回复200 OK响应，SBC将自己注入返回的媒体路径。发送信号后，媒体开始流动，两个SBC执行媒体加密和解密。
Some of the functions listed in this document are more SIP-unfriendly than others. This list of requirements is derived from the functions that break the principles of SIP in one way or another when performed by SBCs that do not have the users' consent. The derived requirements are:
本文档中列出的一些函数比其他函数更不友好。此需求列表源自未经用户同意的SBC执行时以某种方式违反SIP原则的功能。衍生需求为：
Req-1: There should be a SIP-friendly way to hide network topology information. Currently, this is done by stripping and replacing header fields, which is against the principles of SIP on behalf of some header fields (see Section 3.1).
Req-1：应该有一种SIP友好的方法来隐藏网络拓扑信息。目前，这是通过剥离和替换报头字段来实现的，这违反了代表某些报头字段的SIP原则（参见第3.1节）。
Req-2: There should be a SIP-friendly way to direct media traffic through intermediaries. Currently, this is done by modifying session descriptors, which is against the principles of SIP (see Sections 3.2, 3.4, 3.5, and 3.7).
Req-2：应该有一种SIP友好的方式通过中介引导媒体流量。目前，这是通过修改会话描述符来实现的，这违反了SIP的原则（参见第3.2、3.4、3.5和3.7节）。
Req-3: There should be a SIP-friendly way to fix capability mismatches in SIP messages. This requirement is harder to fulfill on complex mismatch cases, like the 3GPP/SIP [1] network mismatch. Currently, this is done by modifying SIP messages, which may violate end-to-end security (see Sections 3.3 and 3.6), on behalf of some header fields.
Req-3：应该有一种SIP友好的方法来修复SIP消息中的功能不匹配。在复杂的不匹配情况下，如3GPP/SIP[1]网络不匹配，很难满足这一要求。目前，这是通过修改SIP消息来完成的，这可能会违反端到端安全性（参见第3.3节和第3.6节），代表一些头字段。
Req-1 and Req-3 do not have an existing, standardized solution today. There is ongoing work in the IETF for addressing Req-2, such as SIP session policies [10], Traversal Using Relays around NAT (TURN) [11], and Interactive Connectivity Establishment (ICE) [12]. Nonetheless, future work is needed in order to develop solutions to these requirements.
Req-1和Req-3目前没有现有的标准化解决方案。IETF中正在进行处理Req-2的工作，例如SIP会话策略[10]，使用NAT（TURN）[11]周围的中继进行遍历，以及交互式连接建立（ICE）[12]。尽管如此，还需要进一步的工作来开发这些需求的解决方案。
Many of the functions this document describes have important security and privacy implications. One major security problem is that many functions implemented by SBCs (e.g., topology hiding and media traffic management) modify SIP messages and their bodies without the user agents' consent. The result is that the user agents may
本文档描述的许多功能都具有重要的安全和隐私含义。一个主要的安全问题是，SBC实现的许多功能（例如拓扑隐藏和媒体流量管理）在未经用户代理同意的情况下修改SIP消息及其主体。结果是用户代理可以
interpret the actions taken by an SBC as a MITM attack. SBCs modify SIP messages because it allows them to, for example, protect elements in the inner network from direct attacks.
将SBC采取的行动解释为MITM攻击。SBC修改SIP消息，因为它允许它们（例如）保护内部网络中的元素免受直接攻击。
SBCs that place themselves (or another entity) on the media path can be used to eavesdrop on conversations. Since, often, user agents cannot distinguish between the actions of an attacker and those of an SBC, users cannot know whether they are being eavesdropped on or if an SBC on the path is performing some other function. SBCs place themselves on the media path because it allows them to, for example, perform legal interception.
将自身（或其他实体）置于媒体路径上的SBC可用于窃听对话。由于用户代理通常无法区分攻击者和SBC的行为，因此用户无法知道他们是否被窃听，或者路径上的SBC是否正在执行其他功能。SBC将自己放在媒体路径上，因为它允许它们执行合法拦截。
On a general level, SBCs prevent the use of end-to-end authentication. This is because SBCs need to be able to perform actions that look like MITM attacks, and in order for user agents to communicate, they must allow those type of attacks. It other words, user agents cannot use end-to-end security. This is especially harmful because other network elements, besides SBCs, are then able to do similar attacks. However, in some cases, user agents can establish encrypted media connections between one another. One example is a scenario where SBC is used for enabling media monitoring but not for interception.
一般来说，SBC阻止使用端到端身份验证。这是因为SBC需要能够执行类似于MITM攻击的操作，并且为了让用户代理通信，它们必须允许这些类型的攻击。换句话说，用户代理不能使用端到端安全性。这尤其有害，因为除了SBC之外，其他网络元素也可以进行类似的攻击。但是，在某些情况下，用户代理可以在彼此之间建立加密的媒体连接。一个例子是SBC用于启用媒体监视但不用于拦截的场景。
An SBC is a single point of failure from the architectural point of view. This makes it an attractive target for DoS attacks. The fact that some functions of SBCs require those SBCs to maintain session-specific information makes the situation even worse. If the SBC crashes (or is brought down by an attacker), ongoing sessions experience undetermined behavior.
从体系结构的角度来看，SBC是单点故障。这使得它成为DoS攻击的诱人目标。SBC的某些功能要求这些SBC维护特定于会话的信息，这一事实使得情况更加糟糕。如果SBC崩溃（或被攻击者击倒），正在进行的会话将经历不确定的行为。
If the IETF decides to develop standard mechanisms to address the requirements presented in Section 4, the security and privacy-related aspects of those mechanisms will, of course, need to be taken into consideration.
如果IETF决定开发标准机制来满足第4节中提出的要求，那么当然需要考虑这些机制的安全和隐私相关方面。
The ad hoc meeting about SBCs, held on November 9, 2004 in Washington DC during the 61st IETF meeting, provided valuable input to this document. The authors would also like to thank Sridhar Ramachandran, Gaurav Kulshreshtha, and Rakendu Devdhar. Reviewers Spencer Dawkins and Francois Audet also deserve special thanks.
2004年11月9日，在第61届IETF会议期间，在华盛顿特区举行了关于SBC的特别会议，为本文件提供了宝贵的投入。作者还要感谢Sridhar Ramachandran、Gaurav Kulshreshtha和Rakendu Devdhar。评论家斯宾塞·道金斯和弗朗索瓦·奥德特也值得特别感谢。
[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] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[2] Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC3323，2002年11月。
[3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
[3] Willis，D.和B.Hoeneisen，“用于注册非相邻联系人的会话启动协议（SIP）扩展头字段”，RFC 3327，2002年12月。
[4] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[4] Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年8月。
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[6] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 10.0.0, March 2010.
[6] 3GPP，“IP多媒体子系统（IMS）；第2阶段”，3GPP TS 23.228 10.0.012010年3月。
[7] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[7] Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[8] Munakata, M., Schubert, S., and T. Ohba, "User-Agent-Driven Privacy Mechanism for SIP", RFC 5767, April 2010.
[8] Munakata，M.，Schubert，S.，和T.Ohba，“SIP的用户代理驱动隐私机制”，RFC 5767，2010年4月。
[9] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[9] Eggert，L.和G.Fairhurst，“应用程序设计者的单播UDP使用指南”，BCP 145，RFC 5405，2008年11月。
[10] Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework for Session Initiation Protocol (SIP) Session Policies", Work in Progress, February 2010.
[10] Hilt，V.，Camarillo，G.，和J.Rosenberg，“会话启动协议（SIP）会话策略框架”，正在进行的工作，2010年2月。
[11] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[11] Mahy，R.，Matthews，P.，和J.Rosenberg，“使用NAT周围的中继进行遍历（TURN）：NAT会话遍历实用程序的中继扩展（STUN）”，RFC 5766，2010年4月。
[12] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, MonthTBD 2010.
[12] Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 5245，MonthTBD 2010。
Authors' Addresses
作者地址
Jani Hautakorpi (editor) Ericsson Hirsalantie 11 Jorvas 02420 Finland
Jani Hautakorpi（编辑）爱立信Hirsalantie 11 Jorvas 02420芬兰
EMail: Jani.Hautakorpi@ericsson.com
EMail: Jani.Hautakorpi@ericsson.com
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Robert F. Penfield Acme Packet 71 Third Avenue Burlington, MA 01803 US
美国马萨诸塞州伯灵顿第三大道71号Robert F.Penfield Acme包01803
EMail: bpenfield@acmepacket.com
EMail: bpenfield@acmepacket.com
Alan Hawrylyshen Skype, Inc. 2055 E. Hamilton Ave San Jose, CA 95125 US
Alan Hawrylyshen Skype，Inc.美国加利福尼亚州圣何塞汉密尔顿大道东2055号，邮编95125
EMail: alan.ietf@polyphase.ca
EMail: alan.ietf@polyphase.ca
Medhavi Bhatia 3CLogic 9700 Great Seneca Hwy. Rockville, MD 20850 US
Medhavi Bhatia 3CLogic 9700大塞内卡公路。美国马里兰州洛克维尔20850
EMail: mbhatia@3clogic.com
EMail: mbhatia@3clogic.com