RFC 6432 - Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6432
タイトル : RFC 6432 - SIP（セッション開始プロトコル）応答の理由ヘッダーフィールドでQ.850コードを運ぶ
翻訳編集 : 自動生成

[要約] RFC 6432は、SIP（セッション開始プロトコル）の応答でのReasonヘッダーフィールドにQ.850コードを含めるための仕様です。このRFCの目的は、SIP応答でのエラーコードの詳細な情報を提供するために、Q.850コードを使用する方法を定義することです。

Internet Engineering Task Force (IETF)                         R. Jesske
Request for Comments: 6432                                      L. Liess
Category: Standards Track                               Deutsche Telekom
ISSN: 2070-1721                                            November 2011

Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses

SIP（セッション開始プロトコル）応答の理由ヘッダーフィールドでQ.850コードを運ぶ

Abstract

概要

Although the use of the SIP (Session Initiation Protocol) Reason header field in responses is considered in general in RFC 3326, its use is not specified for any particular response code. Nonetheless, existing deployments have been using Reason header fields to carry failure-related Q.850 cause codes in SIP responses to INVITE requests that have been gatewayed to Public Switched Telephone Network (PSTN) systems. This document normatively describes the use of the Reason header field in carrying Q.850 cause codes in SIP responses.

RFC 3326では、SIP（セッション開始プロトコル）の理由ヘッダーフィールドの使用は一般的に考慮されていますが、その使用は特定の応答コードでは指定されていません。それにもかかわらず、既存の展開は、SIP応答で故障関連のQ.850の原因コードを運ぶためにReason Headerフィールドを使用して、パブリックスイッチ付き電話ネットワーク（PSTN）システムにゲートウェイされたリクエストを招待しています。このドキュメントは、Q.850の原因コードをSIP応答で運ぶ際の理由ヘッダーフィールドの使用を規範的に説明しています。

Status of This Memo

本文書の位置付け

This is an Internet Standards Track document.

これは、インターネット標準トラックドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6432.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6432で取得できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。

Table of Contents

   1. Overview ........................................................2
   2. Terminology .....................................................2
   3. Applicability ...................................................3
   4. Security Considerations .........................................3
   5. Acknowledgments .................................................3
   6. Normative References ............................................3

1. Overview

1. 概要

Although the use of the SIP (Session Initiation Protocol) Reason header field in responses is considered in general in RFC 3326 [RFC3326], its use is not specified for any particular response code. Nonetheless, existing deployments have been using Reason header fields to carry failure-related Q.850 [Q.850] cause codes in SIP responses to INVITE requests that have been gatewayed to PSTN systems. This document normatively describes the use of the Reason header field in SIP responses to carry Q.850 [Q.850] cause codes.

RFC 3326 [RFC3326]では、SIP（セッション開始プロトコル）の理由ヘッダーフィールドの使用は一般に一般的に考慮されていますが、その使用は特定の応答コードでは指定されていません。それにもかかわらず、既存の展開により、Reason Headerフィールドを使用して、故障関連のQ.850 [Q.850]を運ぶSIP応答のコードを使用して、PSTNシステムにゲートウェイされたリクエストを招待しています。このドキュメントは、Q.850 [Q.850]原因コードをキャリーするためのSIP応答での理由ヘッダーフィールドの使用を規範的に説明しています。

2. Terminology

2. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。

This document uses terms from [RFC3261].

このドキュメントでは、[RFC3261]の用語を使用しています。

3. Applicability

3. 適用性

This document allows SIP responses to carry Reason header fields as follows:

このドキュメントにより、SIP応答は次のように理由ヘッダーフィールドを運ぶことができます。

Any SIP Response message, with the exception of a 100 (Trying), MAY contain a Reason header field with a Q.850 [Q.850] cause code.

100（試行）を除くSIP応答メッセージには、Q.850 [Q.850]原因コードを持つ理由ヘッダーフィールドが含まれる場合があります。

The Reason header field is not needed in the 100 (Trying) responses, since they are transmitted hop by hop, not end to end. SIP responses with Reason header fields carrying values other than Q.850 [Q.850] cause codes are outside of the scope of this document.

ヘッダーフィールドは、100（試行）応答では必要ありません。これは、エンドツーエンドではなく、ホップによってホップが送信されるためです。Q.850 [Q.850]以外のReason HeaderフィールドのCARLINY値を使用したSIP応答原因コードはこのドキュメントの範囲外です。

4. Security Considerations

4. セキュリティに関する考慮事項

This specification allows the presence of the Reason header field containing Q.850 [Q.850] cause codes in responses. The presence of the Reason header field in a response does not affect the treatment of the response. Nevertheless, there could be situations where a wrong Q.850 [Q.850] cause code could, for example, cause an announcement system to play the wrong information. To avoid such situations, it is RECOMMENDED that this header field be protected by a suitable integrity mechanism. The use of transport- or network-layer hop-by-hop security mechanisms, such as Transport Layer Security (TLS) or IPsec with appropriate cipher suites, can satisfy this requirement.

この仕様により、Q.850 [Q.850]を含むヘッダーフィールドの存在が応答にコードを引き起こすことができます。応答における理由ヘッダーフィールドの存在は、応答の治療に影響しません。それにもかかわらず、Q.850 [Q.850]がコードがコードを引き起こす可能性がある場合、たとえば、アナウンスシステムが間違った情報を再生する可能性がある場合があります。このような状況を回避するには、このヘッダーフィールドを適切な整合性メカニズムによって保護することをお勧めします。トランスポートレイヤーセキュリティ（TLS）や適切な暗号スイートを使用したIPSECなどの輸送またはネットワーク層のホップバイホップセキュリティメカニズムの使用は、この要件を満たすことができます。

5. Acknowledgments

5. 謝辞

Thanks to Gonzalo Camarillo and Mary Barnes for the detailed review of this document.

この文書の詳細なレビューをしてくれたGonzalo CamarilloとMary Barnesに感謝します。

Thanks to Paul Kyzivat, Mary Barnes, John Elwell, Keith Drage, and Thomas Belling, who provided helpful comments, feedback, and suggestions.

ポール・キジバット、メアリー・バーンズ、ジョン・エルウェル、キース・ドレイジ、トーマス・ベリングに感謝します。

6. Normative References

6. 引用文献

[Q.850] "Usage of cause and location in the Digital Subscriber Signalling System No. 1 and the Signalling System No. 7 ISDN User Part", ITU Recommendation Q.850, May 1998.

[Q.850]「デジタル加入者シグナリングシステムNo. 1およびシグナリングシステムNo. 7 ISDNユーザーパーツの原因と位置の使用」、ITU推奨Q.850、1998年5月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。

[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002.

[RFC3326] Schulzrinne、H.、Oran、D。、およびG. Camarillo、「セッション開始プロトコルの理由ヘッダーフィールド（SIP）」、RFC 3326、2002年12月。

Authors' Addresses

著者のアドレス

Roland Jesske Deutsche Telekom Heinrich-Hertz-Strasse 3-7 Darmstadt 64307 Germany

ローランド・ジェスケ・ドイツ・テイチェ・テレコム・ハインリッヒ・ハーツ・ストレス3-7ダルムシュタット64307ドイツ

   Phone: +4961515812766
   EMail: r.jesske@telekom.de

Laura Liess Deutsche Telekom Heinrich-Hertz-Strasse 3-7 Darmstadt 64307 Germany

Laura Liess Deutsche Telekom Heinrich-Hertz-Strasse 3-7 Darmstadt 64307ドイツ

   Phone: +4961515812761
   EMail: L.Liess@telekom.de