| STRAW Working Group | H. Kaplan |
| Internet-Draft | Oracle |
| Intended status: Informational | V. Pascual |
| Expires: April 24, 2014 | Quobis |
| October 21, 2013 |
A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents
draft-ietf-straw-b2bua-taxonomy-03
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 [RFC3261] 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 Back-to-Back User Agents, performing different roles in different ways. For Example IP-PBXs, Session Border Controllers (SBC) [RFC5853] and Application Servers (AS). This document identifies several common Back-to-Back User Agent roles, in order to provide taxonomy other documents can use and reference.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 24, 2014.
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.
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, and with widely varying behavior from a SIP protocol 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 get deployed and interconnected the probability of a single SIP session crossing multiple B2BUA's 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 re-defining them in each document.
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.
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 for example when an SBC 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 not a B2BUA; whereas an inline (conference bridge) transcoder based on [RFC5370] is a B2BUA.
A Signaling-plane B2BUA is one that operates only on the SIP message protocol layer, and only with SIP messages and headers but not the media itself in any way. This implies that it does not modify 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 B2BUA's"
A Proxy-B2BUA is one that appears, from a SIP protocol perspective, to be a SIP Proxy based on [RFC3261] and its extensions, except that it maintains 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 which can generate BYE requests to tear-down a dead session.
A Proxy-B2BUA does not modify the received header fields such as the To, From, or Contact, and 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.
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 Application Server and PBX, such as a server which locally processes REFER requests and generates new INVITEs on behalf of the REFER's target. Another example would be an [RFC3323] Privacy Service Proxy performing the 'header' privacy function.
An SDP-Modifying Signaling-only B2BUA is one that operates in the signaling plane only and is not in the media path, but does modify SDP bodies and is thus aware of and understands SDP syntax and semantics. Some Application Servers and PBXs act in this role in some cases, 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 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.
A Media-plane B2BUA is one that operates at both the SIP and media planes, not only on SIP messages but also SDP and potentially Real-time Transport Protocol (RTP) / 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 an [RFC3323] Privacy Service Proxy performing the 'session' privacy function.
Note that a Media-plane B2BUA need not be instantiated in a single physical system, but may be decomposed into separate signaling and media functions.
The Media-plane B2BUA category is further subdivided into specific roles as described in this section.
A B2BUA which 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 only support UDP or only TCP or both, as well as other transport types or not. Such a role may involve policing the IP packets to fit within a bandwidth limit, or converting from IPv4 to IPV6 or vice-versa. This is typically similar to a 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.
A B2BUA which 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 [RFC3550] RTP or RTCP) but it does not at a codec or higher layer. An example of such a role is an [RFC3711] SRTP terminator, which does not need to care about the RTP payload but does care about the RTP header; or a device which monitors RTCP for QoS information; or a device which multiplexes/de-multiplexes RTP and RTCP packets on the same 5-tuple.
A B2BUA which performs a media-termination role is one that operates at the media payload layer, such as RTP/RTCP codec or MSRP message layer and higher. Such a role may only terminate/generate specific RTP media, such as [RFC4733] DTMF packets, or it may convert between media codecs, or act as a Back-To-Back [RFC4975] MSRP agent. This is the role performed by transcoders, [RFC5366] based conference servers, etc.
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.
SIP-enabled Private Branch eXchanges (SIP PBXs) and Softswitches are market category terms, and 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 PRI loopback; others are built as a SIP Proxy core with optional modules to "do more".
Application Servers are a broad marketing term, and not specified in any standard in general, although 3GPP and other organizations specify some specific Application Server functions and behaviors. Common examples of Application Servers functions are message-waiting indication (MWI), 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-ringtone or integrated voicemail services.
Session Border Controllers (SBCs) are a market category term, and 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 the 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.
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 [RFC5370] inline conference bridge model is to behave as a SIP B2BUA without using the resource-list mechanism, but rather simply route a normal INVITE request through a B2BUA with built-in transcoder. SIP Transcoders architectures are based on everything from SIP media servers, to 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 to a 3PCC model; others just insert additional codecs in SDP offers and only transcode if the inserted codec(s) are selected in the answer.
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 server 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.
Proxy-Call Session Control Function (P-CSCF) and Interconnection Border Control Function (IBCF) are functions defined by 3GPP [IMS] standards, and when coupled with the IMS media-plane gateways (IMS Access Gateway IMS-AGW, Transition Gateway TrGW, etc.) typically form a logical Media-relay or Media-aware B2BUA role.
Serving-Call Session Control Function (S-CSCF) is a function defined by 3GPP [IMS] standards, and typically follows a Proxy-B2BUA role.
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:
Further security considerations related to the functionality described in this document are addressed in the relevant references.
This document makes no request of IANA.