idnits 2.17.1 draft-ietf-sip-info-method-05.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- 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 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 149: '...s an INFO request it MUST send a final...' RFC 2119 keyword, line 152: '... 200 OK response MUST be sent by a UAS...' RFC 2119 keyword, line 190: '...Does Not Exist message MUST be sent by...' RFC 2119 keyword, line 195: '...e body, the body MAY be rendered and d...' RFC 2119 keyword, line 200: '...body, the server MUST respond with a 4...' (7 more instances...) 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 normative reference: RFC 2543 (ref. '1') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Steve Donovan 2 draft-ietf-sip-info-method-05.txt dynamicsoft 3 January, 2001 5 The SIP INFO Method 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that other 14 groups may also distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/lid-abstracts.txt. 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Abstract 29 This document proposes an extension to the Session Initiation 30 Protocol (SIP). This extension adds the INFO method to the SIP 31 protocol. The intent of the INFO method is to allow for the carrying 32 of session related control information that is generated during a 33 session. One example of such session control information is ISUP and 34 ISDN signaling messages used to control telephony call services. 36 This and other example uses of the INFO method may be standardized in 37 the future. 39 Table of Contents 41 1 Introduction................................................3 42 1.1 Example Uses................................................3 43 2 INFO Method.................................................4 44 2.1 Header Field Support for INFO Method........................4 45 2.2 Responses to the INFO Request Method........................4 46 2.3 Message Body Inclusion......................................6 47 2.4 Behavior of SIP User Agents.................................6 48 2.5 Behavior of SIP Proxy and Redirect Servers..................7 49 2.5.1 Proxy Server................................................7 50 2.5.2 Forking Proxy Server........................................7 51 2.5.3 Redirection Server..........................................7 52 3. INFO Message Bodies.........................................7 53 4. Guidelines for extensions making use of INFO................8 54 5. Security Considerations.....................................7 55 6. References..................................................8 56 7. Acknowledgments.............................................9 57 8. Author's Address............................................9 58 Full Copyright Statement...................................10 60 1. Introduction 62 The SIP protocol described in [1] defines session control messages 63 used during the setup and tear down stages of a SIP controlled 64 session. 66 In addition, the SIP re-INVITE can be used during a session to change 67 the characteristics of the session. This is generally to change the 68 properties of media flows related to the session or to update the SIP 69 session timer. 71 However, there is no general-purpose mechanism to carry session 72 control information along the SIP signaling path during the session. 74 The purpose of the INFO message is to carry application level 75 information along the SIP signaling path. 77 The INFO method is not used to change the state of SIP calls, or the 78 parameters of the sessions SIP initiates. It merely sends optional 79 application layer information, generally related to the session. 81 It is necessary that the mid-session signaling information traverse 82 the post session setup SIP signaling path. This is the path taken by 83 SIP re-INVITEs, BYEs and other SIP requests that are tied to an 84 individual session. This allows SIP proxy servers to receive, and 85 potentially act on, the mid-session signaling information. 87 This document proposes an extension to SIP by defining the new INFO 88 method. The INFO method would be used for the carrying of mid-call 89 signaling information along the session signaling path. 91 1.1 Example Uses 93 The following are a few of the potential uses of the INFO message: 95 - Carrying mid-call PSTN signaling messages between PSTN 96 gateways. 98 - Carrying DTMF digits generated during a SIP session. 100 - Carrying wireless signal strength information in support of 101 wireless mobility applications. 103 - Carrying account balance information. 105 - Carrying images or other non streaming information between the 106 participants of a session. 108 These are just potential uses; this document does not specify such 109 uses nor does it necessarily recommend them. 111 It can also be envisioned that there will be other telephony and 112 non-telephony uses of the INFO method. 114 2. INFO Method 116 The INFO method is used for communicating mid-session signaling 117 information along the signaling path for the call. 119 The INFO method is not used to change the state of SIP calls, nor 120 does it change the state of sessions initiated by SIP. Rather, it 121 provides additional optional information which can further enhance 122 the application using SIP. 124 The signaling path for the INFO method is the signaling path 125 established as a result of the call setup. This can be either direct 126 signaling between the calling and called user agents or a signaling 127 path involving SIP proxy servers that were involved in the call setup 128 and added themselves to the Record-Route header on the initial INVITE 129 message. 131 The mid-session information can be communicated in either an INFO 132 message header or as part of a message body. The definition of the 133 message body and/or message headers used to carry the mid-session 134 information is outside the scope of this document. 136 There are no specific semantics associated with INFO. The semantics 137 are derived from the body or new headers defined for usage in INFO. 139 2.1 Header Field Support for INFO Method 141 Tables 1 and 2 add a column to tables 4 and 5 in the [1]. Refer 142 to Section 6 of [1] for a description of the content of the 143 tables. Note that the rules defined in the enc. and e-e columns 144 in tables 4 and 5 in [1] also apply to use of the headers in the 145 INFO request and responses to the INFO request. 147 2.2 Responses to the INFO Request Method 149 If a server receives an INFO request it MUST send a final 150 response. 152 A 200 OK response MUST be sent by a UAS for an INFO request with 153 no message body if the INFO request was successfully received for 154 an existing call. Beyond that, no additional operations are 155 required. 157 Header Where INFO 158 ------ ----- ---- 159 Accept R o 160 Accept-Encoding R o 161 Accept-Language R o 162 Allow 200 - 163 Allow 405 o 164 Authorization R o 165 Call-ID gc m 166 Contact R o 167 Contact 1xx - 168 Contact 2xx - 169 Contact 3xx - 170 Contact 485 - 171 Content-Encoding e o 172 Content-Length e o 173 Content-Type e * 174 CSeq gc m 175 Date g o 176 Encryption g o 177 Expires g o 178 From gc m 179 Hide R o 180 Max-Forwards R o 181 Organization g o 183 Table 1 Summary of header fields, A-0 185 Handling of INFO messages that contain message bodies is outside 186 the scope of this document. The documents defining the message 187 bodies will also need to define the SIP protocol rules associated 188 with those message bodies. 190 A 481 Call Leg/Transaction Does Not Exist message MUST be sent by 191 a UAS if the INFO request does not match any existing call leg. 193 If a server receives an INFO request with a body it understands, 194 but it has no knowledge of INFO associated processing rules for 195 the body, the body MAY be rendered and displayed to the user. The 196 INFO is responded to with a 200 OK. 198 If the INFO request contains a body that the server does not 199 understand then, in the absence of INFO associated processing 200 rules for the body, the server MUST respond with a 415 Unsupported 201 Media Type message. 203 Header Where INFO 204 ------ ----- ---- 205 Priority R o 206 Proxy-Authenticate 407 o 207 Proxy-Authorization R o 208 Proxy-Require R o 209 Require R o 210 Retry-After R - 211 Retry-After 404,480,486 o 212 Retry-After 503 o 213 Retry-After 600,603 o 214 Response-Key R o 215 Record-Route R o 216 Record-Route 2xx o 217 Route R o 218 Server r o 219 Subject R o 220 Timestamp g o 221 To gc(1) m 222 Unsupported 420 o 223 User-Agent g o 224 Via gc(2) m 225 Warning r o 226 WWW-Authenticate 401 o 228 Table 2 Summary of header fields, P-Z 230 Bodies which imply a change in the SIP call state or the sessions 231 initiated by SIP MUST NOT be sent in an INFO message. 233 Other request failure (4xx), Server Failure (5xx) and Global 234 Failure (6xx) responses MAY be sent for the INFO Request. 236 2.3 Message Body Inclusion 238 The INFO request MAY contain a message body. 240 2.4 Behavior of SIP User Agents 242 Unless stated otherwise, the protocol rules for the INFO request 243 governing the usage of tags, Route and Record-Route, 244 retransmission and reliability, CSeq incrementing and message 245 formatting follow those in [1] as defined for the BYE request. 247 An INFO request MAY be cancelled. A UAS receiving a CANCEL for an 248 INFO request SHOULD respond to the INFO with a "487 Request 249 Cancelled" response if a final response has not been sent to the 250 INFO and then behave as if the request were never received. 252 However, the INFO message MUST NOT change the state of the SIP 253 call, or the sessions initiated by SIP. 255 2.5 Behavior of SIP Proxy and Redirect Servers 257 2.5.1 Proxy Server 259 Unless stated otherwise, the protocol rules for the INFO 260 request at a proxy are identical to those for a BYE request as 261 specified in [1]. 263 2.5.2 Forking Proxy Server 265 Unless stated otherwise, the protocol rules for the INFO 266 request at a proxy are identical to those for a BYE request as 267 specified in [1]. 269 2.5.3 Redirection Server 271 Unless stated otherwise, the protocol rules for the INFO 272 request at a proxy are identical to those for a BYE request as 273 specified in [1]. 275 3. INFO Message Bodies 277 The purpose of the INFO message is to carry mid-session information 278 between SIP user agents. This information will generally be carried 279 in message bodies, although it can be carried in headers in the INFO 280 message. 282 The definition of the message bodies or any new headers created for 283 the INFO method is outside the scope of this document. It is 284 expected that separate documents will be created to address 285 definition of these entities. 287 In addition, the INFO method does not define additional mechanisms 288 for ensuring in-order delivery. While the CSeq header will be 289 incremented upon the transmission of new INFO messages, this should 290 not be used to determine the sequence of INFO information. This is 291 due to the fact that there could be gaps in the INFO message CSeq 292 count caused by a user agent sending re-INVITES or other SIP 293 messages. 295 4. Guidelines for extensions making use of INFO 297 The following are considerations that should be taken into account 298 when defining SIP extensions that make use of the INFO method. 300 - Consideration should be taken on the size of message bodies to be 301 carried by INFO messages. The message bodies should be kept small 302 due to the potential for the message to be carried over UDP and the 303 potential for fragmentation of larger messages. 305 - There is potential that INFO messages could be forked by a SIP 306 Proxy Server. The implications of this forking of the information 307 in the INFO message need to be taken into account. 309 - The use of multi-part message bodies may be helpful when defining 310 the message bodies to be carried by the INFO message. 312 - The extensions that use the INFO message MUST NOT rely on the 313 INFO message to do anything that effects the SIP call state or the 314 state of related sessions. 316 - The INFO extension defined in this document does not depend on 317 the use of the Require or Proxy-Require headers. Extensions using 318 the INFO message may need the use of these mechanisms. However, 319 the use of Require and Proxy-Require should be avoided, if 320 possible, in order to improve interoperability between SIP 321 entities. 323 5. Security Considerations 325 If the contents of the message body are private then end-to-end 326 encryption of the message body can be used to prevent unauthorized 327 access to the content. 329 There are no other security issues specific to the INFO method. 330 The security requirements specified in the SIP specification apply 331 to the INFO method. 333 6. References 335 [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, 336 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 338 7. Acknowledgements 340 The author would like to thank Matthew Cannon for his contributions 341 to this document. In addition, the author would like to thank the 342 members of the MMUSIC and SIP working groups, especially Jonathan 343 Rosenberg, for comments and suggestions on how to improve the 344 document. 346 8. Author's Address 348 Steve Donovan 349 dynamicsoft 350 5400 LBJ, Suite 400 351 Dallas, Texas 75240 352 Email: sdonovan@dynamicsoft.com 354 Full Copyright Statement 356 Copyright (C) The Internet Society (2000). All Rights Reserved. 358 This document and translations of it may be copied and furnished to 359 others, and derivative works that comment on or otherwise explain it 360 or assist in its implementation may be prepared, copied, published 361 and distributed, in whole or in part, without restriction of any 362 kind, provided that the above copyright notice and this paragraph are 363 included on all such copies and derivative works. However, this 364 document itself may not be modified in any way, such as by removing 365 the copyright notice or references to the Internet Society or other 366 Internet organizations, except as needed for the purpose of 367 developing Internet standards in which case the procedures for 368 copyrights defined in the Internet Standards process must be 369 followed, or as required to translate it into languages other than 370 English. 372 The limited permissions granted above are perpetual and will not be 373 revoked by the Internet Society or its successors or assigns. 375 This document and the information contained herein is provided on an 376 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 377 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 378 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 379 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 380 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.