idnits 2.17.1 draft-ejzak-mmusic-bg-bypass-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 6) being 59 lines 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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (December 17, 2008) is 5609 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4566 (ref. '7') (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 2617 (ref. '10') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 5389 (ref. '18') (Obsoleted by RFC 8489) == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-12 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Ejzak 3 INTERNET-DRAFT Alcatel-Lucent 4 Intended status: Informational December 17, 2008 5 Expires: June 17, 2009 7 Extension to the Session Description 8 Protocol (SDP) for Bypass of Border Gateways 9 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 19 Internet-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/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 34 This document describes an extension to the Session Description 35 Protocol (SDP) that can be used by systems of cooperating networks 36 using Application Level Gateways (ALG) to insert border gateways 37 performing as Network Address Port Translators (NAPT) between their 38 IP realms to identify when border gateways can be bypassed for more 39 efficient media flow. This extension can be used by networks based 40 on a protocol using the SDP offer/answer model, such as the IP 41 Multimedia Subsystem (IMS) of the Third Generation Partnership 42 Project (3GPP), which is based on the Session Initiation Protocol 43 (SIP). ALGs using this extension can determine within a single SDP 44 offer/answer transaction when the insertion of a new border gateway 45 would cause the media path to re-enter an IP realm visited elsewhere 46 within the media path, and to bypass one or more border gateways 47 that would otherwise be included in the media path. This extension 48 also works with hosted NAPT traversal schemes to establish a direct 49 media path between endpoints within the same IP realm. Optional 50 procedures provide additional means to improve media flow. 52 Table of Contents 54 1. Introduction....................................................3 55 2. Applicability Statement.........................................5 56 3. Conventions and Acronyms........................................6 57 4. Overview of Operation...........................................6 58 4.1. Overview of Operation of Base Algorithm....................6 59 4.2. Overview of Operation of the Active-Bypass Option..........9 60 5. IP realm considerations........................................12 61 6. ALG procedures.................................................13 62 6.1. ALG handling of SDP offer.................................13 63 6.1.1. SDP offer case 1: bypass controlled BG and prior BGs.14 64 6.1.2. SDP offer case 2: bypass controlled BG...............15 65 6.1.3. SDP offer case 3: bypass prior BGs...................15 66 6.1.4. SDP offer case 4: bypass no BGs......................16 67 6.2. ALG handling of SDP answer in base algorithm..............17 68 6.2.1. SDP answer sub-case a: valid connection information..18 69 6.2.2. SDP answer sub-case b: match on other IP realm.......19 70 6.2.3. SDP answer sub-case c: match on forwarded SDP offer..20 71 6.2.4. SDP answer sub-case d: match on received SDP offer...20 72 6.2.5. SDP answer sub-case e: match on own secondary-realm..21 73 6.2.6. SDP answer sub-case f: no match......................22 74 6.3. ALG procedures for Active-Bypass Option...................22 75 6.3.1. Anchor ALG sends an alternate path request...........22 76 6.3.2. Target ALG processing of alternate path request......23 77 6.3.3. Anchor ALG processing of SDP offer from Target ALG...24 78 6.3.4. Other ALG processing of SDP answer in original dialog 26 79 6.3.5. Target ALG processing of SDP answers.................26 80 6.3.6. Release of alternate path dialog.....................27 81 6.4. Special handling of unspecified address from endpoints....28 82 6.5. Assumptions about non-compliant ALGs......................28 83 6.6. Operation in the presence of forking......................30 84 7. The visited-realm and secondary-realm attributes...............30 85 8. Security Considerations........................................35 86 9. IANA Considerations............................................35 87 9.1. visited-realm Attribute...................................36 88 9.2. secondary-realm Attribute.................................36 89 10. References....................................................37 90 10.1. Normative References.....................................37 91 10.2. Informative References...................................37 92 1. 93 Introduction 95 The IP Multimedia Subsystem (IMS) [20] [21] and other SIP networks 96 have the option to deploy border gateways between the IP realms 97 defined by each network. Within an IP realm every endpoint is 98 reachable from any other endpoint using a common address space. 99 Each border gateway typically provides a firewall or Network Address 100 Port Translator (NAPT) [13] to limit access to endpoints within a 101 realm. An Application Layer Gateway (ALG) controls each border 102 gateway to allocate new IP addresses and ports as necessary for each 103 SDP media line and updates the SDP connection and port information 104 in each forwarded SDP offer and answer to effectively insert the 105 border gateway into each end-to-end multimedia stream. 107 The media path associated with a multimedia stream may traverse an 108 arbitrary number of IP realms between endpoints. As long as each 109 border gateway in the media path has no connection to IP realms on 110 the media path other than its two directly connected IP realms, 111 there is no option to optimize the media path using the allocated 112 border gateway resources. But if either endpoint or any border 113 gateway on the path has direct access to one of the other IP realms 114 on the path, then a shorter media path exists. A sequence of ALGs 115 implementing the procedures herein, where each ALG can determine the 116 IP address and port information for entities on the media path in 117 its interconnected IP realms, will be able to establish a media path 118 with the minimum number of border gateways without compromising any 119 of the access controls associated with the border gateways on the 120 path. If one or more ALGs on the signaling path do not implement 121 the procedures then border gateway bypass can still occur but some 122 potentially bypassable border gateways may remain in the media path. 124 The procedures described herein also include an "active-bypass" 125 option to attempt to find a shorter media path segment between 126 existing border gateways associated with the path. This option 127 requires additional SIP signaling to establish a SIP dialog for each 128 alternate media path segment candidate, whereas the base algorithm 129 works by adding information to existing SDP offer/answer messages. 130 Due to this additional signaling overhead, this option should only 131 be used when it can be determined that dramatic improvement is 132 possible for a media path segment. 134 This extension also works with hosted NAPT traversal schemes to 135 establish a direct media path between endpoints within the same IP 136 realm. If the endpoints are in different IP realms, this extension 137 cannot bypass an ALG/BG that is coordinating the traversal of a 138 Residential Gateway (RG) NAPT, although it is possible that a 139 combination of NAPT traversal techniques can achieve this. This 140 document does not analyze combination methods to address this 141 limitation. Since networks using ALG/BGs typically perform other 142 media path functions at the ALG/BG configured to traverse the 143 RG/NAPT, this is not a significant limitation. 145 RFC 3264 [3] describes the SDP offer/answer model, which enables SIP 146 networks to establish end-to-end media paths for the multimedia 147 streams in each session. This document describes two SDP extension 148 attributes and some extensions to ALG procedures for forwarding SDP 149 offers and answers. ALGs on the path manipulate the SDP as 150 necessary within a single end-to-end SDP offer/answer transaction to 151 enable establishment of an end-to-end media path with the minimum of 152 border gateways. The SDP extension attributes describe media 153 connection and port information for each IP realm on the path that 154 is a candidate to bypass one or more border gateways on the path. 156 This document describes an extension and optimization of the ALG 157 approach to NAPT traversal. Other options for NAPT traversal 158 include the Middlebox Control Protocol [14], Session Traversal 159 Utilities for NAT (STUN) [18], the STUN Relay Usage [19], and Realm 160 Specific IP [11] [12]. The most recent and comprehensive approach 161 to NAPT traversal is Interactive Connectivity Establishment (ICE) 162 [17], which uses STUN to identify candidate addresses for NAPT 163 traversal for media streams established by the offer/answer model. 165 While an ALG approach may require the insertion of a SIP back to 166 back user agent (B2BUA) to modify SDP whenever a border gateway is 167 inserted in the media path, ICE also has several disadvantages. ICE 168 requires the deployment of STUN servers in each IP realm, a means of 169 advertising the location of available STUN servers to SIP endpoints, 170 extra signaling to discover candidate addresses for inclusion in SDP 171 offers and answers, extra signaling to communicate the selected 172 connection information, and implementation of the ICE procedures in 173 the endpoints. With ICE, border gateways must be configured to 174 allow signaling between endpoints and STUN servers, and do not 175 receive definitive information on which ones are actually used and 176 which remote addresses will be used in the RTP [15] stream. This 177 makes it difficult for border gateways to limit access to known IP 178 source addresses and to predict bandwidth usage, which are two 179 important reasons for deploying border gateways. 181 The border gateway bypass procedures in this document, while 182 requiring the use of ALGs, avoid the requirement to deploy STUN 183 servers, require no additional signaling beyond what is needed for a 184 single end-to-end SDP offer/answer transaction (although an optional 185 procedure does generate additional signaling), require no new 186 procedures to be supported by endpoints, allow border gateways to 187 limit access to known IP source addresses, and allow border gateways 188 to predictably manage aggregate bandwidth usage for all sessions. 190 Since this extension does not incorporate end-to-end connectivity 191 checks of the media path, it requires accurate provisioning of the 192 IP realms. 194 2. 195 Applicability Statement 197 The use of this extension is only applicable inside a "Trust Domain" 198 as defined in RFC 3325 [4]. Nodes in such a Trust Domain are 199 explicitly trusted by its users and end-systems to inspect and 200 manipulate SDP messages as necessary to traverse and/or bypass 201 firewalls and NATS while limiting access from unauthorized sources 202 to endpoints in IP realms associated with the Trust Domain. 204 Since the procedures in this document include an option to 205 cryptographically certify the candidate connection and port 206 information from each IP realm, they can be used under some 207 circumstances when the signaling traverses non-trusted networks or 208 the Internet at large. 210 This extension requires that ALGs on the signaling path have the 211 ability to access and manipulate SDP messages, which is inconsistent 212 with the general recommendation that these messages be encrypted and 213 integrity protected end-to-end. 215 In the interest of algorithmic simplicity, this extension finds 216 improved media paths in most cases according to the available 217 information, but not under all circumstances. 219 This document does NOT offer a general model for optimal 220 configuration of border gateways in the Internet at large. 222 This extension assumes that there is at most a single set of 223 connection and port information for each SDP media line, consistent 224 with existing RFCs. Possible future SDP extensions that allow 225 description of alternative connection or port capabilities may not 226 be compatible. 228 This extension makes some assumptions about the behavior of ALGs not 229 implementing the extension that may not always be valid. See 230 section 6.5 for a discussion of the compatibility issues and work- 231 arounds. The extension also has some limitations when handling an 232 unspecified address as connection information from an endpoint. See 233 section 6.4. 235 Despite these limitations, there are sufficiently useful specialized 236 deployments that meet the assumptions described above, and can 237 accept the limitations that result, to warrant publication of this 238 mechanism. An example deployment would be an IMS network using 239 border gateways to interconnect multimedia sessions with other 240 networks. 242 3. 243 Conventions and Acronyms 245 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 246 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 247 document are to be interpreted as described in RFC 2119 [1]. 249 The following acronyms are used in this document: 251 3GPP - the Third Generation Partnership Project 252 3pcc - Third Party Call Control [16] 253 ABNF - Augmented Backus-Naur Form [6] 254 ALG - Application Layer Gateway [13] 255 B2BUA - Back to Back User Agent [2] 256 BG - Border Gateway 257 FQDN - Fully Qualified Domain Name 258 GRUU - Globally Reachable UA URI [8] 259 ICE - Interactive Connectivity Establishment [17] 260 IMS - Internet Protocol Multimedia Subsystem [20] [21] 261 IP - Internet Protocol 262 IPSEC - IP Security 263 IPv4 - IP Version 4 264 IPv6 - IP Version 6 265 LAN - Local Area Network 266 MD5 - Message-Digest 5 Algorithm [9] 267 NAT - Network Address Translation [13] 268 NAPT - Network Address Port Translation [13] 269 RG - Residential Gateway 270 RTCP - RTP Control Protocol [15] 271 RTP - Real-time Transport Protocol [15] 272 SDP - Session Description Protocol [7] 273 SIP - Session Initiation Protocol [2] 274 SP - Space 275 STUN - Session Traversal Utilities for NAT [18] 276 TCP - Transport Control Protocol 277 UA - User Agent [2] 278 UDP - User Datagram Protocol 279 URI - Uniform Resource Identifier 280 WGS - World Geodetic System [24] 282 4. 283 Overview of Operation 285 4.1. 286 Overview of Operation of Base Algorithm 287 Figure 1 shows a typical call configuration between endpoints UA1 288 and UA2, where the SIP signaling goes between the UAs via at least 289 one ALG (four are shown) and other SIP servers not shown, and one 290 RTP multimedia stream goes between the UAs via the BGs and possibly 291 an RG associated with each UA (only one RG is shown associated with 292 UA2). Each BG is controlled by its corresponding ALG. R1, R2, 293 etc., in the figure represent the IP realms associated with each 294 segment of the media path. 296 The media path for each multimedia stream between the UAs is 297 established via an end-to-end SDP offer/answer exchange where each 298 ALG may choose to modify the connection and port information 299 associated with each media line in the SDP to insert its BG in the 300 media path according to normal ALG procedures. Each ALG may also 301 perform the base algorithm procedures to identify when one or more 302 BGs and/or RGs can be bypassed and to modify the forwarded SDP 303 messages to implement the corresponding changes in the media path to 304 bypass the BGs. 306 +----+ +----+ +----+ +----+ 307 |ALG1|---|ALG2|---|ALG3|---|ALG4| 308 /+----+ +----+ +----+ +----+\ 309 / | | | | \ 310 +---+/ | | | | \+---+ +---+ 311 |UA1| +----+ +----+ +----+ +----+ |RG |---|UA2| 312 | |---|BG1 |---|BG2 |---|BG3 |---|BG4 |---| |---| | 313 +---+ +----+ +----+ +----+ +----+ +---+ +---+ 315 |<--R1-->|<--R2-->|<--R3-->|<--R4-->|<--R5-->|<--R6-->| 317 Figure 1: Example Call Configuration 319 Figure 2 shows another example call configuration where secondary 320 BGs are used to establish a media path with fewer BGs. ALG1 through 321 ALG5 initially allocate BG1a, BG2, BG4, BG4 and BG5a as ALGs forward 322 the initial SDP offer towards UA2 from UA1. These BGs enable 323 traversal of unique IP realms R1 through R6 (not labeled in the 324 figure). Since these BGs do not create any loop in the media path, 325 there is no possibility to bypass any of them if the algorithm is 326 limited to finding loops in a fixed media path. 328 +----+ +----+ +----+ +----+ +----+ 329 |ALG1|---|ALG2|---|ALG3|---|ALG4|---|ALG5| 330 /+----+ +----+ +----+ +----+ +----+\ 331 / | | | | | | | \ 332 +---+/ | | | | | | | \+---+ 333 |UA1| +----+| +----+ +----+ +----+ |+----+ |UA2| 334 | |-|BG1a|-----|BG2 |---|BG3 |---|BG4 |-----|BG5a|-| | 335 +---+ +----+| +----+ +----+ +----+ |+----+ +---+ 336 \ | | / 337 \ +----+ +----+ / 338 \---|BG1b|----------------------------|BG5b|---/ 339 +----+ +----+ 341 Figure 2: Example Configuration using Secondary BGs 343 While forwarding the initial SDP, if an ALG along the way, such as 344 ALG1, controls BG(s) that have access to IP realm(s) other than 345 those IP realms that it controls on the default media path (i.e., 346 not R1 or R2), then the ALG can advertise its ability to access 347 additional IP realm(s) by including information about them in the 348 forwarded SDP. 350 If a subsequent ALG (e.g., ALG5) determines that it controls a BG 351 (e.g., BG5b) that has a direct connection to an IP realm accessible 352 from a BG controlled by a previous ALG in the path (e.g., ALG1 and 353 BG1b), then the ALG may choose to use this alternative media path if 354 it appears to be an improvement over the initial path. In this 355 example, the algorithm establishes an alternative media path from 356 UA1 to UA2 via BG1b and BG5b while significantly reducing the number 357 of BGs traversed. Note that the IP realm between BG1b and BG5b in 358 the example (R7) will not match any of the IP realms R1 through R6. 359 If the connections exist, the algorithm may also generate 360 alternative paths either via BG1a and BG5b, via BG1b and BG5a, or 361 via BG1a and BG5a, for example (not shown). 363 The border gateway bypass base algorithm and active-bypass option 364 (described in the next section) assume ICE is not used by any entity 365 in the architecture. Although hybrid procedures are possible, they 366 are beyond the scope of this document. 368 It is assumed that the UAs participate in standard SDP offer/answer 369 negotiation by presenting standard connection and port information 370 for each media line according to RFC 4566 [7], RFC 3264 [3] and 371 possibly other extensions. If necessary, the ALGs may use the rtcp 372 attribute defined in RFC 3605 [5] to identify an RTCP port not using 373 the expected default value. 375 The border gateway bypass base algorithm and the active-bypass 376 option are may be implemented only within the ALGs. The procedures 377 have no impact on any aspect of SDP offer/answer negotiation other 378 than the connection and port information associated with each media 379 line. 381 This document defines an SDP extension attribute 'visited-realm' 382 that provides connection and port information for a prior IP realm 383 visited on the signaling path. Each instance of visited-realm has 384 an instance number, realm identifier, connection/port data, and 385 optional cryptographic signature computed using an algorithm private 386 to each IP realm so as to ensure the integrity of the visited-realm 387 data. 389 This document also defines an SDP extension attribute 'secondary- 390 realm' that provides connection and port information for secondary 391 IP realms associated with the signaling path. The secondary-realm 392 attribute includes the same types of information as the visited- 393 realm attribute. 395 Note that the connection and port information in each SDP 396 offer/answer transaction within a SIP dialog must be handled the 397 same way, as described in this document, re-allocating and de- 398 allocating BGs as necessary with each SDP offer/answer transaction 399 to accommodate any potential changes in the IP realms associated 400 with the session endpoints. 402 4.2. 403 Overview of Operation of the Active-Bypass Option 405 Figure 3 shows an example of the use of the base algorithm with the 406 active-bypass option. If the initial BG allocations traversing IP 407 realms R1 through R6 do not offer an opportunity to bypass any BGs 408 (as in figure 2), and if no connections exist to offer any of the 409 alternative options available in the base algorithm, then the 410 active-bypass option can discover additional alternative(s). Note 411 that in this case BG1b and BG5b do not share a common IP realm (in 412 fact, all of the IP realms are different in this example), so the 413 active-bypass option creates a new signaling path via ALG6 to 414 establish a new media path segment via BG6. 416 +----+ 417 /--------|ALG6|----------------\ 418 / +----+ \ 419 / | \ 420 +----+ +----+ | +----+ +----+ +----+ 421 |ALG1|---|ALG2|---|ALG3|---|ALG4|---|ALG5| 422 /+----+ +----+ | +----+ +----+ +----+\ 423 / | | | | | | | | \ 424 +---+/ | | | | | | | | \+---+ 425 |UA1| +----+| +----+ | +----+ +----+ |+----+ |UA2| 426 | |-|BG1a|-----|BG2 |---|BG3 |---|BG4 |-----|BG5a|-| | 427 +---+ +----+| +----+ | +----+ +----+ |+----+ +---+ 428 \ | | | / 429 \ +----+ +----+ +----+ / 430 \---|BG1b|-------|BG6 |---------------|BG5b|---/ 431 +----+ +----+ +----+ 433 Figure 3: Example Configuration with Active-Bypass Option 435 When implementing the active-bypass option, the following additional 436 information may be included in each visited-realm and secondary- 437 realm attribute generated by the base algorithm for an SDP offer, if 438 available: the approximate geo-location of the corresponding BG; the 439 approximate delay of IP packets on the previous media path segment 440 between this BG and the immediately preceding BG or endpoint; the 441 approximate packet loss rate on the same media path segment; and if 442 the ALG is reachable via a globally unique host name, then a 443 globally reachable address of the ALG with a unique instance id for 444 the corresponding SIP dialog and media line, in the form of a 445 temporary GRUU [8]. 447 Each ALG should include the geo-location, delay and loss information 448 in the first visited-realm attribute generated for an SDP offer, and 449 may include them for other visited-realm or secondary-realm 450 attributes if the information differs significantly from the first. 451 Each ALG may include the GRUU in the first visited-realm attribute 452 generated for a media line in an SDP offer. There is no need to 453 repeat the GRUU in subsequent visited-realm or secondary-realm 454 attributes for the same media line. 456 When processing the SDP answer in the second phase of the base 457 algorithm, after determining which BGs (if any) are to be bypassed 458 as a result of the base algorithm, each ALG that still controls a BG 459 determines if there is the possibility that a significantly shorter 460 media path segment can be established via another ALG reachable via 461 a GRUU. Each ALG makes this determination based on the available 462 geo-location, delay and packet loss information associated with each 463 BG and media path segment. 465 If an ALG determines that it may be able to establish a shorter 466 media path segment, the ALG (e.g., ALG5) sends a SIP INVITE request 467 to the "best" ALG reachable via a GRUU (e.g., ALG1) to establish a 468 separate dialog and corresponding alternate media path segment 469 (e.g., via ALG6 and BG6). If the ALG is successful in establishing 470 the alternate media path segment and it appears to be significantly 471 better than the corresponding one determined by the base algorithm, 472 then the ALGs instruct the BGs to insert the shorter path segment 473 into the overall media path. 475 Figure 4 shows a call flow that corresponds to the configuration in 476 figure 3. 478 UA1 ALG1 ALG2 ALG6 ALG3 ALG4 ALG5 UA2 479 | | | | | | | | 480 |(1a)SDP| | | | | | 481 | Offer|(1b) |(1c) | |(1d) |(1e) |(1f) | 482 |------>|------>|-------------->|------>|------>|------>| 483 | | | | | |(3a) |(2a)SDP| 484 | | | | | | empty | Answer| 485 | | |(3b) | | | Invite|<------| 486 | |<--------------|<----------------------| | 487 | |(4a) | | | | | | 488 | | 200 OK| | | | | | 489 | | w/ SDP| | | | | | 490 | | Offer| |(4b) | | | | 491 | |-------------->|---------------------->| | 492 | | | | | |(5a) | | 493 | | | | | | ACK | | 494 | | | | | | w/ SDP| | 495 | | |(5b) | | | Answer| | 496 | |<--------------|<----------------------| | 497 | | | | | | | | 498 |(2f) |(2e) | |(2d) |(2c) |(2b) | | 499 |<------|<------|<--------------|<------|<------| | 500 | | | | | | | | 502 Figure 4: Example Flow with Active-Bypass Option 504 Steps 1a to 1f describe the progression of SDP offers via the ALGs 505 from UA1 to UA2 and steps 2a to 2f describe the corresponding 506 progression of SDP answers according to the base algorithm. After 507 step 2a, ALG5 determines that it may be able to establish a shorter 508 media path segment via ALG1 and sends an empty SIP INVITE request to 509 ALG1 via ALG6 in steps 3a and 3b. Steps 4a, 4b, 5a and 5b describe 510 a new SDP offer/answer transaction between ALG1 and ALG5 via ALG6 511 which attempts to establish an alternate media path segment. If an 512 alternate media path segment is successfully established and is a 513 significant improvement, ALG5 signals the selection of the alternate 514 media path segment to ALG1 in steps 2b through 2e. ALG1 515 incorporates the alternate media path segment into the media path 516 for the primary dialog before forwarding the final SDP answer to UA1 517 in step 2f. 519 5. 520 IP realm considerations 522 For the procedures in this specification, the term "IP realm" has a 523 specific meaning beyond the use of the term "realm" for digest 524 authentication [10]. An IP realm has two purposes: 1) to identify a 525 private means by which network entities sharing private information 526 can verify that data communicated via intermediaries remains 527 unchanged; and 2) to identify when one network entity is reachable 528 from another via a fully interconnected common IP address space. 530 The syntax for the visited-realm and secondary-realm extension 531 attributes in section 7 clearly describes means of accomplishing 532 purpose 1) using security credentials. 534 There are many network configurations for which 2) is applicable, as 535 described below. 537 For example, all hosts in a residence on a private LAN behind an 538 RG/NAPT can be considered to be in their own IP realm. An operator 539 providing hosted NAPT traversal from an ALG in the network can 540 identify a separate IP realm for each such residence and provide the 541 security framework to ensure, for example, that it is possible to 542 provide a media path directly between hosts in the same residence 543 when they are involved in an end-to-end session established via SIP 544 servers in an external network, thus bypassing a potentially 545 significant number of BGs that would otherwise have been allocated 546 using normal ALG procedures. 548 A very similar example is when there is a private enterprise network 549 using a private IP address space with one or more NAPTs to external 550 networks. The same principles apply as in the residential case. An 551 ALG providing hosted NAPT traversal creates an IP realm for the 552 enterprise, associates the appropriate IP addresses from the 553 enterprise IP realm with a selected identifier and looks for 554 opportunities to bypass BGs in the network. 556 Session endpoints not associated with NAPTs may also be directly 557 connected to an ALG in the network. Those mutually reachable 558 endpoints connected to an ALG may be assigned an IP realm. 560 Once a media path enters a network isolated with ALGs from access 561 and peer networks, all addresses associated with media connections 562 to BGs that are mutually reachable within the network can be 563 considered part of another IP realm. Whenever an ALG forwards an 564 SDP offer back into such an IP realm after visiting it on a prior 565 hop, there is an opportunity to bypass all BGs visited on the "loop" 566 back into the IP realm. 568 Two interconnected networks may have ALG/BGs directly connected via 569 IPSEC associations over the Internet. There may be one or more IP 570 realms created just to identify these limited connectivity options. 571 Since there will be limited opportunities to bypass BGs via these IP 572 realms, a network MAY choose to leave these IP realms unidentified 573 and MAY choose not to forward visited-realm or secondary-realm 574 information for these IP realms. 576 IP addresses reachable from the open internet are associated with 577 the pre-defined IP realm "IN". 579 These are just a few examples of IP realms. Since no connectivity 580 checks are used to verify reachability, IP realms MUST be 581 provisioned to correctly identify mutually reachable IP addresses. 582 It is RECOMMENDED that networks provide other means to verify 583 reachability between endpoints in their defined IP realms. 585 6. 586 ALG procedures 588 The ALG procedures apply in this section SHALL apply separately to 589 each media line with non-zero port value in each SDP message, and 590 SHALL apply separately to each SDP offer/answer transaction. 592 6.1. 593 ALG handling of SDP offer 595 When an ALG receives an SDP offer from a UA or another ALG, it first 596 determines the IP realm for the outgoing segment of the media path 597 associated with the outgoing signaling. For example, in Figure 1, 598 if UA1 initiates an SDP offer towards UA2, then the outgoing IP 599 realm for ALG1 is R2, the outgoing IP realm for ALG2 is R3, and the 600 outgoing IP realm for ALG4 is R6 (rather than R5). Since ALG4 is 601 managing the traversal of the RG to R6, BG4 and IP realm R5 are not 602 eligible for bypass, unless both media path IP endpoints are in the 603 same IP realm R6, so that all BGs and RGs in the media path are 604 bypassed. 606 The ALG examines all previously visited IP realms represented by the 607 visited-realm and secondary-realm instances for the media line in 608 the received SDP offer. If the outgoing IP realm matches any of the 609 visited-realm or secondary-realm instances, then the ALG can bypass 610 one or more BGs, including the one it controls. The ALG SHOULD 611 select the earliest matching IP realm and determine the number of 612 BGs that can be bypassed by substituting the connection and port 613 information from this earliest IP realm into the forwarded SDP 614 offer. 616 The ALG then determines if a BG under its control has access both to 617 the outgoing IP realm and to an IP realm associated with a prior 618 visited-realm or secondary-realm instance in the received SDP offer. 619 In this case the ALG may be able to bypass one or more BGs, but not 620 the one it controls. The ALG SHOULD select the earliest IP realm 621 accessible from a BG under its control and determine the number of 622 BGs that can be bypassed by connecting the prior IP realm directly 623 to the BG. Note that in this case use of a visited-realm instance 624 associated with the immediately prior ALG is pointless since no BGs 625 are bypassed. Also note that in this case use of a secondary-realm 626 instance associated with the immediately prior ALG will not reduce 627 the number of BGs in the path, but may still result in a superior 628 media path if, for example, it can be determined that there is less 629 IP layer congestion using this path. 631 The ALG SHALL then select one of the following four cases depending 632 on applicability and local policy. 634 1. Bypass the controlled BG and one or more prior BGs. 635 2. Bypass the controlled BG. 636 3. Bypass prior BGs. 637 4. Bypass no BGs. 639 The most common local policy will be to select the case that 640 bypasses the largest number of BGs. In cases 3 and 4, the ALG MAY 641 signal that it is not to be bypassed by removing all visited-realm 642 and secondary-realm instances associated with incoming and prior IP 643 realms from the forwarded SDP offer. The ALG SHOULD signal that it 644 is not to be bypassed if it performs any necessary media function 645 other than address translation, e.g., transcoding. 647 6.1.1. 648 SDP offer case 1: bypass controlled BG and prior BGs 650 In case 1, the ALG determines that there exists a visited-realm or 651 secondary-realm instance for the media line in the received SDP 652 offer that does not match the incoming IP realm for that media line 653 but does match the IP realm to be used for the media line in the 654 forwarded SDP offer. 656 The ALG 657 1. SHALL replace the connection and port information for the media 658 line in the SDP offer with the connection and port information 659 from the earliest visited-realm or secondary-realm instance 660 associated with the outgoing IP realm; 661 2. SHALL delete every visited-realm or secondary-realm instance 662 with realm-number value higher than the one used to populate 663 the outgoing connection and port data, and 664 3. SHALL forward the modified SDP offer. 666 An example of case 1, using Figure 1 as reference, is that upon 667 receiving an SDP offer from the direction of UA1, ALG3 determines 668 that R4 and R1 are instances of the same IP realm. ALG3 substitutes 669 the connection and port information from UA1 into the outgoing SDP 670 offer and deletes the visited-realm instances for R2 and R3 from the 671 SDP before forwarding. After the end-to-end SDP offer/answer 672 transaction is completed, the media path will bypass BG1, BG2 and 673 BG3. 675 6.1.2. 676 SDP offer case 2: bypass controlled BG 678 In case 2 (bypass only the controlled BG), the ALG determines that 679 the outgoing IP realm is accessible from the incoming IP realm 680 represented by the IP connection and port information for the media 681 line in the received SDP offer. If there is a visited-realm or 682 secondary-realm instance for the incoming IP realm that matches the 683 media line in the received SDP offer (not necessarily matching the 684 incoming connection information), the ALG SHALL forward the received 685 SDP offer without change. Otherwise the ALG SHALL construct a new 686 visited-realm instance from the connection and port information for 687 the media line in the incoming SDP offer and SHALL add this visited- 688 realm instance to the SDP offer before forwarding. 690 For case 2, the received SDP offer will normally include a visited- 691 realm or secondary-realm instance that matches the incoming IP realm 692 unless the previous ALG does not support the BG bypass procedures. 693 Adding this missing information provides for more opportunities to 694 perform BG bypass. 696 6.1.3. 697 SDP offer case 3: bypass prior BGs 699 In case 3, the ALG determines that a BG under its control has access 700 both to the outgoing IP realm and to an IP realm other than the 701 incoming IP realm that matches a prior visited-realm or secondary- 702 realm instance for the media line in the received SDP offer. 704 The ALG: 705 1. SHALL use the connection and port information from the earliest 706 visited-realm or secondary-realm instance accessible from the 707 BG as the remote connection and port information for the side 708 of the BG directed towards the offerer; 709 2. SHALL replace the connection and port information for the media 710 line in the SDP offer with the connection and port information 711 from the side of its BG directed toward the answerer; 712 3. SHALL delete from the SDP answer every visited-realm and 713 secondary-realm instance with realm-number higher than the 714 realm-number for the earliest visited-realm or secondary-realm 715 instance accessible from the BG; 716 4. MAY, if the ALG requires that its BG remain in the media path, 717 remove all visited-realm and secondary-realm instances from the 718 SDP offer; 719 5. SHOULD, if the outgoing IP realm does not match any of the 720 visited-realm or secondary-realm instances in the SDP offer, 721 add to the SDP offer a visited-realm instance for the IP realm 722 associated with the connection and port information for the 723 media line in the modified SDP offer; 724 6. MAY add to the SDP offer a secondary-realm instance for each IP 725 realm that does not match any other visited-realm or secondary- 726 realm instance for the media line but for which there is a BG 727 controlled by the ALG that has access both to this IP realm and 728 to the incoming IP realm associated with the BG previously 729 allocated by this ALG and 730 7. SHALL forward the modified SDP offer. 732 An example of case 3, using Figure 1 as reference, is that upon 733 receiving an SDP offer from the direction of UA1, ALG4 determines 734 that BG4 has access to R2. ALG4 substitutes its BG connection and 735 port information into the SDP offer, uses the connection and port 736 information from the visited-realm instance for R2 as the remote 737 connection and port information for the UA1 side of BG4, deletes the 738 visited-realm instances for R3 and R4 from the SDP offer, and adds 739 the visited-realm instance for R5 before forwarding. After the end- 740 to-end SDP offer/answer transaction is completed, the media path 741 will bypass BG2 and BG3. 743 6.1.4. 744 SDP offer case 4: bypass no BGs 746 In case 4, the ALG bypasses no BGs. 748 The ALG: 749 1. SHOULD, if there is no visited-realm or secondary-realm 750 instance that matches the IP realm associated with the media 751 line in the received SDP offer and the ALG allows bypass of its 752 BG, construct a new visited-realm instance from the connection 753 and port information for the media line in the incoming SDP 754 offer and add this visited-realm instance to the SDP offer to 755 be forwarded; 756 2. SHALL replace the connection and port information for the media 757 line in the SDP offer with the connection and port information 758 from the side of its BG directed toward the answerer; 759 3. MAY, if the ALG requires that its BG remain in the media path, 760 remove all visited-realm and secondary-realm instances from the 761 SDP offer; 762 4. SHOULD, if the outgoing IP realm does not match any of the 763 visited-realm or secondary-realm instances in the SDP offer, 764 add a visited-realm instance for the IP realm associated with 765 the connection and port information for the media line in the 766 forwarded SDP offer; 767 5. MAY add to the SDP offer a secondary-realm instance for each IP 768 realm that does not match any other visited-realm or secondary- 769 realm instance for the media line but for which there is a BG 770 controlled by the ALG that has access both to this IP realm and 771 to the IP realm associated with the received SDP offer and 772 6. SHALL forward the modified SDP offer. 774 If the ALG is not performing hosted NAPT traversal on the side 775 towards the SDP offerer, the ALG SHALL use the connection and port 776 information from the incoming SDP offer as the remote connection and 777 port information for the side of the BG directed towards the 778 offerer. If the ALG is performing hosted NAPT traversal on the side 779 towards the SDP offerer, the ALG/BG MUST discover the address of the 780 RG via latching or other unspecified technique. Except for the 781 insertion of the visited-realm and secondary-realm instance(s) in 782 the outgoing SDP offer, case 4 corresponds to standard ALG behavior. 784 6.2. 785 ALG handling of SDP answer in base algorithm 787 After forwarding an SDP offer, the ALG SHALL keep information about 788 which of the four cases it selected for handling of BG bypass and 789 which visited-realm and secondary-realm instances it received and 790 added to the forwarded SDP offer. The ALG uses this information in 791 the processing of the corresponding SDP answer, but there are 792 additional sub-cases to be considered since downstream ALGs can also 793 bypass BGs already visited, and other ALGs in the path may or may 794 not support the BG bypass procedures. Note that there is at most 795 one identified instance of each IP realm (as represented by a 796 visited-realm or secondary-realm instance) in the SDP offer that 797 reaches its final destination. The ALG uses this fact to correctly 798 process the SDP answer. Unidentified IP realms represent lost 799 opportunities for BG bypass. 801 To help distinguish the additional sub-cases when processing the SDP 802 answer, the ALG SHALL insert into the connection information for the 803 media line in the forwarded SDP answer either: 1) a valid IP address 804 for the corresponding IP realm or 2) an unspecified address. For 805 this purpose the unspecified address for IPv4 is '0.0.0.0' and for 806 IPv6 is a domain name within the .invalid DNS top level domain 807 (rather than the IPv6 unspecified address '0::0'). When signaling 808 the unspecified address for the connection information, the port 809 information MUST have a non-zero value. 811 The ALG must consider the following sub-cases when receiving an SDP 812 answer: 814 a. The connection and port information for the media line in the 815 SDP answer received by the ALG is *valid* for its IP realm. 816 This IP realm matches the IP realm associated with the 817 connection and port information for the corresponding media 818 line in the SDP offer forwarded by the ALG. 819 b. The connection information for the media line in the SDP answer 820 received by the ALG is the *unspecified address*. The visited- 821 realm instance in the SDP answer matches a visited-realm or 822 secondary-realm instance previously *received* in the SDP 823 offer. 824 c. The connection information for the media line in the SDP answer 825 received by the ALG is the *unspecified address*. The visited- 826 realm instance in the SDP answer matches the IP realm 827 associated with the connection and port information for the 828 corresponding media line in the SDP offer *forwarded* by the 829 ALG, and sub-case b does not apply. 830 d. The connection information for the media line in the SDP answer 831 received by the ALG is the *unspecified address*. The visited- 832 realm instance in the SDP answer matches the IP realm 833 associated with the connection and port information for the 834 corresponding media line in the SDP offer *received* by the 835 ALG, and sub-cases b and c do not apply. 836 e. The connection information for the media line in the SDP answer 837 received by the ALG is the *unspecified address*. The visited- 838 realm instance in the SDP answer matches the IP realm 839 associated with a secondary-realm instance previously inserted 840 by the ALG in the forwarded SDP offer, and sub-cases b, c and d 841 do not apply. 842 f. The connection information for the media line in the SDP answer 843 received by the ALG is the *unspecified address*. Sub-cases b, 844 c, d and e do not apply. 846 Note that after completing the processing for the appropriate sub- 847 case, the ALG MAY release any BG resources no longer used by the 848 resulting media path. 850 6.2.1. 851 SDP answer sub-case a: valid connection information 853 In sub-case a, the ALG receives connection information for the media 854 line in the SDP answer that corresponds to a valid IP address in its 855 IP realm. The ALG behavior depends on which SDP offer case it 856 selected when forwarding the SDP offer: 858 . In case 1, since the ALG bypassed its BG and at least one prior 859 BG when forwarding the SDP offer, the ALG must forward an SDP 860 answer containing the unspecified address to signal that the 861 ALG receiving the forwarded SDP answer controls a BG that is to 862 be bypassed. The ALG SHALL construct a new visited-realm 863 instance from the connection and port information for the media 864 line in the incoming SDP answer, SHALL add this visited-realm 865 instance to the SDP answer, replacing any other visited-realm 866 instances that may appear in the SDP answer, SHALL replace the 867 connection information for the media line in the SDP answer 868 with the unspecified address, and SHALL forward the modified 869 SDP answer. 870 . In case 2, since the ALG already bypassed its BG and no others 871 in the SDP offer, it SHALL forward the received SDP answer with 872 no changes. 873 . In case 3, since the ALG already bypassed at least one prior BG 874 in the SDP offer, but did not bypass its own BG, the forwarded 875 SDP answer must contain the unspecified address to signal that 876 the ALG receiving the forwarded SDP answer controls a BG that 877 is to be bypassed. The ALG SHALL construct a new visited-realm 878 instance from the local connection and port information for the 879 side of the BG directed towards the offerer, SHALL add this 880 visited-realm instance to the SDP answer, SHALL replace the 881 connection information for the media line in the SDP answer 882 with the unspecified address, and SHALL forward the modified 883 SDP answer. 884 . In case 4, since the ALG does not bypass any BGs, the ALG SHALL 885 replace the connection and port information for the media line 886 in the SDP answer with the local connection and port 887 information for the side of its BG directed toward the offerer, 888 and SHALL forward the modified SDP answer. 890 In addition, when the controlled BG remains allocated, as in cases 3 891 and 4 with sub-case a, if the ALG is not performing hosted NAPT 892 traversal on the side towards the SDP answerer, the ALG SHALL use 893 the connection and port information from the incoming SDP answer as 894 the remote connection and port information for the side of the BG 895 directed towards the answerer. If the ALG is performing hosted NAPT 896 traversal on the side towards the SDP answerer, the ALG/BG MUST 897 discover the IP address of the RG via latching or other unspecified 898 technique. 900 6.2.2. 901 SDP answer sub-case b: match on other IP realm 903 In sub-case b, the ALG receives an unspecified address in the 904 connection information for the media line in the SDP answer. The 905 visited-realm instance in the SDP answer matches a visited-realm or 906 secondary-realm instance previously *received* by the ALG in the SDP 907 offer. Regardless which case 1-4 the ALG previously applied to the 908 SDP offer, the ALG is not required to provide a BG for the media 909 path. The ALG SHALL forward the SDP answer with no changes. 911 6.2.3. 912 SDP answer sub-case c: match on forwarded SDP offer 914 In sub-case c, the ALG receives an unspecified address in the 915 connection information for the media line in the SDP answer. The 916 visited-realm instance in the SDP answer matches the IP realm 917 associated with the connection and port information for the 918 corresponding media line in the SDP offer *forwarded* by the ALG, 919 and sub-case b does not apply. The ALG behavior depends on which 920 SDP offer case it selected when forwarding the SDP offer: 922 . Sub-case b applies exclusively to case 1. 923 . In case 2, since the ALG already bypassed its BG and no others 924 in the SDP offer, the visited-realm instance in the received 925 SDP answer also matches the IP realm associated with the 926 connection and port information for the corresponding media 927 line in the SDP offer *received* by the ALG. The ALG SHALL 928 replace the connection and port information for the media line 929 in the SDP answer with the connection and port information from 930 the visited-realm instance in the received SDP answer, SHALL 931 delete the visited-realm instance from the SDP answer, and 932 SHALL forward the modified SDP answer. 933 . In case 3, since the ALG already bypassed at least one prior BG 934 in the SDP offer, but did not bypass its own BG, the forwarded 935 SDP answer must contain the unspecified address to signal that 936 the ALG receiving the forwarded SDP answer controls a BG that 937 is to be bypassed. The ALG SHALL replace the visited-realm 938 instance for the media line in the SDP answer with a new 939 visited-realm instance constructed from the local connection 940 and port information for the side of the BG directed towards 941 the offerer, SHALL retain the unspecified address in the 942 connection information for the media line in the SDP answer, 943 and SHALL forward the modified SDP answer. 944 . In case 4, since the ALG does not bypass any BGs, the ALG SHALL 945 replace the connection and port information for the media line 946 in the SDP answer with the local connection and port 947 information for the side of its BG directed toward the offerer, 948 SHALL delete the visited-realm instance from the SDP answer, 949 and SHALL forward the modified SDP answer. 951 In addition, when the controlled BG remains allocated, as in cases 3 952 and 4 with sub-case c, the ALG SHALL use the connection and port 953 information from the visited-realm instance in the received SDP 954 answer as the remote connection and port information for the side of 955 the BG directed towards the answerer. 957 6.2.4. 958 SDP answer sub-case d: match on received SDP offer 959 In sub-case d, the ALG receives an unspecified address in the 960 connection information for the media line in the SDP answer. The 961 visited-realm instance in the SDP answer matches the IP realm 962 associated with the connection and port information for the 963 corresponding media line in the SDP offer *received* by the ALG, and 964 sub-cases b and c do not apply. The ALG bypasses its BG in all 965 cases. The ALG behavior depends on which SDP offer case it selected 966 when forwarding the SDP offer: 968 . Sub-case b applies exclusively to case 1. 969 . Either sub-case b or c applies to case 2. 970 . Sub-case b applies exclusively to case 3. 971 . In case 4, since the ALG did not bypass any BGs when processing 972 the SDP offer, it must now signal the forwarded SDP answer to 973 bypass its own BG. The ALG SHALL replace the connection and 974 port information for the media line in the SDP answer with the 975 connection and port information from the visited-realm instance 976 for the media line in the received SDP answer, SHALL delete the 977 visited-realm instance from the SDP answer, and SHALL forward 978 the modified SDP answer. 980 6.2.5. 981 SDP answer sub-case e: match on own secondary-realm 983 In sub-case e, the ALG receives the unspecified address in the 984 connection information for the media line in the SDP answer. The 985 visited-realm instance in the SDP answer matches a secondary-realm 986 instance previously inserted by the ALG in the SDP offer, and sub- 987 cases b, c and d do not apply. The ALG behavior depends on which 988 SDP offer case it selected when forwarding the SDP offer: 990 . SDP offer cases 1 and 2 do not apply since the ALG does not 991 insert secondary-realm instances into the SDP offer in these 992 cases. 993 . In case 3, since the ALG already bypassed at least one prior BG 994 in the SDP offer, but did not bypass its own BG, the forwarded 995 SDP answer must contain the unspecified address to signal that 996 the ALG receiving the forwarded SDP answer controls a BG that 997 is to be bypassed. The ALG uses the BG associated with the 998 secondary-realm instance rather than the original BG allocated 999 for the forwarded SDP offer. The ALG SHALL construct a new 1000 visited-realm instance from the local connection and port 1001 information for the side of the secondary BG directed towards 1002 the offerer, SHALL add this visited-realm instance to the SDP 1003 answer, SHALL replace the connection information for the media 1004 line in the SDP answer with the unspecified address, and SHALL 1005 forward the modified SDP answer. 1006 . In case 4, since the ALG does not bypass any BGs, the ALG SHALL 1007 replace the connection and port information for the media line 1008 in the SDP answer with the local connection and port 1009 information for the side of its secondary BG directed toward 1010 the offerer, and SHALL forward the modified SDP answer. 1012 In addition, since the secondary BG remains allocated for this sub- 1013 case, if the ALG is not performing hosted NAPT traversal on the side 1014 towards the SDP answerer, the ALG SHALL use the connection and port 1015 information from the incoming SDP answer as the remote connection 1016 and port information for the side of the BG directed towards the 1017 answerer. If the ALG is performing hosted NAPT traversal on the 1018 side towards the SDP answerer, the ALG/BG MUST discover the address 1019 of the RG via latching or other unspecified technique. 1021 6.2.6. 1022 SDP answer sub-case f: no match 1024 In sub-case f, the ALG receives an unspecified address in the 1025 connection information for the media line in the SDP answer, and 1026 sub-cases b, c, d and e do not apply. Since either there is no 1027 visited-realm instance or the instance does not match any of the 1028 listed cases, then either the unspecified address comes from the SDP 1029 answerer or the active-bypass option has been invoked by another 1030 ALG. In all cases 1-4, the ALG SHALL forward the SDP answer with no 1031 changes. 1033 6.3. 1034 ALG procedures for Active-Bypass Option 1036 During the processing of the SDP answer in the base algorithm, any 1037 ALG that still retains a BG in the media path (i.e., SDP answer sub- 1038 cases a, c or e with SDP offer cases 3 or 4) MAY choose to perform 1039 the active-bypass option as a candidate anchor ALG for an alternate 1040 media path segment. The candidate anchor ALG contacts the best 1041 candidate target ALG to mutually determine if a superior media path 1042 segment is available. 1044 6.3.1. 1045 Anchor ALG sends an alternate path request 1047 Each ALG handling one of SDP answer sub-cases a, c or e with SDP 1048 offer case 3 or 4 MAY examine the information within visited-realm 1049 and secondary-realm instances previously received in the SDP offer 1050 to determine if there is a possibility that a significantly "better" 1051 remaining path can be constructed than the one already determined by 1052 the base algorithm. In particular, the ALG examines the geo- 1053 location, delay and loss data from its BG back to the earliest ALG 1054 reachable via a GRUU to make this determination. The method of 1055 using the information to identify better paths and the threshold of 1056 improvement required (given the extra signaling needed for the 1057 active-bypass option) is a matter of local policy. 1059 For example, if the earliest ALG reachable via a GRUU controls a BG 1060 that is geographically close to the BG controlled by the determining 1061 ALG, yet there are other visited-realm or secondary-realm instances 1062 on the path between them that are geographically distant from them, 1063 then there is good reason to expect that a better media path segment 1064 exists. 1066 If a possible "better" path exists for one or more SDP media lines 1067 to the same earlier ALG, the determining ALG (now called the anchor 1068 ALG) SHALL send a SIP INVITE request without SDP to the earlier ALG 1069 (now called the target ALG). This INVITE request is called an 1070 alternate path request. This alternate path request will, if 1071 successful, result in an alternate path dialog and one or more 1072 alternate media path segments, if they have not already been 1073 established by earlier alternate path requests. This is in contrast 1074 to the original dialog, for which the anchor ALG is still processing 1075 the SDP answer. 1077 If an alternate path dialog associated with the original dialog 1078 already exists between the anchor and target ALGs, the alternate 1079 path request SHALL comprise a re-INVITE request within the existing 1080 alternate path dialog. This may occur, for example, if a previous 1081 SDP offer/answer transaction has already completed within the 1082 original dialog. Otherwise the alternate path request SHALL 1083 comprise a new INVITE request, placing the GRUU of the target ALG in 1084 the Request-URI and the GRUU of the anchor ALG in the From and P- 1085 Asserted-Identity headers. 1087 According to normal IMS routing procedures, the alternate path 1088 request may traverse one or more ALGs on its path to the target ALG. 1089 If the alternate path request fails prematurely with any non-success 1090 final response, the anchor ALG SHOULD abort the active-bypass option 1091 and continue handling of the SDP answer within the original dialog 1092 according to the base algorithm. 1094 6.3.2. 1095 Target ALG processing of alternate path request 1097 Upon receipt of an alternate path request in a new INVITE request, 1098 the target ALG SHALL identify the corresponding original dialog via 1099 the unique value of the GRUU in the Request-URI. Upon receipt of an 1100 alternate path request in a re-INVITE request, the target ALG SHALL 1101 identify the associated alternate path dialog and its corresponding 1102 original dialog. The target ALG uniquely identifies either request 1103 as an alternate path request associated with the original dialog 1104 since the assigned GRUU is the only address for which the target ALG 1105 will establish a corresponding alternate path dialog. 1107 For each SDP media line in the previously forwarded SDP offer within 1108 the original dialog for which SDP offer case 3 or 4 has been applied 1109 (i.e., the target ALG has allocated a BG for the media line), the 1110 target ALG SHALL determine the IP realm associated with the 1111 alternate path request. Then for each applicable media line, the 1112 target ALG SHALL determine whether the BG resource(s) allocated 1113 during the processing of the SDP offer for the original dialog has 1114 access to the IP realm associated with the alternate path request. 1115 If so, then the BG resource can be re-used, else the target ALG MUST 1116 allocate a new BG resource. 1118 Then the target ALG SHALL construct a new SDP offer from the SDP 1119 offer forwarded within the original dialog by: 1120 1. copying the original SDP offer; 1121 2. modifying the o line as appropriate; 1122 3. deleting all visited-realm and secondary-realm instances; 1123 4. constructing the visited-realm information for each applicable 1124 media line; 1125 5. inserting the corresponding connection and visited-realm 1126 instance information for each applicable media line and 1127 6. setting port value to zero for all other media lines. 1129 For each applicable media line in the new SDP offer, if BG resources 1130 are available with access to additional IP realms as well as access 1131 to the IP realm previously selected for the portion of the bearer 1132 path towards the original SDP offerer, the target ALG MAY construct 1133 the corresponding secondary-realm instances and add them to the 1134 media line. 1136 Then the target ALG SHALL send the constructed SDP offer to the 1137 anchor ALG in the SIP 200 OK response message according to normal 1138 SIP procedures. If the alternate path request received by the 1139 target ALG traversed one or more ALGs on its path from the anchor 1140 ALG, this new SDP offer will also traverse the same ALGs, which will 1141 recursively apply the base algorithm and optionally the active- 1142 bypass option to the SDP offer. 1144 If an error such as any of the following occurs during the 1145 processing of the alternate path request, the target ALG responds 1146 with an appropriate SIP final error response: 1147 . The target ALG does not recognize the GRUU. 1148 . There are no BG resources allocated for any media line in the 1149 original SDP offer. 1150 . The INVITE request included SDP. 1152 6.3.3. 1153 Anchor ALG processing of SDP offer from Target ALG 1154 When the anchor ALG receives the SDP offer from the target ALG in 1155 the 200 OK response, the anchor ALG SHALL apply the following 1156 procedure independently to each media line in the received SDP offer 1157 before returning the corresponding SDP offer in the ACK request 1158 towards the target ALG. 1160 If the port value is set to zero in the media line, the anchor ALG 1161 SHALL set the port value to zero in the corresponding media line in 1162 the SDP answer to be sent towards the target ALG and SHALL proceed 1163 with the base algorithm (i.e., the active-bypass option has no 1164 impact on the base algorithm for this media line). 1166 If the media line has a non-zero port value, then the anchor ALG 1167 SHALL attempt to identify the corresponding media line in the 1168 original SDP answer. There is a possibility that the order of the 1169 media lines in the received SDP offer is different from the order of 1170 the media lines in the original SDP answer due to intermediate 1171 applications performing 3rd party call control procedures to 1172 split/merge SDP media lines. If there is a visited-realm or 1173 secondary-realm instance in the received SDP offer with a GRUU for 1174 the target ALG, then this can be matched against the GRUU received 1175 for the target ALG in the original SDP offer to identify the 1176 corresponding media line. If no GRUU is present to assist in 1177 matching media lines, the anchor ALG may be able to uniquely match 1178 the media lines based on other information, e.g., only one 1179 applicable media line is common to both the original and alternate 1180 path dialogs. 1182 If the anchor ALG cannot identify the corresponding original media 1183 line for a received media line with a non-zero port value, the 1184 anchor ALG SHALL set the port value to zero in the corresponding 1185 media line in the SDP answer to be sent towards the target ALG. 1187 If the anchor ALG can identify the corresponding original media line 1188 for a received media line with a non-zero port value, the anchor ALG 1189 SHOULD use available visited-realm and secondary-realm instance 1190 information in the received SDP offer and MAY use other unspecified 1191 data to determine if the alternate media path segment is 1192 significantly "better" than the corresponding portion of the 1193 original media path. The algorithm used to assess the quality of 1194 each media path segment and to determine the minimum threshold of 1195 significance is a matter of local policy. 1197 If the anchor ALG determines that the alternate media path segment 1198 is not significantly better than the corresponding portion of the 1199 original media path, the anchor ALG SHALL set the port value to zero 1200 in the corresponding media line in the SDP answer to be sent towards 1201 the target ALG and SHALL proceed with the base algorithm. 1203 If the anchor ALG determines that the alternate media path segment 1204 is significantly better than the corresponding portion of the 1205 original media path, the anchor ALG: 1207 1. SHALL allocate BG resources for the IP realm associated with 1208 the alternate media path segment, if not already available; 1209 2. SHALL set the connection information and/or visited-realm 1210 attribute for the corresponding media line in the SDP answer 1211 in the alternate path dialog according to the recursive 1212 application of the base algorithm by choosing SDP offer case 1213 3 or 4 according to the processing of the received media line 1214 from the alternate path dialog and by applying SDP answer 1215 sub-case a, c or e from the processing of the original SDP 1216 answer; and 1217 3. SHALL modify the processing of the original SDP answer in the 1218 base algorithm as follows. 1220 For the corresponding media line of the SDP answer received during 1221 the course of the base algorithm, the anchor ALG: 1222 1. SHALL select the remote connection and port information for the 1223 side of the BG directed towards the answerer according to the 1224 SDP offer case applied to the media line in the alternate path 1225 dialog and the applicable original SDP answer sub-case; 1226 2. SHALL delete any visited-realm instance for the media line in 1227 the SDP answer; 1228 3. SHALL construct a new visited-realm instance for the special IP 1229 realm "NOMATCH" including the GRUU of the media line received 1230 from the target ALG, if available; 1231 4. SHALL add this visited-realm instance to the SDP answer; 1232 5. SHALL replace the connection information for the media line in 1233 the SDP answer with the unspecified address; and 1234 6. SHALL forward the modified SDP answer within the original 1235 dialog. 1237 6.3.4. 1238 Other ALG processing of SDP answer in original dialog 1240 After the anchor ALG forwards the original SDP answer, every other 1241 conformant ALG on the signaling path prior to the target ALG will 1242 forward the SDP answer without change according to SDP answer sub- 1243 case f of the base algorithm. 1245 6.3.5. 1246 Target ALG processing of SDP answers 1248 Upon receipt of the SDP answer within the original dialog, 1249 recognizing that it has recently received and responded to an 1250 alternate path request for this media line (and possibly others), 1251 the target ALG: 1253 1. SHALL determine if SDP answer sub-case f applies with special 1254 IP realm "NOMATCH" in the corresponding visited-realm 1255 attribute (if one is present); 1256 2. SHALL verify that the corresponding media line for the 1257 alternate path dialog is to be associated with this original 1258 media line, using either the GRUU in the received visited- 1259 realm attribute or other unspecified means; 1260 3. SHALL determine if the SDP answer for the alternate path 1261 dialog is received (in the ACK request) in a reasonable 1262 amount of time; 1263 4. SHALL determine if the port for the corresponding media line 1264 for the alternate path dialog has non-zero value and 1265 5. SHALL determine that SDP answer sub-case a, c or e applies to 1266 the corresponding media line for the alternate path dialog. 1268 If any of the above conditions do not apply, then the target ALG 1269 SHOULD continue with the normal processing of the base algorithm 1270 and mark the media line for the alternate path request as 1271 "unused". Note that some combinations of conditions (representing 1272 error cases) will fail to establish an end-to-end media path. If 1273 this occurs, the target ALG SHOULD reject subsequent alternate 1274 path requests within the original dialog and MAY apply other 1275 unspecified recovery actions. 1277 If all of the above conditions apply, the target ALG SHALL apply the 1278 applicable SDP offer case 3 or 4 and the applicable SDP answer sub- 1279 case a, c or e for the corresponding media line for the alternate 1280 path dialog to configure the BG and modify the received SDP answer 1281 for the original dialog before forwarding the SDP answer. 1283 The net result of the successful application of the procedure in 1284 sections 6.3.1 through 6.3.5 is to replace the portion of the end- 1285 to-end media path generated by the base algorithm between the target 1286 and anchor ALGs with the alternate media path segment generated by 1287 the alternate path request. 1289 6.3.6. 1290 Release of alternate path dialog 1292 The target ALG and anchor ALG SHOULD release the alternate path 1293 dialog and associated resources not otherwise needed using standard 1294 SIP procedures when either the original dialog is released or when 1295 all of the media lines for the alternate path dialog either have 1296 port value zero or are marked "unused". 1298 If the alternate path dialog is released while in use to maintain an 1299 alternate media path segment, the anchor ALG and target ALG MAY 1300 release the corresponding original dialog or perform other 1301 unspecified recovery actions. 1303 6.4. 1304 Special handling of unspecified address from endpoints 1306 If the UA initiating an SDP offer includes an unspecified address in 1307 the connection information, the unspecified address SHALL be 1308 associated with the IP realm of the UA. The ALG SHALL follow case 1 1309 when forwarding an SDP offer with an unspecified address, where it 1310 is understood that the SDP offer contains an implicit visited-realm 1311 instance with the unspecified address for every IP realm. The net 1312 result of this procedure is that if there is an unspecified address 1313 in the initial SDP offer, every ALG will forward an unspecified 1314 address. If the received SDP answer includes a valid IP address, it 1315 will be transformed into an unspecified address by the first ALG 1316 using sub-case a, and subsequent ALGs will include the unspecified 1317 address in the forwarded SDP answer using a sub-case b through f. 1318 Since this procedure does not support the use of a "black hole" 1319 address [16] to discover the connection information for the 1320 answering UA, there are some limitations to the applicability of 1321 these procedures, although none of the recommended 3pcc procedures 1322 [16] depend on the use of the "black hole" address. 1324 If the UA initiating an SDP answer includes an unspecified address 1325 in the connection information, the ALG procedures for handling of 1326 SDP answers remain unchanged, with the result that if any BGs were 1327 allocated when forwarding SDP offers, they will all be released. 1328 Each ALG SHALL treat an SDP answer with an unspecified address but 1329 without an explicit visited-realm instance as if it contains a 1330 single implicit visited-realm instance for an unknown IP realm. 1331 Thus sub-case f always applies. 1333 Note that if the initial SDP offer or initial SDP answer includes an 1334 unspecified address in the connection information, there can be no 1335 media flow until a subsequent SDP offer/answer transaction is 1336 performed using actual IP addresses from the endpoint IP realms. 1338 6.5. 1339 Assumptions about non-compliant ALGs 1341 A non-compliant ALG will usually delete unknown SDP attributes 1342 before forwarding SDP offers or answers. Such an ALG will delete 1343 any visited-realm or secondary-realm instances from the SDP offer 1344 before allocating a BG and forwarding the SDP offer, making it 1345 impossible for subsequent ALGs to bypass the allocated BG. 1346 Optimizations can still be applied independently to the portions of 1347 the end-to-end media path before and after the non-compliant ALG to 1348 successfully establish the end-to-end media path via the BG 1349 allocated by the non-compliant ALG. 1351 If a non-compliant ALG in a session signaling path does forward 1352 visited-realm and secondary-realm attributes after BG allocation, 1353 compliant ALGs retain most opportunities for BG bypass while 1354 establishing the end-to-end media path if the non-compliant ALG 1355 exhibits the following behaviors: 1357 . When receiving an SDP message with an unspecified address in 1358 the connection information, the non-compliant ALG retains the 1359 unspecified address in the forwarded SDP message. If the ALG 1360 both converts an unspecified address into a valid address and 1361 forwards visited-realm attributes, then the procedures may fail 1362 to establish a media path. The ALGs bordering a non-compliant 1363 ALG known to do this MAY implement a work-around by 1364 manipulating the signaling to keep the non-compliant ALG in the 1365 media path, although this forfeits significant opportunities 1366 for BG bypass. 1368 To keep a neighbor ALG in the path, a compliant ALG selects an 1369 applicable case or sub-case from the detailed procedures that 1370 ensures that real connection information is provided in all SDP 1371 messages destined to the neighbor ALG and to delete all 1372 visited-realm attributes in SDP messages destined to or coming 1373 from the neighbor ALG. 1375 . A non-compliant ALG will not terminate a session for which 1376 there is no media flow in its BG. The ALG must implicitly 1377 accept that its BG may be bypassed. 1379 The ALGs bordering a non-compliant ALG that is known to violate 1380 this assumption MAY implement a work-around by manipulating the 1381 signaling to keep the non-compliant ALG in the media path, 1382 although this forfeits significant opportunities for BG bypass. 1384 6.6. 1385 Operation in the presence of forking 1387 Forking has no impact on the processing of SDP offers according to 1388 either the base algorithm or the active-bypass option. 1390 When an ALG forwards an INVITE request including an SDP offer that 1391 is subsequently forked, an ALG may receive multiple SDP answers 1392 associated with the SDP offer in the early dialog state, where each 1393 SDP answer is within a separate early dialog. The ALG SHALL apply 1394 the base algorithm and the active-bypass option separately to each 1395 SDP answer associated with a forked branch. The ALG MUST retain any 1396 resources reserved during the handling of the SDP offer until a 1397 dialog is fully established or until it can receive no other forked 1398 SDP answers. If the ALG allocates a BG resource that is shared by 1399 multiple media paths created for parallel-forked dialogs, the ALG 1400 MAY apply local policy to selectively filter the media streams 1401 associated with the forked endpoints according to the gateway model 1402 of RFC 3960 [22] or RFC 5009 [23]. 1404 7. 1405 The visited-realm and secondary-realm attributes 1407 The visited-realm and secondary-realm SDP attributes are media-level 1408 attributes only. 1410 The visited-realm attribute contains an IP realm identifier and 1411 transport address for a previously visited realm that can 1412 potentially be used to bypass allocated BGs. 1414 The secondary-realm attribute contains an IP realm identifier and 1415 transport address for a secondary realm that can potentially be used 1416 to bypass allocated BGs. 1418 The syntax of these attributes is defined using Augmented BNF as 1419 defined in RFC 4234 [6]: 1421 visited-realm = "visited-realm" ":" realm-number SP 1422 realm SP 1423 nettype SP ;from RFC 4566 1424 addrtype SP ;from RFC 4566 1425 connection-address SP ;from RFC 4566 1426 port ;from RFC 4566 1427 [SP rtcp-port [SP rtcp-address]] 1428 [SP coordinates] 1429 [SP delay] 1430 [SP loss] 1431 [SP temp-gruu] 1432 [SP credentials] 1433 *(SP extension-att-name SP 1434 extension-att-value) 1436 secondary-realm = "secondary-realm" ":" realm-number SP 1437 realm SP 1438 nettype SP ;from RFC 4566 1439 addrtype SP ;from RFC 4566 1440 connection-address SP ;from RFC 4566 1441 port ;from RFC 4566 1442 [SP rtcp-port [SP rtcp-address]] 1443 [SP coordinates] 1444 [SP delay] 1445 [SP loss] 1446 [SP temp-gruu] 1447 [SP credentials] 1448 *(SP extension-att-name SP 1449 extension-att-value) 1451 realm-number = 1*DIGIT 1452 realm = non-ws-string ;from RFC 4566 1453 rtcp-port = "rtcp-port" SP port 1454 rtcp-address = "rtcp-address" SP connection-address 1455 coordinates = "coordinates" SP latitude "," longitude 1456 latitude = [ "-" ] 1*2DIGIT [ "." *DIGIT ] 1457 longitude = [ "-" ] 1*3DIGIT [ "." *DIGIT ] 1458 delay = "delay" SP delay-value 1459 delay-value = 1*DIGIT 1460 loss = "loss" SP loss-value 1461 loss-value = "-" 1*DIGIT ["." 1*DIGIT] 1462 temp-gruu = "temp-gruu" SP SIP-URI ;from RFC 3261 1463 credentials = "credentials" SP credentials-value 1464 credentials-value = non-ws-string 1465 extension-att-name = token 1466 extension-att-value = non-ws-string 1467 This grammar encodes the primary information about each visited- 1468 realm and secondary-realm instance: the sequence in which the realm 1469 was visited, the realm identity, its IP address and port, and 1470 optional geo-location, IP packet delay, IP packet loss, temporary- 1471 GRUU and security credentials: 1473 : For a visited-realm instance, realm-number is a 1474 positive decimal integer between 1 and 256 which identifies 1475 the sequence in which this visited-realm instance was 1476 visited during the forwarding of an SDP offer, compared to 1477 other visited-realm instances for the media line in the same 1478 SDP offer. It MUST start at 1 and MUST increment by 1 1479 compared to the highest existing realm-number for the media 1480 line when inserting a new visited-realm instance into an SDP 1481 offer. The realm-number can be ignored in an SDP answer 1482 since there should only be one visited-realm instance and no 1483 secondary-realm instance in an SDP answer. It is 1484 RECOMMENDED that the realm-number have value 1 in an SDP 1485 answer. For a secondary-realm instance in a forwarded SDP 1486 offer, realm-number MUST have the same value as the realm- 1487 number for the visited-realm instance created for the same 1488 media line by the same ALG for the connection information in 1489 the forwarded SDP offer. 1491 : identifies a set of mutually reachable IP endpoints 1492 that share a common IP addressing scheme. Each realm also 1493 defines a protection domain for all hosts using visited- 1494 realm or secondary-realm attribute instances for the realm, 1495 to help ensure the integrity of the remaining information in 1496 each attribute instance. A public address reachable from 1497 the open internet MAY be associated with the special realm 1498 "IN", for which no credentials are required. The special 1499 realm "NOMATCH" is used to signify a realm only reachable 1500 via an alternate media path segment created by the active- 1501 bypass option. Operators of ALGs that wish to ensure the 1502 integrity of the visited-realm instance information for 1503 their realm(s) MUST adhere to the following guidelines for 1504 creation of a realm string for their servers: 1) Realm 1505 strings MUST be globally unique. It is RECOMMENDED that a 1506 realm string contain a hostname or domain name, following 1507 the recommendation in Section 3.2.1 of RFC 2617 [10]. 2) 1508 Realm strings SHOULD present a human-readable identifier 1509 that can be rendered to a user. 1511 , and : are taken from 1512 the connection-field (c= line) of RFC 4566 [7]. They 1513 describe the IP address associated with the visited-realm 1514 instance, allowing for IPv4 addresses, IPv6 addresses and 1515 FQDNs. An IP address SHOULD be used, but an FQDN MAY be 1516 used in place of an IP address. When receiving an offer or 1517 answer containing an FQDN in an a=visited-realm attribute, 1518 if there is a match on the realm according to the procedures 1519 herein, the FQDN is looked up in the DNS using an A or AAAA 1520 record, and the resulting IP address is used for the 1521 remainder of the procedure. 1523 : is also taken from RFC 4566 [7]. It is the port 1524 associated with the visited-realm instance. Its meaning 1525 depends on the network being used for the connection- 1526 address, and on the transport protocol selected for the 1527 corresponding media line, e.g., UDP or TCP. 1529 and : taken together are semantically 1530 equivalent to the rtcp attribute defined in RFC 3605 [5]. 1531 They optionally encode the RTCP port and address information 1532 when the visited-realm instance is for an RTP stream and the 1533 RTCP port number is not exactly one greater than the port 1534 for the RTP stream at the same address. 1536 : provides the approximate geographic coordinates 1537 (geo-location) of the BG or endpoint associated with the 1538 connection information in the visited-realm or secondary- 1539 realm attribute. The "latitude" component MUST contain the 1540 decimal latitude of the identified location in the reference 1541 system WGS 84 [24]. The "longitude" component MUST contain 1542 the decimal longitude of the identified location in the 1543 reference system WGS 84 [24]. The number of decimal places 1544 indicates the precision of the value. The coordinates need 1545 only be accurate enough to estimate the minimum IP packet 1546 propogation delay between successive BGs/endpoints based on 1547 distance. The ALG SHOULD include known coordinates for each 1548 visited-realm or secondary-realm attribute in a forwarded 1549 SDP offer. The procedures in this document do not require 1550 the use of coordinates in SDP answers. 1552 : is an estimate of the delay in transporting IP 1553 packets between the controlled BG and the next BG or 1554 endpoint towards the SDP offerer (through the previous IP 1555 realm). delay-value is a positive decimal integer 1556 representing the delay in milliseconds. The ALG SHOULD 1557 include delay-value for each visited-realm or secondary- 1558 realm attribute in a forwarded SDP offer if the information 1559 is available and is significantly different from an 1560 estimated minimum value based on the coordinates of the 1561 respective BGs/endpoints. The procedures in this document 1562 do not require the use of delay-value in SDP answers. 1564 : is an estimate of the rate of IP packet loss on 1565 the link between the controlled BG and the next BG or 1566 endpoint towards the SDP offerer. loss-value is equal to 1567 log(packet-loss-rate) in negative decimal format, where 1568 packet-loss-rate is the average ratio of lost IP packets to 1569 all IP packets sent on the link. The packet-loss-rate can 1570 be reconstructed as 10**(loss-value). The ALG SHOULD 1571 include loss-value for each visited-realm or secondary-realm 1572 attribute in a forwarded SDP offer if the information is 1573 available. The procedures in this document do not require 1574 the use of loss-value in SDP answers. 1576 : is a temporary GRUU assigned uniquely by each ALG 1577 for a specific dialog and media line. Draft-ietf-sip-gruu 1578 [8] defines the format of the temporary GRUU. For each 1579 media line in a forwarded SDP offer, if the ALG supports the 1580 target ALG procedures of the active-bypass option, is 1581 reachable via a globally unique host name, and controls the 1582 BG associated with the connection information for the media 1583 line in the forwarded SDP offer, the ALG SHOULD include a 1584 temp-gruu in the corresponding visited-realm attribute 1585 generated by the ALG. See the active-bypass option 1586 procedures for use of the temp-gruu in an SDP answer. The 1587 procedures in this document do not require the use of temp- 1588 gruu in the secondary-realm attribute. 1590 : is a digital signature computed on the other 1591 contents of the attribute and other secret data. The 1592 authority for the protection domain associated with the 1593 realm MAY choose MD5 [9] or other algorithm to compute the 1594 credentials. For additional security, extension attributes 1595 (such as nonce and opaque used for digest [10]) MAY be used 1596 to link the credentials calculated on the attribute in one 1597 SDP message to prior SDP offers or answers used within a SIP 1598 dialog. Only servers within the protection domain need to 1599 verify the integrity of the attribute contents. 1601 The candidate attribute can itself be extended. The grammar allows 1602 for new name/value pairs to be added at the end of the attribute. 1603 An implementation MUST ignore any name/value pairs it does not 1604 understand. 1606 Since the connection and port information in an instance of the 1607 visited-realm attribute can only be used by a trusted node within 1608 the corresponding IP realm, the realm MAY choose to put encrypted 1609 versions of the connection-address and port information into the 1610 extension parameters while putting dummy values into the connection- 1611 address and port fields. 1613 8. 1614 Security Considerations 1616 The use of this extension is only applicable inside a "Trust Domain" 1617 as defined in RFC 3325 [4]. Nodes in such a Trust Domain are 1618 explicitly trusted by its users and end-systems to inspect and 1619 manipulate SDP messages as necessary to traverse and/or bypass 1620 firewalls and NATS while limiting access from unauthorized sources 1621 to endpoints in IP realms associated with the Trust Domain. 1623 Since the procedures in this document include an option to 1624 cryptographically certify the candidate connection and port 1625 information from each IP realm, they can be used under some 1626 circumstances when the signaling traverses non-trusted networks or 1627 the Internet at large. 1629 Since the base algorithm in this extension requires no additional 1630 signaling outside of an end-to-end SDP offer/answer exchange, it is 1631 likely to be impacted by any attack that can modify or disrupt an 1632 SDP offer/answer exchange. Such an attack could direct media to a 1633 target of a DoS attack, insert a third party into the media stream, 1634 and so on. These are similar to the general security considerations 1635 for offer/answer exchanges, and the security considerations in RFC 1636 3264 [3] apply. These require techniques for message integrity and 1637 encryption for offers and answers, which can be satisfied by the 1638 SIPS mechanism [2] or IMS security mechanisms when SIP is used. As 1639 such, the usage of hop-by-hop message integrity and encryption with 1640 this extension is RECOMMENDED. 1642 In addition to the above considerations, the active-bypass option in 1643 this extension establishes alternate path dialogs and alternate 1644 media path segments using GRUUs with values that cannot always be 1645 certified. Thus the active-bypass option is NOT RECOMMENDED for 1646 signaling that traverses non-trusted networks or the Internet at 1647 large. 1649 This extension is not consistent with end-to-end security procedures 1650 that are otherwise recommended for SDP messages. 1652 9. 1653 IANA Considerations 1655 This specification registers two new SDP attributes per the 1656 procedures of Section 8.2.4 of [7]. The required information for 1657 the registration is included here. 1659 9.1. 1660 visited-realm Attribute 1662 Contact Name: Richard Ejzak, ejzak@alcatel-lucent.com 1664 Attribute Name: visited-realm 1666 Long Form: visited-realm 1668 Type of Attribute: media level 1670 Charset Considerations: The attribute is not subject to the 1671 charset attribute. 1673 Purpose: This attribute is used in private networks employing 1674 border gateways to identify configurations in which IP 1675 realms are re-entered when establishing an end-to-end 1676 multimedia session, so that border gateways can be bypassed 1677 without compromising their role in securing access to the 1678 networks. The attribute provides a means to identify 1679 connection information for visited IP realms to help select 1680 the most optimal available path. 1682 Appropriate Values: See Section 7 of RFC XXXX [Note to RFC-ed: 1683 please replace XXXX with the RFC number of this 1684 specification]. 1686 9.2. 1687 secondary-realm Attribute 1689 Contact Name: Richard Ejzak, ejzak@alcatel-lucent.com 1691 Attribute Name: secondary-realm 1693 Long Form: secondary-realm 1695 Type of Attribute: media level 1697 Charset Considerations: The attribute is not subject to the 1698 charset attribute. 1700 Purpose: This attribute is used in private networks employing 1701 border gateways to identify configurations in which 1702 secondary IP realms are available to establish an end-to-end 1703 multimedia session, so that border gateways can be bypassed 1704 without compromising their role in securing access to the 1705 networks. The attribute provides a means to identify 1706 connection information for secondary IP realms to help 1707 select the most optimal available path. 1709 Appropriate Values: See Section 7 of RFC XXXX [Note to RFC-ed: 1710 please replace XXXX with the RFC number of this 1711 specification]. 1713 10. 1714 References 1716 10.1. 1717 Normative References 1719 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1720 Levels", BCP 14, RFC 2119, March 1997. 1721 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1722 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1723 Session Initiation Protocol", RFC 3261, June 2002. 1724 [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1725 Session Description Protocol (SDP)", RFC 3264, June 2002. 1726 [4] Jennings, C., Peterson, J. and Watson, M., "Private Extensions 1727 to the Session Initiation Protocol (SIP) for Asserted Identity 1728 within Trusted Network", RFC 3325, November 2002. 1729 [5] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 1730 Session Description Protocol (SDP)", RFC 3605, October 2003. 1731 [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1732 Specifications: ABNF", RFC 5234, January 2008. 1733 [7] Handley, M., Jacobson, V. and Perkins, C., "SDP: Session 1734 Description Protocol", RFC 4566, July 2006. 1735 [8] Rosenberg, J., "Obtaining and Using Globally Routable User 1736 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 1737 (SIP)", draft-ietf-sip-gruu-15 (RFC editor's queue), October 1738 2007. 1740 10.2. 1741 Informative References 1743 [9] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1744 1992. 1745 [10] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1746 Leach, P., Luotonen, A. and L. Stewart, "HTTP authentication: 1747 Basic and Digest Access Authentication", RFC 2617, June 1999. 1748 [11] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm 1749 Specific IP: Framework", RFC 3102, October 2001. 1750 [12] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, "Realm 1751 Specific IP: Protocol Specification", RFC 3103, October 2001. 1752 [13] Senie, D., "Network Address Translator (NAT)-Friendly 1753 Application Design Guidelines", RFC 3235, January 2002. 1754 [14] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. 1755 Rayhan, "Middlebox communication architecture and framework", 1756 RFC 3303, August 2002. 1757 [15] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 1758 "RTP: A Transport Protocol for Real-Time Applications", RFC 1759 3550, July 2003. 1761 [16] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, 1762 "Best Current Practices for Third Party Call Control (3pcc) in 1763 the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 1764 2004. 1765 [17] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 1766 Protocol for Network Address Translator (NAT) Traversal for 1767 Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (RFC editor's 1768 queue), October 2007. 1769 [18] Rosenberg, J., Mahy, R., Matthews, P. and D. Wing, "Session 1770 Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. 1771 [19] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 1772 Relays around NAT (TURN): Relay Extensions to Session Traversal 1773 Utilities for NAT (STUN)", draft-ietf-behave-turn-12 (work in 1774 progress), November 2008. 1775 [20] 3GPP "TS 23.228: IP Multimedia Subsystem (IMS); Stage 2 1776 (Release 8)", 3GPP 23.228, September 2008, 1777 ftp://ftp.3gpp.org/specs/archive/23_series/23.228/. 1778 [21] 3GPP "TS 24.229: IP Multimedia Call Control Protocol based on 1779 SIP and SDP; Stage 3 (Release 8)", 3GPP 24.229, September 2008, 1780 ftp://ftp.3gpp.org/specs/archive/24_series/24.229/. 1781 [22] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone 1782 Generation in the Session Initiation Protocol (SIP)", RFC 3960, 1783 December 2004. 1784 [23] Ejzak, R., "Private Header (P-Header) Extension to the Session 1785 Initiation Protocol (SIP) for Authorization of Early Media", 1786 RFC 5009, September 2007. 1787 [24] National Imagery and Mapping Agency, "Department of Defense 1788 World Geodetic System 1984, Third Edition", NIMA TR8350.2, 1789 January 2000. 1791 Any 3GPP document can be downloaded from the 3GPP webserver, 1792 http://www.3gpp.org/. See specifications. 1794 Author's Address 1796 Richard Ejzak 1797 Alcatel-Lucent 1798 1960 Lucent Lane 1799 Naperville, IL 60566, USA 1801 Phone: +1 630 979 7036 1802 EMail: ejzak@alcatel-lucent.com 1804 Copyright Notice 1806 Copyright (c) 2008 IETF Trust and the persons identified as the 1807 document authors. All rights reserved. 1809 This document is subject to BCP 78 and the IETF Trust's Legal 1810 Provisions Relating to IETF Documents 1811 (http://trustee.ietf.org/license-info) in effect on the date of 1812 publication of this document. Please review these documents 1813 carefully, as they describe your rights and restrictions with 1814 respect to this document. 1816 This Internet-Draft expires June 17, 2009.