idnits 2.17.1 draft-ietf-speermint-architecture-14.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 (November 8, 2010) is 4911 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-speermint-voip-consolidated-usecases' is defined on line 599, but no explicit reference was found in the text == 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-05 ** Obsolete normative reference: RFC 3761 (Obsoleted by RFC 6116, RFC 6117) ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) ** 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: 4 errors (**), 0 flaws (~~), 5 warnings (==), 2 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: May 12, 2011 Comcast 6 November 8, 2010 8 SPEERMINT Peering Architecture 9 draft-ietf-speermint-architecture-14 11 Abstract 13 This document defines a peering architecture for the Session 14 Initiation Protocol (SIP) [RFC3261], it's 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 May 12, 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 . . . . . 5 68 4. Relationships Between Functions/Elements . . . . . . . . . . . 6 69 5. Recommended SSP Procedures . . . . . . . . . . . . . . . . . . 6 70 5.1. Originating or Indirect SSP Procedures . . . . . . . . . . 6 71 5.1.1. The Look-Up Function (LUF) . . . . . . . . . . . . . . 7 72 5.1.1.1. Target Address Analysis . . . . . . . . . . . . . 7 73 5.1.1.2. ENUM Lookup . . . . . . . . . . . . . . . . . . . 7 74 5.1.2. Location Routing Function (LRF) . . . . . . . . . . . 8 75 5.1.2.1. DNS Resolution . . . . . . . . . . . . . . . . . . 8 76 5.1.2.2. Routing Table . . . . . . . . . . . . . . . . . . 8 77 5.1.2.3. LRF to LRF Routing . . . . . . . . . . . . . . . . 9 78 5.1.3. The Signaling Path Border Element (SBE) . . . . . . . 9 79 5.1.3.1. Establishing a Trusted Relationship . . . . . . . 9 80 5.1.3.2. IPSec . . . . . . . . . . . . . . . . . . . . . . 9 81 5.1.3.3. Co-Location . . . . . . . . . . . . . . . . . . . 9 82 5.1.3.4. Sending the SIP Request . . . . . . . . . . . . . 10 83 5.2. Target SSP Procedures . . . . . . . . . . . . . . . . . . 10 84 5.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 5.2.2. Receive SIP Requests . . . . . . . . . . . . . . . . . 10 86 5.3. Data Path Border Element (DBE) . . . . . . . . . . . . . . 10 87 6. Address Space Considerations . . . . . . . . . . . . . . . . . 11 88 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 91 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 92 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 13 93 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 13 94 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 95 13.1. Normative References . . . . . . . . . . . . . . . . . . . 14 96 13.2. Informative References . . . . . . . . . . . . . . . . . . 15 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 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 providers 107 [RFC5486] network. Thus, it also describes the components and the 108 steps necessary to establish a session between two SIP Service 109 Provider (SSP) peering 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]. 122 2. Reference Architecture 124 The following figure depicts the architecture and logical functions 125 that form peering between two SSPs. 127 +=============++ ++==============+ 128 || || 129 +-----------+ +-----------+ 130 | SBE | +-----+ | SBE | 131 | +-----+ | SIP |Proxy| | +-----+ | 132 | | LUF |<-|------>|ENUM | | | LUF | | 133 | +-----+ | ENUM |TN DB| | +-----+ | 134 SIP | | +-----+ | | 135 ------>| +-----+ | DNS +-----+ | +-----+ | 136 | | LRF |<-|------>|FQDN | | | LRF | | 137 | +-----+ | |IP | | +-----+ | 138 | +-----+ | SIP +-----+ | +-----+ | 139 | | SF |<-|----------------|->| SF | | 140 | +-----+ | | +-----+ | 141 +-----------+ +-----------+ 142 || || 143 +-----------+ +-----------+ 144 RTP | DBE | RTP | DBE | 145 ------>| |--------------->| | 146 +-----------+ +-----------+ 147 || || 148 SSP1 Network || || SSP2 Network 149 +=============++ ++=============+ 151 Reference Architecture 153 Figure 1 155 For further details on the elements and functions described in this 156 figure, please refer to [RFC5486]. 158 3. Procedures of Inter-Domain SSP Session Establishment 160 This document assumes that in order for a session to be established 161 from a UA in the originating (or indirect) SSP's network to an UA in 162 the Target SSP's network the following steps are taken: 164 1. Determine the target or indirect SSP via the LUF. (Note: If the 165 target address represents an intra-SSP resource, the behavior is 166 out-of-scope with respect to this draft.) 168 2. Determine the address of the SF of the target SSP via the LRF. 170 3. Establish the session 171 4. Exchange the media, which could include voice, video, text, etc. 173 5. End the session (BYE) 175 The originating or indirect SSP would likely perform steps 1-4, and 176 the target SSP would likely perform steps 4-5. 178 In the case the target SSP changes, then steps 1-4 would be repeated. 179 This is reflected in Figure 1 that shows the target SSP with its own 180 peering functions. 182 4. Relationships Between Functions/Elements 184 o An SBE can contain a SF function. 186 o An SF can perform LUF and LRF functions. 188 o As an additional consideration, a Session Border Controller, can 189 contain an SF, SBE and DBE, and may perform the LUF and LRF 190 functions. 192 o The following functions can communicate as follows, depending upon 193 various real-world implementations: 195 * SF can communicate with LUF, LRF, SBE and SF 197 * LUF can communicator with SF and SBE 199 * LRF can communicate with SF and SBE 201 5. Recommended SSP Procedures 203 This section describes the functions in more detail and provides some 204 recommendations on the role they would play in a SIP call in a Layer 205 5 peering scenario. 207 Some of the information in the section is taken from 208 [I-D.ietf-speermint-requirements] and is put here for continuity 209 purposes. 211 5.1. Originating or Indirect SSP Procedures 213 This section describes the procedures of the originating or indirect 214 SSP. 216 5.1.1. The Look-Up Function (LUF) 218 The purpose of the LUF is to determine the SF of the target domain of 219 a given request and optionally to develop Session Establishment Data. 220 It is important to note that the LUF may utilize the public e164.arpa 221 ENUM root, as well as one or more private roots. When private roots 222 are used specialized routing rules may be implemented, and these 223 rules may vary depending upon whether an originating or indirect SSP 224 is querying the LUF. 226 5.1.1.1. Target Address Analysis 228 When the originating (or indirect) SSP receives a request to 229 communicate, it analyzes the target URI to determine whether the call 230 needs to be routed internal or external to its network. The analysis 231 method is internal to the SSP; thus, outside the scope of SPEERMINT. 233 If the target address does not represent a resource inside the 234 originating (or indirect) SSP's administrative domain or federation 235 of domains, then the originating (or indirect) SSP performs a Lookup 236 Function (LUF) to determine a target address, and then is resolves 237 the call routing data by using the Location routing Function (LRF). 239 For example, if the request to communicate is for an im: or pres: URI 240 type [RFC3861] [RFC3953], the originating (or indirect) SSP follows 241 the procedures in [RFC3861]. If the highest priority supported URI 242 scheme is sip: or sips: the originating (or indirect) SSP skips to 243 SIP DNS resolution in Section 5.1.3. Likewise, if the target address 244 is already a sip: or sips: URI in an external domain, the originating 245 (or indirect) SSP skips to SIP DNS resolution in Section 5.1.2.1. 246 This may be the case, to use one example, with 247 "sips:bob@biloxi.example.com". 249 If the target address corresponds to a specific E.164 address, the 250 SSP may need to perform some form of number plan mapping according to 251 local policy. For example, in the United States, a dial string 252 beginning "011 44" could be converted to "+44", or in the United 253 Kingdom "00 1" could be converted to "+1". Once the SSP has an E.164 254 address, it can use ENUM. 256 5.1.1.2. ENUM Lookup 258 If an external E.164 address is the target, the originating (or 259 indirect) SSP consults the public "User ENUM" rooted at e164.arpa, 260 according to the procedures described in [RFC3761]. The SSP must 261 query for the "E2U+sip" enumservice as described in [RFC3764], but 262 may check for other enumservices. The originating (or indirect) SSP 263 may consult a cache or alternate representation of the ENUM data 264 rather than actual DNS queries. Also, the SSP may skip actual DNS 265 queries if the originating (or indirect) SSP is sure that the target 266 address country code is not represented in e164.arpa. 268 If an im: or pres: URI is chosen for based on an "E2U+im" [RFC3861] 269 or "E2U+pres" [RFC3953] enumserver, the SSP follows the procedures 270 for resolving these URIs to URIs for specific protocols such a SIP or 271 XMPP as described in the previous section. 273 The NAPTR response to the ENUM lookup may be a SIP AoR (such as 274 "sips:bob@example.com") or SIP URI (such as 275 "sips:bob@sbe1.biloxi.example.com"). In the case of when a SIP URI 276 is returned, the originating (or indirect) SSP has sufficient routing 277 information to locate the target SSP. In the case of when a SIP AoR 278 is returned, the SF then uses the LRF to determine the URI for more 279 explicitly locating the target SSP. 281 5.1.2. Location Routing Function (LRF) 283 The LRF of an originating (or indirect) SSP analyzes target address 284 and target domain identified by the LUF, and discovers the next hop 285 signaling function (SF) in a peering relationship. The resource to 286 determine the SF of the target domain might be provided by a third- 287 party as in the assisted-peering case. The following sections define 288 mechanisms which may be used by the LRF. These are not in any 289 particular order and, importantly, not all of them may be used. 291 5.1.2.1. DNS Resolution 293 The originating (or indirect) SSP uses the procedures in Section 4 of 294 [RFC3263] to determine how to contact the receiving SSP. To 295 summarize the [RFC3263] procedure: unless these are explicitly 296 encoded in the target URI, a transport is chosen using NAPTR records, 297 a port is chosen using SRV records, and an address is chosen using A 298 or AAAA records. 300 When communicating with another SSP, entities compliant to this 301 document should select a TLS-protected transport [RFC4366] for 302 communication from the originating (or indirect) SSP to the receiving 303 SSP if available. 305 5.1.2.2. Routing Table 307 If there are no End User ENUM records and the originating (or 308 indirect) SSP cannot discover the carrier-of-record or if the 309 originating (or indirect) SSP cannot reach the carrier-of-record via 310 SIP peering, the originating (or indirect) SSP may deliver the call 311 to the PSTN or reject it. Note that the originating (or indirect) 312 SSP may forward the call to another SSP for PSTN gateway termination 313 by prior arrangement using the routing table. 315 If so, the originating (or indirect) SSP rewrites the Request-URI to 316 address the gateway resource in the target SSP's domain and may 317 forward the request on to that SSP using the procedures described in 318 the remainder of these steps. 320 5.1.2.3. LRF to LRF Routing 322 Communications between the LRF of two interconnecting SSPs may use 323 DNS or statically provisioned IP Addresses for reachability. Other 324 inputs to determine the path may be code-based routing, method-based 325 routing, Time of day, least cost and/or source-based routing. 327 5.1.3. The Signaling Path Border Element (SBE) 329 The purpose of signaling function is to perform routing of SIP 330 messages as well as optionally implement security and policies on SIP 331 messages, and to assist in discovery/exchange of parameters to be 332 used by the Media Function (MF). The signaling function performs the 333 routing of SIP messages. The SBE may be a B2BUA or it may act as a 334 SIP proxy. Optionally, a SF may perform additional functions such as 335 Session Admission Control, SIP Denial of Service protection, SIP 336 Topology Hiding, SIP header normalization, SIP security, privacy, and 337 encryption. The SF of a SBE can also process SDP payloads for media 338 information such as media type, bandwidth, and type of codec; then, 339 communicate this information to the media function. 341 5.1.3.1. Establishing a Trusted Relationship 343 Depending on the security needs and trust relationships between SSPs, 344 different security mechanism can be used to establish SIP calls. 345 These are discussed in the following subsections. 347 5.1.3.2. IPSec 349 In certain deployments the use of IPSec between the signaling 350 functions of the originating and terminating domains can be used as a 351 security mechanism instead of TLS. 353 5.1.3.3. Co-Location 355 In this scenario the SFs are co-located in a physically secure 356 location and/or are members of a segregated network. In this case 357 messages between the originating and terminating SSPs would be sent 358 as clear text. 360 5.1.3.4. Sending the SIP Request 362 Once a trust relationship between the peers is established, the 363 originating (or indirect) SSP sends the request. 365 5.2. Target SSP Procedures 367 This section describes the Target SSP Procedures. 369 5.2.1. TLS 371 The section defines uses of TLS [RFC4366] between two SSPs [RFC5246]. 372 When the receiving SSP receives a TLS client hello, it responds with 373 its certificate. The Target SSP certificate should be valid and 374 rooted in a well-known certificate authority. The procedures to 375 authenticate the SSP's originating domain are specified in [RFC5922]. 377 The SF of the Target SSP verifies that the Identity header is valid, 378 corresponds to the message, corresponds to the Identity-Info header, 379 and that the domain in the From header corresponds to one of the 380 domains in the TLS client certificate. 382 5.2.2. Receive SIP Requests 384 Once a trust relationship is established, the Target SSP is prepared 385 to receive incoming SIP requests. For new requests (dialog forming 386 or not) the receiving SSP verifies if the target (request-URI) is a 387 domain that for which it is responsible. For these requests, there 388 should be no remaining Route header field values. For in-dialog 389 requests, the receiving SSP can verify that it corresponds to the 390 top-most Route header field value. 392 The receiving SSP may reject incoming requests due to local policy. 393 When a request is rejected because the originating (or indirect) SSP 394 is not authorized to peer, the receiving SSP should respond with a 395 403 response with the reason phrase "Unsupported Peer". 397 5.3. Data Path Border Element (DBE) 399 The purpose of the DBE [RFC5486] is to perform media related 400 functions such as media transcoding and media security implementation 401 between two SSPs. 403 An example of this is to transform a voice payload from one codec 404 (e.g., G.711) to another (e.g., EvRC). Additionally, the MF may 405 perform media relaying, media security [RFC3711], privacy, and 406 encryption. 408 6. Address Space Considerations 410 Peering must occur in a common IP address space, which is defined by 411 the federation, which may be entirely on the public Internet, or some 412 private address space [RFC1918]. The origination or termination 413 networks may or may not entirely be in the same address space. If 414 they are not, then a network address translation (NAT) or similar may 415 be needed before the signaling or media is presented correctly to the 416 federation. The only requirement is that all associated entities 417 across the peering interface are reachable. 419 7. Acknowledgments 421 The working group would like to thank John Elwell, Otmar Lendl, Rohan 422 Mahy, Alexander Mayrhofer, Jim McEachern, Jean-Francois Mule, 423 Jonathan Rosenberg, and Dan Wing for their valuable contributions to 424 various versions of this document. 426 8. IANA Considerations 428 This memo includes no request to IANA. 430 9. Security Considerations 432 In all cases, cryptographic-based security should be maintained as an 433 optional requirement between peering providers conditioned on the 434 presence or absence of underlying physical security of SSP 435 connections, e.g. within the same secure physical building. 437 In order to maintain a consistent approach, unique and specialized 438 security requirements common for the majority of peering 439 relationships, should be standardized within the IETF. These 440 standardized methods may enable capabilities such as dynamic peering 441 relationships across publicly maintained interconnections. 443 Additional security considerations have been documented separately in 444 [I-D.ietf-speermint-voipthreats]. 446 10. Contributors 448 Mike Hammer 450 Cisco Systems 451 Herndon, VA - USA 453 Email: mhammer@cisco.com 455 -------------------------------------------------------------- 457 Hadriel Kaplan 459 Acme Packet 461 Burlington, MA - USA 463 Email: hkaplan@acmepacket.com 465 -------------------------------------------------------------- 467 Sohel Khan, Ph.D. 469 Comcast Cable 471 Philadelphia, PA - USA 473 Email: sohel_khan@cable.comcast.com 475 -------------------------------------------------------------- 477 Reinaldo Penno 479 Juniper Networks 481 Sunnyvale, CA - USA 483 Email: rpenno@juniper.net 485 -------------------------------------------------------------- 487 David Schwartz 489 XConnect Global Networks 491 Jerusalem - Israel 493 Email: dschwartz@xconnnect.net 495 -------------------------------------------------------------- 497 Rich Shockey 498 Shockey Consulting 500 USA 502 Email: Richard@shockey.us 504 -------------------------------------------------------------- 506 Adam Uzelac 508 Global Crossing 510 Rochester, NY - USA 512 Email: adam.uzelac@globalcrossing.com 514 11. Change Log 516 NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION PRIOR TO PUBLICATION. 518 o 14: WGLC ended. Ran final nits check prior to sending proto to 519 the AD and sending the doc to the IESG. Found a few very minor 520 nits, such as capitalization and replacement of an obsoleted RFC, 521 which were corrected per nits tool recommendation. The -14 now 522 moves to the AD and the IESG. 524 o 13: Closed out all remaining tickets, resolved all editorial 525 notes. 527 o 12: Closed out several open issues. Properly XML-ized all 528 references. Updated contributors list. 530 o 11: Quick update to refresh the I-D since it expired, and cleaned 531 up some of the XML for references. A real revision is coming 532 soon. 534 12. Open Issues 536 NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION PRIOR TO PUBLICATION. 538 o NONE! 540 13. References 541 13.1. Normative References 543 [I-D.ietf-speermint-requirements] 544 Mule, J., "Requirements for SIP-based Session Peering", 545 draft-ietf-speermint-requirements-10 (work in progress), 546 October 2010. 548 [I-D.ietf-speermint-voipthreats] 549 Seedorf, J., Niccolini, S., Chen, E., and H. Scholz, 550 "SPEERMINT Security Threats and Suggested 551 Countermeasures", draft-ietf-speermint-voipthreats-05 552 (work in progress), September 2010. 554 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 555 E. Lear, "Address Allocation for Private Internets", 556 BCP 5, RFC 1918, February 1996. 558 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 559 A., Peterson, J., Sparks, R., Handley, M., and E. 560 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 561 June 2002. 563 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 564 Protocol (SIP): Locating SIP Servers", RFC 3263, 565 June 2002. 567 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 568 Resource Identifiers (URI) Dynamic Delegation Discovery 569 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 571 [RFC3764] Peterson, J., "enumservice registration for Session 572 Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, 573 April 2004. 575 [RFC3861] Peterson, J., "Address Resolution for Instant Messaging 576 and Presence", RFC 3861, August 2004. 578 [RFC3953] Peterson, J., "Telephone Number Mapping (ENUM) Service 579 Registration for Presence Services", RFC 3953, 580 January 2005. 582 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 583 and T. Wright, "Transport Layer Security (TLS) 584 Extensions", RFC 4366, April 2006. 586 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 587 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 589 [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia 590 Interconnect (SPEERMINT) Terminology", RFC 5486, 591 March 2009. 593 [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 594 Certificates in the Session Initiation Protocol (SIP)", 595 RFC 5922, June 2010. 597 13.2. Informative References 599 [I-D.ietf-speermint-voip-consolidated-usecases] 600 Uzelac, A. and Y. Lee, "VoIP SIP Peering Use Cases", 601 draft-ietf-speermint-voip-consolidated-usecases-18 (work 602 in progress), April 2010. 604 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 605 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 606 RFC 3711, March 2004. 608 Authors' Addresses 610 Daryl Malas (editor) 611 CableLabs 612 Louisville, CO 613 US 615 Email: d.malas@cablelabs.com 617 Jason Livingood (editor) 618 Comcast 619 Philadelphia, PA 620 US 622 Email: Jason_Livingood@cable.comcast.com