📄 rfc2976.txt
字号:
Network Working Group S. DonovanRequest for Comments: 2976 dynamicsoftCategory: Standards Track October 2000 The SIP INFO MethodStatus 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..................................................8Donovan Standards Track [Page 1]RFC 2976 SIP INFO Method October 2000 7. Acknowledgments.............................................8 8. Author's Address............................................8 Full Copyright Statement....................................91. 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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -