[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 draft-ietf-sipping-sbc-funcs

SIPPING Working Group                                 J. Hautakorpi, Ed.
Internet-Draft                                              G. Camarillo
Expires: January 19, 2006                                       Ericsson
                                                               M. Bhatia
                                                  NexTone Communications
                                                             R. Penfield
                                                             Acme Packet
                                                          A. Hawrylyshen
                                       Ditech Communications Corporation
                                                           July 18, 2005

   SIP (Session Initiation Protocol)-Unfriendly Functions in Current
                      Communication Architectures

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   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
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 19, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   This document gives an overview to SIP-unfriendly functions in

Hautakorpi, et al.      Expires January 19, 2006                [Page 1]

Internet-Draft          SIP-Unfriendly Functions               July 2005

   current communication architectures.  These functions are generally
   implemented in SBCs (Session Border Controllers).  The purpose of
   this document is to help the IETF community understand what SIP-
   unfriendly functions can be found in existing networks so that the
   appropriate working groups can decide whether or not new standard
   solutions need to be developed to provide such functionality (or a
   subset of it) in a standard, SIP-friendly way.  Working groups may
   also develop recommendations on how to use existing standard
   mechanisms to provide such functionality.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Background on SBCs . . . . . . . . . . . . . . . . . . . . . .  3
   3.  SIP-Unfriendly Functions . . . . . . . . . . . . . . . . . . .  4
     3.1   Topology Hiding  . . . . . . . . . . . . . . . . . . . . .  4
     3.2   Media Traffic Shaping  . . . . . . . . . . . . . . . . . .  5
     3.3   Fixing Capability Mismatches . . . . . . . . . . . . . . .  6
     3.4   NAT Traversal  . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     7.1   Normative References . . . . . . . . . . . . . . . . . . .  7
     7.2   Informational References . . . . . . . . . . . . . . . . .  8
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  8
       Intellectual Property and Copyright Statements . . . . . . . . 10

Hautakorpi, et al.      Expires January 19, 2006                [Page 2]

Internet-Draft          SIP-Unfriendly Functions               July 2005

1.  Introduction

   This document gives an overview to SIP [1] unfriendly functions in
   current communication architectures.  These functions are generally
   implemented in Session Border Controllers (SBCs).  The reason for
   this is that network policies are typically enforced at the edge of
   the network, and SBCs are typically located there.

   Of course, a typical SBC does not only implement SIP-unfriendly
   functions.  They usually implement a set of functions, some of which
   are perfectly legal from the SIP point of view.  However, this
   document focuses on those functions that break SIP somehow.

   Many existing SBCs use proprietary solutions because there is no
   standard solution for a given issue or because the standard solution
   does not fully meet the requirements of the network operator.  This
   document is intended to be taken as input by the IETF so that the
   appropriate working groups can decide whether or not new standard
   solutions need to be developed to provide the same functionality (or
   a subset of it) in a SIP-friendly way.  Working groups may also
   decide to develop recommendations on how to use existing standard
   mechanisms to provide such functionality.

2.  Background on SBCs

   The term SBC is pretty vague, since it is not standardized or defined
   anywhere.  Nodes that may be referred to as SBCs but do not implement
   SIP are outside the scope of this document.

   Even though many SBCs currently break things like end-to-end security
   and can impact feature negotiations, there is clearly a market for
   them.  Network operators need many of the features current SBCs
   provide and many times there are no standard mechanisms available to
   provide them in a better way.

   SIP-based SBCs typically handle both signaling and media, and often
   modify the session descriptions contained in SIP messages.
   Consequently, they are, by definition, B2BUAs (Back-to-Back User
   Agents).  The transparency of these B2BUAs varies depending on the
   functions they perform.  For example, some SBCs modify the session
   description carried in the message and insert a Record-Route entry.
   Other SBCs replace the value of the Contact header field with the
   SBCs address, and generate a new Call-ID and new To and From tags.

Hautakorpi, et al.      Expires January 19, 2006                [Page 3]

Internet-Draft          SIP-Unfriendly Functions               July 2005

                            |       SBC       |
                [signaling] |  +-----------+  |
               <------------|->| signaling |<-|---------->
                  outer     |  +-----------+  |  inner
                  network   |        |        |  network
                            |  +-----------+  |
               <------------|->|   media   |<-|---------->
                  [media]   |  +-----------+  |

                        Figure 1: SBC architecture

   Figure 1 shows the logical architecture of an SBC, which includes a
   signaling and a media component.  Typically SBCs are located between
   two networks.  In this document, the terms outer and inner network
   are used for describing these two networks.

   There are two typical deployment scenarios where SBCs are used.  The
   first one of them is a peering scenario, where the SBC is located
   between different-operators' networks.  The second deployment
   scenario is an access scenario, where the SBC is located between the
   access network and the operator's network.

3.  SIP-Unfriendly Functions

   This section examines SIP-unfriendly functions that are used in
   current communication networks.  Each subsection describes a
   particular function or feature, what is the operator's motivation for
   having it, how it is currently implemented, and why it breaks SIP.
   Each section also discusses the problems associated to that
   particular way of implementing it.  Providing suggestions for
   alternative, more SIP-friendly ways of implementing each of the
   functions is outside the scope of this document.

3.1  Topology Hiding

   Topology hiding consists of limiting the amount of topology
   information given to external parties.  Operators want to have this
   functionality because they do not want the IP addresses of their
   equipment (proxies, gateways, application servers, etc) to be exposed
   to outside parties.  This may be because they do not want to expose
   their equipment to DoS (Denial of Service) attacks or because they
   may use other carriers for certain traffic and do not want their
   customers to be aware of it.  In some environments, the operator's
   customers may wish to hide the addresses of their equipment or the
   SIP messages may contain private, non-routable addresses.

Hautakorpi, et al.      Expires January 19, 2006                [Page 4]

Internet-Draft          SIP-Unfriendly Functions               July 2005

   The current way of implementing topology consists of having an SBC
   act as a B2BUA (Back-to-Back User Agents) and remove all traces of
   topology information (e.g., Via and Record-Route entries) from
   outgoing messages.

   Like a regular proxy server that inserts a Record-Route entry, the
   SBC handles every single message of a given SIP dialog.  However,
   unlike the proxy server, if the SBC loses state (e.g., the SBC
   restarts for some reason), it will not be able to route messages
   properly.  For example, if the SBC removes Via entries from a request
   and then restarts losing state, the SBC will not be able to route
   responses to that request.

3.2  Media Traffic Shaping

   Media traffic shaping is the act of controlling media traffic.
   Operators have several reasons for having this functionality.
   Operators want to control the traffic they carry on their network.
   Traffic shaping helps them create different kinds of billing models
   (e.g., video telephony can be priced differently than voice-only
   calls).  Additionally, traffic shaping can be used to implement
   intercept capabilities (e.g., lawful intercept).

   Some operators do not actually want to reshape the traffic, but only
   to monitor it.  However, the SIP techniques needed for monitoring
   media traffic are the same as for reshaping media traffic.

   Currently, traffic shaping is performed in the following way.  The
   SBC behaves as a B2BUA and inserts itself, or some other entity under
   the operator's control, in the media path.  In practice, the SBC
   modifies the session descriptions carried in the SIP messages.  As a
   result, the SBC receives media from one user agent and relays it to
   the other in both directions.

   An example of traffic shaping is codec restriction.  The SBC
   restricts the codec set negotiated in offer/answer [2] exchange
   between the user agents.  After modifying the session descriptions,
   the SBC can check whether or not the media stream corresponds to what
   was negotiated in the offer/answer exchange.  If it differs, the SBC
   has the ability to terminate the media stream.

   Note SBCs can terminate media streams and SIP dialogs for a number of
   different reasons (e.g., in a situation where the subscriber runs out
   of credits or when a user agent loses radio coverage).

   The current way of implementing traffic shaping has some SIP-
   unfriendly aspects.  The SBC needs to access and modify the session
   descriptions (i.e., offers and answers) exchanged between the user

Hautakorpi, et al.      Expires January 19, 2006                [Page 5]

Internet-Draft          SIP-Unfriendly Functions               July 2005

   agents.  Consequently, this approach does not work if user agents
   encrypt or integrity-protect their message bodies end-to-end.  User
   agents do not have any way to distinguish the SBC actions from an
   attack by a MitM (Man-in-the-Middle).

   Furthermore, the SBC needs to understand the session description
   protocol and all the extensions used by the user agents.  This means
   that in order to use a new extension (e.g., an extension to implement
   a new service) or a new session description protocol, it is not
   enough with upgrading the user agents; SBCs in the network need also
   to be upgraded.  This fact may slow down service innovation.

   Additionally, the SBC may need to generate requests on its own (e.g.,
   a BYE request to terminate a SIP dialog).  This does not work when
   end-to-end authentication is in use.

3.3  Fixing Capability Mismatches

   SBCs fixing capability mismatches enable communications between user
   agents with different capabilities.  For example, user agents that
   support different IP versions, different codecs, or that are in
   different address realms.

   SBCs fixing capability mismatches insert a media element in the media
   path using the procedures described in Section 3.2.  Therefore, these
   SBCs have the same problems as SBCs performing traffic shaping: the
   SBC modifies SIP messages without explicit consent from any of the
   user agents.  This breaks end-to-end security and extension

   Additionally, SBCs may make wrong assumptions about the capabilities
   of the user agents.  When this happens, user agents with compatible
   capabilities may end up communicating via the SBC instead of doing it
   directly between them (e.g., the SBC assumes that a dual-stack user
   agent only supports IPv6).

3.4  NAT Traversal

   An SBC performing a NAT (Network Address Translator) traversal
   function for a user agent behind a NAT sits between the user agent
   and the registrar of the domain.  When the registrar receives a
   REGISTER request from the user agent and responds with a 200 (OK)
   response, the SBC modifies such a response decreasing the validity of
   the registration (i.e., the registration expires sooner).  This
   forces the user agent to send a new REGISTER to refresh the
   registration sooner that it would have done on receiving the original
   response from the registrar.  The REGISTER requests sent by the user
   agent refresh the binding of the NAT before the binding expires.

Hautakorpi, et al.      Expires January 19, 2006                [Page 6]

Internet-Draft          SIP-Unfriendly Functions               July 2005

   Note that the SBC does not need to relay all the REGISTER requests
   received from the user agent to the registrar.  The SBC can generate
   responses to REGISTER requests received before the registration is
   about to expire at the registrar.  Moreover, the SBC needs to
   deregister the user agent if this fails to refresh its registration
   in time, even if the registration at the registrar would still be

   Operators implement this functionality in an SBC instead of in the
   registrar because the SBC is supposed to have more information about
   the access the user agent is using.  Additionally, distributing this
   functionality helps offload the registrar.

   This approach to NAT traversal does not work when end-to-end
   confidentiality or integrity-protection is used.  The SBC would be
   seen as a MitM modifying the messages between the user agent and the

4.  Security Considerations

   Many of the functions this document describes have important security
   and privacy implications.  If the IETF decides to develop standard
   mechanisms to address those functions, security and privacy-related
   aspects will need to be taken into consideration.

5.  IANA Considerations

   This document has no IANA considerations.

6.  Acknowledgements

   The ad-hoc meeting about SBCs, held on Nov 9th 2004 at Washington DC
   during the 61st IETF meeting, provided valuable input to this
   document.  Special thanks goes also to Sridhar Ramachandran, Gaurav
   Kulshreshtha, and to Rakendu Devdhar.

7.  References

7.1  Normative References

   [1]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

   [2]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
        Session Description Protocol (SDP)", RFC 3264, June 2002.

Hautakorpi, et al.      Expires January 19, 2006                [Page 7]

Internet-Draft          SIP-Unfriendly Functions               July 2005

7.2  Informational References

Authors' Addresses

   Jani Hautakorpi (editor)
   Hirsalantie 11
   Jorvas  02420

   Email: Jani.Hautakorpi@ericsson.com

   Gonzalo Camarillo
   Hirsalantie 11
   Jorvas  02420

   Email: Gonzalo.Camarillo@ericsson.com

   Medhavi Bhatia
   NexTone Communications
   101 Orchard Ridge Drive
   Gaithersburg, MD  20878

   Email: mbhatia@nextone.com

   Robert F. Penfield
   Acme Packet
   71 Third Avenue
   Burlington, MA  01803

   Email: bpenfield@acmepacket.com

Hautakorpi, et al.      Expires January 19, 2006                [Page 8]

Internet-Draft          SIP-Unfriendly Functions               July 2005

   Alan Hawrylyshen
   Ditech Communications Corporation
   310, 602 - 11 Ave SW
   Calgary, Alberta  T2R 1J8

   Email: alan@jasomi.com

Hautakorpi, et al.      Expires January 19, 2006                [Page 9]

Internet-Draft          SIP-Unfriendly Functions               July 2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Hautakorpi, et al.      Expires January 19, 2006               [Page 10]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/