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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（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）の拡張を提案しています。この拡張は、SIPプロトコルにINFOメソッドを追加します。 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
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再INVITEはセッションの特性を変更するために、セッション中に使用することができます。これは、セッションに関連した流れまたは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の再のINVITE、不戦勝と個々のセッションに関連付けられている他の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メソッドは、セッションシグナリングパスに沿って中間呼シグナリング情報を搬送するために使用されるであろう。
The following are a few of the potential uses of the INFO message:
INFOメッセージの潜在的な用途のいくつかは、次のとおりです。
- 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方法のシグナリングパスは、コールセットアップの結果として確立シグナリング経路です。これは、呼び出し元と呼ばれるユーザーエージェントやコールセットアップに関与し、初期INVITEメッセージのRecord-Routeヘッダに自分自身を追加されたSIPプロキシサーバが関与するシグナリングパスの間の直接のシグナリングのいずれかになります。
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.
中間セッション情報はどちらかINFOメッセージヘッダ内またはメッセージ本体の一部として通信することができます。中間セッション情報を運ぶために使用されるメッセージ本体及び/又はメッセージヘッダの定義は、この文書の範囲外です。
There are no specific semantics associated with INFO. The semantics are derived from the body or new headers defined for usage in INFO.
INFOに関連した具体的な意味はありません。セマンティクスは、本体または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を参照。ルールはENCで定義されていることに注意してください。およびE-E列表4および5に[1]また、INFOリクエストとINFO要求に対する応答のヘッダーの使用に当てはまります。
If a server receives an INFO request it MUST send a final response.
サーバがINFO要求を受信した場合には、最終的な応答を送らなければなりません。
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.
INFO要求が正常に既存のコールのために受信された場合は200 OK応答なしメッセージ本体とINFO要求のためにUASによって送らなければなりません。それを超えて、追加の操作は必要ありません。
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.
メッセージ本文が含まれているINFOメッセージの取り扱いは、この文書の範囲外です。メッセージ本文を定義文書はまた、これらのメッセージボディに関連付けられた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.
481コールレグ/トランザクションは、INFO要求は、既存のコールレッグと一致しない場合、メッセージがUASによって送らなければなりません存在しません。
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.
サーバは、それが理解本体とINFO要求を受信し、それは身体のためにINFO関連する処理ルールの知識を持っていない場合は、本体がレンダリングされ、ユーザに表示することができます。 INFOは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.
INFO要求は、サーバーが身体のためINFO関連する処理ルールが存在しない場合には、理解していない体が含まれている場合、サーバーは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
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によって開始されたセッションを意味するものでは体はINFOメッセージで送ってはいけません。
Other request failure (4xx), Server Failure (5xx) and Global Failure (6xx) responses MAY be sent for the INFO Request.
その他の要求の失敗（4XX）、サーバ障害（5xxの）およびグローバル失敗（6xxの）応答がINFO要求のために送られるかもしれません。
The INFO request MAY contain a message body.
INFO要求は、メッセージ本体を含むかもしれません。
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.
INFO要求はキャンセルされる場合があります。最終的な応答をINFOに送られ、その後、要求が受信されなかったかのように動作されていない場合はINFO要求に対してCANCELを受信UASは「487要求のキャンセル」応答をINFOに応じます。
However, the INFO message MUST NOT change the state of the SIP call, or the sessions initiated by SIP.
しかし、INFOメッセージは、SIPコール、またはSIPによって開始されたセッションの状態を変更しないでください。
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].
特に明記しない限り、プロキシにおけるINFO要求のプロトコル規則[1]で指定されるようにBYE要求のものと同一です。
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].
特に明記しない限り、プロキシにおけるINFO要求のプロトコル規則[1]で指定されるようにBYE要求のものと同一です。
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].
特に明記しない限り、プロキシにおけるINFO要求のプロトコル規則[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ヘッダは新しいINFOメッセージの送信時にインクリメントされるが、これは、INFO情報の配列を決定するために使用すべきではありません。これは、再INVITESまたは他のSIPメッセージを送信するユーザエージェントによって引き起こさカウントCSEQ INFOメッセージにギャップがあるかもしれないという事実によるものです。
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.
- 対価は、INFOメッセージによって運ばれるメッセージボディのサイズに注意する必要があります。メッセージ本文が原因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.
- INFOメッセージはSIPプロキシサーバによってフォークすることができることを可能性があります。 INFOメッセージ内の情報のこのフォークの影響が考慮される必要があります。
- The use of multi-part message bodies may be helpful when defining the message bodies to be carried by the INFO message.
- INFOメッセージによって運ばれるべきメッセージ本文を定義するときにマルチパートメッセージ本文の使用が有用であり得ます。
- 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メッセージを使用して拡張子がSIP通話状態または関連セッションの状態に影響を与える何かをするINFOメッセージ当てにしてはいけません。
- 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.
- 本書で定義されている情報の拡張子が必要とするか、またはプロキシ要求ヘッダの使用に依存しません。 INFOメッセージを使用した拡張機能は、これらのメカニズムの使用が必要な場合があります。可能であればしかし、必要とするプロキシ要求を使用すると、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]ハンドレー、M.、Schulzrinneと、H.、学生はE.およびJ.ローゼンバーグ、 "SIP：セッション開始プロトコル"、RFC 2543、1999年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.
作者はこのドキュメントへの貢献のためのマシュー・キャノンに感謝したいと思います。また、著者は、ドキュメントを改善する方法についての意見や提案のために、MMUSICとSIPワーキンググループ、特にジョナサン・ローゼンバーグのメンバーに感謝したいと思います。
Steve Donovan dynamicsoft 5100 Tennyson Parkway, Suite 200 Plano, Texas 75024
スティーブ・ドノバンdynamicsoft 5100テニソンパークウェイ、スイート200プラノ、テキサス75024
Email: sdonovan@dynamicsoft.com
メール：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 Editor機能のための基金は現在、インターネット協会によって提供されます。