idnits 2.17.1 draft-ietf-speermint-architecture-17.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 abstract seems to contain references ([RFC3261]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 20, 2010) is 4868 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '4' on line 161 == Outdated reference: A later version (-11) exists of draft-ietf-speermint-requirements-10 == Outdated reference: A later version (-09) exists of draft-ietf-speermint-voipthreats-06 ** Obsolete normative reference: RFC 3761 (Obsoleted by RFC 6116, RFC 6117) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-19) exists of draft-ietf-speermint-voip-consolidated-usecases-18 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPEERMINT D. Malas, Ed. 3 Internet-Draft CableLabs 4 Intended status: Informational J. Livingood, Ed. 5 Expires: June 23, 2011 Comcast 6 December 20, 2010 8 Session PEERing for Multimedia INTerconnect Architecture 9 draft-ietf-speermint-architecture-17 11 Abstract 13 This document defines a peering architecture for the Session 14 Initiation Protocol (SIP) [RFC3261], its functional components and 15 interfaces. It also describes the components and the steps necessary 16 to establish a session between two SIP Service Provider (SSP) peering 17 domains. 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 June 23, 2011. 36 Copyright Notice 38 Copyright (c) 2010 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 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Reference Architecture . . . . . . . . . . . . . . . . . . . . 4 67 3. Procedures of Inter-Domain SSP Session Establishment . . . . . 6 68 4. Relationships Between Functions/Elements . . . . . . . . . . . 7 69 5. Recommended SSP Procedures . . . . . . . . . . . . . . . . . . 7 70 5.1. Originating or Indirect SSP Procedures . . . . . . . . . . 8 71 5.1.1. The Look-Up Function (LUF) . . . . . . . . . . . . . . 8 72 5.1.1.1. Target Address Analysis . . . . . . . . . . . . . 8 73 5.1.1.2. ENUM Lookup . . . . . . . . . . . . . . . . . . . 9 74 5.1.2. Location Routing Function (LRF) . . . . . . . . . . . 9 75 5.1.2.1. DNS Resolution . . . . . . . . . . . . . . . . . . 9 76 5.1.2.2. Routing Table . . . . . . . . . . . . . . . . . . 10 77 5.1.2.3. LRF to LRF Routing . . . . . . . . . . . . . . . . 10 78 5.1.3. The Signaling Path Border Element (SBE) . . . . . . . 10 79 5.1.3.1. Establishing a Trusted Relationship . . . . . . . 10 80 5.1.3.2. IPSec . . . . . . . . . . . . . . . . . . . . . . 10 81 5.1.3.3. Co-Location . . . . . . . . . . . . . . . . . . . 11 82 5.1.3.4. Sending the SIP Request . . . . . . . . . . . . . 11 83 5.2. Target SSP Procedures . . . . . . . . . . . . . . . . . . 11 84 5.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 5.2.2. Receive SIP Requests . . . . . . . . . . . . . . . . . 11 86 5.3. Data Path Border Element (DBE) . . . . . . . . . . . . . . 12 87 6. Address Space Considerations . . . . . . . . . . . . . . . . . 12 88 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 91 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 92 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 94 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 95 12.2. Informative References . . . . . . . . . . . . . . . . . . 16 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 99 1. Introduction 101 This document defines a reference peering architecture for the 102 Session Initiation Protocol (SIP)[RFC3261], it's functional 103 components and interfaces, in the context of session peering for 104 multimedia interconnects. In this process, we define the peering 105 reference architecture, its functional components, and peering 106 interface functions from the perspective of a SIP Service Provider's 107 (SSP) [RFC5486] network. Thus, it also describes the components and 108 the steps necessary to establish a session between two SSP peering 109 domains. 111 This architecture enables the interconnection of two SSPs in layer 5 112 peering, as defined in the SIP-based session peering requirements 113 [I-D.ietf-speermint-requirements]. 115 Layer 3 peering is outside the scope of this document. Hence, the 116 figures in this document do not show routers so that the focus is on 117 layer 5 protocol aspects. 119 This document uses terminology defined in the Session Peering for 120 Multimedia Interconnect (SPEERMINT) Terminology document [RFC5486]. 121 Apart from normative references included herein, readers may also 122 find [I-D.ietf-speermint-voip-consolidated-usecases] informative. 124 2. Reference Architecture 126 The following figure depicts the architecture and logical functions 127 that form peering between two SSPs. 129 For further details on the elements and functions described in this 130 figure, please refer to [RFC5486]. The following terms, which appear 131 in Figure 1, which are documented in [RFC5486] are reproduced here 132 for simplicity. 134 - Data Path Border Element (DBE): A data path border element (DBE) is 135 located on the administrative border of a domain through which flows 136 the media associated with an inter-domain session. It typically 137 provides media-related functions such as deep packet inspection and 138 modification, media relay, and firewall-traversal support. The DBE 139 may be controlled by the SBE. 141 - E.164 Number Mapping (ENUM): See [RFC3761]. 143 - Fully Qualified Domain Name (FQDN): See Section 5.1 of [RFC1035]. 145 - Location Routing Function (LRF): The Location Routing Function 146 (LRF) determines for the target domain of a given request the 147 location of the SF in that domain, and optionally develops other SED 148 required to route the request to that domain. An example of the LRF 149 may be applied to either example in Section 4.3.3 of [RFC5486]. Once 150 the ENUM response or SIP 302 redirect is received with the 151 destination's SIP URI, the LRF must derive the destination peer's SF 152 from the FQDN in the domain portion of the URI. In some cases, some 153 entity (usually a 3rd party or federation) provides peering 154 assistance to the originating SSP by providing this function. The 155 assisting entity may provide information relating to direct (Section 156 4.2.1 of [RFC5486]) or indirect (Section 4.2.2 of [RFC5486]) peering 157 as necessary. 159 - Look-Up Function (LUF): The Look-Up Function (LUF) determines for a 160 given request the target domain to which the request should be 161 routed. An example of an LUF is an ENUM [4] look-up or a SIP INVITE 162 request to a SIP proxy providing redirect responses for peers. In 163 some cases, some entity (usually a 3rd party or federation) provides 164 peering assistance to the originating SSP by providing this function. 165 The assisting entity may provide information relating to direct 166 (Section 4.2.1 of [RFC5486]) or indirect (Section 4.2.2 of [RFC5486]) 167 peering as necessary. 169 - Real-Time Transport Protocol (RTP): See [RFC3550]. 171 - Session Initiation Protocol (SIP): See [RFC3261]. 173 - Signaling Path Border Element (SBE): A signaling path border 174 element (SBE) is located on the administrative border of a domain 175 through which inter-domain session layer messages will flow. It 176 typically provides signaling functions such as protocol inter-working 177 (for example, H.323 to SIP), identity and topology hiding, and 178 Session Admission Control for a domain. 180 - Signaling Function (SF): The Signaling Function (SF) performs 181 routing of SIP requests for establishing and maintaining calls, and 182 to assist in the discovery or exchange of parameters to be used by 183 the Media Function (MF). The SF is a capability of SIP processing 184 elements such as SIP proxies, SBEs, and user agents. 186 - SIP Service Provider (SSP): A SIP Service Provider (SSP) is an 187 entity that provides session services utilizing SIP signaling to its 188 customers. In the event that the SSP is also a function of the SP, 189 it may also provide media streams to its customers. Such an SSP may 190 additionally be peered with other SSPs. An SSP may also interconnect 191 with the PSTN. An SSP may also be referred to as an Internet 192 Telephony Service Provider (ITSP). While the terms ITSP and SSP are 193 frequently used interchangeably, this document and other subsequent 194 SIP peering-related documents should use the term SSP. SSP more 195 accurately depicts the use of SIP as the underlying layer 5 signaling 196 protocol. 198 +=============++ ++==============+ 199 || || 200 +-----------+ +-----------+ 201 | SBE | +-----+ | SBE | 202 | +-----+ | SIP |Proxy| | +-----+ | 203 | | LUF |<-|------>|ENUM | | | LUF | | 204 | +-----+ | ENUM |TN DB| | +-----+ | 205 SIP | | +-----+ | | 206 ------>| +-----+ | DNS +-----+ | +-----+ | 207 | | LRF |<-|------>|FQDN | | | LRF | | 208 | +-----+ | |IP | | +-----+ | 209 | +-----+ | SIP +-----+ | +-----+ | 210 | | SF |<-|----------------|->| SF | | 211 | +-----+ | | +-----+ | 212 +-----------+ +-----------+ 213 || || 214 +-----------+ +-----------+ 215 RTP | DBE | RTP | DBE | 216 ------>| |--------------->| | 217 +-----------+ +-----------+ 218 || || 219 SSP1 Network || || SSP2 Network 220 +=============++ ++=============+ 222 Reference Architecture 224 Figure 1 226 3. Procedures of Inter-Domain SSP Session Establishment 228 This document assumes that in order for a session to be established 229 from a User Agent (UA) in the originating (or indirect) SSP's network 230 to an UA in the Target SSP's network the following steps are taken: 232 1. Determine the target or indirect SSP via the LUF. (Note: If the 233 target address represents an intra-SSP resource, the behavior is 234 out-of-scope with respect to this draft.) 236 2. Determine the address of the SF of the target SSP via the LRF. 238 3. Establish the session 240 4. Exchange the media, which could include voice, video, text, etc. 242 5. End the session (BYE) 244 The originating or indirect SSP would likely perform steps 1-4, the 245 target SSP would likely perform steps 4, and either one is likely to 246 perform step 5. 248 In the case the target SSP changes, then steps 1-4 would be repeated. 249 This is reflected in Figure 1 that shows the target SSP with its own 250 peering functions. 252 4. Relationships Between Functions/Elements 254 o An SBE can contain a SF function. 256 o An SF can perform LUF and LRF functions. 258 o As an additional consideration, a Session Border Controller, can 259 contain an SF, SBE and DBE, and may perform the LUF and LRF 260 functions. 262 o The following functions can communicate as follows, depending upon 263 various real-world implementations: 265 * SF can communicate with LUF, LRF, SBE and SF 267 * LUF can communicator with SF and SBE 269 * LRF can communicate with SF and SBE 271 5. Recommended SSP Procedures 273 This section describes the functions in more detail and provides some 274 recommendations on the role they would play in a SIP call in a Layer 275 5 peering scenario. 277 Some of the information in the section is taken from 278 [I-D.ietf-speermint-requirements] and is put here for continuity 279 purposes. 281 5.1. Originating or Indirect SSP Procedures 283 This section describes the procedures of the originating or indirect 284 SSP. 286 5.1.1. The Look-Up Function (LUF) 288 The purpose of the LUF is to determine the SF of the target domain of 289 a given request and optionally to develop Session Establishment Data. 290 It is important to note that the LUF may utilize the public e164.arpa 291 ENUM root, as well as one or more private roots. When private roots 292 are used specialized routing rules may be implemented, and these 293 rules may vary depending upon whether an originating or indirect SSP 294 is querying the LUF. 296 5.1.1.1. Target Address Analysis 298 When the originating (or indirect) SSP receives a request to 299 communicate, it analyzes the target URI to determine whether the call 300 needs to be routed internal or external to its network. The analysis 301 method is internal to the SSP; thus, outside the scope of SPEERMINT. 303 If the target address does not represent a resource inside the 304 originating (or indirect) SSP's administrative domain or federation 305 of domains, then the originating (or indirect) SSP performs a Lookup 306 Function (LUF) to determine a target address, and then is resolves 307 the call routing data by using the Location routing Function (LRF). 309 For example, if the request to communicate is for an im: or pres: URI 310 type [RFC3861] [RFC3953], the originating (or indirect) SSP follows 311 the procedures in [RFC3861]. If the highest priority supported URI 312 scheme is sip: or sips: the originating (or indirect) SSP skips to 313 SIP DNS resolution in Section 5.1.3. Likewise, if the target address 314 is already a sip: or sips: URI in an external domain, the originating 315 (or indirect) SSP skips to SIP DNS resolution in Section 5.1.2.1. 316 This may be the case, to use one example, with 317 "sips:bob@biloxi.example.com". 319 If the target address corresponds to a specific E.164 address, the 320 SSP may need to perform some form of number plan mapping according to 321 local policy. For example, in the United States, a dial string 322 beginning "011 44" could be converted to "+44", or in the United 323 Kingdom "00 1" could be converted to "+1". Once the SSP has an E.164 324 address, it can use ENUM. 326 5.1.1.2. ENUM Lookup 328 If an external E.164 address is the target, the originating (or 329 indirect) SSP consults the public "User ENUM" rooted at e164.arpa, 330 according to the procedures described in [RFC3761]. The SSP must 331 query for the "E2U+sip" enumservice as described in [RFC3764], but 332 may check for other enumservices. The originating (or indirect) SSP 333 may consult a cache or alternate representation of the ENUM data 334 rather than actual DNS queries. Also, the SSP may skip actual DNS 335 queries if the originating (or indirect) SSP is sure that the target 336 address country code is not represented in e164.arpa. 338 If an im: or pres: URI is chosen based on an "E2U+im" [RFC3861] or 339 "E2U+pres" [RFC3953] enumserver, the SSP follows the procedures for 340 resolving these URIs to URIs for specific protocols such a SIP or 341 XMPP as described in the previous section. 343 The NAPTR response to the ENUM lookup may be a SIP AoR (such as 344 "sips:bob@example.com") or SIP URI (such as 345 "sips:bob@sbe1.biloxi.example.com"). In the case of when a SIP URI 346 is returned, the originating (or indirect) SSP has sufficient routing 347 information to locate the target SSP. In the case of when a SIP AoR 348 is returned, the SF then uses the LRF to determine the URI for more 349 explicitly locating the target SSP. 351 5.1.2. Location Routing Function (LRF) 353 The LRF of an originating (or indirect) SSP analyzes target address 354 and target domain identified by the LUF, and discovers the next hop 355 signaling function (SF) in a peering relationship. The resource to 356 determine the SF of the target domain might be provided by a third- 357 party as in the assisted-peering case. The following sections define 358 mechanisms which may be used by the LRF. These are not in any 359 particular order and, importantly, not all of them may be used. 361 5.1.2.1. DNS Resolution 363 The originating (or indirect) SSP uses the procedures in Section 4 of 364 [RFC3263] to determine how to contact the receiving SSP. To 365 summarize the [RFC3263] procedure: unless these are explicitly 366 encoded in the target URI, a transport is chosen using NAPTR records, 367 a port is chosen using SRV records, and an address is chosen using A 368 or AAAA records. 370 When communicating with another SSP, entities compliant to this 371 document should select a TLS-protected transport for communication 372 from the originating (or indirect) SSP to the receiving SSP if 373 available, as described further in Section 5.2.1. 375 5.1.2.2. Routing Table 377 If there are no End User ENUM records and the originating (or 378 indirect) SSP cannot discover the carrier-of-record or if the 379 originating (or indirect) SSP cannot reach the carrier-of-record via 380 SIP peering, the originating (or indirect) SSP may deliver the call 381 to the PSTN or reject it. Note that the originating (or indirect) 382 SSP may forward the call to another SSP for PSTN gateway termination 383 by prior arrangement using the routing table. 385 If so, the originating (or indirect) SSP rewrites the Request-URI to 386 address the gateway resource in the target SSP's domain and may 387 forward the request on to that SSP using the procedures described in 388 the remainder of these steps. 390 5.1.2.3. LRF to LRF Routing 392 Communications between the LRF of two interconnecting SSPs may use 393 DNS or statically provisioned IP Addresses for reachability. Other 394 inputs to determine the path may be code-based routing, method-based 395 routing, Time of day, least cost and/or source-based routing. 397 5.1.3. The Signaling Path Border Element (SBE) 399 The purpose of signaling function is to perform routing of SIP 400 messages as well as optionally implement security and policies on SIP 401 messages, and to assist in discovery/exchange of parameters to be 402 used by the Media Function (MF). The signaling function performs the 403 routing of SIP messages. The SBE may be a B2BUA or it may act as a 404 SIP proxy. Optionally, a SF may perform additional functions such as 405 Session Admission Control, SIP Denial of Service protection, SIP 406 Topology Hiding, SIP header normalization, SIP security, privacy, and 407 encryption. The SF of a SBE can also process SDP payloads for media 408 information such as media type, bandwidth, and type of codec; then, 409 communicate this information to the media function. 411 5.1.3.1. Establishing a Trusted Relationship 413 Depending on the security needs and trust relationships between SSPs, 414 different security mechanism can be used to establish SIP calls. 415 These are discussed in the following subsections. 417 5.1.3.2. IPSec 419 In certain deployments the use of IPSec between the signaling 420 functions of the originating and terminating domains can be used as a 421 security mechanism instead of TLS. 423 5.1.3.3. Co-Location 425 In this scenario the SFs are co-located in a physically secure 426 location and/or are members of a segregated network. In this case 427 messages between the originating and terminating SSPs would be sent 428 as clear text. 430 5.1.3.4. Sending the SIP Request 432 Once a trust relationship between the peers is established, the 433 originating (or indirect) SSP sends the request. 435 5.2. Target SSP Procedures 437 This section describes the Target SSP Procedures. 439 5.2.1. TLS 441 The section defines uses of TLS between two SSPs [RFC5246] [RFC5746] 442 [RFC5878]. When the receiving SSP receives a TLS client hello, it 443 responds with its certificate. The Target SSP certificate should be 444 valid and rooted in a well-known certificate authority. The 445 procedures to authenticate the SSP's originating domain are specified 446 in [RFC5922]. 448 The SF of the Target SSP verifies that the Identity header is valid, 449 corresponds to the message, corresponds to the Identity-Info header, 450 and that the domain in the From header corresponds to one of the 451 domains in the TLS client certificate. 453 5.2.2. Receive SIP Requests 455 Once a trust relationship is established, the Target SSP is prepared 456 to receive incoming SIP requests. For new requests (dialog forming 457 or not) the receiving SSP verifies if the target (request-URI) is a 458 domain that for which it is responsible. For these requests, there 459 should be no remaining Route header field values. For in-dialog 460 requests, the receiving SSP can verify that it corresponds to the 461 top-most Route header field value. 463 The receiving SSP may reject incoming requests due to local policy. 464 When a request is rejected because the originating (or indirect) SSP 465 is not authorized to peer, the receiving SSP should respond with a 466 403 response with the reason phrase "Unsupported Peer". 468 5.3. Data Path Border Element (DBE) 470 The purpose of the DBE [RFC5486] is to perform media related 471 functions such as media transcoding and media security implementation 472 between two SSPs. 474 An example of this is to transform a voice payload from one codec 475 (e.g., G.711) to another (e.g., EvRC). Additionally, the MF may 476 perform media relaying, media security [RFC3711], privacy, and 477 encryption. 479 6. Address Space Considerations 481 Peering must occur in a common IP address space, which is defined by 482 the federation, which may be entirely on the public Internet, or some 483 private address space [RFC1918]. The origination or termination 484 networks may or may not entirely be in the same address space. If 485 they are not, then a network address translation (NAT) or similar may 486 be needed before the signaling or media is presented correctly to the 487 federation. The only requirement is that all associated entities 488 across the peering interface are reachable. 490 7. Acknowledgments 492 The working group would like to thank John Elwell, Otmar Lendl, Rohan 493 Mahy, Alexander Mayrhofer, Jim McEachern, Jean-Francois Mule, 494 Jonathan Rosenberg, and Dan Wing for their valuable contributions to 495 various versions of this document. 497 8. IANA Considerations 499 This memo includes no request to IANA. 501 9. Security Considerations 503 In all cases, cryptographic-based security should be maintained as an 504 optional requirement between peering providers conditioned on the 505 presence or absence of underlying physical security of SSP 506 connections, e.g. within the same secure physical building. 508 In order to maintain a consistent approach, unique and specialized 509 security requirements common for the majority of peering 510 relationships, should be standardized within the IETF. These 511 standardized methods may enable capabilities such as dynamic peering 512 relationships across publicly maintained interconnections. 514 Additional security considerations have been documented separately in 515 [I-D.ietf-speermint-voipthreats]. 517 10. Contributors 519 Mike Hammer 521 Cisco Systems 523 Herndon, VA - USA 525 Email: mhammer@cisco.com 527 -------------------------------------------------------------- 529 Hadriel Kaplan 531 Acme Packet 533 Burlington, MA - USA 535 Email: hkaplan@acmepacket.com 537 -------------------------------------------------------------- 539 Sohel Khan, Ph.D. 541 Comcast Cable 543 Philadelphia, PA - USA 545 Email: sohel_khan@cable.comcast.com 547 -------------------------------------------------------------- 549 Reinaldo Penno 551 Juniper Networks 553 Sunnyvale, CA - USA 555 Email: rpenno@juniper.net 557 -------------------------------------------------------------- 558 David Schwartz 560 XConnect Global Networks 562 Jerusalem - Israel 564 Email: dschwartz@xconnnect.net 566 -------------------------------------------------------------- 568 Rich Shockey 570 Shockey Consulting 572 USA 574 Email: Richard@shockey.us 576 -------------------------------------------------------------- 578 Adam Uzelac 580 Global Crossing 582 Rochester, NY - USA 584 Email: adam.uzelac@globalcrossing.com 586 11. Change Log 588 NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION PRIOR TO PUBLICATION. 590 o 17: Misc. updates at the request of Gonzalo, the RAI AD, in order 591 to clear his review and move to the IESG. This included adding 592 terminology from RFC 5486 and expanding the document name. 594 o 16: Yes, one final outdated reference to fix. 596 o 15: Doh! Uploaded the wrong doc to create -14. Trying again. :-) 598 o 14: WGLC ended. Ran final nits check prior to sending proto to 599 the AD and sending the doc to the IESG. Found a few very minor 600 nits, such as capitalization and replacement of an obsoleted RFC, 601 which were corrected per nits tool recommendation. The -14 now 602 moves to the AD and the IESG. 604 o 13: Closed out all remaining tickets, resolved all editorial 605 notes. 607 o 12: Closed out several open issues. Properly XML-ized all 608 references. Updated contributors list. 610 o 11: Quick update to refresh the I-D since it expired, and cleaned 611 up some of the XML for references. A real revision is coming 612 soon. 614 12. References 616 12.1. Normative References 618 [I-D.ietf-speermint-requirements] 619 Mule, J., "Requirements for SIP-based Session Peering", 620 draft-ietf-speermint-requirements-10 (work in progress), 621 October 2010. 623 [I-D.ietf-speermint-voipthreats] 624 Seedorf, J., Niccolini, S., Chen, E., and H. Scholz, 625 "Session Peering for Multimedia Interconnect (SPEERMINT) 626 Security Threats and Suggested Countermeasures", 627 draft-ietf-speermint-voipthreats-06 (work in progress), 628 November 2010. 630 [RFC1035] Mockapetris, P., "Domain names - implementation and 631 specification", STD 13, RFC 1035, November 1987. 633 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 634 E. Lear, "Address Allocation for Private Internets", 635 BCP 5, RFC 1918, February 1996. 637 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 638 A., Peterson, J., Sparks, R., Handley, M., and E. 639 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 640 June 2002. 642 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 643 Protocol (SIP): Locating SIP Servers", RFC 3263, 644 June 2002. 646 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 647 Jacobson, "RTP: A Transport Protocol for Real-Time 648 Applications", STD 64, RFC 3550, July 2003. 650 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 651 Resource Identifiers (URI) Dynamic Delegation Discovery 652 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 654 [RFC3764] Peterson, J., "enumservice registration for Session 655 Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, 656 April 2004. 658 [RFC3861] Peterson, J., "Address Resolution for Instant Messaging 659 and Presence", RFC 3861, August 2004. 661 [RFC3953] Peterson, J., "Telephone Number Mapping (ENUM) Service 662 Registration for Presence Services", RFC 3953, 663 January 2005. 665 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 666 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 668 [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia 669 Interconnect (SPEERMINT) Terminology", RFC 5486, 670 March 2009. 672 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 673 "Transport Layer Security (TLS) Renegotiation Indication 674 Extension", RFC 5746, February 2010. 676 [RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS) 677 Authorization Extensions", RFC 5878, May 2010. 679 [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 680 Certificates in the Session Initiation Protocol (SIP)", 681 RFC 5922, June 2010. 683 12.2. Informative References 685 [I-D.ietf-speermint-voip-consolidated-usecases] 686 Uzelac, A. and Y. Lee, "VoIP SIP Peering Use Cases", 687 draft-ietf-speermint-voip-consolidated-usecases-18 (work 688 in progress), April 2010. 690 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 691 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 692 RFC 3711, March 2004. 694 Authors' Addresses 696 Daryl Malas (editor) 697 CableLabs 698 Louisville, CO 699 US 701 Email: d.malas@cablelabs.com 703 Jason Livingood (editor) 704 Comcast 705 Philadelphia, PA 706 US 708 Email: Jason_Livingood@cable.comcast.com