draft-ietf-sipping-sbc-funcs-09.txt   rfc5853.txt 
SIPPING Working Group J. Hautakorpi, Ed. Internet Engineering Task Force (IETF) J. Hautakorpi, Ed.
Internet-Draft G. Camarillo Request for Comments: 5853 G. Camarillo
Intended status: Informational Ericsson Category: Informational Ericsson
Expires: August 22, 2010 R. Penfield ISSN: 2070-1721 R. Penfield
Acme Packet Acme Packet
A. Hawrylyshen A. Hawrylyshen
Ditech Networks Inc. Skype, Inc.
M. Bhatia M. Bhatia
3CLogic 3CLogic
February 18, 2010 April 2010
Requirements from Session Initiation Protocol (SIP) Session Border Requirements from Session Initiation Protocol (SIP)
Control (SBC) Deployments Session Border Control (SBC) Deployments
draft-ietf-sipping-sbc-funcs-09.txt
Abstract Abstract
This document describes functions implemented in Session Initiation This document describes functions implemented in Session Initiation
Protocol (SIP) intermediaries known as Session Border Controllers Protocol (SIP) intermediaries known as Session Border Controllers
(SBCs). The goal of this document is to describe the commonly (SBCs). The goal of this document is to describe the commonly
provided functions of SBCs. A special focus is given to those provided functions of SBCs. A special focus is given to those
practices that are viewed to be in conflict with SIP architectural practices that are viewed to be in conflict with SIP architectural
principles. This document also explores the underlying requirements principles. This document also explores the underlying requirements
of network operators that have led to the use of these functions and of network operators that have led to the use of these functions and
practices in order to identify protocol requirements and determine practices in order to identify protocol requirements and determine
whether those requirements are satisfied by existing specifications whether those requirements are satisfied by existing specifications
or additional standards work is required. or if additional standards work is required.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document is not an Internet Standards Track specification; it is
http://www.ietf.org/ietf/1id-abstracts.txt. published for informational purposes.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (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.
This Internet-Draft will expire on August 22, 2010. 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.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................4
2. Background on SBCs . . . . . . . . . . . . . . . . . . . . . . 4 2. Background on SBCs ..............................................4
2.1. Peering Scenario . . . . . . . . . . . . . . . . . . . . . 6 2.1. Peering Scenario ...........................................6
2.2. Access Scenario . . . . . . . . . . . . . . . . . . . . . 6 2.2. Access Scenario ............................................6
3. Functions of SBCs . . . . . . . . . . . . . . . . . . . . . . 8 3. Functions of SBCs ...............................................8
3.1. Topology Hiding . . . . . . . . . . . . . . . . . . . . . 8 3.1. Topology Hiding ............................................8
3.1.1. General Information and Requirements . . . . . . . . . 8 3.1.1. General Information and Requirements ................8
3.1.2. Architectural Issues . . . . . . . . . . . . . . . . . 9 3.1.2. Architectural Issues ................................9
3.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.3. Example .............................................9
3.2. Media Traffic Management . . . . . . . . . . . . . . . . . 10 3.2. Media Traffic Management ..................................11
3.2.1. General Information and Requirements . . . . . . . . . 10 3.2.1. General Information and Requirements ...............11
3.2.2. Architectural Issues . . . . . . . . . . . . . . . . . 11 3.2.2. Architectural Issues ...............................12
3.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.3. Example ............................................13
3.3. Fixing Capability Mismatches . . . . . . . . . . . . . . . 13 3.3. Fixing Capability Mismatches ..............................14
3.3.1. General Information and Requirements . . . . . . . . . 13 3.3.1. General Information and Requirements ...............14
3.3.2. Architectural Issues . . . . . . . . . . . . . . . . . 14 3.3.2. Architectural Issues ...............................14
3.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.3. Example ............................................15
3.4. Maintaining SIP-related NAT Bindings . . . . . . . . . . . 15 3.4. Maintaining SIP-Related NAT Bindings ......................15
3.4.1. General Information and Requirements . . . . . . . . . 15 3.4.1. General Information and Requirements ...............15
3.4.2. Architectural Issues . . . . . . . . . . . . . . . . . 16 3.4.2. Architectural Issues ...............................16
3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 16 3.4.3. Example ............................................17
3.5. Access Control . . . . . . . . . . . . . . . . . . . . . . 17 3.5. Access Control ............................................18
3.5.1. General Information and Requirements . . . . . . . . . 17 3.5.1. General Information and Requirements ...............18
3.5.2. Architectural Issues . . . . . . . . . . . . . . . . . 18 3.5.2. Architectural Issues ...............................19
3.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 18 3.5.3. Example ............................................19
3.6. Protocol Repair . . . . . . . . . . . . . . . . . . . . . 19 3.6. Protocol Repair ...........................................20
3.6.1. General Information and Requirements . . . . . . . . . 19 3.6.1. General Information and Requirements ...............20
3.6.2. Architectural Issues . . . . . . . . . . . . . . . . . 20 3.6.2. Architectural Issues ...............................21
3.6.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 20 3.6.3. Examples ...........................................21
3.7. Media Encryption . . . . . . . . . . . . . . . . . . . . . 20 3.7. Media Encryption ..........................................21
3.7.1. General Information and Requirements . . . . . . . . . 20 3.7.1. General Information and Requirements ...............21
3.7.2. Architectural Issues . . . . . . . . . . . . . . . . . 21 3.7.2. Architectural Issues ...............................22
3.7.3. Example . . . . . . . . . . . . . . . . . . . . . . . 21 3.7.3. Example ............................................22
4. Derived Requirements for Future SIP Standardization Work . . . 22 4. Derived Requirements for Future SIP Standardization Work .......23
5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 5. Security Considerations ........................................23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 6. Acknowledgements ...............................................24
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 7. References .....................................................25
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Normative References ......................................25
8.1. Normative References . . . . . . . . . . . . . . . . . . . 24 7.2. Informative References ....................................25
8.2. Informational References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
In the past few years there has been a rapid adoption of the Session In the past few years, there has been a rapid adoption of the Session
Initiation Protocol (SIP) [1] and deployment of SIP-based Initiation Protocol (SIP) [1] and deployment of SIP-based
communications networks. This has often outpaced the development and communications networks. This has often outpaced the development and
implementation of protocol specifications to meet network operator implementation of protocol specifications to meet network operator
requirements. This has led to the development of proprietary requirements. This has led to the development of proprietary
solutions. Often, these proprietary solutions are implemented in solutions. Often, these proprietary solutions are implemented in
network intermediaries known in the marketplace as Session Border network intermediaries known in the marketplace as Session Border
Controllers (SBCs) because they typically are deployed at the border Controllers (SBCs) because they typically are deployed at the border
between two networks. The reason for this is that network policies between two networks. The reason for this is that network policies
are typically enforced at the edge of the network. are typically enforced at the edge of the network.
Even though many SBCs currently behave badly in a sense that they Even though many SBCs currently behave in ways that can break end-to-
break end-to-end security and impact feature negotiations, there is end security and impact feature negotiations, there is clearly a
clearly a market for them. Network operators need many of the market for them. Network operators need many of the features current
features current SBCs provide and often there are no standard SBCs provide, and often there are no standard mechanisms available to
mechanisms available to provide them. provide them.
The purpose of this document is to describe functions implemented in The purpose of this document is to describe functions implemented in
SBCs. A special focus is given to those practices that are SBCs. A special focus is given to those practices that conflict with
conflicting with SIP architectural principles in some way. The SIP architectural principles in some way. The document also explores
document also explores the underlying requirements of network the underlying requirements of network operators that have led to the
operators that have led to the use of these functions and practices use of these functions and practices in order to identify protocol
in order to identify protocol requirements and determine whether requirements and determine whether those requirements are satisfied
those requirements are satisfied by existing specifications or by existing specifications or if additional standards work is
additional standards work is required. required.
2. Background on SBCs 2. Background on SBCs
The term SBC is relatively non-specific, since it is not standardized 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 or defined anywhere. Nodes that may be referred to as SBCs but do
not implement SIP are outside the scope of this document. not implement SIP are outside the scope of this document.
SBCs usually sit between two service provider networks in a peering SBCs usually sit between two service provider networks in a peering
environment, or between an access network and a backbone network to environment, or between an access network and a backbone network to
provide service to residential and/or enterprise customers. They provide service to residential and/or enterprise customers. They
provide a variety of functions to enable or enhance session-based provide a variety of functions to enable or enhance session-based
multi-media services (e.g., Voice over IP). These functions include: multi-media services (e.g., Voice over IP). These functions include:
a) perimeter defense (access control, topology hiding, and denial of a) perimeter defense (access control, topology hiding, and denial-of-
service prevention and detection); b) functionality not available in service prevention and detection); b) functionality not available in
the endpoints (NAT traversal, protocol interworking or repair); and the endpoints (NAT traversal, protocol interworking or repair); and
c) traffic management (media monitoring and QoS). Some of these c) traffic management (media monitoring and Quality of Service
functions may also get integrated into other SIP elements (like pre- (QoS)). Some of these functions may also get integrated into other
paid platforms, 3GPP P-CSCF [6], 3GPP I-CSCF, etc). SIP elements (like pre-paid platforms, Third Generation Partnership
Project (3GPP) Proxy CSCF (P-CSCF) [6], 3GPP I-CSCF, etc.).
SIP-based SBCs typically handle both signaling and media and can SIP-based SBCs typically handle both signaling and media and can
implement behavior which is equivalent to a "privacy service" (as implement behavior that is equivalent to a "privacy service" (as
described in[2]) performing both Header Privacy and Session Privacy). described in [2]) performing both Header Privacy and Session
SBCs often modify certain SIP headers and message bodies that proxies Privacy). SBCs often modify certain SIP headers and message bodies
are not allowed to modify. Consequently, they are, by definition, that proxies are not allowed to modify. Consequently, they are, by
B2BUAs (Back-to-Back User Agents). The transparency of these B2BUAs definition, B2BUAs (Back-to-Back User Agents). The transparency of
varies depending on the functions they perform. For example, some these B2BUAs varies depending on the functions they perform. For
SBCs modify the session description carried in the message and insert example, some SBCs modify the session description carried in the
a Record-Route entry. Other SBCs replace the value of the Contact message and insert a Record-Route entry. Other SBCs replace the
header field with the SBCs address, and generate a new Call-ID and value of the Contact header field with the SBCs' address and generate
new To and From tags. a new Call-ID and new To and From tags.
+-----------------+ +-----------------+
| SBC | | SBC |
[signaling] | +-----------+ | [signaling] | +-----------+ |
<------------|->| signaling |<-|----------> <------------|->| signaling |<-|---------->
outer | +-----------+ | inner outer | +-----------+ | inner
network | | | network network | | | network
| +-----------+ | | +-----------+ |
<------------|->| media |<-|----------> <------------|->| media |<-|---------->
[media] | +-----------+ | [media] | +-----------+ |
+-----------------+ +-----------------+
Figure 1: SBC architecture Figure 1: SBC Architecture
Figure 1 shows the logical architecture of an SBC, which includes a Figure 1 shows the logical architecture of an SBC, which includes a
signaling and a media component. In this document, the terms outer signaling and a media component. In this document, the terms outer
and inner network are used for describing these two networks. An SBC and inner network are used for describing these two networks. An SBC
is logically associated to the inner network, and it typically is logically associated with the inner network, and it typically
provides functions such as controlling and protecting access to the provides functions such as controlling and protecting access to the
inner network from the outer network. The SBC itself is configured inner network from the outer network. The SBC itself is configured
and managed by the organization operating the inner network. and managed by the organization operating the inner network.
In some scenarios SBCs operate with users' (implicit or explicit) In some scenarios, SBCs operate with users' (implicit or explicit)
consent while in others they operate without users' consent (this consent; while in others, they operate without users' consent (this
latter case can potentially cause problems). For example, if an SBC latter case can potentially cause problems). For example, if an SBC
in the same administrative domain as a set of enterprise users in the same administrative domain as a set of enterprise users
performs topology hiding (see Section 3.1), the enterprise users can performs topology hiding (see Section 3.1), the enterprise users can
choose to route their SIP messages through it. If they choose to 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' route through the SBC, then the SBC can be seen as having the users'
implicit consent. Another example is a scenario where a service implicit consent. Another example is a scenario where a service
provider has broken gateways and it deploys an SBC in front of them 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 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 configure the SBC as their gateway and, so, the SBC can be seen as
having the users' implicit consent. having the users' implicit consent.
2.1. Peering Scenario 2.1. Peering Scenario
A typical peering scenario involves two network operators who A typical peering scenario involves two network operators who
exchange traffic with each other. An example peering scenario is exchange traffic with each other. An example peering scenario is
illustrated in Figure 2. An originating gateway (GW-A1) in operator 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 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 network. Then, the SBC forward it to the softswitch (SS-B). The
softswitch responds with a redirect (3xx) message back to the SBC softswitch responds with a redirect (3xx) message back to the SBC
that points to the appropriate terminating gateway (GW-B1) in that points to the appropriate terminating gateway (GW-B1) in
operator B's network. If operator B would not have an SBC, the Operator B's network. If Operator B does not have an SBC, the
redirect message would go to the operator A's originating gateway. redirect message would go to the Operator A's originating gateway.
After receiving the redirect message, the SBC sends the INVITE to the After receiving the redirect message, the SBC sends the INVITE to the
terminating gateway. terminating gateway.
Operator A . Operator B Operator A . Operator B
. .
. 2) INVITE . 2) INVITE
+-----+ . /--------------->+-----+ +-----+ . /--------------->+-----+
|SS-A | . / 3) 3xx (redir.) |SS-B | |SS-A | . / 3) 3xx (redir.) |SS-B |
+-----+ . / /---------------+-----+ +-----+ . / /---------------+-----+
. / / . / /
skipping to change at page 6, line 39 skipping to change at page 6, line 39
. .
+-----+ . +-----+ +-----+ . +-----+
|GW-A2| . |GW-B2| |GW-A2| . |GW-B2|
+-----+ . +-----+ +-----+ . +-----+
Figure 2: Peering with SBC Figure 2: Peering with SBC
From the SBC's perspective the Operator A is the outer network, and 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 Operator B is the inner network. Operator B can use the SBC, for
example, to control access to its network, protect its gateways and example, to control access to its network, protect its gateways and
softswitches from unauthorized use and Denial of Service (DoS) softswitches from unauthorized use and denial-of-service (DoS)
attacks, and monitor the signaling and media traffic. It also attacks, and monitor the signaling and media traffic. It also
simplifies network management by minimizing the number ACL (Access simplifies network management by minimizing the number of ACL (Access
Control List) entries in the gateways. The gateways do not need to Control List) entries in the gateways. The gateways do not need to
be exposed to the peer network, and they can restrict access (both 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 and signaling) to the SBCs. The SBC helps ensure that only
media from sessions the SBC authorizes will reach the gateway. media from sessions the SBC authorizes will reach the gateway.
2.2. Access Scenario 2.2. Access Scenario
In an access scenario, presented in Figure 3, the SBC is placed at In an access scenario, presented in Figure 3, the SBC is placed at
the border between the access network (outer network) and the the border between the access network (outer network) and the
operator's network (inner network) to control access to the operator's network (inner network) to control access to the
skipping to change at page 7, line 27 skipping to change at page 7, line 25
+-----+ \ +-----+ \
\ \
+-----+ \------->+-----+ +-------+ +-----+ \------->+-----+ +-------+
| UA2 |<-------------------->| SBC |<----->| proxy |<-- - | UA2 |<-------------------->| SBC |<----->| proxy |<-- -
+-----+ /--->+-----+ +-------+ +-----+ /--->+-----+ +-------+
/ /
+-----+ +-----+ / +-----+ +-----+ /
| UA3 +---+ NAT |<---/ | UA3 +---+ NAT |<---/
+-----+ +-----+ +-----+ +-----+
Figure 3: Access scenario with SBC Figure 3: Access Scenario with SBC
The SBC may be hosted in the access network (e.g,. this is common 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 when the access network is an enterprise network), or in the operator
network (e.g., this is common when the access network is a network (e.g., this is common when the access network is a
residential or small business network). Despite where the SBC is residential or small business network). Despite where the SBC is
hosted, it is managed by the organization maintaining the operator hosted, it is managed by the organization maintaining the operator
network. network.
Some endpoints may be behind enterprise or residential NATs. In Some endpoints may be behind enterprise or residential NATs. In
cases where the access network is a private network, the SBC is a NAT 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 for all traffic. It is noteworthy that SIP traffic may have to
traverse more that one NAT. The proxy usually does authentication traverse more than one NAT. The proxy usually does authentication
and/or authorization for registrations and outbound calls. The SBC and/or authorization for registrations and outbound calls. The SBC
modifies the REGISTER request so that subsequent requests to the modifies the REGISTER request so that subsequent requests to the
registered address-of-record are routed to the SBC. This is done 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 either with a Path header field [3] or by modifying the Contact to
point at the SBC. point at the SBC.
The scenario presented in this section is a general one, and it The scenario presented in this section is a general one, and it
applies also to other similar settings. One example from a similar applies also to other similar settings. One example from a similar
setting is the one where an access network is the open internet, and setting is the one where an access network is the open internet, and
the operator network is the network of a SIP service provider. the operator network is the network of a SIP service provider.
3. Functions of SBCs 3. Functions of SBCs
This section lists those functions that are used in SBC deployments This section lists those functions that are used in SBC deployments
skipping to change at page 8, line 28 skipping to change at page 8, line 28
relevant header lines from SIP and SDP (Session Description Protocol) relevant header lines from SIP and SDP (Session Description Protocol)
[7] messages are displayed. [7] messages are displayed.
3.1. Topology Hiding 3.1. Topology Hiding
3.1.1. General Information and Requirements 3.1.1. General Information and Requirements
Topology hiding consists of limiting the amount of topology Topology hiding consists of limiting the amount of topology
information given to external parties. Operators have a requirement information given to external parties. Operators have a requirement
for this functionality because they do not want the IP addresses of for this functionality because they do not want the IP addresses of
their equipment (proxies, gateways, application servers, etc) to be their equipment (proxies, gateways, application servers, etc.) to be
exposed to outside parties. This may be because they do not want to exposed to outside parties. This may be because they do not want to
expose their equipment to DoS attacks, they may use other carriers expose their equipment to DoS attacks, they may use other carriers
for certain traffic and do not want their customers to be aware of 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 it, or they may want to hide their internal network architecture from
competitors or partners. In some environments, the operator's competitors or partners. In some environments, the operator's
customers may wish to hide the addresses of their equipment or the customers may wish to hide the addresses of their equipment or the
SIP messages may contain private, non-routable addresses. SIP messages may contain private, non-routable addresses.
The most common form of topology hiding is the application of header The most common form of topology hiding is the application of header
privacy (see Section 5.1 of [2]), which involves stripping Via and privacy (see Section 5.1 of [2]), which involves stripping Via and
Record-Route headers, replacing the Contact header, and even changing Record-Route headers, replacing the Contact header, and even changing
Call-IDs. However, in deployments which use IP addresses instead of Call-IDs. However, in deployments that use IP addresses instead of
domain names in headers that cannot be removed (e.g. From and To 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 headers), the SBC may replace these IP addresses with its own IP
address or domain name. address or domain name.
For a reference, there are also other ways of hiding topology For a reference, there are also other ways of hiding topology
information than inserting an intermediary, like an SBC, to the information than inserting an intermediary, like an SBC, to the
signaling path. One of the ways is the User Agent (UA) driven signaling path. One of the ways is the UA-driven privacy mechanism
privacy mechanism [8], where the UA can facilitate the conceal of [8], where the UA can facilitate the concealment of topology
topology information. information.
3.1.2. Architectural Issues 3.1.2. Architectural Issues
Performing topology hiding as described above by SBCs that do not Performing topology hiding, as described above, by SBCs that do not
have the users' consent presents some issues. This functionality is 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 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 model. The messages are modified without the subscriber's consent
and could potentially modify or remove information about the user's and could potentially modify or remove information about the user's
privacy, security requirements, and higher-layer applications which privacy, security requirements, and higher-layer applications that
are communicated end-to-end using SIP. Neither user agent in an end- 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- to-end call has any way to distinguish the SBC actions from a man-in-
The-Middle (MitM) attack. the-middle (MITM) attack.
Topology hiding function does not work well with Authenticated The topology hiding function does not work well with Authenticated
Identity Management [4] in scenarios where the SBC does not have any Identity Management [4] in scenarios where the SBC does not have any
kind of consent from the users. The Authenticated Identity kind of consent from the users. The Authenticated Identity
Management mechanism is based on a hash value that is calculated from Management mechanism is based on a hash value that is calculated from
parts of From, To, Call-Id, CSeq, Date, and Contact header fields parts of From, To, Call-ID, CSeq, Date, and Contact header fields
plus from the whole message body. If the authentication service is plus from the whole message body. If the authentication service is
not provided by the SBC itself, the modification of the forementioned not provided by the SBC itself, the modification of the
header fields and the message body is in violation of [4]. Some aforementioned header fields and the message body is in violation of
forms of topology hiding are in violation, because they are e.g., [4]. Some forms of topology hiding are in violation, because they
replacing the Contact header of a SIP message. are, e.g., replacing the Contact header of a SIP message.
3.1.3. Example 3.1.3. Example
The current way of implementing topology hiding consists of having an 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 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 topology information (e.g., Via and Record-Route entries) from
outgoing messages. outgoing messages.
Imagine the following example scenario: The SBC Imagine the following example scenario: the SBC
(p4.domain.example.com) receives an INVITE request from the inner (p4.domain.example.com) receives an INVITE request from the inner
network, which in this case is an operator network. The received SIP network, which in this case is an operator network. The received SIP
message is shown in Figure 4. message is shown in Figure 4.
INVITE sip:callee@u2.domain.example.com SIP/2.0 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 p3.middle.example.com;branch=z9hG4bK48jq9w174131.1
Via: SIP/2.0/UDP p2.example.com;branch=z9hG4bK18an6i9234172.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 p1.example.com;branch=z9hG4bK39bn2e5239289.1
Via: SIP/2.0/UDP u1.example.com;branch=z9hG4bK92fj4u7283927.1 Via: SIP/2.0/UDP u1.example.com;branch=z9hG4bK92fj4u7283927.1
Contact: sip:caller@u1.example.com Contact: sip:caller@u1.example.com
Record-Route: <sip:p3.middle.example.com;lr> Record-Route: <sip:p3.middle.example.com;lr>
Record-Route: <sip:p2.example.com;lr> Record-Route: <sip:p2.example.com;lr>
Record-Route: <sip:p1.example.com;lr> Record-Route: <sip:p1.example.com;lr>
Figure 4: INVITE Request Prior to Topology Hiding Figure 4: INVITE Request Prior to Topology Hiding
Then the SBC performs a topology hiding function. In this scenario, Then, the SBC performs a topology hiding function. In this scenario,
the SBC removes and stores all existing Via and Record-Route headers, 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 and then inserts Via and Record-Route header fields with its own SIP
URI. After the topology hiding function, the message could appear as URI. After the topology hiding function, the message could appear as
shown in Figure 5. shown in Figure 5.
INVITE sip:callee@u2.domain.example.com SIP/2.0 INVITE sip:callee@u2.domain.example.com SIP/2.0
Via: SIP/2.0/UDP p4.domain.example.com;branch=z9hG4bK92es3w230129.1 Via: SIP/2.0/UDP p4.domain.example.com;branch=z9hG4bK92es3w230129.1
Contact: sip:caller@u1.example.com Contact: sip:caller@u1.example.com
Record-Route: <sip:p4.domain.example.com;lr> Record-Route: <sip:p4.domain.example.com;lr>
Figure 5: INVITE Request After Topology Hiding Figure 5: INVITE Request after Topology Hiding
Like a regular proxy server that inserts a Record-Route entry, the 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 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 loses state (e.g., SBC restarts for some reason), it may not be able
to route messages properly (note: some SBCs preserve the state to route messages properly (note: some SBCs preserve the state
information also on restart). For example, if the SBC removes "Via" information also on restart). For example, if the SBC removes Via
entries from a request and then restarts, thus losing state, the SBC 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 may not be able to route responses to that request, depending on the
information that was lost when the SBC restarted. information that was lost when the SBC restarted.
This is only one example of topology hiding. Besides topology hiding This is only one example of topology hiding. Besides topology hiding
(i.e., information related to network elements is beeing hidden), (i.e., information related to the network elements is being hidden),
SBCs may also do identity hiding (i.e., information related to SBCs may also do identity hiding (i.e., information related to
identity of subscribers in beeing hidden). While performing identity identity of subscribers is being hidden). While performing identity
hiding, SBCs may modify Contact header field values and other header hiding, SBCs may modify Contact header field values and other header
fields containing identity information. The header fields containing fields containing identity information. The header fields containing
identity information is listed in Section 4.1 of [2]. Since the identity information is listed in Section 4.1 of [2]. Since the
publication of [2], the following header fields containing identity publication of [2], the following header fields containing identity
information have been defined: "P-Asserted-Identity", "Referred-By", information have been defined: "P-Asserted-Identity", "Referred-By",
"Identity", and "Identity-Info". "Identity", and "Identity-Info".
3.2. Media Traffic Management 3.2. Media Traffic Management
3.2.1. General Information and Requirements 3.2.1. General Information and Requirements
Media traffic management is the function of controlling media Media traffic management is the function of controlling media
traffic. Network operators may require this functionality in order traffic. Network operators may require this functionality in order
to control the traffic being carried on their network on behalf of to control the traffic being carried on their network on behalf of
their subscribers. Traffic management helps the creation of their subscribers. Traffic management helps the creation of
different kinds of billing models (e.g., video telephony can be different kinds of billing models (e.g., video telephony can be
priced differently to voice-only calls) and it also makes it possible priced differently than voice-only calls) and it also makes it
for operators to enforce the usage of selected codecs. possible for operators to enforce the usage of selected codecs.
One of the use cases for media traffic management is the One of the use cases for media traffic management is the
implementation of intercept capabilities where required to support implementation of intercept capabilities that are required to support
audit or legal obligations. It is noteworthy that the legal audit or legal obligations. It is noteworthy that the legal
obligations mainly apply to operators providing voice services, and obligations mainly apply to operators providing voice services, and
those operators typically have infrastructure (e.g., SIP proxies those operators typically have infrastructure (e.g., SIP proxies
acting as B2BUAs) for providing intercept capabilities even without acting as B2BUAs) for providing intercept capabilities even without
SBCs. SBCs.
Since the media path is independent of the signaling path, the media Since the media path is independent of the signaling path, the media
may not traverse through the operator's network unless the SBC may not traverse through the operator's network unless the SBC
modifies the session description. By modifying the session modifies the session description. By modifying the session
description the SBC can force the media to be sent through a media 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 relay which may be co-located with the SBC. This kind of traffic
management can be done, for example, to ensure a certain QoS (Quality management can be done, for example, to ensure a certain QoS level,
of Service) level, or to ensure that subscribers are using only or to ensure that subscribers are using only allowed codecs. It is
allowed codecs. It is noteworthy that the SBCs do not have direct noteworthy that the SBCs do not have direct ties to routing topology
ties to routing topology and they do not, for example, change and they do not, for example, change bandwidth reservations on
bandwidth reservations on Traffic Engineering (TE) tunnels, nor they Traffic Engineering (TE) tunnels, nor do they have direct interaction
have direct interaction with routing protocol. with routing protocol.
Some operators do not want to manage the traffic, but only to monitor Some operators do not want to manage the traffic, but only to monitor
it for collecting statistics and making sure that they are able to it to collect statistics and make sure that they are able to meet any
meet any business service level agreements with their subscribers business service level agreements with their subscribers and/or
and/or partners. The protocol techniques, from the SBC's viewpoint, partners. The protocol techniques, from the SBC's viewpoint, needed
needed for monitoring media traffic are the same as for managing for monitoring media traffic are the same as for managing media
media traffic. traffic.
SBCs on the media path are also capable of dealing with the "lost 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 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 SBC can detect that the media has stopped flowing and issue a BYE to
both sides to cleanup any state in other intermediate elements and both sides to clean up any state in other intermediate elements and
the endpoints. the endpoints.
One possible form of media traffic management is that SBCs terminate One possible form of media traffic management is that SBCs terminate
media streams and SIP dialogs by generating BYE requests. This kind media streams and SIP dialogs by generating BYE requests. This kind
of procedure can take place, for example, in a situation where the of procedure can take place, for example, in a situation where the
subscriber runs out of credits. Media management is needed to ensure subscriber runs out of credits. Media management is needed to ensure
that the subscriber cannot just ignore the BYE request generated by that the subscriber cannot just ignore the BYE request generated by
the SBC and continue their media sessions. the SBC and continue its media sessions.
3.2.2. Architectural Issues 3.2.2. Architectural Issues
Implementing traffic management in this manner requires the SBC to Implementing traffic management in this manner requires the SBC to
access and modify the session descriptions (i.e., offers and answers) access and modify the session descriptions (i.e., offers and answers)
exchanged between the user-agents. Consequently, this approach does exchanged between the user agents. Consequently, this approach does
not work if user-agents encrypt or integrity-protect their message not work if user agents encrypt or integrity-protect their message
bodies end-to-end. Again, messages are modified without subscriber bodies end-to-end. Again, messages are modified without subscriber
consent, and user-agents do not have any way to distinguish the SBC 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 actions from an attack by a MITM. Furthermore, this is in violation
of Authenticated Identity Management [4], see Section 3.1.2. of Authenticated Identity Management [4], see Section 3.1.2.
The insertion of a media relay can prevent "non-media" uses of media The insertion of a media relay can prevent "non-media" uses of the
path, for example media path key agreement. Sometimes this type of media path, for example, the media path key agreement. Sometimes
prevention is intentional, but it is not always necessary. For this type of prevention is intentional, but it is not always
example, if an SBC is used just for enabling media monitoring, but necessary. For example, if an SBC is used just for enabling media
not for interception. monitoring, but not for interception.
There are some possible issues related to the media relaying. If the There are some possible issues related to the media relaying. If the
media relaying is not done in a correct manner, it may break media relaying is not done in the correct manner, it may break
functions like Explicit Congestion Notification (ECN) and Path MTU functions like Explicit Congestion Notification (ECN) and Path MTU
Discovery (PMTUD), for example. The media relays easily break such Discovery (PMTUD), for example. The media relays easily break such
IP and transport layer functionalities that rely on the correct IP and transport layer functionalities that rely on the correct
handling of the protocol fields. Some especially sensitive field handling of the protocol fields. Some especially sensitive fields
are, for example, ECN and Type of Service (TOS) fields, and Don't are, for example, ECN and Type of Service (ToS) fields and the Don't
Fragment (DF) bit. Fragment (DF) bit.
Media traffic management function also hinders innovations. The The way in which media traffic management functions impedes
reason for the hinderance is that in many cases SBCs need to be able innovation. The reason for the impediment is that in many cases,
to support new ways of communicating (e.g., extensions to the SDP SBCs need to be able to support new forms of communication (e.g.,
protocol) before new services can be taken into use, and that slows extensions to the SDP protocol) before new services can be put into
down the adoption of innovations. use, which slows the adoption of new innovations.
If an SBC directs many media streams through a central point in the If an SBC directs many media streams through a central point in the
network, it is likely to cause a significant amount of additional network, it is likely to cause a significant amount of additional
traffic to a path to that central point. This might create possible traffic to a path to that central point. This might create possible
bottleneck in the path. bottleneck in the path.
In this application, the SBC may originate messages that the user may 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 not be able to authenticate as coming from the dialog peer or the SIP
Registrar/Proxy. Registrar/Proxy.
3.2.3. Example 3.2.3. Example
Traffic management may be performed in the following way: The SBC Traffic management may be performed in the following way: The SBC
behaves as a B2BUA and inserts itself, or some other entity under the 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 operator's control, in the media path. In practice, the SBC modifies
the session descriptions carried in the SIP messages. As a result, 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 the SBC receives media from one user agent and relays it to the other
user-agent and performs the identical operation with media traveling user agent and performs the identical operation with media traveling
in the reverse direction. in the reverse direction.
As mentioned in Section 3.2.1, codec restriction is a form of traffic 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/ management. The SBC restricts the codec set negotiated in the offer/
answer exchange [5] between the user-agents. After modifying the answer exchange [5] between the user agents. After modifying the
session descriptions, the SBC can check whether or not the media session descriptions, the SBC can check whether or not the media
stream corresponds to what was negotiated in the offer/answer stream corresponds to what was negotiated in the offer/answer
exchange. If it differs, the SBC has the ability to terminate the exchange. If it differs, the SBC has the ability to terminate the
media stream or take other appropriate (configured) actions (e.g. media stream or take other appropriate (configured) actions (e.g.,
raise an alarm). raise an alarm).
Consider the following example scenario: The SBC receives an INVITE Consider the following example scenario: the SBC receives an INVITE
request from the outer network, which in this case is an access request from the outer network, which in this case is an access
network. The received SIP message contains the SDP session network. The received SIP message contains the SDP session
descriptor shown in Figure 6. descriptor shown in Figure 6.
v=0 v=0
o=owner 2890844526 2890842807 IN IP4 192.0.2.4 o=owner 2890844526 2890842807 IN IP4 192.0.2.4
c=IN IP4 192.0.2.4 c=IN IP4 192.0.2.4
m=audio 49230 RTP/AVP 96 98 m=audio 49230 RTP/AVP 96 98
a=rtpmap:96 L8/8000 a=rtpmap:96 L8/8000
a=rtpmap:98 L16/16000/2 a=rtpmap:98 L16/16000/2
Figure 6: Request Prior to Media Management Figure 6: Request Prior to Media Management
In this example, the SBC performs the media traffic management In this example, the SBC performs the media traffic management
function by rewriting the 'm' line, and removing one 'a' line function by rewriting the "m=" line, and removing one "a=" line
according to some (external) policy. Figure 7 shows the session according to some (external) policy. Figure 7 shows the session
description after the traffic management function. description after the traffic management function.
v=0 v=0
o=owner 2890844526 2890842807 IN IP4 192.0.2.4 o=owner 2890844526 2890842807 IN IP4 192.0.2.4
c=IN IP4 192.0.2.4 c=IN IP4 192.0.2.4
m=audio 49230 RTP/AVP 96 m=audio 49230 RTP/AVP 96
a=rtpmap:96 L8/8000 a=rtpmap:96 L8/8000
Figure 7: Request Body After Media Management Figure 7: Request Body After Media Management
Media traffic management has a problem where the SBC needs to Media traffic management has a problem where the SBC needs to
understand the session description protocol and all extensions used understand the session description protocol and all extensions used
by the user-agents. This means that in order to use a new extension 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 (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 description protocol, SBCs in the network may need to be upgraded in
conjunction with the endpoints. It is noteworthy that a similar conjunction with the endpoints. It is noteworthy that a similar
problem, but with header fields, applies to, for example, topology problem, but with header fields, applies to, for example, topology
hiding function, see Section 3.1. Certain extensions that do not hiding function, see Section 3.1. Certain extensions that do not
require active manipulation of the session descriptors to facilitate require active manipulation of the session descriptors to facilitate
traffic management will be able to be deployed without upgrading traffic management will be able to be deployed without upgrading
existing SBCs, depending on the degree of transparency the SBC existing SBCs, depending on the degree of transparency the SBC
implementation affords. In cases requiring an SBC modification to implementation affords. In cases requiring an SBC modification to
support the new protocol features, the rate of service deployment may support the new protocol features, the rate of service deployment may
be affected. be affected.
3.3. Fixing Capability Mismatches 3.3. Fixing Capability Mismatches
3.3.1. General Information and Requirements 3.3.1. General Information and Requirements
SBCs fixing capability mismatches enable communications between user- SBCs fixing capability mismatches enable communications between user
agents with different capabilities or extensions. For example, an agents with different capabilities or extensions. For example, an
SBC can enable a plain SIP [1] user agent to connect to a 3GPP SBC can enable a plain SIP [1] user agent to connect to a 3GPP
network, or enable a connection between user agents that support network, or enable a connection between user agents that support
different IP versions, different codecs, or that are in different different IP versions, different codecs, or that are in different
address realms. Operators have a requirement and a strong motivation address realms. Operators have a requirement and a strong motivation
for performing capability mismatch fixing, so that they can provide for performing capability mismatch fixing, so that they can provide
transparent communication across different domains. In some cases transparent communication across different domains. In some cases,
different SIP extensions or methods to implement the same SIP different SIP extensions or methods to implement the same SIP
application (like monitoring session liveness, call history/diversion application (like monitoring session liveness, call history/diversion
etc) may also be interworked through the SBC. etc.) may also be interworked through the SBC.
3.3.2. Architectural Issues 3.3.2. Architectural Issues
SBCs that are fixing capability mismatches do it by insert a media SBCs that are fixing capability mismatches do it by inserting a media
element to the media path using the procedures described in element into the media path using the procedures described in
Section 3.2. Therefore, these SBCs have the same concerns as SBCs Section 3.2. Therefore, these SBCs have the same concerns as SBCs
performing traffic management: the SBC may modify SIP messages performing traffic management: the SBC may modify SIP messages
without consent from any of the user-agents. This may break end-to- without consent from any of the user agents. This may break end-to-
end security and application extensions negotiation. end security and application extensions negotiation.
The capability mismatch fixing is a fragile function in the long The capability mismatch fixing is a fragile function in the long
term. The number of incompatibilities built into various network term. The number of incompatibilities built into various network
elements is increasing the fragility and complexity over time. This elements is increasing the fragility and complexity over time. This
might lead to a situation where SBCs need to be able to handle a might lead to a situation where SBCs need to be able to handle a
large number of capability mismatches in parallel. large number of capability mismatches in parallel.
3.3.3. Example 3.3.3. Example
skipping to change at page 14, line 48 skipping to change at page 15, line 24
Contact: sip:caller@u1.example.com Contact: sip:caller@u1.example.com
v=0 v=0
o=owner 2890844526 2890842807 IN IP4 192.0.2.4 o=owner 2890844526 2890842807 IN IP4 192.0.2.4
c=IN IP4 192.0.2.4 c=IN IP4 192.0.2.4
m=audio 49230 RTP/AVP 96 m=audio 49230 RTP/AVP 96
a=rtpmap:96 L8/8000 a=rtpmap:96 L8/8000
Figure 8: Request Prior to Capabilities Match Figure 8: Request Prior to Capabilities Match
Then the SBC performs a capability mismatch fixing function. In this Then, the SBC performs a capability mismatch fixing function. In
scenario the SBC inserts Record-Route and Via headers, and rewrites this scenario, the SBC inserts Record-Route and Via headers and
the 'c' line from the sessions descriptor. Figure 9 shows the rewrites the "c=" line from the sessions descriptor. Figure 9 shows
request after the capability mismatch adjustment. the request after the capability mismatch adjustment.
INVITE sip:callee@ipv6.domain.com SIP/2.0 INVITE sip:callee@ipv6.domain.com SIP/2.0
Record-Route: <sip:[2001:DB8::801:201:2ff:fe94:8e10];lr> 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 sip:[2001:DB8::801:201:2ff:fe94:8e10]
Via: SIP/2.0/UDP 192.0.2.4 Via: SIP/2.0/UDP 192.0.2.4
Contact: sip:caller@u1.example.com Contact: sip:caller@u1.example.com
v=0 v=0
o=owner 2890844526 2890842807 IN IP4 192.0.2.4 o=owner 2890844526 2890842807 IN IP4 192.0.2.4
c=IN IP6 2001:DB8::801:201:2ff:fe94:8e10 c=IN IP6 2001:DB8::801:201:2ff:fe94:8e10
m=audio 49230 RTP/AVP 96 m=audio 49230 RTP/AVP 96
a=rtpmap:96 L8/8000 a=rtpmap:96 L8/8000
Figure 9: Request After Capability Match Figure 9: Request after Capability Match
This message is then sent by the SBC to the onward IPv6 network. This message is then sent by the SBC to the onward IPv6 network.
3.4. Maintaining SIP-related NAT Bindings 3.4. Maintaining SIP-Related NAT Bindings
3.4.1. General Information and Requirements 3.4.1. General Information and Requirements
NAT traversal in this instance refers to the specific message NAT traversal in this instance refers to the specific message
modifications required to assist a user-agent in maintaining SIP and modifications required to assist a user agent in maintaining SIP and
media connectivity when there is a NAT device located between a user- media connectivity when there is a NAT device located between a user
agent and a proxy/registrar and, possibly, any other user-agent. The agent and a proxy/registrar and, possibly, any other user agent. The
primary purpose of NAT traversal function is to keep up a control primary purpose of NAT traversal function is to keep up a control
connection to user-agents behind NATs. This can, for example, be connection to user agents behind NATs. This can, for example, be
achieved by generating periodic network traffic that keeps bindings achieved by generating periodic network traffic that keeps bindings
in NATs alive. SBCs' NAT traversal function is required in scenarios 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 where the NAT is outside the SBC (i.e., not in cases where SBC itself
acts as a NAT). acts as a NAT).
An SBC performing a NAT (Network Address Translator) traversal An SBC performing a NAT (Network Address Translator) traversal
function for a user agent behind a NAT sits between the user-agent 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 and the registrar of the domain. NATs are widely deployed in various
access networks today, so operators have a requirement to support it. access networks today, so operators have a requirement to support it.
When the registrar receives a REGISTER request from the user-agent When the registrar receives a REGISTER request from the user agent
and responds with a 200 (OK) response, the SBC modifies such a and responds with a 200 (OK) response, the SBC modifies such a
response decreasing the validity of the registration (i.e., the response decreasing the validity of the registration (i.e., the
registration expires sooner). This forces the user-agent to send a registration expires sooner). This forces the user agent to send a
new REGISTER to refresh the registration sooner that it would have new REGISTER to refresh the registration sooner that it would have
done on receiving the original response from the registrar. The done on receiving the original response from the registrar. The
REGISTER requests sent by the user-agent refresh the binding of the REGISTER requests sent by the user agent refresh the binding of the
NAT before the binding expires. NAT before the binding expires.
Note that the SBC does not need to relay all the REGISTER requests 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 received from the user agent to the registrar. The SBC can generate
responses to REGISTER requests received before the registration is responses to REGISTER requests received before the registration is
about to expire at the registrar. Moreover, the SBC needs to about to expire at the registrar. Moreover, the SBC needs to
deregister the user-agent if this fails to refresh its registration deregister the user agent if this fails to refresh its registration
in time, even if the registration at the registrar would still be in time, even if the registration at the registrar would still be
valid. valid.
SBCs can also force traffic to go through a media relay for NAT SBCs can also force traffic to go through a media relay for NAT
traversal purposes (more about media traffic management in traversal purposes (more about media traffic management in
Section 3.2). A typical call has media streams to two directions. Section 3.2). A typical call has media streams to two directions.
Even though SBCs can force media streams from both directions to go 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 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 media from one direction (e.g., in a scenario where only the other
endpoint is behind a NAT). endpoint is behind a NAT).
3.4.2. Architectural Issues 3.4.2. Architectural Issues
This approach to NAT traversal does not work if end-to-end This approach to NAT traversal does not work if end-to-end
confidentiality or integrity-protection mechanisms are used (e.g., confidentiality or integrity-protection mechanisms are used (e.g.,
S/MIME). The SBC would be seen as a MitM modifying the messages Secure/Multipurpose Internet Mail Extensions (S/MIME)). The SBC
between the user-agent and the registrar. would be seen as a MITM modifying the messages between the user agent
and the registrar.
There is also a problem related to the method how SBCs choose the 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 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 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 maintain the NAT binding. Some SBCs do not have any deterministic
method for choosing a suitable value. However, SBCs can just use a method for choosing a suitable value. However, SBCs can just use a
sub-optimal, relatively small value which usually works. An example sub-optimal, relatively small value that usually works. An example
from such value is 15 seconds (see [9]). from such value is 15 seconds (see [9]).
NAT Traversal for media using SBCs poses few issues as well. For NAT traversal for media using SBCs poses few issues as well. For
example an SBC normally guesses the recipient's public IP address on 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 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 IP address of another media stream relayed by the same SBC. This
causes security and interoperability issues since the SBC can end up causes security and interoperability issues since the SBC can end up
associating wrong destination IP addresses on media streams it is associating wrong destination IP addresses on media streams it is
relaying. For example, an attacker may snoop on the local IP address 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 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 few packets from a malicious IP address to these destinations. In
most cases, this can cause media streams in the opposite directions most cases, this can cause media streams in the opposite directions
to divert traffic to the attacker resulting in a successful MitM or to divert traffic to the attacker resulting in a successful MITM or
DoS attack. A similar example of an interop issue is caused when an DoS attack. A similar example of an interoperability issue is caused
endpoint behind a NAT attempts to switch the IP address of the media when an endpoint behind a NAT attempts to switch the IP address of
streams by using a re-INVITE. If any media packets are re-ordered or the media streams by using a re-INVITE. If any media packets are re-
delayed in the network, they can cause the SBC to block the switch ordered or delayed in the network, they can cause the SBC to block
from happening even if the re-INVITE successfully goes through. the switch from happening even if the re-INVITE successfully goes
through.
3.4.3. Example 3.4.3. Example
Consider the following example scenario: The SBC resides between the Consider the following example scenario: The SBC resides between the
UA and Registrar. Previously the UA has sent a REGISTER request to UA and Registrar. Previously, the UA has sent a REGISTER request to
Registrar, and the SBC receives the registration response shown in the Registrar, and the SBC receives the registration response shown
Figure 10. in Figure 10.
SIP/2.0 200 OK SIP/2.0 200 OK
From: Bob <sip:bob@biloxi.example.com>;tag=a73kszlfl From: Bob <sip:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sip:bob@biloxi.example.com>;tag=34095828jh To: Bob <sip:bob@biloxi.example.com>;tag=34095828jh
CSeq: 1 REGISTER CSeq: 1 REGISTER
Contact: <sips:bob@client.biloxi.example.com>;expires=3600 Contact: <sips:bob@client.biloxi.example.com>;expires=3600
Figure 10: Response Prior to NAT Maintenance Function Figure 10: Response Prior to NAT Maintenance Function
When performing the NAT traversal function, the SBC may re-write the When performing the NAT traversal function, the SBC may rewrite the
expiry time to coax the UA to re-register prior to the intermediating expiry time to coax the UA to re-register prior to the intermediating
NAT deciding to close the pinhole. Figure 11 shows a possible NAT deciding to close the pinhole. Figure 11 shows a possible
modification of the response from Figure 10. modification of the response from Figure 10.
SIP/2.0 200 OK SIP/2.0 200 OK
From: Bob <sip:bob@biloxi.example.com>;tag=a73kszlfl From: Bob <sip:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sip:bob@biloxi.example.com>;tag=34095828jh To: Bob <sip:bob@biloxi.example.com>;tag=34095828jh
CSeq: 1 REGISTER CSeq: 1 REGISTER
Contact: <sips:bob@client.biloxi.example.com>;expires=60 Contact: <sips:bob@client.biloxi.example.com>;expires=60
Figure 11: Manipulated Response for NAT Traversal Figure 11: Manipulated Response for NAT Traversal
Naturally also other measures could be taken in order to enable the Naturally, other measures could be taken in order to enable the NAT
NAT traversal (e.g., non-SIP keepalive messages), but this example traversal (e.g., non-SIP keepalive messages), but this example
illustrates only one mechanism for preserving the SIP-related NAT illustrates only one mechanism for preserving the SIP-related NAT
bindings. bindings.
3.5. Access Control 3.5. Access Control
3.5.1. General Information and Requirements 3.5.1. General Information and Requirements
Network operators may wish to control what kind of signaling and Network operators may wish to control what kind of signaling and
media traffic their network carries. There is strong motivation and media traffic their network carries. There is strong motivation and
a requirement to do access control on the edge of an operator's a requirement to do access control on the edge of an operator's
network. Access control can be based on, for example, link-layer network. Access control can be based on, for example, link-layer
identifiers, IP addresses or SIP identities. identifiers, IP addresses or SIP identities.
This function can be implemented by protecting the inner network with This function can be implemented by protecting the inner network with
firewalls and configuring them so that they only accept SIP traffic firewalls and configuring them so that they only accept SIP traffic
from the SBC. This way, all the SIP traffic entering the inner from the SBC. This way, all the SIP traffic entering the inner
network needs to be routed though the SBC, which only routes messages network needs to be routed though the SBC, which only routes messages
from authorized parties or traffic that meets a specific policy that from authorized parties or traffic that meets a specific policy that
is expressed in the SBC administratively. is expressed in the SBC administratively.
Access control can be applied either only to the signaling, or to Access control can be applied to either only the signaling or both
both the signaling and media. If it is applied only to the the signaling and media. If it is applied only to the signaling,
signaling, then the SBC might behave as a proxy server. If access then the SBC might behave as a proxy server. If access control is
control is applied to both the signaling and media, then the SBC applied to both the signaling and media, then the SBC behaves in a
behaves in a similar manner as explained in Section 3.2. A key part similar manner as explained in Section 3.2. A key part of media-
of media-layer access control is that only media for authorized layer access control is that only media for authorized sessions is
sessions is allowed to pass through the SBC and/or associated media allowed to pass through the SBC and/or associated media relay
relay devices. devices.
Operators implement some functionalities, like NAT traversal for Operators implement some functionalities, like NAT traversal for
example, in an SBC instead of other elements in the inner network for example, in an SBC instead of other elements in the inner network for
several reasons: (i) preventing packets from unregistered users to several reasons: (i) preventing packets from unregistered users to
prevent chances of DoS attack, (ii) prioritization and/or re-routing prevent chances of DoS attack, (ii) prioritization and/or re-routing
of traffic (based on user or service, like E911) as it enters the of traffic (based on user or service, like E911) as it enters the
network, and (iii) performing a load balancing function or reducing network, and (iii) performing a load balancing function or reducing
the load on other network equipment. the load on other network equipment.
In environments where there is limited bandwidth on the access links, In environments where there is limited bandwidth on the access links,
the SBC can compute the potential bandwidth usage by examining the the SBC can compute the potential bandwidth use by examining the
codecs present in SDP offers and answers. With this information, the codecs present in SDP offers and answers. With this information, the
SBC can reject sessions before the available bandwidth is exhausted SBC can reject sessions before the available bandwidth is exhausted
to allow existing sessions to maintain acceptable quality of service. to allow existing sessions to maintain acceptable quality of service.
Otherwise, the link could become over-subscribed and all sessions Otherwise, the link could become over-subscribed and all sessions
would experience a deterioration in quality of service. SBCs may would experience a deterioration in quality of service. SBCs may
contact a policy server to determine whether sufficient bandwidth is contact a policy server to determine whether sufficient bandwidth is
available on a per-session basis. available on a per-session basis.
3.5.2. Architectural Issues 3.5.2. Architectural Issues
skipping to change at page 19, line 30 skipping to change at page 20, line 30
| 200 OK + modified SDP | | | 200 OK + modified SDP | |
|<-----------------------| | |<-----------------------| |
| | | | | |
| Media [Media inspection] Media | | Media [Media inspection] Media |
|<======================>|<======================>| |<======================>|<======================>|
| | | | | |
Figure 12: Example Access Callflow Figure 12: Example Access Callflow
In this scenario, the SBC first identifies the caller, so it can In this scenario, the SBC first identifies the caller, so it can
determine whether or not to give signaling access for the caller. determine whether or not to give signaling access to the caller.
This might be achieved using information gathered during This might be achieved using information gathered during
registration, or by other means. Some SBCs may rely on the proxy to registration, or by other means. Some SBCs may rely on the proxy to
authenticate the user-agent placing the call. After identification, authenticate the user agent placing the call. After identification,
the SBC modifies the session descriptors in INVITE and 200 OK 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 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 itself. When the media starts flowing, the SBC can inspect whether
the callee and caller use the codec(s) that they had previously the callee and caller use the codec(s) upon which they had previously
agreed on. agreed.
3.6. Protocol Repair 3.6. Protocol Repair
3.6.1. General Information and Requirements 3.6.1. General Information and Requirements
SBCs are also used to repair protocol messages generated by not- SBCs are also used to repair protocol messages generated by not-
fully-standard compliant or badly implemented clients. Operators may fully-standard-compliant or badly implemented clients. Operators may
wish to support protocol repair, if they want to support as many wish to support protocol repair, if they want to support as many
clients as possible. It is noteworthy, that this function affects clients as possible. It is noteworthy that this function affects
only the signaling component of an SBC, and that the protocol repair only the signaling component of an SBC, and that the protocol repair
function is not the same as protocol conversion (i.e., making function is not the same as protocol conversion (i.e., making
translation between two completely different protocols). translation between two completely different protocols).
3.6.2. Architectural Issues 3.6.2. Architectural Issues
In many cases, doing protocol repair for SIP header fields can be In many cases, doing protocol repair for SIP header fields can be
seen as being compatible with SIP architectural principles, and it seen as being compatible with SIP architectural principles, and it
does not violate the end-to-end model of SIP. The SBC repairing 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 protocol messages behaves as a proxy server that is liberal in what
skipping to change at page 20, line 35 skipping to change at page 21, line 35
new SIP UA as illustrated in Figure 13. new SIP UA as illustrated in Figure 13.
INVITE sip:callee@sbchost.example.com INVITE sip:callee@sbchost.example.com
Via: SIP/2.0/UDP u1.example.com:5060;lr Via: SIP/2.0/UDP u1.example.com:5060;lr
From: Caller <sip:caller@one.example.com> From: Caller <sip:caller@one.example.com>
To: Callee <sip:callee@two.example.com> To: Callee <sip:callee@two.example.com>
Call-ID: 18293281@u1.example.com Call-ID: 18293281@u1.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: sip:caller@u1.example.com Contact: sip:caller@u1.example.com
Figure 13: Request from a relatively new client Figure 13: Request from a Relatively New Client
If the SBC does protocol repair, it can re-write the 'lr' parameter If the SBC does protocol repair, it can rewrite the 'lr' parameter on
on the Via header field into the form 'lr=true', in order to support the Via header field into the form 'lr=true' in order to support some
some older, badly implemented SIP stacks. It could also remove older, badly implemented SIP stacks. It could also remove excess
excess white spaces to make the SIP message more human readable. white spaces to make the SIP message more human readable.
3.7. Media Encryption 3.7. Media Encryption
3.7.1. General Information and Requirements 3.7.1. General Information and Requirements
SBCs are used to perform media encryption / decryption at the edge of SBCs are used to perform media encryption/decryption at the edge of
the network. This is the case when media encryption (e.g., Secure the network. This is the case when media encryption (e.g., Secure
Real-time Transport Protocol (SRTP)) is used only on the access Real-time Transport Protocol (SRTP)) is used only on the access
network (outer network) side and the media is carried unencrypted in network (outer network) side and the media is carried unencrypted in
the inner network. Some operators provide the ability to do legal the inner network. Some operators provide the ability to do legal
interception while still giving their customers the ability to interception while still giving their customers the ability to
encrypt media in the access network. One possible way to do this is encrypt media in the access network. One possible way to do this is
to perform media encryption function. to perform media encryption function.
3.7.2. Architectural Issues 3.7.2. Architectural Issues
While performing a media encryption function, SBCs need to be able to While performing a media encryption function, SBCs need to be able to
inject either themselves, or some other entity to the media path. It 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 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 MITM attack. Due to this, the SBCs have the same architectural
issues as explained in Section 3.2. issues as explained in Section 3.2.
3.7.3. Example 3.7.3. Example
Figure 14 shows an example where the SBC is performing media Figure 14 shows an example where the SBC is performing media-
encryption related functions (ACKs omitted for brevity). encryption-related functions (ACKs omitted for brevity).
caller SBC#1 SBC#2 callee caller SBC#1 SBC#2 callee
| | | | | | | |
| INVITE + SDP | | | | INVITE + SDP | | |
|------------------->| | | |------------------->| | |
| [Modify the SDP] | | | [Modify the SDP] | |
| | | | | | | |
| | INVITE + mod. SDP | | | | INVITE + mod. SDP | |
| |------------------->| | | |------------------->| |
| | [Modify the SDP] | | | [Modify the SDP] |
skipping to change at page 21, line 50 skipping to change at page 23, line 5
| 200 OK + mod. SDP | | | | 200 OK + mod. SDP | | |
|<-------------------| | | |<-------------------| | |
| | | | | | | |
| Encrypted | Plain | Encrypted | | Encrypted | Plain | Encrypted |
| media [enc./dec.] media [enc./dec.] media | | media [enc./dec.] media [enc./dec.] media |
|<==================>|<- - - - - - - - ->|<==================>| |<==================>|<- - - - - - - - ->|<==================>|
| | | | | | | |
Figure 14: Media Encryption Example Figure 14: Media Encryption Example
First the UAC sends an INVITE request , and the first SBC modifies 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 the session descriptor in a way that it injects itself to the media
path. The same happens in the second SBC. Then the UAS replies with path. The same happens in the second SBC. Then, the User Agent
a 200 OK response and the SBCs inject themselves in the returning Server (UAS) replies with a 200 OK response and the SBCs inject
media path. After signaling the media starts flowing, and both SBCs themselves in the returning media path. After signaling, the media
are performing media encryption and decryption. starts flowing, and both SBCs perform media encryption and
decryption.
4. Derived Requirements for Future SIP Standardization Work 4. Derived Requirements for Future SIP Standardization Work
Some of the functions listed in this document are more SIP-unfriendly Some of the functions listed in this document are more SIP-unfriendly
than others. This list of requirements is derived from the functions than others. This list of requirements is derived from the functions
that break the principles of SIP in one way or another when performed that break the principles of SIP in one way or another when performed
by SBCs that do not have the users' consent. The derived by SBCs that do not have the users' consent. The derived
requirements are: requirements are:
Req-1: There should be a SIP-friendly way to hide network topology Req-1: There should be a SIP-friendly way to hide network topology
information. Currently this is done by stripping and information. Currently, this is done by stripping and
replacing header fields, which is against the principles of replacing header fields, which is against the principles of
SIP on behalf of some header fields (see Section 3.1). SIP on behalf of some header fields (see Section 3.1).
Req-2: There should be a SIP-friendly way to direct media traffic Req-2: There should be a SIP-friendly way to direct media traffic
through intermediaries. Currently this is done by modifying through intermediaries. Currently, this is done by modifying
session descriptors, which is against the principles of SIP session descriptors, which is against the principles of SIP
(see Section 3.2, Section 3.4, Section 3.5, and Section 3.7). (see Sections 3.2, 3.4, 3.5, and 3.7).
Req-3: There should be a SIP-friendly way to fix capability Req-3: There should be a SIP-friendly way to fix capability
mismatches in SIP messages. This requirement is harder to mismatches in SIP messages. This requirement is harder to
fulfill on complex mismatch cases, like the 3GPP/SIP [1] fulfill on complex mismatch cases, like the 3GPP/SIP [1]
network mismatch. Currently this is done by modifying SIP network mismatch. Currently, this is done by modifying SIP
messages, which may violate end-to-end security (see messages, which may violate end-to-end security (see Sections
Section 3.3 and Section 3.6), on behalf of some header 3.3 and 3.6), on behalf of some header fields.
fields.
Req-1 and Req-3 do not have an existing, standardized solution today. 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 There is ongoing work in the IETF for addressing Req-2, such as SIP
session policies [10], Traversal Using Relays around NAT (TURN) [11], session policies [10], Traversal Using Relays around NAT (TURN) [11],
and Interactive Connectivity Establishment (ICE) [12]. Nonetheless, and Interactive Connectivity Establishment (ICE) [12]. Nonetheless,
future work is needed in order to develop solutions to these future work is needed in order to develop solutions to these
requirements. requirements.
5. Security Considerations 5. Security Considerations
Many of the functions this document describes have important security Many of the functions this document describes have important security
and privacy implications. One major security problem is that many and privacy implications. One major security problem is that many
functions implemented by SBCs (e.g., topology hiding and media functions implemented by SBCs (e.g., topology hiding and media
traffic management) modify SIP messages and their bodies without the traffic management) modify SIP messages and their bodies without the
user agents' consent. The result is that the user agents may user agents' consent. The result is that the user agents may
interpret the actions taken by an SBC as a MitM attack. SBCs modify interpret the actions taken by an SBC as a MITM attack. SBCs modify
SIP messages because it allows them to, for example, protect elements SIP messages because it allows them to, for example, protect elements
in the inner network from direct attacks. in the inner network from direct attacks.
SBCs that place themselves (or another entity) on the media path can SBCs that place themselves (or another entity) on the media path can
be used to eavesdrop on conversations. Since, often, user agents be used to eavesdrop on conversations. Since, often, user agents
cannot distinguish between the actions of an attacker and those of an cannot distinguish between the actions of an attacker and those of an
SBC, users cannot know whether they are being eavesdropped or an SBC SBC, users cannot know whether they are being eavesdropped on or if
on the path is performing some other function. SBCs place themselves an SBC on the path is performing some other function. SBCs place
on the media path because it allows them to, for example, perform themselves on the media path because it allows them to, for example,
legal interception. perform legal interception.
On a general level SBCs prevent the use of end-to-end authentication. On a general level, SBCs prevent the use of end-to-end
This is because SBCs need to be able to perform actions that look authentication. This is because SBCs need to be able to perform
like MitM attacks, and in order for user agents to communicate, they actions that look like MITM attacks, and in order for user agents to
must allow those type of attacks. It other words, user agents can communicate, they must allow those type of attacks. It other words,
not use end-to-end security. This is especially harmful because also user agents cannot use end-to-end security. This is especially
other network element, besides SBCs, are then able to do similar harmful because other network elements, besides SBCs, are then able
attacks. However, on some cases, user agents can establish encrypted to do similar attacks. However, in some cases, user agents can
media connections between each other. One example is a scenario establish encrypted media connections between one another. One
where SBC is used for enabling media monitoring, but not for example is a scenario where SBC is used for enabling media monitoring
interception. but not for interception.
An SBC is a single point of failure from the architectural point of 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 view. This makes it an attractive target for DoS attacks. The fact
that some functions of SBCs require those SBCs to maintain session- that some functions of SBCs require those SBCs to maintain session-
specific information makes the situation even worse. If the SBC specific information makes the situation even worse. If the SBC
crashes (or is brought down by an attacker), ongoing sessions crashes (or is brought down by an attacker), ongoing sessions
experience undetermined behavior. experience undetermined behavior.
If the IETF decides to develop standard mechanisms to address the If the IETF decides to develop standard mechanisms to address the
requirements presented in Section 4, the security and privacy-related requirements presented in Section 4, the security and privacy-related
aspects of those mechanisms will, of course, need to be taken into aspects of those mechanisms will, of course, need to be taken into
consideration. consideration.
6. IANA Considerations 6. Acknowledgements
This document has no IANA considerations.
7. Acknowledgements
The ad-hoc meeting about SBCs, held on Nov 9th 2004 at Washington DC The ad hoc meeting about SBCs, held on November 9, 2004 in Washington
during the 61st IETF meeting, provided valuable input to this DC during the 61st IETF meeting, provided valuable input to this
document. Authors would also like to thank Sridhar Ramachandran, document. The authors would also like to thank Sridhar Ramachandran,
Gaurav Kulshreshtha, and Rakendu Devdhar. Reviewers Spencer Dawkins Gaurav Kulshreshtha, and Rakendu Devdhar. Reviewers Spencer Dawkins
and Francois Audet also deserve special thanks. and Francois Audet also deserve special thanks.
8. References 7. References
8.1. Normative References
7.1. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[2] Peterson, J., "A Privacy Mechanism for the Session Initiation [2] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002. Protocol (SIP)", RFC 3323, November 2002.
[3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) [3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
Extension Header Field for Registering Non-Adjacent Contacts", Extension Header Field for Registering Non-Adjacent Contacts",
RFC 3327, December 2002. RFC 3327, December 2002.
[4] Peterson, J. and C. Jennings, "Enhancements for Authenticated [4] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)", Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006. RFC 4474, August 2006.
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
8.2. Informational References 7.2. Informative References
[6] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 [6] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228
5.15.0, June 2006. 10.0.0, March 2010.
[7] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [7] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[8] Munakata, M., Schubert, S., and T. Ohba, "UA-Driven Privacy [8] Munakata, M., Schubert, S., and T. Ohba, "User-Agent-Driven
Mechanism for SIP", draft-ietf-sip-ua-privacy-08 (work in Privacy Mechanism for SIP", RFC 5767, April 2010.
progress), May 2009.
[9] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for [9] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for
Application Designers", BCP 145, RFC 5405, November 2008. Application Designers", BCP 145, RFC 5405, November 2008.
[10] Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework for [10] Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework for
Session Initiation Protocol (SIP) Session Policies", Session Initiation Protocol (SIP) Session Policies", Work
draft-ietf-sip-session-policy-framework-06 (work in progress), in Progress, February 2010.
September 2009.
[11] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using [11] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Traversal Relays around NAT (TURN): Relay Extensions to Session Traversal
Utilities for NAT (STUN)", draft-ietf-behave-turn-16 (work in Utilities for NAT (STUN)", RFC 5766, April 2010.
progress), July 2009.
[12] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A [12] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Protocol for Network Address Translator (NAT) Traversal for Protocol for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in Offer/Answer Protocols", RFC 5245, MonthTBD 2010.
progress), October 2007.
Authors' Addresses Authors' Addresses
Jani Hautakorpi (editor) Jani Hautakorpi (editor)
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Jani.Hautakorpi@ericsson.com EMail: Jani.Hautakorpi@ericsson.com
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com EMail: Gonzalo.Camarillo@ericsson.com
Robert F. Penfield Robert F. Penfield
Acme Packet Acme Packet
71 Third Avenue 71 Third Avenue
Burlington, MA 01803 Burlington, MA 01803
US US
Email: bpenfield@acmepacket.com EMail: bpenfield@acmepacket.com
Alan Hawrylyshen Alan Hawrylyshen
Ditech Networks Inc. Skype, Inc.
825 E Middlefield Rd 2055 E. Hamilton Ave
Mountain View, CA San Jose, CA 95125
US US
Email: alan.ietf@polyphase.ca EMail: alan.ietf@polyphase.ca
Medhavi Bhatia Medhavi Bhatia
3CLogic 3CLogic
9700 Great Seneca Hwy. 9700 Great Seneca Hwy.
Rockville, MD 20850 Rockville, MD 20850
US US
Email: mbhatia@3clogic.com EMail: mbhatia@3clogic.com
 End of changes. 125 change blocks. 
300 lines changed or deleted 289 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/