draft-ietf-sipping-sbc-funcs-07.txt   draft-ietf-sipping-sbc-funcs-08.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: April 26, 2009 R. Penfield Expires: July 9, 2009 R. Penfield
Acme Packet Acme Packet
A. Hawrylyshen A. Hawrylyshen
Ditech Networks Inc. Ditech Networks Inc.
M. Bhatia M. Bhatia
3CLogic 3CLogic
October 23, 2008 January 5, 2009
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-07.txt draft-ietf-sipping-sbc-funcs-08.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 April 26, 2009. This Internet-Draft will expire on July 9, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
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 48 skipping to change at page 4, line 4
3.7.2. Architectural Issues . . . . . . . . . . . . . . . . . 21 3.7.2. Architectural Issues . . . . . . . . . . . . . . . . . 21
3.7.3. Example . . . . . . . . . . . . . . . . . . . . . . . 21 3.7.3. Example . . . . . . . . . . . . . . . . . . . . . . . 21
4. Derived Requirements for Future SIP Standardization Work . . . 22 4. Derived Requirements for Future SIP Standardization Work . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Normative References . . . . . . . . . . . . . . . . . . . 24 8.1. Normative References . . . . . . . . . . . . . . . . . . . 24
8.2. Informational References . . . . . . . . . . . . . . . . . 24 8.2. Informational References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 26
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 9, line 39 skipping to change at page 9, line 39
SBC act as a B2BUA (Back-to-Back User Agent) and remove all traces of SBC act as a B2BUA (Back-to-Back User Agent) and remove all traces of
topology information (e.g., Via and Record-Route entries) from topology information (e.g., Via and Record-Route entries) from
outgoing messages. outgoing messages.
Imagine the following example scenario: The SBC Imagine the following example scenario: The SBC
(p4.domain.example.com) receives an INVITE request from the inner (p4.domain.example.com) receives an INVITE request from the inner
network, which in this case is an operator network. The received SIP network, which in this case is an operator network. The received SIP
message is shown in Figure 4. message is shown in Figure 4.
INVITE sip:callee@u2.domain.example.com SIP/2.0 INVITE sip:callee@u2.domain.example.com SIP/2.0
Via: SIP/2.0/UDP p3.middle.example.com;branch=z9hG4bK48jq9w9174131.1 Via: SIP/2.0/UDP p3.middle.example.com;branch=z9hG4bK48jq9w174131.1
Via: SIP/2.0/UDP p2.example.com;branch=z9hG4bK18an6i9234172.1 Via: SIP/2.0/UDP p2.example.com;branch=z9hG4bK18an6i9234172.1
Via: SIP/2.0/UDP p1.example.com;branch=z9hG4bK39bn2e5239289.1 Via: SIP/2.0/UDP p1.example.com;branch=z9hG4bK39bn2e5239289.1
Via: SIP/2.0/UDP u1.example.com;branch=z9hG4bK92fj4u7283927.1 Via: SIP/2.0/UDP u1.example.com;branch=z9hG4bK92fj4u7283927.1
Contact: sip:caller@u1.example.com Contact: sip:caller@u1.example.com
Record-Route: <sip:p3.middle.example.com;lr> Record-Route: <sip:p3.middle.example.com;lr>
Record-Route: <sip:p2.example.com;lr> Record-Route: <sip:p2.example.com;lr>
Record-Route: <sip:p1.example.com;lr> Record-Route: <sip:p1.example.com;lr>
Figure 4: INVITE Request Prior to Topology Hiding Figure 4: INVITE Request Prior to Topology Hiding
Then the SBC performs a topology hiding function. In this scenario, Then the SBC performs a topology hiding function. In this scenario,
the SBC removes and stores all existing Via and Record-Route headers, the SBC removes and stores all existing Via and Record-Route headers,
and then inserts Via and Record-Route header fields with its own SIP and then inserts Via and Record-Route header fields with its own SIP
URI. After the topology hiding function, the message could appear as URI. After the topology hiding function, the message could appear as
shown in Figure 5. shown in Figure 5.
INVITE sip:callee@u2.domain.example.com SIP/2.0 INVITE sip:callee@u2.domain.example.com SIP/2.0
Via: SIP/2.0/UDP p4.domain.example.com;branch=z9hG4bK92es3w1230129.1 Via: SIP/2.0/UDP p4.domain.example.com;branch=z9hG4bK92es3w230129.1
Contact: sip:caller@u1.example.com Contact: sip:caller@u1.example.com
Record-Route: <sip:p4.domain.example.com;lr> Record-Route: <sip:p4.domain.example.com;lr>
Figure 5: INVITE Request After Topology Hiding Figure 5: INVITE Request After Topology Hiding
Like a regular proxy server that inserts a Record-Route entry, the Like a regular proxy server that inserts a Record-Route entry, the
SBC handles every single message of a given SIP dialog. If the SBC SBC handles every single message of a given SIP dialog. If the SBC
loses state (e.g., SBC restarts for some reason), it may not be able loses state (e.g., SBC restarts for some reason), it may not be able
to route messages properly (note: some SBCs preserve the state to route messages properly (note: some SBCs preserve the state
information also on restart). For example, if the SBC removes "Via" information also on restart). For example, if the SBC removes "Via"
skipping to change at page 11, line 15 skipping to change at page 11, line 15
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, or to ensure that subscribers are using only of Service) level, or to ensure that subscribers are using only
allowed codecs. It is noteworthy that the SBCs do not have direct allowed codecs. It is noteworthy that the SBCs do not have direct
ties to routing topology and they do not, for example, change ties to routing topology and they do not, for example, change
bandwidth reservations on Traffic Engineering (TE) tunnels. bandwidth reservations on Traffic Engineering (TE) tunnels, nor they
have direct interaction with routing protocol.
Some operators do not want to manage the traffic, but only to monitor Some operators do not want to manage the traffic, but only to monitor
it for collecting statistics and making sure that they are able to it for collecting statistics and making sure that they are able to
meet any business service level agreements with their subscribers meet any business service level agreements with their subscribers
and/or partners. The protocol techniques, from the SBC's viewpoint, and/or partners. The protocol techniques, from the SBC's viewpoint,
needed for monitoring media traffic are the same as for managing needed for monitoring media traffic are the same as for managing
media traffic. 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
skipping to change at page 24, line 40 skipping to change at page 24, line 40
8.2. Informational References 8.2. Informational References
[5] 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.
[6] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [6] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[7] Munakata, M., Schubert, S., and T. Ohba, "UA-Driven Privacy [7] Munakata, M., Schubert, S., and T. Ohba, "UA-Driven Privacy
Mechanism for SIP", draft-ietf-sip-ua-privacy-01 (work in Mechanism for SIP", draft-ietf-sip-ua-privacy-03 (work in
progress), February 2008. progress), October 2008.
[8] Eggert, L. and G. Fairhurst, "Guidelines for Application [8] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for
Designers on Using Unicast UDP", Application Designers", BCP 145, RFC 5405, November 2008.
draft-ietf-tsvwg-udp-guidelines-08 (work in progress),
June 2008.
Authors' Addresses Authors' Addresses
Jani Hautakorpi (editor) Jani Hautakorpi (editor)
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Jani.Hautakorpi@ericsson.com Email: Jani.Hautakorpi@ericsson.com
skipping to change at page 26, line 4 skipping to change at line 1131
Email: alan.ietf@polyphase.ca Email: alan.ietf@polyphase.ca
Medhavi Bhatia Medhavi Bhatia
3CLogic 3CLogic
9700 Great Seneca Hwy. 9700 Great Seneca Hwy.
Rockville, MD 20850 Rockville, MD 20850
US US
Email: mbhatia@3clogic.com Email: mbhatia@3clogic.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
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
http://www.ietf.org/ipr.
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
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 13 change blocks. 
19 lines changed or deleted 23 lines changed or added

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