From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2976.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc2976.txt (limited to 'doc/rfc/rfc2976.txt') diff --git a/doc/rfc/rfc2976.txt b/doc/rfc/rfc2976.txt new file mode 100644 index 0000000..11a226a --- /dev/null +++ b/doc/rfc/rfc2976.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group S. Donovan +Request for Comments: 2976 dynamicsoft +Category: Standards Track October 2000 + + + The SIP INFO Method + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + This document proposes an extension to the Session Initiation + Protocol (SIP). This extension adds the INFO method to the SIP + protocol. The intent of the INFO method is to allow for the carrying + of session related control information that is generated during a + session. One example of such session control information is ISUP and + ISDN signaling messages used to control telephony call services. + + This and other example uses of the INFO method may be standardized in + the future. + +Table of Contents + + 1 Introduction................................................2 + 1.1 Example Uses................................................2 + 2 INFO Method.................................................3 + 2.1 Header Field Support for INFO Method........................3 + 2.2 Responses to the INFO Request Method........................4 + 2.3 Message Body Inclusion......................................5 + 2.4 Behavior of SIP User Agents.................................6 + 2.5 Behavior of SIP Proxy and Redirect Servers..................6 + 2.5.1 Proxy Server................................................6 + 2.5.2 Forking Proxy Server........................................6 + 2.5.3 Redirection Server..........................................6 + 3. INFO Message Bodies.........................................6 + 4. Guidelines for extensions making use of INFO................7 + 5. Security Considerations.....................................7 + 6. References..................................................8 + + + +Donovan Standards Track [Page 1] + +RFC 2976 SIP INFO Method October 2000 + + + 7. Acknowledgments.............................................8 + 8. Author's Address............................................8 + Full Copyright Statement....................................9 + +1. Introduction + + The SIP protocol described in [1] defines session control messages + used during the setup and tear down stages of a SIP controlled + session. + + In addition, the SIP re-INVITE can be used during a session to change + the characteristics of the session. This is generally to change the + properties of media flows related to the session or to update the SIP + session timer. + + However, there is no general-purpose mechanism to carry session + control information along the SIP signaling path during the session. + + The purpose of the INFO message is to carry application level + information along the SIP signaling path. + + The INFO method is not used to change the state of SIP calls, or the + parameters of the sessions SIP initiates. It merely sends optional + application layer information, generally related to the session. + + It is necessary that the mid-session signaling information traverse + the post session setup SIP signaling path. This is the path taken by + SIP re-INVITEs, BYEs and other SIP requests that are tied to an + individual session. This allows SIP proxy servers to receive, and + potentially act on, the mid-session signaling information. + + This document proposes an extension to SIP by defining the new INFO + method. The INFO method would be used for the carrying of mid-call + signaling information along the session signaling path. + + 1.1 Example Uses + + The following are a few of the potential uses of the INFO message: + + - Carrying mid-call PSTN signaling messages between PSTN + gateways. + + - Carrying DTMF digits generated during a SIP session. + + - Carrying wireless signal strength information in support of + wireless mobility applications. + + - Carrying account balance information. + + + +Donovan Standards Track [Page 2] + +RFC 2976 SIP INFO Method October 2000 + + + - Carrying images or other non streaming information between the + participants of a session. + + These are just potential uses; this document does not specify such + uses nor does it necessarily recommend them. + + It can also be envisioned that there will be other telephony and + non-telephony uses of the INFO method. + +2. INFO Method + + The INFO method is used for communicating mid-session signaling + information along the signaling path for the call. + + The INFO method is not used to change the state of SIP calls, nor + does it change the state of sessions initiated by SIP. Rather, it + provides additional optional information which can further enhance + the application using SIP. + + The signaling path for the INFO method is the signaling path + established as a result of the call setup. This can be either direct + signaling between the calling and called user agents or a signaling + path involving SIP proxy servers that were involved in the call setup + and added themselves to the Record-Route header on the initial INVITE + message. + + The mid-session information can be communicated in either an INFO + message header or as part of a message body. The definition of the + message body and/or message headers used to carry the mid-session + information is outside the scope of this document. + + There are no specific semantics associated with INFO. The semantics + are derived from the body or new headers defined for usage in INFO. + + 2.1 Header Field Support for INFO Method + + Tables 1 and 2 add a column to tables 4 and 5 in the [1]. Refer + to Section 6 of [1] for a description of the content of the + tables. Note that the rules defined in the enc. and e-e columns + in tables 4 and 5 in [1] also apply to use of the headers in the + INFO request and responses to the INFO request. + + + + + + + + + + +Donovan Standards Track [Page 3] + +RFC 2976 SIP INFO Method October 2000 + + + 2.2 Responses to the INFO Request Method + + If a server receives an INFO request it MUST send a final + response. + + A 200 OK response MUST be sent by a UAS for an INFO request with + no message body if the INFO request was successfully received for + an existing call. Beyond that, no additional operations are + required. + + Header Where INFO + ------ ----- ---- + Accept R o + Accept-Encoding R o + Accept-Language R o + Allow 200 - + Allow 405 o + Authorization R o + Call-ID gc m + Contact R o + Contact 1xx - + Contact 2xx - + Contact 3xx - + Contact 485 - + Content-Encoding e o + Content-Length e o + Content-Type e * + CSeq gc m + Date g o + Encryption g o + Expires g o + From gc m + Hide R o + Max-Forwards R o + Organization g o + + Table 1 Summary of header fields, A-0 + + Handling of INFO messages that contain message bodies is outside + the scope of this document. The documents defining the message + bodies will also need to define the SIP protocol rules associated + with those message bodies. + + A 481 Call Leg/Transaction Does Not Exist message MUST be sent by + a UAS if the INFO request does not match any existing call leg. + + + + + + +Donovan Standards Track [Page 4] + +RFC 2976 SIP INFO Method October 2000 + + + If a server receives an INFO request with a body it understands, + but it has no knowledge of INFO associated processing rules for + the body, the body MAY be rendered and displayed to the user. The + INFO is responded to with a 200 OK. + + If the INFO request contains a body that the server does not + understand then, in the absence of INFO associated processing + rules for the body, the server MUST respond with a 415 Unsupported + Media Type message. + + Header Where INFO + ------ ----- ---- + Priority R o + Proxy-Authenticate 407 o + Proxy-Authorization R o + Proxy-Require R o + Require R o + Retry-After R - + Retry-After 404,480,486 o + Retry-After 503 o + Retry-After 600,603 o + Response-Key R o + Record-Route R o + Record-Route 2xx o + Route R o + Server r o + Subject R o + Timestamp g o + To gc(1) m + Unsupported 420 o + User-Agent g o + Via gc(2) m + Warning r o + WWW-Authenticate 401 o + + Table 2 Summary of header fields, P-Z + + Bodies which imply a change in the SIP call state or the sessions + initiated by SIP MUST NOT be sent in an INFO message. + + Other request failure (4xx), Server Failure (5xx) and Global + Failure (6xx) responses MAY be sent for the INFO Request. + + 2.3 Message Body Inclusion + + The INFO request MAY contain a message body. + + + + + +Donovan Standards Track [Page 5] + +RFC 2976 SIP INFO Method October 2000 + + + 2.4 Behavior of SIP User Agents + + Unless stated otherwise, the protocol rules for the INFO request + governing the usage of tags, Route and Record-Route, + retransmission and reliability, CSeq incrementing and message + formatting follow those in [1] as defined for the BYE request. + + An INFO request MAY be cancelled. A UAS receiving a CANCEL for an + INFO request SHOULD respond to the INFO with a "487 Request + Cancelled" response if a final response has not been sent to the + INFO and then behave as if the request were never received. + + However, the INFO message MUST NOT change the state of the SIP + call, or the sessions initiated by SIP. + + 2.5 Behavior of SIP Proxy and Redirect Servers + + 2.5.1 Proxy Server + + Unless stated otherwise, the protocol rules for the INFO + request at a proxy are identical to those for a BYE request as + specified in [1]. + + 2.5.2 Forking Proxy Server + + Unless stated otherwise, the protocol rules for the INFO + request at a proxy are identical to those for a BYE request as + specified in [1]. + + 2.5.3 Redirection Server + + Unless stated otherwise, the protocol rules for the INFO + request at a proxy are identical to those for a BYE request as + specified in [1]. + +3. INFO Message Bodies + + The purpose of the INFO message is to carry mid-session information + between SIP user agents. This information will generally be carried + in message bodies, although it can be carried in headers in the INFO + message. + + The definition of the message bodies or any new headers created for + the INFO method is outside the scope of this document. It is + expected that separate documents will be created to address + definition of these entities. + + + + + +Donovan Standards Track [Page 6] + +RFC 2976 SIP INFO Method October 2000 + + + In addition, the INFO method does not define additional mechanisms + for ensuring in-order delivery. While the CSeq header will be + incremented upon the transmission of new INFO messages, this should + not be used to determine the sequence of INFO information. This is + due to the fact that there could be gaps in the INFO message CSeq + count caused by a user agent sending re-INVITES or other SIP + messages. + +4. Guidelines for extensions making use of INFO + + The following are considerations that should be taken into account + when defining SIP extensions that make use of the INFO method. + + - Consideration should be taken on the size of message bodies to be + carried by INFO messages. The message bodies should be kept small + due to the potential for the message to be carried over UDP and the + potential for fragmentation of larger messages. + + - There is potential that INFO messages could be forked by a SIP + Proxy Server. The implications of this forking of the information + in the INFO message need to be taken into account. + + - The use of multi-part message bodies may be helpful when defining + the message bodies to be carried by the INFO message. + + - The extensions that use the INFO message MUST NOT rely on the + INFO message to do anything that effects the SIP call state or the + state of related sessions. + + - The INFO extension defined in this document does not depend on + the use of the Require or Proxy-Require headers. Extensions using + the INFO message may need the use of these mechanisms. However, + the use of Require and Proxy-Require should be avoided, if + possible, in order to improve interoperability between SIP + entities. + +5. Security Considerations + + If the contents of the message body are private then end-to-end + encryption of the message body can be used to prevent unauthorized + access to the content. + + There are no other security issues specific to the INFO method. + The security requirements specified in the SIP specification apply + to the INFO method. + + + + + + +Donovan Standards Track [Page 7] + +RFC 2976 SIP INFO Method October 2000 + + +6. References + + [1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, + "SIP: Session Initiation Protocol", RFC 2543, March 1999. + +7. Acknowledgements + + The author would like to thank Matthew Cannon for his contributions + to this document. In addition, the author would like to thank the + members of the MMUSIC and SIP working groups, especially Jonathan + Rosenberg, for comments and suggestions on how to improve the + document. + +8. Author's Address + + Steve Donovan + dynamicsoft + 5100 Tennyson Parkway, Suite 200 + Plano, Texas 75024 + + Email: sdonovan@dynamicsoft.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Donovan Standards Track [Page 8] + +RFC 2976 SIP INFO Method October 2000 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Donovan Standards Track [Page 9] + -- cgit v1.2.3