Network Working Group S. Donovan
Request for Comments: 2976 dynamicsoft
Category: Standards Track October 2000
Network Working Group S. Donovan
Request for Comments: 2976 dynamicsoft
Category: Standards Track October 2000
The SIP INFO Method
SIP-INFO方法
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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.
本文档建议对会话启动协议（SIP）进行扩展。此扩展将INFO方法添加到SIP协议中。INFO方法的目的是允许携带会话期间生成的会话相关控制信息。这种会话控制信息的一个例子是用于控制电话呼叫服务的ISUP和ISDN信令消息。
This and other example uses of the INFO method may be standardized in the future.
INFO方法的这个和其他示例使用可能在将来被标准化。
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
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
7. Acknowledgments.............................................8
8. Author's Address............................................8
Full Copyright Statement....................................9
7. Acknowledgments.............................................8
8. Author's Address............................................8
Full Copyright Statement....................................9
The SIP protocol described in [1] defines session control messages used during the setup and tear down stages of a SIP controlled session.
[1]中描述的SIP协议定义了在SIP控制会话的设置和中断阶段使用的会话控制消息。
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.
此外，SIP重新邀请可在会话期间用于更改会话的特征。这通常用于更改与会话相关的媒体流的属性或更新SIP会话计时器。
However, there is no general-purpose mechanism to carry session control information along the SIP signaling path during the session.
然而，在会话期间，没有通用机制沿着SIP信令路径携带会话控制信息。
The purpose of the INFO message is to carry application level information along the SIP signaling path.
INFO消息的目的是沿着SIP信令路径传送应用程序级信息。
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.
INFO方法不用于更改SIP调用的状态或SIP发起的会话的参数。它只发送可选的应用层信息，通常与会话相关。
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.
中间会话信令信息必须穿过会话后设置SIP信令路径。这是SIP重新邀请、是和其他绑定到单个会话的SIP请求所采用的路径。这允许SIP代理服务器接收并可能对会话中期信令信息进行操作。
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.
本文通过定义新的INFO方法，提出了对SIP的扩展。INFO方法将用于沿会话信令路径承载中间呼叫信令信息。
1.1 Example Uses
1.1 示例使用
The following are a few of the potential uses of the INFO message:
以下是信息消息的一些潜在用途：
- Carrying mid-call PSTN signaling messages between PSTN gateways.
- 在PSTN网关之间承载呼叫中PSTN信令消息。
- Carrying DTMF digits generated during a SIP session.
- 承载SIP会话期间生成的DTMF数字。
- Carrying wireless signal strength information in support of wireless mobility applications.
- 携带无线信号强度信息以支持无线移动应用。
- Carrying account balance information.
- 携带帐户余额信息。
- 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.
还可以设想，INFO方法还有其他电话和非电话用途。
The INFO method is used for communicating mid-session signaling information along the signaling path for the call.
INFO方法用于沿呼叫的信令路径传送中间会话信令信息。
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.
INFO方法不用于更改SIP调用的状态，也不更改SIP发起的会话的状态。相反，它提供了额外的可选信息，可以进一步增强使用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.
INFO方法的信令路径是作为呼叫设置的结果而建立的信令路径。这可以是呼叫和被叫用户代理之间的直接信令，也可以是涉及SIP代理服务器的信令路径，SIP代理服务器参与呼叫设置并将其自身添加到初始INVITE消息上的记录路由头中。
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.
没有与信息关联的特定语义。语义来自为在INFO中使用而定义的正文或新标题。
2.1 Header Field Support for INFO Method
2.1 对INFO方法的标题字段支持
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.
表1和表2在[1]中的表4和表5中添加了一列。有关表格内容的说明，请参阅[1]第6节。请注意，[1]中表4和表5的enc.和e-e列中定义的规则也适用于信息请求和信息请求响应中标题的使用。
2.2 Responses to the INFO Request Method
2.2 对信息请求方法的响应
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.
如果成功接收到现有呼叫的信息请求，UAS必须为没有消息正文的信息请求发送200 OK响应。除此之外，不需要额外的操作。
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
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
表1标题字段摘要，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.
处理包含消息正文的信息消息超出了本文档的范围。定义消息体的文档还需要定义与这些消息体关联的SIP协议规则。
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.
如果信息请求与任何现有呼叫分支不匹配，则UAS必须发送481呼叫分支/事务不存在消息。
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.
如果服务器接收到包含其理解的主体的信息请求，但不知道与主体相关的信息处理规则，则可以向用户呈现和显示该主体。该信息以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.
如果信息请求包含服务器不理解的主体，则在没有与主体相关联的信息处理规则的情况下，服务器必须使用415不支持的媒体类型消息进行响应。
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
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
表2标题字段汇总，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.
暗示SIP呼叫状态或SIP发起的会话发生变化的主体不得在信息消息中发送。
Other request failure (4xx), Server Failure (5xx) and Global Failure (6xx) responses MAY be sent for the INFO Request.
可能会针对信息请求发送其他请求故障（4xx）、服务器故障（5xx）和全局故障（6xx）响应。
2.3 Message Body Inclusion
2.3 消息体包含
The INFO request MAY contain a message body.
信息请求可能包含消息正文。
2.4 Behavior of SIP User Agents
2.4 SIP用户代理的行为
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.
除非另有说明，否则INFO请求的协议规则（管理标签的使用、路由和记录路由、重传和可靠性、CSeq增量和消息格式）遵循[1]中为BYE请求定义的规则。
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.
可能会取消信息请求。如果尚未向信息发送最终响应，则收到信息请求取消的UAS应以“487请求取消”响应信息，然后表现为从未收到请求。
However, the INFO message MUST NOT change the state of the SIP call, or the sessions initiated by SIP.
但是，INFO消息不得更改SIP呼叫或SIP发起的会话的状态。
2.5 Behavior of SIP Proxy and Redirect Servers
2.5 SIP代理和重定向服务器的行为
2.5.1 Proxy Server
2.5.1 代理服务器
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].
除非另有说明，代理上的信息请求的协议规则与[1]中规定的BYE请求的协议规则相同。
2.5.2 Forking Proxy Server
2.5.2 分叉代理服务器
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].
除非另有说明，代理上的信息请求的协议规则与[1]中规定的BYE请求的协议规则相同。
2.5.3 Redirection Server
2.5.3 重定向服务器
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].
除非另有说明，代理上的信息请求的协议规则与[1]中规定的BYE请求的协议规则相同。
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.
INFO消息的目的是在SIP用户代理之间传输中间会话信息。此信息通常会在消息正文中携带，但也可以在INFO消息的标题中携带。
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.
为INFO方法创建的消息体或任何新头的定义不在本文档的范围内。预计将创建单独的文件来处理这些实体的定义。
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.
此外，INFO方法没有定义额外的机制来确保按订单交付。虽然CSeq报头将在传输新信息时增加，但这不应用于确定信息的顺序。这是因为用户代理发送重新邀请或其他SIP消息可能会导致信息消息CSeq计数出现间隙。
The following are considerations that should be taken into account when defining SIP extensions that make use of the INFO method.
以下是在定义使用INFO方法的SIP扩展时应考虑的事项。
- 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.
- 应考虑信息消息所承载的消息体的大小。由于消息可能会通过UDP传输，并且可能会出现较大消息的碎片，因此消息体应保持较小。
- 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.
- SIP代理服务器可能会分叉信息消息。需要考虑信息消息中信息分叉的含义。
- 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.
- 使用INFO消息的扩展不能依赖INFO消息来执行任何影响SIP呼叫状态或相关会话状态的操作。
- 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.
- 本文档中定义的信息扩展不依赖于Require或Proxy Require标题的使用。使用INFO消息的扩展可能需要使用这些机制。但是，如果可能的话，应该避免使用Require和Proxy Require，以提高SIP实体之间的互操作性。
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.
没有特定于INFO方法的其他安全问题。SIP规范中规定的安全要求适用于INFO方法。
[1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[1] Handley，M.，Schulzrinne，H.，Schooler，E.和J.Rosenberg，“SIP：会话启动协议”，RFC 25431999年3月。
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.
作者要感谢Matthew Cannon对本文件的贡献。此外，作者还要感谢MMUSIC和SIP工作组的成员，特别是Jonathan Rosenberg，就如何改进该文件提出了意见和建议。
Steve Donovan dynamicsoft 5100 Tennyson Parkway, Suite 200 Plano, Texas 75024
Steve Donovan dynamicsoft 5100丁尼生大道200号套房，德克萨斯州普莱诺75024
Email: sdonovan@dynamicsoft.com
Email: sdonovan@dynamicsoft.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。