idnits 2.17.1 draft-kaplan-straw-b2bua-taxonomy-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 22, 2012) is 4203 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Kaplan 3 Internet Draft Acme Packet 4 Intended status: Informational October 22, 2012 5 Expires: April 22, 2013 7 A Taxonomy of Session Initiation Protocol (SIP) 8 Back-to-Back User Agents 9 draft-kaplan-straw-b2bua-taxonomy-01 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with 14 the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 22, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described in 46 Section 4.e of the Trust Legal Provisions and are provided without 47 warranty as described in the Simplified BSD License. 49 Abstract 51 There are numerous types of SIP Back-to-Back User Agents (B2BUAs), 52 performing different roles in different ways. This document 53 identifies several common B2BUA roles, in order to provide taxonomy 54 other documents can use and reference. 56 Table of Contents 58 1. Terminology...................................................2 59 2. Introduction..................................................3 60 3. B2BUA Role Types..............................................3 61 3.1. Signaling-plane B2BUA Roles..............................4 62 3.1.1 Proxy-B2BUA 4 63 3.1.2 Signaling-only 4 64 3.1.3 SDP-Modifying Signaling-only 5 65 3.2. Media-plane B2BUA Roles..................................5 66 3.2.1 Media-relay 5 67 3.2.2 Media-aware 5 68 3.2.3 Media-termination 6 69 4. Mapping SIP Device Types to B2BUA Roles.......................6 70 4.1. SIP PBXs and Softswitches................................6 71 4.2. Application Servers......................................6 72 4.3. Session Border Controllers...............................7 73 4.4. Transcoders..............................................7 74 4.5. Conference Servers.......................................7 75 4.6. P-CSCF and IBCF Functions................................7 76 4.7. S-CSCF Function..........................................8 77 5. Security Considerations.......................................8 78 6. IANA Considerations...........................................8 79 7. Acknowledgments...............................................8 80 8. References....................................................8 81 8.1. Informative References...................................8 82 Author's Address..................................................9 84 1. Terminology 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119. The 89 terminology in this document conforms to RFC 2828, "Internet 90 Security Glossary". 92 B2BUA: a SIP Back-to-Back User Agent, which is the logical 93 combination of a User Agent Server (UAS) and User Agent Client 94 (UAC). 96 UAS: a SIP User Agent Server. 98 UAC: a SIP User Agent Client. 100 2. Introduction 102 In many SIP deployments, SIP entities exist in the SIP signaling 103 path between the originating UAC and final terminating UAS, which go 104 beyond the definition of a Proxy, performing functions not defined 105 in standards-track RFCs. The only term for such devices provided in 106 [RFC3261] is for a Back-to-Back User Agent (B2BUA), which is defined 107 as the logical concatenation of a User Agent Server (UAS) and User 108 Agent Client (UAC). 110 In practice, there are numerous forms of B2BUAs, operating at 111 various layers of the protocol stack, and for various purposes, and 112 with widely varying behavior from a SIP protocol perspective. Some 113 act as pure SIP Proxies and only change to the role of B2BUA in 114 order to generate BYEs to terminate dead sessions. Some are full 115 User Agent stacks with only high-level event and application logic 116 binding the UAS and UAC sides. Some B2BUAs operate only in the SIP 117 signaling plane, while others participate in the media plane as 118 well. 120 As more and more SIP domains get deployed and interconnect, the odds 121 of a SIP session crossing such media-plane B2BUAs increases, as well 122 as the number of such B2BUAs any given SIP session may go through. 123 In other words, any given SIP session may cross any number of B2BUAs 124 both in the SIP signaling plane as well as media-plane. 126 This document provides a taxonomy of several common B2BUA roles, so 127 that other documents may refer to them using their given names 128 without re-defining them in each document. 130 3. B2BUA Role Types 132 Within the context of this document, the terms refer to a B2BUA 133 role, not a particular system type. A given system type may change 134 its role in the middle of a SIP session, for example when a Stateful 135 Proxy tears-down a session by generating BYEs; or for example when 136 an SBC performs transcoding or REFER termination. 138 Furthermore, this document defines 'B2BUA' following the definition 139 provided in [RFC3261], which is the logical concatenation of a UAS 140 and UAC. A typical centralized conference server, for example, is 141 not a B2BUA because it is the target UAS of multiple UACs, whereby 142 the UACs individually and independently initiate separate SIP 143 sessions to the central conference server. Likewise, a one-armed 144 third-party call control transcoder as described in section 3.1 of 145 [RFC5369] is not a B2BUA; whereas an inline transcoder based on 146 [RFC5370] is a B2BUA. 148 3.1. Signaling-plane B2BUA Roles 150 A Signaling-plane B2BUA is one that operates only on the SIP message 151 protocol layer, and only with SIP messages and headers but not the 152 media itself in any way. This implies it does not modify SDP 153 bodies, although it may save them and/or operate on other MIME body 154 types. This category is further subdivided into specific roles as 155 described in this section. 157 3.1.1 Proxy-B2BUA 159 A Proxy-B2BUA is one that appears, from a SIP protocol perspective, 160 to be a SIP Proxy based on [RFC3261] and its extensions, except that 161 it maintains sufficient dialog state to generate in-dialog SIP 162 messages on its own and does so in specific cases. The most common 163 example of this is a SIP Proxy which can generate BYE requests to 164 tear-down a dead session. 166 A Proxy-B2BUA does not modify the received header fields such as the 167 To, From, or Contact, and only modifies the Via and Record-Route 168 header fields following the rules in [RFC3261] and its extensions. 169 A Proxy-B2BUA neither modifies nor inspects MIME bodies (including 170 SDP), does not have any awareness of media, will forward any Method 171 type, etc. 173 3.1.2 Signaling-only 175 A Signaling-only B2BUA is one that operates at the SIP layer but in 176 ways beyond those of [RFC3261] Proxies, even for normally forwarded 177 requests. Such a B2BUA may or may not replace the Contact URI, 178 modify or remove all Via and Record-Route headers, modify the To and 179 From header fields, modify or inspect specific MIME bodies, etc. No 180 SIP header field is guaranteed to be copied from the received 181 request on the UAS side to the generated request on the UAC side. 183 An example of such a B2BUA would be some forms of Application 184 Servers and PBXs, such as a server which locally processes REFER 185 requests and generates new INVITEs on behalf of the REFER's target. 186 Another example would be an [RFC3323] Privacy Service Proxy 187 performing the 'header' privacy function. 189 3.1.3 SDP-Modifying Signaling-only 191 An SDP-Modifying Signaling-only B2BUA is one that operates in the 192 signaling plane only and is not in the media path, but does modify 193 SDP bodies and is thus aware of and understands SDP syntax and 194 semantics. 196 3.2. Media-plane B2BUA Roles 198 A Media-plane B2BUA is one that operates at both the SIP and media 199 planes, not only on SIP messages but also SDP and potentially 200 RTP/RTCP or other media. Such a B2BUA may or may not replace the 201 Contact URI, modify or remove all Via and Record-Route headers, 202 modify the To and From header fields, etc. No SIP header field is 203 guaranteed to be copied from the received request on the UAS side to 204 the generated request on the UAC side, and SDP will also be 205 modified. 207 An example of such a B2BUA would be a Session Border Controller 208 performing the functions defined in [RFC5853], a B2BUA transcoder as 209 defined in [RFC5370], a rich-ringtone Application Server, or a 210 recording system. Another example would be an [RFC3323] Privacy 211 Service Proxy performing the 'session' privacy function. 213 Note that a Media-plane B2BUA need not be instantiated in a single 214 physical system, but may be decomposed into separate signaling and 215 media functions. 217 The Media-plane B2BUA category is further subdivided into specific 218 roles as described in this section. 220 3.2.1 Media-relay 222 A B2BUA which performs a media-relay role is one that terminates the 223 media plane at the IP and UDP/TCP layers on its UAS and UAC sides, 224 but neither modifies nor restricts which forms of UDP or TCP payload 225 are carried within the UDP or TCP packets. Such a role may only 226 support UDP or only TCP or both, as well as other transport types or 227 not. Such a role may involve policing the IP packets to fit within 228 a bandwidth limit, or converting from IPv4 to IPV6 or vice-versa. 229 This is typically similar to a NAT behavior, except a NAT operating 230 in both directions on both the source and destination information; 231 it is often found as the default behavior in SBCs. 233 3.2.2 Media-aware 235 A B2BUA which performs a media-aware role is similar to a media- 236 relay except that it inspects and potentially modifies the payload 237 carried in UDP or TCP, such as RTP or RTCP, but not at a codec or 238 higher layer. An example of such a role is an SRTP terminator, 239 which does not need to care about the RTP payload but does care 240 about the RTP header; or a device which monitors RTCP for QoS 241 information; or a device which muxes/de-muxes RTP and RTCP packets 242 on the same 5-tuple. 244 3.2.3 Media-termination 246 A B2BUA which performs a media-termination role is one that operates 247 at the media payload layer, such as RTP/RTCP codec or MSRP message 248 layer and higher. Such a role may only terminate/generate specific 249 RTP media, such as [RFC4733] DTMF packets, or it may convert between 250 media codecs, or act as a Back-To-Back MSRP agent. This is the role 251 performed by transcoders, conference servers, etc. 253 4. Mapping SIP Device Types to B2BUA Roles 255 Although the B2BUA role types defined previously do not define a 256 system type, as discussed in section 3, some discussion of what 257 common system types perform which defined roles may be appropriate. 258 This section provides such a 'mapping' for general cases, to aid in 259 understanding of the roles. 261 4.1. SIP PBXs and Softswitches 263 SIP-enabled Private Branch eXchanges (SIP PBXs) and Softswitches are 264 market category terms, and not specified in any standard. In 265 general they can perform every role described in this document at 266 any given time, based on their architecture or local policy. Some 267 are based on architectures that make them the equivalent of a SIP 268 UAS and UAC connected with a logical PRI loopback; others are built 269 as a SIP Proxy core with optional modules to "do more". 271 4.2. Application Servers 273 Application Servers are a broad marketing term, and not specified in 274 any standard in general, although 3GPP and other organizations 275 specify some specific Application Server functions and behaviors. 276 Common examples of Application Servers functions are message-waiting 277 indication, find-me-follow-me services, privacy services, call- 278 center ACD services, call screening, and VCC services. Some only 279 operate in the signaling plane in either Poxy-B2BUA or Signaling- 280 only B2BUA roles; others operate as full Media-termination B2BUAs, 281 such as when providing IVR, rich-ringtone or integrated voicemail 282 services. 284 4.3. Session Border Controllers 286 Session Border Controllers (SBCs) are a market category term, and 287 not specified in any standard. Some of the common functions 288 performed by SBCs are described in [RFC5853], but in general they 289 can perform every role described in this document at any given time, 290 based on local policy. By default, most SBCs are either Media-relay 291 or Media-aware B2BUAs, and replace the Contact URI, remove the Via 292 and Record-Route headers, modify the Call-ID, To, From, and various 293 other headers, and modify SDP. Some SBCs remove all headers, all 294 bodies, and reject all Method types unless explicitly allowed by 295 local policy; other SBCs pass all such elements through unless 296 explicitly forbidden by local policy. 298 4.4. Transcoders 300 Transcoders perform the function of transcoding one audio or video 301 media codec type to another, such as G.711 to G.729. As such they 302 perform the Media-termination role, although they may only terminate 303 media in specific cases of codec mismatch between the two ends. 304 Although [RFC5369] and [RFC5370] define two types of SIP 305 Transcoders, in practice a popular variant of the [RFC5370] inline 306 model is to behave as a SIP B2BUA without using the resource-list 307 mechanism, but rather simply route a normal INVITE request through 308 an inline transcoder. SIP Transcoders architectures are based on 309 everything from SIP media servers, to SBCs, to looped-back TDM 310 gateways, and thus run the gamut from replacing only specific 311 headers/bodies and SDP content needed to perform their function, to 312 replacing almost all SIP headers and SDP content. Some transcoders 313 save and remove SDP offers in INVITEs form the UAC, and wait for an 314 offer in the response from the UAS, similar to a 3PCC model; others 315 just insert additional codecs in SDP offers and only transcode if 316 the inserted codec(s) are selected in the answer. 318 4.5. Conference Servers 320 In general Conference Servers do not fall under the term 'B2BUA' as 321 defined by this document, since typically they involve multiple SIP 322 UACs initiating independent SIP sessions to the single conference 323 server UAS. However, a conference server supporting [RFC5366], 324 whereby the received INVITE triggers the conference focus UAS to 325 initiate multiple INVITEs as a UAC, would be in a Media-termination 326 B2BUA role when performing that function. 328 4.6. P-CSCF and IBCF Functions 330 Proxy-CSCFs and IBCFs are functions defined by 3GPP IMS standards, 331 and when coupled with the IMS media-plane gateways (IMS AGW, TrGW, 332 etc.) typically form a logical Media-relay or Media-aware B2BUA 333 role. 335 4.7. S-CSCF Function 337 S-CSCF is a function defined by 3GPP IMS standards, and typically 338 follows a Proxy-B2BUA role. 340 5. Security Considerations 342 There are no security implications for this document, as it is only 343 a taxonomy. 345 6. IANA Considerations 347 This document makes no request of IANA. 349 7. Acknowledgments 351 Funding for the RFC Editor function is provided by the IETF 352 Administrative Support Activity (IASA). 354 8. References 356 8.1. Informative References 358 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 359 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 360 Session Initiation Protocol", RFC 3261, June 2002. 362 [RFC3323] Peterson, J., " A Privacy Mechanism for the Session 363 Initiation Protocol (SIP)", RFC 3323, November 2002. 365 [RFC4733] Schulzrinne, H., Taylor, T., "RTP Payload for DTMF Digits, 366 Telephony Tones, and Telephony Signals", RFC 4733, December 2006. 368 [RFC5366] Camarillo, G., Johnston, A., "Conference Establishment 369 Using Request-Contained Lists in the Session Initiation Protocol 370 (SIP)", RFC 5366, October 2008. 372 [RFC5369] Camarillo, G., "Framework for Transcoding with the Session 373 Initiation Protocol (SIP)", RFC 5369, October 2008. 375 [RFC5370] Camarillo, G., "The Session Initiation Protocol (SIP) 376 Conference Bridge Transcoding Model", RFC 5370, October 2008. 378 [RFC5853] Hautakorpi, J, et al, "Requirements from Session 379 Initiation Protocol (SIP) Session Border Control (SBC) Deployments", 380 RFC 5853, April 2010. 382 Author's Address 384 Hadriel Kaplan 385 Acme Packet 386 Email: hkaplan@acmepacket.com