RFC 7261 - Offer/Answer Considerations for G723 Annex A and G729 Annex B 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7261
タイトル : RFC 7261 - G723 Annex AおよびG729 Annex Bのオファー/アンサーに関する考慮事項
翻訳編集 : 自動生成

[要約] RFC 7261は、G723 Annex AおよびG729 Annex BのOffer/Answerに関する考慮事項を提供しています。このRFCの目的は、これらのコーデックの使用に関するプロトコルの一貫性と互換性を確保することです。

Internet Engineering Task Force (IETF)                        M. Perumal
Request for Comments: 7261                                 Cisco Systems
Category: Standards Track                                   P. Ravindran
ISSN: 2070-1721                                                      NSN
                                                                May 2014

Offer/Answer Considerations for G723 Annex A and G729 Annex B

G723 Annex AおよびG729 Annex Bのオファー/アンサーに関する考慮事項

Abstract

概要

This document provides the offer/answer considerations for the annexa parameter of G723 and the annexb parameter of G729, G729D, and G729E when the value of the annexa or annexb parameter does not match in the Session Description Protocol (SDP) offer and answer.

このドキュメントでは、セッション記述プロトコル（SDP）オファーとアンサーでannexaまたはannexbパラメーターの値が一致しない場合の、G723のannexaパラメーターとG729、G729D、およびG729Eのannexbパラメーターのオファー/アンサーの考慮事項について説明します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

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（Internet Engineering Task Force）の製品です。これは、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/rfc7261.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7261で入手できます。

著作権表示

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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Offer/Answer Considerations . . . . . . . . . . . . . . . . .   3
     3.1.  Considerations for Use of Comfort Noise Frames  . . . . .   3
     3.2.  Offer/Answer Considerations for G723 Annex A  . . . . . .   3
     3.3.  Offer/Answer Considerations for G729 Annex B, G729D Annex
           B, and G729E Annex B  . . . . . . . . . . . . . . . . . .   4
   4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Offer with G729 annexb=yes and Answer with G729 annexb=no   5
     4.2.  Offer with G729 annexb=yes and Answer with G729 and No
           annexb Parameter  . . . . . . . . . . . . . . . . . . . .   5
     4.3.  Offer with G729 and No annexb Parameter and Answer with
           G729 annexb=no  . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   7

1. Introduction

1. はじめに

[RFC4856] describes the annexa parameter for G723 as follows:

[RFC4856]は、G723のannexaパラメータを次のように説明しています。

annexa: indicates that Annex A, voice activity detection, is used or preferred. Permissible values are "yes" and "no" (without the quotes); "yes" is implied if this parameter is omitted.

annexa：音声アクティビティ検出であるAnnex Aが使用または優先されていることを示します。許容値は「yes」と「no」です（引用符なし）。このパラメーターを省略すると、「はい」が暗黙指定されます。

Also, [RFC4856] describes the annexb parameter for G729, G729D, and G729E as follows:

また、[RFC4856]は、G729、G729D、およびG729Eのannexbパラメータを次のように説明しています。

annexb: indicates that Annex B, voice activity detection, is used or preferred. Permissible values are "yes" and "no" (without the quotes); "yes" is implied if this parameter is omitted.

annexb：音声アクティビティ検出であるAnnex Bが使用または推奨されることを示します。許容値は「yes」と「no」です（引用符なし）。このパラメーターを省略すると、「はい」が暗黙指定されます。

However, a problem arises when the value of the annexa or annexb parameter does not match in the SDP [RFC4566] offer and answer.

ただし、annexaまたはannexbパラメータの値がSDP [RFC4566]オファーおよびアンサーで一致しない場合、問題が発生します。

For example, if the offer has G729 with annexb=yes and the answer has G729 with annexb=no, it can be interpreted in two different ways:

たとえば、オファーにannexb = yesのG729があり、回答にannexb = noのG729がある場合、2つの異なる方法で解釈できます。

o The offerer and answerer proceed as if G729 is negotiated with annexb=yes, or

o 提案者と回答者は、G729がannexb = yesと交渉されたかのように処理を進めます。

o The offerer and answerer proceed as if G729 is negotiated with annexb=no.

o 提案者と回答者は、G729がannexb = noで交渉されているかのように処理を進めます。

Since this is not clear in the existing specifications, various implementations have interpreted the offer/answer in their own ways, resulting in a different codec being chosen to call failure, when the parameter value does not match in the offer and answer.

これは既存の仕様では明確ではないため、さまざまな実装がオファー/アンサーを独自の方法で解釈し、パラメーター値がオファーとアンサーで一致しない場合、呼び出しを失敗するために異なるコーデックが選択されます。

