doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc7092.txt b/doc/rfc/rfc7092.txt
new file mode 100644
index 0000000..d631099
--- /dev/null
+++ b/doc/rfc/rfc7092.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         H. Kaplan
+Request for Comments: 7092                                        Oracle
+Category: Informational                                       V. Pascual
+ISSN: 2070-1721                                                   Quobis
+                                                           December 2013
+
+
+A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents
+
+Abstract
+
+   In many SIP deployments, SIP entities exist in the SIP signaling path
+   between the originating and final terminating endpoints, which go
+   beyond the definition of a SIP proxy, performing functions not
+   defined in Standards Track RFCs.  The only term for such devices
+   provided in RFC 3261 is for a Back-to-Back User Agent (B2BUA), which
+   is defined as the logical concatenation of a SIP User Agent Server
+   (UAS) and User Agent Client (UAC).
+
+   There are numerous types of SIP B2BUAs performing different roles in
+   different ways; for example, IP Private Branch Exchanges (IPBXs),
+   Session Border Controllers (SBCs), and Application Servers (ASs).
+   This document identifies several common B2BUA roles in order to
+   provide taxonomy other documents can use and reference.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7092.
+
+
+
+
+
+
+
+
+
+
+
+Kaplan & Pascual              Informational                     [Page 1]
+
+RFC 7092                   Taxonomy of B2BUAs              December 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 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.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  B2BUA Role Types  . . . . . . . . . . . . . . . . . . . . . .   3
+     3.1.  Signaling Plane B2BUA Roles . . . . . . . . . . . . . . .   4
+       3.1.1.  Proxy-B2BUA . . . . . . . . . . . . . . . . . . . . .   4
+       3.1.2.  Signaling-only  . . . . . . . . . . . . . . . . . . .   4
+       3.1.3.  SDP-Modifying Signaling-only  . . . . . . . . . . . .   5
+     3.2.  Signaling/Media Plane B2BUA Roles . . . . . . . . . . . .   5
+       3.2.1.  Media Relay . . . . . . . . . . . . . . . . . . . . .   5
+       3.2.2.  Media Aware . . . . . . . . . . . . . . . . . . . . .   6
+       3.2.3.  Media Termination . . . . . . . . . . . . . . . . . .   6
+   4.  Mapping SIP Device Types to B2BUA Roles . . . . . . . . . . .   6
+     4.1.  SIP PBXs and Softswitches . . . . . . . . . . . . . . . .   6
+     4.2.  Application Servers . . . . . . . . . . . . . . . . . . .   7
+     4.3.  Session Border Controllers  . . . . . . . . . . . . . . .   7
+     4.4.  Transcoders . . . . . . . . . . . . . . . . . . . . . . .   7
+     4.5.  Conference Servers  . . . . . . . . . . . . . . . . . . .   8
+     4.6.  P-CSCF and IBCF Functions . . . . . . . . . . . . . . . .   8
+     4.7.  S-CSCF Function . . . . . . . . . . . . . . . . . . . . .   8
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
+   6.  Informative References  . . . . . . . . . . . . . . . . . . .   9
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kaplan & Pascual              Informational                     [Page 2]
+
+RFC 7092                   Taxonomy of B2BUAs              December 2013
+
+
+1.  Introduction
+
+   In current SIP deployments, there are numerous forms of Back-to-Back
+   User Agents (B2BUAs), operating at various levels of transparency and
+   for various purposes, with widely varying behavior from a SIP
+   perspective.  Some act as pure SIP proxies and only change to the
+   role of B2BUA in order to generate BYEs to terminate dead sessions.
+   Some are full User Agent stacks with only high-level event and
+   application logic binding the User Agent Server (UAS) and User Agent
+   Client (UAC) sides.  Some B2BUAs operate only in the SIP signaling
+   plane, while others participate in the media plane as well.
+
+   As more SIP domains are deployed and interconnected, the probability
+   of a single SIP session crossing multiple B2BUAs at both the
+   signaling and media planes increases significantly.
+
+   This document provides a taxonomy of several common B2BUA roles so
+   that other documents may refer to them using their given names
+   without redefining them in each document.
+
+2.  Terminology
+
+   The following terms are defined in [RFC3261], Section 6.
+
+   B2BUA:   a SIP Back-to-Back User Agent, which is the logical
+            combination of a User Agent Server (UAS) and User Agent
+            Client (UAC).
+
+   UAS:     a SIP User Agent Server.
+
+   UAC:     a SIP User Agent Client.
+
+3.  B2BUA Role Types
+
+   Within the context of this document, the classification refers to a
+   B2BUA role, not a particular system type.  A given system type may
+   change its role in the middle of a SIP session, for example, when a
+   stateful proxy tears down a session by generating BYEs or when an SBC
+   [RFC5853] performs transcoding or REFER termination.
+
+   Furthermore, this document defines "B2BUA" following the definition
+   provided in [RFC3261], which is the logical concatenation of a UAS
+   and UAC.  A typical centralized conference server, for example, is
+   not a B2BUA because it is the target UAS of multiple UACs, whereby
+   the UACs individually and independently initiate separate SIP
+   sessions to the central conference server.  Likewise, a third-party
+   call control transcoder, as described in Section 3.1 of [RFC5369], is
+
+
+
+
+Kaplan & Pascual              Informational                     [Page 3]
+
+RFC 7092                   Taxonomy of B2BUAs              December 2013
+
+
+   not a B2BUA, whereas an inline (conference bridge) transcoder based
+   on [RFC5370] is a B2BUA.
+
+3.1.  Signaling Plane B2BUA Roles
+
+   A signaling plane B2BUA is one that operates only on the SIP message
+   protocol layer and only with SIP messages and headers but not with
+   the media itself in any way.  This implies that it does not modify
+   the Session Description Protocol (SDP) bodies, although it may save
+   them and/or operate on other MIME body types.  This category is
+   further subdivided into specific roles as described in this section.
+
+   It should be noted that there is a large variety of modifications
+   made by "signaling plane B2BUAs".
+
+3.1.1.  Proxy-B2BUA
+
+   A Proxy-B2BUA is one that appears, from a SIP perspective, to be a
+   SIP proxy based on [RFC3261] and its extensions, except that it
+   maintains a sufficient dialog state to generate in-dialog SIP
+   messages on its own and does so in specific cases.  The most common
+   example of this is a SIP proxy that can generate BYE requests to tear
+   down a dead session.
+
+   A Proxy-B2BUA does not modify the received header fields such as To,
+   From, or Contact, and it only modifies the Via and Record-Route
+   header fields following the rules in [RFC3261] and its extensions.
+   If a Proxy-B2BUA can generate in-dialog messages, then it will also
+   need to modify the CSeq header after it has generated its own.  A
+   Proxy-B2BUA neither modifies nor inspects MIME bodies (including
+   SDP), does not have any awareness of media, will forward any method
+   type, etc.
+
+3.1.2.  Signaling-only
+
+   A Signaling-only B2BUA is one that operates at the SIP layer but in
+   ways beyond those of [RFC3261] proxies, even for normally forwarded
+   requests.  For example, such a B2BUA might replace the Contact URI,
+   modify or remove all Via and Record-Route headers, modify the To and
+   From header fields, modify or inspect specific MIME bodies, etc.  No
+   SIP header field is guaranteed to be copied from the received request
+   on the UAS side to the generated request on the UAC side.
+
+   An example of such a B2BUA would be some form of an Application
+   Server and a PBX, such as a server that locally processes REFER
+   requests and generates new INVITEs on behalf of the REFER's target.
+   Another example would be a privacy service proxy [RFC3323] performing
+   the 'header' privacy function.
+
+
+
+Kaplan & Pascual              Informational                     [Page 4]
+
+RFC 7092                   Taxonomy of B2BUAs              December 2013
+
+
+3.1.3.  SDP-Modifying Signaling-only
+
+   An SDP-Modifying Signaling-only B2BUA is one that operates in the
+   signaling plane only and is not in the media path, but it does modify
+   SDP bodies and is thus aware of and understands SDP syntax and
+   semantics.  In some cases, some Application Servers and PBXs act in
+   this role, for example, to remove certain codec choices or merge two
+   media endpoints into one SDP offer.
+
+   These B2BUAs don't do anything that changes the path that the media
+   takes (in particular, they don't insert themselves on the media
+   path), but they may make SDP changes that affect what is sent on the
+   media plane.
+
+3.2.  Signaling/Media Plane B2BUA Roles
+
+   A signaling/media plane B2BUA is one that operates at both the SIP
+   and media planes and not only on SIP messages but also on SDP and
+   potentially the Real-time Transport Protocol (RTP) / the Real-Time
+   Control Protocol (RTCP) [RFC3550] or other media.  Such a B2BUA may
+   or may not replace the Contact URI, modify or remove all Via and
+   Record-Route headers, modify the To and From header fields, etc.  No
+   SIP header field is guaranteed to be copied from the received request
+   on the UAS side to the generated request on the UAC side, and SDP
+   will also be modified.
+
+   An example of such a B2BUA would be a Session Border Controller (SBC)
+   performing the functions defined in [RFC5853], a B2BUA transcoder as
+   defined in [RFC5370], a rich-ringtone Application Server, or a
+   recording system.  Another example would be a privacy service proxy
+   [RFC3323] performing the 'session' privacy function.
+
+   Note that a signaling/media plane B2BUA need not be instantiated in a
+   single physical system, but it may be decomposed into separate
+   signaling and media functions.
+
+   The signaling/media plane B2BUA category is further subdivided into
+   specific roles as described in this section.
+
+3.2.1.  Media Relay
+
+   A B2BUA that performs a media-relay role is one that terminates the
+   media plane at the IP and transport (UDP/TCP) layers on its UAS and
+   UAC sides, but neither modifies nor restricts which forms of payload
+   are carried within the packets.  Rather, the payload is transparently
+   copied from one side to the other.  Such a role may or may not
+   support only UDP, only TCP, both UDP and TCP, as well as other
+   transport types.  It may also involve policing the IP packets to fit
+
+
+
+Kaplan & Pascual              Informational                     [Page 5]
+
+RFC 7092                   Taxonomy of B2BUAs              December 2013
+
+
+   within a bandwidth limit or converting from IPv4 to IPv6, or vice
+   versa.  This is typically similar to NAT behavior, except a NAT
+   operating in both directions on both the source and destination
+   information; it is often found as the default behavior in SBCs.
+
+3.2.2.  Media Aware
+
+   A B2BUA that performs a media-aware role is similar to a media relay
+   except that it inspects and potentially modifies the payload carried
+   in UDP or TCP (as it could be RTP or RTCP [RFC3550]), but it does not
+   at a codec or higher layer.  An example of such a role is a Secure
+   Real-time Transport Protocol (SRTP) [RFC3711] terminator, which does
+   not need to care about the RTP payload but does care about the RTP
+   header; or, a device that monitors RTCP for QoS information; or, a
+   device that multiplexes/demultiplexes RTP and RTCP packets on the
+   same 5-tuple.
+
+3.2.3.  Media Termination
+
+   A B2BUA that performs a media-termination role is one that operates
+   at the media payload layer, such as RTP/RTCP codec or the Message
+   Session Relay Protocol (MSRP) message layer and higher.  Such a role
+   may only terminate/generate specific RTP media, such as dual-tone
+   multi-frequency (DTMF) packets [RFC4733], or it may convert between
+   media codecs or act as a Back-to-Back MSRP [RFC4975] agent.  This is
+   the role performed by transcoders, conference servers based on
+   [RFC5366], etc.
+
+4.  Mapping SIP Device Types to B2BUA Roles
+
+   Although the B2BUA roles defined previously do not define system
+   types, as discussed in Section 3, some discussion of what common
+   system types perform which defined roles may be appropriate.  This
+   section provides such a 'mapping' for general cases to aid in
+   understanding of the roles.
+
+4.1.  SIP PBXs and Softswitches
+
+   SIP-enabled Private Branch Exchanges (SIP PBXs) and softswitches are
+   market category terms and are not specified in any standard.  In
+   general, they can perform every role described in this document at
+   any given time based on their architecture or local policy.  Some are
+   based on architectures that make them the equivalent of a SIP UAS and
+   UAC connected with a logical Primary Rate Interface (PRI) loopback;
+   others are built as a SIP proxy core with optional modules to "do
+   more".
+
+
+
+
+
+Kaplan & Pascual              Informational                     [Page 6]
+
+RFC 7092                   Taxonomy of B2BUAs              December 2013
+
+
+4.2.  Application Servers
+
+   Application Servers are a broad marketing term and are not specified
+   in any standard in general, although the Third Generation Partnership
+   Project (3GPP) and other organizations specify some specific
+   Application Server functions and behaviors.  Common examples of
+   Application Server functions are message-waiting indicators (MWIs),
+   Find Me/Follow Me services, privacy services, call center Automatic
+   Call Distributor (ACD) services, call screening, and Voice Call
+   Continuity (VCC) services.  Some only operate in the signaling plane
+   in either Proxy-B2BUA or Signaling-only B2BUA roles; others operate
+   as full Media-termination B2BUAs, such as when providing Interactive
+   Voice Recognition (IVR), rich ringtones, or integrated voicemail
+   services.
+
+4.3.  Session Border Controllers
+
+   Session Border Controllers (SBCs) are a market category term and are
+   not specified in any standard.  Some of the common functions
+   performed by SBCs are described in [RFC5853], but in general, they
+   can perform every role described in this document at any given time
+   based on local policy.  By default, most SBCs are either Media-relay
+   or Media-aware B2BUAs and replace the Contact URI; remove the Via and
+   Record-Route headers; modify Call-ID, To, From, and various other
+   headers; and modify SDP.  Some SBCs remove all headers, all bodies,
+   and reject all method types unless explicitly allowed by local
+   policy; other SBCs pass all such elements through unless explicitly
+   forbidden by local policy.
+
+4.4.  Transcoders
+
+   Transcoders perform the function of transcoding one audio or video
+   media codec type to another, such as G.711 to G.729.  As such, they
+   perform the Media-termination role, although they may only terminate
+   media in specific cases of codec mismatch between the two ends.
+   Although [RFC5369] and [RFC5370] define two types of SIP transcoders,
+   in practice, a popular variant of the inline conference bridge model
+   [RFC5370] is to behave as a SIP B2BUA without using the resource-list
+   mechanism but rather simply routing a normal INVITE request through a
+   B2BUA with a built-in transcoder.  SIP transcoder architectures are
+   based on everything from SIP media servers and SBCs to looped-back
+   Time Division Multiplexing (TDM) gateways, and thus run the gamut
+   from replacing only specific headers/bodies and SDP content needed to
+   perform their function to replacing almost all SIP headers and SDP
+   content.  Some transcoders save and remove SDP offers in INVITEs from
+   the UAC, and wait for an offer in the response from the UAS, similar
+
+
+
+
+
+Kaplan & Pascual              Informational                     [Page 7]
+
+RFC 7092                   Taxonomy of B2BUAs              December 2013
+
+
+   to a Third Party Call Control (3PCC) model; others just insert
+   additional codecs in SDP offers and only transcode if the inserted
+   codec(s) is selected in the answer.
+
+4.5.  Conference Servers
+
+   In general, conference servers do not fall under the term "B2BUA" as
+   defined by this document, since typically they involve multiple SIP
+   UACs initiating independent SIP sessions to the single conference
+   UAS.  However, a conference server supporting [RFC5366], whereby the
+   received INVITE triggers the conference focus UAS to initiate
+   multiple INVITEs as a UAC, would be in a Media-termination B2BUA role
+   when performing that function.
+
+4.6.  P-CSCF and IBCF Functions
+
+   The Proxy-Call Session Control Function (P-CSCF) and the
+   Interconnection Border Control Function (IBCF) are defined by 3GPP
+   [IMS] standards, and when coupled with the IP Multimedia Subsystems
+   (IMS) media plane gateways (IMS Access Gateway (AGW), Transition
+   Gateway (TrGW), etc.), they typically form a logical Media-relay or
+   Media-aware B2BUA role.
+
+4.7.  S-CSCF Function
+
+   The Serving-Call Session Control Function (S-CSCF) is defined by 3GPP
+   [IMS] standards and typically follows a Proxy-B2BUA role.
+
+5.  Security Considerations
+
+   Security risks are specific to each type of B2BUA, so little can be
+   said in general.  Of course, adding extra systems in the
+   communication path creates extra points of attack, reduces or
+   eliminates the ability to perform end-to-end encryption, decreases
+   the privacy of SIP communications, and complicates trust models.
+   Thus, every B2BUA design requires particular attention to security
+   analysis.
+
+   A few general points can be made:
+
+   1.  The B2BUA processing of SDP and media packets is an impediment to
+       the deployment of end-to-end SRTP and reduces the ability to
+       deploy new, stronger forms of SRTP key exchange.
+
+   2.  The ability for B2BUAs to modify any SIP header field value and
+       body impacts the ability to deploy SIP identity and message
+       integrity.
+
+
+
+
+Kaplan & Pascual              Informational                     [Page 8]
+
+RFC 7092                   Taxonomy of B2BUAs              December 2013
+
+
+   3.  The management and configuration mechanisms of B2BUAs are a
+       tempting point of attack and must be strongly defended.
+
+   Further security considerations related to the functionality
+   described in this document are addressed in the relevant references.
+
+6.  Informative References
+
+   [RFC3261]  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.
+
+   [RFC3323]  Peterson, J., "A Privacy Mechanism for the Session
+              Initiation Protocol (SIP)", RFC 3323, November 2002.
+
+   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
+              Jacobson, "RTP: A Transport Protocol for Real-Time
+              Applications", STD 64, RFC 3550, July 2003.
+
+   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+              RFC 3711, March 2004.
+
+   [RFC4733]  Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
+              Digits, Telephony Tones, and Telephony Signals", RFC 4733,
+              December 2006.
+
+   [RFC4975]  Campbell, B., Mahy, R., and C. Jennings, "The Message
+              Session Relay Protocol (MSRP)", RFC 4975, September 2007.
+
+   [RFC5366]  Camarillo, G. and A. Johnston, "Conference Establishment
+              Using Request-Contained Lists in the Session Initiation
+              Protocol (SIP)", RFC 5366, October 2008.
+
+   [RFC5369]  Camarillo, G., "Framework for Transcoding with the Session
+              Initiation Protocol (SIP)", RFC 5369, October 2008.
+
+   [RFC5370]  Camarillo, G., "The Session Initiation Protocol (SIP)
+              Conference Bridge Transcoding Model", RFC 5370, October
+              2008.
+
+   [RFC5853]  Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen,
+              A., and M. Bhatia, "Requirements from Session Initiation
+              Protocol (SIP) Session Border Control (SBC) Deployments",
+              RFC 5853, April 2010.
+
+
+
+
+
+Kaplan & Pascual              Informational                     [Page 9]
+
+RFC 7092                   Taxonomy of B2BUAs              December 2013
+
+
+   [IMS]      3GPP, "IP Multimedia Subsystem (IMS); Stage 2, 3GPP TS
+              23.228", Version 12.2.0, September 2013.
+
+Authors' Addresses
+
+   Hadriel Kaplan
+   Oracle
+
+   EMail: hadriel.kaplan@oracle.com
+
+
+   Victor Pascual
+   Quobis
+
+   EMail: victor.pascual@quobis.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kaplan & Pascual              Informational                    [Page 10]
+