idnits 2.17.1 draft-ietf-drinks-usecases-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 27, 2009) is 5441 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DRINKS S. Channabasappa, Ed. 3 Internet-Draft CableLabs 4 Intended status: Informational May 27, 2009 5 Expires: November 28, 2009 7 DRINKS Use cases and Protocol Requirements 8 draft-ietf-drinks-usecases-requirements-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on November 28, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document captures the use cases and associated requirements for 47 interfaces to provision session establishment data into SIP Service 48 Provider components that aid with session routing. Specifically, the 49 current version of this document focuses on the provisioning of one 50 such element, termed the registry. 52 Table of Contents 54 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Use Cases and Requirements . . . . . . . . . . . . . . . . . . 10 57 3.1. Registry Provisioning . . . . . . . . . . . . . . . . . . 10 58 3.1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . 10 59 3.1.2. Requirements . . . . . . . . . . . . . . . . . . . . . 14 60 3.2. Distribution of data into local data repositories . . . . 17 61 3.3. Miscellaneous Use Cases . . . . . . . . . . . . . . . . . 17 62 3.3.1. Indirect Peering to Selected Destinations . . . . . . 17 63 3.3.2. TBD: RN Destinations . . . . . . . . . . . . . . . . . 17 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 66 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 21 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 21 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 72 1. Terminology 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 This document reuses terms from [RFC3261] (e.g., SIP) and [RFC5486] 79 (e.g., LUF, LRF). In addition, this document specifies the following 80 additional terms. 82 Registry: The authoritative source for provisioned session 83 establishment data (SED) and related information. 85 Local Data Repository: The data store component of an addressing 86 server that provides resolution responses. 88 Destination Group: A set of public identities that are grouped 89 together to facilitate session setup and routing. 91 Public Identity: A generic term that refers to a telephone number 92 (TN), an email address, or other identity as deemed appropriate, 93 such as a globally routable URI of a user address (e.g., 94 mailto:john.doe@example.net). 96 Routing Group: a grouping of SED records. 98 SED Record: A SED Record contains much of the session establishment 99 data or a 'redirect' to another registry where the session 100 establishment data can be discovered. SED Records types supported 101 are NAPTRs, CNAME, DNAME, and NS Records. 103 Data Recipient: SP or SSP that receives or consumes SED and related 104 information. 106 Data Recipient Group: A group of Data Recipients that receive the 107 same set (or subset) of SED and related information. 109 2. Overview 111 The SPEERMINT WG specifies Session Establishment Data, or SED, as the 112 data used to route a call to the next hop associated with the called 113 domain's ingress point. More specifically, the SED is the set of 114 parameters that the outgoing signalling path border elements (SBEs) 115 need to complete the call. See [RFC5486] for more details. 117 The specification of the format and protocols to configure SED is a 118 task taken up by the DRINKS WG. The use cases and requirements that 119 have been proposed in this regard are compiled in this document. 121 SED is typically created by the terminating SSP and consumed by the 122 originating SSP. For scalability reasons SED is rarely exchanged 123 directly between the intended parties. Instead, it is exchanged via 124 intermediate systems - termed Registries within this document. Such 125 registries receive SED via provisioning transactions from other SSPs, 126 and then distribute the received data into Local Data Repositories. 127 These local data repositories are used for call routing by outgoing 128 SBEs. This is depicted in Figure 1. 130 *-------------* 131 1. Provision SED | | 132 -----------------------> | Registry | 133 | | 134 *-------------* 135 / \ 136 / \ 137 / \ 138 / \ 139 / \ 140 / \ 141 / 2.Distribute \ 142 / SED \ 143 V V 144 +----------+ +----------+ 145 |Local Data| |Local Data| 146 |Repository| |Repository| 147 +----------+ +----------+ 149 Figure 1: General Diagram 151 In this version of the document, we primarily address the use cases 152 and requirements for provisioning registries. Future revisions may 153 include data distribution. The resulting provisioning protocol can 154 be used to provision data into a registry, or between registries. 155 This is depicted in Figure 2. 157 . . . . . . . 158 . . . . . . . registry . . . . . . . 159 . . . . . . . . . 160 . . . 161 . . provision . 162 +-----------+ . +-----------+ 163 | | provision +----------+ provision | | 164 | SSP 1 |------------>| Registry |<-----------| SSP 2 | 165 | | +----------+ | | 166 | +-----+ | /\ | +-----+ | 167 | | LDR | <-------------------- ------------------>| LDR | | 168 | +-----+ | distribute distribute | +-----+ | 169 | | | | 170 +-----------+ +-----------+ 171 . . 172 . . . . . . . . . . . . . . . . . . . . . . . . 173 (provision / distribute) 175 Where, LDR = Local Data Repository 177 Figure 2: Functional Overview 179 The following is a summary of the proposed responsibilities for 180 Registries and Local Data Repositories: 182 o Registries are the authoritative source for provisioned session 183 establishment data (SED) and related information. 185 o Local Data Repositories are the data store component of an 186 addressing server that provides resolution responses. 188 o Registries are responsible for distributing SED and related 189 information to the local data repositories. 191 In addition, this document proposes the following aggregation groups 192 with regards to SED (certain use cases also illustrate these groups): 194 o Aggregation of public Identifiers: The initial input "key" to a 195 SED lookup is a public identifier. Since many public identifiers 196 will share similar (or identical) destinations, and hence return 197 similar (or identical) SED, provisioning the same set of SED for 198 millions of public identifiers is inefficient, especially in cases 199 where the SED needs to be modified. Therefore, an aggregation 200 mechanism to "group" public identifiers is proposed. This 201 aggregation is called a "destination group". 203 o Aggregation of SSPs: It is expected that SSPs may want to expose 204 different sets of SED, depending on the receiving SSP. This 205 exposure may not always be unique, in which case an aggregation 206 makes it efficient. Such an aggregation is proposed, and termed 207 "Data Receipient Group". 209 o Aggregation of SED records: Finally, it is anticipated that a 210 complete set of routing data will consist of more than just one 211 SED record. To be able to create and use the same set of SED 212 records multiple times (without creating duplicates) an 213 aggregation mechanism at this level is proposed, and called 214 "routing group". 216 The above aggregations are illustrated in Figure 3. 218 +---------+ +--------------+ 219 | Data | |DATA RECIPIENT| 220 |Recipient|----------->| GROUP | 221 +---------+ +------.-------+ 222 ^ 223 | 224 | 225 +--------------+ +---------+ 226 | ROUTING | ------------->| SED | 227 | GROUP | | Record | 228 +--------------+ +---------+ 229 ^ ^ 230 | | 231 | | 232 +--------------+ | 233 ----->| DESTINATION |<----- | 234 | | GROUP | | | 235 | +--------------+ | | 236 | ^ | | 237 | | | | 238 | | | | 239 | | | | 240 +---------+ +---------+ +---------+ | 241 | RN | | TN | | Public |------- 242 | | | Range | |Identity | 243 +---------+ +---------+ +---------+ 245 Figure 3: Data Model Diagram 247 A description of the relationships follows: 249 - An RN is associated with one or more Destination Groups 251 - A TN Range object is associated with one or more Destination Group 253 - A Public Identity is associated with zero or more Destination 254 Group 256 - A Public Identity is associated with zero or more SED Records 257 - A Destination Group is associated with zero or more Routing 258 Groups. 260 - A Routing Group is associated with zero or more SED Records; 261 NAPTRs and other SED Record Types associated with Routes are not 262 User or TN specific. For example the user portion of a NAPTR 263 regex will be "\1". 265 - An Routing Group is associated with zero or more peering 266 organizations to control visibility/access privs to that Routing 267 Group and the Destination Groups they expose. 269 - A Data Recipient Group is associated with (contains) zero or more 270 Data Recipients to facilitate the allocation of access privileges 271 to Routing Groups. 273 3. Use Cases and Requirements 275 This section presents the use cases and associated requirements. 277 3.1. Registry Provisioning 279 Registry is the authoritative source for session establishment data 280 (SED). The registry needs to be provisioned with this data to 281 perform its function. This data includes: destination groups, 282 routing groups and data recipient groups. It can also include RNs 283 and TN Ranges. The following sub-sections illustrate the use cases 284 and the requirements, respectively. 286 3.1.1. Use Cases 288 USE CASE #1 Near-real-time provisioning: The registry is 289 provisioned with data that is not accompanied by an 290 effective date or time. In such cases, the registry 291 will validate the data and make it effective in near 292 real-time. 294 USE CASE #2 Non-real-time provisioning: The registry is provisioned 295 via an asynchronous provisioning process. For 296 instance, an SSP has commissioned a new registry and 297 wishes to download a very large number of telephone 298 numbers. Rather than stream individual entities, one 299 at a time, the SSP's back-office system prefers to 300 perform the operation as a set of one or more batches 301 (e.g., via an external data file), instead of the near- 302 real-time provisioning interface. 304 USE CASE #3 Deferred provisioning: The registry is provisioned with 305 data that is accompanied by an effective date and time. 306 In scenarios such as this, the registry will validate 307 the data and wait until the effective date and time to 308 make it effective. TBD: What happens if near-real time 309 data overrides data parked for later incorporation? 311 USE CASE #4 Intra-network SED: SSP wishes to provision their intra- 312 network Session Establishment Data (SED) such that it 313 enables current and future network services to identify 314 and route real-time sessions. For example, in the case 315 of VoIP calls it allows one SoftSwitch (calling) to 316 discover another (called). The SSP provisions IP 317 addressing information pertaining to each SoftSwitch, 318 which is provisioned to the registry but only 319 distributed to a specific local data repository. This 320 SED may differ from the SED that is distributed to 321 other local data repositories. 323 USE CASE #5 Destination Groups: An SSP may wish to control the flow 324 of traffic into their network (ingress) based on 325 groupings of Public Identities. Associating each group 326 of Public Identities with a specific set of ingress 327 SBEs or points-of-interconnect. The SSP, for example, 328 sub-divides the country into four regions: North-East, 329 South-East, Mid-West, and West-Coast. For each region 330 they establish points-of-interconnect with peers and 331 provision the associated SED hostnames or IP addresses 332 of the SBEs used for ingress traffic. Against each 333 region they provision the served Public Identities into 334 groups- termed Destination Groups - and associate those 335 destination groups with the appropriate points of 336 ingres. 338 USE CASE #6 Public Identity is taken out of service: A public 339 identity (or a TN range) is taken out of service 340 because it is no longer valid. The Registry receives a 341 delete operation and removes the public identity from 342 its database. This can also trigger delete operations 343 to keep the local data repositories up-to-date. 345 USE CASE #7 Assigning a set of public identities to a different 346 Destination Group: A set of public identities are 347 assigned a different Destination Group which 348 effectively changes their routing information. This 349 may be due to a network re-arrangement, a Signaling 350 path Border Element being split into two, or a need to 351 do maintenance, two carriers merging, or other 352 considerations. This scenario can also include an 353 effective date and time. 355 USE CASE #8 Moving an SSP from one Data Recipient Group to another: 356 An SSP would like to re-assign the Destination Groups 357 it shares with a peer and move the peer SSP from one 358 Data Recipient Group to another. This results in the 359 moved peer seeing a new and different set of routing 360 data. 362 USE CASE #9 Inter-network SED (Direct and Selective Peering): In 363 this case the SSP is the actual carrier-of-record; the 364 entity serving the end-user. The SSP wishes to 365 communicate different SED data to some of its peers 366 that wish to route to its destinations. So the SSP has 367 implemented direct points-of-interconnect with each 368 peer and therefore would like address-resolution to 369 result in different answers depending on which peer is 370 asking. 372 USE CASE #10 Separation of Responsibility: An SSP's operational 373 practices can seperate the responsibility of 374 provisioning the routing information, and the 375 associated identities, to different entities. For 376 example, a network engineer can establish a physical 377 interconnect with a peering SSP's network and provision 378 the associated domain name, host, and IP addressing 379 information. Separately, for each new service 380 subscription, the SSP's back office system provisions 381 the associated public identities. 383 USE CASE #11 Global TN Destinations: The SSP wishes to add or remove 384 one or multiple fully qualified TN destinations in a 385 single provisioning request. 387 USE CASE #12 TN Range Destinations: The SSP wishes to add or remove 388 one or multiple TN Range destinations in a single 389 provisioning request. TN Ranges support number ranges 390 that need not be 'blocks'. In other words the TN range 391 start can be any number and the TN range end can be any 392 number that is greater than the TN range start. 394 USE CASE #13 Non-TN Destinations: An SSP chooses to peer their 395 messaging service with another SSPs picture/video mail 396 service. Allowing a user to send and receive pictures 397 and/or video messages to a mobile user's handset, for 398 example. The important aspect of this use case is that 399 it goes beyond simply mapping TNs to IP addresses/ 400 hostnames that describe points-of-interconnect between 401 peering network SSP's. Rather, for each user the SSP 402 provisions the subscriber's email address (i.e. 403 jane.doe@example.com). This mapping allows the mobile 404 multimedia messaging service center (MMSC) to use the 405 subscriber email address as the lookup key and route 406 messages accordingly. 408 USE CASE #14 Tier 2 Name Server: An SSP maintains a Tier 2 name 409 server that contains the NAPTR records that constitute 410 the terminal step in the LUF. The SSP needs to 411 provision an registry to direct queries for the SSPs 412 numbers to the Tier 2. Usually queries to the registry 413 should return NS records, but, in cases where the Tier 414 2 uses a different domain suffix from that used in the 415 registry, CNAME and NS records may be employed instead. 417 USE CASE #15 Peering Offer/Acceptance: An SSP offers to allow 418 terminations from another SSP by adding that SSP to a 419 Data Recipient Group it controls. This causes 420 notification of the offered SSP. An SSP receiving a 421 peering offer should be able to accept or decline the 422 offer. If the offer is rejected the Registry should 423 not provision corresponding SED to the rejecting SSP. 424 It is expected that this capability will apply mainly 425 in the transit case where non-authoritative parties (in 426 the sense of not being the terminating SSP for an 427 identity) wish to offer the ability to reach the 428 identity and originating SSPs may wish to restrict the 429 routes that are provisioned to their local data 430 repositories. 432 USE CASE #16 Points of Egress: An SSP has a peering relationship 433 with a peer, and when sending messages to that peer's 434 point of interconnection, the originating SSP wishes to 435 use one or more points of egress. These points of 436 egress may vary for an given peer. This capability is 437 supported by allowing an originating SSP to provision 438 SED for identities terminating to other SSPs where the 439 originating SSP is itself the data recipient. The 440 provisioning SSP may make use of multiple data 441 recipient identities if it requires different sets of 442 egress points be used for calls originating from 443 different parts of its network. Routing from egress 444 points to ingress points of the terminating SSP may be 445 accomplished by static routing from the egress points 446 or by the egress points using data provisioned to the 447 Registry by the terminating SSP. 449 3.1.2. Requirements 451 The following data requirements apply: 453 DREQ1: The registry provisioning data model MUST support the 454 following entities: public identities, destination groups, 455 routing groups and data recipient groups. 457 DREQ2: The registry provisioning data model MUST support the 458 grouping and aggregation of public identities within 459 destination groups. 461 DREQ3: The registry provisioning data model SHOULD support the 462 grouping and aggregation of TN Ranges within destination 463 groups. 465 DREQ4: The registry provisioning data model SHOULD support the 466 grouping and aggregation of RNs within destination groups. 468 The following functional requirements apply: 470 FREQ1: The registry provisioning interface MUST support the 471 creation and deletion of: public identities, destination 472 groups, routing groups and data recipient groups. 474 FREQ2: The registry provisioning interface MUST support near-real- 475 time, non-real-time and deferred provisioning operations. 477 FREQ3: The registry provisioning interface MUST support the 478 following types of modifications: 480 - reassignment of one or more public identities from one 481 destination group to another; 483 - reassignment of one data recipient from one destination 484 group to another; 486 - association and disassociation of a "Default Routing 487 Group" with a Data Recipient; and, 489 - identification of a destination group as a "Primary 490 Provider" destination group or a "Transit" destination 491 group. 493 FREQ4: When an entity with a different client identifier than that 494 of the carrier of record for a public identity in a 495 destination group adds a new SSP to a destination recipient 496 group associated with that destination group, the registry 497 provisioning interface MUST: a) notify the new SSP of the 498 updated routing information (which constitutes a peering 499 offer) b) not provision the SED to the new SSP's LDR unless 500 the new SSP signals acceptance. 502 FREQ5: The registry provisioning interface MUST separate the 503 provisioning of the routing information from the associated 504 identities. 506 FREQ6: The registry provisioning protocol MUST define a discrete 507 set of response codes for each supported protocol operation. 508 Each response code MUST definitively indicate whether the 509 operation succeeded or failed. If the operation failed, the 510 response code MUST indicate the reason for the failure. 512 FREQ7: The registry provisioning interface MUST allow an SSP to 513 define multiple sub-identities that can be used in data 514 recipient groups 516 FREQ8: The registry provisioning interface MUST define the 517 concurrency rules, locking rules, and race conditions that 518 underlie the implementation of that protocol operation and 519 that result from the coexistence of protocol operations that 520 can operate on multiple objects in a single operation and 521 bulk file operations that may process for an extended period 522 of time. 524 FREQ9: The registry provisioning interface MUST support the ability 525 for a Data Recipient to optionally define a Routing Group as 526 their Default Routing Group, such that if the Data Recipient 527 performs a resolution request and the lookup key being 528 resolved is not found in the Destination Groups visible to 529 that Data Recipient then the SED Records associated with the 530 Default Routing Group shall be returned in the resolution 531 response. 533 FREQ10: The registry provisioning interface MUST support the ability 534 for the owner of a Routing Group to optionally define Source 535 Based Routing Criteria to be associated with their Routing 536 Group(s). The Source Based Routing Criteria will include 537 the ability to specify zero or more of the following in 538 association with a given Routing Group: Resolution Client IP 539 Address(es) or Domain Names, Calling Party URI(s). The 540 result will be that the resolution server would evaluate the 541 characteristics of the Source, compare them against Source 542 Based Routing Criteria associated with the Routing Groups 543 visible to that Data Recipient, and return any SED Records 544 associated with the matching Routing Groups. 546 FREQ11: The registry provisioning interface MUST track, via a client 547 identifier, the entity provisioning each data object (e.g. 548 Destination Group or Routing Group ). This client 549 identifier will identify the entity that is responsible for 550 that data object from a protocol interface perspective. 551 This client identifier SHOULD be tied to the session 552 authentication credentials that the client uses to connect 553 into to the registry. 555 The registry provisioning interface MUST incorporate a data 556 recipient identifier that identifies the organization 557 responsible for each data object from a business 558 perspective. This organization identifier may or may not 559 ultimately refer to the same organization that the client 560 Identifier refers to. The separation of the data recipient 561 identifier from the client identifier will allow for the 562 separation of the two entities, when the need arises. 564 Exactly one client identifier MUST be allowed to provision 565 objects under a given data recipient identifier. But a 566 client identifier MUST be allowed to provision objects under 567 multiple data recipient identifiers. 569 Objects provisioned under one "Protocol Client Identifier" 570 MUST NOT be alterable by a provisioning session established 571 by another "Protocol Client Identifier". 573 3.2. Distribution of data into local data repositories 575 This section targets use cases concerned with the distribution of SED 576 to local data repositories. This is considered out-of-scope for this 577 version of the document. 579 3.3. Miscellaneous Use Cases 581 This section contains additional use cases for consideration. 583 3.3.1. Indirect Peering to Selected Destinations 585 The SSP transit provider wishes to provide transit peering points for 586 a set of destinations. But that set of destinations does not align 587 with the destination groups that already exist. The SSP wishes to 588 establish its own destination groups for the destinations that it 589 provides transit to. 591 3.3.2. TBD: RN Destinations 593 The SSP does not wish to provision individual TNs, but instead, for 594 ease of management, wishes to provision Routing Numbers ((e.g., as in 595 some number portability implementations). Each RN effectively 596 represents a set of individual TNs, and that set of TNs is assumed to 597 change 'automatically' as TNs are ported in and ported out. Note 598 that this approach requires a query to resolve a TN to an RN prior to 599 using the provisioned data to route. 601 4. Security Considerations 603 Session establishment data allows for the routing of SIP sesions 604 within, and between, SIP Service Providers. Access to this data can 605 compromise the routing of sessions and expose a SIP Service Provider 606 to attacks such as service hijacking and denial of service. The data 607 can be compromised by vulnerable functional components and interfaces 608 identified within the use cases. 610 5. IANA Considerations 612 This document does not register any values in IANA registries. 614 6. Acknowledgments 616 This document is a result of various discussions held by the DRINKS 617 requirements design team, which is comprised of the following 618 individuals, in alphabetical order: Deborah A Guyton (Telcordia), 619 Gregory Schumacher (Sprint), Jean-Francois Mule (CableLabs), Kenneth 620 Cartwright (Verisign), Manjul Maharishi (Verisign), Penn Pfautz (AT&T 621 Corp), Ray Bellis (Nominet), the co-chairs (Richard Shockey, Nuestar; 622 and Alexander Mayrhofer, enum.at GmbH), and the editors of this 623 document. 625 7. References 627 7.1. Normative References 629 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 630 Requirement Levels", BCP 14, RFC 2119, March 1997. 632 7.2. Informative References 634 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 635 A., Peterson, J., Sparks, R., Handley, M., and E. 636 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 637 June 2002. 639 [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia 640 Interconnect (SPEERMINT) Terminology", RFC 5486, 641 March 2009. 643 Author's Address 645 Sumanth Channabasappa 646 CableLabs 647 858 Coal Creek Circle 648 Louisville, CO 80027 649 USA 651 Email: sumanth@cablelabs.com