Internet DRAFT - draft-kaplan-dispatch-b2bua-taxonomy
draft-kaplan-dispatch-b2bua-taxonomy
Network Working Group H. Kaplan
Internet Draft Acme Packet
Intended status: Informational October 15, 2011
Expires: April 21, 2012
A Taxonomy of Session Initiation Protocol (SIP)
Back-to-Back User Agents
draft-kaplan-dispatch-b2bua-taxonomy-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 15, 2011.
Copyright and License Notice
Copyright (c) 2010 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 BSD License.
Kaplan Expires April 24, 2012 [Page 1]
Internet-Draft Taxonomy of B2BUAs October 2011
Abstract
There are numerous types of SIP Back-to-Back User Agents (B2BUAs),
performing different roles in different ways. This document
identifies several common B2BUA roles, in order to provide taxonomy
other documents can use and reference.
Table of Contents
1. Terminology.................................................2
2. Introduction................................................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.2. Media-plane B2BUA Roles.................................4
3.2.1 Media-relay...........................................5
3.2.2 Media-aware...........................................5
3.2.3 Media-termination.....................................5
4. Mapping SIP Device Types to B2BUA Roles.....................6
4.1. SIP PBXs and Softswitches...............................6
4.2. Application Servers.....................................6
4.3. Session Border Controllers..............................6
4.4. Transcoders.............................................7
4.5. Conference Servers......................................7
4.6. P-CSCF and IBCF Functions...............................7
4.7. S-CSCF Function.........................................7
5. Security Considerations.....................................7
6. IANA Considerations.........................................8
7. Acknowledgments.............................................8
8. References..................................................8
8.1. Informative References..................................8
Author's Address..................................................8
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. The
terminology in this document conforms to RFC 2828, "Internet
Security Glossary".
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.
Kaplan Expires - April 2011 [Page 2]
Internet-Draft Taxonomy of B2BUAs October 2011
UAC: a SIP User Agent Client.
2. Introduction
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
[RFC3261] 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).
In practice, 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.
As more and more SIP domains get deployed and interconnect, the odds
of a SIP session crossing such media-plane B2BUAs increases, as well
as the number of such B2BUAs any given SIP session may go through.
In other words, any given SIP session may cross any number of B2BUAs
both in the SIP signaling plane as well as media-plane.
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.
3. B2BUA Role Types
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.
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 one-armed
third-party call control transcoder as described in section 3.1 of
Kaplan Expires - April 2011 [Page 3]
Internet-Draft Taxonomy of B2BUAs October 2011
[RFC5369] is not a B2BUA; whereas an inline 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 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.
3.1.1 Proxy-B2BUA
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. Another example would be a Proxy which
can generate UPDATE requests to test the liveness of a 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.
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. 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.
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 [RFC3323] Privacy Service Proxy
performing the 'header' privacy function.
3.2. Media-plane B2BUA Roles
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
Kaplan Expires - April 2011 [Page 4]
Internet-Draft Taxonomy of B2BUAs October 2011
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.
An example of such a B2BUA would be a Session Border Controller
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.
3.2.1 Media-relay
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.
3.2.2 Media-aware
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 RTP or RTCP, but not at a codec or
higher layer. An example of such a role is an 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.
3.2.3 Media-termination
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
Kaplan Expires - April 2011 [Page 5]
Internet-Draft Taxonomy of B2BUAs October 2011
RTP media, such as [RFC4733] DTMF packets, or it may convert between
media codecs, or act as a Back-To-Back MSRP agent. This is the role
performed by transcoders, conference servers, etc.
4. Mapping SIP Device Types to B2BUA Roles
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.
4.1. SIP PBXs and Softswitches
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".
4.2. Application Servers
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, find-me-follow-me services, privacy services, call-
center ACD services, call screening, and VCC services. Some only
operate in the signaling plane in either Poxy-B2BUA or Signaling-
only B2BUA roles; others operate as full Media-termination B2BUAs,
such as when providing IVR, rich-ringtone or integrated voicemail
services.
4.3. Session Border Controllers
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.
Kaplan Expires - April 2011 [Page 6]
Internet-Draft Taxonomy of B2BUAs October 2011
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 [RFC5370] 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 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 form 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.
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
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.
4.6. P-CSCF and IBCF Functions
Proxy-CSCFs and IBCFs are functions defined by 3GPP IMS 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.
4.7. S-CSCF Function
S-CSCF is a function defined by 3GPP IMS standards, and typically
follows a Proxy-B2BUA role.
5. Security Considerations
There are no security implications for this document, as it is only
a taxonomy.
Kaplan Expires - April 2011 [Page 7]
Internet-Draft Taxonomy of B2BUAs October 2011
6. IANA Considerations
This document makes no request of IANA.
7. Acknowledgments
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
8. References
8.1. 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.
[RFC4733] Schulzrinne, H., Taylor, T., "RTP Payload for DTMF Digits,
Telephony Tones, and Telephony Signals", RFC 4733, December 2006.
[RFC5366] Camarillo, G., Johnston, A., "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, et al, "Requirements from Session
Initiation Protocol (SIP) Session Border Control (SBC) Deployments",
RFC 5853, April 2010.
Author's Address
Hadriel Kaplan
Acme Packet
Email: hkaplan@acmepacket.com
Kaplan Expires - April 2011 [Page 8]
