draft-ietf-sipping-sbc-funcs-04.txt   draft-ietf-sipping-sbc-funcs-05.txt 
SIPPING Working Group J. Hautakorpi, Ed. SIPPING Working Group J. Hautakorpi, Ed.
Internet-Draft G. Camarillo Internet-Draft G. Camarillo
Intended status: Informational Ericsson Intended status: Informational Ericsson
Expires: June 23, 2008 R. Penfield Expires: September 26, 2008 R. Penfield
Acme Packet Acme Packet
A. Hawrylyshen A. Hawrylyshen
Ditech Networks Inc. Ditech Networks Inc.
M. Bhatia M. Bhatia
3CLogic 3CLogic
December 21, 2007 March 25, 2008
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-04.txt draft-ietf-sipping-sbc-funcs-05.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 June 23, 2008. This Internet-Draft will expire on September 26, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
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
skipping to change at page 3, line 34 skipping to change at page 3, line 34
3.4. Maintaining SIP-related NAT Bindings . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . 15 3.4.2. Architectural Issues . . . . . . . . . . . . . . . . . 15
3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 15 3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 15
3.5. Access Control . . . . . . . . . . . . . . . . . . . . . . 16 3.5. Access Control . . . . . . . . . . . . . . . . . . . . . . 16
3.5.1. General Information and Requirements . . . . . . . . . 16 3.5.1. General Information and Requirements . . . . . . . . . 16
3.5.2. Architectural Issues . . . . . . . . . . . . . . . . . 17 3.5.2. Architectural Issues . . . . . . . . . . . . . . . . . 17
3.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 17 3.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 17
3.6. Protocol Repair . . . . . . . . . . . . . . . . . . . . . 18 3.6. Protocol Repair . . . . . . . . . . . . . . . . . . . . . 18
3.6.1. General Information and Requirements . . . . . . . . . 18 3.6.1. General Information and Requirements . . . . . . . . . 18
3.6.2. Architectural Issues . . . . . . . . . . . . . . . . . 18 3.6.2. Architectural Issues . . . . . . . . . . . . . . . . . 19
3.6.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 18 3.6.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 19
3.7. Media Encryption . . . . . . . . . . . . . . . . . . . . . 19 3.7. Media Encryption . . . . . . . . . . . . . . . . . . . . . 19
3.7.1. General Information and Requirements . . . . . . . . . 19 3.7.1. General Information and Requirements . . . . . . . . . 19
3.7.2. Architectural Issues . . . . . . . . . . . . . . . . . 19 3.7.2. Architectural Issues . . . . . . . . . . . . . . . . . 20
3.7.3. Example . . . . . . . . . . . . . . . . . . . . . . . 19 3.7.3. Example . . . . . . . . . . . . . . . . . . . . . . . 20
4. Derived Requirements for Future SIP Standardization Work . . . 20 4. Derived Requirements for Future SIP Standardization Work . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . . 22 8.1. Normative References . . . . . . . . . . . . . . . . . . . 23
8.2. Informational References . . . . . . . . . . . . . . . . . 22 8.2. Informational References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 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
skipping to change at page 5, line 30 skipping to change at page 5, line 30
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. and inner network are used for describing these two networks. An SBC
is logically associated to the inner network, and it typically
provides functions such as controlling and protecting access to the
inner network from the outer network.
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. For example, in a toll bypass exchange traffic with each other. For example, in a toll bypass
application, a gateway in operator A's network sends an INVITE that application, a gateway in operator A's network sends an INVITE that
is routed to the softswitch (proxy) in operator B's network. The is routed to the softswitch (proxy) in operator B's network. The
proxy responds with a redirect (3xx) message back to the originating proxy responds with a redirect (3xx) message back to the originating
gateway that points to the appropriate terminating gateway in gateway that points to the appropriate terminating gateway in
operator B's network. The originating gateway then sends the INVITE operator B's network. The originating gateway then sends the INVITE
skipping to change at page 6, line 42 skipping to change at page 6, line 42
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, since attacks, and monitor the signaling and media traffic. Also, since
the SBC is call stateful, it may provide access control functions to 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 |<---------\
+-----+ \ +-----+ \
\ \
+-----+ \------->+-----+ +-------+ +-----+ \------->+-----+ +-------+
skipping to change at page 7, line 27 skipping to change at page 7, line 27
+-----+ +-----+ +-----+ +-----+
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). 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 a NAT
NAT for all traffic. The proxy usually does authentication and/or for all traffic. It is noteworthy that SIP traffic may have to
authorization for registrations and outbound calls. The SBC modifies traverse more that one NAT. The proxy usually does authentication
the REGISTER request so that subsequent requests to the registered and/or authorization for registrations and outbound calls. The SBC
address-of-record are routed to the SBC. This is done either with a modifies the REGISTER request so that subsequent requests to the
Path header, or by modifying the Contact to point at the SBC. registered 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.
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
in current communication networks. Each subsection describes a in current communication networks. Each subsection describes a
skipping to change at page 9, line 8 skipping to change at page 9, line 9
From, To, Call-Id, CSeq, Date, and Contact header fields plus from From, To, Call-Id, CSeq, Date, and Contact header fields plus from
the whole message body. If the authentication service is not the whole message body. If the authentication service is not
provided by the SBC itself, the modification of the forementioned provided by the SBC itself, the modification of the forementioned
header fields and the message body is in violation of [3]. Some header fields and the message body is in violation of [3]. Some
forms of topology hiding are in violation, because they are e.g., forms of topology hiding are in violation, because they are e.g.,
replacing the Contact header of a SIP message. 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 Agents) and remove all traces SBC act as a B2BUA (Back-to-Back User Agent) and remove all traces of
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=z9hG4bK48jq9w9174131.1 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 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> 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 a Via and Record-Route header fields with its own and then inserts Via and Record-Route header fields with its own SIP
SIP URI. After the topology hiding function, the message could URI. After the topology hiding function, the message could appear as
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=z9hG4bK92es3w1230129.1 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., SBC restarts for some reason), it may not be able
able to route messages properly. For example, if the SBC removes to route messages properly (note: some SBCs preserve the state
"Via" entries from a request and then restarts, thus losing state, information also on restart). For example, if the SBC removes "Via"
the SBC may not be able to route responses to that request; depending entries from a request and then restarts, thus losing state, the SBC
on the information that was lost when the SBC restarted. may not be able to route responses to that request; depending on the
information that was lost when the SBC restarted.
This is only one example of topology hiding. In some cases, SBCs may This is only one example of topology hiding. Besides topology hiding
modify other headers, including the Contact header field values. The (i.e., information related to network elements is beeing hidden),
header fields containing identity information is listed in Section SBCs may also do identity hiding (i.e., information related to
4.1 of [2]. Since the publication of [2], the following header identity of subscribers in beeing hidden). While performing identity
fields containing identity information have been defined: hiding, SBCs may modify Contact header field values and other header
"P-Asserted-Identity", "Referred-By", "Identity", and fields containing identity information. The header fields containing
"Identity-Info". identity information is listed in Section 4.1 of [2]. Since the
publication of [2], the following header fields containing identity
information have been defined: "P-Asserted-Identity", "Referred-By",
"Identity", and "Identity-Info".
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
skipping to change at page 10, line 29 skipping to change at page 10, line 36
for operators to enforce the usage of selected codecs. Additionally, for operators to enforce the usage of selected codecs. Additionally,
traffic management can be used to implement intercept capabilities traffic management can be used to implement intercept capabilities
where required to support audit or legal obligations. where required to 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
management can be done, for example, to ensure a certain QoS (Quality management can be done, for example, to ensure a certain QoS (Quality
of Service) level. of Service) level, or to ensure that subscribers are using only
allowed codecs.
Some operators do not want to manage the traffic (e.g., allowing only Some operators do not want to manage the traffic, but only to monitor
certain codecs), but only to monitor it for collecting statistics and it for collecting statistics and making sure that they are able to
making sure that they are able to meet any business service level meet any business service level agreements with their subscribers
agreements with their subscribers and/or partners. The protocol and/or partners. The protocol techniques needed for monitoring media
techniques needed for monitoring media traffic are the same as for traffic are the same as for managing media traffic.
managing 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 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 of procedure can take place, for example, in a situation where the
subscriber runs out of credits. Media management is needed for subscriber runs out of credits. Media management is needed to ensure
ensuring that the subscriber cannot just ignore the BYE request that the subscriber cannot just ignore the BYE request generated by
generated by the SBC and continue their media sessions. the SBC and continue their 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 [3], see Section 3.1.2. of Authenticated Identity Management [3], see Section 3.1.2.
Media traffic management function also hinders innovations. The Media traffic management function also hinders innovations. The
reason for the hinderance is that in many cases SBCs need to be able reason for the hinderance is that in many cases SBCs need to be able
to support new ways of communicating (e.g., extensions to the SDP to support new ways of communicating (e.g., extensions to the SDP
protocol) before new services can be taken into use, and that slows protocol) before new services can be taken into use, and that slows
down the adoption of innovations. down the adoption of innovations.
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.
skipping to change at page 12, line 6 skipping to change at page 12, line 7
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=mhandley 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=mhandley 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 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, user- agents with different capabilities or extensions. For example, user-
agents on networks which implement SIP differently (for example 3GPP agents on networks which implement SIP differently (for example 3GPP
or Packet Cable etc) or those that support different IP versions, or SIP [1] network etc) or those that support different IP versions,
different codecs, or that are in different address realms. Operators different codecs, or that are in different address realms. Operators
have a requirement and a strong motivation for performing capability have a requirement and a strong motivation for performing capability
mismatch fixing, so that they can provide transparent communication mismatch fixing, so that they can provide transparent communication
across different domains. In some cases different SIP extensions or across different domains. In some cases different SIP extensions or
methods to implement the same SIP application (like monitoring methods to implement the same SIP application (like monitoring
session liveness, call history/diversion etc) may also be interworked session liveness, call history/diversion etc) may also be interworked
through the SBC. through the SBC.
3.3.2. Architectural Issues 3.3.2. Architectural Issues
skipping to change at page 13, line 36 skipping to change at page 13, line 38
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
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=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 this
scenario the SBC inserts Record-Route and Via headers, and rewrites scenario the SBC inserts Record-Route and Via headers, and rewrites
the 'c' line from the sessions descriptor. Figure 9 shows the the 'c' line from the sessions descriptor. Figure 9 shows the
request after the capability mismatch adjustment. 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=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. agent and a proxy/registrar and, possibly, any other user-agent. The
primary purpose of NAT traversal function is to keep up a control
connection to user-agents behind NATs. This can, for example, be
achieved by generating periodic network traffic that keeps bindings
in NATs alive. SBCs' NAT traversal function is required in scenarios
where the NAT is outside the SBC (i.e., not in cases where SBC itself
acts as a NAT).
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
skipping to change at page 14, line 51 skipping to change at page 15, line 8
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.
Operators implement this functionality in an SBC instead of in the
registrar for several reasons: (i) preventing packets from
unregistered users to prevent chances of DoS attack, (ii)
prioritization and/or re-routing of traffic (based on user or
service, like E911) as it enters the network, and (iii) performing a
load balancing function or reducing the load on other network
equipment.
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 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 when end-to-end This approach to NAT traversal does not work if end-to-end
confidentiality or integrity-protection is used. The SBC would be confidentiality or integrity-protection mechanisms are used (e.g.,
seen as a MitM modifying the messages between the user-agent and the S/MIME). The SBC would be seen as a MitM modifying the messages
registrar. 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 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. Typically SBCs do not have any maintain the NAT binding. Typically SBCs do not have any
deterministic method for choosing a suitable value. deterministic method for choosing a suitable value. However, SBCs
can just use a sub-optimal, relatively small value which usually
works.
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 Registrar, and the SBC receives the registration response shown in
Figure 10. 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
skipping to change at page 16, line 13 skipping to change at page 16, line 13
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 need to be taken in order to enable the Naturally also other measures could be taken in order to enable the
NAT traversal, but this example illustrates only one mechanism for NAT traversal (e.g., non-SIP keepalive messages), but this example
preserving the SIP related NAT bindings. illustrates only one mechanism for preserving the SIP-related NAT
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.
skipping to change at page 16, line 43 skipping to change at page 16, line 44
Access control can be applied either only to the signaling, or to Access control can be applied either only to the signaling, or to
both the signaling and media. If it is applied only to the both the signaling and media. If it is applied only to the
signaling, then the SBC might behave as a proxy server. If access signaling, then the SBC might behave as a proxy server. If access
control is applied to both the signaling and media, then the SBC control is applied to both the signaling and media, then the SBC
behaves in a similar manner as explained in Section 3.2. A key part behaves in a similar manner as explained in Section 3.2. A key part
of media-layer access control is that only media for authorized of media-layer access control is that only media for authorized
sessions is allowed to pass through the SBC and/or associated media sessions is allowed to pass through the SBC and/or associated media
relay devices. relay devices.
Operators implement some functionalities, like NAT traversal for
example, in an SBC instead of other elements in the inner network for
several reasons: (i) preventing packets from unregistered users to
prevent chances of DoS attack, (ii) prioritization and/or re-routing
of traffic (based on user or service, like E911) as it enters the
network, and (iii) performing a load balancing function or reducing
the load on other network equipment.
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 usage 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
Since the SBC needs to handle all SIP messages, this function has Since the SBC needs to handle all SIP messages, this function has
scalability implications. In addition, the SBC is a single point of scalability implications. In addition, the SBC is a single point of
failure from an architectural point of view. Although, in practice, failure from an architectural point of view. Although, in practice,
many current SBCs have the capability to support redundant many current SBCs have the capability to support redundant
skipping to change at page 18, line 5 skipping to change at page 18, line 35
| | | | | |
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.
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 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) that they had previously
agreed on. agreed on.
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 clients. Operators may wish to support protocol fully-standard compliant or badly implemented clients. Operators may
repair, if they want to support as many clients as possible. It is wish to support protocol repair, if they want to support as many
noteworthy, that this function affects only the signaling component clients as possible. It is noteworthy, that this function affects
of an SBC, and that protocol repair function is not the same as only the signaling component of an SBC, and that the protocol repair
protocol conversion. function is not the same as protocol conversion (i.e., making
translation between two completely different protocols).
3.6.2. Architectural Issues 3.6.2. Architectural Issues
In most cases, this function can be seen as being compatible with SIP In most cases, this function can be seen as being compatible with SIP
architectural principles, and it does not violate the end-to-end architectural principles, and it does not violate the end-to-end
model of SIP. The SBC repairing protocol messages behaves as a proxy model of SIP. The SBC repairing protocol messages behaves as a proxy
server that is liberal in what it accepts and strict in what it server that is liberal in what it accepts and strict in what it
sends. sends.
A similar problem related to increasing complexity, as explained in A similar problem related to increasing complexity, as explained in
skipping to change at page 18, line 49 skipping to change at page 19, line 33
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 re-write the 'lr' parameter
on the Via header field into the form 'lr=true', in order to support on the Via header field into the form 'lr=true', in order to support
some older, non-standard SIP stacks. It could also remove excess some older, badly implemented SIP stacks. It could also remove
white spaces to make the SIP message more human readable. excess 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 is used only on the network. This is the case when media encryption (e.g., Secure
the access network (outer network) side and the media is carried Real-time Transport Protocol (SRTP)) is used only on the access
unencrypted in the inner network. Operators may have an obligation network (outer network) side and the media is carried unencrypted in
to provide the ability to do legal interception, while they still the inner network. Operators may have an obligation to provide the
want to give their customers the ability to encrypt media in the ability to do legal interception, while they still want to give their
access network. This leads to a situation where operators have a customers the ability to encrypt media in the access network. This
requirement to perform media encryption function. leads to a situation where operators have a 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. 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
skipping to change at page 20, line 39 skipping to change at page 20, line 52
| 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 UAS replies with
a 200 OK response, the SBCs inject themselves in the returning media a 200 OK response and the SBCs inject themselves in the returning
path. After signaling the media start flowing, and both SBCs are media path. After signaling the media starts flowing, and both SBCs
performing media encryption and decryption. are performing 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. The derived that break the principles of SIP in one way or another. 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. SIP (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 without user through intermediaries. Currently this is done without user
consent by modifying session descriptors, which is against consent by modifying session descriptors, which is against
the principles of SIP. the principles of SIP (see Section 3.2, Section 3.4,
Section 3.5, and Section 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/Packet Cable fulfill on complex mismatch cases, like the 3GPP/SIP [1]
mismatch. Currently this is done by modifying SIP messages, network mismatch. Currently this is done by modifying SIP
which violates end-to-end security. messages, which violates end-to-end security (see Section 3.3
and Section 3.6).
Req-1 and Req-3 does not have an exiting solution today. There is Req-1 and Req-3 do not have an exiting solution today. There is
ongoing work in the IETF for addressing Req-2, such as SIP session ongoing work in the IETF for addressing Req-2, such as SIP session
policies, Traversal Using Relays around NAT (TURN), and Interactive policies, Traversal Using Relays around NAT (TURN), and Interactive
Connectivity Establishment (ICE). Nonetheless, future work is needed Connectivity Establishment (ICE). Nonetheless, future work is needed
in order to develop solutions to these requirements. in order to develop solutions to these requirements.
It is noteworthy that a subset of the functions of SBCs will remain
as non-standardized functions, because it is not reasonable, or
feasible to develop a standardized solutions to replace them.
Examples from this kind of functions are the ability to enforce the
usage of a specific codec and the protocol repair (see Section 3.6)
functionality.
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. interpret the actions taken by an SBC as a MitM attack. SBCs modify
SIP messages because it allows them to, for example, protect elements
in the inner network from direct attacks.
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 or an SBC
on the path is performing some other function. on the path is performing some other function. SBCs place themselves
on the media path because it allows them to, for example, perform
legal interception.
On a general level SBCs prevent the use of end-to-end authentication.
This is because SBCs need to be able to perform actions that look
like MitM attacks, and in order for user agents to communicate, they
must allow those type of attacks. It other words, user agents can
not use end-to-end security. This is especially harmful because also
other network element, besides SBCs, are then able to do similar
attacks.
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. IANA Considerations
skipping to change at page 23, line 33 skipping to change at page 24, line 14
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. Ditech Networks Inc.
Suite 200, 1167 Kensington Cres NW 825 E Middlefield Rd
Calgary, Alberta T2N 1X7 Mountain View, CA
Canada US
Email: ahawrylyshen@ditechnetworks.com 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
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 50 change blocks. 
110 lines changed or deleted 151 lines changed or added

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