idnits 2.17.1 draft-ietf-speermint-flows-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 327 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 20 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 9, 2009) is 5526 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'On-Demand' on line 693 -- Looks like a reference, but probably isn't: 'Peering' on line 536 == Unused Reference: '3' is defined on line 966, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 969, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 972, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 983, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 986, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 992, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 995, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 999, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3265 (ref. '7') (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 4234 (ref. '8') (Obsoleted by RFC 5234) == Outdated reference: A later version (-17) exists of draft-ietf-speermint-terminology-16 == Outdated reference: A later version (-15) exists of draft-ietf-sipping-nat-scenarios-08 -- Unexpected draft version: The latest known version of draft-camarillo-sipping-sbc-funcs is -05, but you're referring to -06. == Outdated reference: A later version (-14) exists of draft-ietf-sip-connect-reuse-11 Summary: 4 errors (**), 0 flaws (~~), 14 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Speermint Working Group H. Kaplan (Ed.) 3 Internet Draft Acme Packet 4 Intended status: Informational R. Penno 5 Expires: September 2009 Juniper Networks 6 D. Malas 7 CableLabs 8 S. Khan 9 Comcast 10 A. Uzelac 11 Global Crossing 12 March 9, 2009 14 SPEERMINT Routing Architecture Message Flows 15 draft-ietf-speermint-flows-05 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on September 9, 2009. 40 Copyright and License Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents in effect on the date of 47 publication of this document (http://trustee.ietf.org/license-info). 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. 51 Abstract 53 This document describes example message flows associated with the 54 SPEERMINT routing architecture, relative to various peering 55 scenarios. 57 Table of Contents 59 1. Introduction...................................................3 60 2. Definitions....................................................3 61 3. Peering Scenarios..............................................4 62 4. Legend for Message Flows.......................................6 63 5. Basic Peering Message Flow.....................................8 64 5.1. Message Examples for Basic Peering Model..................9 65 6. On-Demand Peering.............................................11 66 6.1. Transport Layer Security.................................11 67 7. Static Peering................................................13 68 7.1. TLS......................................................13 69 7.2. IPsec....................................................14 70 7.3. Co-Location..............................................14 71 8. Federation Based Peering......................................15 72 8.1. Central Federation Proxy.................................15 73 8.2. Central ENUM Federation..................................17 74 9. Media Relay...................................................19 75 10. Peering Message Flow Phases..................................19 76 10.1. Discovery Phase.........................................21 77 10.2. Security Establishment Phase............................22 78 10.3. Signaling Exchange Phase................................22 79 10.4. Media Exchange Phase....................................23 80 11. Security Considerations......................................23 81 12. IANA Considerations..........................................24 82 13. Acknowledgments..............................................24 83 14. References...................................................24 84 14.1. Normative References....................................24 85 14.2. Informative References..................................25 86 Author's Addresses...............................................25 88 Conventions used in this document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC-2119 [1]. The 93 terminology in this document conforms to RFC 2828, "Internet Security 94 Glossary". 96 1. Introduction 98 This document shows the message flows associated with the most 99 relevant SPEERMINT routing architecture peering scenarios. Most of 100 the message diagrams were based on previous work described within 101 existing IETF standards documents. 103 The document focuses on the messages exchanged for the purpose of 104 Layer 5 peering [7] between two domains. Messages exchanged for the 105 purpose of setting up SIP sessions within a domain are considered out 106 of scope and are already defined in other IETF documents. 108 2. Definitions 110 SSP: SIP Service Provider, the administrative entity providing SIP 111 services utilizing SIP. Note that an SSP may be a traditional 112 Service Provider, an Enterprise, or any administrative domain 113 context. 115 LUF: Look-Up Function, the functional step(s) necessary to determine 116 for a given SIP request, which terminating domain it should be 117 sent to. 119 LRF: Location Routing Function, the functional step(s) necessary to 120 determine for a given SIP request's terminating domain, the path 121 to follow to reach the terminating domain. 123 Routing: In the context of this document, it is forwarding of an out- 124 of-dialog SIP request. 126 SED: Session Establishment Data, the LUF and LRF data needed and used 127 to route a SIP request to the next-hop(s) associated with 128 reaching the terminating domain. 130 SBE: Signaling-path Border Element, the logical SIP node that 131 represents the logical boundaries between SSP domains (a.k.a., 132 the signaling portion of an SBC, I-BCF, etc.). 134 SF: Signaling Function, the logical functional role for processing 135 SIP requests for peering/routing; i.e., the SBE's role. 137 DBE: Data-path Border Element, the logical node that relays media 138 between the logical boundaries of SSP domains (a.k.a., the media 139 portion of an SBC, I-BGF, etc.). 141 MF: Media Function, the logical functional role for processing media 142 for peering purposes, including relaying media; i.e., the DBE's 143 role. 145 3. Peering Scenarios 147 This draft separates the Layer 5 peering scenarios into two major 148 peering scenarios: 150 o On-demand: In this scenario the SIP proxies in domains A and B 151 establish a peering relationship driven by the necessity to 152 deliver a SIP message to another domain, without a pre-existing 153 relationship. This is sometimes referred as the "email" model. 155 o Static: In this scenario the peering relationship between proxies 156 A and B is statically pre-provisioned independent of the 157 establishment of any SIP session between users in different 158 domains. 160 Media for a given SIP session may follow a different path from 161 signaling, only following the IP routed transport path when crossing 162 peering domains. Alternatively, media for a given session can be 163 directed to traverse the same SIP device used for Layer 5 peering, 164 i.e., the same device that handles signaling when crossing domains. 165 This produces three different models: 167 o Media-direct: In this model SIP proxies perform Layer 5 peering 168 Signaling Function (SF), while media is sent directly between the 169 User Agent's (UA's) involved in the session, as shown in Figure 1. 170 Therefore signaling and media follow different paths. 172 o Integrated: In this model, the device that performs Layer 5 SIP 173 peering SF/SBE also processes the associated media when crossing 174 domains, as an MF/DBE, as shown in Figure 2. This function is 175 usually referred to as media relay and is usually performed by a 176 B2BUA or SBC (Session Border Controller). See [6] for a complete 177 discussion of such SBC functions. We will refer to this picture 178 throughout this document. 180 o Decomposed: In this model, media is relayed by a DBE/MF which is 181 physically separated from the SBE/SF. A control protocol, 182 typically H.248 or MGCP, is used by the SBE to control the DBE. 183 From the UA and peering domain's perspective, the decomposed SBE 184 and DBE do not function any differently than an integrated SBC. 185 For the purposes of this document, one can consider this model as 186 just a specific variant of the integrated model, and is not 187 discussed separately. 189 ............................ .............................. 190 . . . . 191 . +-------+ . . +-------+ . 192 . | | . . | | . 193 . | DNS | . . | DNS | . 194 . | 1 | . . | 2 | . 195 . | | . . | | . 196 . +-------+ . . +-------+ . 197 . | . . | . 198 . | . . | . 199 . +-------+ . . +-------+ . 200 . | SF | . . | SF | . 201 . | Proxy |--------------| Proxy | . 202 . | 1 | . . | 2 | . 203 . | | . . | | . 204 . / +-------+ . . +-------+ \ . 205 . / . . \ . 206 . / . . \ . 207 . / . . \ . 208 . / . . \ . 209 . / . . \ . 210 . / . . \ . 211 . / . . \ . 212 . +-------+ . . +-------+ . 213 . | | . . | | . 214 . | | . Media . | | . 215 . | UA 1 |<========================================>| UA 2 | . 216 . | | . . | | . 217 . +-------+ . . +-------+ . 218 . Domain A . . Domain B . 219 ............................ .............................. 221 Figure 1: Basic Peering Picture (media-direct) 223 The integrated model is shown below: 225 ............................ .............................. 226 . . . . 227 . +-------+ . . +-------+ . 228 . | | . . | | . 229 . | DNS | . . | DNS | . 230 . | 1 | . . | 2 | . 231 . | | . . | | . 232 . +-------+ . . +-------+ . 233 . | . . | . 234 . | . . | . 235 . +-------+ . . +-------+ . 236 . | SBE/SF| . . | SBE/SF| . 237 . | & |--------------| & | . 238 . | DBE/MF|**************| DBE/MF|\ . 239 . /| | . . | | \ . 240 . / +-------+ . . +-------+* \ signaling . 241 . / * . . * \ . 242 . / * . . * \ . 243 . / * . . * \ . 244 . / * media . . * \ . 245 . / * . . * \ . 246 . / * . . * \ . 247 . / * . . * \ . 248 . +-------+ . . +-------+ . 249 . | | . . | | . 250 . | | . . | | . 251 . | UA 1 | . . | UA 2 | . 252 . | | . . | | . 253 . +-------+ . . +-------+ . 254 . Domain A . . Domain B . 255 ............................ .............................. 257 Figure 2: Integrated Peering Picture 259 In a decomposed model, the Signaling Function (SF) of an SBE, and the 260 Media Function (MF) of a DBE, are implemented in separate physical 261 entities. A B2BUA is generally on the SIP path performing the SF. A 262 vertical control protocol between the SF and MF is out of the scope 263 of this document. 265 4. Legend for Message Flows 266 Dashed lines (---) represent signaling messages that are mandatory to 267 the call scenario. These messages can be SIP or DNS protocols. The 268 arrow indicates the direction of message flow. 270 The Actors: 272 Element URI IP Address 273 ------- --- ---------- 274 User Agent +12125551212@sp1.example.com 192.0.10.10 275 User Agent +17815551212@sp2.example.net 192.0.20.20 276 SBE/Peer-Proxy/SF-1 sbe1.sp1.example.com 192.0.10.111 277 SBE/Peer-Proxy/SF-2 sbe2.sp2.example.net 192.0.20.222 278 5. Basic Peering Message Flow 280 This section depicts the "basic" Peering message flow. This does not 281 imply this is the most common peering scenario - just a baseline. 282 The various scenarios differ mostly of how and when peering is 283 implemented. As stated earlier, peering can be establish dynamically 284 following the arrival of a message at a border proxy, or statically 285 based on an agreement between both domains. 287 Alice SF-1 DNS SF-2 Bob 288 | | | | | 289 | INVITE | | | | 290 |------->| | | | 291 | 100 | | | | 292 |<-------| | | | 293 | | NAPTR | | | 294 | | Query | | | 295 | |--------->| | | 296 | | NAPTR | | | 297 | | Reply | | | 298 | |"SIP+D2U" | | | 299 | |<---------| | | 300 | | SRV | | | 301 | | Query | | | 302 | |--------->| | | 303 | | SRV | | | 304 | | Reply | | | 305 | |<---------| | | 306 | | | | 307 | | Peering | | 308 | | Phase | | 309 | | [On-Demand] | | 310 | |<------------------>| | 311 | | INVITE | | 312 | |------------------->| INVITE | 313 | | 100 |---------->| 314 | |<-------------------| | 315 | | | 180 | 316 | | 180 |<----------| 317 | 180 |<-------------------| | 318 |<-------| | 200 | 319 | | 200 |<----------| 320 | 200 |<-------------------| | 321 |<-------| | | 322 | ACK | | | 323 |------->| ACK | | 324 | |------------------->| ACK | 325 | | |---------->| 326 | Both Way RTP Media | 327 |<=======================================>| 329 | | | BYE | 330 | | BYE |<----------| 331 | BYE |<-------------------| | 332 |<-------| | | 333 | 200 | | | 334 |------->| 200 | | 335 | |------------------->| 200 | 336 | | |---------->| 337 | | | | 339 In the integrated model, media would follow the path shown below. All 340 other signaling call flows remain the same. In the decomposed model, 341 the media would also go to a MF/DBE functional entity, but it would 342 just be physically separate from the SF/SBE. 344 Alice SF/MF-1 DNS SF/MF-2 Bob 345 | | | | | 346 | | | | | 347 | Both Way RTP Media | 348 |<======>|<==================>|<=========>| 349 | | | | 351 5.1. Message Examples for Basic Peering Model 353 Message Details 355 F1 INVITE Alice -> SF-1 357 INVITE sip:+17815551213@sp2.example.net SIP/2.0 358 Via: SIP/2.0/UDP 192.0.10.10:5060;branch=z9hG4bK74b43 359 Route: 360 Max-Forwards: 70 361 To: 362 From: +12125551212 ;tag=9fxced76sl 363 Call-ID: 3848276298220188511 364 CSeq: 1 INVITE 365 Contact: 366 Content-Type: application/sdp 367 Content-Length: [sum of MIME body length] 368 v=0 369 o=- 2890844526 2890844526 IN IP4 192.0.10.10 370 s=- 371 c=IN IP4 192.0.10.10 372 t=0 0 373 m=audio 49172 RTP/AVP 0 374 a=rtpmap:0 PCMU/8000 376 F2 DNS NAPTR Reply DNS -> SF-1 378 IN NAPTR 50 50 "s" "SIP+D2U" "" _sip._udp.sp1.example.com. 380 F3 DNS SRV Reply DNS -> SF-1 382 IN SRV 0 1 5060 sbe2.sp2.example.net 384 F4 INVITE SF-1 -> SF-2 386 INVITE sip:+17815551213@sp2.example.net SIP/2.0 387 Via: SIP/2.0/UDP 192.0.10.111:5060;branch=z9hG4bK87298 388 Via: SIP/2.0/UDP 192.0.10.10:5060;branch=z9hG4bK74b43 389 Route: 390 Max-Forwards: 69 391 To: 392 From: 12125551212 ;tag=9fxced76sl 393 Call-ID: 3848276298220188511 394 CSeq: 1 INVITE 395 Contact: 396 Content-Type: application/sdp 397 Content-Length: [sum of MIME body length] 399 v=0 400 o=- 2890844526 2890844526 IN IP4 192.0.10.10 401 s=- 402 c=IN IP4 192.0.10.10 403 t=0 0 404 m=audio 49172 RTP/AVP 0 405 a=rtpmap:0 PCMU/8000 407 6. On-Demand Peering 409 In the on-demand peering scenario, the relationship between proxies 410 in domains A and B is driven by the arrival of a SIP message at proxy 411 A directed to a user in domain B (or vice-versa). 413 6.1. Transport Layer Security 415 In case this is in fact the first SIP request between two SSPs in an 416 on-demand peering relationship, then the SIP request will trigger the 417 establishment of the TLS connection. Otherwise it is assumed the TLS 418 connection has been established by some other means and may be 419 reused. 421 Alice Proxy 1 DNS Proxy 2 Bob 422 | | | | | 423 | | | | | 424 | INVITE | | | | 425 |------->| | | | 426 | 100 | | | | 427 |<-------| | | | 428 | | NAPTR | | | 429 | | Query | | | 430 | |--------->| | | 431 | | NAPTR | | | 432 | | Reply | | | 433 | |"SIPS+D2T"| | | 434 | |<---------| | | 435 | | SRV | | | 436 | | Query | | | 437 | |--------->| | | 438 | | SRV | | | 439 | | Reply | | | 440 | |<---------| | | 441 | | | | | 442 | | Peering | | 443 | | [TLS Connection] | | 444 | |<------------------>| | 445 | | | | 446 | | INVITE | | 447 | |------------------->| INVITE | 448 | | 100 |---------->| 449 | |<-------------------| | 450 | | | 180 | 451 | | 180 |<----------| 452 | 180 |<-------------------| | 453 |<-------| | 200 | 454 | | 200 |<----------| 455 | 200 |<-------------------| | 456 |<-------| | | 457 | ACK | | | 458 |------->| ACK | | 459 | |------------------->| ACK | 460 | | |---------->| 461 | Both Way RTP Media | 462 |<=======================================>| 463 | | | BYE | 464 | | BYE |<----------| 465 | BYE |<-------------------| | 466 |<-------| | | 467 | 200 | | | 468 |------->| 200 | | 469 | |------------------->| 200 | 470 | | |---------->| 471 | | | | 473 [TBD: add TLS connection for upstream requests?] 475 F1 INVITE request is the same as for previous direct peering flow. 477 F2 DNS NAPTR Reply DNS -> SF-1 479 IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.sp1.example.com. 481 F3 DNS SRV Reply DNS -> SF-1 483 IN SRV 0 1 5061 sbe2.sp2.example.net 485 F4 INVITE SF-1 -> SF-2 487 INVITE sip:+17815551213@sp2.example.net SIP/2.0 488 Via: SIP/2.0/TLS 192.0.10.111:12345;branch=z9hG4bK98479 489 Via: SIP/2.0/UDP 192.0.10.10:5060;branch=z9hG4bK74b43 490 Route: 491 Max-Forwards: 69 492 To: 493 From: 12125551212 ;tag=9fxced76sl 494 Call-ID: 3848276298220188511 495 CSeq: 1 INVITE 496 Contact: 497 Content-Type: application/sdp 498 Content-Length: ... [SDP omitted from example] 500 7. Static Peering 502 In the static peering scenario the relationship between proxies A and 503 B is not driven by a SIP request, but before-hand through manual 504 provisioning. 506 7.1. TLS 508 In this model a TLS connection between proxies A and B is provisioned 509 following an agreement between the two domains. Creation of the TLS 510 connection may be established through previous SIP message exchanges, 511 or by continuous message exchange such as OPTIONS requests/responses. 512 If Mutual-TLS is used, reverse-path requests may use the same 513 connection as defined in [13], or separate TLS connections may be 514 used for each request direction. 516 7.2. IPsec 518 In this model an IPSec connection between proxies A and B is 519 provisioned following an agreement between the two domains. 520 Typically either transport-mode ESP is used for SIP signaling only, 521 or tunnel-mode is used for either just signaling, or both signaling 522 and media. If tunneling is used, media-relay must be performed as 523 described later. No diagram is shown for the IPsec case, since the 524 changes are only at the network layer. 526 7.3. Co-Location 528 In this scenario the two proxies are co-located in a physically 529 secure location and/or are members of a segregated network, such as a 530 VPN. In this case messages between Proxy 1 and Proxy 2 would be sent 531 as clear text. 533 Alice Proxy 1 DNS Proxy 2 Bob 534 | | | | | 535 | | | | 536 | | [Peering] | | 537 | | Co-Location | | 538 | |<------------------>| | 539 | | | | | 540 \ / \ / \ 541 / \ / \ / 542 | | | | | 543 | INVITE | | | | 544 |------->| | | | 545 | 100 | | | | 546 |<-------| | | | 547 \ / \ / \ 548 / \ / \ / 549 | | BYE |<----------| 550 | BYE |<-------------------| | 551 |<-------| | | 552 | 200 | | | 554 8. Federation Based Peering 556 Multiple SSP's may be members of the same Federation, such that their 557 policies and relationships are defined to be the same for a given 558 federation. Federations are one way for a source and destination 559 network to find a common set of procedures for peering. 561 8.1. Central Federation Proxy 563 Federation rules can dictate that calls are to be routed via a 564 federation-maintained central SIP proxy. In that case no further 565 NAPTR/SRV/A lookups need be made. Instead, the INVITE will be sent 566 directly via a preconfigured connection to that proxy. This proxy 567 acts as a redirect proxy, returning SIP 3xx responses with the 568 Contact URI(s) identifying the next target(s), which may need 569 subsequent DNS resolution per RFC 3263 to resolve. The SIP Redirect 570 proxy essentially performs the role of the LUF and potentially the 571 LRF, using SIP as the query protocol. 573 The following message flow provides an example describing this 574 process: 576 Peer Proxy 1 Federation Proxy Peer Proxy 2 Bob 577 | | | | 578 | INVITE | | | 579 |--------------->| | | 580 | 302 | | | 581 |<---------------| | | 582 | ACK | | | 583 |--------------->| | | 584 | INVITE | | 585 |-------------------------------->| INVITE | 586 | 100 |--------------->| 587 |<--------------------------------| 180 | 588 | 180 |<---------------| 589 |<--------------------------------| | 590 | | 200 | 591 | 200 |<---------------| 592 |<--------------------------------| | 593 | ACK | | 594 |-------------------------------->| ACK | 595 | |--------------->| 596 | Both Way RTP Media | 597 |<================================================>| 598 | | BYE | 599 | BYE |<---------------| 600 |<--------------------------------| | 601 | 200 | | 602 |-------------------------------->| 200 | 603 | |--------------->| 605 F1 INVITE Peer Proxy 1 -> Federation Redirect Server 607 INVITE sip:+17815551213@fed.example.org SIP/2.0 608 Via: SIP/2.0/UDP 192.0.10.111:5060;branch=z9hG4bK98479 609 Via: SIP/2.0/UDP 192.0.10.10:5060;branch=z9hG4bK74b43 610 Max-Forwards: 69 611 To: 612 From: 12125551212 ;tag=9fxced76sl 613 Call-ID: 3848276298220188511 614 CSeq: 1 INVITE 615 Contact: 616 Content-Type: application/sdp 617 Content-Length: ... [SDP omitted from example] 619 F2 Redirect response Federation Proxy -> Peer Proxy 1 621 SIP/2.0 302 Moved Temporarily 622 Via: SIP/2.0/UDP 192.0.10.111:5060;branch=z9hG4bK98479 623 Via: SIP/2.0/UDP 192.0.10.10:5060;branch=z9hG4bK74b43 624 Contact: 625 To: 626 From: 12125551212 ;tag=9fxced76sl 627 Call-ID: 3848276298220188511 628 CSeq: 1 INVITE 629 Content-Length: 0 631 F3 INVITE Peer Proxy 1 -> Peer Proxy 2 633 INVITE sip:+17815551213@sbe2.sp2.example.net SIP/2.0 634 Via: SIP/2.0/UDP 192.0.10.111:5060;branch=z9hG4bK141344 635 Via: SIP/2.0/UDP 192.0.10.10:5060;branch=z9hG4bK74b43 636 Max-Forwards: 69 637 To: 638 From: 12125551212 ;tag=9fxced76sl 639 Call-ID: 3848276298220188511 640 CSeq: 1 INVITE 641 Contact: 642 Content-Type: application/sdp 643 Content-Length: ... [SDP omitted from example] 645 8.2. Central ENUM Federation 647 Another form of centralized Federation is to use an ENUM 648 infrastructure instead of SIP Redirect Proxy, and thus DNS as the 649 query protocol for the LUF, and possibly LRF. The originating SSP 650 performs a NAPTR query to a pre-arranged ENUM server (a private DNS 651 server deployed for this role), for the destination calling party 652 E.164 number, with a private domain root for the Federation. 654 If the ENUM server provides just an LUF function, it will provide SED 655 data identifying the terminating SSP domain, and any number 656 portability data required, in its NAPTR response; but then relies on 657 the originating SSP to either know how to reach the terminating 658 domain or to perform some means of performing the LRF. If the ENUM 659 serve provides both, it will resolve not only the number portability 660 information, if any, but also return the next-hop URI target(s) for 661 the originating SSP to send the SIP request to. 663 The following diagram shows a scenario whereby the originating SSP 664 performs an LUF query using ENUM-DNS to a central Federation ENUM 665 server, which responds with the resolved peer SSP's domain. In this 666 particular case the originating SSP can reach the terminating SSP 667 directly, and happens to perform just a DNS request to resolve the 668 connection information for the Peer, to reach the Peer's SF-2 SBE. 669 This is only one particular scenario - many others are possible. 671 Alice SF-1 ENUM DNS SF-2 Bob 672 | | LUF| | | | 673 | INVITE | | | | | 674 |------->| | | | | 675 | 100 | | | | | 676 |<-------| | | | | 677 | | NAPTR | | | | 678 | | Query | | | | 679 | |-------->| | | | 680 | | NAPTR | | | | 681 | | Reply | | | | 682 | |"E2U+sip"| | | | 683 | |<--------| | | | 684 | | SRV | | | 685 | | Query | | | 686 | |------------->| | | 687 | | SRV | | | 688 | | Reply | | | 689 | |<-------------| | | 690 | | | | 691 | | Peering | | 692 | | Phase | | 693 | | [On-Demand] | | 694 | |<------------------>| | 695 | | INVITE | | 696 | |------------------->| INVITE | 697 | | 100 |---------->| 698 | |<-------------------| | 699 | | | 180 | 700 | | 180 |<----------| 701 | 180 |<-------------------| | 702 |<-------| | 200 | 703 | | 200 |<----------| 704 | 200 |<-------------------| | 705 |<-------| | | 706 | ACK | | | 707 |------->| ACK | | 708 | |------------------->| ACK | 709 | | |---------->| 710 | Both Way RTP Media | 711 |<=======================================>| 713 F1 INVITE Alice -> SF-1 715 INVITE sip:+17815551213@sp2.example.net SIP/2.0 716 Via: SIP/2.0/UDP 192.0.10.10:5060;branch=z9hG4bK74b43 717 Route: 718 Max-Forwards: 70 719 To: 720 From: +12125551212 ;tag=9fxced76sl 721 Call-ID: 3848276298220188511 722 CSeq: 1 INVITE 723 Contact: 724 Content-Type: application/sdp 725 Content-Length: ... [SDP omitted from example] 727 F2 DNS ENUM (LUF) query for +17815551213 729 NAPTR query for "3.1.2.1.5.5.5.1.8.7.1.e164.sp1.example.com" 731 F3 NAPTR Reply 733 IN NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:\1@sbe2.sp2.example.net" _. 735 [The rest of the examples follow the previous sections] 737 9. Media Relay 739 In the event that a source and/or destination SSP are part of a 740 private network, or peer through a private network, the SSP peers 741 must enable the SIP signaling and media to route between the peers. 742 This process is implemented by an SBE and DBE, either in an 743 integrated or decomposed model. The core of the process is media 744 relaying, whereby the SBE forces the relay of media through its DBE 745 by modifying the SDP. 747 10. Peering Message Flow Phases 749 The message flow phases are Discovery, Security Establishment, 750 Signaling Exchange, and Media Exchange. The following flow provides 751 an overview of the phases. Each of the phases is described 752 individually in the following subsections. For the following 753 diagram, the signaling and media exchange phase descriptions have 754 been omitted for clarity purposes, because their functionality has 755 not changed for the purposes of peering. However, they have been 756 explained further in the following subsections. 758 Alice Peer Proxy DNS Peer Policy/Proxy Bob 759 | | | | | 760 |INVITE | | | | 761 |----------->| | | | 762 | 100| | | | 763 |<-----------| | | | 764 |NAPTR Query | | | 765 +---->|--------------->| | | 766 | | NAPTR Reply| | | 767 Discovery Phase | |<---------------| | | 768 ----------------| |SRV Query | | | 769 | |--------------->| | | 770 | | SRV Reply| | | 771 +---->|<---------------| | | 772 | | | | 773 Security Exch. | [TLS Connection] | | 774 --------------------->|<--------------------------->| | 775 Phase | INVITE | | 776 |---------------------------->|INVITE | 777 | | 100 Trying |------------->| 778 | |<----------------------------| 180 Ringing| 779 | | 180 Ringing |<-------------| 780 | 180 Ringing|<----------------------------| 200OK | 781 |<------------| 200OK |<-------------| 782 | 200OK |<----------------------------| | 783 |<------------| | | 784 | ACK | | | 785 |------------>| ACK | | 786 | |---------------------------->|ACK | 787 | | |------------->| 788 | | Both Way RTP Media | | 789 |<========================================================>| 790 | | | BYE | 791 | | BYE |<-------------| 792 | BYE |<----------------------------| | 793 |<------------| | | 794 | 200OK | | | 795 |------------>| 200OK | | 796 | |---------------------------->|200OK | 797 | | |------------->| 799 10.1. Discovery Phase 801 The first phase of static or dynamic peering requests is discovery. 802 The discovery process can be summarized by querying the Location 803 Routing Function (LRF) to determine the next phase in the message 804 flow. The discovery phase can take place via a local or external 805 federation location function. Examples of the function may be 806 comprised of an ENUM/DNS or redirect server. After the discovery 807 phase has completed, the peering process will progress to a 808 subsequent phase, usually the policy or authentication phase. The 809 following message flows provide examples of the discovery phase. 811 Discovery phase utilizing an ENUM/DNS server as a location function: 813 Alice Peer Proxy DNS Peer Proxy 814 | | | | 815 |INVITE | | | 816 |----------->| | | 817 | 100| | | 818 |<-----------| | | 819 |NAPTR Query | | 820 +---->|--------------->| | 821 | | NAPTR Reply| | 822 Discovery Phase | |<---------------| | 823 -----------------| |SRV Query | | 824 | |--------------->| | 825 | | SRV Reply| | 826 +---->|<---------------| | 827 |INVITE | 828 |------------------------------->| 830 Discovery phase utilizing a REDIRECT server as a location function: 832 Peer Proxy Federation Proxy Peer Proxy 833 | | | 834 | INVITE | | 835 +---->|--------------->| | 836 Discovery Phase | | 302 | | 837 -----------------| |<---------------| | 838 | | ACK | | 839 +---->|--------------->| | 840 | INVITE | 841 |------------------------------->| 843 10.2. Security Establishment Phase 845 The security establishment phase follows the described methods in 846 previous sections of this document. This phase follows standard 847 methods described in [2], so the following flow provides an example 848 of this phase, but does not incorporate all possibilities. This 849 phase assumes the previous phases were successfully completed or 850 purposefully omitted per peering implementation. 852 Peer Proxy Peer Proxy 853 | | 854 | INVITE | 855 +---->|------------------------------->| 856 | | [TLS Connection] | 857 Security Exch. | |<------------------------------>| 858 ----------------| | 401 Unauthorized | 859 Phase | |<-------------------------------| 860 | | INVITE | 861 +---->|------------------------------->| 862 | 100 Trying | 863 |<-------------------------------| 864 | 180 Ringing | 865 |<-------------------------------| 867 10.3. Signaling Exchange Phase 869 The signaling exchange phase is a necessary step to progress towards 870 establishing peering. This phase may incorporate the security 871 exchange phase, but it is not required. This phase follows standard 872 methods described in [2], so the following flow provides an example 873 of this phase, but does not incorporate all possibilities. 875 Peer Proxy Peer Proxy 876 | | 877 | [TLS Connection] | 878 +---->|<------------------------------>| 879 | | INVITE | 880 | |------------------------------->| 881 Signaling Exch. | | 100 Trying | 882 -----------------| |<-------------------------------| 883 Phase | | 180 Ringing | 884 | |<-------------------------------| 885 | | 200 OK | 886 | |<-------------------------------| 887 | | ACK | 888 | |------------------------------->| 889 | | BYE | 890 | |<-------------------------------| 891 | | 200 OK | 892 +---->|------------------------------->| 893 | | 895 10.4. Media Exchange Phase 897 The media exchange phase is negotiated and established during the 898 signaling exchange phase. This phase follows standard methods 899 described in [2], so the following flow provides an example of this 900 phase, but does not incorporate all possibilities. 902 Alice Peer Proxy Peer Proxy Bob 903 +---->|INVITE | | | 904 | |----------->| INVITE | | 905 | | 100 |------------------>| INVITE | 906 | |<-----------| 100 Trying |----------->| 907 Media Exch. | | |<------------------| 100 | 908 ---------------| | | |<-----------| 909 Phase | | | | 180 | 910 | | | 180 Ringing |<-----------| 911 | | 180 |<------------------| 200 | 912 | |<-----------| 200 OK |<-----------| 913 | | 200 |<------------------| | 914 | |<-----------| | | 915 | |ACK | | | 916 +---->|----------->|ACK | | 917 | |------------------>|ACK | 918 | | |----------->| 919 | Both Way RTP Media | | 920 |<===========================================>| 921 | | | | 922 | | | BYE | 923 | | BYE |<-----------| 924 | BYE|<------------------| | 925 |<-----------| | | 926 |200 | | | 927 |----------->|200 | | 928 | |------------------>|200 | 929 | | |----------->| 931 11. Security Considerations 933 The level of security required during the establishment and 934 maintenance of a SIP peering relationship between two proxies can 935 vary greatly. In general all security considerations related to the 936 SIP protocol are also applicable in a peering relationship. 938 If the two proxies communicate over an insecure network, and 939 consequently are subject to attacks/eavesdropping/etc., the use of 940 TLS or IPSec would be advisable. 942 If there is physical security and the proxies are co-located, or the 943 proxies are situated in a segregated network (such as a VPN), one 944 could argue that weaker measures are sufficient. 946 12. IANA Considerations 948 N/A 950 13. Acknowledgments 952 Thanks to Reinaldo Penno for his work as the original author of this 953 document, and to Otmar Lendl for his contributions. 955 14. References 957 14.1. Normative References 959 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 960 Levels", BCP 14, RFC 2119, March 1997. 962 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 963 A.,Peterson, J., Sparks, R., Handley, M. and E. Schooler, 964 "SIP:Session Initiation Protocol", RFC 3261, June 2002. 966 [3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 967 (SIP): Locating SIP Servers", RFC 3263, June 2002. 969 [4] Srisuresh, P. and K. Egevang, "Traditional IP Network Address 970 Translator (Traditional NAT)", RFC 3022, January 2001. 972 [5] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. 973 Summers, "Session Initiation Protocol (SIP) Basic Call 974 Flow Examples", BCP 75, RFC 3665, December 2003. 976 [6] ETSI TS 102 333: " Telecommunications and Internet converged 977 Services and Protocols for Advanced Networking (TISPAN); Gate 978 control protocol". 980 [7] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 981 Notification", RFC 3265, June 2002. 983 [8] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 984 Specifications: ABNF", RFC 4234, October 2005. 986 [9] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and 987 E. Lear, "Address Allocation for Private Internets", RFC 1918, 988 February 1996. 990 14.2. Informative References 992 [10] Meyer, D., Malas, D., "SPEERMINT Terminology", Internet Draft, 993 draft-ietf-speermint-terminology-16, February 2008. 995 [11] Boulton, C., Rosenberg, J., Camarillo, G., "Best Current 996 Practices for NAT Traversal for SIP", Internet Draft, draft- 997 ietf-sipping-nat-scenarios-08, April 2008. 999 [12] Camarillo, G., Penfield, R., Hawrylyshen, A., "Requirements 1000 from SIP (Session Initiation Protocol) Session Border 1001 Controller Deployments", Internet Draft, draft-camarillo- 1002 sipping-sbc-funcs-06, June 2008. 1004 [13] Gurbani, V., Mahy, R., Tate, B., " Connection Reuse in the 1005 Session Initiation Protocol (SIP)", draft-ietf-sip-connect- 1006 reuse-11, July 2008. 1008 Author's Addresses 1010 Hadriel Kaplan 1011 Acme Packet 1012 71 Third Ave. 1013 Burlington, MA 01803, USA 1014 Email: hkaplan@acmepacket.com 1016 Daryl Malas 1017 CableLabs 1018 858 Coal Creek Circle 1019 Louisville, CO, 80027, USA 1020 EMail: d.malas@cablelabs.com 1022 Sohel Khan, Ph.D. 1023 Comcast Cable Communications 1024 USA 1025 Email: sohel_khan@cable.comcast.com 1026 Reinaldo Penno 1027 Juniper Networks 1028 1194 N Mathilda Avenue 1029 Sunnyvale, CA, USA 1030 Email: rpenno@juniper.net 1032 Adam Uzelac 1033 Global Crossing 1034 1120 Pittsford Victor Road 1035 PITTSFORD, NY 14534, USA 1036 Email: adam.uzelac@globalcrossing.com