📄 rfc2976.txt
字号:
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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -