< draft-ietf-straw-b2bua-taxonomy-02.txt   draft-ietf-straw-b2bua-taxonomy-03.txt >
STRAW Working Group H. Kaplan STRAW Working Group H. Kaplan
Internet-Draft V. Pascual Internet-Draft Oracle
Intended status: Informational Acme Packet Intended status: Informational V. Pascual
Expires: November 11, 2013 May 10, 2013 Expires: April 21, 2014 Quobis
October 18, 2013
A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents
draft-ietf-straw-b2bua-taxonomy-02 draft-ietf-straw-b2bua-taxonomy-03
Abstract Abstract
In many SIP deployments, SIP entities exist in the SIP signaling path In many SIP deployments, SIP entities exist in the SIP signaling path
between the originating UAC and final terminating UAS, which go between the originating and final terminating endpoints, which go
beyond the definition of a Proxy, performing functions not defined in beyond the definition of a SIP Proxy, performing functions not
standards-track RFCs. The only term for such devices provided in defined in standards-track RFCs. The only term for such devices
[RFC3261] is for a Back-to-Back User Agent (B2BUA), which is defined provided in [RFC3261] is for a Back-to-Back User Agent (B2BUA), which
as the logical concatenation of a User Agent Server (UAS) and User is defined as the logical concatenation of a SIP User Agent Server
Agent Client (UAC). (UAS) and User Agent Client (UAC).
There are numerous types of SIP Back-to-Back User Agents (B2BUAs), There are numerous types of SIP Back-to-Back User Agents, performing
performing different roles in different ways. For Example IP-PBXs, different roles in different ways. For Example IP-PBXs, Session
SBCs and Application Servers. This document identifies several Border Controllers (SBC) [RFC5853] and Application Servers (AS).
common B2BUA roles, in order to provide taxonomy other documents can This document identifies several common Back-to-Back User Agent
use and reference. roles, in order to provide taxonomy other documents can use and
reference.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 11, 2013. This Internet-Draft will expire on April 21, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. B2BUA Role Types . . . . . . . . . . . . . . . . . . . . . . 3 3. B2BUA Role Types . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Signaling-plane B2BUA Roles . . . . . . . . . . . . . . . 3 3.1. Signaling-plane B2BUA Roles . . . . . . . . . . . . . . . 3
3.1.1. Proxy-B2BUA . . . . . . . . . . . . . . . . . . . . . 3 3.1.1. Proxy-B2BUA . . . . . . . . . . . . . . . . . . . . . 4
3.1.2. Signaling-only . . . . . . . . . . . . . . . . . . . 4 3.1.2. Signaling-only . . . . . . . . . . . . . . . . . . . 4
3.1.3. SDP-Modifying Signaling-only . . . . . . . . . . . . 4 3.1.3. SDP-Modifying Signaling-only . . . . . . . . . . . . 4
3.2. Media-plane B2BUA Roles . . . . . . . . . . . . . . . . . 4 3.2. Media-plane B2BUA Roles . . . . . . . . . . . . . . . . . 5
3.2.1. Media-relay . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. Media-relay . . . . . . . . . . . . . . . . . . . . . 5
3.2.2. Media-aware . . . . . . . . . . . . . . . . . . . . . 5 3.2.2. Media-aware . . . . . . . . . . . . . . . . . . . . . 5
3.2.3. Media-termination . . . . . . . . . . . . . . . . . . 5 3.2.3. Media-termination . . . . . . . . . . . . . . . . . . 6
4. Mapping SIP Device Types to B2BUA Roles . . . . . . . . . . . 6 4. Mapping SIP Device Types to B2BUA Roles . . . . . . . . . . . 6
4.1. SIP PBXs and Softswitches . . . . . . . . . . . . . . . . 6 4.1. SIP PBXs and Softswitches . . . . . . . . . . . . . . . . 6
4.2. Application Servers . . . . . . . . . . . . . . . . . . . 6 4.2. Application Servers . . . . . . . . . . . . . . . . . . . 6
4.3. Session Border Controllers . . . . . . . . . . . . . . . 6 4.3. Session Border Controllers . . . . . . . . . . . . . . . 6
4.4. Transcoders . . . . . . . . . . . . . . . . . . . . . . . 6 4.4. Transcoders . . . . . . . . . . . . . . . . . . . . . . . 7
4.5. Conference Servers . . . . . . . . . . . . . . . . . . . 7 4.5. Conference Servers . . . . . . . . . . . . . . . . . . . 7
4.6. P-CSCF and IBCF Functions . . . . . . . . . . . . . . . . 7 4.6. P-CSCF and IBCF Functions . . . . . . . . . . . . . . . . 7
4.7. S-CSCF Function . . . . . . . . . . . . . . . . . . . . . 7 4.7. S-CSCF Function . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 7. Informative References . . . . . . . . . . . . . . . . . . . 8
8. Informative References . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Terminology 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, 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.
2. Terminology
The following terms are defined in [RFC3261], Section 6.
B2BUA: a SIP Back-to-Back User Agent, which is the logical B2BUA: a SIP Back-to-Back User Agent, which is the logical
combination of a User Agent Server (UAS) and User Agent Client (UAC). combination of a User Agent Server (UAS) and User Agent Client (UAC).
UAS: a SIP User Agent Server. UAS: a SIP User Agent Server.
UAC: a SIP User Agent Client. UAC: a SIP User Agent Client.
2. Introduction
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.
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.
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 3. B2BUA Role Types
Within the context of this document, the terms refer to a B2BUA role, Within the context of this document, the classification refers to a
not a particular system type. A given system type may change its B2BUA role, not a particular system type. A given system type may
role in the middle of a SIP session, for example when a Stateful change its role in the middle of a SIP session, for example when a
Proxy tears-down a session by generating BYEs; or for example when an Stateful Proxy tears-down a session by generating BYEs; or for
SBC performs transcoding or REFER termination. example when an SBC performs transcoding or REFER termination.
Furthermore, this document defines 'B2BUA' following the definition Furthermore, this document defines 'B2BUA' following the definition
provided in [RFC3261], which is the logical concatenation of a UAS provided in [RFC3261], which is the logical concatenation of a UAS
and UAC. A typical centralized conference server, for example, is and UAC. A typical centralized conference server, for example, is
not a B2BUA because it is the target UAS of multiple UACs, whereby not a B2BUA because it is the target UAS of multiple UACs, whereby
the UACs individually and independently initiate separate SIP the UACs individually and independently initiate separate SIP
sessions to the central conference server. Likewise, a third-party sessions to the central conference server. Likewise, a third-party
call control transcoder as described in section 3.1 of [RFC5369] is call control transcoder as described in section 3.1 of [RFC5369] is
not a B2BUA; whereas an inline transcoder based on [RFC5370] is a not a B2BUA; whereas an inline (conference bridge) transcoder based
B2BUA. on [RFC5370] is a B2BUA.
3.1. Signaling-plane B2BUA Roles 3.1. Signaling-plane B2BUA Roles
A Signaling-plane B2BUA is one that operates only on the SIP message 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 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, media itself in any way. This implies that it does not modify
although it may save them and/or operate on other MIME body types. Session Description Protocol (SDP) bodies, although it may save them
This category is further subdivided into specific roles as described and/or operate on other MIME body types. This category is further
in this section. 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"
3.1.1. Proxy-B2BUA 3.1.1. Proxy-B2BUA
A Proxy-B2BUA is one that appears, from a SIP protocol perspective, 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 to be a SIP Proxy based on [RFC3261] and its extensions, except that
it maintains sufficient dialog state to generate in-dialog SIP it maintains sufficient dialog state to generate in-dialog SIP
messages on its own and does so in specific cases. The most common 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 example of this is a SIP Proxy which can generate BYE requests to
tear-down a dead session. tear-down a dead session.
A Proxy-B2BUA does not modify the received header fields such as the 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 To, From, or Contact, and only modifies the Via and Record-Route
header fields following the rules in [RFC3261] and its extensions. header fields following the rules in [RFC3261] and its extensions.
If a Proxy-B2BUA can generate in-dialog messages, then it will also 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 need to modify the CSeq header, after it has generated its own. A
Proxy-B2BUA neither modifies nor inspects MIME bodies (including Proxy-B2BUA neither modifies nor inspects MIME bodies (including
SDP), does not have any awareness of media, will forward any Method SDP), does not have any awareness of media, will forward any Method
type, etc. type, etc.
3.1.2. Signaling-only 3.1.2. Signaling-only
A Signaling-only B2BUA is one that operates at the SIP layer but in A Signaling-only B2BUA is one that operates at the SIP layer but in
ways beyond those of [RFC3261] Proxies, even for normally forwarded ways beyond those of [RFC3261] Proxies, even for normally forwarded
requests. Such a B2BUA may or may not replace the Contact URI, requests. For example, such a B2BUA might replace the Contact URI,
modify or remove all Via and Record-Route headers, modify the To and modify or remove all Via and Record-Route headers, modify the To and
From header fields, modify or inspect specific MIME bodies, etc. No From header fields, modify or inspect specific MIME bodies, etc. No
SIP header field is guaranteed to be copied from the received request SIP header field is guaranteed to be copied from the received request
on the UAS side to the generated request on the UAC side. 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 An example of such a B2BUA would be some form of Application Server
and PBXs, such as a server which locally processes REFER requests and and PBX, such as a server which locally processes REFER requests and
generates new INVITEs on behalf of the REFER's target. Another generates new INVITEs on behalf of the REFER's target. Another
example would be an [RFC3323] Privacy Service Proxy performing the example would be an [RFC3323] Privacy Service Proxy performing the
'header' privacy function. 'header' privacy function.
3.1.3. SDP-Modifying Signaling-only 3.1.3. SDP-Modifying Signaling-only
An SDP-Modifying Signaling-only B2BUA is one that operates in the 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 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 SDP bodies and is thus aware of and understands SDP syntax and
semantics. Some Application Servers and PBXs act in this role in semantics. Some Application Servers and PBXs act in this role in
some cases, for example to remove certain codec choices or merge two some cases, for example to remove certain codec choices or merge two
media endpoints into one SDP offer. 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.
3.2. Media-plane B2BUA Roles 3.2. Media-plane B2BUA Roles
A Media-plane B2BUA is one that operates at both the SIP and media 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/ planes, not only on SIP messages but also SDP and potentially Real-
RTCP or other media. Such a B2BUA may or may not replace the Contact time Transport Protocol (RTP) / Real Time Control Protocol (RTCP)
URI, modify or remove all Via and Record-Route headers, modify the To [RFC3550] or other media. Such a B2BUA may or may not replace the
and From header fields, etc. No SIP header field is guaranteed to be Contact URI, modify or remove all Via and Record-Route headers,
copied from the received request on the UAS side to the generated modify the To and From header fields, etc. No SIP header field is
request on the UAC side, and SDP will also be modified. 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 An example of such a B2BUA would be a Session Border Controller (SBC)
performing the functions defined in [RFC5853], a B2BUA transcoder as performing the functions defined in [RFC5853], a B2BUA transcoder as
defined in [RFC5370], a rich-ringtone Application Server, or a defined in [RFC5370], a rich-ringtone Application Server, or a
recording system. Another example would be an [RFC3323] Privacy recording system. Another example would be an [RFC3323] Privacy
Service Proxy performing the 'session' privacy function. Service Proxy performing the 'session' privacy function.
Note that a Media-plane B2BUA need not be instantiated in a single Note that a Media-plane B2BUA need not be instantiated in a single
physical system, but may be decomposed into separate signaling and physical system, but may be decomposed into separate signaling and
media functions. media functions.
The Media-plane B2BUA category is further subdivided into specific The Media-plane B2BUA category is further subdivided into specific
roles as described in this section. roles as described in this section.
3.2.1. Media-relay 3.2.1. Media-relay
A B2BUA which performs a media-relay role is one that terminates the 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, media plane at the IP and transport (UDP/TCP) layers on its UAS and
but neither modifies nor restricts which forms of UDP or TCP payload UAC sides, but neither modifies nor restricts which forms of payload
are carried within the UDP or TCP packets. Such a role may only are carried within the packets. Rather, the payload is transparently
support UDP or only TCP or both, as well as other transport types or copied from one side to the other. Such a role may only support UDP
not. Such a role may involve policing the IP packets to fit within a or only TCP or both, as well as other transport types or not. Such a
bandwidth limit, or converting from IPv4 to IPV6 or vice-versa. This role may involve policing the IP packets to fit within a bandwidth
is typically similar to a NAT behavior, except a NAT operating in limit, or converting from IPv4 to IPV6 or vice-versa. This is
both directions on both the source and destination information; it 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. often found as the default behavior in SBCs.
3.2.2. Media-aware 3.2.2. Media-aware
A B2BUA which performs a media-aware role is similar to a media- A B2BUA which performs a media-aware role is similar to a media-
relay except that it inspects and potentially modifies the payload relay except that it inspects and potentially modifies the payload
carried in UDP or TCP, such as [RFC3550] RTP or RTCP, but not at a carried in UDP or TCP (as it could be [RFC3550] RTP or RTCP) but it
codec or higher layer. An example of such a role is an [RFC3711] does 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 [RFC3711] SRTP terminator, which does not need to care about the RTP
but does care about the RTP header; or a device which monitors RTCP payload but does care about the RTP header; or a device which
for QoS information; or a device which muxes/de-muxes RTP and RTCP monitors RTCP for QoS information; or a device which multiplexes/de-
packets on the same 5-tuple. multiplexes RTP and RTCP packets on the same 5-tuple.
3.2.3. Media-termination 3.2.3. Media-termination
A B2BUA which performs a media-termination role is one that operates 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 at the media payload layer, such as RTP/RTCP codec or MSRP message
layer and higher. Such a role may only terminate/generate specific layer and higher. Such a role may only terminate/generate specific
RTP media, such as [RFC4733] DTMF packets, or it may convert between 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 media codecs, or act as a Back-To-Back [RFC4975] MSRP agent. This is
the role performed by transcoders, conference servers, etc. the role performed by transcoders, [RFC5366] based conference
servers, etc.
4. Mapping SIP Device Types to B2BUA Roles 4. Mapping SIP Device Types to B2BUA Roles
Although the B2BUA role types defined previously do not define a Although the B2BUA roles defined previously do not define system
system type, as discussed in section 3, some discussion of what types, as discussed in section 3, some discussion of what common
common system types perform which defined roles may be appropriate. system types perform which defined roles may be appropriate. This
This section provides such a 'mapping' for general cases, to aid in section provides such a 'mapping' for general cases, to aid in
understanding of the roles. understanding of the roles.
4.1. SIP PBXs and Softswitches 4.1. SIP PBXs and Softswitches
SIP-enabled Private Branch eXchanges (SIP PBXs) and Softswitches are SIP-enabled Private Branch eXchanges (SIP PBXs) and Softswitches are
market category terms, and not specified in any standard. In general market category terms, and not specified in any standard. In general
they can perform every role described in this document at any given they can perform every role described in this document at any given
time, based on their architecture or local policy. Some are based on time, based on their architecture or local policy. Some are based on
architectures that make them the equivalent of a SIP UAS and UAC architectures that make them the equivalent of a SIP UAS and UAC
connected with a logical PRI loopback; others are built as a SIP connected with a logical PRI loopback; others are built as a SIP
skipping to change at page 7, line 4 skipping to change at page 7, line 13
every role described in this document at any given time, based on every role described in this document at any given time, based on
local policy. By default, most SBCs are either Media-relay or Media- local policy. By default, most SBCs are either Media-relay or Media-
aware B2BUAs, and replace the Contact URI, remove the Via and Record- aware B2BUAs, and replace the Contact URI, remove the Via and Record-
Route headers, modify the Call-ID, To, From, and various other Route headers, modify the Call-ID, To, From, and various other
headers, and modify SDP. Some SBCs remove all headers, all bodies, headers, and modify SDP. Some SBCs remove all headers, all bodies,
and reject all Method types unless explicitly allowed by local and reject all Method types unless explicitly allowed by local
policy; other SBCs pass all such elements through unless explicitly policy; other SBCs pass all such elements through unless explicitly
forbidden by local policy. forbidden by local policy.
4.4. Transcoders 4.4. Transcoders
Transcoders perform the function of transcoding one audio or video 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 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 perform the Media-termination role, although they may only terminate
media in specific cases of codec mismatch between the two ends. media in specific cases of codec mismatch between the two ends.
Although [RFC5369] and [RFC5370] define two types of SIP Transcoders, Although [RFC5369] and [RFC5370] define two types of SIP Transcoders,
in practice a popular variant of the [RFC5370] inline model is to in practice a popular variant of the [RFC5370] inline conference
behave as a SIP B2BUA without using the resource-list mechanism, but bridge model is to behave as a SIP B2BUA without using the resource-
rather simply route a normal INVITE request through an inline list mechanism, but rather simply route a normal INVITE request
transcoder. SIP Transcoders architectures are based on everything through a B2BUA with built-in transcoder. SIP Transcoders
from SIP media servers, to SBCs, to looped-back Time Division architectures are based on everything from SIP media servers, to
Multiplexing (TDM) gateways, and thus run the gamut from replacing SBCs, to looped-back Time Division Multiplexing (TDM) gateways, and
only specific headers/bodies and SDP content needed to perform their thus run the gamut from replacing only specific headers/bodies and
function, to replacing almost all SIP headers and SDP content. Some SDP content needed to perform their function, to replacing almost all
transcoders save and remove SDP offers in INVITEs from the UAC, and SIP headers and SDP content. Some transcoders save and remove SDP
wait for an offer in the response from the UAS, similar to a 3PCC offers in INVITEs from the UAC, and wait for an offer in the response
model; others just insert additional codecs in SDP offers and only from the UAS, similar to a 3PCC model; others just insert additional
transcode if the inserted codec(s) are selected in the answer. codecs in SDP offers and only transcode if the inserted codec(s) are
selected in the answer.
4.5. Conference Servers 4.5. Conference Servers
In general Conference Servers do not fall under the term 'B2BUA' as In general Conference Servers do not fall under the term 'B2BUA' as
defined by this document, since typically they involve multiple SIP defined by this document, since typically they involve multiple SIP
UACs initiating independent SIP sessions to the single conference UACs initiating independent SIP sessions to the single conference
server UAS. However, a conference server supporting [RFC5366], server UAS. However, a conference server supporting [RFC5366],
whereby the received INVITE triggers the conference focus UAS to whereby the received INVITE triggers the conference focus UAS to
initiate multiple INVITEs as a UAC, would be in a Media-termination initiate multiple INVITEs as a UAC, would be in a Media-termination
B2BUA role when performing that function. B2BUA role when performing that function.
4.6. P-CSCF and IBCF Functions 4.6. P-CSCF and IBCF Functions
Proxy-CSCFs and IBCFs are functions defined by 3GPP [IMS] standards, Proxy-Call Session Control Function (P-CSCF) and Interconnection
and when coupled with the IMS media-plane gateways (IMS AGW, TrGW, Border Control Function (IBCF) are functions defined by 3GPP [IMS]
etc.) typically form a logical Media-relay or Media-aware B2BUA standards, and when coupled with the IMS media-plane gateways (IMS
role. Access Gateway IMS-AGW, Transition Gateway TrGW, etc.) typically form
a logical Media-relay or Media-aware B2BUA role.
4.7. S-CSCF Function 4.7. S-CSCF Function
S-CSCF is a function defined by 3GPP [IMS] standards, and typically Serving-Call Session Control Function (S-CSCF) is a function defined
follows a Proxy-B2BUA role. by 3GPP [IMS] standards, and typically follows a Proxy-B2BUA role.
5. Security Considerations 5. Security Considerations
The security considerations related to the functionality described in Security risks are specific to each type of B2BUA, so little can be
this document are addressed in the relevant references. 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.
6. IANA Considerations A few general points can be made:
This document makes no request of IANA. 1. The B2BUA processing of SDP and media packets is an impediment to
deployment of end-to-end SRTP, and reduces the ability to deploy
new, stronger forms of SRTP key exchange.
7. Acknowledgments 2. The ability for B2BUAs to modify any SIP header field value and
body impacts the ability to deploy SIP Identity and message
integrity.
Funding for the RFC Editor function is provided by the IETF 3. The management and configuration mechanisms of B2BUAs are a
Administrative Support Activity (IASA). tempting point of attack, and must be strongly defended.
8. Informative References Further security considerations related to the functionality
described in this document are addressed in the relevant references.
6. IANA Considerations
This document makes no request of IANA.
7. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session [RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323, November 2002. Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
skipping to change at page 9, line 8 skipping to change at page 9, line 38
A., and M. Bhatia, "Requirements from Session Initiation A., and M. Bhatia, "Requirements from Session Initiation
Protocol (SIP) Session Border Control (SBC) Deployments", Protocol (SIP) Session Border Control (SBC) Deployments",
RFC 5853, April 2010. RFC 5853, April 2010.
[IMS] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2, 3GPP TS [IMS] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2, 3GPP TS
23.228", 2013. 23.228", 2013.
Authors' Addresses Authors' Addresses
Hadriel Kaplan Hadriel Kaplan
Acme Packet Oracle
Email: hkaplan@acmepacket.com Email: hadriel.kaplan@oracle.com
Victor Pascual Victor Pascual
Acme Packet Quobis
Email: victor.pascual.avila@gmail.com Email: victor.pascual@quobis.com
 End of changes. 41 change blocks. 
117 lines changed or deleted 152 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/