idnits 2.17.1 draft-ietf-speermint-architecture-13.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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 250: '... MAY check for other enumservices. ...' RFC 2119 keyword, line 251: '... MAY consult a cache or alternate re...' RFC 2119 keyword, line 304: '...rce in the target SSP's domain and MAY...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 25, 2010) is 4930 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3546' is defined on line 550, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-speermint-voip-consolidated-usecases' is defined on line 582, 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 3546 (Obsoleted by RFC 4366) ** 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: 5 errors (**), 0 flaws (~~), 6 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: April 28, 2011 Comcast 6 October 25, 2010 8 SPEERMINT Peering Architecture 9 draft-ietf-speermint-architecture-13 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 April 28, 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 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Reference Architecture . . . . . . . . . . . . . . . . . . . . 3 55 3. Procedures of Inter-Domain SSP Session Establishment . . . . . 4 56 4. Relationships Between Functions/Elements . . . . . . . . . . . 5 57 5. Recommended SSP Procedures . . . . . . . . . . . . . . . . . . 5 58 5.1. Originating or Indirect SSP Procedures . . . . . . . . . . 5 59 5.1.1. The Look-Up Function (LUF) . . . . . . . . . . . . . . 6 60 5.1.1.1. Target Address Analysis . . . . . . . . . . . . . 6 61 5.1.1.2. ENUM Lookup . . . . . . . . . . . . . . . . . . . 6 62 5.1.2. Location Routing Function (LRF) . . . . . . . . . . . 7 63 5.1.2.1. DNS Resolution . . . . . . . . . . . . . . . . . . 7 64 5.1.2.2. Routing Table . . . . . . . . . . . . . . . . . . 7 65 5.1.2.3. LRF to LRF Routing . . . . . . . . . . . . . . . . 8 66 5.1.3. The Signaling Path Border Element (SBE) . . . . . . . 8 67 5.1.3.1. Establishing a Trusted Relationship . . . . . . . 8 68 5.1.3.2. IPSec . . . . . . . . . . . . . . . . . . . . . . 8 69 5.1.3.3. Co-Location . . . . . . . . . . . . . . . . . . . 8 70 5.1.3.4. Sending the SIP Request . . . . . . . . . . . . . 9 71 5.2. Target SSP Procedures . . . . . . . . . . . . . . . . . . 9 72 5.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 5.2.2. Receive SIP Requests . . . . . . . . . . . . . . . . . 9 74 5.3. Data Path Border Element (DBE) . . . . . . . . . . . . . . 9 75 6. Address Space Considerations . . . . . . . . . . . . . . . . . 10 76 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 13.1. Normative References . . . . . . . . . . . . . . . . . . . 12 84 13.2. Informative References . . . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 This document defines a reference peering architecture for the 90 Session Initiation Protocol (SIP)[RFC3261], it's functional 91 components and interfaces, in the context of session peering for 92 multimedia interconnects. In this process, we define the peering 93 reference architecture, its functional components, and peering 94 interface functions from the perspective of a SIP Service providers 95 [RFC5486] network. Thus, it also describes the components and the 96 steps necessary to establish a session between two SIP Service 97 Provider (SSP) peering domains. 99 This architecture enables the interconnection of two SSPs in layer 5 100 peering, as defined in the SIP-based session peering requirements 101 [I-D.ietf-speermint-requirements]. 103 Layer 3 peering is outside the scope of this document. Hence, the 104 figures in this document do not show routers so that the focus is on 105 layer 5 protocol aspects. 107 This document uses terminology defined in the Session Peering for 108 Multimedia Interconnect (SPEERMINT) Terminology document [RFC5486]. 110 2. Reference Architecture 112 The following figure depicts the architecture and logical functions 113 that form peering between two SSPs. 115 +=============++ ++==============+ 116 || || 117 +-----------+ +-----------+ 118 | SBE | +-----+ | SBE | 119 | +-----+ | SIP |Proxy| | +-----+ | 120 | | LUF |<-|------>|ENUM | | | LUF | | 121 | +-----+ | ENUM |TN DB| | +-----+ | 122 SIP | | +-----+ | | 123 ------>| +-----+ | DNS +-----+ | +-----+ | 124 | | LRF |<-|------>|FQDN | | | LRF | | 125 | +-----+ | |IP | | +-----+ | 126 | +-----+ | SIP +-----+ | +-----+ | 127 | | SF |<-|----------------|->| SF | | 128 | +-----+ | | +-----+ | 129 +-----------+ +-----------+ 130 || || 131 +-----------+ +-----------+ 132 RTP | DBE | RTP | DBE | 133 ------>| |--------------->| | 134 +-----------+ +-----------+ 135 || || 136 SSP1 Network || || SSP2 Network 137 +=============++ ++=============+ 139 Reference Architecture 141 Figure 1 143 For further details on the elements and functions described in this 144 figure, please refer to [RFC5486]. 146 3. Procedures of Inter-Domain SSP Session Establishment 148 This document assumes that in order for a session to be established 149 from a UA in the originating (or indirect) SSP's network to an UA in 150 the Target SSP's network the following steps are taken: 152 1. Determine the target or indirect SSP via the LUF. (Note: If the 153 target address represents an intra-SSP resource, the behavior is 154 out-of-scope with respect to this draft.) 156 2. Determine the address of the SF of the target SSP via the LRF. 158 3. Establish the session 159 4. Exchange the media, which could include voice, video, text, etc. 161 5. End the session (BYE) 163 The originating or indirect SSP would likely perform steps 1-4, and 164 the target SSP would likely perform steps 4-5. 166 In the case the target SSP changes, then steps 1-4 would be repeated. 167 This is reflected in Figure 1 that shows the target SSP with its own 168 peering functions. 170 4. Relationships Between Functions/Elements 172 o An SBE can contain a SF function. 174 o An SF can perform LUF and LRF functions. 176 o As an additional consideration, a Session Border Controller, can 177 contain an SF, SBE and DBE, and may perform the LUF and LRF 178 functions. 180 o The following functions can communicate as follows, depending upon 181 various real-world implementations: 183 * SF can communicate with LUF, LRF, SBE and SF 185 * LUF can communicator with SF and SBE 187 * LRF can communicate with SF and SBE 189 5. Recommended SSP Procedures 191 This section describes the functions in more detail and provides some 192 recommendations on the role they would play in a SIP call in a Layer 193 5 peering scenario. 195 Some of the information in the section is taken from 196 [I-D.ietf-speermint-requirements] and is put here for continuity 197 purposes. 199 5.1. Originating or Indirect SSP Procedures 201 This section describes the procedures of the originating or indirect 202 SSP. 204 5.1.1. The Look-Up Function (LUF) 206 The purpose of the LUF is to determine the SF of the target domain of 207 a given request and optionally to develop Session Establishment Data. 208 It is important to note that the LUF may utilize the public e164.arpa 209 ENUM root, as well as one or more private roots. When private roots 210 are used specialized routing rules may be implemented, and these 211 rules may vary depending upon whether an originating or indirect SSP 212 is querying the LUF. 214 5.1.1.1. Target Address Analysis 216 When the originating (or indirect) SSP receives a request to 217 communicate, it analyzes the target URI to determine whether the call 218 needs to be routed internal or external to its network. The analysis 219 method is internal to the SSP; thus, outside the scope of SPEERMINT. 221 If the target address does not represent a resource inside the 222 originating (or indirect) SSP's administrative domain or federation 223 of domains, then the originating (or indirect) SSP performs a Lookup 224 Function (LUF) to determine a target address, and then is resolves 225 the call routing data by using the Location routing Function (LRF). 227 For example, if the request to communicate is for an im: or pres: URI 228 type [RFC3861] [RFC3953], the originating (or indirect) SSP follows 229 the procedures in [RFC3861]. If the highest priority supported URI 230 scheme is sip: or sips: the originating (or indirect) SSP skips to 231 SIP DNS resolution in Section 5.1.3. Likewise, if the target address 232 is already a sip: or sips: URI in an external domain, the originating 233 (or indirect) SSP skips to SIP DNS resolution in Section 5.1.2.1. 234 This may be the case, to use one example, with 235 "sips:bob@biloxi.example.com". 237 If the target address corresponds to a specific E.164 address, the 238 SSP may need to perform some form of number plan mapping according to 239 local policy. For example, in the United States, a dial string 240 beginning "011 44" could be converted to "+44", or in the United 241 Kingdom "00 1" could be converted to "+1". Once the SSP has an E.164 242 address, it can use ENUM. 244 5.1.1.2. ENUM Lookup 246 If an external E.164 address is the target, the originating (or 247 indirect) SSP consults the public "User ENUM" rooted at e164.arpa, 248 according to the procedures described in [RFC3761]. The SSP must 249 query for the "E2U+sip" enumservice as described in [RFC3764], but 250 MAY check for other enumservices. The originating (or indirect) SSP 251 MAY consult a cache or alternate representation of the ENUM data 252 rather than actual DNS queries. Also, the SSP may skip actual DNS 253 queries if the originating (or indirect) SSP is sure that the target 254 address country code is not represented in e164.arpa. 256 If an im: or pres: URI is chosen for based on an "E2U+im" [RFC3861] 257 or "E2U+pres" [RFC3953] enumserver, the SSP follows the procedures 258 for resolving these URIs to URIs for specific protocols such a SIP or 259 XMPP as described in the previous section. 261 The NAPTR response to the ENUM lookup may be a SIP AoR (such as 262 "sips:bob@example.com") or SIP URI (such as 263 "sips:bob@sbe1.biloxi.example.com"). In the case of when a SIP URI 264 is returned, the originating (or indirect) SSP has sufficient routing 265 information to locate the target SSP. In the case of when a SIP AoR 266 is returned, the SF then uses the LRF to determine the URI for more 267 explicitly locating the target SSP. 269 5.1.2. Location Routing Function (LRF) 271 The LRF of an originating (or indirect) SSP analyzes target address 272 and target domain identified by the LUF, and discovers the next hop 273 signaling function (SF) in a peering relationship. The resource to 274 determine the SF of the target domain might be provided by a third- 275 party as in the assisted-peering case. The following sections define 276 mechanisms which may be used by the LRF. These are not in any 277 particular order and, importantly, not all of them may be used. 279 5.1.2.1. DNS Resolution 281 The originating (or indirect) SSP uses the procedures in Section 4 of 282 [RFC3263] to determine how to contact the receiving SSP. To 283 summarize the [RFC3263] procedure: unless these are explicitly 284 encoded in the target URI, a transport is chosen using NAPTR records, 285 a port is chosen using SRV records, and an address is chosen using A 286 or AAAA records. 288 When communicating with another SSP, entities compliant to this 289 document should select a TLS-protected transport for communication 290 from the originating (or indirect) SSP to the receiving SSP if 291 available. 293 5.1.2.2. Routing Table 295 If there are no End User ENUM records and the originating (or 296 indirect) SSP cannot discover the carrier-of-record or if the 297 originating (or indirect) SSP cannot reach the carrier-of-record via 298 SIP peering, the originating (or indirect) SSP may deliver the call 299 to the PSTN or reject it. Note that the originating (or indirect) 300 SSP may forward the call to another SSP for PSTN gateway termination 301 by prior arrangement using the routing table. 303 If so, the originating (or indirect) SSP rewrites the Request-URI to 304 address the gateway resource in the target SSP's domain and MAY 305 forward the request on to that SSP using the procedures described in 306 the remainder of these steps. 308 5.1.2.3. LRF to LRF Routing 310 Communications between the LRF of two interconnecting SSPs may use 311 DNS or statically provisioned IP Addresses for reachability. Other 312 inputs to determine the path may be code-based routing, method-based 313 routing, Time of day, least cost and/or source-based routing. 315 5.1.3. The Signaling Path Border Element (SBE) 317 The purpose of signaling function is to perform routing of SIP 318 messages as well as optionally implement security and policies on SIP 319 messages, and to assist in discovery/exchange of parameters to be 320 used by the Media Function (MF). The signaling function performs the 321 routing of SIP messages. The SBE may be a B2BUA or it may act as a 322 SIP proxy. Optionally, a SF may perform additional functions such as 323 Session Admission Control, SIP Denial of Service protection, SIP 324 Topology Hiding, SIP header normalization, SIP security, privacy, and 325 encryption. The SF of a SBE can also process SDP payloads for media 326 information such as media type, bandwidth, and type of codec; then, 327 communicate this information to the media function. 329 5.1.3.1. Establishing a Trusted Relationship 331 Depending on the security needs and trust relationships between SSPs, 332 different security mechanism can be used to establish SIP calls. 333 These are discussed in the following subsections. 335 5.1.3.2. IPSec 337 In certain deployments the use of IPSec between the signaling 338 functions of the originating and terminating domains can be used as a 339 security mechanism instead of TLS. 341 5.1.3.3. Co-Location 343 In this scenario the SFs are co-located in a physically secure 344 location and/or are members of a segregated network. In this case 345 messages between the originating and terminating SSPs would be sent 346 as clear text. 348 5.1.3.4. Sending the SIP Request 350 Once a trust relationship between the peers is established, the 351 originating (or indirect) SSP sends the request. 353 5.2. Target SSP Procedures 355 This section describes the Target SSP Procedures. 357 5.2.1. TLS 359 The section defines uses of TLS between two SSPs [RFC5246]. When the 360 receiving SSP receives a TLS client hello, it responds with its 361 certificate. The Target SSP certificate should be valid and rooted 362 in a well-known certificate authority. The procedures to 363 authenticate the SSP's originating domain are specified in [RFC5922]. 365 The SF of the Target SSP verifies that the Identity header is valid, 366 corresponds to the message, corresponds to the Identity-Info header, 367 and that the domain in the From header corresponds to one of the 368 domains in the TLS client certificate. 370 5.2.2. Receive SIP Requests 372 Once a trust relationship is established, the Target SSP is prepared 373 to receive incoming SIP requests. For new requests (dialog forming 374 or not) the receiving SSP verifies if the target (request-URI) is a 375 domain that for which it is responsible. For these requests, there 376 should be no remaining Route header field values. For in-dialog 377 requests, the receiving SSP can verify that it corresponds to the 378 top-most Route header field value. 380 The receiving SSP may reject incoming requests due to local policy. 381 When a request is rejected because the originating (or indirect) SSP 382 is not authorized to peer, the receiving SSP should respond with a 383 403 response with the reason phrase "Unsupported Peer". 385 5.3. Data Path Border Element (DBE) 387 The purpose of the DBE [RFC5486] is to perform media related 388 functions such as media transcoding and media security implementation 389 between two SSPs. 391 An example of this is to transform a voice payload from one codec 392 (e.g., G.711) to another (e.g., EvRC). Additionally, the MF may 393 perform media relaying, media security [RFC3711], privacy, and 394 encryption. 396 6. Address Space Considerations 398 Peering must occur in a common IP address space, which is defined by 399 the federation, which may be entirely on the public Internet, or some 400 private address space [RFC1918]. The origination or termination 401 networks may or may not entirely be in the same address space. If 402 they are not, then a network address translation (NAT) or similar may 403 be needed before the signaling or media is presented correctly to the 404 federation. The only requirement is that all associated entities 405 across the peering interface are reachable. 407 7. Acknowledgments 409 The working group would like to thank John Elwell, Otmar Lendl, Rohan 410 Mahy, Alexander Mayrhofer, Jim McEachern, Jean-Francois Mule, 411 Jonathan Rosenberg, and Dan Wing for their valuable contributions to 412 various versions of this document. 414 8. IANA Considerations 416 This memo includes no request to IANA. 418 9. Security Considerations 420 In all cases, cryptographic-based security should be maintained as an 421 optional requirement between peering providers conditioned on the 422 presence or absence of underlying physical security of SSP 423 connections, e.g. within the same secure physical building. 425 In order to maintain a consistent approach, unique and specialized 426 security requirements common for the majority of peering 427 relationships, should be standardized within the IETF. These 428 standardized methods may enable capabilities such as dynamic peering 429 relationships across publicly maintained interconnections. 431 Additional security considerations have been documented separately in 432 [I-D.ietf-speermint-voipthreats]. 434 10. Contributors 436 Mike Hammer 438 Cisco Systems 439 Herndon, VA - USA 441 Email: mhammer@cisco.com 443 -------------------------------------------------------------- 445 Hadriel Kaplan 447 Acme Packet 449 Burlington, MA - USA 451 Email: hkaplan@acmepacket.com 453 -------------------------------------------------------------- 455 Sohel Khan, Ph.D. 457 Comcast Cable 459 Philadelphia, PA - USA 461 Email: sohel_khan@cable.comcast.com 463 -------------------------------------------------------------- 465 Reinaldo Penno 467 Juniper Networks 469 Sunnyvale, CA - USA 471 Email: rpenno@juniper.net 473 -------------------------------------------------------------- 475 David Schwartz 477 XConnect Global Networks 479 Jerusalem - Israel 481 Email: dschwartz@xconnnect.net 483 -------------------------------------------------------------- 485 Rich Shockey 486 Shockey Consulting 488 USA 490 Email: Richard@shockey.us 492 -------------------------------------------------------------- 494 Adam Uzelac 496 Global Crossing 498 Rochester, NY - USA 500 Email: adam.uzelac@globalcrossing.com 502 11. Change Log 504 NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION PRIOR TO PUBLICATION. 506 o 13: Closed out all remaining tickets, resolved all editorial 507 notes. 509 o 12: Closed out several open issues. Properly XML-ized all 510 references. Updated contributors list. 512 o 11: Quick update to refresh the I-D since it expired, and cleaned 513 up some of the XML for references. A real revision is coming 514 soon. 516 12. Open Issues 518 NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION PRIOR TO PUBLICATION. 520 o NONE! 522 13. References 524 13.1. Normative References 526 [I-D.ietf-speermint-requirements] 527 Mule, J., "Requirements for SIP-based Session Peering", 528 draft-ietf-speermint-requirements-10 (work in progress), 529 October 2010. 531 [I-D.ietf-speermint-voipthreats] 532 Seedorf, J., Niccolini, S., Chen, E., and H. Scholz, 533 "SPEERMINT Security Threats and Suggested 534 Countermeasures", draft-ietf-speermint-voipthreats-05 535 (work in progress), September 2010. 537 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 538 E. Lear, "Address Allocation for Private Internets", 539 BCP 5, RFC 1918, February 1996. 541 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 542 A., Peterson, J., Sparks, R., Handley, M., and E. 543 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 544 June 2002. 546 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 547 Protocol (SIP): Locating SIP Servers", RFC 3263, 548 June 2002. 550 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 551 and T. Wright, "Transport Layer Security (TLS) 552 Extensions", RFC 3546, June 2003. 554 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 555 Resource Identifiers (URI) Dynamic Delegation Discovery 556 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 558 [RFC3764] Peterson, J., "enumservice registration for Session 559 Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, 560 April 2004. 562 [RFC3861] Peterson, J., "Address Resolution for Instant Messaging 563 and Presence", RFC 3861, August 2004. 565 [RFC3953] Peterson, J., "Telephone Number Mapping (ENUM) Service 566 Registration for Presence Services", RFC 3953, 567 January 2005. 569 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 570 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 572 [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia 573 Interconnect (SPEERMINT) Terminology", RFC 5486, 574 March 2009. 576 [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 577 Certificates in the Session Initiation Protocol (SIP)", 578 RFC 5922, June 2010. 580 13.2. Informative References 582 [I-D.ietf-speermint-voip-consolidated-usecases] 583 Uzelac, A. and Y. Lee, "VoIP SIP Peering Use Cases", 584 draft-ietf-speermint-voip-consolidated-usecases-18 (work 585 in progress), April 2010. 587 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 588 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 589 RFC 3711, March 2004. 591 Authors' Addresses 593 Daryl Malas (editor) 594 CableLabs 595 Louisville, CO 596 US 598 Email: d.malas@cablelabs.com 600 Jason Livingood (editor) 601 Comcast 602 Philadelphia, PA 603 US 605 Email: Jason_Livingood@cable.comcast.com