idnits 2.17.1 draft-ietf-sipping-3pcc-03.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 the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 19) being 109 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (March 2, 2003) is 7719 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) -- Obsolete informational reference (is this intentional?): RFC 1889 (ref. '8') (Obsoleted by RFC 3550) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIPPING WG 3 Internet Draft J. Rosenberg 4 dynamicsoft 5 J. Peterson 6 Neustar 7 H. Schulzrinne 8 Columbia U. 9 G. Camarillo 10 Ericsson 11 draft-ietf-sipping-3pcc-03.txt 12 March 2, 2003 13 Expires: September 2003 15 Best Current Practices for Third Party Call Control 16 in the Session Initiation Protocol 18 STATUS OF THIS MEMO 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress". 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 To view the list Internet-Draft Shadow Directories, see 37 http://www.ietf.org/shadow.html. 39 Abstract 41 Third party call control refers to the ability of one entity to 42 create a call in which communications is actually between other 43 parties. Third party call control is possible using the mechanisms 44 specified within the Session Initiation Protocol (SIP). However, 45 there are several possible approaches, each with different benefits 46 and drawbacks. This document discusses best current practices for the 47 usage of SIP for third party call control. 49 Table of Contents 51 1 Introduction ........................................ 3 52 2 Terminology ......................................... 3 53 3 Definitions ......................................... 3 54 4 3pcc Call Establishment ............................. 4 55 4.1 Flow I .............................................. 4 56 4.2 Flow II ............................................. 5 57 4.3 Flow III ............................................ 7 58 4.4 Flow IV ............................................. 8 59 4.5 Recommendations ..................................... 9 60 5 Error Handling ...................................... 10 61 6 Continued Processing ................................ 11 62 7 3pcc and Early Media ................................ 12 63 8 Third Party Call Control and SDP Preconditions ...... 16 64 8.1 Controller Initiates ................................ 16 65 8.2 Party A Initiates ................................... 17 66 9 Example Call Flows .................................. 20 67 9.1 Click to Dial ....................................... 20 68 9.2 Mid-Call Announcement Capability .................... 22 69 10 Implementation Recommendations ...................... 24 70 11 Security Considerations ............................. 24 71 11.1 Identity ............................................ 24 72 11.2 End-to-End Encryption and Integrity ................. 25 73 12 IANA Considerations ................................. 26 74 13 Acknowledgements .................................... 26 75 14 Authors Addresses ................................... 26 76 15 Normative References ................................ 27 77 16 Informative References .............................. 27 79 1 Introduction 81 In the traditional telephony context, third party call control allows 82 one entity (which we call the controller) to set up and manage a 83 communications relationship between two or more other parties. Third 84 party call control (referred to as 3pcc) is often used for operator 85 services (where an operator creates a call that connects two 86 participants together), and conferencing. 88 Similarly, many SIP services are possible through third party call 89 control. These include the traditional ones on the PSTN, but also new 90 ones such as click-to-dial. Click-to-dial allows a user to click on a 91 web page when they wish to speak to a customer service 92 representative. The web server then creates a call between the user 93 and a customer service representative. The call can be between two 94 phones, a phone and an IP host, or two IP hosts. 96 Third party call control is possible using only the mechanisms 97 specified within RFC 3261 [1]. Indeed, many different call flows are 98 possible, each of which will work with SIP compliant user agents. 99 However, there are benefits and drawbacks to each of these flows. The 100 usage of third party call control also becomes more complex when 101 aspects of the call utilize SIP extensions or optional features of 102 SIP. In particular, the usage of RFC 3312 [2] (used for coupling of 103 signaling to resource reservation) with third party call control is 104 non-trivial. Similarly, the usage of early media (where session data 105 is exchanged before the call is accepted) with third party call 106 control is not trivial. 108 This document serves as a best current practice for implementing 109 third party call control without usage of any extensions specifically 110 designed for that purpose. Section 4 presents the known call flows 111 that can be used to achieve third party call control, and provides 112 guidelines on their usage. Section 8 discusses the interactions of 113 RFC 3312 [2] with third party call control. Section 7 discusses the 114 interactions of early media with third party call control. Section 9 115 provides example applications that make usage of the flows 116 recommended here. 118 2 Terminology 120 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 121 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 122 and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and 123 indicate requirement levels for compliant implementations. 125 3 Definitions 126 The following terms are used throughout this document: 128 3pcc: Third Party Call Control, which refers to the general 129 ability to manipulate calls between other parties. 131 Controller: A controller is a SIP User Agent that wishes to 132 create a session between two other user agents. 134 4 3pcc Call Establishment 136 The primary primitive operation of third party call control is the 137 establishment of a session between participants A and B. 138 Establishment of this session is orchestrated by a third party, 139 referred to as the controller. 141 This section documents three call flows that the controller can 142 utilize in order to provide this primitive operation. 144 4.1 Flow I 146 A Controller B 147 |(1) INVITE no SDP | | 148 |<------------------| | 149 |(2) 200 offer1 | | 150 |------------------>| | 151 | |(3) INVITE offer1 | 152 | |------------------>| 153 | |(4) 200 OK answer1 | 154 | |<------------------| 155 | |(5) ACK | 156 | |------------------>| 157 |(6) ACK answer1 | | 158 |<------------------| | 159 |(7) RTP | | 160 |.......................................| 162 Figure 1: 3pcc Flow I 164 The call flow for Flow I is shown in Figure 1. The controller first 165 sends an INVITE A (1). This INVITE has no session description. A's 166 phone rings, and A answers. This results in a 200 OK (2) that 167 contains an offer [4]. The controller needs to send its answer in the 168 ACK, as mandated by [1]. To obtain the answer, it sends the offer it 169 got from A (offer1) in an INVITE to B (3). B's phone rings. When B 170 answers, the 200 OK (4) contains the answer to this offer, answer1. 171 The controller sends an ACK to B (5), and then passes answer1 to A in 172 an ACK sent to it (6). Because the offer was generated by A, and the 173 answer generated by B, the actual media session is between A and B. 174 Therefore, media flows between them (7). 176 This flow is simple, requires no manipulation of the SDP by the 177 controller, and works for any media types supported by both 178 endpoints. However, it has a serious timeout problem. User B may not 179 answer the call immediately. The result is that the controller cannot 180 send the ACK to A right away. This causes A to retransmit the 200 OK 181 response periodically. As specified in RFC 3261 Section 13.3.1.4, the 182 200 OK will be retransmitted for 64*T1 seconds. If an ACK does not 183 arrive by then, the call is considered to have failed. This limits 184 the applicability of this flow to scenarios where the controller 185 knows that B will answer the INVITE immediately. 187 4.2 Flow II 189 A Controller B 190 |(1) INVITE bh sdp1 | | 191 |<------------------| | 192 |(2) 200 sdp2 | | 193 |------------------>| | 194 | |(3) INVITE sdp2 | 195 | |------------------>| 196 |(4) ACK | | 197 |<------------------| | 198 | |(5) 200 OK sdp3 | 199 | |<------------------| 200 | |(6) ACK | 201 | |------------------>| 202 |(7) INVITE sdp3 | | 203 |<------------------| | 204 |(8) 200 OK sdp2 | | 205 |------------------>| | 206 |(9) ACK | | 207 |<------------------| | 208 |(10) RTP | | 209 |.......................................| 211 Figure 2: 3pcc Flow II 212 An alternative flow, Flow II, is shown in Figure 2. The controller 213 first sends an INVITE to user A (1). This is a standard INVITE, 214 containing an offer (sdp1) with a single audio media line, one codec, 215 a random port number (but not zero), and a connection address of 216 0.0.0.0. This creates an initial media stream that is "black holed", 217 since no media (or RTCP packets [8]) will flow from A. The INVITE 218 causes A's phone to ring. 220 When A answers (2), the 200 OK contains an answer, sdp2. the 221 controller sends an ACK (4). It then generates a second INVITE (3). 222 This INVITE is addressed to user B, and it contains sdp2 as the offer 223 to B. Note that the role of sdp2 has changed. In the 200 OK (message 224 2), it was an answer, but in the INVITE, it is an offer. Fortunatly, 225 all valid answers are valid initial offers. This INVITE causes B's 226 phone to ring. When it answers, it generates a 200 OK (5) with an 227 answer, sdp3. The controller then generates an ACK (6). Next, it 228 sends a re-INVITE to A (7) containing sdp3 as the offer. Once again, 229 there has been a reversal of roles. sdp3 was an answer, and now it is 230 an offer. Fortunately, an answer to an answer recast as an offer is, 231 in turn, a valid offer. This re-INVITE generates a 200 OK (8) with 232 sdp2, assuming that A doesn't decide to change any aspects of the 233 session as a result of this re-INVITE. This 200 OK is ACKed (9), and 234 then media can flow from A to B. Media from B to A could already 235 start flowing once message 5 was sent. 237 This flow has the advtange that all final responses are immediately 238 ACKed. It therefore does not suffer from the timeout and message 239 inefficiency problems of flow 1. However, it too has troubles. First 240 off, it requires that the controller know the media types to be used 241 for the call (since it must generate a "blackhole" SDP, which 242 requires media lines). Secondly, the first INVITE to A (1) contains 243 media with a 0.0.0.0 connection address. The controller expects that 244 the response contains a valid, non-zero connection address for A. 245 However, experience has shown that many UAs respond to an offer of a 246 0.0.0.0 connection address with an answer containing a 0.0.0.0 247 connection address. The offer-answer specification [4] now explicitly 248 tells implementors not to do this, but at the time of publication of 249 this document, many implementations still did. If A should respond 250 with a 0.0.0.0 connection address in sdp2, the flow will not work. 252 However, the most serious flaw in this flow is the assumption that 253 the 200 OK to the re-INVITE (message 8) contains the same SDP as in 254 message 2. This may not be the case. If it is not, the controller 255 needs to re-INVITE B with that SDP (say, sdp4), which may result in 256 getting a different SDP, sdp5 , in the 200 OK from B. Then, the 257 controller needs to re-INVITE A again, and so on. The result is an 258 infinite loop of re-INVITEs. It is possible to break this cycle by 259 having very smart UAs which can return the same SDP whenever 260 possible, or really smart controllers that can analyze the SDP to 261 determine if a re-INVITE is really needed. However, we wish to keep 262 this mechanism simple, and avoid SDP awareness in the controller. As 263 a result, this flow is not really workable. It is therefore NOT 264 RECOMMENDED. 266 4.3 Flow III 268 A Controller B 269 |(1) INVITE no SDP | | 270 |<---------------------| | 271 |(2) 200 offer1 | | 272 |--------------------->| | 273 |(3) ACK answer1 (bh) | | 274 |<---------------------| | 275 | |(4) INVITE no SDP | 276 | |--------------------->| 277 | |(5) 200 OK offer2 | 278 | |<---------------------| 279 |(6) INVITE offer2' | | 280 |<---------------------| | 281 |(7) 200 answer2' | | 282 |--------------------->| | 283 | |(8) ACK answer2 | 284 | |--------------------->| 285 |(9) ACK | | 286 |<---------------------| | 287 |(10) RTP | | 288 |.............................................| 290 Figure 3: 3pcc Flow III 292 A third flow, Flow III, is shown in Figure 3. 294 First, the controller sends an INVITE (1) to user A without any SDP 295 (which is good, since it means that the controller doesn't need to 296 assume anything about the media composition of the session). A's 297 phone rings. When A answers, a 200 OK is generated (2) containing its 298 offer, offer1. The controller generates an immediate ACK containing 299 an answer (3). This answer is a "black hole" SDP, with its connection 300 address set to 0.0.0.0. 302 The controller then sends an INVITE to B without SDP (4). This causes 303 B's phone to ring. When they answer, a 200 OK is sent, containing 304 their offer, offer2 (5). This SDP is used to create a re-INVITE back 305 to A (6). That re-INVITE is based on offer2, but may need to be 306 reorganized to match up media lines, or to trim media lines. For 307 example, if offer1 contained an audio and a video line, in that 308 order, but offer2 contained just an audio line, the controller would 309 need to add a video line to the offer (setting its port to zero) to 310 create offer2'. Since this is a re-INVITE, it should complete quickly 311 in the general case. Thats good, since user B is retransmitting their 312 200 OK, waiting for an ACK. The SDP in the 200 OK (7) from A, 313 answer2', may also need to be reorganized or trimmed before sending 314 it an the ACK to B (8) as answer2. Finally, an ACK is sent to A (9), 315 and then media can flow. 317 This flow has many benefits. First, it will usually operate without 318 any spurious retransmissions or timeouts (although this may still 319 happen if a re-INVITE is not responded to quickly). Secondly, it does 320 not require the controller to guess the media that will be used by 321 the participants. Thirdly, it does not assume that a device responds 322 properly to an INVITE with SDP containing a connection address of 323 0.0.0.0. 325 There are some drawbacks. The controller does need to perform SDP 326 manipulations. Specifically, it must take some SDP, and generate 327 another SDP which has the same media composition, but has connection 328 addresses of 0.0.0.0. This is needed for message 3. Secondly, it may 329 need to reorder and trim on SDP X, so that its media lines match up 330 with those in some other SDP, Y. Thirdly, the offer from B (offer2) 331 may have no codecs or media streams in common with the offer from A 332 (offer 1). The controller will need to detect this condition, and 333 terminate the call. Finally, the flow is far more complicated than 334 the simple and elegant Flow I (Figure 1). 336 4.4 Flow IV 338 Flow IV shows a variation on Flow III that reduces its complexity. 339 The actual message flow is identical, but the SDP placement and 340 construction differs. The initial INVITE (1) contains SDP with no 341 media at all, meaning that there are no m lines. This is valid, and 342 implies that the media makeup of the session will be established 343 later through a re-INVITE [4]. Once the INVITE is received, user A is 344 alerted. When they answer the call, the 200 OK (2) has an answer with 345 no media either. This is acknowledged by the controller (3). The flow 346 from this point onwards is identical to Flow III. However, the 347 manipulations required to convert offer2 to offer2', and answer2' to 348 answer2, are much simpler. Indeed, no media manipulations are needed 349 at all. The only change that is needed is to modify the origin lines, 350 A Controller B 351 |(1) INVITE offer1 | | 352 |no media | | 353 |<---------------------| | 354 |(2) 200 answer1 | | 355 |no media | | 356 |--------------------->| | 357 |(3) ACK | | 358 |<---------------------| | 359 | |(4) INVITE no SDP | 360 | |--------------------->| 361 | |(5) 200 OK offer2 | 362 | |<---------------------| 363 |(6) INVITE offer2' | | 364 |<---------------------| | 365 |(7) 200 answer2' | | 366 |--------------------->| | 367 | |(8) ACK answer2 | 368 | |--------------------->| 369 |(9) ACK | | 370 |<---------------------| | 371 |(10) RTP | | 372 |.............................................| 374 Figure 4: 3pcc Flow IV 376 so that the origin line in offer2' is valid based on the value in 377 offer1 (validify requires that the version increments by one, and 378 that the other parameters remain unchanged). 380 There are some limitations associated with this flow. First, user A 381 will be alerted without any media having been established yet. This 382 means that user A will not be able to reject or accept the call based 383 on its media composition. Secondly, both A and B will end up 384 answering the call (i.e., generating a 200 OK) before it is known 385 whether their is compatible media. If there is no media in common, 386 the call can be terminated later with a BYE. However, the users will 387 have already been alerted, resulting in user annoyance and possibly 388 resulting in billing events. 390 4.5 Recommendations 392 Flow I (Figure 1) represents the simplest and the most efficient 393 flow. This flow SHOULD be used by a controller if it knows with 394 certainty that user B is actually an automata that will answer the 395 call immediately. This is the case for devices such as media servers, 396 conferencing servers, and messaging servers, for example. Since we 397 expect a great deal of third party call control to be to automata, 398 special caseing this scenario is reasonable. 400 For calls to unknown entities, or to entities known to represent 401 people, it is RECOMMENDED that Flow IV (Figure 4) be used for third 402 party call control. Flow III MAY be used instead, but it provides no 403 additional benefits over Flow IV. However, Flow II SHOULD NOT be 404 used, because of the potential for infinite ping-ponging of re- 405 INVITEs. 407 Several of these flows use a "black hole" connection address of 408 0.0.0.0. This is an IPV4 address with the property that packets sent 409 to it will never leave the host which sent them; they are just 410 discarded. Those flows are therefore specific to IPv4. For other 411 network or address types, an address with an equivalent property 412 SHOULD be used. 414 5 Error Handling 416 There are numerous error cases which merit discussion. 418 With all of the call flows in Section 4, one call is established to 419 A, and then the controller attempts to establish a call to B. 420 However, this call attempt may fail, for any number of reasons. User 421 B might be busy (resulting in a 486 response to the INVITE), there 422 may not be any media in common, the request may time out, and so on. 423 If the call attempt to B should fail, it is RECOMMENDED that the 424 controller send a BYE to A. This BYE SHOULD include a Reason header 425 [5] which carries the status code from the error response. This will 426 inform A of the precise reason for the failure. The information is 427 important from a user interface perspective. For example, if A was 428 calling from a black phone, and B generated a 486, the BYE will 429 contain a Reason code of 486, and this could be used to generate a 430 local busy signal so that A knows that B is busy. 432 Another error condition worth discussion is shown in Figure 5. After 433 the controller establishes the dialog with A (messages 1-3) it 434 attempts to contact B (message 4). Contacting B may take some time. 435 During that interval, A could possibly attempt a re-INVITE, providing 436 an updated offer. However, the controller cannot pass this offer on 437 to B, since it has an INVITE transaction pending with it. As a 438 result, the controller needs to reject the request. It is RECOMMENDED 439 that a 491 response be used. The situation here is similar to the 440 glare condition described in [1], and thus the same error handling is 441 A Controller B 442 |(1) INVITE offer1 | | 443 |no media | | 444 |<---------------------| | 445 |(2) 200 answer1 | | 446 |no media | | 447 |--------------------->| | 448 |(3) ACK | | 449 |<---------------------| | 450 | |(4) INVITE no SDP | 451 | |--------------------->| 452 | |(5) 180 | 453 | |<---------------------| 454 |(6) INVITE offer2 | | 455 |--------------------->| | 456 |(7) 491 | | 457 |<---------------------| | 458 |(8) ACK | | 459 |--------------------->| | 461 Figure 5: Glare Error Condition 463 sensible. However, A is likely to retry its request (as a result of 464 the 491), and this may occur before the exchange with B is completed. 465 In that case, the controller would respond with another 491. 467 6 Continued Processing 469 Once the calls are established, both participants believe they are in 470 a single point-to-point call. However, they are exchanging media 471 directly with each other, rather than with the controller. The 472 controller is involved in two dialogs, yet sees no media. 474 Since the controller is still a central point for signaling, it now 475 has complete control over the call. If it receives a BYE from one of 476 the participants, it can create a new BYE and hang up with the other 477 participant. This is shown in Figure 6. 479 Similarly, if it receives a re-INVITE from one of the participants, 480 it can forward it to the other participant. Depending on which flow 481 was used, this may require some manipulation on the SDP before 482 passing it on. 484 A Controller B 485 |(1) BYE | | 486 |------------------>| | 487 |(2) 200 OK | | 488 |<------------------| | 489 | |(3) BYE | 490 | |------------------>| 491 | |(4) 200 OK | 492 | |<------------------| 494 Figure 6: Hanging Up with 3PCC 496 However, the controller need not "proxy" the SIP messages received 497 from one of the parties. Since it is a B2BUA, it can invoke any 498 signaling mechanism on each dialog, as it sees fit. For example, if 499 the controller receives a BYE from A, it can generate a new INVITE to 500 a third party, C, and connect B to that participant instead. A call 501 flow for this is shown in Figure 7, assuming the case where C 502 represents an end user, not an automata. Note that it is just Flow 503 IV. 505 From here, new parties can be added, removed, transferred, and so on, 506 as the controller sees fit. 508 It is important to point out that the call need not have been 509 established by the controller in order for the processing of this 510 section to be used. Rather, the controller could have acted as a 511 B2BUA during a call established by A towards B (or vice a versa). 513 7 3pcc and Early Media 515 Early media represents the condition where the session is established 516 (as a result of the completion of an offer/answer exchange), yet the 517 call itself has not been accepted. This is usually used to convey 518 tones or announcements regarding progress of the call. Handling of 519 early media in a third party call is straightforward. 521 Figure 8 shows the case where user B generates early media before 522 answering the call. The flow is almost identical to Flow IV from 523 Figure 4. The only difference is that user B generates a reliable 524 provisional response (5) [6] instead of a final response, and answer2 525 is carried in a PRACK (8) instead of an ACK. When party B finally 526 A Controller B C 527 |(1) BYE | | | 528 |--------------->| | | 529 |(2) 200 OK | | | 530 |<---------------| | | 531 | |(3) INV no media| | 532 | |-------------------------------->| 533 | |(4) 200 no media| | 534 | |<--------------------------------| 535 | |(5) ACK | | 536 | |-------------------------------->| 537 | |(6) INV no SDP | | 538 | |--------------->| | 539 | |(7) 200 offer3 | | 540 | |<---------------| | 541 | |(8) INV offer3' | | 542 | |-------------------------------->| 543 | |(9) 200 answer3'| | 544 | |<--------------------------------| 545 | |(10) ACK | | 546 | |-------------------------------->| 547 | |(11) ACK answer3| | 548 | |--------------->| | 549 | | |(12) RTP | 550 | | |................| 552 Figure 7: Alternative to Hangup 554 does accept the call (11), there is no change in the session state, 555 and therefore, no signaling needs to be done with user A. The 556 controller simply ACKs the 200 OK (12) to confirm the dialog. 558 The case where user A generates early media is more complicated, and 559 is shown in Figure 9. The flow is based on Flow IV. The controller 560 sends an INVITE to user A (1), with an offer containing no media 561 streams. User A generates a reliable provisional response (2) 562 containing an answer with no media streams. The controller PRACKs 563 this provisional response (3). Now, the controller sends an INVITE 564 without SDP to user B (5). User B's phone rings, and they answer, 565 resulting in a 200 OK (6) with an offer, offer2. The controller now 566 needs to update the session parameters with user A. However, since 567 the call has not been answered, it cannot use a re-INVITE. Rather, it 568 uses a SIP UPDATE request (7) [7], passing the offer (after modifying 569 A Controller B 570 | | | 571 |(1) INVITE offer1 | | 572 |no media | | 573 |<---------------------| | 574 | | | 575 | | | 576 | | | 577 | | | 578 | | | 579 | | | 580 |(2) 200 answer1 | | 581 |no media | | 582 |--------------------->| | 583 | | | 584 |(3) ACK | | 585 |<---------------------| | 586 | | | 587 | |(4) INVITE no SDP | 588 | |--------------------->| 589 | | | 590 | | | 591 | | | 592 | | | 593 | |(5) 183 offer2 | 594 | |<---------------------| 595 | | | 596 |(6) INVITE offer2' | | 597 |<---------------------| | 598 | | | 599 |(7) 200 answer2' | | 600 |--------------------->| | 601 | | | 602 |(8) ACK | | 603 |<---------------------| | 604 | | | 605 | |(9) PRACK answer2 | 606 | |--------------------->| 607 | | | 608 | |(10) 200 PRACK | 609 | |<---------------------| 610 | | | 611 |(11) RTP | | 612 |.............................................| 613 | | | 614 | | | 615 | | | 616 | | | 617 | |(12) 200 OK | 618 | |<---------------------| 619 | | | 620 | |(13) ACK | 621 | |--------------------->| 622 | | | 623 | | | 624 | | | 626 Figure 8: Early Media from User B 627 A Controller B 628 | | | 629 |(1) INVITE offer1 | | 630 |no media | | 631 |<---------------------| | 632 | | | 633 |ring | | 634 | | | 635 |(2) 183 answer1 | | 636 |no media | | 637 |--------------------->| | 638 | | | 639 |(3) PRACK | | 640 |<---------------------| | 641 | | | 642 |(4) 200 PRACK | | 643 |--------------------->| | 644 | | | 645 | |(5) INVITE no SDP | 646 | |--------------------->| 647 | | | 648 | | |ring 649 | | | 650 | | | 651 | | |answer 652 | | | 653 | | | 654 | |(6) 200 OK offer2 | 655 | |<---------------------| 656 | | | 657 |(7) UPDATE offer2' | | 658 |<---------------------| | 659 | | | 660 |answer | | 661 | | | 662 | | | 663 |(8) 200 answer2' | | 664 |--------------------->| | 665 | | | 666 | |(9) ACK answer2 | 667 | |--------------------->| 668 | | | 669 |(10) RTP | | 670 |.............................................| 671 | | | 672 |(11) 200 OK | | 673 |--------------------->| | 674 | | | 675 |(12) ACK | | 676 |<---------------------| | 677 | | | 678 | | | 679 | | | 681 Figure 9: Early Media from User A 683 it to get the origin field correct). User A generates its answer in 684 the 200 OK to the UPDATE (8). This answer is passed to user B in the 685 ACK (9). When user A finally answers (11), there is no change in 686 session state, so the controller simply ACKs the 200 OK (12). 688 Note that it is likely that there will be clipping of media in this 689 call flow. User A is likely a PSTN gateway, and has generated a 690 provisional response because of early media from the PSTN side. The 691 PSTN will deliver this media even though the gateway does not have 692 anywhere to send it, since the initial offer from the controller had 693 no media streams. When user B answers, media can begin to flow. 694 However, any media sent to the gateway from the PSTN up to that point 695 will be lost. 697 8 Third Party Call Control and SDP Preconditions 699 A SIP extension has been specified that allows for the coupling of 700 signaling and resource reservation [2]. This draft relies on 701 exchanges of session descriptions before completion of the call 702 setup. These flows are initiated when certain SDP parameters are 703 passed in the initial INVITE. As a result, the interaction of this 704 mechanism with third party call control is not obvious, and worth 705 detailing. 707 8.1 Controller Initiates 709 In one usage scenario, the controller wishes to make use of 710 preconditions in order to avoid the call failure scenarios documented 711 in Section 4.4. Specifically, the controller can use preconditions in 712 order to guarantee that neither party is alerted unless there is a 713 common set of media and codecs. It can also provide both parties with 714 information on the media composition of the call before they decide 715 to accept it. 717 The flow for this scenario is shown in Figure 10. In this example, we 718 assume that user B is an automata or agent of some sort which will 719 answer the call immediately. Therefore, the flow is based on Flow I. 720 The controller sends an INVITE to user A containing no SDP, but with 721 a Require header indicating that preconditions are required. This 722 specific scenario (an INVITE without an offer, but with a Require 723 header indicating preconditions) is not described in [2]. It is 724 RECOMMENDED that the UAS respond with an offer in a 1xx including the 725 media streams it wishes to use for the call, and for each, list all 726 preconditions it supports as optional. Of course, the user is not 727 alerted at this time. The controller takes this offer and passes it 728 to user B (3). User B does not support preconditions, or does, but is 729 not interested in them. Therefore, when it answers the call, the 200 730 OK contains an answer without any preconditions listed (4). This 731 answer is passed to user A in the PRACK (6). At this point, user A 732 knows that there are no preconditions actually in use for the call, 733 and therefore, it can alert the user. When the call is answered, user 734 A sends a 200 OK to the controller (8) and the call is complete. 736 In the event that the offer generated by user A was not acceptable to 737 user B (because of non-overlapping codecs or media, for example), 738 user B would immediately reject the INVITE (message 3). The 739 controller would then CANCEL the request to user A. In this 740 situation, neither user A nor user B would have been alerted, 741 achieving the desired effect. It is interesting to note that this 742 property is achieved using preconditions even though it doesn't 743 matter what specific types of preconditions are supported by user A. 745 It is also entirely possible that user B does actually desire 746 preconditions. In that case, it might generate a 1xx of its own with 747 an answer containing preconditions. That answer would still be passed 748 to user A, and both parties would proceed with whatever measures are 749 necessary to meet the preconditions. Neither user would be alerted 750 until the preconditions were met. 752 8.2 Party A Initiates 754 In Section 8.1, the controller requested the use of preconditions to 755 achieve a specific goal. It is also possible that the controller 756 doesn't care (or perhaps doesn't even know) about preconditions, but 757 one of the participants in the call does care. A call flow for this 758 case is shown in Figure 11. 760 The controller follows Flow IV; it has no specific requirements for 761 support of the preconditions specification [2]. Therefore, it sends 762 an INVITE (1) with SDP that contains no media lines. User A is 763 interested in supporting preconditions, and does not want to ring its 764 phone until resources are reserved. Since there are no media streams 765 in the INVITE, it can't reserve resources for media streams, and 766 therefore it can't ring the phone until they are conveyed in a 767 subsequent offer and then reserved. Therefore, it generates a 183 768 with the answer, and doesn't alert the user (2). The controller 769 PRACKs this (3) and A responds to the PRACK (4). 771 At this point, the controller attempts to bring B into the call. It 772 sends B an INVITE without SDP (5). B is interested in having 773 preconditions for this call. Therefore, it generates its offer in a 774 User Controller Customer Service 775 | | | 776 |(1) INVITE no SDP | | 777 |require precon | | 778 |<------------------| | 779 |(2) 183 offer1 | | 780 |optional precon | | 781 |------------------>| | 782 | | | 783 | |(3) INVITE offer1 | 784 | |------------------>| 785 | | | 786 | | | 787 | | | 788 | | | 789 | | | 790 | | | 791 | |(4) 200 OK answer1 | 792 | |no precon | 793 | |<------------------| 794 | | | 795 | |(5) ACK | 796 | |------------------>| 797 | | | 798 |(6) PRACK answer1 | | 799 |<------------------| | 800 | | | 801 | | | 802 | | | 803 | | | 804 |(7) 200 PRACK | | 805 |------------------>| | 806 | | | 807 | | | 808 | | | 809 | | | 810 |(8) 200 INVITE | | 811 |------------------>| | 812 | | | 813 |(9) ACK | | 814 |<------------------| | 815 | | | 816 | | | 817 | | | 819 Figure 10: Controller Initiated Preconditions 820 A Controller B 821 |(1) INVITE offer1 | | 822 |no media | | 823 |<---------------------| | 824 |(2) 183 answer1 | | 825 |no media | | 826 |--------------------->| | 827 |(3) PRACK | | 828 |<---------------------| | 829 |(4) 200 OK | | 830 |--------------------->| | 831 | |(5) INVITE no SDP | 832 | |--------------------->| 833 | |(6) 183 offer2 | 834 | |des=sendrecv | 835 | |conf=recv | 836 | |cur=none | 837 | |<---------------------| 838 |(7) UPDATE offer2' | | 839 |des=sendrecv | | 840 |conf=recv | | 841 |cur=none | | 842 |<---------------------| | 843 |(8) 200 UPDATE | | 844 |answer2' | | 845 |des=sendrecv | | 846 |conf=recv | | 847 |cur=none | | 848 |--------------------->| | 849 | |(9) PRACK answer2 | 850 | |des=sendrecv | 851 | |conf=recv | 852 | |cur=none | 853 | |--------------------->| 854 | |(10) 200 PRACK | 855 | |<---------------------| 856 |(11) reservation | | 857 |-------------------------------------------->| 858 |(12) reservation | | 859 |<--------------------------------------------| 860 |(13) UPDATE offer3 | | 861 |des=sendrecv | | 862 |conf=recv | | 863 |cur=recv | | 864 |--------------------->| | 865 | |(14) UPDATE offer3' | 866 | |des=sendrecv | 867 | |conf=recv | 868 | |cur=recv | 869 | |--------------------->| 870 | |(15) 200 UPDATE | 871 | |answer3' | 872 | |des=sendrecv | 873 | |conf=recv | 874 | |cur=send | 875 | |<---------------------| 876 |(16) 200 UPDATE | | 877 |answer3 | | 878 |des=sendrecv | | 879 |conf=recv | | 880 |cur=send | | 881 |<---------------------| | 882 | | | 883 | |(17) UPDATE offer4 | 884 | |des=sendrecv | 885 | |conf=recv | 886 | |cur=sendrecv | 887 | |<---------------------| 888 |(18) UPDATE offer4' | | 889 |des=sendrecv | | 890 |conf=recv | | 891 |cur=sendrecv | | 892 |<---------------------| | 893 | | | 894 |(19) 200 UPDATE | | 895 |answer4' | | 896 |des=sendrecv | | 897 |conf=recv | | 898 |cur=sendrecv | | 899 |--------------------->| | 900 | |(20) 200 UPDATE | 901 | |answer4 | 902 | |des=sendrecv | 903 | |conf=recv | 904 | |cur=sendrecv | 905 | |--------------------->| 906 |(21) 180 INVITE | | 907 |--------------------->| | 908 | |(22) 180 INVITE | 909 | |<---------------------| 910 | | | 911 |(23) 200 INVITE | | 912 |--------------------->| | 913 |(24) ACK | | 914 |<---------------------| | 915 | | | 916 | |(25) 200 INVITE | 917 | |<---------------------| 918 | |(26) ACK | 919 | |--------------------->| 921 Figure 11: User A Initiated Preconditions 923 183 that contains the appropriate SDP attributes (6). The controller 924 passes this offer to A in an UPDATE request (7). The controller uses 925 UPDATE because the call has not been answered yet, and therefore, it 926 cannot use a re-INVITE. User A sees that its peer is capable of 927 supporting preconditions. Since it desires preconditions for the 928 call, it generates an answer in the 200 OK (8) to the UPDATE. This 929 answer, in turn, is passed to B in the PRACK for the provisional 930 response (9). Now, both sides perform resource reservation. User A 931 succeeds first, and passes an updated session description in an 932 UPDATE request (13). The controller simply passes this to A (after 933 the manipulation of the origin field, as required in Flow IV) in an 934 UPDATE (14), and the answer (15) is passed back to A (16). The same 935 flow happens, but from B to A, when B's reservation succeeds (17-20). 936 Since the preconditions have been met, both sides ring (21 and 22), 937 and then both answer (23 and 25), completing the call. 939 What is important about this flow is that the controller doesn't know 940 anything about preconditions. It merely passes the SDP back and forth 941 as needed. The trick is the usage of UPDATE and PRACK to pass the SDP 942 when needed. That determination is made entirely based on the 943 offer/answer rules described in [6] and [7], and is independent of 944 preconditions. 946 9 Example Call Flows 948 9.1 Click to Dial 950 The first application of this capability we discuss is click to dial. 951 In this service, a user is browsing the web page of an e-commerce 952 site, and would like to speak to a customer service representative. 953 They click on a link, and a call is placed to a customer service 954 representative. When the representative picks up, the phone on the 955 user's desk rings. When they pick up, the customer service 956 representative is there, ready to talk to the user. 958 The call flow for this service is given in Figure 12. It is identical 959 to that of Figure 4, with the exception that the service is triggered 960 through an http GET request when the user clicks on the link. 962 We note that this service can be provided through other mechanisms, 963 namely PINT [9]. However, there are numerous differences between the 964 way in which the service is provided by pint, and the way in which it 965 is provided here: 967 Customer Service Controller Users Phone Users Browser 968 | |(1) HTTP POST | | 969 | |<--------------------------------------| 970 | |(2) HTTP 200 OK | | 971 | |-------------------------------------->| 972 |(3) INVITE offer1 | | | 973 |no media | | | 974 |<------------------| | | 975 |(4) 200 answer1 | | | 976 |no media | | | 977 |------------------>| | | 978 |(5) ACK | | | 979 |<------------------| | | 980 | |(6) INVITE no SDP | | 981 | |------------------>| | 982 | |(7) 200 OK offer2 | | 983 | |<------------------| | 984 |(8) INVITE offer2' | | | 985 |<------------------| | | 986 |(9) 200 answer2' | | | 987 |------------------>| | | 988 | |(10) ACK answer2 | | 989 | |------------------>| | 990 |(11) ACK | | | 991 |<------------------| | | 992 |(12) RTP | | | 993 |.......................................| | 995 Figure 12: Click to Dial Call Flow 997 o The pint solution enables calls only between two PSTN 998 endpoints. The solution described here allows calls between 999 PSTN phones (through SIP enabled gateways) and native IP 1000 phones. 1002 o When used for calls between two PSTN phones, the solution here 1003 may result in a portion of the call being routed over the 1004 Internet. In pint, the call is always routed only over the 1005 PSTN. This may result in better quality calls with the pint 1006 solution, depending on the codec in use and QoS capabilities 1007 of the network routing the Internet portion of the call. 1009 o The PINT solution requires extensions to SIP (PINT is an 1010 extension to SIP), whereas the solution described here is done 1011 with baseline SIP. 1013 o The PINT solution allows the controller (acting as a PINT 1014 client) to "step out" once the call is established. The 1015 solution described here requires the controller to maintain 1016 call state for the entire duration of the call. 1018 9.2 Mid-Call Announcement Capability 1020 The third party call control mechanism described here can also be 1021 used to enable mid-call announcements. Consider a service for pre- 1022 paid calling cards. Once the pre-paid call is established, the system 1023 needs to set a timer to fire when they run out of minutes. When this 1024 timer fires, we would like the user to hear an announcement which 1025 tells them to enter a credit card to continue. Once they enter the 1026 credit card info, more money is added to the pre-paid card, and the 1027 user is reconnected to the destination party. 1029 We consider here the usage of third party call control just for 1030 playing the mid-call dialog to collect the credit card information. 1032 We assume the call is set up so that the controller is in the call as 1033 a B2BUA. When the timer fires, we wish to connect the caller to a 1034 media server. The flow for this is shown in Figure 13. When the 1035 timer expires, the controller places the called party with a 1036 connection address of 0.0.0.0 (1). This effectively "disconnects" the 1037 called party. The controller then sends an INVITE without SDP to the 1038 the pre-paid caller (4). The offer returned from the caller (5) is 1039 used in an INVITE to the media server which will be collecting digits 1040 (6). This is an instantiation of Flow I. This flow can only be used 1041 here because the media server is an automata, and will answer the 1042 INVITE immediately. If the controller was connecting the pre-paid 1043 user with another end user, Flow III would need to be used. The media 1044 server returns an immediate 200 OK (7) with an answer, which is 1045 passed to the caller in an ACK (8). The result is that the media 1046 server and the pre-paid caller have their media streams connected. 1048 The media server plays an announcement, and prompts the user to enter 1049 a credit card number. After collecting the number, the card number is 1050 validated. The media server then passes the card number to the 1051 controller (using some means outside the scope of this 1052 specification), and then hangs up the call (11). 1054 After hanging up with the media server, the controller reconnects the 1055 user to the original called party. To do this, the controller sends 1056 an INVITE without SDP to the called party (13). The 200 OK (14) 1057 contains an offer, offer3. The controller modifies the SDP (as is 1058 Pre-Paid User Controller Called Party Media Server 1059 | |(1) INV SDP c=0 | | 1060 | |------------------>| | 1061 | |(2) 200 answer1 | | 1062 | |<------------------| | 1063 | |(3) ACK | | 1064 | |------------------>| | 1065 |(4) INV no SDP | | | 1066 |<------------------| | | 1067 |(5) 200 offer2 | | | 1068 |------------------>| | | 1069 | |(6) INV offer2 | | 1070 | |-------------------------------------->| 1071 | |(7) 200 answer2 | | 1072 | |<--------------------------------------| 1073 |(8) ACK answer2 | | | 1074 |<------------------| | | 1075 | |(9) ACK | | 1076 | |-------------------------------------->| 1077 |(10) RTP | | | 1078 |...........................................................| 1079 | |(11) BYE | | 1080 | |-------------------------------------->| 1081 | |(12) 200 OK | | 1082 | |<--------------------------------------| 1083 | |(13) INV no SDP | | 1084 | |------------------>| | 1085 | |(14) 200 offer3 | | 1086 | |<------------------| | 1087 |(15) INV offer3' | | | 1088 |<------------------| | | 1089 |(16) 200 answer3' | | | 1090 |------------------>| | | 1091 | |(17) ACK answer3' | | 1092 | |------------------>| | 1093 |(18) ACK | | | 1094 |<------------------| | | 1095 |(19) RTP | | | 1096 |.......................................| | 1098 Figure 13: Mid-Call Announcement 1099 done in Flow III), and passes the offer in an INVITE to the pre-paid 1100 user (15). The pre-paid user generates an answer in a 200 OK (16) 1101 which the controller passes to user B in the ACK (17). At this point, 1102 the caller and called party are reconnected. 1104 10 Implementation Recommendations 1106 Most of the work involved in supporting third party call control is 1107 within the controller. A standard SIP UA should be controllable using 1108 the mechanisms described here. However, third party call control 1109 relies on a few features that might not be implemented. As such, we 1110 RECOMMEND that implementors of user agent servers to support the 1111 following: 1113 o Re-invites that change the port to which media should be sent 1115 o Re-invites that change the connection address 1117 o Re-invites that add a media stream 1119 o Re-invites that remove a media stream (setting its port to 1120 zero) 1122 o Re-invites that add a codec amongst the set in a media stream 1124 o SDP Connection address of zero 1126 o Initial invites with a connection address of zero 1128 o Initial invites with no SDP 1130 o Initial invites with SDP but no media lines 1132 o Re-invites with no SDP 1134 o The UPDATE method [7] 1136 o Reliability of provisional responses [6] 1138 o Integration of resource management and SIP [2]. 1140 11 Security Considerations 1142 11.1 Identity 1144 The principal security consideration with third party call control is 1145 identity. When the controller initiates the call, what identity does 1146 it place in the From field of the INVITE? The controller could 1147 indicate that the call is from itself (From: 1148 sip:controller@example.com), but the call is really from some user, 1149 and is just facilitated by the controller. This impacts on how the 1150 call is authenticated by the end users. 1152 There are many cases, and the right one depends on the application of 1153 3pcc. In one common scenario, the controller is acting on behalf of 1154 one of the participants in the call. A typical example is click-to- 1155 dial, where the controller and the customer service representative 1156 are run by the same administrative domain. Indeed, for the purposes 1157 of identification, the controller can legitimately claim to be the 1158 customer service representative. In this scenario, it would be 1159 appropriate for the INVITE to the end user to contain a From field 1160 identifying the customer service rep, and authenticate the request 1161 using S/MIME signed by the key of the customer service rep (which is 1162 held by the controller). 1164 This requires the controller to actually have credentials with which 1165 it can authenticate itself as the customer support representative. In 1166 many other cases, the controller is representing one of the 1167 participants, but does not possess their credentials. Unfortunately, 1168 there are currently no standardized mechanisms that allow a user to 1169 delegate credentials to the controller in a way that limits their 1170 usage to specific third party call control operations. In the absence 1171 of such a mechanisms, the best that can be done is to use the display 1172 name in the From field to indicate the identity of the user on who's 1173 behalf the call is being made. It is RECOMMENDED that the display 1174 name be set to " on behalf of ", where user and 1175 controller are textual identities of the user and controller, 1176 respectively. In this case, the URI in the From field would identify 1177 the controller. 1179 In other situations, there is no real relationship between the 1180 controller and the participants in the call. In these situations, 1181 ideally the controller would have a means to assert that the call is 1182 from a particular identity (which could be one of the participants, 1183 or even a third party, depending on the application), and to validate 1184 that assertion with a signature using the key of the controller. 1186 11.2 End-to-End Encryption and Integrity 1188 With third party call control, the controller is actually one of the 1189 participants as far as the SIP dialog is concerened. Therefore, 1190 encryption and integrity of the SIP messages, as provided by S/MIME, 1191 will occur between participants and the controller, rather than 1192 directly between participants. 1194 However, end-to-end integrity, authenticity and confidentiality of 1195 the media sessions can be guaranteed through a controller. End-to-end 1196 media security is based on the exchange of keying material within 1197 SDP. For example, protocols such as MIKEY [10] can be used within 1198 SDP. The proper operation of these mechanisms with third party call 1199 control depends on the controller behaving properly. So long as it is 1200 not attempting to explicitly disable these mechanisms, the protocols 1201 will properly operate end-to-end, resulting in a secure media session 1202 that even the controller cannot eavesdrop or modify. Since third 1203 party call control is based on a model of trust between the users and 1204 the controller, it is reasonable to assume it is operating in a 1205 well-behaved manner. 1207 12 IANA Considerations 1209 There are no IANA considerations associated with this specification. 1211 13 Acknowledgements 1213 The authors would like to thank Paul Kyzivat, Rohan Mahy, Eric 1214 Rescorla, Allison Mankin and Sriram Parameswar for their comments. 1216 14 Authors Addresses 1218 Jonathan Rosenberg 1219 dynamicsoft 1220 72 Eagle Rock Avenue 1221 First Floor 1222 East Hanover, NJ 07936 1223 US 1224 email: jdrosen@dynamicsoft.com 1226 Jon Peterson 1227 NeuStar, Inc. 1228 1800 Sutter St 1229 Suite 570 1230 Concord, CA 94520 1231 US 1232 EMail: jon.peterson@neustar.biz 1234 Henning Schulzrinne 1235 Columbia University 1236 M/S 0401 1237 1214 Amsterdam Ave. 1238 New York, NY 10027-7003 1239 US 1240 email: schulzrinne@cs.columbia.edu 1241 Gonzalo Camarillo 1242 Ericsson 1243 Advanced Signalling Research Lab. 1244 FIN-02420 Jorvas 1245 Finland 1246 Phone: +358 9 299 3371 1247 Fax: +358 9 299 3052 1248 Email: Gonzalo.Camarillo@ericsson.com 1250 15 Normative References 1252 [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 1253 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 1254 initiation protocol," RFC 3261, Internet Engineering Task Force, June 1255 2002. 1257 [2] "Integration of resource management and session initiation 1258 protocol (SIP)," RFC 3312, Internet Engineering Task Force, Oct. 1259 2002. 1261 [3] S. Bradner, "Key words for use in rfcs to indicate requirement 1262 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 1264 [4] J. Rosenberg and H. Schulzrinne, "An offer/answer model with 1265 session description protocol (SDP)," RFC 3264, Internet Engineering 1266 Task Force, June 2002. 1268 [5] H. Schulzrinne, D. Oran, and G. Camarillo, "The reason header 1269 field for the session initiation protocol (SIP)," RFC 3326, Internet 1270 Engineering Task Force, Dec. 2002. 1272 [6] J. Rosenberg and H. Schulzrinne, "Reliability of provisional 1273 responses in session initiation protocol (SIP)," RFC 3262, Internet 1274 Engineering Task Force, June 2002. 1276 [7] J. Rosenberg, "The session initiation protocol (SIP) UPDATE 1277 method," RFC 3311, Internet Engineering Task Force, Oct. 2002. 1279 16 Informative References 1281 [8] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a 1282 transport protocol for real-time applications," RFC 1889, Internet 1283 Engineering Task Force, Jan. 1996. 1285 [9] S. Petrack and L. Conroy, "The PINT service protocol: Extensions 1286 to SIP and SDP for IP access to telephone call services," RFC 2848, 1287 Internet Engineering Task Force, June 2000. 1289 [10] J. Arkko et al. , "MIKEY: multimedia Internet keying," internet 1290 draft, Internet Engineering Task Force, Feb. 2003. Work in progress. 1292 Intellectual Property Statement 1294 The IETF takes no position regarding the validity or scope of any 1295 intellectual property or other rights that might be claimed to 1296 pertain to the implementation or use of the technology described in 1297 this document or the extent to which any license under such rights 1298 might or might not be available; neither does it represent that it 1299 has made any effort to identify any such rights. Information on the 1300 IETF's procedures with respect to rights in standards-track and 1301 standards-related documentation can be found in BCP-11. Copies of 1302 claims of rights made available for publication and any assurances of 1303 licenses to be made available, or the result of an attempt made to 1304 obtain a general license or permission for the use of such 1305 proprietary rights by implementors or users of this specification can 1306 be obtained from the IETF Secretariat. 1308 The IETF invites any interested party to bring to its attention any 1309 copyrights, patents or patent applications, or other proprietary 1310 rights which may cover technology that may be required to practice 1311 this standard. Please address the information to the IETF Executive 1312 Director. 1314 Full Copyright Statement 1316 Copyright (c) The Internet Society (2003). All Rights Reserved. 1318 This document and translations of it may be copied and furnished to 1319 others, and derivative works that comment on or otherwise explain it 1320 or assist in its implementation may be prepared, copied, published 1321 and distributed, in whole or in part, without restriction of any 1322 kind, provided that the above copyright notice and this paragraph are 1323 included on all such copies and derivative works. However, this 1324 document itself may not be modified in any way, such as by removing 1325 the copyright notice or references to the Internet Society or other 1326 Internet organizations, except as needed for the purpose of 1327 developing Internet standards in which case the procedures for 1328 copyrights defined in the Internet Standards process must be 1329 followed, or as required to translate it into languages other than 1330 English. 1332 The limited permissions granted above are perpetual and will not be 1333 revoked by the Internet Society or its successors or assigns. 1335 This document and the information contained herein is provided on an 1336 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1337 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1338 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1339 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1340 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.