[RFC3264] requires SDP extensions that define new fmtp parameters to specify their proper interpretation in offer/answer. This document specifies the proper interpretation for the annexa and annexb parameters in offer/answer.

[RFC3264]は、オファー/アンサーで適切な解釈を指定するために、新しいfmtpパラメータを定義するSDP拡張が必要です。このドキュメントでは、offer / answerのannexaおよびannexbパラメータの適切な解釈について説明しています。

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].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

3. Offer/Answer Considerations

3. オファー/アンサーの考慮事項

The general objective of the offer/answer considerations is to make sure that if the offerer or answerer indicates it does not support Annex A or Annex B, then Annex A or Annex B is not used.

オファー/アンサーの考慮事項の一般的な目的は、提供者または回答者がAnnex AまたはAnnex Bをサポートしていないことを示した場合、Annex AまたはAnnex Bが使用されないようにすることです。

3.1. Considerations for Use of Comfort Noise Frames

3.1. コンフォートノイズフレームの使用に関する考慮事項

[RFC3551] states that:

[RFC3551]は次のように述べています：

Receivers MUST accept comfort noise frames if restriction of their use has not been signaled. The MIME registration for G729 in RFC 3555 specifies a parameter that MAY be used with MIME or SDP to restrict the use of comfort noise frames.

使用制限が通知されていない場合、受信機はコンフォートノイズフレームを受け入れる必要があります。 RFC 3555のG729のMIME登録は、コンフォートノイズフレームの使用を制限するためにMIMEまたはSDPで使用される可能性があるパラメーターを指定します。

Hence, if the SDP offer or answer indicates that comfort noise is not supported, comfort noise frames MUST NOT be used.

したがって、SDPオファーまたは回答がコンフォートノイズがサポートされていないことを示している場合、コンフォートノイズフレームを使用してはなりません（MUST NOT）。

3.2. Offer/Answer Considerations for G723 Annex A

3.2. G723 Annex Aのオファー/アンサーに関する考慮事項

When the offer or answer has G723 and the annexa parameter is absent, the offerer or answerer knows that it has implied the default "annexa=yes". This is because the annexa attribute is part of the original registration of audio/G723 [RFC4856]. All implementations that support G723 understand the annexa attribute. Hence, this case MUST be considered as if the offer or answer has G723 with annexa=yes.

オファーまたはアンサーにG723があり、annexaパラメーターが存在しない場合、オファー側またはアンサー側は、デフォルトの「annexa = yes」を暗黙指定していることを知っています。これは、annexa属性がaudio / G723 [RFC4856]の元の登録の一部であるためです。 G723をサポートするすべての実装は、annexa属性を理解します。したがって、このケースは、オファーまたはアンサーにannexa = yesを指定したG723があるかのように考慮する必要があります。

When the offer has G723 with annexa=yes and the answer has G723 with annexa=no, the offerer and answerer MUST proceed as if G723 is negotiated with annexa=no.

オファーにannexa = yesのG723があり、回答にannexa = noのG723がある場合、オファー者と回答者は、G723がannexa = noとネゴシエートされているかのように処理を進める必要があります。

When the offer has G723 with annexa=no, after the offer/answer completion the offerer and answerer MUST proceed as if G723 is negotiated with annexa=no.

オファーにannexa = noを指定したG723が含まれている場合、オファー/回答の完了後、オファー提供者と回答者は、G723がannexa = noを使用して交渉されているかのように続行する必要があります。

When the offer has G723 with annexa=no, the reason for not mandating that the answer MUST have annexa=no for G723 is that there are implementations that omit the annexa parameter in answer. In such cases, the offerer and answerer proceed as if G723 is negotiated with annexa=no.

オファーにannexa = noのG723がある場合、回答がG723のannexa = noを持つ必要があることを強制しない理由は、回答でannexaパラメーターを省略する実装があるためです。このような場合、提供者と回答者は、G723がannexa = noで交渉されたかのように処理を進めます。

When the offer has G723 with no annexa parameter and the answer has G723 with annexa=yes, the offerer and answerer MUST proceed as if G723 is negotiated with annexa=yes.

オファーにannexaパラメータのないG723があり、回答にannexa = yesのG723がある場合、オファー側とアンサー側は、G723がannexa = yesとネゴシエートされているかのように処理を進める必要があります。

3.3. Offer/Answer Considerations for G729 Annex B, G729D Annex B, and G729E Annex B

3.3. G729 Annex B、G729D Annex B、およびG729E Annex Bのオファー/アンサーに関する考慮事項

