idnits 2.17.1 draft-rs-trip-gw-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 252: '... it SHOULD NOT be propagated unless ...' RFC 2119 keyword, line 274: '... Routes MAY be originated containing...' RFC 2119 keyword, line 276: '... updates MAY be sent as it changes. ...' RFC 2119 keyword, line 279: '...hold. It is also RECOMMENDED that the ...' RFC 2119 keyword, line 286: '...pacity attribute MAY be used for route...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (July 14, 2000) is 8688 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 572 looks like a reference -- Missing reference section? '2' on line 576 looks like a reference -- Missing reference section? '3' on line 580 looks like a reference -- Missing reference section? '4' on line 584 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force IPTEL WG 3 Internet Draft J.Rosenberg,H.Salama 4 draft-rs-trip-gw-01.txt dynamicsoft, Cisco 5 July 14, 2000 6 Expires: January 2001 8 Usage of TRIP in Gateways for Exporting Phone Routes 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 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 Abstract 33 This document describes a new application of the Telephony Routing 34 over IP (TRIP) protocol. TRIP was engineered as a tool for inter- 35 domain exchange of telephone routing information. However, it can 36 also be used as a means for gateways and soft switches to export 37 their routing information to a Location Server (LS), which may be 38 co-resident with a proxy or gatekeeper. This LS can then manage those 39 gateway resources. We discuss the motivations for this application, 40 the reasons why other mechanims, such as the SIP REGISTER method, are 41 not appropriate, and then show how a minimal subset of TRIP is needed 42 for this application. 44 1 Introduction 46 In typical VoIP deployments, a service provider runs a network 47 composed of numerous gateways, softswitches, and proxy servers. 48 Generally, gateways (both composed and decomposed) are distributed 49 geograpically throughout the network. When a gateway terminates a 50 call to a number, cost to the service provider is incurred. This cost 51 is partly dependent on the cost of making a call over the PSTN from 52 the gateway to the destination number. By placing gateways in 53 numerous locations over the globe, the service provider can be sure 54 it can terminate calls to the PSTN with minimal cost. 56 When calls arrive at the network (either from customers of the 57 provider, or from peer providers desiring termination service), they 58 are first sent to a proxy which acts as a routing engine. Based on 59 the knowledge of available gateways, their capacity (in terms of 60 circuit and DSP resources) and other attributes, and the telephone 61 numbers each gateway can terminate calls to, the proxy forwards the 62 call to the appropriate gateway. In essence, the LS/proxy is 63 responsible for managing the real-time resources made available by a 64 set of gateways. 66 This configuration is depicted graphically in Figure 1. 68 There are several problems that must be solved in order to enable 69 this scenario: 71 o Often, the routing tables in the routing proxies are manually 72 entered. This makes configuration more complex, particularly 73 for large networks with hundreds or even thousands of 74 gateways. In the ideal scenario, each gateway is configured 75 with the numbers it can terminate calls to, and with the 76 address of the routing proxies. The gateways then push their 77 routing information to the proxy. No standard mechanism has 78 been specified to do this. 80 o It is important for the routing proxy to be aware of failures 81 of gateways. This way, an alternate gateway can be selected 82 for new incoming calls. This requires some kind of keepalive 83 between the gateways and the routing proxy. No standard 84 mechanism yet exists for this keepalive. 86 o The routing proxy will need to route call setup requests to 87 the gateways based on dynamic attributes of those gateways. In 88 particular, the available capacity, measured in terms of both 89 circuit resources and coding resources, is used to properly 90 route calls. The proxy can, for example, perform load 91 balancing by forwarding call setups to the most lightly loaded 92 gateway among a set. No standard mechanism has been specified 93 to do this. 95 +---------+ 96 | | 97 | GW | 98 > +---------+ 99 // 100 // 101 // +---------+ 102 // | | 103 // | GW | 104 // +---------+ 105 // 106 +----------+ // TO PSTN 107 | | / +---------+ 108 | Routing | -------> | | -----> 109 -------->| Proxy | ------- | GW | 110 | | -- +---------+ 111 | | -- 112 +----------+ -- 113 --- +---------+ 114 -- | | 115 -- | GW | 116 -- +---------+ 117 --> 119 +---------+ 120 | | 121 | GW | 122 +---------+ 124 Figure 1: Gateway and LS Configuration 126 This document discusses how TRIP [1] can be used to solve these two 127 problems. The first section reviews other mechanisms for 128 accomplishing this - namely the SIP [2] REGISTER method, and 129 discusses why TRIP is a much better solution. We assume the reader is 130 familiar with TRIP. An overview of its architecture can be found in 131 [3]. 133 2 Why not SIP REGISTER? 135 The SIP REGISTER method has frequently been proposed as a solution 136 for these two problems. This is due, in part, to the similarity of 137 the REGISTER method to the H.323 [4] RAS messages. In H.323, RAS 138 messages are used to allow gateways to register telephone number 139 prefixes with a gatekeeper. Many assume that SIP REGISTER should 140 therefore play a similar role. 142 Certainly, the REGISTER mechanism is close to this functionality. 143 REGISTER allows clients to send address bindings (including for 144 telephone numbers) to a proxy. Registrations are also periodically 145 refreshed, allowing a proxy to determine if the address binding 146 becomes stale, perhaps due to a crash or device failure. The refresh 147 timer (present in the Expires header) can even be negotiated by the 148 proxy. 150 However, the SIP REGISTER mechanism is different from the desired 151 mechanisms for gateways in many respects: 153 o The REGISTER mechanism is used to bind a single incoming URI 154 to one or more outgoing URIs. In the case of a telephony 155 gateway, the binding is between a set of telephone prefixes to 156 the address of a gateway. This is a significantly different 157 binding, and cannot be represented with the syntax or 158 semantics of a SIP REGISTER request. 160 o The keepalive mechanism in REGISTER refreshes the *binding*, 161 not the status of the UA performing the registration. The 162 bindings must be sent each time to keep them alive. In the 163 case of a gateway, the keepalive is for the state of the 164 gateway, not for the routes the gateway terminates. The 165 semantics of REGISTER would need to be completely changed in 166 order to support this different semantic. 168 o There are properties associated with gateway routes that are 169 not associated with URIs. For example, a route may have 170 information like capacity (how many simultaneous calls can be 171 terminated), which does not make much sense for a property of 172 a URI. 174 o Because gateways can handle so many calls, it is important for 175 liveness information to be conveyed very frequently, on the 176 order of seconds. SIP registrations are not meant to be sent 177 that frequently; they can be fairly large messages 178 (particularly if they need to contain the routes when 179 refreshed), resulting in uneeded overheads. 181 For these reasons, we do not believe the SIP REGISTER request is the 182 right tool for gateway route propagation and gateway keepalives. 184 3 Why TRIP? 186 TRIP was engineered as a tool for interdomain route exchange. It is 187 not a simple protocol, and at first glance, does not seem appropriate 188 for application in a gateway. 190 However, TRIP provides exactly the features needed to solve the 191 problem at hand. TRIP allows one entity (in this case, a gateway) to 192 convey to another (in this case, a proxy) a set of telephone routes 193 which terminate through it. These routes are represented by telephone 194 number prefixes. In TRIP, the routing tables are exchanged once. Only 195 when they change are updates sent. This is exactly the capability 196 needed for a gateway to send its routing information to a proxy. 198 TRIP also supports a keepalive between peers. This keepalive is a 199 short message, sent fairly frequently. It does not contain routing 200 information. The period of the keepalive is negotiated once at 201 startup time. If one of the entities crashes, the other flushes all 202 routes received from it. This, too, is exactly the mechanism needed 203 for keepalives in a gateway. 205 TRIP can contain attributes describing a route. New attributes can 206 easily be added. The available capacity of a route is needed by the 207 proxies to properly load balance and route to a set of gateways. This 208 capacity can be expressed as an attribute. 210 Another advantage of using TRIP here is that it makes the 211 redistribution of local gateway reachability information into inter- 212 domain TRIP straightforward, because it's the same protocol. 214 While it is true that TRIP is complex, almost all of this complexity 215 is related to the processing of routes *received* from other peers. 216 An element, such as a gateway, which only *sends* routes to a peer 217 (the proxy), does not need to implement any of those functions. In 218 particular, any processing related to aggregation, TRIB updates, 219 route propagation and advertisement, handling of transitivity and 220 unknown routes, or the decision process need not be implemented. The 221 resulting set of functions are very small. They are composed of only: 223 o The initial OPEN phase, exchange of keepalive timers, and the 224 process of bringing up the state machine. 226 o Sending of an UPDATE containing the routes and parameters of 227 the gateways. 229 o Sending of a periodic keepalive. 231 Its worth noting that these functions are not substantially more 232 complex than sending a periodic REGISTER. 234 The rest of this document is organized as follows. Section 4 235 discusses a new attribute, circuit capacity, and section 5 discusses 236 another new attribute, DSP capacity. These new attributes contain 237 dynamic capacity of gateways that can be propagated to the LS 238 managing those gateways. Section 6 describes the processing rules 239 needed for a gateway, and section 7 discusses some of the processing 240 needed in an LS. 242 4 CircuitCapacity Attribute 244 Mandatory: False. 245 Required Flags: optional, non-transitive 246 Potential Flags: None. 247 TRIP Type Code: TBD. 249 The circuit capacity attribute is used only between a gateway and its 250 peer LS responsible for managing that gateway. It is for this reason 251 that this attribute is non-transitive. If it is received in a route, 252 it SHOULD NOT be propagated unless the LS is sure that it is 253 relatively static. 255 The circuit capacity identifies the number of PSTN circuits that are 256 currently available on a route to terminate calls. The number of 257 additional calls sent to that gateway for that route can not exceed 258 the circuit capacity. If it does, the signaling protocol will likely 259 generate errors, and calls will be rejected. 261 Circuit capacity is measured in integral number of calls. It changes 262 very dynamically. 264 4.1 CircuitCapacity Syntax 266 The CircuitCapacity attribute is a 4-octet unsigned numbeic value. It 267 represents the number of circuits remaining for terminating calls to 268 this route. This attribute represents a potentially achievable lower 269 bound on the number of calls which can additionally forwarded on this 270 route. 272 4.2 Route Origination and CircuitCapacity 274 Routes MAY be originated containing the CircuitCapacity attribute. 275 Since this attribute is highly dynamic, changing with every call, 276 updates MAY be sent as it changes. However, it is RECOMMENDED that a 277 gateway originating routes with this attribute use thresholds, and 278 that routes are re-originated only when the attribute moves above or 279 below a treshold. It is also RECOMMENDED that the thresholds in each 280 direction (going above a threshold and going below a threshold) be 281 different, thus achieving a form of hysterisis. Both of these 282 measures help reduce the messaging load from route origination. 284 4.3 Route Selection and CircuitCapacity 286 The CircuitCapacity attribute MAY be used for route selection. Since 287 one of its primary applications is load balancing, an LS will wish to 288 choose a potentially different route (amonst a set of routes for the 289 same prefix) on a call by call basis. This can be modeled as re- 290 running the decision process on the arrival of each call. The 291 aggregation and dissemination rules for routes with this attribute 292 ensure that re-running this selection process never results in 293 propagation of a new route to other peers. 295 4.4 Aggregation and CircuitCapacity 297 An LS MUST aggregate routes to the same prefix which contain a 298 CircuitCapacity attribute. This guarantees that if the decision 299 process is rerun, the route that is disseminated to peers is 300 unchanged. 302 4.5 Route Dissemination and CircuitCapacity 304 Routes SHOULD NOT be disseminated with the CircuitCapacity attribute. 305 The attribute is meant to reflect capacity at the originating gateway 306 only. Its highly dynamic nature makes it inappropriate to disseminate 307 in most cases. 309 5 DSPCapacity attribute 311 Mandatory: False. 312 Required Flags: optional, non-transitive 313 Potential Flags: None. 314 TRIP Type Code: TBD. 316 The DSPCapacity attribute is used only between a gateway and its peer 317 LS responsible for managing that gateway. It is for this reason that 318 this attribute is non-transitive. If it is received in a route, it 319 SHOULD NOT be propagated unless the LS is sure it is relatively 320 static in value. 322 The DSPcapacity identifies the amount of DSP resources, in MIPS, that 323 are currently available on a route to terminate calls. The metric 324 should be considered as only an approximate. The MIPS are computed 325 based on a specific processor (TBD); other processors will need to 326 perform a conversion to obtain this normalized parameter. It is 327 assumed that the LS is aware of the DSP resource requirements for 328 each call, based on the set of codecs indicated in the messages 329 routed by the LS/proxy. 331 There is lots of handwaving here. Can we usefully define 332 this metric? How to determine how much DSP resources are 333 really required to terminate a call? Also, the codec used 334 may not be known at the time the message is to be routed. 335 This can happen with both SIP (when the SDP in the INVITE 336 is empty), and H.323. How to handle this? 338 DSP capacity is measured in integral number of MIPS. It changes very 339 dynamically. 341 5.1 DSPCapacity Syntax 343 The DSPCapacity attribute is a 4-octet unsigned numbeic value. It 344 represents the number of MIPS remaining for terminating calls to this 345 route. 347 5.2 Route Origination and DSPCapacity 349 Routes MAY be originated containing the DSPCapacity attribute. Since 350 this attribute is highly dynamic, changing with every call, updates 351 MAY be sent as it changes. However, it is RECOMMENDED that a gateway 352 originating routes with this attribute use thresholds, and that 353 routes are re-originated only when the attribute moves above or below 354 a treshold. It is also RECOMMENDED that the tresholds in each 355 direction (going above a threshold and going below a threshold) be 356 different, thus achieving a form of hysterisis. Both of these 357 measures help reduce the messaging load from route origination. 359 5.3 Route Selection and DSPCapacity 361 The DSPCapacity attribute MAY be used for route selection. Since one 362 of its primary applications is load balancing, an LS will wish to 363 choose a potentially different route (amonst a set of routes for the 364 same prefix) on a call by call basis. This can be modeled as re- 365 running the decision process on the arrival of each call. The 366 aggregation and dissemination rules for routes with this attribute 367 ensure that re-running this selection process never results in 368 propagation of a new route to other peers. 370 5.4 Aggregation and DSPCapacity 372 An LS MUST aggregate routes to the same prefix which contain a 373 DSPCapacity attribute. This guarantees that if the decision process 374 is rerun, the route that is disseminated to peers is unchanged. 376 5.5 Route Dissemination and DSPCapacity 378 Routes SHOULD NOT be disseminated with the DSPCapacity attribute. The 379 attribute is meant to reflect capacity at the originating gateway 380 only. Its highly dynamic nature makes it inappropriate to 381 disseminate. 383 6 Gateway Operation 385 The protocol a gateway uses to advertise its E.164 reachability to 386 the its domain's Location Server(s) (LS)is TRIP. The gateway operates 387 in TRIP Send Only mode since it is only interested in advertising its 388 reachability, but is not interested in learning about the 389 reachability of other gateways and other domains. Also, the gateway 390 will not create its own call routing database. Therefore, the gateway 391 does not need a complete implementation of TRIP. A lightweight 392 version of the protocol is sufficient. In this section we describe 393 the operation of TRIP on a gateway. We refer to the protocol 394 operating in this context as TRIP for Gateways, or TRIP-GW. 396 TRIP-GW is a stripped down version of TRIP, but still completely 397 interoperable with normal TRIP speakers. It is an implementation 398 profile, not an extension or incompatible reduction. 400 The reader is assumed to be familiar with TRIP. In our discussion we 401 will skip most of the details common to both versions. 403 6.1 Session Establishment 405 When opening a peering session with a TRIP LS, an TRIP-GW gateway 406 follows exactly the same procedures as any other TRIP speaker. The 407 TRIP-GW gateway sends an OPEN message which includes a Send Receive 408 Capability in the Optional Parameters. The Send Receive Capability is 409 set by the gateway to Send Only. When the TRIP LS receives the 410 gateway's OPEN message, it set its local policy such that no UPDATE 411 messages are sent to the TRIP-GW gateway. The remainder of the peer 412 session establishment is identical to TRIP. 414 6.2 UPDATE Messages 416 Once the peer session has been established, the gateway sends UPDATE 417 messages to the TRIP LS with the gateway's entire E.164 reachability 418 and its ITAD topology. 420 If the gateway's E.164 reachability or its ITAD topology changes at 421 any point in time, the gateway MUST generate UPDATE message(s) with 422 the change. The frequency of successive UPDATE messages MUST follow 423 the same rules specified for TRIP [1]. The TRIP-GW gateway MUST at 424 least support all mandatory TRIP attributes. 426 If the gateway receives an UPDATE message from the TRIP LS, it MUST 427 silently discard it as specified in [1]. No further action should be 428 taken. 430 6.3 KEEPALIVE Messages 432 KEEPALIVE messages are periodically exchanged over the peering 433 session between the TRIP-GW gateway and the TRIP LS as specified in 434 Section 5.4 of [1]. 436 6.4 Error Handling and NOTIFICATION Messages 438 The same procedures used with TRIP, are used with TRIP-GW for error 439 handling and generating NOTIFICATION messages. The only difference is 440 that an TRIP-GW gateway will never generate a NOTIFICATION message in 441 response to an UPDATE message, irrespective of the contents of the 442 UPDATE message. Any UPDATE message is silently discarded. 444 6.5 TRIP-GW Finite State Machine 446 When the TRIP-GW finite state machine is in the Established state and 447 an UPDATE message is received, the UPDATE message is silently 448 discarded and the TRIP-GW gateway remains in the Established state. 449 Other than that the TRIP finite state machine and the TRIP-GW finite 450 state machine are identical. 452 6.6 Call Routing Databases 454 A TRIP-GW gateway may maintain simultaneous sessions with more than 455 one TRIP LSs. A TRIP-GW gateway maintains one call routing database 456 per peer TRIP LS. These databases are equivalent to TRIP's Adj- 457 TRIBs-Out, and hence we will call them Adj-TRIB-GWs-Out. An Adj- 458 TRIB-GW-Out contains the gateway's E.164 reachability information 459 advertised to its peer TRIP LS. How an Adj-TRIB-GW-Out database gets 460 populated is outside the scope of this draft (possibly by manual 461 configuration). 463 The TRIP-GW gateway does not have databases equivalent to TRIP's 464 Adj-TRIBs-In and Loc-TRIB, because the TRIP-GW gateway does not learn 465 routes from its peer TRIP LSs, and hence it does not run call route 466 selection. 468 6.7 Route Selection and Aggregation 470 TRIP's route selection and aggregation operations SHOULD NOT be 471 implemented by TRIP-GW gateways. 473 7 LS Behavior 475 TRIP completely specifies the behavior of the LS as a TRIP speaker. 476 However, the primary question is: is an LS connected to a gateway an 477 internal or external peer of the gateway? 479 The most obvious choice, internal peer, is not the best choice. If an 480 LS has ten peer GWs, all of them advertising reachability to 1408*, 481 it will flood all ten routes to all other LSs in the same ITAD. This 482 won't scale, because each LS in the ITAD will have to create a 483 separate Adj-TRIB-In for each GW in that ITAD. In addition, it 484 doesn't allow a SIP Proxy server or an H.323 GK to load balance among 485 the GWs of its zone/subdomain. 487 A similar problem exists when an LS is an external peer to the 488 gateways, and has direct peering relationships with one or more 489 internal peers. However, an ingress LS to an ITAD does not perform 490 aggregation. Only the egress aggregates routes. 492 Therefore, it is RECOMMENDED that the appropriate architecture is 493 that the LS actually runs two instances of TRIP; one with an external 494 peering relationship to the gateways, and the other with an internal 495 peering relationship with one or more LS's within the ITAD. The 496 interface between these instances is a local matter; routes are 497 exported from one and imported to the other. This architecture is 498 shown in Figure 2. 500 8 Conclusion 502 We have argued that the problem of managing a set of gateways from a 503 location server is critical. This process of management includes 504 propagation of routes, liveness determination, and propagation of 505 available capacity for the purposes of load balancing. TRIP is 506 ideally suited for these problems. As such, we propose here to define 507 TRIP-GW, a subset of TRIP functionality (yet still 100% compatible 508 with it) for use on gateways to perform this function. 510 9 Changes since -00 512 o Added text to stress the value of this proposal for managing a 513 +-----+ 514 | | 515 .................................... --| GW | 516 . +-------------.------------+ --- +-----+ 517 . | +--------+ .+--------+ | -- 518 . | |TRIP | .|TRIP | +-- +-----+ 519 . |/|Instance| .|Instance|--| | | 520 . / | | .| |--+-------- | GW | 521 . /| | | .| |--| +-----+ 522 . / | +--------+ .+--------+ +--- 523 . / | LS. | --- +-----+ 524 . / +-------------.------------+ -- | | 525 . / . | GW | 526 . +----------+ . +-----+ 527 . | | . 528 . | | . 529 . | LS | . 530 . | | . 531 . | | . 532 . +----------+ . +-----+ 533 . \ . | | 534 . \ . -- | GW | 535 . \ +-------------.------------+ -- +-----+ 536 . \ | +--------+ .+--------+ | --- 537 . \ | |TRIP | .|TRIP | +- +-----+ 538 . \| |Instance| .|Instance|--| | | 539 . \ | | .| |--+---------| GW | 540 . | | | .| |--| +-----+ 541 . | +--------+ .+--------+ +--- 542 . | LS. | --- +-----+ 543 . +-------------.------------+ -- | | 544 . ITAD . | GW | 545 .................................... +-----+ 547 Figure 2: LS Architecture for TRIP-GW 548 gateway cluster 550 o Added attributes for circuit capacity and DSP capacity 552 o Added section on LS operation, discussing aggregation issue 554 10 Authors Addresses 556 Jonathan Rosenberg 557 dynamicsoft 558 72 Eagle Rock Avenue 559 First Floor 560 East Hanover, NJ 07936 561 email: jdrosen@dynamicsoft.com 563 Hussein F. Salama 564 Cisco Systems 565 Mail Stop SJ-6/3 566 170 W. Tasman Drive 567 San Jose, CA 95134 568 email: hsalama@cisco.com 570 11 Bibliography 572 [1] J. Rosenberg, H. Salama, and M. Squire, "Telephony routing over 573 IP (TRIP)," Internet Draft, Internet Engineering Task Force, Jan. 574 2000. Work in progress. 576 [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 577 session initiation protocol," Request for Comments 2543, Internet 578 Engineering Task Force, Mar. 1999. 580 [3] J. Rosenberg and H. Schulzrinne, "A framework for telephony 581 routing over ip," Request for Comments 2871, Internet Engineering 582 Task Force, June 2000. 584 [4] International Telecommunication Union, "Packet based multimedia 585 communication systems," Recommendation H.323, Telecommunication 586 Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998.