idnits 2.17.1 draft-ietf-sipping-sip-offeranswer-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.3 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 585. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 562. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 569. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 575. ** The document has an RFC 3978 Section 5.3 Publication Limitation clause. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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.) ** There are 164 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 29, 2006) is 6351 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) == Unused Reference: '5' is defined on line 531, but no explicit reference was found in the text Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group T. Sawada 3 Internet Draft KDDI Corporation 4 Expires: May 2006 P. Kyzivat 5 Cisco Systems, Inc. 6 November 29, 2006 8 SIP (Session Initiation Protocol) Usage of Offer/Answer Model 9 draft-ietf-sipping-sip-offeranswer-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that 14 any applicable patent or other IPR claims of which he or she is 15 aware have been or will be disclosed, and any of which he or she 16 becomes aware will be disclosed, in accordance with Section 6 of 17 BCP 79. 19 This document may only be posted in an Internet-Draft. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on May 29, 2006. 38 Abstract 40 SIP utilizes offer/answer model to establish and update multimedia 41 sessions. The descriptions on how to use offer/answer in SIP are 42 dispersed in the multiple RFCs. This document summarizes all the 43 current usage of offer/answer model in SIP communication. 45 Conventions used in this document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC-2119 [1]. 51 Table of Contents 53 1. Summary of SIP usage of Offer/Answer Model...................2 54 1.1. Offer/Answer Exchange Pairs in SIP Messages.............3 55 1.2. Rejection against an Offer..............................4 56 2. Detailed Discussion on Offer/Answer Model for SIP............5 57 2.1. Offer/Answer for INVITE method with 100rel extension....5 58 2.1.1. INVITE Request with SDP............................6 59 2.1.2. INVITE request without SDP.........................7 60 2.2. Offer/Answer Exchange in Early Dialog...................8 61 2.3. Offer/Answer Exchange in Established Dialog.............9 62 3. Exceptional Case Handling....................................9 63 3.1. Message Crossing Case Handling..........................9 64 3.2. Glare Case Handling....................................10 65 4. Add New Offer/Answer Usage in SIP...........................11 66 4.1. Explicit Usage.........................................11 67 4.2. Rejection against an Offer.............................11 68 4.3. Backward Compatibility.................................12 69 4.4. Exceptional Case Handling..............................12 70 5. Security Considerations.....................................12 71 6. References..................................................12 72 6.1. Normative References...................................12 73 Author's Addresses.............................................12 74 Intellectual Property Statement................................13 75 Disclaimer of Validity.........................................13 76 Copyright Statement............................................13 77 Acknowledgment.................................................14 79 1. Summary of SIP usage of Offer/Answer Model 81 Offer/answer model itself is independent from the higher layer 82 application protocols which utilize it. SIP is one of the 83 applications using offer/answer model. In RFC 3264 [4], which defines 84 offer/answer model, which SIP message should convey an offer or an 85 answer is not defined. This should be defined in the SIP core and 86 extensions RFCs. 88 In theory, any SIP message can include session description in its 89 body. But not all the session description in a SIP message is an 90 offer or an answer. Only the session description that conforms to the 91 rules described in the standard track RFCs can be interpreted as an 92 offer or an answer. The rules how to handle offer/answer model are 93 currently defined in several RFCs. Unless defined in an RFC 94 explicitly as an offer or an answer, except ones in non-reliable 95 provisional response to INVITE request, a session description should 96 not be included in SIP messages to avoid confusions. 98 Offer/answer model defines the update of sessions. In SIP, dialog is 99 used to match the offer/answer exchange to the session which is to be 100 updated with it. In other words, only the offer/answer exchange in 101 the SIP dialog can update the session which is managed with it. 103 1.1. Offer/Answer Exchange Pairs in SIP Messages 105 Currently, the rules on offer/answer model are defined in RFC 3261, 106 RFC 3262 and RFC 3311. In these RFCs, only the six patterns shown in 107 Table 1 are defined for exchanging an offer and an answer with SIP 108 messages. 110 Note that an offer/answer exchange initiated by an INVITE request 111 must follow exactly one of the patterns 1, 2, 3, 4. Only one of them, 112 one for each dialog if multiple dialogs are created, must occur in an 113 INVITE 3-way handshake process. Pattern 2 and pattern 4 can occur 114 only when INVITE request does not include an offer. 'The first 115 reliable non-failure message' must have an offer if there is no offer 116 in the INVITE request. This means that UA which receives the INVITE 117 request without an offer must include an offer in the first reliable 118 response with 100rel extension. If no reliable provisional response 119 has been sent, UAS must include an offer when sending 2xx response. 121 In pattern 3, the first reliable provisional response may or may not 122 have an answer. When a reliable provisional response contains a 123 session description, and is the first to do so, then that session 124 description is the answer to the offer in the INVITE request. 126 In pattern 5, PRACK request can contain an offer only if the non- 127 reliable response which it acknowledges contains an answer in the 128 previous offer/answer exchange. 130 Offer Answer RFC Ini Est Early 131 ------------------------------------------------------------------- 132 1. INVITE Req. 2xx INVITE Resp. RFC 3261 O O X 133 2. 2xx INVITE Resp. ACK Req. RFC 3261 O O X 134 3. INVITE Req. 1xx-rel INVITE Resp. RFC 3262 O O X 135 4. 1xx-rel INVITE Resp. PRACK Req. RFC 3262 O O X 136 5. PRACK Req. 200 PRACK Resp. RFC 3262 X O O 137 6. UPDATE Req. 2xx UPDATE Resp. RFC 3311 X O O 139 Table 1. Summary of SIP Usage of Offer/Answer Model 140 In Table 1, '1xx-rel' corresponds to the reliable provisional 141 response which applies 100rel option defined in RFC 3262 [3]. 143 'Ini' column shows the ability to exchange the offer/answer to 144 initiate the session. 'O' indicates that the pattern can be used in 145 the initial offer/answer exchange, while 'X' indicates that it can 146 not. Only the initial INVITE request can be used to exchange the 147 offer/answer to establish multimedia session. 149 'Est' column shows the ability to update the established session. 151 'Early' column shows the ability to be used to modify the established 152 session in an early dialog. There are two ways to exchange subsequent 153 offer/answer in an early dialog. 155 1.2. Rejection against an Offer 157 How to reject an offer when it can not be accepted is not so clear 158 and some method can not allow explicit rejection against an offer. 159 Corresponding to the patterns in Table 1, how to reject an offer is 160 shown in Table 2. 162 When a UA receives an INVITE request with an offer which it can not 163 accept, it should respond with a 488 response preferably with Warning 164 header field indicating the reason of the rejection unless other 165 response code is more appropriate to reject it. (Pattern 1 and 166 Pattern 3) 168 When a UA receives an UPDATE request with an offer which it can not 169 accept, it should respond with a 488 response preferably with Warning 170 header field indicating the reason of the rejection unless other 171 response code is more appropriate to reject it. (Pattern 6) 173 When a UA receives a PRACK request with an offer which it can not 174 accept, it may respond with a 200 response with a syntactically 175 correct session description followed by an UPDATE request possibly to 176 rearrange the session parameters if both ends support UPDATE method. 177 A UA may simply give up continuing the dialog and send error response 178 to INVITE request. (Pattern 5) 180 When a UA receives a response with an offer which it can not accept, 181 a UA does not have the way to reject it explicitly. Therefore, an UA 182 should respond to the offer with the correct session description and 183 rearrange the session parameters by initiating a new offer/answer 184 exchange. (Pattern 2 and Pattern 4) 185 Offer Rejection 186 ----------------------------------------------------- 187 1. INVITE Req. 488 INVITE Response 188 2. 2xx INVITE Resp. Answer in ACK Req. followed by new offer 189 3. INVITE Req. 488 INVITE Response (same as Pattern 1.) 190 4. 1xx-rel INVITE Resp. Answer in PRACK Req. followed by new offer 191 5. PRACK Req. (*) 200 PRACK Resp. followed by new offer 192 6. UPDATE Req. 488 UPDATE Response 194 Table 2. Rejection against an Offer 196 (*) UA should only use PRACK to send an offer when it has strong 197 reasons to assume the receiver will accept. 199 1.3. Session Description which is not Offer nor Answer 201 As it is stated, not all the session description in a SIP message is 202 an offer or an answer. For example, SIP can use the session 203 description to describe the capabilities apart from offer/answer 204 exchange. Examples of these messages are 200 OK responses for OPTIONS 205 and 488 responses for INVITE. 207 2. Detailed Discussion on Offer/Answer Model for SIP 209 2.1. Offer/Answer for INVITE method with 100rel extension 211 INVITE method is the basic procedure for offer/answer exchange in SIP. 212 Without 100rel option, the rules are simple as described in RFC 3261 213 [2]. If an INVITE request includes a session description, pattern 1 214 is applied and if an INVITE request does not include a session 215 description, pattern 2 is applied. 217 With 100rel, pattern 3 and pattern 4 are added and this makes the 218 rules complicated. An INVITE request may cause multiple responses. 219 Note that even if both UAs support 100rel extension, not all the 220 provisional responses are sent reliably. Note also that a reliable 221 provisional response is allowed not to include a session description 222 even when UAS does not send the answer yet. Unreliable provisional 223 response may include a session description in its body until an UAC 224 receives the answer, but its session description is not an offer nor 225 an answer. All the session descriptions in the unreliable responses 226 to the INVITE request must be identical to the answer which is 227 included in the reliable response. Session description in an 228 unreliable response that precedes a reliable response can be 229 considered a "preview" of the session description that will be coming, 230 and hence may be treated like an offer or an answer until the actual 231 one arrives. 233 2.1.1. INVITE Request with SDP 235 When UAC includes an SDP in the INVITE request as an offer, it 236 expects the answer to be received with one of the reliable responses. 237 Other than that, no offer/answer exchanges can occur in the INVITE 3- 238 way handshake process. 240 UAC UAS 241 | F1 INVITE (SDP) | <- The offer in offer/answer model 242 |-------------------->| 243 | F2 1xx (SDP) | <- The SDP is not an official answer but 244 |<--------------------| UAC act as if it receives the answer. 245 | | ^ 246 | F3 1xx-rel (no SDP) | |<- a 1xx-rel may be sent without answer 247 |<--------------------| | SDP. 248 | F4 PRACK (no SDP) | | 249 |-------------------->| | UAC must not send a new offer. 250 | F5 2xx PRA (no SDP) | | 251 |<--------------------| v 252 | | 253 | F6 1xx-rel (SDP) | <- The answer in offer/ answer model 254 |<--------------------| - 255 | F7 PRACK | | UAC can send a new offer in a PRACK 256 |-------------------->| | request to acknowledge F6. 257 | F8 2xx PRA | | After F6 UAC and UAS can send a new offer 258 |<--------------------| v in an UPDATE request. 259 | | 260 | F9 1xx-rel | <- SDP should not be included in the 261 |<--------------------| subsequent 1xx-rel once offer/answer 262 | F10 PRACK | has been completed. 263 |-------------------->| 264 | F11 2xx PRA | 265 |<--------------------| 266 | | 267 | F12 2xx INV | <- SDP should not be included in the final 268 |<--------------------| response once offer/answer has been 269 | F13 ACK | completed. 270 |-------------------->| 272 Figure 1 Example of Offer/Answer with 100rel Extension (1) 274 For example, in Figure 1, only the SDP in F6 is the answer. The SDP 275 in the non-reliable response (F3) must be the same as the answer in 276 F6 but is not the answer. Receiving F3, UAC should act as if it 277 receives the answer. However, offer/answer exchange is not completed 278 yet and UAC must not send a new offer until it receives the same SDP 279 in the first reliable response, which is the real answer. After 280 sending the SDP in F6, UAS must prepare to receive new offer from UAC 281 with an UPDATE request or a PRACK request. 283 UAS should not include an SDP in the responses F9 and F12. However, 284 UAC should prepare to receive an SDP in F9 and/or F12, and just 285 ignore them for the case that the peer does not conform to the 286 recommended implementation. 288 2.1.2. INVITE request without SDP 290 When UAC does not include an SDP in the INVITE request, it expects 291 the offer to be received with the first reliable response. UAC will 292 send the answer in the request to acknowledge the response, i.e. 293 PRACK request for the reliable response. Other than that, no 294 offer/answer exchanges can occur in the INVITE 3-way handshake 295 process. 297 For example, in Figure 2, only the SDP in F3 is the answer. The SDP 298 in the non-reliable response (F2) must be the same as the offer in F3 299 but is not the offer. Receiving F2, UAC can act as if it receives the 300 offer. However, the official offer is not received until it receives 301 the first reliable response. The first reliable response (F3) must 302 include an SDP as an offer. 304 UAS should not include an SDP in the responses F6 and F9. However, 305 UAC should prepare to receive an SDP in F6 and/or F9, and just ignore 306 them for the case that the peer does not conform to the recommended 307 implementation. 309 UAC UAS 310 | F1 INVITE (no SDP) | 311 |-------------------->| 312 | F2 1xx (SDP) | <- SDP may be included but it is not the 313 |<--------------------| offer. UAC may act as if it receives 314 | | the offer. 315 | F3 1xx-rel (SDP) | <- The first 1xx-rel must contain an SDP 316 |<--------------------| as the offer. 317 | F4 PRACK (SDP) | <- An PRACK request to the first 1xx-rel 318 |-------------------->| must contain an SDP as the answer. 319 | F5 2xx PRA (no SDP) | - 320 |<--------------------| | 321 | | | 322 | F6 1xx-rel (no SDP) | <- The subsequent 1xx-rel should not 323 |<--------------------| | contain an SDP. 324 | F7 PRACK | | 325 |-------------------->| | UAC can send a new offer in an UPDATE 326 | F8 2xx PRA | | request after F4. 327 |<--------------------| v 328 | | 329 | F9 2xx INV (no SDP) | <- The final response should not 330 |<--------------------| contain an SDP. 331 | F10 ACK | 332 |-------------------->| 334 Figure 2 Example of Offer/Answer with 100rel Extension (2) 336 2.2. Offer/Answer Exchange in Early Dialog 338 When both UAs support 100rel extension, they can update the session 339 in the early dialog once the first offer/answer exchange has been 340 completed. 342 From UA sending an INVITE request: 344 UA can send an UPDATE request with a new offer if both ends support 345 UPDATE method. Whether UPDATE method is supported must be declared in 346 Allow header in some prior messages in the dialog. 348 UA can send a PRACK request with a new offer when acknowledging the 349 reliable provisional response with the answer to the offer in the 350 INVITE request. Compared to UPDATE method, using PRACK can save 351 messages to be exchanged between the UAs. However, as a PRACK request 352 should not be rejected, UA is recommended to send a PRACK request 353 only when it has strong reasons to assume the receiver will accept it. 354 For example, the procedure used in precondition extension[6] is the 355 case that a PRACK request should be used for updating the session 356 status in the early dialog. 358 From UA receiving an INVITE request: 360 UA can send an UPDATE request with a new offer if both ends support 361 UPDATE method. UAS can not send new offer in the reliable provisional 362 response. So UPDATE method is the only method for UAS to update the 363 early session. 365 2.3. Offer/Answer Exchange in Established Dialog 367 Re-INVITE method and UPDATE method can be used in the established 368 dialog to update the session. 370 UPDATE method is simpler and can save at least one message compared 371 with INVITE method. But both ends must support UPDATE method to use 372 UPDATE. 374 INVITE method needs at least three messages to complete but no 375 extensions are needed. Additionally, INVITE method allows the peer to 376 take time to decide whether it accept session update or not by 377 sending provisional responses. That is, re-INVITE allows the UAS to 378 interact with the user at the peer, while UPDATE needs to be answered 379 automatically by the UAS. It is noted that re-INVITE should be 380 answered immediately unless such a user interaction is needed. 381 Otherwise, some 3pcc flows would break. 383 3. Exceptional Case Handling 385 In RFC 3264 [4], the following restrictions are defined with regard 386 to sending a new offer. 388 "It MUST NOT generate a new offer if it has received an offer 389 which it has not yet answered or rejected. It MUST NOT generate a 390 new offer if it has generated a prior offer for which it has not 391 yet received an answer or a rejection." 393 Assuming that the above rules are guaranteed, there seems to be two 394 possible 'exceptional' cases to be considered in SIP offer/answer 395 usage, which are 'message crossing' case and 'glare' case. One of the 396 reasons why the usage of a SIP method to exchange offer/answer needs 397 to be carefully restricted in the RFCs is to make sure that UA can 398 detect and handle appropriately the 'exceptional' cases to avoid the 399 confusion. 401 3.1. Message Crossing Case Handling 403 When message packets are crossed in the transport network, an offer 404 may reach before the answer for the previous offer/answer exchange as 405 described in Figure 3. In such a case, UA A must detect the session 406 description of the offer2 is not the answer to the offer1. 408 A B 409 |offer1 | 410 |----------------->| 411 | answer1| 412 |<------\ /-------| 413 | \/ | 414 | /\ offer2| 415 |<------/ \-------| 417 Figure 3 Message Crossing Case 419 When offer2 is in an UPDATE request or a re-INVITE request, a session 420 description can never be the answer. Then UA A must reject the 421 message including offer2 with a 500 response with Retry-After header 422 field. 424 When offer2 is in a PRACK request, that is, when PRACK request to 425 acknowledge the reliable provisional response with an answer to the 426 offer in the INVITE request contains a session description, UA A 427 knows it is an offer. As a PRACK request should not be rejected, UA A 428 is recommended to wait for the answer1 until sending a PRACK response 429 with the answer to the offer2. Note that if UA A does not send a new 430 offer until the reliable provisional response with an answer to the 431 offer in the INVITE request is acknowledged with a PRACK request, 432 this case never happens. Therefore, to make implementations simple, a 433 UA acting as a UAS for INVITE transaction is recommended not to send 434 a UPDATE request with an offer until the reliable response with an 435 answer to the offer in the INVITE request is acknowledged with PRACK 436 request. 438 When offer2 is in a reliable provisional response or a successful 439 final response, UA A knows it is not the answer to the offer1. For a 440 reliable response to an initial INVITE request, this case never 441 happens. For a reliable response to a re-INVITE request, UA A can 442 detect the offer2 is not the answer1. In this case, UA A can not 443 reject offer2 in a reliable response, it is recommended to wait for 444 the answer1 until sending a PRACK request with the answer to the 445 offer2. Note that if UA A does not send an INVITE request without 446 session description if it has sent the offer which has not yet 447 received the answer to it, this case never happens. 449 3.2. Glare Case Handling 451 When both ends in a dialog send an offer at nearly the same time, UA 452 may receive a new offer before it receives the answer to the offer 453 itsends as described in Figure 4. This case is called 'glare' case in 454 general. 456 A B 457 |offer1 offer2| 458 |-------\ /-------| 459 | \/ | 460 | /\ | 461 |<------/ \------>| 463 Figure 4 Glare Case 465 When offer2 is in an UPDATE request or (re-)INVITE request, it must 466 be rejected with a 491 response. 468 When offer2 is in a PRACK request, it may be accepted with 200 or may 469 be rejected with a 491 response. A 491 response may be adequate for 470 offer/answer model but it may delay the completion of the reliable 471 response transfer mechanism or, in worst case, may result in the 472 failure to complete SIP transaction because there is no clear retry 473 rule when a PRACK request is rejected with a 491 response. To avoid 474 this glare condition, UA is recommended not to send an offer, which 475 currently must be in an UPDATE request, if it has generated the 476 reliable provisional response with the answer to the offer in the 477 INVITE request which is not acknowledged with a PRACK request. 479 To avoid glare condition for offer2 in the response, UA A is 480 recommended not to send a new offer if it has generated (re)INVITE 481 request without session description which it has not received the 482 reliable response with the offer. 484 4. Add New Offer/Answer Usage in SIP 486 It is not recommended to add new SIP methods for the offer/answer 487 exchange beyond the ways described in this document. However, it may 488 be requested to have new offer/answer exchange methods as SIP 489 extensions evolve. In this clause, what should be taken into 490 considerations is noted in this section. 492 4.1. Explicit Usage 494 New method should define the usage explicitly without any ambiguity. 496 4.2. Rejection against an Offer 498 New method should define how to reject an offer where possible. 500 4.3. Backward Compatibility 502 New method must keep backward compatibility. 504 4.4. Exceptional Case Handling 506 New method should take care of how to handle exceptional cases, 507 message crossing case and glare case. 509 5. Security Considerations 511 There are not any security issues beyond the referenced RFCs. 513 6. References 515 6.1. Normative References 517 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 518 Levels", BCP 14, RFC 2119, March 1997. 520 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 521 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 522 Session Initiation Protocol", RFC 3261, June 2002. 524 [3] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 525 Responses in the Session Initiation Protocol (SIP)", RFC 3262, 526 June 2002. 528 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 529 SDP", RFC 3264, June 2002. 531 [5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 532 Method", RFC 3311, September 2002. 534 [6] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of 535 Resource Management and Session Initiation Protocol (SIP)", RFC 536 3312, October 2002. 538 Author's Addresses 540 Takuya Sawada 541 KDDI Corporation 542 3-10-10, Iidabashi, Chiyoda-ku, Tokyo, Japan 544 Email: tu-sawada@kddi.com 545 Paul H. Kyzivat 546 Cisco Systems, Inc. 547 1414 Massachusetts Avenue 548 Boxborough, MA 01719 549 USA 551 Email: pkyzivat@cisco.com 553 Intellectual Property Statement 555 The IETF takes no position regarding the validity or scope of any 556 Intellectual Property Rights or other rights that might be claimed to 557 pertain to the implementation or use of the technology described in 558 this document or the extent to which any license under such rights 559 might or might not be available; nor does it represent that it has 560 made any independent effort to identify any such rights. Information 561 on the procedures with respect to rights in RFC documents can be 562 found in BCP 78 and BCP 79. 564 Copies of IPR disclosures made to the IETF Secretariat and any 565 assurances of licenses to be made available, or the result of an 566 attempt made to obtain a general license or permission for the use of 567 such proprietary rights by implementers or users of this 568 specification can be obtained from the IETF on-line IPR repository at 569 http://www.ietf.org/ipr. 571 The IETF invites any interested party to bring to its attention any 572 copyrights, patents or patent applications, or other proprietary 573 rights that may cover technology that may be required to implement 574 this standard. Please address the information to the IETF at 575 ietf-ipr@ietf.org. 577 Disclaimer of Validity 579 This document and the information contained herein are provided on an 580 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 581 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 582 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 583 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 584 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 585 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 587 Copyright Statement 589 Copyright (C) The Internet Society (2006). 591 This document is subject to the rights, licenses and restrictions 592 contained in BCP 78, and except as set forth therein, the authors 593 retain all their rights. 595 Acknowledgment 597 Funding for the RFC Editor function is currently provided by the 598 Internet Society.