1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
|
<pre>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 <a href="./rfc3261">RFC 3261</a> 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 <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7092">http://www.rfc-editor.org/info/rfc7092</a>.
<span class="grey">Kaplan & Pascual Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7092">RFC 7092</a> Taxonomy of B2BUAs December 2013</span>
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. B2BUA Role Types . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. Signaling Plane B2BUA Roles . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.1.1">3.1.1</a>. Proxy-B2BUA . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.1.2">3.1.2</a>. Signaling-only . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.1.3">3.1.3</a>. SDP-Modifying Signaling-only . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.2">3.2</a>. Signaling/Media Plane B2BUA Roles . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.2.1">3.2.1</a>. Media Relay . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.2.2">3.2.2</a>. Media Aware . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.2.3">3.2.3</a>. Media Termination . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4">4</a>. Mapping SIP Device Types to B2BUA Roles . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. SIP PBXs and Softswitches . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.2">4.2</a>. Application Servers . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4.3">4.3</a>. Session Border Controllers . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4.4">4.4</a>. Transcoders . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4.5">4.5</a>. Conference Servers . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.6">4.6</a>. P-CSCF and IBCF Functions . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.7">4.7</a>. S-CSCF Function . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5">5</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-6">6</a>. Informative References . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<span class="grey">Kaplan & Pascual Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7092">RFC 7092</a> Taxonomy of B2BUAs December 2013</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
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.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
The following terms are defined in <a href="./rfc3261#section-6">[RFC3261], Section 6</a>.
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.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. B2BUA Role Types</span>
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
[<a href="./rfc5853" title=""Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments"">RFC5853</a>] performs transcoding or REFER termination.
Furthermore, this document defines "B2BUA" following the definition
provided in [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>], 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 <a href="./rfc5369#section-3.1">Section 3.1 of [RFC5369]</a>, is
<span class="grey">Kaplan & Pascual Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7092">RFC 7092</a> Taxonomy of B2BUAs December 2013</span>
not a B2BUA, whereas an inline (conference bridge) transcoder based
on [<a href="./rfc5370" title=""The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model"">RFC5370</a>] is a B2BUA.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Signaling Plane B2BUA Roles</span>
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".
<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>. Proxy-B2BUA</span>
A Proxy-B2BUA is one that appears, from a SIP perspective, to be a
SIP proxy based on [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>] 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 [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>] 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.
<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>. Signaling-only</span>
A Signaling-only B2BUA is one that operates at the SIP layer but in
ways beyond those of [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>] 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 [<a href="./rfc3323" title=""A Privacy Mechanism for the Session Initiation Protocol (SIP)"">RFC3323</a>] performing
the 'header' privacy function.
<span class="grey">Kaplan & Pascual Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7092">RFC 7092</a> Taxonomy of B2BUAs December 2013</span>
<span class="h4"><a class="selflink" id="section-3.1.3" href="#section-3.1.3">3.1.3</a>. SDP-Modifying Signaling-only</span>
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.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Signaling/Media Plane B2BUA Roles</span>
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) [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>] 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 [<a href="./rfc5853" title=""Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments"">RFC5853</a>], a B2BUA transcoder as
defined in [<a href="./rfc5370" title=""The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model"">RFC5370</a>], a rich-ringtone Application Server, or a
recording system. Another example would be a privacy service proxy
[<a href="./rfc3323" title=""A Privacy Mechanism for the Session Initiation Protocol (SIP)"">RFC3323</a>] 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.
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>. Media Relay</span>
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
<span class="grey">Kaplan & Pascual Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7092">RFC 7092</a> Taxonomy of B2BUAs December 2013</span>
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.
<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>. Media Aware</span>
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 [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>]), but it does not
at a codec or higher layer. An example of such a role is a Secure
Real-time Transport Protocol (SRTP) [<a href="./rfc3711" title=""The Secure Real-time Transport Protocol (SRTP)"">RFC3711</a>] 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.
<span class="h4"><a class="selflink" id="section-3.2.3" href="#section-3.2.3">3.2.3</a>. Media Termination</span>
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 [<a href="./rfc4733" title=""RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals"">RFC4733</a>], or it may convert between
media codecs or act as a Back-to-Back MSRP [<a href="./rfc4975" title=""The Message Session Relay Protocol (MSRP)"">RFC4975</a>] agent. This is
the role performed by transcoders, conference servers based on
[<a href="./rfc5366" title=""Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)"">RFC5366</a>], etc.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Mapping SIP Device Types to B2BUA Roles</span>
Although the B2BUA roles defined previously do not define system
types, as discussed in <a href="#section-3">Section 3</a>, 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.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. SIP PBXs and Softswitches</span>
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".
<span class="grey">Kaplan & Pascual Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7092">RFC 7092</a> Taxonomy of B2BUAs December 2013</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Application Servers</span>
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.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Session Border Controllers</span>
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 [<a href="./rfc5853" title=""Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments"">RFC5853</a>], 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.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Transcoders</span>
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 [<a href="./rfc5369" title=""Framework for Transcoding with the Session Initiation Protocol (SIP)"">RFC5369</a>] and [<a href="./rfc5370" title=""The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model"">RFC5370</a>] define two types of SIP transcoders,
in practice, a popular variant of the inline conference bridge model
[<a href="./rfc5370" title=""The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model"">RFC5370</a>] 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
<span class="grey">Kaplan & Pascual Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7092">RFC 7092</a> Taxonomy of B2BUAs December 2013</span>
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.
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. Conference Servers</span>
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 [<a href="./rfc5366" title=""Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)"">RFC5366</a>], 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.
<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>. P-CSCF and IBCF Functions</span>
The Proxy-Call Session Control Function (P-CSCF) and the
Interconnection Border Control Function (IBCF) are defined by 3GPP
[<a href="#ref-IMS" title=""IP Multimedia Subsystem (IMS); Stage 2, 3GPP TS 23.228"">IMS</a>] 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.
<span class="h3"><a class="selflink" id="section-4.7" href="#section-4.7">4.7</a>. S-CSCF Function</span>
The Serving-Call Session Control Function (S-CSCF) is defined by 3GPP
[<a href="#ref-IMS" title=""IP Multimedia Subsystem (IMS); Stage 2, 3GPP TS 23.228"">IMS</a>] standards and typically follows a Proxy-B2BUA role.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
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.
<span class="grey">Kaplan & Pascual Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7092">RFC 7092</a> Taxonomy of B2BUAs December 2013</span>
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.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Informative References</span>
[<a id="ref-RFC3261">RFC3261</a>] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", <a href="./rfc3261">RFC 3261</a>,
June 2002.
[<a id="ref-RFC3323">RFC3323</a>] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", <a href="./rfc3323">RFC 3323</a>, November 2002.
[<a id="ref-RFC3550">RFC3550</a>] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, <a href="./rfc3550">RFC 3550</a>, July 2003.
[<a id="ref-RFC3711">RFC3711</a>] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
<a href="./rfc3711">RFC 3711</a>, March 2004.
[<a id="ref-RFC4733">RFC4733</a>] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
Digits, Telephony Tones, and Telephony Signals", <a href="./rfc4733">RFC 4733</a>,
December 2006.
[<a id="ref-RFC4975">RFC4975</a>] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", <a href="./rfc4975">RFC 4975</a>, September 2007.
[<a id="ref-RFC5366">RFC5366</a>] Camarillo, G. and A. Johnston, "Conference Establishment
Using Request-Contained Lists in the Session Initiation
Protocol (SIP)", <a href="./rfc5366">RFC 5366</a>, October 2008.
[<a id="ref-RFC5369">RFC5369</a>] Camarillo, G., "Framework for Transcoding with the Session
Initiation Protocol (SIP)", <a href="./rfc5369">RFC 5369</a>, October 2008.
[<a id="ref-RFC5370">RFC5370</a>] Camarillo, G., "The Session Initiation Protocol (SIP)
Conference Bridge Transcoding Model", <a href="./rfc5370">RFC 5370</a>, October
2008.
[<a id="ref-RFC5853">RFC5853</a>] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen,
A., and M. Bhatia, "Requirements from Session Initiation
Protocol (SIP) Session Border Control (SBC) Deployments",
<a href="./rfc5853">RFC 5853</a>, April 2010.
<span class="grey">Kaplan & Pascual Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7092">RFC 7092</a> Taxonomy of B2BUAs December 2013</span>
[<a id="ref-IMS">IMS</a>] 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]
</pre>
|