In this section, G729 represents any of G729 or G729D or G729E.

このセクションでは、G729はG729またはG729DまたはG729Eのいずれかを表します。

When the offer or answer has G729 and the annexb parameter is absent, the offerer or answerer knows that it has implied the default "annexb=yes". This is because the annexb attribute is part of the original registration of audio/G729 [RFC4856]. All implementations that support G729 understand the annexb attribute. Hence, this case MUST be considered as if the offer or answer has G729 with annexb=yes.

オファーまたはアンサーにG729があり、annexbパラメーターが存在しない場合、オファー側またはアンサー側は、デフォルトの「annexb = yes」を暗黙指定していることを知っています。これは、annexb属性がaudio / G729 [RFC4856]の元の登録の一部であるためです。 G729をサポートするすべての実装は、annexb属性を理解します。したがって、このケースは、オファーまたはアンサーがannexb = yesのG729を持っているかのように考慮される必要があります。

When the offer has G729 with annexb=yes and the answer has G729 with annexb=no, the offerer and answerer MUST proceed as if G729 is negotiated with annexb=no.

オファーにannexb = yesのG729があり、回答にannexb = noのG729がある場合、オファー側とアンサー側は、G729がannexb = noとネゴシエートされているかのように処理を進める必要があります。

When the offer has G729 with annexb=no, after the offer/answer completion the offerer and answerer MUST proceed as if G729 is negotiated with annexb=no.

オファーにannexb = noを指定したG729がある場合、オファー/回答の完了後、オファー提供者と回答者は、G729がannexb = noとネゴシエートされたかのように処理を続行する必要があります。

When the offer has G729 with annexb=no, the reason for not mandating that the answer MUST have annexb=no for G729 is that there are implementations that omit the annexb parameter in the answer. In such cases, the offerer and answerer proceed as if G729 is negotiated with annexb=no.

オファーにannexb = noを指定したG729がある場合、回答にG729のannexb = noが必須であることを強制しない理由は、回答でannexbパラメータを省略した実装があるためです。このような場合、提供者と回答者は、G729がannexb = noでネゴシエートされたかのように処理を進めます。

When the offer has G729 with no annexb parameter and the answer has G729 with annexb=yes, the offerer and answerer MUST proceed as if G729 is negotiated with annexb=yes.

オファーにannexbパラメータのないG729があり、回答にannexb = yesのG729がある場合、オファー側とアンサー側は、G729がannexb = yesとネゴシエートされているかのように処理を進める必要があります。

4. Examples

4. 例

4.1. Offer with G729 annexb=yes and Answer with G729 annexb=no

4.1. G729 annexb = yesで提供し、G729 annexb = noで回答する

[Offer with G729 annexb=yes]

[G729 annexb = yesのオファー]

           v=0
           o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
           s=
           c=IN IP4 host.atlanta.example.com
           t=0 0
           m=audio 49170 RTP/AVP 18
           a=rtpmap:18 G729/8000
           a=fmtp:18 annexb=yes

[Answer with G729 annexb=no]

[G729 annexb = noで応答]

           v=0
           o=bob 1890844326 1890844326 IN IP4 host.bangalore.example.com
           s=
           c=IN IP4 host.bangalore.example.com
           t=0 0
           m=audio 19140 RTP/AVP 18
           a=rtpmap:18 G729/8000
           a=fmtp:18 annexb=no

In the above example, the offerer and answerer proceed as if G729 is negotiated with annexb=no.

上記の例では、提供者と回答者は、G729がannexb = noでネゴシエートされたかのように処理を進めます。

4.2. Offer with G729 annexb=yes and Answer with G729 and No annexb Parameter

4.2. G729 annexb = yesで提供し、G729で回答し、annexbパラメータなし

[Offer with G729 annexb=yes]

[G729 annexb = yesのオファー]

           v=0
           o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
           s=
           c=IN IP4 host.atlanta.example.com
           t=0 0
           m=audio 49170 RTP/AVP 18
           a=rtpmap:18 G729/8000
           a=fmtp:18 annexb=yes

[Answer with G729 and no annexb parameter]

[G729で回答し、annexbパラメータはありません]

           v=0
           o=bob 1890844326 1890844326 IN IP4 host.bangalore.example.com
           s=
           c=IN IP4 host.bangalore.example.com
           t=0 0
           m=audio 19140 RTP/AVP 18
           a=rtpmap:18 G729/8000

In the above example, the offerer and answerer proceed as if G729 is negotiated with annexb=yes.

上記の例では、提供者と回答者は、G729がannexb = yesとネゴシエートされたかのように処理を進めます。

