summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2976.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2976.txt')
-rw-r--r--doc/rfc/rfc2976.txt507
1 files changed, 507 insertions, 0 deletions
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]
+