idnits 2.17.1 draft-ietf-speermint-voip-consolidated-usecases-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 340 has weird spacing: '...riority weigh...' == Line 706 has weird spacing: '...riority weigh...' -- 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 (October 17, 2011) is 4574 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-speermint-voipthreats-01 ** Obsolete normative reference: RFC 3761 (Obsoleted by RFC 6116, RFC 6117) == Outdated reference: A later version (-06) exists of draft-ietf-drinks-usecases-requirements-00 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPEERMINT Working Group A. Uzelac, Ed. 3 Internet-Draft Global Crossing 4 Intended status: Informational Y. Lee, Ed. 5 Expires: April 19, 2012 Comcast 6 October 17, 2011 8 VoIP SIP Peering Use Cases 9 draft-ietf-speermint-voip-consolidated-usecases-19 11 Abstract 13 This document depicts many common Voice over IP (VoIP) use cases for 14 Session Initiation Protocol (SIP) Peering. These use cases are 15 categorized into static and on-demand, and then further sub- 16 categorized into direct and indirect. These use cases are not an 17 exhaustive set, but rather the most common use cases deployed today. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 19, 2012. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Reference Architecture . . . . . . . . . . . . . . . . . . . . 3 59 4. Contexts of Use Cases . . . . . . . . . . . . . . . . . . . . 4 61 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 5.1. Static Peering Use Cases . . . . . . . . . . . . . . . . . 5 63 5.2. Static Direct Peering Use Case . . . . . . . . . . . . . . 5 64 5.2.1. Administrative characteristics . . . . . . . . . . . . 10 65 5.2.2. Options and Nuances . . . . . . . . . . . . . . . . . 11 66 5.3. Static Direct Peering Use Case - Assisting LUF and LRF . . 11 67 5.3.1. Administrative Characteristics . . . . . . . . . . . . 12 68 5.3.2. Options and Nuances . . . . . . . . . . . . . . . . . 13 69 5.4. Static Indirect Peering Use Case - Assisting LUF and 70 LRF . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 5.4.1. Administrative characteristics . . . . . . . . . . . . 19 72 5.4.2. Options and Nuances . . . . . . . . . . . . . . . . . 20 73 5.5. Static Indirect Peering Use Case . . . . . . . . . . . . . 20 74 5.5.1. Administrative characteristics . . . . . . . . . . . . 21 75 5.5.2. Options and Nuances . . . . . . . . . . . . . . . . . 21 76 5.6. On-demand Peering Use Case . . . . . . . . . . . . . . . . 22 77 5.6.1. Administrative characteristics . . . . . . . . . . . . 22 78 5.6.2. Options and Nuances . . . . . . . . . . . . . . . . . 22 80 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 88 9.2. Informative References . . . . . . . . . . . . . . . . . . 24 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 92 1. Introduction 94 This document describes important Voice over IP (VoIP) use cases 95 Session Initiation Protocol (SIP) [RFC3261] based peering. These use 96 cases are determined by the SPEERMINT working group and will assist 97 in identifying requirements and other issues to be considered for 98 future resolution by the working group. 100 Only use cases related to VoIP are considered in this document. 101 Other real-time SIP communications use cases, like Instant Messaging 102 (IM), Video Chat, and Presence are out of scope for this document. 104 The use cases contained in this document are described as 105 comprehensive as possible, but should not be considered the exclusive 106 set of use cases. 108 2. Terminology 110 This document uses terms defined in [RFC5486]. Please refer to it 111 for definitions. 113 3. Reference Architecture 115 The diagram below provides the reader with a context for the VoIP use 116 cases in this document. Terms such as SIP Service Provider (SSP), 117 Look-Up Function (LUF), Location Routing Function (LRF), Signaling 118 Path Border Element (SBE) and Data Path Border Element (DBE) are 119 defined in [RFC5486]. 121 Originating SSP (O-SSP) is the SSP originating a SIP request. 122 Terminating SSP (T-SSP) is the SSP terminating the SIP request 123 originating from O-SSP. Assisting LUF and LRF Provider offers LUF 124 and LRF services to O-SSP. Indirect SSP (I-SSP) is the SSP providing 125 indirect peering service(s) to O-SSP to connect to T-SSP. 127 +--------------------+------------------------+--------------------+ 128 | Originating SSP | Assisting LUF and LRF | Terminating SSP | 129 | Domain | Provider Domain | Domain | 130 | | | | 131 | +-----+ +-----+ | +------+ +------+ | +-----+ +-----+ | 132 | |O-LUF| |O-LRF| | |A-LUF | | A-LRF| | |T-LUF| |T-LRF| | 133 | +-----+ +-----+ | +------+ +------+ | +-----+ +-----+ | 134 | | | | 135 | +-------+ +-----+ +------------------------+ +-----+ +-------+ | 136 | |O-Proxy| |O-SBE| | Indirect SSP Domain | |T-SBE| |T-Proxy| | 137 | +-------+ +-----+ | | +-----+ +-------+ | 138 | | +-----+ +-----+ | | 139 | +---+ +-----+ | |O-SBE| |O-DBE| | +-----+ +---+ | 140 | |UAC| |O-DBE| | +-----+ +-----+ | |T-DBE| |UAS| | 141 | +---+ +-----+ | | +-----+ +---+ | 142 | | | | 143 +--------------------+------------------------+--------------------+ 145 General Overview 147 Figure 1 149 Note that some elements included in Figure 1 are optional. 151 4. Contexts of Use Cases 153 Use cases are sorted into two general groups: Static and On-demand 154 Peering [RFC5486]. Each group can be further sub-divided into Direct 155 Peering and Indirect Peering [RFC5486]. Although there may be some 156 overlap among the use cases in these categories, there are different 157 requirements between the scenarios. Each use case must specify a 158 basic set of required operations to be performed by each SSP when 159 peering. 161 These can include: 163 o Peer Discovery - Peer discovery via a Look-Up Function (LUF) to 164 determine the Session Establishment Data (SED) [RFC5486] of the 165 request. In VoIP use cases, a request normally contains a phone 166 number. The O-SSP will input the phone number to the LUF and the 167 LUF will normally return a SIP AOR [RFC3261] which contains a 168 domain name. 170 o Next Hop Routing Determination - Resolving the SED information is 171 necessary to route the request to the T-SSP. The LRF is used for 172 this determination. After obtaining the SED, the O-SSP may use 173 the standard procedure defined in [RFC3263] to discover the next 174 hop address. 176 o Call setup - SSPs that are interconnecting to one another may also 177 define specifics on what peering policies need to be used when 178 contacting the next hop in order to a) reach the next hop at all 179 and b) to prove that the sender is a legitimate peering partner. 181 Examples: hard-code transport (TCP/UDP/TLS), non-standard port 182 number, specific source IP address (e.g. in a private Layer-3 183 network), which TLS client certificate [RFC5246] to use, and other 184 authentication schemes. 186 o Call reception - This step serves to ensure that the type of 187 relationship (static or on-demand, indirect or direct) is 188 understood and acceptable. For example, the receiving SBE needs 189 to determine whether the INVITE it received really came from a 190 trusted member. 192 5. Use Cases 194 Please note there are intra-domain message flows within the use cases 195 to serve as supporting background information. Only inter-domain 196 communications are germane to this document. 198 5.1. Static Peering Use Cases 200 Static Peering [RFC5486] describes the use case when two SSPs form a 201 peering relationship with some form of association established prior 202 to the exchange of traffic. Pre-association is a prerequisite to 203 static peering. Static peering is used in cases when two peers want 204 a consistent and tightly controlled approach to peering. In this 205 scenario, a number of variables, such as an identification method 206 (remote proxy IP address) and Quality of Service (QoS) parameters, 207 can be defined upfront and known by each SSP prior to peering. 209 5.2. Static Direct Peering Use Case 211 This is the simplest form of a peering use case. Two SSPs negotiate 212 and agree to establish a SIP peering relationship. The peer 213 connection is statically configured and the peer SSPs are directly 214 connected. The peers may exchange interconnection parameters such as 215 DSCP [RFC2474] policies, the maximum number of requests per second, 216 and proxy location prior to establishing the interconnection. 217 Typically, the T-SSP only accepts traffic originating directly from 218 the trusted peer. 220 +--------------------+ +---------------------+ 221 | O-SSP | | T-SSP | 222 | +-----+ | | +-----+ | 223 | |O-LUF| | | |T-LUF| | 224 | |O-LRF| | | /|T-LRF| | 225 | /+-----+\ | | / +-----+ | 226 | (2) (4,5,6) | | / | 227 | / \ | | /(8,9) | 228 |+-------+ +-----+ +-----+ +-------+| 229 ||O-Proxy|-(3)-|O-SBE+-----(7)-----+T-SBE|-(10)-|T-Proxy|| 230 |+-------+ +-----+ +-----+ +-------+| 231 | | | | | | 232 | (1) | | (11) | 233 | | | | | | 234 | +-----+ +-----+ +-----+ +-----+ | 235 | | UAC +======|O-DBE+=====(12)====+T-DBE|=======+ UAS | | 236 | +-----+ +-----+ +-----+ +-----+ | 237 +--------------------+ +---------------------+ 238 example.com example.net 240 Static Direct Peering Use Case 242 Figure 2 244 The following is a high-level depiction of the use case: 246 1. UAC initiates a call via SIP INVITE to O-Proxy. O-Proxy is the 247 home proxy for UAC. 249 INVITE sip:+19175550100@example.com;user=phone SIP/2.0 250 Via: SIP/2.0/TCP client.example.com:5060 251 ;branch=z9hG4bK74bf9 252 Max-Forwards: 10 253 From: Alice 254 ;tag=12345 255 To: Bob 256 Call-ID: abcde 257 CSeq: 1 INVITE 258 259 Contact: 261 263 Note that UAC inserted its Fully Qualified Domain Name (FQDN) in 264 the VIA and CONTACT headers. This example assumes that UAC has 265 its own FQDN. 267 2. UAC knows UAS's TN, but does not know UAS's domain. It appends 268 its own domain to generate the SIP URI in Request-URI and TO 269 header. O-Proxy checks the Request-URI and discovers that the 270 Request-URI contains user parameter "user=phone". This 271 parameter signifies that the Request-URI is a phone number. So 272 O-Proxy will extract the TN from the Request-URI and query LUF 273 for SED information from a routing database. In this example, 274 the LUF is an ENUM [RFC3761] database. The ENUM entry looks 275 similar to this: 277 $ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa. 278 IN NAPTR ( 279 10 280 100 281 "u" 282 "E2U+SIP" 283 "!^.*$!sip:+19175550100@example.net!" 284 . ) 286 This SED data can be provisioned by O-SSP or populated by the 287 T-SSP. 289 3. O-Proxy examines the SED and discovers the domain is external. 290 Given the O-Proxy's internal routing policy, O-Proxy decides to 291 use O-SBE to reach T-SBE. O-Proxy routes the INVITE request to 292 O-SBE and adds a Route header which contains O-SBE. 294 INVITE sip:+19175550100@example.net;user=phone SIP/2.0 295 Via: SIP/2.0/TCP o-proxy.example.com:5060 296 ;branch=z9hG4bKye8ad 297 Via: SIP/2.0/TCP client.example.com:5060 298 ;branch=z9hG4bK74bf9;received=192.0.1.1 299 Max-Forwards: 9 300 Route: 301 Record-Route: 302 From: Alice 303 ;tag=12345 304 To: Bob 305 Call-ID: abcde 306 CSeq: 1 INVITE 307 308 Contact: 310 312 4. O-SBE receives the requests and pops the top entry of the Route 313 header which contains "o-sbe1.example.com". O-SBE examines the 314 Request-URI and does a LRF for "example.net". In this example, 315 the LRF is a NAPTR DNS query [RFC3403] of the domain name. 316 O-SBE receives a NAPTR response from LRF. The response looks 317 similar to this: 319 IN NAPTR ( 320 50 321 50 322 "S" 323 "SIP+D2T" 324 "" 325 _sip._tcp.t-sbe.example.net. ) 327 IN NAPTR ( 328 90 329 50 330 "S" 331 "SIP+D2U" 332 "" 333 _sip._udp.t-sbe.example.net. ) 335 5. Given the lower order for TCP in the NAPTR response, O-SBE 336 decides to use TCP as the transport protocol, so it sends a SRV 337 DNS query for the SRV record [RFC2782] for "_sip._tcp.t- 338 sbe.example.net." to O-LRF. 340 ;; priority weight port target 341 IN SRV 0 2 5060 t-sbe1.example.net. 342 IN SRV 0 1 5060 t-sbe2.example.net. 344 6. Given the higher weight for "t-sbe1.example.net", O-SBE sends an 345 A record DNS query for "t-sbe1.example.net." to get the A 346 record: 348 ;; DNS ANSWER 349 t-sbe1.example.net. IN A 192.0.2.100 350 t-sbe1.example.net. IN A 192.0.2.101 352 7. O-SBE sends the INVITE to T-SBE. O-SBE is the egress point to 353 the O-SSP domain, so it should ensure subsequent mid-dialog 354 requests traverse via itself. If O-SBE chooses to act as a 355 Back-to-Back User Agent (B2BUA) [RFC3261], it will generate a 356 new INVITE request in next step. If O-SBE chooses to act as a 357 proxy, it should record-route to stay in the call path. In this 358 example, O-SBE is a B2BUA. 360 INVITE sip:+19175550100@example.net;user=phone SIP/2.0 361 Via: SIP/2.0/TCP o-sbe1.example.com:5060 362 ;branch= z9hG4bK2d4zzz 363 Max-Forwards: 8 364 From: Alice 365 ;tag=54321 366 To: Bob 367 Call-ID: abcde-osbe1 368 CSeq: 1 INVITE 369 370 Contact: 372 374 Note that O-SBE may re-write the Request-URI with the target 375 domain in the SIP URI. Some proxy implementations will only 376 accept the request if the Request-URI contains their own 377 domains. 379 8. T-SBE determines the called party home proxy and directs the 380 call to the called party. T-SBE may use ENUM lookup or other 381 internal mechanism to locate the home proxy. If T-SSP uses ENUM 382 ookup, this internal ENUM entry is different from the external 383 ENUM entry populated for O-SSP. In this example, the internal 384 ENUM query returns the UAS's home proxy. 386 $ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa. 387 IN NAPTR ( 388 10 389 100 390 "u" 391 "E2U+SIP" 392 "!^.*$!sip:+19175550100@t-proxy.example.net!" 393 . ) 395 9. T-SBE receives the NAPTR record and following the requirements 396 in [RFC3263] queries DNS for the SRV records indicated by the 397 NAPTR result. Not finding any, the T-SBE then queries DNS for 398 the A record of domain "t-proxy.example.net.". 400 ;; DNS ANSWER 401 t-proxy.example.net. IN A 192.0.2.2 403 10. T-SBE is a B2BUA, so it generates a new INVITE and sends it to 404 UAS's home proxy: 406 INVITE sip:bob@t-proxy.example.net;user=phone SIP/2.0 407 Via: SIP/2.0/TCP t-sbe1.example.net:5060 408 ;branch= z9hG4bK28uyyy 409 Max-Forwards: 7 410 From: Alice 411 ;tag=54321 412 To: Bob 413 Call-ID: abcde-tsbe1 414 CSeq: 1 INVITE 415 416 Contact: 418 420 11. Finally, UAS's home proxy forwards the INVITE request to the 421 UAS. 423 INVITE sip:+19175550100@server.example.net;user=phone SIP/2.0 424 Via: SIP/2.0/TCP t-proxy.example.net:5060 425 ;branch= z9hG4bK28u111 426 Via: SIP/2.0/TCP t-sbe1.example.net:5060 427 ;branch= z9hG4bK28uyyy; received=192.2.0.100 428 Max-Forwards: 6 429 Record-Route: , 430 431 From: Alice 432 ;tag=54321 433 To: Bob 434 Call-ID: abcde-tsbe1 435 CSeq: 1 INVITE 436 437 Contact: 439 441 12. RTP is established between the UAC and UAS. Note that the media 442 shown in Figure 2 passes through O-DBE and T-DBE, but the use of 443 DBE is optional. 445 5.2.1. Administrative characteristics 447 The static direct peering use case is typically implemented in a 448 scenario where there is a strong degree of trust between the two 449 administrative domains. Both administrative domains typically sign a 450 peering agreement which state clearly the policies and terms. 452 5.2.2. Options and Nuances 454 In Figure 2 O-SSP and T-SSP peer via SBEs. Normally, the operator 455 will deploy the SBE at the edge of its administrative domain. The 456 signaling traffic will pass between two networks through the SBEs. 457 The operator has many reasons to deploy a SBE. For example, the 458 O-SSP may use [RFC1918] addresses for their UA and proxies. These 459 addresses are not routable in the target network. The SBE can 460 perform a NAT function. Also, the SBE eases the operation cost for 461 deploying or removing Layer-5 network elements. Consider the 462 deployment architecture where multiple proxies connect to a single 463 SBE. An operator can add or remove a proxy without coordinating with 464 the peer operator. The peer operator "sees" only the SBE. As long 465 as the SBE is maintained in the path, the peer operator does not need 466 to be notified. 468 When an operator deploys SBEs, the operator is required to advertise 469 the SBE to the peer LRF so that the peer operator can locate the SBE 470 and route the traffic to the SBE accordingly. 472 SBE deployment is a decision within an administrative domain. Either 473 one or both administrative domains can decide to deploy SBE(s). To 474 the peer network, most important is to identify the next-hop address. 475 This decision does not affect the network's ability to identify the 476 next-hop address. 478 5.3. Static Direct Peering Use Case - Assisting LUF and LRF 480 This use case shares many properties with the Static Direct Peering 481 Use Case. There must exist a pre-association between the O-SSP and 482 T-SSP. The difference is O-SSP will use the Assisting LUF/LRF 483 Provider for LUF and LRF. The LUF/LRF Provider stores the SED to 484 reach T-SSP and provides it to O-SSP when O-SSP requests it. 486 +-----------------+ 487 |LUF/LRF Provider | 488 | | 489 | +-------+ | 490 | +-+ A-LUF | | 491 | / | A-LRF | | 492 +--------------------+ / ++-------+ +---------------------+ 493 | O-SSP |/ / | T-SSP | 494 | +------------/(4,5,6) | +-----+ | 495 | / | / | |T-LUF| | 496 | (2) +-+/ | +-|T-LRF| | 497 | / / | | / +-----+ | 498 | / / | | /(8,9) | 499 |+-------+ +-----+ +-----+ +-------+| 500 ||O-Proxy|-(3)-|O-SBE+-------(7)-------+T-SBE|-(10)-|T-Proxy|| 501 |+-------+ +-----+ +-----+ +-------+| 502 | | | | | | 503 | (1) | | (11) | 504 | | | | | | 505 | +-----+ +-----+ +-----+ +-----+ | 506 | | UAC +======|O-DBE+=======(12)======+T-DBE+=======+ UAS | | 507 | +-----+ +-----+ +-----+ +-----+ | 508 +--------------------+ +---------------------+ 509 example.com example.net 511 Static Direct Peering with Assisting LUF and LRF 513 Figure 3 515 The call flow looks almost identical to Static Direct Peering Use 516 Case except Step 2,4,5 and 6 involve the LUF/LRF Provider instead of 517 happening in O-SSP domain. 519 Similar to Static Direct Peering Use case, O-DBE and T-DBE in 520 Figure 3 are optional. 522 5.3.1. Administrative Characteristics 524 The LUF/LRF Provider provides the LUF and LRF services for the O-SSP. 525 Taken together LUF/LRF Provider, O-SSP, and T-SSP form a trusted 526 administrative domain. To reach T-SSP, O-SSP must still require pre- 527 arranged agreements for the peer relationship with T-SSP. The 528 Layer-5 policy is maintained in the O-SSP and T-SSP domains, and the 529 LUF/LRF Provider may not be aware of any Layer-5 policy between the 530 O-SSP and T-SSP. 532 A LUF/LRF Provider can serve multiple administrative domains. The 533 LUF/LRF Provider typically does not share SED from one administrative 534 domain to another administrative domain without appropriate 535 permission. 537 5.3.2. Options and Nuances 539 The LUF/LRF Provider can use multiple methods to provide SED to 540 O-SSP. The most commonly used are an ENUM lookup and a SIP Redirect. 541 The O-SSP should negotiate with the LUF/LRF Provider which query 542 method it will use prior to sending request to LUF/LRF Provider. 544 The LUF/LRF Providers must be populated with the T-SSP's AORs and 545 SED. Currently, this procedure is non-standardized and labor 546 intensive. A more detailed description of this problem has been 547 documented in the work in progress 548 [I-D.ietf-drinks-usecases-requirements]. 550 5.4. Static Indirect Peering Use Case - Assisting LUF and LRF 552 The difference between a Static Direct Use Case and a Static Indirect 553 Use Case lies within the Layer-5 relationship maintained by O-SSP and 554 T-SSP. In the Indirect use case, the O-SSP and T-SSP do not have 555 direct Layer-5 connectivity. They require one or multiple Indirect 556 Domains to assist routing the SIP messages and possibly the 557 associated media. 559 In this use case, the O-SSP and T-SSP want to form a peer 560 relationship. For some reason, the O-SSP and T-SSP do not have 561 direct Layer-5 connectivity. The reasons may vary, for example 562 business demands and/or domain policy controls. Due to this indirect 563 relationship the signaling will traverse from O-SSP through one or 564 multiple I-SSP(s) to reach T-SSP. 566 In addition, O-SSP is using a LUF/LRF Provider. This LUF/LRF 567 Provider stores the T-SSP's SED pre-populated by T-SSP. One 568 important motivation to use the LUF/LRF Provider is that T-SSP only 569 needs to populate its SED once to the provider. Using LUF/LRF 570 Provider allows the T-SSP to populate its SED once, while any O-SSP 571 T-SSP's SED can use this LUF/LRF Provider. Current practice has 572 shown that it is rather difficult for the T-SSP to populate its SED 573 to every O-SSP who must reach the T-SSP's subscribers. This is 574 especially true in the Enterprise environment. 576 Note that the LUF/LRF Provider and I-SSP can be the same provider or 577 different providers. 579 +------------------+ 580 | LUF/LRF Provider | 581 | I-SSP | 582 | +-------+ | 583 | ---+ A-LUF | | 584 | / | A-LRF | | 585 +--------------------+ / +-------+ +---------------------+ 586 | O-SSP |/ / | T-SSP | 587 | +-------------/ / | +-----+ | 588 | / |(4,5,6) | |T-LUF| | 589 | / | / | +----+T-LRF| | 590 | (2) + +--- | / +-----+ | 591 | / / | | /(9,10) | 592 |+-------+ +-----+ +-----+ +-----+ +-------+| 593 ||O-Proxy|-(3)-|O-SBE+-(7)-+I-SBE+-(8)--+T-SBE+-(11)-|T-Proxy|| 594 |+-------+ +-----+ +-----+ +-----+ +-------+| 595 | | | | | | 596 | (1) | | (12) | 597 | | | | | | 598 | +-----+ +-----+ +-----+ +-----+ +-----+ | 599 | | UAC +=(13)=|O-DBE+=====+I-DBE+======+T-DBE+=======+ UAS | | 600 | +-----+ +-----+ +-----+ +-----+ +-----+ | 601 +-------------------------------------------------------------+ 602 example.com example.org example.net 604 Indirect Peering via LUF/LRF Provider and I-SSP (SIP and media) 606 Figure 4 608 The following is a high-level depiction of the use case: 610 1. UAC initiates a call via SIP INVITE to O-Proxy. O-Proxy is the 611 home proxy for UAC. 613 INVITE sip:+19175550100@example.com;user=phone SIP/2.0 614 Via: SIP/2.0/TCP client.example.com:5060 615 ;branch=z9hG4bK74bf9 616 Max-Forwards: 10 617 From: Alice 618 ;tag=12345 619 To: Bob 620 Call-ID: abcde 621 CSeq: 1 INVITE 622 623 Contact: 625 627 2. UAC knows UAS's TN, but does not know UAS's domain. It appends 628 its own domain to generate the SIP URI in Request-URI and TO 629 header. O-Proxy checks the Request-URI and discovers that the 630 Request-URI contains user parameter "user=phone". This 631 parameter indicates that the Request-URI is a phone number. So 632 O-Proxy will extract the TN from the Request-URI and query LUF 633 for SED information from a routing database. In this example, 634 the LUF is an ENUM database. The ENUM entry looks similar to 635 this: 637 $ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa. 638 IN NAPTR ( 639 10 640 100 641 "u" 642 "E2U+SIP" 643 "!^.*$!sip:+19175550100@example.org!" 644 . ) 646 Note that the response shows the next-hop is the SBE in I-SSP. 648 Alternatively, O-SSP may have a pre-association with I-SSP. As 649 such, O-SSP will forward all requests which contains an external 650 domain in the Request-URI or unknown TN to I-SSP. The O-SSP 651 will rely on the I-SSP to determine the T-SSP and route the 652 request correctly. In this configuration, the O-SSP can skip 653 Steps 2,4,5 and 6 and forward the request directly to the I-SBE. 654 This configuration is commonly used in the Enterprise 655 environment. 657 3. Given the O-Proxy's internal routing policy, O-Proxy decides to 658 use O-SBE to reach I-SBE. O-Proxy routes the INVITE request to 659 O-SBE and adds a Route header which contains the O-SBE. 661 INVITE sip:+19175550100@example.org;user=phone SIP/2.0 662 Via: SIP/2.0/TCP o-proxy.example.com:5060 663 ;branch=z9hG4bKye8ad 664 Via: SIP/2.0/TCP client.example.com:5060 665 ;branch=z9hG4bK74bf9;received=192.0.1.1 666 Max-Forwards: 9 667 Route: 668 Record-Route: 669 From: Alice 670 ;tag=12345 671 To: Bob 672 Call-ID: abcde 673 CSeq: 1 INVITE 674 675 Contact: 677 679 4. O-SBE receives the requests and pops the top entry of the Route 680 header which contains "sip:o-sbe1.example.com". O-SBE examines 681 the Request-URI and does a LRF for "example.org". In this 682 example, the LRF is a NAPTR DNS query of the domain. O-SBE 683 receives a response similar to this: 685 IN NAPTR ( 686 50 687 50 688 "S" 689 "SIP+D2T" 690 "" 691 _sip._tcp.i-sbe.example.org. ) 693 IN NAPTR ( 694 90 695 50 696 "S" 697 "SIP+D2U" 698 "" 699 _sip._udp.i-sbe.example.org. ) 701 5. Given the lower order for TCP in the NAPTR response, O-SBE 702 decides to use TCP for transport protocol, so it sends a SRV DNS 703 query for the SRV record for "_sip._tcp.i-sbe.example.org." to 704 O-LRF. 706 ;; priority weight port target 707 IN SRV 0 2 5060 i-sbe1.example.org. 708 IN SRV 0 1 5060 i-sbe2.example.org. 710 6. Given the higher weight for "i-sbe1.example.org", O-SBE sends a 711 DNS query for A record of "i-sbe1.example.org." to get the A 712 record: 714 ;; DNS ANSWER 715 i-sbe1.example.org. IN A 192.0.2.200 716 i-sbe1.example.org. IN A 192.0.2.201 718 7. O-SBE sends the INVITE to I-SBE. O-SBE is the entry point to 719 the O-SSP domain, so it should ensure subsequent mid-dialog 720 requests traverse via itself. If O-SBE chooses to act as a 721 B2BUA, it will generate a new back-to-back INVITE request in 722 next step. If O-SBE chooses to act as proxy, it should record- 723 route to stay in the call path. In this example, O-SBE is a 724 B2BUA. 726 INVITE sip:+19175550100@example.org;user=phone SIP/2.0 727 Via: SIP/2.0/TCP o-sbe1.example.com:5060 728 ;branch= z9hG4bK2d4zzz 729 Max-Forwards: 8 730 Route: 731 From: Alice 732 ;tag=54321 733 To: Bob 734 Call-ID: abcde-osbe1 735 CSeq: 1 INVITE 736 737 Contact: 739 741 8. I-SBE receives the request and queries its internal routing 742 database on the TN. It determines the target belongs to T-SSP. 743 Since I-SBE is a B2BUA, I-SBE generates a new INVITE request to 744 T-SSP. 746 INVITE sip:+19175550100@.example.net;user=phone SIP/2.0 747 Via: SIP/2.0/TCP i-sbe1.example.org:5060 748 ;branch= z9hG4bK2d4777 749 Max-Forwards: 7 750 Route: 751 From: Alice 752 ;tag=54321 753 To: Bob 754 Call-ID: abcde-isbe1 755 CSeq: 1 INVITE 756 757 Contact: 759 761 Note that if I-SSP wants the media to traverse through the 762 I-DBE, I-SBE must modify the SDP in the Offer to point to its 763 DBE. 765 9. T-SBE determines the called party home proxy and directs the 766 call to the called party. T-SBE may use ENUM lookup or other 767 internal mechanism to locate the home proxy. If T-SSP uses ENUM 768 lookup, this internal ENUM entry is different from the external 769 ENUM entry populated for O-SSP. This internal ENUM entry will 770 contain the information to identify the next-hop to reach the 771 called party. In this example, the internal ENUM query returns 772 the UAS's home proxy. 774 $ORIGIN 0.0.1.0.5.5.5.7.1.9.1.e164.arpa. 775 IN NAPTR ( 776 10 777 100 778 "u" 779 "E2U+SIP" 780 "!^.*$!sip:+19175550100@t-proxy.example.net!" 781 . ) 783 Note that this step is optional. If T-SBE has other ways to 784 locate the UAS home proxy, T-SBE can skip this step and send the 785 request to the UAS's home proxy. We show this step to 786 illustrate one of the many possible ways to locate UAS's home 787 proxy. 789 10. T-SBE receives the NAPTR record and following the requirements 790 in [RFC3263] queries DNS for the SRV records indicated by the 791 NAPTR result. Not finding any, the T-SBE then queries DNS for 792 the A record of domain "t-proxy.example.net.". 794 ;; DNS ANSWER 795 t-proxy.example.net. IN A 192.0.2.2 797 11. T-SBE sends the INVITE to UAS's home proxy: 799 INVITE sip:+19175550100@t-proxy.example.net;user=phone SIP/2.0 800 Via: SIP/2.0/TCP t-sbe1.example.net:5060 801 ;branch= z9hG4bK28uyyy 802 Max-Forwards: 6 803 Record-Route: 804 From: Alice 805 ;tag=54321 806 To: Bob 807 Call-ID: abcde-tsbe1 808 CSeq: 1 INVITE 809 810 Contact: 812 814 12. Finally, UAS's home proxy forwards the INVITE request to UAS. 816 INVITE sip:+19175550100@server.example.net;user=phone SIP/2.0 817 Via: SIP/2.0/TCP t-proxy.example.net:5060 818 ;branch= z9hG4bK28u111 819 Via: SIP/2.0/TCP t-sbe1.example.net:5060 820 ;branch= z9hG4bK28uyyy; received=192.2.0.100 821 Max-Forwards: 5 822 Record-Route: , 823 824 From: Alice 825 ;tag=54321 826 To: Bob 827 Call-ID: abcde-tsbe1 828 CSeq: 1 INVITE 829 830 Contact: 832 834 13. In Figure 4, RTP is established between UAC and UAS via O-DBE, 835 I-DBE and T-DBE. The use of DBE is optional. 837 5.4.1. Administrative characteristics 839 This use case looks very similar to the Static Direct Peering with 840 Assisting LUF and LRF. The major difference is the O-SSP and T-SSP 841 do not have direct Layer-5 connectivity. Instead, O-SSP connects to 842 T-SSP indirectly via I-SSP. 844 Typically, a LUF/LRF Provider serves multiple O-SSPs. Two O-SSPs may 845 use different I-SSP to reach the same T-SSP. For example, O-SSP1 may 846 use I-SSP1 to reach T-SSP, but O-SSP2 may use I-SSP2 to reach T-SSP. 847 Given the O-SSP and T-SSP pair as input, the LUF/LRF Provider will 848 return the SED of I-SSP that is trusted by O-SSP to forward the 849 request to T-SSP. 851 In this use case. there are two levels of trust relationship. First 852 trust relationship is between the O-SSP and LUF/LRF Provider. The 853 O-SSP trusts the LUF/LRF to provide the T-SSP's SED. Second trust 854 relationship is between O-SSP and I-SSP. The O-SSP trusts the I-SSP 855 to provide Layer-5 connectivity to assist the O-SSP to reach T-SSP. 856 The O-SSP and I-SSP have a pre-arranged agreement for policy. Note 857 that Figure 4 shows a single provider to provide both LUF/LRF and 858 I-SSP, but O-SSP can choose two different providers. 860 5.4.2. Options and Nuances 862 Similar to the Static Direct Peering Use Case, the O-SSP and T-SSP 863 may deploy SBE and DBE for NAT traversal, security, transcoding, etc. 864 I-SSP can also deploy SBE and DBE for similar reasons. (as depicted 865 in Figure 4) 867 5.5. Static Indirect Peering Use Case 869 This use case shares many properties with the Static Indirect Use 870 Case with Assisting LUF and LRF. The difference is that the O-SSP 871 uses its internal LUF/LRF to control the routing database. By 872 controlling the database, O-SSP can apply different routing rules and 873 policies to different T-SSPs. For example, O-SSP can use I-SSP1 and 874 Policy-1 to reach T-SSP1, and use I-SSP2 and Policy-2 to reach 875 T-SSP2. Note that there could be multiple I-SSPs and multiple SIP 876 routes to reach the same T-SSP; the selection process is out of scope 877 of this document. 879 +--------------------+-------------------+---------------------+ 880 | O-SSP | I-SSP | T-SSP | 881 | +-----+ | | +-----+ | 882 | -+O-LUF| | | |T-LUF| | 883 | / |O-LRF+\ | | +----+T-LRF| | 884 | / +-----+ \ | | / +-----+ | 885 | /(2) \(4,5,6) | /(9,10) | 886 |+-------+ +-----+ +-----+ +-----+ +-------+| 887 ||O-Proxy|-(3)-|O-SBE+--(7)-+I-SBE+-(8)--+T-SBE+-(11)-|T-Proxy|| 888 |+-------+ +-----+ +-----+ +-----+ +-------+| 889 | | | | | | 890 | (1) | | (12) | 891 | | | | | | 892 | +-----+ +-----+ +-----+ +-----+ +-----+ | 893 | | UAC +=(13)=+O-DBE+======+I-DBE+======+T-DBE+=======+ UAS | | 894 | +-----+ +-----+ +-----+ +-----+ +-----+ | 895 +--------------------------------------------------------------+ 896 example.com example.org example.net 898 Indirect Peering via I-SSP (SIP and media) 900 Figure 5 902 5.5.1. Administrative characteristics 904 The Static Indirect Peering Use Case is implemented in cases where no 905 direct interconnection exists between the originating and terminating 906 domains due to either business or physical constraints. 908 O-SSP <---> I-SSP = Relationship O-I 910 In the O-I relationship, typical policies, features or functions that 911 deem this relationship necessary are number portability, Ubiquity of 912 termination options, security certificate management and masquerading 913 of originating VoIP network gear. 915 T-SSP <---> I-SSP = Relationship T-I 917 In the T-I relationship, typical policies, features or functions 918 observed consist of codec "scrubbing", anonymizing, and transcoding. 919 I-SSP must record-route and stay in the signaling path. T-SSP will 920 not accept message sent directly from O-SSP. 922 5.5.2. Options and Nuances 924 In Figure 5, we show I-DBE. Using I-DBE is optional. For example, 925 the I-DBE can be used is when the O-SSP and T-SSP do not have a 926 common codec. To involve I-DBE, I-SSP should know the list of codecs 927 supported by O-SSP and T-SSP. When I-SBE receives the INVITE 928 request, it will make a decision to invoke the I-DBE. An I-DBE may 929 also be used if O-SSP uses SRTP [RFC3711] for media and T-SSP does 930 not support SRTP. 932 5.6. On-demand Peering Use Case 934 On-demand Peering [RFC5486] describes how two SSPs form the peering 935 relationship without a pre-arranged agreement. 937 The basis of this use case is built on the fact that there is no pre- 938 established relationship between the O-SSP and T-SSP. The O-SSP and 939 T-SSP does not share any information prior to the dialog initiation 940 request. When the O-Proxy invokes the LUF and LRF on the Request- 941 URI, the terminating user information must be publicly available. 942 When the O-Proxy routes the request to the T-Proxy, the T-Proxy must 943 accept the request without any pre-arranged agreement with O-SSP. 945 The On-demand Peering Use Case is uncommon in production. In this 946 memo, we capture only the high-level descriptions. Further analysis 947 is expected when this use case becomes more popular. 949 5.6.1. Administrative characteristics 951 The On-demand Direct Peering Use Case is typically implemented in a 952 scenario where the T-SSP allows any O-SSP to reach its serving 953 subscribers. T-SSP administrative domain does not require any pre- 954 arranged agreement to accept the call. The T-SSP makes its 955 subscribers information publicly available. This model mimics the 956 Internet email model. Sender does not need an pre-arranged agreement 957 to send email to the receiver. 959 5.6.2. Options and Nuances 961 Similar to the Static Direct Peering Use Case, the O-SSP and T-SSP 962 can decide to deploy SBE. Since T-SSP is open to the public, T-SSP 963 is considered to be in higher security risk than static model because 964 there is no trusted relationship between O-SSP and T-SSP. T-SSP 965 should protect itself from any attack launched by untrusted O-SSP. 967 6. Acknowledgments 969 Michael Haberler, Mike Mammer, Otmar Lendl, Rohan Mahy, David 970 Schwartz, Eli Katz and Jeremy Barkan are the authors of the early 971 individual drafts. Their use cases are captured in this document. 972 Besides, Jason Livingood, Daryl Malas, David Meyer, Hadriel Kaplan, 973 John Elwell, Reinaldo Penno, Sohel Khan, James McEachern, Jon 974 Peterson, Alexander Mayrhofer, and Jean-Francois Mule made many 975 valuable comments to this document. The editors would also like to 976 extend a special thank to Spencer Dawkins for his detailed review of 977 this document. 979 7. Security Considerations 981 Session interconnect for VoIP, as described in this document, has a 982 wide variety of security issues that should be considered. For 983 example, if the O-SSP and T-SSP peer through public Internet, O-SSP 984 must protect the signaling channel and accept messages only from 985 authorized T-SSP. This document does not analyze the threats in 986 details. [I-D.ietf-speermint-voipthreats] discusses the different 987 security threats and countermeasures related to VoIP peering. 989 8. IANA Considerations 991 Note to RFC Editor: please delete this section before publication. 993 9. References 995 9.1. Normative References 997 [I-D.ietf-speermint-voipthreats] 998 Niccolini, S., Chen, E., Seedorf, J., and H. Scholz, 999 "SPEERMINT Security Threats and Suggested 1000 Countermeasures", draft-ietf-speermint-voipthreats-01 1001 (work in progress), July 2009. 1003 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1004 E. Lear, "Address Allocation for Private Internets", 1005 BCP 5, RFC 1918, February 1996. 1007 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1008 specifying the location of services (DNS SRV)", RFC 2782, 1009 February 2000. 1011 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1012 A., Peterson, J., Sparks, R., Handley, M., and E. 1013 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1014 June 2002. 1016 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1017 Protocol (SIP): Locating SIP Servers", RFC 3263, 1018 June 2002. 1020 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1021 Part Three: The Domain Name System (DNS) Database", 1022 RFC 3403, October 2002. 1024 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 1025 Resource Identifiers (URI) Dynamic Delegation Discovery 1026 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 1028 [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia 1029 Interconnect (SPEERMINT) Terminology", RFC 5486, 1030 March 2009. 1032 9.2. Informative References 1034 [I-D.ietf-drinks-usecases-requirements] 1035 Channabasappa, S., "DRINKS Use cases and Protocol 1036 Requirements", draft-ietf-drinks-usecases-requirements-00 1037 (work in progress), May 2009. 1039 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1040 "Definition of the Differentiated Services Field (DS 1041 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1042 December 1998. 1044 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1045 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1046 RFC 3711, March 2004. 1048 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1049 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1051 Authors' Addresses 1053 Adam Uzelac (editor) 1054 Global Crossing 1055 U.S.A. 1057 Email: adam.uzelac@globalcrossing.com 1058 URI: http://www.globalcrossing.com 1059 Yiu L.Lee (editor) 1060 Comcast Cable 1061 U.S.A. 1063 Email: yiu_lee@cable.comcast.com 1064 URI: http://www.comcast.com