draft-ietf-sipping-sbc-funcs-01.txt   draft-ietf-sipping-sbc-funcs-02.txt 
SIPPING Working Group J. Hautakorpi, Ed. SIPPING Working Group J. Hautakorpi, Ed.
Internet-Draft G. Camarillo Internet-Draft G. Camarillo
Expires: August 24, 2007 Ericsson Expires: October 15, 2007 Ericsson
R. Penfield R. Penfield
Acme Packet Acme Packet
A. Hawrylyshen A. Hawrylyshen
Ditech Networks Inc. Ditech Networks Inc.
M. Bhatia M. Bhatia
NexTone Communications NexTone Communications
February 20, 2007 April 13, 2007
Requirements from SIP (Session Initiation Protocol) Session Border Requirements from SIP (Session Initiation Protocol) Session Border
Control Deployments Control Deployments
draft-ietf-sipping-sbc-funcs-01.txt draft-ietf-sipping-sbc-funcs-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 24, 2007. This Internet-Draft will expire on October 15, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This documents describes functions implemented in Session Initiation This documents 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
skipping to change at page 3, line 24 skipping to change at page 3, line 24
3.1.2. Architectural Issues . . . . . . . . . . . . . . . . . 8 3.1.2. Architectural Issues . . . . . . . . . . . . . . . . . 8
3.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Media Traffic Shaping . . . . . . . . . . . . . . . . . . 10 3.2. Media Traffic Shaping . . . . . . . . . . . . . . . . . . 10
3.2.1. General Information and Requirements . . . . . . . . . 10 3.2.1. General Information and Requirements . . . . . . . . . 10
3.2.2. Architectural Issues . . . . . . . . . . . . . . . . . 10 3.2.2. Architectural Issues . . . . . . . . . . . . . . . . . 10
3.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Fixing Capability Mismatches . . . . . . . . . . . . . . . 12 3.3. Fixing Capability Mismatches . . . . . . . . . . . . . . . 12
3.3.1. General Information and Requirements . . . . . . . . . 12 3.3.1. General Information and Requirements . . . . . . . . . 12
3.3.2. Architectural Issues . . . . . . . . . . . . . . . . . 12 3.3.2. Architectural Issues . . . . . . . . . . . . . . . . . 12
3.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 13 3.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 13
3.4. Maintaining SIP-related NAT Bindings . . . . . . . . . . . 13 3.4. Maintaining SIP-related NAT Bindings . . . . . . . . . . . 14
3.4.1. General Information and Requirements . . . . . . . . . 14 3.4.1. General Information and Requirements . . . . . . . . . 14
3.4.2. Architectural Issues . . . . . . . . . . . . . . . . . 14 3.4.2. Architectural Issues . . . . . . . . . . . . . . . . . 15
3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 15 3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 15
3.5. Access Control . . . . . . . . . . . . . . . . . . . . . . 15 3.5. Access Control . . . . . . . . . . . . . . . . . . . . . . 16
3.5.1. General Information and Requirements . . . . . . . . . 15 3.5.1. General Information and Requirements . . . . . . . . . 16
3.5.2. Architectural Issues . . . . . . . . . . . . . . . . . 16 3.5.2. Architectural Issues . . . . . . . . . . . . . . . . . 16
3.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 16 3.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 17
3.6. Protocol Repair . . . . . . . . . . . . . . . . . . . . . 17 3.6. Protocol Repair . . . . . . . . . . . . . . . . . . . . . 17
3.6.1. General Information and Requirements . . . . . . . . . 17 3.6.1. General Information and Requirements . . . . . . . . . 17
3.6.2. Architectural Issues . . . . . . . . . . . . . . . . . 18 3.6.2. Architectural Issues . . . . . . . . . . . . . . . . . 18
3.6.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 18 3.6.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 18
3.7. Media Encryption . . . . . . . . . . . . . . . . . . . . . 18 3.7. Media Encryption . . . . . . . . . . . . . . . . . . . . . 18
3.7.1. General Information and Requirements . . . . . . . . . 18 3.7.1. General Information and Requirements . . . . . . . . . 18
3.7.2. Architectural Issues . . . . . . . . . . . . . . . . . 18 3.7.2. Architectural Issues . . . . . . . . . . . . . . . . . 19
3.7.3. Example . . . . . . . . . . . . . . . . . . . . . . . 19 3.7.3. Example . . . . . . . . . . . . . . . . . . . . . . . 19
4. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 20 4. Derived Requirements for Future SIP Standardization Work . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
8.2. Informational References . . . . . . . . . . . . . . . . . 21 8.2. Informational References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 23
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 badly in a sense that they
break end-to-end security and impact on feature negotiations, there break end-to-end security and impact feature negotiations, there is
is clearly a market for them. Network operators need many of the clearly a market for them. Network operators need many of the
features current SBCs provide and many times there are no standard features current SBCs provide and often there are no standard
mechanisms available to provide them in a better way. mechanisms available to 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 are
conflicting with SIP architectural principles in some way. The conflicting with SIP architectural principles in some way. The
document also explores the underlying requirements of network document also explores the underlying requirements of network
operators that have led to the use of these functions and practices operators that have led to the use of these functions and practices
in order to identify protocol requirements and determine whether in order to identify protocol requirements and determine whether
those requirements are satisfied by existing specifications or those requirements are satisfied by existing specifications or
additional standards work is required. additional standards work is required.
skipping to change at page 4, line 49 skipping to change at page 4, line 49
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 DoS a) perimeter defense (access control, topology hiding, and DoS
prevention and detection); b) functionality not available in the prevention and detection); b) functionality not available in the
endpoints (NAT traversal, protocol interworking or repair); and c) endpoints (NAT traversal, protocol interworking or repair); and c)
network management (traffic monitoring, shaping, and QoS). Some of network management (traffic monitoring, shaping, and QoS). Some of
these functions may also get integrated into other SIP elements (like these functions may also get integrated into other SIP elements (like
pre-paid platforms, 3GPP P-CSCF [4], 3GPP I-CSCF, etc). pre-paid platforms, 3GPP P-CSCF [5], 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 which 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 Privacy).
SBCs often modify certain SIP headers and message bodies that proxies SBCs often modify certain SIP headers and message bodies that proxies
are not allowed to modify. Consequently, they are, by definition, are not allowed to modify. Consequently, they are, by definition,
B2BUAs (Back-to-Back User Agents). The transparency of these B2BUAs B2BUAs (Back-to-Back User Agents). The transparency of these B2BUAs
varies depending on the functions they perform. For example, some varies depending on the functions they perform. For example, some
SBCs modify the session description carried in the message and insert SBCs modify the session description carried in the message and insert
a Record-Route entry. Other SBCs replace the value of the Contact a Record-Route entry. Other SBCs replace the value of the Contact
skipping to change at page 6, line 40 skipping to change at page 6, line 40
(both media and signaling) to the SBCs. The SBC helps ensure that (both media and signaling) to the SBCs. The SBC helps ensure that
only media from sessions the SBC authorizes will reach the gateway. only 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
operator's network, protect its components (media servers, operator's network, protect its components (media servers,
application servers, gateways, etc.) from unauthorized use and DoS application servers, gateways, etc.) from unauthorized use and DoS
attacks, and monitor the signaling and media traffic. Also, as a attacks, and monitor the signaling and media traffic. Also, since
part of access control, since the SBC is call stateful, it can the SBC is call stateful, it may provide access control functions to
prevent over subscription of the access links. Endpoints are prevent over subscription of the access links. Endpoints are
configured with the SBC as their outbound proxy address. The SBC configured with the SBC as their outbound proxy address. The SBC
routes requests to one or more proxies in the operator network. routes requests to one or more proxies in the operator network.
Access Network . Operator Network Access Network Operator Network
.
+-----+ . +-----+
| UA1 |<---------\ . | UA1 |<---------\
+-----+ \ . +-----+ \
\ . \
+-----+ \------->+-----+ +-------+ +-----+ \------->+-----+ +-------+
| 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
when the access network is an enterprise network), or in the operator
network (e.g., this is common when the access network is a
residential or small business network).
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 the cases where the access network is a private network, the SBC is the
NAT for all traffic. The proxy usually does authentication and/or NAT for all traffic. The proxy usually does authentication and/or
authorization for registrations and outbound calls. The SBC modifies authorization for registrations and outbound calls. The SBC modifies
the REGISTER request so that subsequent requests to the registered the REGISTER request so that subsequent requests to the registered
address-of-record are routed to the SBC. This is done either with a address-of-record are routed to the SBC. This is done either with a
Path header, or by modifying the Contact to point at the SBC. Path header, or by modifying the Contact to 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
skipping to change at page 7, line 47 skipping to change at page 8, line 6
in current communication networks. Each subsection describes a in current communication networks. Each subsection describes a
particular function or feature, the operators' requirements for particular function or feature, the operators' requirements for
having it, explanation of any impact to the end-to-end SIP having it, explanation of any impact to the end-to-end SIP
architecture, and a concrete implementation example. Each section architecture, and a concrete implementation example. Each section
also discusses potential concerns specific to that particular also discusses potential concerns specific to that particular
implementation technique. Suggestions for alternative implementation implementation technique. Suggestions for alternative implementation
techniques that may be more architecturally compatible with SIP are techniques that may be more architecturally compatible with SIP are
outside the scope of this document. outside the scope of this document.
All the examples given in this section are simplified; only the All the examples given in this section are simplified; only the
relevant header lines from SIP and SDP [5] messages are displayed. relevant header lines from SIP and SDP [6] 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 (Denial of Service) attacks, they may expose their equipment to DoS (Denial of Service) attacks, they may
use other carriers for certain traffic and do not want their use other carriers for certain traffic and do not want their
customers to be aware of it or they may want to hide their internal customers to be aware of it or they may want to hide their internal
network architecture from competitors or partners. In some network architecture from competitors or partners. In some
environments, the operator's customers may wish to hide the addresses environments, the operator's customers may wish to hide the addresses
of their equipment or the SIP messages may contain private, non- of their equipment or the SIP messages may contain private, non-
routable addresses. 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 and replacing the Contact header. However, in Record-Route headers, replacing the Contact header, and even changing
deployments which use IP addresses instead of domain names in headers Call-IDs. However, in deployments which use IP addresses instead of
that cannot be removed (e.g. From and To headers), the SBC may domain names in headers that cannot be removed (e.g. From and To
replace these IP addresses with its own IP address or domain name. headers), the SBC may replace these IP addresses with its own IP
address or domain name.
3.1.2. Architectural Issues 3.1.2. Architectural Issues
This functionality is based on a hop-by-hop trust model as opposed to This functionality is based on a hop-by-hop trust model as opposed to
an end-to-end trust model. The messages are modified without an end-to-end trust model. The messages are modified without
subscriber consent and could potentially modify or remove information subscriber consent and could potentially modify or remove information
about the user's privacy, security requirements and higher layer about the user's privacy, security requirements and higher layer
applications which are communicating end-to-end using SIP. Neither applications which are communicating end-to-end using SIP. Neither
user agent in an end-to-end call does not have any way to distinguish user agent in an end-to-end call has any way to distinguish the SBC
the SBC actions from a Man-In-The-Middle (MitM) attack. actions from a Man-In-The-Middle (MitM) attack.
Modification of IP addresses in Uniform Resource Identifiers (URIs) Topology hiding function does not work well with Authenticated
within SIP headers can lead to application failures if these URIs are Identity Management [3]. The Authenticated Identity Management
communicated to other SIP servers outside the current dialog. These mechanism is based on a hash value that is calculated from parts of
URIs could appear in a REFER request or in the body of NOTIFY request From, To, Call-Id, CSeq, Date, and Contact header fields plus from
as part of an event package. If these messages traverse the same the whole message body. If the authentication service is not
SBC, it has the opportunity to restore the original IP address. On provided by the SBC itself, the modification of the forementioned
the other hand, if the REFER or NOTIFY message returns to the header fields and the message body is in violation with [3]. Some
original network through a different SBC that does not have access to forms of topology hiding are in violation, because they are e.g.,
the address mapping, the recipient of the message will not see the replacing the Contact header of a SIP message.
original address. This may cause the application function to fail.
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 Agents) and remove all traces SBC act as a B2BUA (Back-to-Back User Agents) and remove all traces
of topology information (e.g., Record-Route and Via entries) from of 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=z9hG4bK48jq9w9174131.1
Via: SIP/2.0/UDP p2.example.com;branch=z9hG4bK18an6i9234172.1
Via: SIP/2.0/UDP p1.example.com;branch=z9hG4bK39bn2e5239289.1
Via: SIP/2.0/UDP u1.example.com;branch=z9hG4bK92fj4u7283927.1
Contact: sip:caller@u1.example.com Contact: sip:caller@u1.example.com
Record-Route: <sip:p3.middle.example.com> Record-Route: <sip:p3.middle.example.com>
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 Record-Route headers, and the SBC removes and stores all existing Via and Record-Route headers,
then inserts a Record-Route header field with its own SIP URI. After and then inserts a Via and Record-Route header fields with its own
the topology hiding function, the message could appear as shown in SIP URI. After the topology hiding function, the message could
Figure 5. appear as 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=z9hG4bK92es3w1230129.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., the SBC restarts for some reason), it may not be loses state (e.g., the SBC restarts for some reason), it may not be
able to route messages properly. For example, if the SBC removes able to route messages properly. For example, if the SBC removes
"Via" entries from a request and then restarts, thus losing state, "Via" entries from a request and then restarts, thus losing state,
skipping to change at page 10, line 9 skipping to change at page 10, line 10
This is only one example of topology hiding. In some cases, SBCs may This is only one example of topology hiding. In some cases, SBCs may
modify other headers, including the Contact header field values. The modify other headers, including the Contact header field values. The
header fields containing identity information is listed in Section header fields containing identity information is listed in Section
4.1 of [2]. 4.1 of [2].
3.2. Media Traffic Shaping 3.2. Media Traffic Shaping
3.2.1. General Information and Requirements 3.2.1. General Information and Requirements
Media traffic shaping is the act of controlling media traffic. Media traffic shaping is the function of controlling media traffic.
Network operators may require this functionality in order to control Network operators may require this functionality in order to control
the traffic being carried on their network on behalf of their the traffic being carried on their network on behalf of their
subscribers. Traffic shaping helps the creation of different kinds subscribers. Traffic shaping helps the creation of different kinds
of billing models (e.g., video telephony can be priced differently to of billing models (e.g., video telephony can be priced differently to
voice-only calls) and it also makes it possible for operators to voice-only calls) and it also makes it possible for operators to
enforce the usage of selected codecs. Additionally, traffic shaping enforce the usage of selected codecs. Additionally, traffic shaping
can be used to implement intercept capabilities where required to can be used to implement intercept capabilities where required to
support audit or legal obligations. support audit or legal obligations.
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
shaping can be done, for example, to ensure a certain QoS (Quality of shaping can be done, for example, to ensure a certain QoS (Quality of
Service) level. Service) level.
Some operators do not want to reshape the traffic (e.g., change a Some operators do not want to reshape the traffic (e.g., allowing
codec), but only to monitor it for collecting statistics and making only certain codecs), but only to monitor it for collecting
sure that they are able to meet any business service level agreements statistics and making sure that they are able to meet any business
with their subscribers and/or partners. The protocol techniques service level agreements with their subscribers and/or partners. The
needed for monitoring media traffic are the same as for reshaping protocol techniques needed for monitoring media traffic are the same
media traffic. as for reshaping media 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 cleanup any state in other intermediate elements and
the endpoints. the endpoints.
One possible form of media traffic shaping is that SBCs terminate One possible form of media traffic shaping 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 of procedure can take place, for example, in a situation where
subscriber runs out of credits. subscriber runs out of credits.
3.2.2. Architectural Issues 3.2.2. Architectural Issues
Implementing traffic shaping in this manner requires the SBC to Implementing traffic shaping 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. actions from an attack by a MitM. Furthermore, this is in violation
with [3], see Section 3.1.2.
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 shaping may be performed in the following way: The SBC Traffic shaping 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
shaping. The SBC restricts the codec set negotiated in the offer/ shaping. The SBC restricts the codec set negotiated in the offer/
answer exchange [3] between the user-agents. After modifying the answer exchange [4] 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.
skipping to change at page 11, line 44 skipping to change at page 11, line 47
v=0 v=0
o=mhandley 2890844526 2890842807 IN IP4 192.0.2.4 o=mhandley 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 Shaping Figure 6: Request Prior to Media Shaping
In this example, the SBC performs the media traffic shaping function In this example, the SBC performs the media traffic shaping function
by rewritting the 'm' line, and removing one 'a' line according to by rewriting the 'm' line, and removing one 'a' line according to
some (external) policy. Figure 7 shows the session description after some (external) policy. Figure 7 shows the session description after
the traffic shaping function. the traffic shaping function.
v=0 v=0
o=mhandley 2890844526 2890842807 IN IP4 192.0.2.4 o=mhandley 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 Shaping Figure 7: Request Body After Media Shaping
Media traffic shaping has a problem where the SBC needs to understand Media traffic shaping has a problem where the SBC needs to understand
the session description protocol and all extensions used by the user- the session description protocol and all extensions used by the user-
agents. This means that in order to use a new extension (e.g., an agents. This means that in order to use a new extension (e.g., an
extension to implement a new service) or a new session description extension to implement a new service) or a new session description
protocol, SBCs in the network may need to be upgraded in conjunction protocol, SBCs in the network may need to be upgraded in conjunction
with the endpoints. It is noteworthy than similar problem, but with with the endpoints. It is noteworthy that similar problem, but with
header fields, applies to, for example, topology hiding function, see header fields, applies to, for example, topology hiding function, see
Section 3.1. Certain extensions that do not require active Section 3.1. Certain extensions that do not require active
manipulation of the session descriptors to facilitate traffic shaping manipulation of the session descriptors to facilitate traffic shaping
will be able to be deployed without upgrading existing SBCs, will be able to be deployed without upgrading existing SBCs,
depending on the degree of transparency the SBC implementation depending on the degree of transparency the SBC implementation
affords. In cases requiring an SBC modification to support the new affords. In cases requiring an SBC modification to support the new
protocol features, the rate of service deployment may be affected. protocol features, the rate of service deployment may be affected.
3.3. Fixing Capability Mismatches 3.3. Fixing Capability Mismatches
skipping to change at page 12, line 52 skipping to change at page 12, line 52
3.3.2. Architectural Issues 3.3.2. Architectural Issues
SBCs fixing capability mismatches insert a media element in the media SBCs fixing capability mismatches insert a media element in the media
path using the procedures described in Section 3.2. Therefore, these path using the procedures described in Section 3.2. Therefore, these
SBCs have the same concerns as SBCs performing traffic shaping: the SBCs have the same concerns as SBCs performing traffic shaping: the
SBC modifies SIP messages without explicit consent from any of the SBC modifies SIP messages without explicit consent from any of the
user-agents. This may break end-to-end security and application user-agents. This may break end-to-end security and application
extensions negotiation. extensions negotiation.
There is also a problem related to increasing complexity. If the The capability mismatch fixing is a fragile function in the long
number of incompatibilites increase, which is probable, then SBCs term. The number of incompatibilities built into various network
need to be able to handle a large number of capability mismatches in elements is increasing the fragility and complexity over time. This
parallel. might lead to a situation where SBCs need to be able to handle a
large number of capability mismatches in parallel.
3.3.3. Example 3.3.3. Example
Consider the following example scenario where the inner network is an Consider the following example scenario where the inner network is an
access network using IPv4 and the outer network is using IPv6. The access network using IPv4 and the outer network is using IPv6. The
SBC receives an INVITE request with a session description from the SBC receives an INVITE request with a session description from the
access network: access network:
INVITE sip:callee@ipv6.domain.example.com SIP/2.0 INVITE sip:callee@ipv6.domain.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4 Via: SIP/2.0/UDP 192.0.2.4
skipping to change at page 13, line 28 skipping to change at page 13, line 29
v=0 v=0
o=mhandley 2890844526 2890842807 IN IP4 192.0.2.4 o=mhandley 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 this
imagined situation the SBC inserts Record-Route and Via headers, and scenario the SBC inserts Record-Route and Via headers, and rewrites
rewrites the 'c' line from the sessions descriptor. Figure 9 shows the 'c' line from the sessions descriptor. Figure 9 shows the
the request after the capability mismatch adjusment. 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=mhandley 2890844526 2890842807 IN IP4 192.0.2.4 o=mhandley 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
skipping to change at page 16, line 49 skipping to change at page 17, line 9
the event of a failure on a single node. the event of a failure on a single node.
If access control is performed only on behalf of signaling, then the If access control is performed only on behalf of signaling, then the
SBC is compatible with general SIP architectural principles, but if SBC is compatible with general SIP architectural principles, but if
it is performed for signaling and for media, then there are similar it is performed for signaling and for media, then there are similar
problems as described in Section 3.2.2. problems as described in Section 3.2.2.
3.5.3. Example 3.5.3. Example
Figure 12 shows a callflow where the SBC is providing both signaling Figure 12 shows a callflow where the SBC is providing both signaling
and media access control. and media access control (ACKs omitted for brevity).
caller SBC callee caller SBC callee
| | | | | |
| Identify the caller | | | Identify the caller | |
|<- - - - - - - - - - - >| | |<- - - - - - - - - - - >| |
| | | | | |
| INVITE + SDP | | | INVITE + SDP | |
|----------------------->| | |----------------------->| |
| [Modify the SDP] | | [Modify the SDP] |
| | INVITE + modified SDP | | | INVITE + modified SDP |
skipping to change at page 17, line 31 skipping to change at page 17, line 37
|<-----------------------| | |<-----------------------| |
| | | | | |
| 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 for the caller.
The identification can be done, for example, already in the This might be achieved using information gathered during
registration phase. Some SBCs may rely on the proxy to authenticate registration, or by other means. Some SBCs may rely on the proxy to
the user-agent placing the call. After identification, the SBC authenticate the user-agent placing the call. After identification,
modifies the session descriptors in INVITE and 200 OK messages in a the SBC modifies the session descriptors in INVITE and 200 OK
way that the media is going to flow through SBC itself. When the messages in a way that the media is going to flow through SBC itself.
media starts flowing, the SBC can inspect whether the callee and When the media starts flowing, the SBC can inspect whether the callee
caller use the codec(s) that they had previously agreed on. and caller use the codec(s) that they had previously agreed on.
3.6. Protocol Repair 3.6. Protocol Repair
3.6.1. General Information and Requirements 3.6.1. General Information and Requirements
SBC are also used to repair protocol messages generated by not-fully- SBC are also used to repair protocol messages generated by not-fully-
standard clients. Operators may wish to support protocol repair, if standard clients. Operators may wish to support protocol repair, if
they want to support as many clients as possible. It is noteworthy, they want to support as many clients as possible. It is noteworthy,
that this function affects only the signaling component of SBC, and that this function affects only the signaling component of SBC, and
that protocol repair function is not the same as protocol conversion. that protocol repair function is not the same as protocol conversion.
skipping to change at page 19, line 4 skipping to change at page 19, line 9
unencrypted in the inner network. Operators may have an obligation unencrypted in the inner network. Operators may have an obligation
to provide the ability to do legal interception, while they still to provide the ability to do legal interception, while they still
want to give their customers the ability to encrypt media in the want to give their customers the ability to encrypt media in the
access network. This leads to a situation where operators have a access network. This leads to a situation where operators have a
requirement to perform media encryption function. requirement 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. inject either themselves, or some other entity to the media path.
Due to this, the SBCs have the same architectural issues as explained Due to this, the SBCs have the same architectural issues as explained
in Section 3.2. 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. 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 20, line 5 skipping to change at page 20, line 6
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 UAS replies with
a 200 OK response, the SBCs inject themselves in the returning media a 200 OK response, the SBCs inject themselves in the returning media
path. After signaling the media start flowing, and both SBCs are path. After signaling the media start flowing, and both SBCs are
performing media encryption and decryption. performing media encryption and decryption.
4. Derived Requirements 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 requirements that are derived from the than others. This list requirements that are derived from the
functions that break the principles of SIP in one way or another. functions that break the principles of SIP in one way or another.
The derived requirements are: The derived 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. SIP.
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 without user
session descriptors, which is against the principles of SIP. consent by modifying session descriptors, which is against
the principles of SIP.
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/Packet Cable fulfill on complex mismatch cases, like the 3GPP/Packet Cable
mismatch. Currently this is done by modifying SIP messages, mismatch. Currently this is done by modifying SIP messages,
which violates end-to-end security. which violates end-to-end security.
All the above-mentioned requirements are such that they do not have All the above-mentioned requirements are such that they do not have
an existing solution today. Thus, future work is needed in order to an existing solution today. Thus, future work is needed in order to
develop solutions to these requirements. develop solutions to these requirements.
skipping to change at page 21, line 16 skipping to change at page 21, line 20
consideration. consideration.
6. IANA Considerations 6. IANA Considerations
This document has no IANA considerations. This document has no IANA considerations.
7. Acknowledgements 7. Acknowledgements
The ad-hoc meeting about SBCs, held on Nov 9th 2004 at Washington DC The ad-hoc meeting about SBCs, held on Nov 9th 2004 at Washington DC
during the 61st IETF meeting, provided valuable input to this during the 61st IETF meeting, provided valuable input to this
document. Special thanks goes also to Sridhar Ramachandran, Gaurav document. Authors would also like to thank Sridhar Ramachandran,
Kulshreshtha, and to Rakendu Devdhar. Gaurav Kulshreshtha, and Rakendu Devdhar. Reviewers Spencer Dawkins
and Francois Audet also deserve special thanks.
8. References 8. References
8.1. Normative References 8.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] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [3] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[4] 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 8.2. Informational References
[4] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 [5] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228
5.15.0, June 2006. 5.15.0, June 2006.
[5] Handley, M. and V. Jacobson, "SDP: Session Description [6] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
Authors' Addresses Authors' Addresses
Jani Hautakorpi (editor) Jani Hautakorpi (editor)
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
 End of changes. 43 change blocks. 
87 lines changed or deleted 104 lines changed or added

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