One document matched: draft-ietf-straw-b2bua-taxonomy-02.xml
<?xml version="1.0" encoding="iso-8859-1"?>
<!-- comment -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc ipr="trust200902" category="info" docName="draft-ietf-straw-b2bua-taxonomy-02" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="Taxonomy of B2BUAs">
A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents
</title>
<author initials="H." surname="Kaplan" fullname="Hadriel Kaplan">
<organization>Acme Packet</organization>
<address>
<postal>
<street></street>
<code></code>
<city></city>
<country></country>
</postal>
<email>hkaplan@acmepacket.com</email>
</address>
</author>
<author initials="V." surname="Pascual" fullname="Victor Pascual">
<organization>Acme Packet</organization>
<address>
<postal>
<street></street>
<code></code>
<city></city>
<country></country>
</postal>
<email>victor.pascual.avila@gmail.com</email>
</address>
</author>
<date year="2013" />
<area>Transport</area>
<workgroup>STRAW Working Group</workgroup>
<keyword>SIP</keyword>
<keyword>B2BUA</keyword>
<keyword>taxonomy</keyword>
<abstract>
<t>
In many SIP deployments, SIP entities exist in the SIP signaling
path between the originating UAC and final terminating UAS, which go
beyond the definition of a Proxy, performing functions not defined
in standards-track RFCs. The only term for such devices provided in
<xref target="RFC3261" pageno="false" format="default" /> is for a
Back-to-Back User Agent (B2BUA), which is defined as the logical
concatenation of a User Agent Server (UAS) and User Agent Client (UAC).
</t>
<t>
There are numerous types of SIP Back-to-Back User Agents (B2BUAs),
performing different roles in different ways. For Example IP-PBXs,
SBCs and Application Servers. This document identifies several
common B2BUA roles, in order to provide taxonomy other documents can
use and reference.
</t>
</abstract>
</front>
<middle>
<section title="Terminology" toc="default">
<t>
B2BUA: a SIP Back-to-Back User Agent, which is the logical
combination of a User Agent Server (UAS) and User Agent Client
(UAC).
</t>
<t>
UAS: a SIP User Agent Server.
</t>
<t>
UAC: a SIP User Agent Client.
</t>
</section>
<section title="Introduction" toc="default">
<t>
In current SIP deployments, there are numerous forms of B2BUAs,
operating at various layers of the protocol stack, 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 UAS and UAC sides. Some B2BUAs
operate only in the SIP signaling plane, while others participate in
the media plane as well.
</t>
<t>
As more and more SIP domains get deployed and interconnect the
probability of a single SIP session crossing multiple B2BUA's at
both the signaling and media planes increases significantly.
</t>
<t>
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.
</t>
</section>
<section title="B2BUA Role Types" toc="default">
<t>
Within the context of this document, the terms refer 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.
</t>
<t>
Furthermore, this document defines 'B2BUA' following the definition
provided in <xref target="RFC3261" pageno="false" format="default"/>,
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 <xref target="RFC5369" pageno="false"
format="default"/> is not a B2BUA; whereas an inline transcoder based on
<xref target="RFC5370" pageno="false" format="default"/> is a B2BUA.
</t>
<section title="Signaling-plane B2BUA Roles" toc="default">
<t>
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 it does not modify 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.
</t>
<section title="Proxy-B2BUA" toc="default">
<t>
A Proxy-B2BUA is one that appears, from a SIP protocol perspective,
to be a SIP Proxy based on <xref target="RFC3261" pageno="false"
format="default"/> 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.
</t>
<t>
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 <xref target="RFC3261" pageno="false"
format="default"/> and its extensions. If a Proxy-B2BUA can generate
in-dialog messages, then it will also need to modify the CSeq header,
after it's 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.
</t>
</section>
<section title="Signaling-only" toc="default">
<t>
A Signaling-only B2BUA is one that operates at the SIP layer but in
ways beyond those of <xref target="RFC3261" pageno="false" format="default" />
Proxies, even for normally forwarded
requests. 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, 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.
</t>
<t>
An example of such a B2BUA would be some forms of Application
Servers and PBXs, 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 <xref target="RFC3323" pageno="false"
format="default" /> Privacy Service Proxy performing the 'header' privacy function.
</t>
</section>
<section title="SDP-Modifying Signaling-only" toc="default">
<t>
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.
</t>
</section>
</section>
<section title="Media-plane B2BUA Roles" toc="default">
<t>
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
RTP/RTCP 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.
</t>
<t>
An example of such a B2BUA would be a Session Border Controller
performing the functions defined in <xref target="RFC5853" pageno="false"
format="default" />, a B2BUA transcoder as defined in <xref target="RFC5370"
pageno="false" format="default" />, a rich-ringtone Application Server, or a
recording system. Another example would be an <xref target="RFC3323"
pageno="false" format="default" /> Privacy Service Proxy performing
the 'session' privacy function.
</t>
<t>
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.
</t>
<t>
The Media-plane B2BUA category is further subdivided into specific
roles as described in this section.
</t>
<section title="Media-relay" toc="default">
<t>
A B2BUA which performs a media-relay role is one that terminates the
media plane at the IP and UDP/TCP layers on its UAS and UAC sides,
but neither modifies nor restricts which forms of UDP or TCP payload
are carried within the UDP or TCP packets. 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.
</t>
</section>
<section title="Media-aware" toc="default">
<t>
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, such as <xref target="RFC3550" pageno="false"
format="default" /> RTP or RTCP, but not at a codec or higher layer.
An example of such a role is an <xref target="RFC3711" pageno="false" format="default" />
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 muxes/de-muxes RTP and RTCP
packets on the same 5-tuple.
</t>
</section>
<section title="Media-termination" toc="default">
<t>
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 <xref target="RFC4733" pageno="false" format="default" />
DTMF packets, or it may convert between media codecs, or act as a Back-To-Back
<xref target="RFC4975" pageno="false" format="default" /> MSRP agent. This
is the role performed by transcoders, conference servers, etc.
</t>
</section>
</section>
</section>
<section title="Mapping SIP Device Types to B2BUA Roles" toc="default">
<t>
Although the B2BUA role types defined previously do not define a
system type, 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.
</t>
<section title="SIP PBXs and Softswitches" toc="default">
<t>
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".
</t>
</section>
<section title="Application Servers" toc="default">
<t>
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.
</t>
</section>
<section title="Session Border Controllers" toc="default">
<t>
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 <xref target="RFC5853" pageno="false"
format="default" />, 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.
</t>
</section>
<section title="Transcoders" toc="default">
<t>
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 <xref target="RFC5369" pageno="false" format="default" /> and
<xref target="RFC5370" pageno="false" format="default" /> define two
types of SIP Transcoders, in practice a popular variant of the
<xref target="RFC5370" pageno="false" format="default" /> inline
model is to behave as a SIP B2BUA without using the resource-list
mechanism, but rather simply route a normal INVITE request through
an inline 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.
</t>
</section>
<section title="Conference Servers" toc="default">
<t>
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 <xref target="RFC5366"
pageno="false" format="default" />, 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.
</t>
</section>
<section title="P-CSCF and IBCF Functions" toc="default">
<t>
Proxy-CSCFs and IBCFs are functions defined by 3GPP <xref target="IMS"></xref> standards,
and when coupled with the IMS media-plane gateways (IMS AGW, TrGW,
etc.) typically form a logical Media-relay or Media-aware B2BUA
role.
</t>
</section>
<section title="S-CSCF Function" toc="default">
<t>
S-CSCF is a function defined by 3GPP <xref target="IMS"></xref> standards, and typically
follows a Proxy-B2BUA role.
</t>
</section>
</section>
<section title="Security Considerations" toc="default">
<t>
The security considerations related to the functionality described
in this document are addressed in the relevant references.
</t>
</section>
<section title="IANA Considerations" toc="default">
<t>
This document makes no request of IANA.
</t>
</section>
<section title="Acknowledgments" toc="default">
<t>
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
</t>
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.3323"?>
<?rfc include="reference.RFC.3550"?>
<?rfc include="reference.RFC.3711"?>
<?rfc include="reference.RFC.4733"?>
<?rfc include="reference.RFC.4975"?>
<?rfc include="reference.RFC.5366"?>
<?rfc include="reference.RFC.5369"?>
<?rfc include="reference.RFC.5370"?>
<?rfc include="reference.RFC.5853"?>
<reference anchor="IMS">
<front>
<title>IP Multimedia Subsystem (IMS); Stage 2, 3GPP TS 23.228</title>
<author>
<organization>3GPP</organization>
</author>
<date year="2013" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:39:55 |