From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7092.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc7092.txt (limited to 'doc/rfc/rfc7092.txt') 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] + -- cgit v1.2.3