4.3. Offer with G729 and No annexb Parameter and Answer with G729 annexb=no

4.3. G729を使用してannexbパラメータを指定せずに提供し、G729 annexb = noを使用して回答する

[Offer with G729 and no annexb parameter]

[G729があり、annexbパラメータがないオファー]

           v=0
           o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
           s=
           c=IN IP4 host.atlanta.example.com
           t=0 0
           m=audio 49170 RTP/AVP 18
           a=rtpmap:18 G729/8000

[Answer with G729 annexb=no]

[G729 annexb = noで応答]

           v=0
           o=bob 1890844326 1890844326 IN IP4 host.bangalore.example.com
           s=
           c=IN IP4 host.bangalore.example.com
           t=0 0
           m=audio 19140 RTP/AVP 18
           a=rtpmap:18 G729/8000
           a=fmtp:18 annexb=no

In the above example, the offerer and answerer proceed as if G729 is negotiated with annexb=no.

上記の例では、提供者と回答者は、G729がannexb = noでネゴシエートされたかのように処理を進めます。

5. Security Considerations

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

The guidelines described in [RFC6562] are to be followed for Use of Voice Activity Detection (i.e., Annex A or Annex B) with the Secure Real-time Transport Protocol (SRTP).

[RFC6562]で説明されているガイドラインは、Secure Real-time Transport Protocol（SRTP）での音声アクティビティ検出（つまり、Annex AまたはAnnex B）の使用について従う必要があります。

6. Acknowledgments

6. 謝辞

Thanks to Flemming Andreasen (Cisco), Miguel A. Garcia (Ericsson), Ali C. Begen (Cisco), Paul Kyzivat (Huawei), Roni Even (Huawei), Kevin Riley (Sonus), Ashish Sharma (Sonus), Kevin P. Fleming (Digium), Dale Worley (Avaya), Cullen Jennings (Cisco), Ari Keranen (Ericsson), Harprit S. Chhatwal (InnoMedia), Aurelien Sollaud (Orange), SM, Stephen Casner, Keith Drage (Alcatel-Lucent), Stephen Farrell, Barry Leiba, and Ted Lemon for their valuable input and comments. Martin Dolly (ATT) and Hadriel Kaplan (Acme Packet) provided useful suggestions at the mic at IETF 83.

Flemming Andreasen（Cisco）、Miguel A. Garcia（Ericsson）、Ali C. Begen（Cisco）、Paul Kyzivat（Huawei）、Roni Even（Huawei）、Kevin Riley（Sonus）、Ashish Sharma（Sonus）、Kevin Pに感謝。フレミング（デジタル）、デールワーリー（アバヤ）、カレンジェニングス（シスコ）、アリケラネン（エリクソン）、ハープリットS.チャトワル（イノメディア）、オーレリアンソラウド（オレンジ）、SM、スティーブンカスナー、キースドラゲ（アルカテルルーセント）、Stephen Farrell、Barry Leiba、Ted Lemonの貴重な意見やコメントに感謝します。 Martin Dolly（ATT）とHadriel Kaplan（Acme Packet）は、IETF 83のマイクで役立つ提案を行いました。

7. Normative References

7. 引用文献

[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月。

[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.

[RFC3264] Rosenberg、J。およびH. Schulzrinne、「オファー/アンサーモデルとセッション記述プロトコル（SDP）」、RFC 3264、2002年6月。

[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.

[RFC3551] Schulzrinne、H。およびS. Casner、「最小制御のオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。

[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.

[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。

[RFC4856] Casner, S., "Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences", RFC 4856, February 2007.

[RFC4856] Casner、S.、「オーディオおよびビデオ会議のRTPプロファイルでのペイロード形式のメディアタイプ登録」、RFC 4856、2007年2月。

[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, March 2012.

[RFC6562]パーキンス、C。およびJM。 Valin、「Secure RTPでの可変ビットレートオーディオの使用に関するガイドライン」、RFC 6562、2012年3月。

Authors' Addresses

著者のアドレス

Muthu Arul Mozhi Perumal Cisco Systems Cessna Business Park Sarjapur-Marathahalli Outer Ring Road Bangalore, Karnataka 560103 India

Muthu Arul Mozhi Perumal Cisco Systems Cessna Business Park Sarjapur-Marathahalli Outer Ring Road Bangalore、Karnataka、560103 India

   EMail: mperumal@cisco.com

Parthasarathi Ravindran NSN Manyata Embassy Business park Bangalore, Karnataka 560045 India

Parthasarathi Ravindran NSN Manyata Embassy Business park Bangalore、Karnataka、インド

   EMail: partha@parthasarathi.co.in