RFC3108 日本語訳
3108 Conventions for the use of the Session Description Protocol (SDP)for ATM Bearer Connections. R. Kumar, M. Mostafa. May 2001. (Format: TXT=248037 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Kumar
Request for Comments: 3108 M. Mostafa
Category: Standards Track Cisco Systems
May 2001
コメントを求めるワーキンググループR.クマーの要求をネットワークでつないでください: 3108年のM.Mostafaカテゴリ: 標準化過程シスコシステムズ2001年5月
Conventions for the use of the Session Description Protocol (SDP)
for ATM Bearer Connections
Session記述プロトコル(SDP)のATM Bearerコネクションズの使用のためのコンベンション
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document describes conventions for using the Session Description Protocol (SDP) described in RFC 2327 for controlling ATM Bearer Connections, and any associated ATM Adaptation Layer (AAL). The AALs addressed are Type 1, Type 2 and Type 5. This list of conventions is meant to be exhaustive. Individual applications can use subsets of these conventions. Further, these conventions are meant to comply strictly with the SDP syntax as defined in RFC 2327.
このドキュメントは、記述プロトコル(SDP)がATM Bearerコネクションズを制御するためにRFC2327で説明したSession、およびどんな関連ATM Adaptation Layer(AAL)も使用するためにコンベンションについて説明します。 扱われたAALsはType1と、Type2とType5です。 コンベンションのこのリストが徹底的であることが意味されます。 個々のアプリケーションはこれらのコンベンションの部分集合を使用できます。 さらに、これらのコンベンションはRFC2327で定義されるように厳密にSDP構文に従うことになっています。
Table of Contents
目次
1. Introduction................................................... 3 1.1 Key words to indicate Requirement Levels..................... 5 2. Representation of Certain Fields within SDP description lines.. 5 2.1 Representation of Extension Attributes....................... 5 2.2 Representation of Parameter Values........................... 5 2.3 Directionality Convention.................................... 6 2.4 Case convention............................................... 7 2.5 Use of special characters in SDP parameter values............. 8 3. Capabilities Provided by SDP conventions....................... 8 4. Format of the ATM Session Description.......................... 9 5. Structure of the Session Description Lines.................... 11 5.1 The Origin Line.............................................. 11 5.2 The Session Name Line........................................ 12 5.3 The Connection Information Line.............................. 13 5.4 The Timestamp Line........................................... 15
1. 序論… 3 Requirement Levelsを示す1.1のキーワード… 5 2. SDP記述の中のCertainフィールズの表現は立ち並んでいます。 5 2.1 拡大属性の表現… 5 2.2 パラメタ値の表現… 5 2.3 方向性コンベンション… 6 2.4 コンベンションをケースに入れてください… 7 2.5 SDPパラメタ値における特殊文字の使用… 8 3. SDPコンベンションによる能力Provided… 8 4. 気圧セッション記述の形式… 9 5. セッション記述の構造は立ち並んでいます… 11 5.1 発生源線… 11 5.2 セッション名前線… 12 5.3 接続情報線… 13 5.4 タイムスタンプ線… 15
Kumar & Mostafa Standards Track [Page 1] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[1ページ]。
5.5 Media Information Line for ATM connections................... 16 5.5.1 The Virtual Connection ID.................................. 16 5.5.2 The Transport Parameter.................................... 19 5.5.3 The Format List for AAL1 and AAL5 applications............. 21 5.5.4 The Format List for AAL2 applications...................... 21 5.5.5 Media information line construction........................ 22 5.6 The Media Attribute Lines.................................... 27 5.6.1 ATM bearer connection attributes........................... 28 5.6.1.1 The 'eecid' attribute.................................... 30 5.6.1.2 The 'aalType' attribute.................................. 31 5.6.1.3 The 'capability' attribute............................... 32 5.6.1.4 The 'qosClass' attribute................................. 33 5.6.1.5 The 'bcob' attribute..................................... 34 5.6.1.6 The 'stc' attribute...................................... 34 5.6.1.7 The 'upcc' attribute..................................... 35 5.6.1.8 The 'atmQOSparms' attribute.............................. 35 5.6.1.9 The 'atmTrfcDesc' attribute............................. 37 5.6.1.10 The 'abrParms' attribute................................. 39 5.6.1.11 The 'abrSetup' attribute................................. 40 5.6.1.12 The 'bearerType' attribute............................... 41 5.6.1.13 The 'lij' attribute...................................... 42 5.6.1.14 The 'anycast' attribute.................................. 43 5.6.1.15 The 'cache' attribute.................................... 43 5.6.1.16 The 'bearerSigIE' attribute.............................. 44 5.6.2 ATM Adaptation Layer (AAL) attributes...................... 45 5.6.2.1 The 'aalApp' attribute................................... 46 5.6.2.2 The 'cbrRate' attribute.................................. 48 5.6.2.3 The 'sbc' attribute...................................... 49 5.6.2.4 The 'clkrec' attribute................................... 51 5.6.2.5 The 'fec' attribute...................................... 51 5.6.2.6 The 'prtfl' attribute.................................... 51 5.6.2.7 The 'structure' attribute................................ 52 5.6.2.8 The 'cpsSDUsize' attribute............................... 53 5.6.2.9 The 'aal2CPS' attribute.................................. 53 5.6.2.10 The 'aal2CPSSDUrate' attribute........................... 54 5.6.2.11 The 'aal2sscs3661unassured' attribute.................... 54 5.6.2.12 The 'aal2sscs3661assured' attribute...................... 55 5.6.2.13 The 'aal2sscs3662' attribute............................. 56 5.6.2.14 The 'aal5sscop' attribute................................ 58 5.6.3 Service attributes......................................... 58 5.6.3.1 The 'atmmap' attribute................................... 60 5.6.3.2 The 'silenceSupp' attribute.............................. 63 5.6.3.3 The 'ecan' attribute..................................... 65 5.6.3.4 The 'gc' attributes...................................... 66 5.6.3.5 The 'profileDesc' attribute.............................. 67 5.6.3.6 The 'vsel' attribute..................................... 68 5.6.3.7 The 'dsel' attribute..................................... 70 5.6.3.8 The 'fsel' attribute..................................... 72
5.5 ATM接続のためのメディア情報線… 16 5.5 .1 仮想接続ID… 16 5.5 .2 輸送パラメタ… 19 5.5 .3 AAL1のためのFormat ListとAAL5アプリケーション… 21 5.5 .4 AAL2アプリケーションのためのFormat List… 21 5.5 .5メディア情報回線工事… 22 5.6 メディア属性は立ち並んでいます… 27 5.6 .1 ATM運搬人接続属性… 28 5.6 .1 .1 'eecid'属性… 30 5.6 .1 .2 'aalType'属性… 31 5.6 .1 .3 '能力'属性… 32 5.6 .1 .4 'qosClass'属性… 33 5.6 .1 .5 'bcob'属性… 34 5.6 .1 .6 'stc'属性… 34 5.6 .1 .7 'upcc'属性… 35 5.6 .1 .8 'atmQOSparms'属性… 35 5.6 .1 .9 'atmTrfcDesc'属性… 37 5.6 .1 .10 'abrParms'属性… 39 5.6 .1 .11 'abrSetup'属性… 40 5.6 .1 .12 'bearerType'属性… 41 5.6 .1 .13 'lij'属性… 42 5.6 .1 .14 'anycast'属性… 43 5.6 .1 .15 'キャッシュ'属性… 43 5.6 .1 .16 'bearerSigIE'属性… 44 5.6 .2 ATM Adaptation Layer(AAL)属性… 45 5.6 .2 .1 'aalApp'属性… 46 5.6 .2 .2 'cbrRate'属性… 48 5.6 .2 .3 'sbc'属性… 49 5.6 .2 .4 'clkrec'属性… 51 5.6 .2 .5 'fec'属性… 51 5.6 .2 .6 'prtfl'属性… 51 5.6 .2 .7 '構造'属性… 52 5.6 .2 .8 'cpsSDUsize'属性… 53 5.6 .2 .9 'aal2CPS'属性… 53 5.6 .2 .10 'aal2CPSSDUrate'属性… 54 5.6 .2 .11 'aal2sscs3661unassured'属性… 54 5.6 .2 .12 'aal2sscs3661assured'属性… 55 5.6 .2 .13 'aal2sscs3662'属性… 56 5.6 .2 .14 'aal5sscop'属性… 58 5.6 .3 属性を修理してください… 58 5.6 .3 .1 'atmmap'属性… 60 5.6 .3 .2 'silenceSupp'属性… 63 5.6 .3 .3 'ecan'属性… 65 5.6 .3 .4 'gc'属性… 66 5.6 .3 .5 'profileDesc'属性… 67 5.6 .3 .6 'vsel'属性… 68 5.6 .3 .7 'dsel'属性… 70 5.6 .3 .8 'fsel'属性… 72
Kumar & Mostafa Standards Track [Page 2] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[2ページ]。
5.6.3.9 The 'onewaySel' attribute................................ 73
5.6.3.10 The 'codecconfig' attribute.............................. 75
5.6.3.11 The 'isup_usi' attribute................................. 76
5.6.3.12 The 'uiLayer1_Prot' attribute............................ 76
5.6.4 Miscellaneous media attributes............................. 77
5.6.4.1 The 'chain' attribute..................................... 77
5.6.5 Use of the second media-level part in H.323 Annex C
applications............................................... 78
5.6.6 Use of the eecid media attribute in call establishment
procedures................................................. 78
6. List of Parameters with Representations....................... 83
7. Examples of ATM session descriptions using SDP................. 93
8. Security Considerations........................................ 94
8.1 Bearer Security.............................................. 94
8.2 Security of the SDP description.............................. 95
9. ATM SDP Grammar................................................ 95
References........................................................104
Acknowledgements..................................................109
Authors' Addresses................................................109
Full Copyright Statement..........................................110
5.6.3.9 'onewaySel'属性… 73 5.6 .3 .10 'codecconfig'属性… 75 5.6 .3 .11 'isup_usi'属性… 76 5.6 .3 .12 'uiLayer1_Prot'属性… 76 5.6 .4 種々雑多なメディア属性… 77 5.6 .4 .1 'チェーン'属性… 77 5.6 .5 H.323 Annex Cアプリケーションにおける2番目のメディアレベル部分の使用… 78 5.6 .6 呼設定手順におけるeecidメディア属性の使用… 78 6. 表現があるパラメタのリスト… 83 7. SDPを使用するATMセッション記述に関する例… 93 8. セキュリティ問題… 94 8.1 運搬人セキュリティ… 94 8.2 SDP記述のセキュリティ… 95 9. 気圧SDP文法… 95の参照箇所…104の承認…109人の作者のアドレス…109 完全な著作権宣言文…110
1. Introduction
1. 序論
SDP will be used in conjunction with a connection handling /device control protocol such as Megaco (H.248) [26], SIP [18] or MGCP [25] to communicate the information needed to set up ATM and AAL2 bearer connections. These connections include voice connections, voiceband data connections, clear channel circuit emulation connections, video connections and baseband data connections (such as fax relay, modem relay, SSCOP, frame relay etc.).
SDPは、ATMとAAL2運搬人接続をセットアップするのに必要である情報を伝えるのにMegaco(H.248)[26]、SIP[18]またはMGCP[25]などの接続取り扱い/デバイス制御プロトコルに関連して使用されるでしょう。 これらの接続は声の接続、voicebandデータ接続、クリア・チャンネル回路エミュレーション接続、ビデオ接続、およびベースバンドデータ接続(ファックスリレー、モデムリレー、フレームリレーSSCOPなどの)を入れます。
These conventions use standard SDP syntax as defined in RFC 2327 [1] to describe the ATM-level and AAL-level connections, addresses and other parameters. In general, parameters associated with layers higher than the ATM adaptation layer are included only if they are tightly coupled to the ATM or AAL layers. Since the syntax conforms to RFC 2327, standard SDP parsers should react in a well-defined and safe manner on receiving session descriptions based on the SDP conventions in this document. This is done by extending the values of fields defined in RFC 2327 rather than by defining new fields. This is true for all SDP lines except the of the media attribute lines, in which case new attributes are defined. The SDP protocol allows the definition of new attributes in the media attribute lines which are free-form. For the remaining lines, the fact that the <networkType> field in an SDP descriptor is set to "ATM" should preclude the misinterpretation of extended parameter values by RFC 2327-compliant SDP parsers.
これらのコンベンションはATM-レベルとAAL-レベル接続、アドレス、および他のパラメタについて説明するためにRFC2327[1]で定義されるように標準のSDP構文を使用します。 一般に、関連しているATM適合層より高い層の形でパラメタはそれらがATMかAAL層への密結合である場合にだけ含まれています。 構文がRFC2327に従うので、本書ではSDPコンベンションに基づくセッション記述を受けるとき、標準のSDPパーサは明確で安全な方法で反応するはずです。 新しい分野を定義することによってというよりむしろRFC2327で定義された分野の値を広げることによって、これをします。 SDPが立ち並ぶすべてに、これが本当である、属性が裏打ちするメディアでは、その場合、新しい属性は定義されます。 SDPプロトコルは属性が裏打ちする自由形式であるメディアとの新しい属性の定義を許します。 残っている系列のために、SDP記述子の<networkType>分野が「気圧」に設定されるという事実はRFCの2327年の対応することのSDPパーサで拡張パラメタ値の誤解を排除するべきです。
Kumar & Mostafa Standards Track [Page 3] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[3ページ]。
These conventions are meant to address the following ATM applications:
これらのコンベンションは以下のATMアプリケーションを扱うことになっています:
1. Applications in which a new SVC is set-up for each service
connection. These SVCs could be AAL1 or AAL5 SVCs or single-
CID AAL2 SVCs.
1. 新しいSVCがそれぞれのためのセットアップであるアプリケーションは接続にサービスを提供します。 これらのSVCsはAAL1、AAL5 SVCsまたは独身のCID AAL2 SVCsであるかもしれません。
2. Applications in which existing path resources are assigned to
service connections. These resources could be:
2. アプリケーションはどの既存の経路リソースでサービス連結部に割り当てられるか。 これらのリソースは以下の通りであるかもしれません。
* AAL1/AAL5 PVCs, SPVCs or cached SVCs,
* AAL2 single-CID PVCs, SPVCs or cached SVCs,
* CIDs within AAL2 SVCs/PVCs/SPVCs that multiplex multiple
CIDs.
* Subchannels (identified by CIDs) within AAL1 [8] or AAL2
[11] SVCs/PVCs/SPVCs.
* *AAL1/AAL5 PVCs、SPVCs、キャッシュされたSVCs、AAL2の独身のCID PVCs、SPVCsまたはキャッシュされたSVCs(複数のCIDsを多重送信するAAL2 SVCs/PVCs/SPVCsの中の*CIDs)。 * AAL1[8]の中のサブチャネル(CIDsによって特定される)かAAL2[11]SVCs/PVCs/SPVCs。
Note that the difference between PVCs and SPVCs is in the way the bearer virtual circuit connection is set up. SPVCs are a class of PVCs that use bearer signaling, as opposed to node-by-node provisioning, for connection establishment.
PVCsとSPVCsの違いが運搬人の仮想の回路接続がセットアップされる方法であることに注意してください。 SPVCsはノードごとの食糧を供給することと対照的にコネクション確立に運搬人シグナリングを使用するPVCsのクラスです。
This document is limited to the case when the network type is ATM. This includes raw RTP encapsulation [45] or voice sample encapsulation [46] over AAL5 with no intervening IP layer. It does not address SDP usage for IP, with or without ATM as a lower layer.
ネットワークタイプがATMであるときに、このドキュメントはケースに制限されます。 これはAAL5の上に介入しているIP層なしで生のRTPカプセル化[45]か声のサンプルカプセル化[46]を含んでいます。 それは、下層としてのATMのあるなしにかかわらずIPのためにSDPが用法であると扱いません。
In some cases, IP connection set-up is independent of lower layers, which are configured prior to it. For example, AAL5 PVCs that connect IP routers can be used for VoIP calls. In other cases, VoIP call set-up is closely tied to ATM-level connection set-up. This might require a chaining of IP and ATM descriptors, as described in section 5.6.4.1.
いくつかの場合、IP接続セットアップは下層から独立しています。(下層はそれの前に構成されます)。 例えば、VoIP呼び出しにIPルータを接続するAAL5 PVCsは使用できます。 他の場合では、VoIP呼び出しセットアップは密接にATM-レベル接続セットアップに結ばれます。 これはセクション5.6.4で.1に説明されるようにIPとATM記述子の推論を必要とするかもしれません。
This document makes no assumptions on who constructs the session descriptions (media gateway, intermediate ATM/AAL2 switch, media gateway controller etc.). This will be different in different applications. Further, it allows the use of one session description for both directions of a connection (as in SIP and MGCP applications) or the use of separate session descriptions for different directions. It also addresses the ATM multicast and anycast capabilities.
このドキュメントはだれがセッションを構成するかに関する仮定を全く記述(メディアゲートウェイ、コントローラの中間的メディアATM/AAL2ゲートウェイスイッチなど)にしません。 これは異なったアプリケーションにおいて異なるでしょう。 さらに、それは1つのセッション記述の異なった方向の接続(SIPとMGCPアプリケーションのように)の方向か別々のセッション記述の使用の両方の使用を許します。 また、それは、ATMマルチキャストとanycastが能力であると扱います。
This document makes no assumptions about how the SDP description will be coded. Although the descriptions shown here are encoded as text, alternate codings are possible:
このドキュメントはSDP記述がどうコード化されるかに関する仮定を全くしません。 ここに示された記述はテキストとしてコード化されますが、代替のコーディングは可能です:
- Binary encoding such as ASN.1. This is an option (in addition to
text encoding) in the Megaco context.
- ASN.1などの2進のコード化。 これはMegaco文脈でオプション(テキストコード化に加えた)です。
Kumar & Mostafa Standards Track [Page 4] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[4ページ]。
- Use of extended ISUP parameters [36] to encode the information in
SDP descriptors, with conversion to/from binary/text-based SDP
encoding when needed.
- 変換で2進の、または、テキストベースのSDPコード化からの必要であると/にSDP記述子の情報をコード化する拡張ISUPパラメタ[36]の使用。
1.1 Key words to indicate Requirement Levels
1.1 Requirement Levelsを示すキーワード
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 RFC 2119 [62].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[62]で説明されるように本書では解釈されることであるべきですか?
2. Representation of Certain Fields within SDP description lines
2. SDP記述系列の中のCertainフィールズの表現
This document conforms to the syntactic conventions of standard SDP as defined in RFC 2327 [1].
このドキュメントはRFC2327[1]で定義されるように標準のSDPの構文のコンベンションに一致しています。
2.1 Representation of Extension Attributes
2.1 拡大属性の表現
The SDP protocol [1] requires that non-standard attributes and codec names use an "X-" prefix.
SDPプロトコル[1]は、標準的でない属性とコーデック名が「X」接頭語を使用するのを必要とします。
In this internet document, the "X-" prefix is used consistently for codec names (Table 2) that have not been registered with the IANA. The IANA-registered codec names listed in [31] do not use this prefix, regardless of whether they are statically or dynamically assigned payload types.
このインターネットドキュメントでは、「X」接頭語はIANAに登録されていないコーデック名(テーブル2)に一貫して使用されます。 [31]に記載されたIANAによって登録されたコーデック名はこの接頭語を使用しません、それらが静的かダイナミックにペイロードタイプに割り当てられるかどうかにかかわらず。
However, this prefix is not used for the extension SDP attributes defined in this document. This has been done to enhance legibility.
しかしながら、この接頭語は本書では定義された拡大SDP属性に使用されません。 読みやすさを高めるためにこれをしました。
This document suggests that parsers be flexible in the use of the "X-" prefix convention. They should accept codec names and attribute names with or without the "X-" prefix.
このドキュメントは、パーサが「X」接頭語コンベンションの使用でフレキシブルであると示唆します。 彼らは「X」接頭語のあるなしにかかわらずコーデック名と属性名を受け入れるべきです。
2.2 Representation of Parameter Values
2.2 パラメタ値の表現
Depending on the format of their representation in SDP, the parameters defined in this document fall into the following classes:
SDPの彼らの表現の形式によって、本書では定義されたパラメタは以下のクラスになります:
(1) Parameters always represented in a decimal format.
(2) Parameters always represented in a hexadecimal format.
(3) Parameters always represented as character strings.
(4) Parameters that can be represented in either decimal or
hexadecimal format.
(1) 10進形式でいつも表されたパラメタ。 (2) 16進形式でいつも表されたパラメタ。 (3) パラメタはキャラクタとしていつもストリングを表しました。 (4) 小数か16進形式のどちらかで表すことができるパラメタ。
No prefixes are needed for classes 1 - 3, since the format is fixed. For class 4, a "0x" prefix shall always be used to differentiate the hexadecimal from the decimal format.
形式が固定されているので、接頭語は全くクラス1--3に必要ではありません。 クラス4において、"0x"接頭語は、10進形式と16進を区別するのにいつも使用されるものとします。
Kumar & Mostafa Standards Track [Page 5] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[5ページ]。
For both decimal and hex representations, if the underlying bit field is smaller or larger than the binary equivalent of the SDP representation, then leading 0 bits should be added or removed as needed. Thus, 3 and 0x3 translate into the following five-bit pattern: 0 0011. The SDP representations 0x12 and 18 translate into the following five-bit pattern: 1 0010.
小数と十六進法表現の両方に関しては、基本的な噛み付いている分野がSDP表現の2進の同等物よりさらに小さいか、または大きいなら、必要に応じて次に、0ビットを導くのを加えるべきであるか、または取り除くべきです。 したがって、3と0×3は以下の5ビットのパターンに翻訳されます: 0 0011. SDP表現0×12と18は以下の5ビットのパターンに翻訳されます: 1 0010.
Leading 0 digits shall not be used in decimal representations. Generally, these are also not used in hexadecimal representations. Exceptions are when an exact number of hex digits is expected, as in the case of NSAP addresses. Parsers shall not reject leading zeros in hex values.
10進表現に主な0ケタを使用しないものとします。 一般に、また、これらは16進表現に使用されません。 例外ははっきりした数の十六進法ケタがNSAPアドレスに関するケースのように予想される時です。 パーサは十六進法値で先行ゼロを拒絶しないものとします。
Both single-character and multi-character string values are enclosed in double quotes (i.e., "). By contrast, single quotes (i.e., ') are used for emphasizing keywords rather than to refer to characters or strings.
「単独のキャラクタとマルチ文字列値の両方が二重引用符に同封されます(すなわち」)。 '対照的に、シングル・クォーテション・マーク(すなわち')は、むしろキーワードを強調するのにキャラクタかストリングについて言及するより使用されます。
In the text representation of decimal and hex numbers, digits to the left are more significant than digits to the right.
小数と十六進法番号のテキスト表現では、左へのケタはケタより右に重要です。
2.3 Directionality Convention
2.3 方向性コンベンション
This section defined the meaning of the terms 'forward' and 'backward' as used in this document. This is specially applicable to parameters that have a specific direction associated with them.
このセクションはこのドキュメントで同じくらい中古の'フォワード'という用語と'後方'の意味を定義しました。 特に、これはそれらに関連している特定の方向を持っているパラメタに適切です。
In this document, 'forward' refers to the direction away from the ATM node under consideration, while 'backward' refers to the direction towards the ATM node. This convention must be used in all SDP-based session descriptions regardless of whether underlying bearer is an SVC, a dynamically allocated PVC/SPVC or a dynamically allocated CID. This is regardless of which side originates the service connection. If ATM SVC or AAL2 Q.2630.1 signaling is used, the directionality convention is independent of which side originates the SVC or AAL2 connection.
本書では、'フォワード'はATMノードから遠くと方向を考慮で呼びます、'後方に'はATMノードに向かった方向を示しますが。 基本的な運搬人がSVC、ダイナミックに割り当てられたPVC/SPVCまたはダイナミックに割り当てられたCIDであることにかかわらずすべてのSDPベースのセッション記述にこのコンベンションを使用しなければなりません。 どの側がサービス連結部を溯源するかにかかわらずこれはあります。 ATM SVCかAAL2 Q.2630.1シグナリングが使用されているなら、どの側がSVCかAAL2接続を溯源するかから方向性コンベンションは独立しています。
This provides a simple way of identifying the direction in which a parameter is applicable, in a manner that is independent of the underlying ATM or AAL2 bearer. This simplicity comes at a price, described below.
これはパラメタが適切である方向を特定する簡単な方法を提供します、基本的なATMかAAL2運搬人から独立している方法で。 この簡単さは以下で説明された価格で来ます。
The convention used by all ATM/AAL2 signaling specifications (e.g., Q.2931 Section 1.3.3 and Q.2630.1) mandates that forward direction is from the end initiating setup/establishment via bearer signaling towards the end receiving the setup/establishment request. The backward direction is in the opposite direction. In some cases, the 'forward' and 'backward' directions of the ATM signaling convention
すべてのATM/AAL2シグナリング仕様(例えば、Q.2931セクション1.3の.3とQ.2630.1)で使用されるコンベンションは、順方向がセットアップ/設立が要求する終わりの受信に向かった運搬人シグナリングでセットアップ/設立を開始しながら終わりからあるのを強制します。 逆方向には逆方向があります。 いくつかの場合ATMシグナリングコンベンションの'前進'の、そして、'後方'の方向
Kumar & Mostafa Standards Track [Page 6] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[6ページ]。
might be the exact opposite of the SDP convention described above, requiring the media gateway to perform the necessary translation. An example case in which this is needed is described below.
必要な翻訳を実行するためにメディアゲートウェイを必要として、上で説明されたSDPコンベンションの正反対はそうですか? これが必要である例の場合は以下で説明されます。
Consider an SDP description sent by a media gateway controller to the gateway originating a service-level call. In the backward SVC call set-up model, this gateway terminates (rather than originates) an SVC call. The media gateway refers to the traffic descriptor (and hence the PCR) in the direction away from this gateway as the forward traffic descriptor and forward PCR. Clearly, this is at odds with ATM SVC signaling which refers to this very PCR as the backward PCR. The gateway needs to be able to perform the required swap of directions. In this example, the media gateway terminating the service level call (and hence originating the SVC call) does not need to perform this swap.
SDPがメディアゲートウェイコントローラによって送られた記述であるとサービスレベル呼び出しを溯源するゲートウェイと考えてください。 遅れているSVC呼び出しセットアップモデルでは、このゲートウェイが終わる、(むしろ、起因する、)、SVC呼び出し。 メディアゲートウェイは前進のトラフィック記述子と前進のPCRとして方向によるトラフィック記述子(そして、したがって、PCR)をこのゲートウェイから遠くと呼びます。 明確に、これはこのまさしくそのPCRを後方のPCRと呼ぶATM SVCシグナリングと仲たがいしてあります。 ゲートウェイは、方向の必要なスワッピングを実行できる必要があります。 この例では、サービスレベル要求(したがって、SVC呼び出しを溯源して)を終えるメディアゲートウェイはこのスワッピングを実行する必要はありません。
Certain parameters within attributes are defined exclusively for the forward or backward directions. Examples for the forward direction are the <fsssar> subparameter within the 'aal2sscs3661unassured' media attribute line, the <fsssar>, <fsscopsdu> and <fsscopuu> subparameters within the 'aal2sscs3661assured' media attribute line, the <fsscopsdu> and <fsscopuu> subparameters within the 'aal5sscop' media attribute line, and the <fmaxFrame> parameter within the 'aal2sscs3662' media attribute line. Examples for the backward direction are the <bsssar> subparameter within the 'aal2sscs3661unassured' media attribute line, the <bsssar>, <bsscopsdu> and <bsscopuu> subparameters within the 'aal2sscs3661assured' media attribute line, the <bsscopsdu> and <bsscopuu> subparameters within the 'aal5sscop' media attribute line, and the <bmaxFrame> parameter within the 'aal2sscs3662' media attribute line.
属性の中のあるパラメタは排他的にフォワードか逆方向のために定義されます。 順方向のための例は、'aal5sscop'メディア属性の中の「副-パラメタ」が裏打ちする'aal2sscs3661assured'メディア属性の中のメディアの属性系列、<fsssar>、<fsscopsdu>、および<fsscopuu>「副-パラメタ」が裏打ちする'aal2sscs3661unassured'、<fsscopsdu>、および<fsscopuu>の中の<fsssar>「副-パラメタ」と、メディアが結果と考える'aal2sscs3662'系列の中の<fmaxFrame>パラメタです。 逆方向のための例は、'aal5sscop'メディア属性の中の「副-パラメタ」が裏打ちする'aal2sscs3661assured'メディア属性の中のメディアの属性系列、<bsssar>、<bsscopsdu>、および<bsscopuu>「副-パラメタ」が裏打ちする'aal2sscs3661unassured'、<bsscopsdu>、および<bsscopuu>の中の<bsssar>「副-パラメタ」と、メディアが結果と考える'aal2sscs3662'系列の中の<bmaxFrame>パラメタです。
2.4 Case convention
2.4 ケースコンベンション
As defined in RFC 2327 [1], SDP syntax is case-sensitive. Since these ATM conventions conform strictly with SDP syntax, they are case-sensitive. SDP line types (e.g., "c", "m", "o", "a") and fields in the SDP lines should be built according to the case conventions in [1] and in this document. It is suggested, but not required, that SDP parsers for ATM applications be case-tolerant where ignoring case does not result in ambiguity. Encoding names, which are defined outside the SDP protocol, are case-insensitive.
RFC2327[1]で定義されるように、SDP構文は大文字と小文字を区別しています。 これらのATMコンベンションが厳密にSDP構文に従うので、それらは大文字と小文字を区別しています。 ケースコンベンションによると、SDP系列におけるSDP系列タイプ(例えば、「c」、「m」、「o」“a")と分野は[1]に本書では造られるべきです。 示されますが、ATMアプリケーションのためのSDPパーサはケースを無視するのがあいまいさをもたらさないところでケース許容性があるのが必要ではありません。 コード化名(SDPプロトコルの外で定義される)は大文字と小文字を区別しないです。
Kumar & Mostafa Standards Track [Page 7] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[7ページ]。
2.5 Use of special characters in SDP parameter values
2.5 SDPパラメタ値における特殊文字の使用
In general, RFC 2327-conformant string values of SDP parameters [1] do not include special characters that are neither alphabets nor digits. An exception is the "/" character used in the value "RTP/AVP" of transport sub-field of the 'm' line.
一般に、SDPパラメタ[1]のRFC 2327-conformantストリング値はアルファベットでなくてまたケタでない特殊文字を、含んでいません。 '、「例外がそうである、」 」 キャラクタが輸送サブ分野の値の"RTP/AVP"で使用した/、'立ち並んでください。
String values used in SDP descriptions of ATM connections retain this convention, while allowing the use of the special character "/" in a manner commensurate with [1]. In addition, the special characters "$" and "-" are used in the following manner. A "$" value is a wildcard that allows the recipient of the SDP description to select any permitted value of the parameter. A "-" value indicates that it is not necessary to specify the value of the parameter in the SDP description because this parameter is irrelevant for this application, or because its value can be known from another source such as provisioning, defaults, another protocol, another SDP descriptor or another part of the same SDP descriptor. If the use of these special characters is construed as a violation of RFC 2327 [1] syntax, then reserved string values can be used. The string "CHOOSE" can be used in lieu of "$". The string "OMIT" can be used in lieu of "-" for an omitted parameter.
[1]について等しい方法で「ATM接続のSDP記述に使用されるストリング値は特殊文字の使用に」 /を許容している間、このコンベンションを保有します」。 さらに、特殊文字「$」と「-」は以下の方法で使用されます。 「$」値はSDP記述の受取人がパラメタのどんな受入れられた値も選択できるワイルドカードです。 このアプリケーションに、このパラメタが無関係であるか、または同じSDP記述子の食糧を供給することなどの別の源、デフォルト、別のプロトコル、別のSDP記述子または別の部分から値は知ることができるので、「-」値は、SDP記述における、パラメタの値を指定するのは必要でないことを示します。 これらの特殊文字の使用がRFC2327[1]構文の違反に理解されているなら、予約されたストリング値を使用できます。 「$」の代わりにストリング「選んでください」を使用できます。 省略されたパラメタのための「-」の代わりにストリング「省略」を使用できます。
3. Capabilities Provided by SDP conventions
3. SDPコンベンションによる能力Provided
To support the applications listed in section 1, the SDP conventions in this document provide the following session control capabilities:
セクション1で記載されたアプリケーションをサポートするために、SDPコンベンションは本書では以下のセッション制御能力を提供します:
* Identification of the underlying bearer network type as ATM.
* ATMとしての基本的な基幹ネットワークタイプの識別。
* Identification by an ATM network element of its own address, in
one of several possible formats. A connection peer can
initiate SVC set-up to this address. A call agent or
connection peer can select an pre-established bearer path to
this address.
* いくつかの可能な形式の1つのそれ自身のアドレスのATMネットワーク原理に従った識別。 接続同輩はSVCセットアップにこのアドレスに着手できます。 呼び出しエージェントか接続同輩がプレ確立した運搬人道をこのアドレスに選択できます。
* Identification of the ATM bearer connection that is to be bound
to the service-level connection. Depending on the application,
this is either a VCC or a subchannel (identified by a CID)
within a VCC.
* サービスレベル接続に縛られることになっているATM運搬人接続の識別。 アプリケーションによって、これは、VCCの中のVCCかサブチャネル(CIDによって特定される)のどちらかです。
* Identification of media type: audio, video, data.
* メディアタイプの識別: オーディオ、ビデオ、データ。
* In AAL1/AAL5 applications, declaration of a set of payload
types that can be bound to the ATM bearer connection. The
encoding names and payload types defined for use in the RTP
context [31] are re-used for AAL1 and AAL5, if applicable.
* AAL1/AAL5アプリケーション、ATM運搬人接続に縛ることができる1セットのペイロードタイプの宣言で。 RTP文脈[31]における使用のために定義されたコード化名とペイロードタイプは、AAL1とAAL5に再中古であって、適切です。
Kumar & Mostafa Standards Track [Page 8] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[8ページ]。
* In AAL2 applications, declaration of a set of profiles that can
be bound to the ATM bearer connection. A mechanism for
dynamically defining custom profiles within the SDP session
description is included. This allows the use of custom
profiles for connections that span multi-network interfaces.
* AAL2アプリケーション、ATM運搬人接続に縛ることができる1セットのプロフィールの宣言で。 SDPセッション記述の中でダイナミックにカスタムプロフィールを定義するためのメカニズムは含まれています。 これはカスタムプロフィールのマルチネットワークインタフェースにかかる接続の使用を許します。
* A means of correlating service-level connections with
underlying ATM bearer connections. The backbone network
connection identifier or bnc-id specified in ITU Q.1901 [36]
standardization work is used for this purpose. In order to
provide a common SDP base for applications based on Q.1901 and
SIP/SIP+, the neutral term 'eecid' is used in lieu of 'bnc-id'
in the SDP session descriptor.
* 基本的なATM運搬人接続とのサービスレベル接続を関連させる手段。 ITU Q.1901[36]標準化仕事で指定されたバックボーンネットワーク接続識別子かbnc-イドがこのために使用されます。 Q.1901に基づくアプリケーションとSIP/SIPのための一般的なSDPベースに+、中立を提供するために、用語'eecid'はSDPセッション記述子の'bnc-イド'の代わりに使用されます。
* A means of mapping codec types and packetization periods into
service types (voice, voiceband data and facsimile). This is
useful in determining the encoding to use when the connection
is upspeeded in response to modem or facsimile tones.
* コーデックタイプとpacketizationの期間をサービスに写像する手段は(声、voicebandデータ、およびファクシミリ)をタイプします。 これは使用するコード化か接続がモデムに対応してupspeededされるとファクシミリトーンを決定する際に役に立ちます。
* A means of describing the adaptation type, QoS class, ATM
transfer capability/service category, broadband bearer class,
traffic parameters, CPS parameters and SSCS parameters related
the underlying bearer connection.
* 適合タイプ、QoSのクラス、ATM転送能力/サービスカテゴリ、広帯域の運搬人のクラス、トラフィックパラメタ、CPSパラメタ、およびSSCSパラメタについて説明する手段は基本的な運搬人接続を関係づけました。
* Means for enabling or describing special functions such as
leaf- initiated-join, anycast and SVC caching.
* -anycastとSVC、葉などの特別な機能について可能にするために意味するか、または説明して、開始されて、接合してください。キャッシュします。
* For H.323 Annex C applications, a means of specifying the IP
address and port number on which the node will receive RTCP
messages.
* H.323 Annex Cアプリケーションのために、IPを指定する手段は、ノードがRTCPメッセージを受け取る数を扱って、移植します。
* A means of chaining consecutive SDP descriptors so that they
refer to different layers of the same connection.
* 彼らが異なった層の同じ接続について言及するように連続したSDP記述子をチェーニングする手段。
4. Format of the ATM Session Description
4. 気圧セッション記述の形式
The sequence of lines in the session descriptions in this document conforms to RFC 2327 [1]. In general, a session description consists of a session-level part followed by zero or more media-level parts. ATM session descriptions consist of a session-level part followed by one or two media-level parts. The only two media applicable are the ATM bearer medium and RTCP control (where applicable).
セッション記述における、系列の系列は本書ではRFC2327[1]に従います。 一般に、セッション記述はゼロがあとに続いたセッションレベル部分か、よりメディア平らな部分から成ります。 ATMセッション記述は1か2つのメディアレベルの部品があとに続いたセッションレベル部分から成ります。 適切な唯一の2つのメディアは、ATM運搬人媒体とRTCPコントロール(適切であるところ)です。
The session level part consists of the following lines:
セッションレベル部分は以下の系列から成ります:
v= (protocol version, zero or one line) o= (origin, zero or one line) s= (session name, zero or one line)
=(プロトコルバージョン、ゼロまたは1つの系列)o=(発生源、ゼロまたは1つの系列)s=に対して(セッション名、ゼロまたは1つの系列)
Kumar & Mostafa Standards Track [Page 9] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[9ページ]。
c= (connection information, one line) b= (bandwidth, zero or more lines) t= (timestamp, zero or one line) k= (encryption key, zero or one line)
c= (connection information, one line) b= (bandwidth, zero or more lines) t= (timestamp, zero or one line) k= (encryption key, zero or one line)
In ATM session descriptions, there are no media attribute lines in the session level part. These are present in the media-level parts.
In ATM session descriptions, there are no media attribute lines in the session level part. These are present in the media-level parts.
The media-level part for the ATM bearer consists of the following lines:
The media-level part for the ATM bearer consists of the following lines:
m= (media information and transport address, one line) b= (bandwidth, zero or more lines) k= (encryption key, zero or more lines) a= (media attribute, zero or more lines)
m= (media information and transport address, one line) b= (bandwidth, zero or more lines) k= (encryption key, zero or more lines) a= (media attribute, zero or more lines)
The media-level part for RTCP control consists of the following lines:
The media-level part for RTCP control consists of the following lines:
m= (media information and transport address, one line) c= (connection information for control only, one line)
m= (media information and transport address, one line) c= (connection information for control only, one line)
In general, the 'v', 'o', 's', and 't' lines are mandatory. However, in the Megaco [26] context, these lines have been made optional. The 'o', 's', and 't' lines are omitted in most MGCP [25] applications.
In general, the 'v', 'o', 's', and 't' lines are mandatory. However, in the Megaco [26] context, these lines have been made optional. The 'o', 's', and 't' lines are omitted in most MGCP [25] applications.
Note that SDP session descriptors for ATM can contain bandwidth (b=) and encryption key (k=) lines. Like all other lines, these lines should strictly conform to the SDP standard [1].
Note that SDP session descriptors for ATM can contain bandwidth (b=) and encryption key (k=) lines. Like all other lines, these lines should strictly conform to the SDP standard [1].
The bandwidth (b=) line is not necessarily redundant in the ATM context since, in some applications, it can be used to convey application-level information which does not map directly into the atmTrfcDesc media attribute line. For instance, the 'b' line can be used in SDP descriptors in RTSP commands to describe content bandwidth.
The bandwidth (b=) line is not necessarily redundant in the ATM context since, in some applications, it can be used to convey application-level information which does not map directly into the atmTrfcDesc media attribute line. For instance, the 'b' line can be used in SDP descriptors in RTSP commands to describe content bandwidth.
The encryption key line (k=) can be used to indicate an encryption key for the bearer, and a method to obtain the key. At present, the encryption of ATM and AAL2 bearers has not been conventionalized, unlike the encryption of RTP payloads. Nor has the authentication or encryption of ATM or AAL2 bearer signaling. In the ATM and AAL2 contexts, the term 'bearer' can include 'bearer signaling' as well as 'bearer payloads'.
The encryption key line (k=) can be used to indicate an encryption key for the bearer, and a method to obtain the key. At present, the encryption of ATM and AAL2 bearers has not been conventionalized, unlike the encryption of RTP payloads. Nor has the authentication or encryption of ATM or AAL2 bearer signaling. In the ATM and AAL2 contexts, the term 'bearer' can include 'bearer signaling' as well as 'bearer payloads'.
The order of lines in an ATM session description is exactly in the
RFC 2327-conformant order depicted above. However, there is no order
of the media attribute ('a') lines with respect to other 'a' lines.
The order of lines in an ATM session description is exactly in the RFC 2327-conformant order depicted above. However, there is no order of the media attribute ('a') lines with respect to other 'a' lines.
Kumar & Mostafa Standards Track [Page 10] RFC 3108 ATM SDP May 2001
Kumar & Mostafa Standards Track [Page 10] RFC 3108 ATM SDP May 2001
The SDP protocol version for session descriptions using these conventions is 0. In conformance with standard SDP, it is strongly recommended that the 'v' line be included at the beginning of each SDP session description. In some contexts such as Megaco, the 'v' line is optional and may be omitted unless several session descriptions are provided in sequence, in which case the 'v' line serves as a delimiter. Depending on the application, sequences of session descriptions might refer to:
The SDP protocol version for session descriptions using these conventions is 0. In conformance with standard SDP, it is strongly recommended that the 'v' line be included at the beginning of each SDP session description. In some contexts such as Megaco, the 'v' line is optional and may be omitted unless several session descriptions are provided in sequence, in which case the 'v' line serves as a delimiter. Depending on the application, sequences of session descriptions might refer to:
- Different connections or sessions. - Alternate ways of realizing the same connection or session. - Different layers of the same session (section 5.6.4.1).
- Different connections or sessions. - Alternate ways of realizing the same connection or session. - Different layers of the same session (section 5.6.4.1).
The 'o', 's' and 't' lines are included for strict conformance with RFC 2327. It is possible that these lines might not carry useful information in some ATM-based applications. Therefore, some applications might omit these lines, although it is recommended that they not do so. For maximum interoperability, it is preferable that SDP parsers not reject session descriptions that do not contain these lines.
The 'o', 's' and 't' lines are included for strict conformance with RFC 2327. It is possible that these lines might not carry useful information in some ATM-based applications. Therefore, some applications might omit these lines, although it is recommended that they not do so. For maximum interoperability, it is preferable that SDP parsers not reject session descriptions that do not contain these lines.
5. Structure of the Session Description Lines
5. Structure of the Session Description Lines
5.1 The Origin Line
5.1 The Origin Line
The origin line for an ATM-based session is structured as follows:
The origin line for an ATM-based session is structured as follows:
o=<username> <sessionID> <version> <networkType>
<addressType> <address>
o=<username> <sessionID> <version> <networkType> <addressType> <address>
The <username> is set to "-".
The <username> is set to "-".
The <sessionID> can be set to one of the following:
The <sessionID> can be set to one of the following:
* an NTP timestamp referring to the moment when the SDP session
descriptor was created.
* a Call ID, connection ID or context ID that uniquely identifies
the session within the scope of the ATM node. Since calls can
comprise multiple connections (sessions), call IDs are
generally not suitable for this purpose.
* an NTP timestamp referring to the moment when the SDP session descriptor was created. * a Call ID, connection ID or context ID that uniquely identifies the session within the scope of the ATM node. Since calls can comprise multiple connections (sessions), call IDs are generally not suitable for this purpose.
NTP time stamps can be represented as decimal or hex integers. The part of the NTP timestamp that refers to an integer number of seconds is sufficient. This is a 32-bit field
NTP time stamps can be represented as decimal or hex integers. The part of the NTP timestamp that refers to an integer number of seconds is sufficient. This is a 32-bit field
On the other hand, call IDs, connection IDs and context IDs can be can be 32 hex digits long.
On the other hand, call IDs, connection IDs and context IDs can be can be 32 hex digits long.
Kumar & Mostafa Standards Track [Page 11] RFC 3108 ATM SDP May 2001
Kumar & Mostafa Standards Track [Page 11] RFC 3108 ATM SDP May 2001
The <sessionID> field is represented as a decimal or hex number of up to 32 digits. A "0x" prefix is used before the hex representation. The <version> refers to the version of the SDP session descriptor (not that of the SDP protocol). This is can be set to one of the following:
The <sessionID> field is represented as a decimal or hex number of up to 32 digits. A "0x" prefix is used before the hex representation. The <version> refers to the version of the SDP session descriptor (not that of the SDP protocol). This is can be set to one of the following:
* 0.
* an NTP timestamp referring to the moment when the SDP session
descriptor was modified. If the SDP session descriptor has not
been modified by an intermediate entity (such as an MGC), then
the <version> timestamp will be the same as the <sessionId>
timestamp, if any. As with the <sessionId>, only the integer
part of the NTP timestamp is used.
* 0. * an NTP timestamp referring to the moment when the SDP session descriptor was modified. If the SDP session descriptor has not been modified by an intermediate entity (such as an MGC), then the <version> timestamp will be the same as the <sessionId> timestamp, if any. As with the <sessionId>, only the integer part of the NTP timestamp is used.
When equated to the integer part of an NTP timestamp, the <version> field is 10 digits wide. This is more restricted than [1], which allows unlimited size. As in [1], the most significant digit is non-zero when an NTP timestamp is used.
When equated to the integer part of an NTP timestamp, the <version> field is 10 digits wide. This is more restricted than [1], which allows unlimited size. As in [1], the most significant digit is non-zero when an NTP timestamp is used.
The <networkType> in SDP session descriptions for ATM applications should be assigned the string value "ATM" or wildcarded to a "$" or "-".
The <networkType> in SDP session descriptions for ATM applications should be assigned the string value "ATM" or wildcarded to a "$" or "-".
The <addressType> and <address> parameters are identical to those
for the connection information ('c') line (Section 5.3). Each of
these parameters can be wildcarded per the conventions described for
the 'c' line in Section 5.3. These parameters should not me omitted
since this would violate SDP syntax [1].
The <addressType> and <address> parameters are identical to those for the connection information ('c') line (Section 5.3). Each of these parameters can be wildcarded per the conventions described for the 'c' line in Section 5.3. These parameters should not me omitted since this would violate SDP syntax [1].
As with the 'c' line, SDP parsers are not expected to check the consistency of <networkType> with <addressType>, <address> pairs. The <addressType> and <address> need to be consistent with each other.
As with the 'c' line, SDP parsers are not expected to check the consistency of <networkType> with <addressType>, <address> pairs. The <addressType> and <address> need to be consistent with each other.
5.2 The Session Name Line
5.2 The Session Name Line
In general, the session name line is structured as follows:
In general, the session name line is structured as follows:
s=<sessionName>
s=<sessionName>
For ATM-based sessions, the <sessionName> parameter is set to a "-". The resulting line is:
For ATM-based sessions, the <sessionName> parameter is set to a "-". The resulting line is:
s=-
s=-
Kumar & Mostafa Standards Track [Page 12] RFC 3108 ATM SDP May 2001
Kumar & Mostafa Standards Track [Page 12] RFC 3108 ATM SDP May 2001
5.3 The Connection Information Line
5.3 The Connection Information Line
In general, the connection information line [1] is structured as follows:
In general, the connection information line [1] is structured as follows:
c=<networkType> <addressType> <address>
c=<networkType> <addressType> <address>
For ATM networks, additional values of <networkType>, <addressType> and <address> are defined, over and above those listed in [1]. The ABNF syntax (Section 9) for ATM SDP does not limit the ways in which <networkType> can be combined with <addressType>, <address> pairs. However, some combinations will not be valid in certain applications, while others will never be valid. Invalid combinations should be rejected by application-specific functions, and not by generic parsers. The ABNF syntax does limit the ways in which <addressType> and <address> can be paired.
For ATM networks, additional values of <networkType>, <addressType> and <address> are defined, over and above those listed in [1]. The ABNF syntax (Section 9) for ATM SDP does not limit the ways in which <networkType> can be combined with <addressType>, <address> pairs. However, some combinations will not be valid in certain applications, while others will never be valid. Invalid combinations should be rejected by application-specific functions, and not by generic parsers. The ABNF syntax does limit the ways in which <addressType> and <address> can be paired.
For ATM networks, the value of <networkType> should be set to "ATM".
Further, this may be wildcarded to "$" or "-". If this is done, an
node using ATM as the basic transport mechanism will select a value
of "ATM". A node that interfaces with multiple network types ("IN",
"ATM" etc.) that include ATM can also choose a value of "ATM".
For ATM networks, the value of <networkType> should be set to "ATM". Further, this may be wildcarded to "$" or "-". If this is done, an node using ATM as the basic transport mechanism will select a value of "ATM". A node that interfaces with multiple network types ("IN", "ATM" etc.) that include ATM can also choose a value of "ATM".
When the SDP description is built by a node such as a media gateway, the <address> refers to the address of the node building the SDP description. When this description is forwarded to another node, it still contains the original node's address. When the media gateway controller builds part or all of the SDP description, the local descriptor contains the address of the local node, while the remote descriptor contains the address of the remote node. If the <address> and/or <addressType> are irrelevant or are known by other means, they can be set to a "$" or a "-", as described below.
When the SDP description is built by a node such as a media gateway, the <address> refers to the address of the node building the SDP description. When this description is forwarded to another node, it still contains the original node's address. When the media gateway controller builds part or all of the SDP description, the local descriptor contains the address of the local node, while the remote descriptor contains the address of the remote node. If the <address> and/or <addressType> are irrelevant or are known by other means, they can be set to a "$" or a "-", as described below.
Additionally, in all contexts, the 'm' line can have an ATM address in the <virtualConnectionId> subparameter which, if present, is the remote address if the 'c' line address is local, and vice versa.
Additionally, in all contexts, the 'm' line can have an ATM address in the <virtualConnectionId> subparameter which, if present, is the remote address if the 'c' line address is local, and vice versa.
For ATM networks, the <addressType> can be NSAP, E164 or GWID (ALIAS). For ATM networks, the <address> syntax depends on the syntax of the <addressType>. SDP parsers should check the consistency of <addressType> with <address>.
For ATM networks, the <addressType> can be NSAP, E164 or GWID (ALIAS). For ATM networks, the <address> syntax depends on the syntax of the <addressType>. SDP parsers should check the consistency of <addressType> with <address>.
NSAP: If the addressType is NSAP, the address is expressed in the standard dotted hex form. This is a string of 40 hex digits, with dots after the 2nd, 6th, 10th, 14th, 18th, 22nd, 26th, 30th, 34th and 38th digits. The last octet of the NSAP address is the 'selector' field that is available for non-standard use. An example of a line with an NSAP address is:
NSAP: If the addressType is NSAP, the address is expressed in the standard dotted hex form. This is a string of 40 hex digits, with dots after the 2nd, 6th, 10th, 14th, 18th, 22nd, 26th, 30th, 34th and 38th digits. The last octet of the NSAP address is the 'selector' field that is available for non-standard use. An example of a line with an NSAP address is:
Kumar & Mostafa Standards Track [Page 13] RFC 3108 ATM SDP May 2001
Kumar & Mostafa Standards Track [Page 13] RFC 3108 ATM SDP May 2001
c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
A "0x" prefix shall not be used in this case since this is always in hexadecimal format.
A "0x" prefix shall not be used in this case since this is always in hexadecimal format.
E164: If the addressType is E164, the address is expressed as a decimal number with up to 15 digits. For example:
E164: If the addressType is E164, the address is expressed as a decimal number with up to 15 digits. For example:
c=ATM E164 9738294382
c=ATM E164 9738294382
The use of E.164 numbers in the B-ISDN context is defined in ITU E.191. There is a disparity between the ATM forum and the ITU in the use of E.164 numbers for ATM addressing. The ATM forum (e.g., UNI Signaling 4.0) allows only International Format E.164 numbers, while the ITU (e.g., Q.2931) allows private numbering plans. Since the goal of this SDP specification is to interoperate with all bearer signaling protocols, it allows the use of numbers that do not conform to the E.164 International Format. However, to maximize overall consistency, network administrators can restrict the provisioning of numbers to the E.164 International Format.
The use of E.164 numbers in the B-ISDN context is defined in ITU E.191. There is a disparity between the ATM forum and the ITU in the use of E.164 numbers for ATM addressing. The ATM forum (e.g., UNI Signaling 4.0) allows only International Format E.164 numbers, while the ITU (e.g., Q.2931) allows private numbering plans. Since the goal of this SDP specification is to interoperate with all bearer signaling protocols, it allows the use of numbers that do not conform to the E.164 International Format. However, to maximize overall consistency, network administrators can restrict the provisioning of numbers to the E.164 International Format.
GWID (ALIAS): If the addressType is GWID, it means that the address
is a Gateway Identifier or Node Alias. This may or may not be
globally unique. In this format, the address is expressed as an
alphanumeric string ("A"-"Z", "a"-"z", "0" - "9",".","-","_"). For
example:
GWID (ALIAS): If the addressType is GWID, it means that the address is a Gateway Identifier or Node Alias. This may or may not be globally unique. In this format, the address is expressed as an alphanumeric string ("A"-"Z", "a"-"z", "0" - "9",".","-","_"). For example:
c=ATM GWID officeABCmgx101vism12
c=ATM GWID officeABCmgx101vism12
Since these SDP conventions can be used for more than gateways, the string "ALIAS" can be used instead of "GWID" in the 'c' line. Thus, the example above is equivalent to:
Since these SDP conventions can be used for more than gateways, the string "ALIAS" can be used instead of "GWID" in the 'c' line. Thus, the example above is equivalent to:
c=ATM ALIAS officeABCmgx101vism12
c=ATM ALIAS officeABCmgx101vism12
An example of a GWID (ALIAS)is the CLLI code used for telecom equipment. For all practical purposes, it should be adequate for the GWID (ALIAS) to be a variable length string with a maximum size of 32 characters.
An example of a GWID (ALIAS)is the CLLI code used for telecom equipment. For all practical purposes, it should be adequate for the GWID (ALIAS) to be a variable length string with a maximum size of 32 characters.
The connection information line is always present in an SDP session descriptor. However, each of the parameters on this line can be wildcarded to a "$" or a "-", independently of whether other parameters on this line are wildcarded or not. Not all syntactically legal wildcard combinations are meaningful in a particular application.
The connection information line is always present in an SDP session descriptor. However, each of the parameters on this line can be wildcarded to a "$" or a "-", independently of whether other parameters on this line are wildcarded or not. Not all syntactically legal wildcard combinations are meaningful in a particular application.
Kumar & Mostafa Standards Track [Page 14] RFC 3108 ATM SDP May 2001
Kumar & Mostafa Standards Track [Page 14] RFC 3108 ATM SDP May 2001
Examples of meaningful wildcard combinations in the ATM context are:
Examples of meaningful wildcard combinations in the ATM context are:
c=- - -
c=$ $ $
c=ATM - -
c=ATM $ $
c=ATM <addressType> -
c=ATM <addressType> $
c=- - - c=$ $ $ c=ATM - - c=ATM $ $ c=ATM <addressType> - c=ATM <addressType> $
Specifying the ATM address type without specifying the ATM address is useful when the recipient is asked to select an ATM address of a certain type (NSAP, E.164 etc.).
Specifying the ATM address type without specifying the ATM address is useful when the recipient is asked to select an ATM address of a certain type (NSAP, E.164 etc.).
Examples of syntactically legal wildcard combinations of dubious utility are:
Examples of syntactically legal wildcard combinations of dubious utility are:
c=- $ -
c=- $ $
c=- <addressType> -
c=$ <addressType> $
c=- <addressType> <address>
c=$ <addressType> <address>
c=- $ - c=- $ $ c=- <addressType> - c=$ <addressType> $ c=- <addressType> <address> c=$ <addressType> <address>
Note that <addressType> and/or <address> should not omitted without being set to a "-" or "$" since this would violate basic SDP syntax [1].
Note that <addressType> and/or <address> should not omitted without being set to a "-" or "$" since this would violate basic SDP syntax [1].
5.4 The Timestamp Line
5.4 The Timestamp Line
The timestamp line for an SDP session descriptor is structured as follows:
The timestamp line for an SDP session descriptor is structured as follows:
t= <startTime> <stopTime>
t= <startTime> <stopTime>
Per Ref. [49], NTP time stamps use a 32 bit unsigned representation of seconds, and a 32 bit unsigned representation of fractional seconds. For ATM-based sessions, the <startTime>parameter can be made equal to the NTP timestamp referring to the moment when the SDP session descriptor was created. It can also be set to 0 indicating its irrelevance. If it made equal to the NTP timestamp in seconds, the fractional part of the NTP timestamp is omitted. When equated to the integer part of an NTP timestamp, the <startTime> field is 10 digits wide. This is more restricted than [1], which allows unlimited size. As in [1], the most significant digit is non-zero when an NTP timestamp is used.
Per Ref. [49], NTP time stamps use a 32 bit unsigned representation of seconds, and a 32 bit unsigned representation of fractional seconds. For ATM-based sessions, the <startTime>parameter can be made equal to the NTP timestamp referring to the moment when the SDP session descriptor was created. It can also be set to 0 indicating its irrelevance. If it made equal to the NTP timestamp in seconds, the fractional part of the NTP timestamp is omitted. When equated to the integer part of an NTP timestamp, the <startTime> field is 10 digits wide. This is more restricted than [1], which allows unlimited size. As in [1], the most significant digit is non-zero when an NTP timestamp is used.
The <stopTime> parameter is set to 0 for ATM-based SDP descriptors.
The <stopTime> parameter is set to 0 for ATM-based SDP descriptors.
Kumar & Mostafa Standards Track [Page 15] RFC 3108 ATM SDP May 2001
Kumar & Mostafa Standards Track [Page 15] RFC 3108 ATM SDP May 2001
5.5 Media Information Line for ATM connections
5.5 Media Information Line for ATM connections
The general format of the media information line adapted for AAL1 and AAL5 applications is:
The general format of the media information line adapted for AAL1 and AAL5 applications is:
m=<media> <virtualConnectionId> <transport> <format list>
m=<media> <virtualConnectionId> <transport> <format list>
The general format of the media information line adapted for AAL2 applications is:
The general format of the media information line adapted for AAL2 applications is:
m=<media> <virtualConnectionId> <transport#1> <format list#1>
<transport#2> <format list#2> ... <transport#M> <format list#M>
m=<media> <virtualConnectionId> <transport#1> <format list#1> <transport#2> <format list#2> ... <transport#M> <format list#M>
Note that <virtualConnectionId> is equivalent to <port> in [1].
Note that <virtualConnectionId> is equivalent to <port> in [1].
The subparameter <media> can take on all the values defined in [1]. These are: "audio", "video", "application", "data" and "control".
The subparameter <media> can take on all the values defined in [1]. These are: "audio", "video", "application", "data" and "control".
When the <transport> parameter has more than one value in the 'm' line, the <transport> <format list> pairs can be arranged in preferential order.
When the <transport> parameter has more than one value in the 'm' line, the <transport> <format list> pairs can be arranged in preferential order.
5.5.1 The Virtual Connection ID
5.5.1 The Virtual Connection ID
In applications in which the media-level part of a session descriptor is bound to an ATM virtual circuit, the <virtualConnectionId> can be in one of the following formats:
In applications in which the media-level part of a session descriptor is bound to an ATM virtual circuit, the <virtualConnectionId> can be in one of the following formats:
* <ex_vcci>
* <addressType>-<address>/<ex_vcci>
* <address>/<ex_vcci>
* <ex_bcg>/<ex_vcci>
* <ex_portId>/<ex_vpi>/<ex_vci>
* <ex_bcg>/<ex_vpi>/<ex_vci>
* <ex_vpci>/<ex_vci>
* <addressType>-<address>/<ex_vpci>/<ex_vci>
* <address>/<ex_vpci>/<ex_vci>
* <ex_vcci> * <addressType>-<address>/<ex_vcci> * <address>/<ex_vcci> * <ex_bcg>/<ex_vcci> * <ex_portId>/<ex_vpi>/<ex_vci> * <ex_bcg>/<ex_vpi>/<ex_vci> * <ex_vpci>/<ex_vci> * <addressType>-<address>/<ex_vpci>/<ex_vci> * <address>/<ex_vpci>/<ex_vci>
In applications in which the media-level part of a session descriptor is bound to a subchannel within an ATM virtual circuit, the <virtualConnectionId> can be in one of the following formats:
In applications in which the media-level part of a session descriptor is bound to a subchannel within an ATM virtual circuit, the <virtualConnectionId> can be in one of the following formats:
* <ex_vcci>/<ex_cid>
* <addressType>-<address>/<ex_vcci>/<ex_cid>
* <address>/<ex_vcci>/<ex_cid>
* <ex_bcg>/<ex_vcci>/<ex_cid>
* <ex_portId>/<ex_vpi>/<ex_vci>/<ex_cid>
* <ex_bcg>/<ex_vpi>/<ex_vci>/<ex_cid>
* <ex_vcci>/<ex_cid> * <addressType>-<address>/<ex_vcci>/<ex_cid> * <address>/<ex_vcci>/<ex_cid> * <ex_bcg>/<ex_vcci>/<ex_cid> * <ex_portId>/<ex_vpi>/<ex_vci>/<ex_cid> * <ex_bcg>/<ex_vpi>/<ex_vci>/<ex_cid>
Kumar & Mostafa Standards Track [Page 16] RFC 3108 ATM SDP May 2001
Kumar & Mostafa Standards Track [Page 16] RFC 3108 ATM SDP May 2001
* <ex_vpci>/<ex_vci>/<ex_cid>
* <addressType>-<address>/<ex_vpci>/<ex_vci>/<ex_cid>
* <address>/<ex_vpci>/<ex_vci>/<ex_cid>
* <ex_vpci>/<ex_vci>/<ex_cid> * <addressType>-<address>/<ex_vpci>/<ex_vci>/<ex_cid> * <address>/<ex_vpci>/<ex_vci>/<ex_cid>
Here,
Here,
<ex_vcci> = VCCI-<vcci>
<ex_vpci> = VPCI-<vpci>
<ex_bcg> = BCG-<bcg>
<ex_portId> = PORT-<portId>
<ex_vpi> = VPI-<vpi>
<ex_vci> = VCI-<vci>
<ex_cid> = CID-<cid>
<ex_vcci> = VCCI-<vcci> <ex_vpci> = VPCI-<vpci> <ex_bcg> = BCG-<bcg> <ex_portId> = PORT-<portId> <ex_vpi> = VPI-<vpi> <ex_vci> = VCI-<vci> <ex_cid> = CID-<cid>
The <vcci>, <vpi>, <vci>, <vpci> and <cid> are decimal numbers or hexadecimal numbers. An "0x" prefix is used before their values when they are in the hex format.
The <vcci>, <vpi>, <vci>, <vpci> and <cid> are decimal numbers or hexadecimal numbers. An "0x" prefix is used before their values when they are in the hex format.
The <portId> is always a hexadecimal number. An "0x" prefix is not used with it.
The <portId> is always a hexadecimal number. An "0x" prefix is not used with it.
The <addressType> and <address> are identical to their definitions above for the connection information line with the difference that this address refers to the remote peer in the media information line. Since the <virtualConnectionId>, as defined here, is meant for use in ATM networks, the values of <addressType> and <address> in the <virtualConnectionId> are limited to ATM-specific values.
The <addressType> and <address> are identical to their definitions above for the connection information line with the difference that this address refers to the remote peer in the media information line. Since the <virtualConnectionId>, as defined here, is meant for use in ATM networks, the values of <addressType> and <address> in the <virtualConnectionId> are limited to ATM-specific values.
The <vpi>, <vci> and <cid> are the Virtual Path Identifier, Virtual Circuit Identifier and Channel Identifier respectively. The <vpi> is an 8 or 12 bit field. The <vci> is a 16-bit field. The <cid> is an 8-bit field ([8] and [11]). For AAL1 applications, it corresponds to the channel number defined in Annex C of [8].
The <vpi>, <vci> and <cid> are the Virtual Path Identifier, Virtual Circuit Identifier and Channel Identifier respectively. The <vpi> is an 8 or 12 bit field. The <vci> is a 16-bit field. The <cid> is an 8-bit field ([8] and [11]). For AAL1 applications, it corresponds to the channel number defined in Annex C of [8].
The <vpci> is a 16-bit field defined in Section 4.5.16 of ITU Q.2931 [Ref. 15]. The <vpci> is similar to the <vpi>, except for its width and the fact that it retains its value across VP crossconnects. In some applications, the size of the <vpci> is the same as the size of the <vpi> (8 or 12 bits). In this case, the most significant 8 or 4 bits are ignored.
The <vpci> is a 16-bit field defined in Section 4.5.16 of ITU Q.2931 [Ref. 15]. The <vpci> is similar to the <vpi>, except for its width and the fact that it retains its value across VP crossconnects. In some applications, the size of the <vpci> is the same as the size of the <vpi> (8 or 12 bits). In this case, the most significant 8 or 4 bits are ignored.
The <vcci> is a 16-bit field defined in ITU Recommendation Q.2941.2 [32]. The <vcci> is similar to the <vci>, except for the fact that it retains its value across VC crossconnects.
The <vcci> is a 16-bit field defined in ITU Recommendation Q.2941.2 [32]. The <vcci> is similar to the <vci>, except for the fact that it retains its value across VC crossconnects.
In general, <vpci> and <vcci> values are unique between a pair of nodes. When they are unique between a pair of nodes but not unique within a network, they need to be qualified, at any node, by the ATM
In general, <vpci> and <vcci> values are unique between a pair of nodes. When they are unique between a pair of nodes but not unique within a network, they need to be qualified, at any node, by the ATM
Kumar & Mostafa Standards Track [Page 17] RFC 3108 ATM SDP May 2001
Kumar & Mostafa Standards Track [Page 17] RFC 3108 ATM SDP May 2001
address of the remote node. These parameters can be pre-provisioned or signaled. When signaled, the <vpci> is encapsulated in the connection identifier information element of SVC signaling messages. The <vcci> is encapsulated in the Generic Information Transport (GIT) information element of SVC signaling messages. In an ATM node pair, either node can assign <vcci> values and signal it to the other end via SVC signaling. A glare avoidance scheme is defined in [32] and [44]. This mechanism works in SVC applications. A different glare avoidance technique is needed when a pool of existing PVCs/SPVCs is dynamically assigned to calls. One such scheme for glare reduction is the assignment of <vcci> values from different ends of the <vcci> range, using the lowest or highest available value as applicable.
address of the remote node. These parameters can be pre-provisioned or signaled. When signaled, the <vpci> is encapsulated in the connection identifier information element of SVC signaling messages. The <vcci> is encapsulated in the Generic Information Transport (GIT) information element of SVC signaling messages. In an ATM node pair, either node can assign <vcci> values and signal it to the other end via SVC signaling. A glare avoidance scheme is defined in [32] and [44]. This mechanism works in SVC applications. A different glare avoidance technique is needed when a pool of existing PVCs/SPVCs is dynamically assigned to calls. One such scheme for glare reduction is the assignment of <vcci> values from different ends of the <vcci> range, using the lowest or highest available value as applicable.
When <vpci> and <vcci> values are pre-provisioned, administrations have the option of provisioning them uniquely in a network. In this case, the ATM address of the far end is not needed to qualify these parameters.
When <vpci> and <vcci> values are pre-provisioned, administrations have the option of provisioning them uniquely in a network. In this case, the ATM address of the far end is not needed to qualify these parameters.
In the AAL2 context, the definition of a VCC implies that there is no CID-level switching between its ends. If either end can assign <cid> values, then a glare reduction mechanism is needed. One such scheme for glare reduction is the assignment of <cid> values from different ends of the <cid> range, using the lowest or highest available value as applicable.
In the AAL2 context, the definition of a VCC implies that there is no CID-level switching between its ends. If either end can assign <cid> values, then a glare reduction mechanism is needed. One such scheme for glare reduction is the assignment of <cid> values from different ends of the <cid> range, using the lowest or highest available value as applicable.
The <portId> parameter is used to identify the physical trunk port on an ATM module. It can be represented as a hexadecimal number of up to 32 hex digits.
The <portId> parameter is used to identify the physical trunk port on an ATM module. It can be represented as a hexadecimal number of up to 32 hex digits.
In some applications, it is meaningful to bundle a set of connections between a pair of ATM nodes into a bearer connection group. The <bcg> subparameter is an eight bit field that allows the bundling of up to 255 VPCs or VCCs.
In some applications, it is meaningful to bundle a set of connections between a pair of ATM nodes into a bearer connection group. The <bcg> subparameter is an eight bit field that allows the bundling of up to 255 VPCs or VCCs.
In some applications, it is necessary to wildcard the <virtualConnectionId> parameter, or some elements of this parameter. The "$" wildcard character can be substituted for the entire <virtualConnectionId> parameter, or some of its terms. In the latter case, the constant strings that qualify the terms in the <virtualConnectionId> are retained. The concatenation <addressType>-<address> can be wildcarded in the following ways:
In some applications, it is necessary to wildcard the <virtualConnectionId> parameter, or some elements of this parameter. The "$" wildcard character can be substituted for the entire <virtualConnectionId> parameter, or some of its terms. In the latter case, the constant strings that qualify the terms in the <virtualConnectionId> are retained. The concatenation <addressType>-<address> can be wildcarded in the following ways:
* The entire concatenation, <addressType>-<address>, is replaced
with a "$".
* <address> is replaced with a "$", but <addressType> is not.
* The entire concatenation, <addressType>-<address>, is replaced with a "$". * <address> is replaced with a "$", but <addressType> is not.
Kumar & Mostafa Standards Track [Page 18] RFC 3108 ATM SDP May 2001
Kumar & Mostafa Standards Track [Page 18] RFC 3108 ATM SDP May 2001
Examples of wildcarding the <virtualConnectionId> in the AAL1 and AAL5 contexts are: $, VCCI-$, BCG-100/VPI-20/VCI-$. Examples of wildcarding the <virtualConnectionId> in the AAL2 context are: $, VCCI-40/CID-$, BCG-100/VPI-20/VCI-120/CID-$, NSAP-$/VCCI-$/CID-$, $/VCCI-$/CID-$.
Examples of wildcarding the <virtualConnectionId> in the AAL1 and AAL5 contexts are: $, VCCI-$, BCG-100/VPI-20/VCI-$. Examples of wildcarding the <virtualConnectionId> in the AAL2 context are: $, VCCI-40/CID-$, BCG-100/VPI-20/VCI-120/CID-$, NSAP-$/VCCI-$/CID-$, $/VCCI-$/CID-$.
It is also permissible to set the entire <virtualConnectionId> parameter to a "-" indicating its irrelevance.
It is also permissible to set the entire <virtualConnectionId> parameter to a "-" indicating its irrelevance.
5.5.2 The Transport Parameter
5.5.2 The Transport Parameter
The <transport> parameter indicates the method used to encapsulate the service payload. These methods are not defined in this document, which refers to existing ATMF and ITU-T standards, which, in turn, might refer to other standards. For ATM applications, the following <transport> values are defined:
The <transport> parameter indicates the method used to encapsulate the service payload. These methods are not defined in this document, which refers to existing ATMF and ITU-T standards, which, in turn, might refer to other standards. For ATM applications, the following <transport> values are defined:
Kumar & Mostafa Standards Track [Page 19] RFC 3108 ATM SDP May 2001
Kumar & Mostafa Standards Track [Page 19] RFC 3108 ATM SDP May 2001
Table 1: List of Transport Parameter values used in SDP in the ATM
context
Table 1: List of Transport Parameter values used in SDP in the ATM context
+---------------------------------------------------------------------+ | | Controlling Document for | | Transport | Encapsulation of Service Payload | +------------------------+--------------------------------------------+ | AAL1/ATMF | af-vtoa-0078.000 [7] | +------------------------+--------------------------------------------+ | AAL1/ITU | ITU-T H.222.1 [51] | +------------------------+--------------------------------------------+ | AAL5/ATMF | af-vtoa-0083.000 [46] | +------------------------+--------------------------------------------+ | AAL5/ITU | ITU-T H.222.1 [51] | +------------------------+--------------------------------------------+ | AAL2/ATMF | af-vtoa-0113.000 [44] and | | | af-vmoa-0145.000 [52] | +------------------------+--------------------------------------------+ | AAL2/ITU | ITU-T I.366.2 [13] | +------------------------+--------------------------------------------+ | AAL1/custom | Corporate document or | | AAL2/custom | application-specific interoperability | | AAL5/custom | statement. | +------------------------+--------------------------------------------+ | AAL1/<corporateName> | | | AAL2/<corporateName> | | | AAL5/<corporateName> | | | AAL1/IEEE:<oui> | Corporate document | | AAL2/IEEE:<oui> | | | AAL5/IEEE:<oui> | | +------------------------+--------------------------------------------+ | RTP/AVP | Annex C of H.323 [45] | +------------------------+--------------------------------------------+
+---------------------------------------------------------------------+ | | ドキュメントを制御します。| | 輸送| サービス有効搭載量のカプセル化| +------------------------+--------------------------------------------+ | AAL1/ATMF| af-vtoa-0078.000[7]| +------------------------+--------------------------------------------+ | AAL1/ITU| ITU-T H.222.1[51]| +------------------------+--------------------------------------------+ | AAL5/ATMF| af-vtoa-0083.000[46]| +------------------------+--------------------------------------------+ | AAL5/ITU| ITU-T H.222.1[51]| +------------------------+--------------------------------------------+ | AAL2/ATMF| そしてaf-vtoa-0113.000[44]。| | | af-vmoa-0145.000[52]| +------------------------+--------------------------------------------+ | AAL2/ITU| ITU-T I.366.2[13]| +------------------------+--------------------------------------------+ | AAL1/習慣| または企業文書。| | AAL2/習慣| アプリケーション特有の相互運用性| | AAL5/習慣| 声明。 | +------------------------+--------------------------------------------+ | AAL1/<corporateName>。| | | AAL2/<corporateName>。| | | AAL5/<corporateName>。| | | AAL1/IEEE: <oui>。| 企業文書| | AAL2/IEEE: <oui>。| | | AAL5/IEEE: <oui>。| | +------------------------+--------------------------------------------+ | RTP/AVP| H.323[45]の別館C| +------------------------+--------------------------------------------+
In H.323 Annex C applications [45], the <transport> parameter has a value of "RTP/AVP". This is because these applications use the RTP protocol [2] and audio/video profile [3]. The fact that RTP is carried directly over AAL5 per [45] can be indicated explicitly via the aalApp media attribute.
H.323 Annex Cアプリケーション[45]では、<輸送>パラメタは"RTP/AVP"の値を持っています。 これはこれらのアプリケーションがRTPプロトコル[2]とオーディオ/ビデオプロフィール[3]を使用するからです。 aalAppメディア属性で明らかに、RTPが1[45]あたりのAAL5の直接上まで運ばれるという事実を示すことができます。
A value of "AAL1/custom", "AAL2/custom" or "AAL5/custom" for the <transport> parameter can indicate non-standard or semi-standard encapsulation schemes defined by a corporation or a multi-vendor agreement. Since there is no standard administration of this convention, care should be taken to preclude inconsistencies within the scope of a deployment.
<輸送>パラメタのための「AAL1/習慣」、「AAL2/習慣」または「AAL5/習慣」の値は会社かマルチベンダ協定で定義された標準的でないか準標準のカプセル化体系について簡単に述べることができます。 このコンベンションのどんな標準の管理もないので、展開の範囲の中で矛盾を排除するために注意するべきです。
Kumar & Mostafa Standards Track [Page 20] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[20ページ]。
The use of <transport> values "AAL1/<corporateName>", "AAL2/<corporateName>", "AAL5/<corporateName>", "AAL1/IEEE:<oui>", "AAL2/IEEE:<oui>" and "AAL5/IEEE:<oui>" is similar. These indicate non-standard transport mechanisms or AAL2 profiles which should be used consistently within the scope of an application or deployment. The parameter <corporateName> is the registered, globally unique name of a corporation (e.g., Cisco, Telcordia etc.). The parameter <oui> is the hex representation of a three-octet field identical to the OUI maintained by the IEEE. Since this is always represented in hex, the "0x" prefix shall not be used. Leading zeros can be omitted. For example, "IEEE:00000C" and "IEEE:C" both refer to Cisco Systems, Inc.
<輸送>値「AAL1/<corporateName>」、「AAL2/<corporateName>」、「AAL5/<corporateName>」、「AAL1/IEEE: <oui>」、「AAL2/IEEE: <oui>」、および「AAL5/IEEE: <oui>」の使用は同様です。 これらはアプリケーションか展開の範囲の中で一貫して使用されるべきである標準的でない移送機構かAAL2プロフィールを示します。 パラメタ<corporateName>は会社(例えば、Telcordiaシスコなど)の登録されて、グローバルにユニークな名前です。 パラメタ<oui>はIEEEによって維持されたOUIと同じ3八重奏の分野の十六進法表現です。 これが十六進法でいつも表されるので、"0x"接頭語を使用しないものとします。 先行ゼロを省略できます。 例えば、「IEEE: 00000C」と「IEEE: C」はともにシスコシステムズInc.を示します。
5.5.3 The Format List for AAL1 and AAL5 applications
5.5.3 AAL1とAAL5アプリケーションのためのFormat List
In the AAL1 and AAL5 contexts, the <format list> is a list of payload types:
AAL1とAAL5文脈では、<形式リスト>はペイロードタイプのリストです:
<payloadType#1> <payloadType#2>...<payloadType#n>
<payloadType#1><payloadType#2>…<payloadType#n>。
In most AAL1 and AAL5 applications, the ordering of payload types implies a preference (preferred payload types before less favored ones). The payload type can be statically assigned or dynamically mapped. Although the transport is not the same, SDP in the ATM context leverages the encoding names and payload types registered with IANA [31] for RTP. Encoding names not listed in [31] use a "X-" prefix. Encodings that are not statically mapped to payload types in [31] are to be dynamically mapped at the time of connection establishment to payload types in the decimal range 96-127. The SDP 'atmmap' attribute (similar to 'rtpmap') is used for this purpose.
ほとんどのAAL1とAAL5アプリケーションでは、ペイロードタイプの注文は優先(それほど好評でないものの前にペイロードタイプを好む)を含意します。 ペイロードタイプを静的に選任するか、またはダイナミックに写像できます。 輸送は同じではありませんが、ATM文脈のSDPは、コード化が名前であると利用します、そして、ペイロードタイプはRTPのためにIANA[31]とともに記名しました。 名前をコード化するのは[31] 使用で「X」接頭語を記載しませんでした。 静的に[31]のペイロードタイプに写像されないEncodingsは10進範囲96-127のペイロードタイプへのコネクション確立時点で、ダイナミックに写像されることになっています。 SDP'atmmap'属性('rtpmap'と同様の)はこのために使用されます。
In addition to listing the IANA-registered encoding names and payload types found in [31], Table 2 defines a few non-standard encoding names(with "X-" prefixes).
名前とペイロードタイプが[31]で見つけたIANAによって登録されたコード化を記載することに加えて、Table2はいくつかの標準的でないコード化名(「X」接頭語がある)を定義します。
5.5.4 The Format List for AAL2 applications
5.5.4 AAL2アプリケーションのためのFormat List
In the AAL2 context, the <format list> is a list of AAL2 profile types:
AAL2文脈では、<形式リスト>はAAL2プロフィールタイプのリストです:
<profile#1> <profile#2>...<profile#n>
<プロフィール#1><プロフィール#2>…<プロフィール#n>。
In most applications, the ordering of profiles implies a preference (preferred profiles before less favored ones). The <profile> parameter is expressed as a decimal number in the range 1-255.
ほとんどのアプリケーションでは、プロフィールの注文は優先(それほど好評でないものの前にプロフィールを好む)を含意します。 <プロフィール>パラメタは10進数として範囲1-255で言い表されます。
Kumar & Mostafa Standards Track [Page 21] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[21ページ]。
5.5.5 Media information line construction
5.5.5 メディア情報回線工事
Using the parameter definitions above, the 'm' for AAL1-based audio media can be constructed as follows:
'上のパラメタ定義を使用する、'AAL1ベースのオーディオにおいて、以下の通りメディアを構成できるということです:
m=audio <virtualConnectionId> AAL1/ATMF <payloadType#1>
<payloadType#2>...<payloadType #n>
mはオーディオの<のAAL1/ATMF<payloadType#1><virtualConnectionId>payloadType#2>と等しいです…<payloadType#n>。
Note that only those payload types, whether statically mapped or dynamically assigned, that are consistent with af-vtoa-78 [7] can be used in this construction.
それらのペイロードタイプだけであり、静的に写像されるか、またはダイナミックに割り当てられることにかかわらずそれがこの構造に使用されるaf-vtoa-78[7]缶と一致していることに注意してください。
Backwards compatibility note: The transport value "AAL1/AVP" used in previous versions of this document should be considered equivalent to the value "AAL1/ATMF" defined above. "AAL1/AVP" is unsuitable because the AVP profile is closely tied to RTP.
後方に、互換性は以下に注意します。 このドキュメントの旧バージョンで使用される輸送値の"AAL1/AVP"は上で定義された値の"AAL1/ATMF"に同等であると考えられるべきです。 AVPプロフィールが密接にRTPに結ばれるので、"AAL1/AVP"は不適当です。
An example 'm' line use for audio media over AAL1 is:
'例は'AAL1の上のオーディオメディアの系列使用があるということです:
m=audio VCCI-27 AAL1/ATMF 0
mはオーディオのVCCI-27 AAL1/ATMF0と等しいです。
This indicates the use of an AAL1 VCC with VCCI=24 to carry PCMU audio that is encapsulated according to ATMF's af-vtoa-78 [7].
これは、ATMFのaf-vtoa-78[7]によると、カプセル化されるPCMUオーディオを運ぶためにVCCI=24とのAAL1 VCCの使用を示します。
Another example of the use of the 'm' line use for audio media over AAL1 is:
'使用に関する別の例、'AAL1の上のオーディオメディアの系列使用があるということです:
m=audio $ AAL1/ATMF 0 8
m=オーディオの$AAL1/ATMF、0 8
This indicates that any AAL1 VCC may be used. If it exists already, then its selection is subject to glare rules. The audio media on this VCC is encapsulated according to ATMF's af-vtoa-78 [7]. The encodings to be used are either PCMU or PCMA, in preferential order.
これは、どんなAAL1 VCCも使用されるかもしれないのを示します。 既に存在しているなら、選択はギラギラと眩しい光規則を受けることがあります。 ATMFのaf-vtoa-78[7]によると、このVCCの上のオーディオメディアはカプセル化されます。 使用されるべきencodingsは優先のオーダーでPCMUかPCMAのどちらかです。
The 'm' for AAL5-based audio media can be constructed as follows:
'、'AAL5ベースのオーディオにおいて、以下の通りメディアを構成できるということです:
m=audio <virtualConnectionId> AAL5/ATMF <payloadType#1>
<payloadType#2>...<payloadType #n>
mはオーディオの<のAAL5/ATMF<payloadType#1><virtualConnectionId>payloadType#2>と等しいです…<payloadType#n>。
An example 'm' line use for audio media over AAL5 is:
'例は'AAL5の上のオーディオメディアの系列使用があるということです:
m=audio PORT-2/VPI-6/$ AAL5/ITU 9 15
オーディオのm=PORT-2/VPI-6/AAL5/ITU9 15ドル
implies that any VCI on VPI= 6 of trunk port #2 may be used. The identities of the terms in the virtual connection ID are implicit in the application context. The audio media on this VCC is encapsulated according to ITU-T H.222.1 [51]. The encodings to be used are either ITU-T G.722 or ITU-T G.728 (LD-CELP), in preferential order.
6個のVPIの上のどんなVCIも=トランクポート#2が使用されるかもしれないのを含意します。 仮想接続IDにおける、用語のアイデンティティはアプリケーション文脈で暗に示されています。 ITU-T H.222.1[51]によると、このVCCの上のオーディオメディアはカプセル化されます。 使用されるべきencodingsは優先のオーダーでITU-T G.722かITU-T G.728(LD-CELP)のどちらかです。
Kumar & Mostafa Standards Track [Page 22] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[22ページ]。
The 'm' for AAL5-based H.323 Annex C audio [45] can be constructed as follows:
'、'AAL5ベースのH.323 Annex Cに関して、以下の通りオーディオ[45]を構成できるということです:
m=audio <virtualConnectionId> RTP/AVP <payloadType#1>
<payloadType#2>...<payloadType #n>
mはオーディオの<のRTP/AVP<payloadType#1><virtualConnectionId>payloadType#2>と等しいです…<payloadType#n>。
For example:
例えば:
m=audio PORT-9/VPI-3/VCI-$ RTP/AVP 2 96
a=rtpmap:96 X-G727-32
a=aalType:AAL5
a=aalApp:itu_h323c - -
mがオーディオPORT-9/VPI-3/VCI-$RTP/AVPと等しい、2、96a=rtpmap、: 96 X-G727-32 a=aalType:AAL5 a=aalApp:itu_h323c--、-
implies that any VCI on VPI= 3 of trunk port #9 may be used. This VC encapsulates RTP packets directly on AAL5 per [45]. The 'rtpmap' (rather than the 'atmmap') attribute is used to dynamically map the payload type of 96 into the codec name X-G727-32 (Table 2). This name represents 32 kbps EADPCM.
3個のVPIの上のどんなVCIも=トランクポート#9が使用されるかもしれないのを含意します。 このVCは直接1[45]あたりのAAL5でパケットをRTPにカプセルに入れります。 'rtpmap'('atmmap'よりむしろ)属性は、ダイナミックにコーデック名のX-G727-32(テーブル2)に96人のペイロードタイプを写像するのに使用されます。 この名前は32キロビット毎秒EADPCMを表します。
The 'm' line for AAL5-based video media can be constructed as follows:
'、'以下の通りAAL5を拠点とするビデオメディアのための系列を構成できるということです:
m=video <virtualConnectionId> AAL5/ITU <payloadType#1>
<payloadType#2>...<payloadType #n>
mはビデオ<virtualConnectionId>AAL5/ITU<payloadType#1><payloadType#2>と等しいです…<payloadType#n>。
In this case, the use of AAL5/ITU as the transport points to H.222.1 as the controlling standard [51]. An example 'm' line use for video media is:
この場合、輸送としてのAAL5/ITUの使用は制御規格[51]としてH.222.1を示します。 '例は'ビデオメディアの系列使用があるということです:
m=video PORT-9/VPI-3/VCI-$ AAL5/ITU 33
mがビデオPORT-9/VPI-3/VCI-$AAL5/ITUと等しい、33
This indicates that any VCI on VPI= 3 of trunk port #9 may be used.
The video media on this VCC is encapsulated according to ITU-T
H.222.1 [51]. The encoding scheme is an MPEG 2 transport stream
("MP2T" in Table 1). This is statically mapped per [31] to a payload
type of 33.
これは、3個のVPIの上のどんなVCIも=トランクポート#9が使用されるかもしれないのを示します。 ITU-T H.222.1[51]によると、このVCCの上のビデオメディアはカプセル化されます。 コード化体系はMPEG2輸送ストリーム(テーブル1の"MP2T")です。 これは[31]単位で静的に33人のペイロードタイプに写像されます。
Using the parameter definitions in the previous subsections, the media information line for AAL2-based audio media can be constructed as follows:
前の小区分とのパラメタ定義を使用して、以下の通りAAL2を拠点とするオーディオメディアのためのメディア情報系列を構成できます:
m=<media> <virtualConnectionId> <transport#1> <format list#1>
<transport#2> <format list#2> ... <transport#M> <format list#M>
m=<メディア><virtualConnectionId><は1つの#><形式リスト#1><輸送#2><形式リスト#2>を輸送します… <輸送#M><形式リスト#M>。
where <format list#i> has the form <profile#i_1>...<profile#i_N> Unlike the 'm' line for AAL1 or AAL5 applications, the 'm' line for AAL2 applications can have multiple <transport> parameters, each followed by a <format list>. This is because it is possible to
<形式リスト#i>にはフォーム<があるところでは、#_i1>の輪郭を描いてください…<'プロフィール#i>Unlike、'AAL1かAAL5アプリケーションのための系列、'AAL2アプリケーションのための系列が複数の<輸送>パラメタを持つことができるということであり、a<形式リスト>によってそれぞれ以下であることは、そうです。 これはそれが可能であるからです
Kumar & Mostafa Standards Track [Page 23] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[23ページ]。
consider definitions from multiple sources (ATMF, ITU and non- standard documents) when selecting AAL2 profile to be bound to a connection.
AAL2プロフィールが接続に縛られるのを選択するときには複数のソース(ATMF、ITU、および非標準のドキュメント)から定義を考えてください。
In most applications, the ordering of profiles implies a preference (preferred profiles before less favored ones). Therefore, there can be multiple instances of the same <transport> value in the same 'm' line.
ほとんどのアプリケーションでは、プロフィールの注文は優先(それほど好評でないものの前にプロフィールを好む)を含意します。 'したがって、輸送>が中に同じようにあるのを評価する同じ<の複数のインスタンスがあることができる'という台詞。
An example 'm' line use for audio media over AAL2 is:
'例は'AAL2の上のオーディオメディアの系列使用があるということです:
m=audio VCCI-27/CID-19 AAL2/ITU 7 AAL2/custom 100 AAL2/ITU 1
m=オーディオのVCCI-27/CID-19 AAL2/ITU7AAL2/習慣100AAL2/ITU1
This indicates the use of CID #19 on VCCI #27 to carry audio. It provides a preferential list of profiles for this connection: profile AAL2/ITU 7 defined in [13], AAL2/custom 100 defined in an application-specific or interoperability document and profile AAL2/ITU 1 defined in [13].
これは、オーディオを運ぶためにVCCI#27におけるCID#19の使用を示します。 それはこの接続へのプロフィールの優先のリストを提供します: [13]で定義されたプロフィールAAL2/ITU7、AAL2/習慣100はアプリケーション特有であるか相互運用性ドキュメントとプロフィールで[13]で定義されたAAL2/ITU1を定義しました。
Another example of the use of the 'm' line use for audio media over AAL2 is:
'使用に関する別の例、'AAL2の上のオーディオメディアの系列使用があるということです:
m=audio VCCI-$/CID-$ AAL2/ATMF 6 8
mはオーディオVCCI-$/CID-$AAL2/ATMF6 8と等しいです。
This indicates that any AAL2 CID may be used, subject to any applicable glare avoidance/reduction rules. The profiles that can be bound to this connection are AAL2/ATMF 6 defined in af-vtoa-0113.000 [44] and AAL2/ATMF 8 defined in af-vmoa-0145.000 [52]. These sources use non-overlapping profile number ranges. The profiles they define fall under the <transport> category "AAL2/ATMF". This application does not order profiles preferentially. This rule is known a priori. It is not embedded in the 'm' line.
これは、どんなAAL2 CIDもどんな適切なギラギラと眩しい光回避/減少定規を条件として使用されるかもしれないのを示します。 この接続に縛ることができるプロフィールは、af-vtoa-0113.000[44]で定義されたAAL2/ATMF6とaf-vmoa-0145.000[52]で定義されたAAL2/ATMF8です。 これらのソースは非重なっているプロフィール数の範囲を使用します。 それらが定義するプロフィールは<輸送>カテゴリ"AAL2/ATMF"の下で落ちます。 このアプリケーションは優先的にプロフィールを注文しません。 この規則は先験的に知られています。 'それが埋め込まれていない、'立ち並んでください。
Another example of the use of the 'm' line use for audio media over AAL2 is:
'使用に関する別の例、'AAL2の上のオーディオメディアの系列使用があるということです:
m=audio VCCI-20/CID-$ AAL2/xyzCorporation 11
mはオーディオのVCCI-20/CID-$AAL2/xyzCorporation11と等しいです。
AAL2 VCCs in this application are single-CID VCCs. Therefore, it is possible to wildcard the CID. The single-CID VCC with VCCI=20 is selected. The AAL2 profile to be used is AAL2/xyzCorporation 11 defined by xyzCorporation.
このアプリケーションにおけるAAL2 VCCsは独身のCID VCCsです。 したがって、それはワイルドカードに可能です。CID。 VCCI=20に伴う独身のCID VCCは選択されます。 使用されるべきAAL2プロフィールはxyzCorporationによって定義されたAAL2/xyzCorporation11です。
In some applications, an "-" can be used in lieu of:
使用目的によっては、以下の代わりに「-」を使用できます。
- <format list> - <transport> and <format list>
- <形式リスト>--<輸送>と<形式リスト>。
Kumar & Mostafa Standards Track [Page 24] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[24ページ]。
This implies that these parameters are irrelevant or are known by other means (such as defaults). For example:
これは、これらのパラメタが無関係であるか、または他の手段(デフォルトなどの)によって知られているのを含意します。 例えば:
m=audio VCCI-234 - -
a=aalType:AAL1
m=オーディオVCCI-234----a=aalType: AAL1
indicates the use of VCCI=234 with AAL1 adaptation and unspecified encoding.
AAL1適合と不特定のコード化によるVCCI=234の使用を示します。
In another example application, the 'aal2sscs3662' attribute can indicate <faxDemod> = "on" and any other competing options as "off", and the <aalType> attribute can indicate AAL2. Thus:
別の例のアプリケーションでは、'aal2sscs3662'属性は、<faxDemod>が“off"として“on"といかなる他の競争しているオプションとも等しいのを示すことができます、そして、<aalType>属性はAAL2を示すことができます。 このようにして:
m=audio VCCI-123/CID-5 - -
a=aalType:AAL2
a=aal2sscs3662:audio off off on off on off off off - - -
m=オーディオVCCI-123/CID-5----下にオフなa=aalType:AAL2 a=aal2sscs3662:オーディオ、下にオンである、下にオフ--、--、-
Besides indicating an audio medium, a VCCI of 123 and a CID of 5, the 'm' line indicates an unspecified profile. The media attribute lines indicate an adaptation layer of AAL2, and the use of the audio SAP [13] to carry demodulated facsimile.
'さらにオーディオ媒体、5の123とCIDのVCCIを示す、'系列は不特定のプロフィールを示します。 属性が裏打ちするメディアはAAL2の適合層を示します、そして、運ぶオーディオSAP[13]の使用はファクシミリを反調節しました。
The media information line for "data" media has one of the following the following formats:
「データ」メディアのためのメディア情報系列には、以下がフォーマットする以下の1つがあります:
m=data <virtualConnectionId> - -
m=data - - -
m=データ<virtualConnectionId>----mがデータと等しい----、-
The data could be circuit emulation data carried over AAL1 or AAL2, or packet data carried over AAL5. Media attribute lines, rather than the 'm' line, are used to indicate the adaptation type for the data media. Examples of the representation of data media are listed below.
データはAAL1かAAL2の上まで運ばれた回路エミュレーションデータであるかもしれませんかパケットデータがAAL5を引き継ぎました。 'メディア属性がむしろ立ち並んでいる、'系列であり、データメディアのために適合タイプを示すのに使用されます。 データメディアの代理に関する例は以下にリストアップされています。
m=data PORT-7/VPI-6/VCI-$ - -
a=aalApp:AAL5_SSCOP- -
m=データPORT-7/VPI-6/VCI-$----a=aalApp: AAL5_SSCOP、-、-
implies that any VCI on VPI= 6 of trunk port #7 may be used. This VC uses SSCOP on AAL5 to transport data.
6個のVPIの上のどんなVCIも=トランクポート#7が使用されるかもしれないのを含意します。 このVCは、データを輸送するのにAAL5の上のSSCOPを使用します。
m=data PORT-7/VPI-6/VCI-50 - -
a=aalType:AAL1_SDT
a=sbc:6
m=データPORT-7/VPI-6/VCI-50----a=aalType: AAL1_SDT a=sbc: 6
implies that VCI 50 on VPI 6 on port 7 uses structured AAL1 to transfer 6 x 64 kbps circuit emulation data. This may be alternately represented as:
ポート7用途でのVPI6の上のVCI50が6x64のキロビット毎秒回路エミュレーションデータを移すためにAAL1を構造化したのを含意します。 これは以下として交互に表されるかもしれません。
Kumar & Mostafa Standards Track [Page 25] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[25ページ]。
m=data PORT-7/VPI-6/VCI-50 - -
b=AS:384
a=aalType:AAL1_SDT
m=データPORT-7/VPI-6/VCI-50----b=AS: 384a=aalType: AAL1_SDT
The following lines:
以下の系列:
m=data VCCI-123/CID-5 - -
a=aalType:AAL2
a=sbc:2
m=データVCCI-123/CID-5----a=aalType:AAL2 a=sbc:2
imply that CID 5 of VCCI 123 is used to transfer 2 x 64 kbps circuit emulation data.
VCCI123のCID5が2x64のキロビット毎秒回路エミュレーションデータを移すのに使用されるのを含意してください。
In the AAL1 context, it is also permissible to represent circuit mode data as an "audio" codec. If this is done, the codec types used are X-CCD or X-CCD-CAS. These encoding names are dynamically mapped into payload types through the 'atmmap' attribute. For example:
また、AAL1文脈では、「オーディオ」コーデックとして回路モードデータを表すのも許されています。これが完了しているなら、使用されるコーデックタイプは、X-CCDかX-CCD-CASです。 名前をコード化するこれらが'atmmap'属性を通してダイナミックにペイロードタイプに写像されます。 例えば:
m=audio VCCI-27 AAL1/AVP 98
a=atmmap:98 X-CCD
a=sbc:6
オーディオのVCCI-27 AAL1/AVP98m=a=atmmap: 98X-CCD a=sbc: 6
implies that AAL1 VCCI=27 is used for 6 x 64 transmission.
AAL1 VCCI=27が6x64送信に使用されるのを含意します。
In the AAL2 context, the X-CCD codec can be assigned a profile type and number. Even though it is not possible to construct a profile table as described in ITU I.366.2 for this "codec", it is preferable to adopt the common AAL2 profile convention in its case. An example AAL2 profile mapping for the X-CCD codec could be as follows:
AAL2文脈では、プロフィールタイプと数をX-CCDコーデックに選任できます。 この「コーデック」のためにITU I.366.2で説明されるプロフィールテーブルを組み立てるのが可能ではありませんが、場合で一般的なAAL2プロフィールコンベンションを採用するのは望ましいです。 X-CCDコーデックのための例のAAL2プロフィールマッピングは以下の通りであるかもしれません:
PROFILE TYPE PROFILE NUMBER "CODEC" (ONLY ONE)
"custom" 200 X-CCD
タイププロフィール数の「コーデック」(1だけ)「習慣」200X-CCDの輪郭を描いてください。
The profile does not identify the number of subchannels ('n' in
nx64). This is known by other means such as the 'sbc' media
attribute line.
プロフィールがnx64のサブチャネル('n'の数を特定しない、) これはメディアが結果と考える'sbc'系列などの他の手段によって知られています。
For example, the media information line:
例えば、メディア情報は立ち並んでいます:
m=audio $ AAL2/custom 200
a=sbc:6
オーディオのAAL2/習慣200ドルのm=a=sbc: 6
implies 384 kbps circuit emulation using AAL2 adaptation.
AAL2適合を使用することで384キロビット毎秒回路エミュレーションを含意します。
It is not necessary to define a profile with the X-CCD-CAS codec, since this method of CAS transport [7] is not used in AAL2 applications.
X-CCD-CASコーデックでプロフィールを定義するのは必要ではありません、CAS輸送[7]のこのメソッドがAAL2アプリケーションで使用されないので。
Kumar & Mostafa Standards Track [Page 26] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[26ページ]。
5.6 The Media Attribute Lines
5.6 メディア属性は立ち並んでいます。
In an SDP line sequence, the media information line 'm' is followed by one or more media attribute or 'a' lines. Media attribute lines are per the format below:
'SDP系列系列では、メディア情報が立ち並んでいる、'1つ以上のメディア属性か'a'系列があとに続いています。 属性が裏打ちするメディアが以下の形式単位であります:
a=<attribute>:<value>
=<属性>: <値の>。
or
または
a=<value>
=<値>。
In general, media attribute lines are optional except when needed to qualify the media information line. This qualification is necessary when the "m" line for an AAL1 or AAL5 session specifies a payload type that needs to be dynamically mapped. The 'atmmap' media attribute line defined below is used for this purpose.
一般に、メディア情報系列に資格を与えるのが必要であるときに時を除いて、属性が裏打ちするメディアは任意です。 AAL1かAAL5セッションのための「m」系列がダイナミックに写像される必要があるペイロードタイプを指定するとき、この資格が必要です。 以下で定義されたメディアが結果と考える'atmmap'系列はこのために使用されます。
In attribute lines, subparameters that are meant to be left unspecified are set to a "-". These are generally inapplicable or, if applicable, are known by other means such as provisioning. In some cases, a media attribute line with all parameters set to "-" carries no information and should be preferably omitted. In other cases, such as the 'lij' media attribute line, the very presence of the media attribute line conveys meaning.
属性系列では、不特定のままにされることになっている「副-パラメタ」は「-」に用意ができています。 これらは、一般に、不適当であるか、または適切であるなら、食糧を供給することなどの他の手段によって知られています。 いくつかのケース、すべてのパラメタがある系列がセットしたメディア属性では、「-」は、情報を全く運ばないで、望ましくは、省略されるべきです。 メディアが結果と考える'lij'系列などの他のケース、メディアのまさしくその前では、属性系列が意味を伝えます。
There are no restrictions placed by RFC 2327 [1] regarding the order of 'a' lines with respect to other 'a' lines. However, these lines must not contradict each other or the other SDP lines. Inconsistencies are not to be ignored and should be flagged as errors. Repeated media attribute lines can carry additional information. These should not be inconsistent with each other.
'a'系列の注文に関して他の'a'系列に関してRFC2327[1]によって置かれた制限が全くありません。 しかしながら、これらの系列は互いか他のSDP系列に逆らってはいけません。 矛盾が無視されないことであり、誤りとして旗を揚げられるべきです。 属性が裏打ちする繰り返されたメディアは追加情報を載せることができます。 これらは互いに矛盾しているべきではありません。
Applications will selectively use the optional media attribute lines listed below. This is meant to be an exhaustive list for describing the general attributes of ATM bearer networks.
アプリケーションは選択的に、属性系列が以下に記載した任意のメディアを使用するでしょう。 これはATM基幹ネットワークの一般属性について説明するための完全なりストであることが意味されます。
The base specification for SDP, RFC 2327 [1], allows the definition f new attributes. In keeping with this spirit, some of the attributes defined in this document can also be used in SDP descriptions of IP nd other non-ATM sessions. For example, the 'vsel', 'dsel' and 'fsel' attributes defined below refer generically to codec-s. These can be bed for service-specific codec negotiation and assignment in non-ATM s well as ATM applications.
SDPのための基礎仕様(RFC2327[1])は定義fに新しい属性を許容します。 また、IPのSDP記述に本書では定義された属性のいくつかをこの精神と共に保つのに、使用できる、他の非ATM第セッション。 例えば、'vsel'、'dsel'、および属性が以下で定義した'fsel'は一般的にコーデックsについて言及します。 これらはATMアプリケーションとしてよく非ATM sのサービス特有のコーデック交渉と課題のためのベッドであるかもしれません。
SDP media attributes defined in this document for use in the ATM context are classified as:
本書ではATM文脈における使用のために定義されたSDPメディア属性は以下として分類されます。
Kumar & Mostafa Standards Track [Page 27] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[27ページ]。
* ATM bearer connection attributes (Section 5.6.1)
* AAL attributes (Section 5.6.2)
* Service attributes (Section 5.6.3).
* Miscellaneous media attributes, that cannot be classified as
ATM, AAL or service attributes (Section 5.6.4).
* ATM運搬人接続属性(セクション5.6.1)*AAL属性(セクション5.6.2)*サービス属性(セクション5.6.3)。 * 種々雑多なメディア属性であり、ATM、AALまたはサービス属性(セクション5.6.4)としてそれを分類できません。
In addition to these, the SDP attributes defined in [1] can also be used in the ATM context. Examples are:
また、これらに加えて、ATM文脈で[1]で定義されたSDP属性は使用できます。 例は以下の通りです。
* The attributes defined in RFC 2327 which allow indication of
the direction in which a session is active. These are
a=sendonly, a=recvonly, a=sendrecv, a=inactive.
* 属性は、RFC2327でどれがセッションが活発である方向のしるしを許容するかを定義しました。 これらはa=sendonly、a=sendrecvの、そして、a=不活発なa=recvonlyです。
* The 'Ptime' attribute defined in RFC 2327. It indicates the
packet period. It is not recommended that this attribute be
used in ATM applications since packet period information is
provided with other parameters (e.g., the profile type and
number in the 'm' line, and the 'vsel', 'dsel' and 'fsel'
attributes). Also, for AAL1 applications, 'ptime' is not
applicable and should be flagged as an error. If used in AAL2
and AAL5 applications, 'ptime' should be consistent with the
rest of the SDP description.
* RFC2327で定義された'Ptime'属性。 それはパケットの期間を示します。 'この属性がパケット期間の情報に他のパラメタを提供するのでATMアプリケーションで使用されることが勧められない、(例えば、中のプロフィールタイプと数、'系列、'vsel'、'dsel'、および'fsel'属性) また、AAL1アプリケーションにおいて、'ptime'は、適切でなく、誤りとして旗を揚げられるべきです。 AAL2とAAL5アプリケーションで使用されるなら、'ptime'はSDP記述の残りと一致しているべきです。
* The 'fmtp' attribute used to designate format-specific
parameters.
* 'fmtp'属性は以前はよく形式特有のパラメタを指定していました。
5.6.1 ATM bearer connection attributes
5.6.1 ATM運搬人接続属性
The following is a summary list of the SDP media attributes that can be used to describe ATM bearer connections. These are detailed in subsequent subsections.
↓これはATM運搬人接続について説明するのに使用できるSDPメディア属性の概要リストです。 これらはその後の小区分で詳細です。
* The 'eecid' attribute. This stands for 'end-to-end connection
identifier'. It provides a means of correlating service-level
connections with underlying ATM bearer connections. In the
Q.1901 [36] context, the eecid is synonymous with the bnc-id
(backbone network connection identifier).
* 'eecid'属性。 これは'終わりから終わりへの接続識別子'を表します。 それは基本的なATM運搬人接続とのサービスレベル接続を関連させる手段を提供します。 Q.1901[36]文脈では、eecidはbnc-イド(バックボーンネットワーク接続識別子)と同義です。
* The 'aalType' attribute. This is used to indicate the nature
of the ATM adaptation layer (AAL).
* 'aalType'属性。 これは、ATM適合(AAL)層の本質を示すのに使用されます。
* The 'capability' attribute, which indicates the ATM transfer
capability (ITU nomenclature), synonymous with the ATM Service
Category (ATMF nomenclature).
* ATM Service Category(ATMF用語体系)と同義の'能力'属性。(その属性はATM転送能力(ITU用語体系)を示します)。
* The 'qosClass' attribute, which indicates the QoS class of the
ATM bearer connection.
* 'qosClass'属性。(その属性はATM運搬人接続のQoSのクラスを示します)。
Kumar & Mostafa Standards Track [Page 28] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[28ページ]。
* The 'bcob' attribute, which indicates the broadband connection
oriented bearer class, and whether end-to-end timing is
required.
* 'bcob'属性が必要です。(それは、ブロードバンドの接続指向の運搬人のクラスと終わりから終わりへのタイミングがそうであるかどうかを示します)。
* The 'stc' attribute, which indicates susceptibility to
clipping.
* 'stc'属性。(その属性は敏感さを切り取りに示します)。
* The 'upcc' attribute, which indicates the user plane connection
configuration.
* 'upcc'属性。(その属性はユーザ飛行機接続構成を示します)。
* The 'atmQOSparms' attribute, which is used to describe certain
key ATM QoS parameters.
* 'atmQOSparms'属性。(その属性は、ある主要なATM QoSパラメタについて説明するのに使用されます)。
* The 'atmTrfcDesc' attribute, which is used to describe ATM
traffic descriptor parameters.
* 'atmTrfcDesc'属性。(その属性は、ATMトラフィック記述子パラメタについて説明するのに使用されます)。
* The 'abrParms' attribute, which is used to describe ABR-
specific parameters. These parameters are per the UNI 4.0
signaling specification [5].
* 'abrParms'属性。(その属性は、ABRの特定のパラメタについて説明するのに使用されます)。 これらのパラメタがUNI4.0シグナリング仕様[5]単位であります。
* The 'abrSetup' attribute, which is used to indicate the ABR
parameters needed during call/connection establishment.
* 'abrSetup'属性。(その属性は、呼び出し/コネクション確立の間必要であるABRパラメタを示すのに使用されます)。
* The 'bearerType' attribute, which is used to indicate whether
the underlying bearer is an ATM PVC/SPVC, an ATM SVC, or a
subchannel within an existing ATM SVC/PVC/SPVC.
* 'bearerType'属性か既存のATM SVC/PVC/SPVCの中のサブチャネル。(それは、基本的な運搬人がATM PVC/SPVC、ATM SVCであるかどうかを示すのに使用されます)。
* The 'lij' attribute, which is used to indicate the presence of
a connection that uses the Leaf-initiated-join capability
described in UNI 4.0 [5], and to optionally describe parameters
associated with this capability.
* 'lij'属性。(その属性は、UNI4.0[5]で説明された開始されたLeafが接合している能力を使用する接続の存在を示して、任意にこの能力に関連しているパラメタについて説明するのに使用されます)。
* The 'anycast' attribute, which is used to indicate the
applicability of the anycast function described in UNI 4.0 [5],
and to optionally qualify it with certain parameters.
* 'anycast'属性。(その属性は、UNI4.0[5]で説明されたanycast機能の適用性を示して、あるパラメタで任意にそれに資格を与えるのに使用されます)。
* The 'cache' attribute, which is used to enable SVC caching and
to specify an inactivity timer for SVC release.
* 'キャッシュ'属性。(その属性は、SVCキャッシュを可能にして、SVCリリースのための不活発タイマを指定するのに使用されます)。
* The 'bearerSigIE' attribute, which can be used to represent ITU
Q-series information elements in bit-map form. This is useful
in describing parameters that are not closely coupled to the
ATM and AAL layers. Examples are the B-HLI and B-LLI IEs
specified in ITU Q.2931 [15], and the user-to-user information
element described in ITU Q.2957 [48].
* 'bearerSigIE'属性。(ビットマップフォームにITU Q-シリーズ情報要素を表すのにその属性を使用できます)。 これは密接にATMと結合されないパラメタとAAL層について説明する際に役に立ちます。 例は、ITU Q.2931[15]、およびITU Q.2957[48]で説明されたユーザー間情報要素で指定されたB-HLIとB-LLI IEsです。
Kumar & Mostafa Standards Track [Page 29] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[29ページ]。
5.6.1.1 The 'eecid' attribute
5.6.1.1 'eecid'属性
The 'eecid' attribute is synonymous with the 4-byte 'bnc-id' parameter used by T1SI, the ATM forum and the ITU (Q.1901) standardization effort. The term 'eecid' stands for 'end-to-end connection identifier', while 'bnc-id' stands for 'backbone network connection identifier'. The name "backbone" is slightly misleading since it refers to the entire ATM network including the ATM edge and ATM core networks. In Q.1901 terminology, an ATM "backbone" connects TDM or analog edges.
'eecid'属性はT1SI、ATMフォーラム、およびITU(Q.1901)標準化取り組みによって使用される4バイトの'bnc-イド'パラメタと同義です。 'eecid'という用語は'終わりから終わりへの接続識別子'を表しますが、'bnc-イド'は'バックボーンネットワーク接続識別子'を表します。 ATM縁とATMコアネットワークを含む全体のATMネットワークを示すので、名前「バックボーン」はわずかに紛らわしいです。 Q.1901用語では、ATM「バックボーン」はTDMかアナログの縁をつなげます。
While the term 'bnc-id' might be used in the bearer signaling plane and in an ISUP (Q.1901) call control plane, SDP session descriptors use the neutral term 'eecid'. This provides a common SDP baseline for applications that use ISUP (Q.1901) and applications that use SIP/SIP+.
用語'bnc-イドは'運搬人シグナリング飛行機とISUPで中古(Q.1901)の呼び出し制御飛行機、SDPセッション記述子が中立'用語eecidを使用するということであるかもしれません'が。 これはISUP(Q.1901)を使用するアプリケーションとSIP/SIP+を使用するアプリケーションに一般的なSDP基線を提供します。
Section 5.6.6 depicts the use of the eecid in call establishment procedures. In these procedures, the eecid is used to correlate service-level calls with SVC set-up requests.
セクション5.6 .6 呼設定手順におけるeecidの使用について表現します。 これらの手順で、eecidは、SVCセットアップ要求でサービスレベル呼び出しを関連させるのに使用されます。
In the forward SVC establishment model, the call-terminating gateway selects an eecid and transmits it via SDP to the call-originating gateway. The call originating gateway transmits this eecid to the call terminating gateway via the bearer set-up message (SVC set-up or Q.2630.1 establish request).
前進のSVC設立モデルで、呼び出しを終えるゲートウェイは、SDPを通してeecidを選択して、それを伝えます。 ゲートウェイを溯源する呼び出しは運搬人セットアップメッセージで呼び出し終わりゲートウェイにこのeecidを伝えます(SVCセットアップかQ.2630.1が要求を確立します)。
In the backward SVC establishment model, the call-originating gateway selects an eecid and transmits it via SDP to the call-terminating gateway. The call terminating gateway transmits this eecid to the call originating gateway via the bearer set-up message (SVC set-up or Q.2630.1 establish request).
遅れているSVC設立モデルで、呼び出しを溯源するゲートウェイは、SDPを通してeecidを選択して、それを伝えます。 ゲートウェイを終える呼び出しは運搬人セットアップメッセージで呼び出し起因するゲートウェイにこのeecidを伝えます(SVCセットアップかQ.2630.1が要求を確立します)。
The value of the eecid attribute values needs to be unique within the node terminating the SVC set-up but not across multiple nodes. Hence, the SVC-terminating gateway has complete control over using and releasing values of this parameter. The eecid attribute is used to correlate, one-to-one, received bearer set-up requests with service-level call control signaling.
eecid属性値の値は、SVCセットアップを終えながらノードの中で特有であることが必要ですが、複数のノードの向こう側に必要があるというわけではありません。 したがって、SVC-終わりゲートウェイは、このパラメタの値を使用して、リリースしながら、完全なコントロールを家に迎えます。 1〜1に、サービスレベル呼び出しコントロールが合図していて、容認された運搬人セットアップは、eecid属性が関連するのに使用されるよう要求します。
Within an SDP session description, the eecid attribute is used as follows:
SDPセッション記述の中では、eecid属性は以下の通り使用されます:
a=eecid:<eecid>
a=eecid: <eecid>。
where <eecid> consists of up to 8 hex digits (equivalent to 4 octets). Since this is always represented in hex, the "0x" prefix shall not be used.
<eecid>が最大8十六進法ケタ(4つの八重奏に同等な)から成るところ。 これが十六進法でいつも表されるので、"0x"接頭語を使用しないものとします。
Kumar & Mostafa Standards Track [Page 30] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[30ページ]。
Within the text representation of the <eecid> parameter, hex digits to the left are more significant than hex digits to the right (Section 2.2).
<eecid>パラメタのテキスト表現の中では、左への十六進法ケタは十六進法ケタより右(セクション2.2)に重要です。
This SDP document does not specify how the eecid (synonymous with bnc-id) is to be communicated through bearer signaling (Q.931, UNI, PNNI, AINI, IISP, proprietary signaling equivalent, Q.2630.1). This is a task of these bearer signaling protocols. However, the following informative statements are made to convey a sense of the interoperability that is a goal of current standardization efforts:
このSDPドキュメントはeecid(bnc-イドと同義の)が運搬人シグナリング(Q.931、UNI、PNNI、AINI、IISP、独占シグナリング同等物、Q.2630.1)を通して伝えられることになっている方法を指定しません。 これはこれらの運搬人シグナリングプロトコルに関するタスクです。 しかしながら、以下の有益な声明は現在の標準化の努力の目標である相互運用性の感覚を伝えさせられます:
- ITU Q.2941.3 and the ATMF each recommend the use of the GIT IE for
carrying the eecid (synonymous with bnc-id) in the set-up message
of ATM signaling protocols (Q.2931, UNI 4.0, PNNI, AINI, IISP).
The coding for carrying the eecid (bnc-id) in the GIT IE is
defined in ITU Q.2941.3 and accepted by the ATM forum.
- ITU Q.2941.3とATMFはそれぞれGIT IEのATMシグナリングプロトコル(Q.2931、UNI4.0、PNNI、AINI、IISP)に関するセットアップメッセージでeecid(bnc-イドと同義の)を運ぶ使用を推薦します。 GIT IEでeecid(bnc-イド)を運ぶためのコード化をITU Q.2941.3で定義して、ATMフォーラムは受け入れます。
- Another alternate method is to use the called party subaddress IE.
In some networks, this might be considered a protocol violation
and is not the recommended means of carrying the eecid (bnc-id).
The GIT IE is the preferred method of transporting the eecid
(bnc-id) in ATM signaling messages.
- 別の代替方法は被呼者subaddress IEを使用することです。 いくつかのネットワークでは、これは、プロトコル違反であると考えられるかもしれなくて、eecid(bnc-イド)を運ぶお勧めの手段ではありません。 GIT IEはATMシグナリングメッセージでeecid(bnc-イド)を輸送する適した方法です。
- The establish request (ERQ) message of the Q.2630.1 [37] signaling
protocol can use the SUGR (Served User Generated Reference) IE to
transport the eecid (bnc-id).
- [37]がeecid(bnc-イド)を輸送するのにSUGR(User Generated Referenceに役立つ)IEを使用できるとプロトコルに合図するQ.2630.1に関する要求(ERQ)メッセージを確立してください。
The node assigning the eecid can release and re-use it when it receives a Q.2931 [15] set-up message or a Q.2630.1 [37] establish request message containing the eecid.
Q.2931[15]セットアップメッセージかQ.2630.1を受け取るとき、eecidを割り当てるノードは、それをリリースして、再使用できます。[37] eecidを含む要求メッセージを確立してください。
However, in both cases (backward and forward models), it is recommended that this eecid be retained until the connection terminates. Since the eecid space is large enough, it is not necessary to release it as soon as possible.
しかしながら、どちらの場合も(後ろ向きで前向きなモデル)、接続が終わるまでこのeecidが保有されるのは、お勧めです。 eecidスペースが十分大きいので、できるだけ早くそれをリリースするのは必要ではありません。
5.6.1.2 The 'aalType' attribute
5.6.1.2 'aalType'属性
When present, the 'aalType' attribute is used to indicate the ATM adaptation layer. If this information is redundant with the 'm' line, it can be omitted. The format of the 'aalType' media attribute line is as follows:
存在しているとき、'aalType'属性は、ATM適合層を示すのに使用されます。 'この情報が余分である、'立ち並んでください、そして、それは省略できます。 メディアが結果と考える'aalType'線の形式は以下の通りです:
a=aalType: <aalType>
a=aalType: <aalType>。
Kumar & Mostafa Standards Track [Page 31] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[31ページ]。
Here, <aalType> can take on the following string values: "AAL1", "AAL1_SDT", "AAL1_UDT", "AAL2", "AAL3/4", "AAL5" and "USER_DEFINED_AAL". Note that "AAL3/4" and "USER DEFINED AAL" are not addressed in this document.
ここに、<aalType>は以下のストリング値を呈することができます: 「AAL1"、「AAL1_SDT」、「AAL1_UDT」、「AAL2"、「何AAL3/4インチも、「AAL5"と「ユーザ_は_AALを定義」でした」。 「AAL3/4インチと「ユーザの定義されたAAL」は本書では記述されません。」と述べてください。
5.6.1.3 The 'capability' attribute
5.6.1.3 '能力'属性
When present, the 'capability' attribute indicates the ATM Transfer Capability described in ITU I.371 [28], equivalent to the ATM Service Category described in the UNI 4.1 Traffic Management specification [6].
存在しているとき、'能力'属性はITU I.371[28]で説明されたATM Transfer Capabilityを示します、UNI4.1Traffic Management仕様[6]で説明されたATM Service Categoryに、同等です。
The 'capability' media attribute line is structured in one of the following ways:
メディアが結果と考える'能力'線は以下の方法の1つで構造化されます:
a=capability:<asc> <subtype>
=能力: <asc><「副-タイプ」>。
a=capability:<atc> <subtype>
=能力: <atc><「副-タイプ」>。
Possible values of the <asc> are enumerated below:
<asc>の可能な値は以下に列挙されます:
"CBR", "nrt-VBR", "rt-VBR", "UBR", "ABR", "GFR"
"CBR"、"nrt-VBR"、"rt-VBR""UBR"、"ABR""GFR"
Possible values of the <atc> are enumerated below:
<atc>の可能な値は以下に列挙されます:
"DBR","SBR","ABT/IT","ABT/DT","ABR"
"DBR"、"SBR"「アプト/IT」、「アプト/DT」"ABR"
Some applications might use non-standard <atc> and <asc> values not listed above. Equipment designers will need to agree on the meaning and implications of non-standard transfer capabilities / service capabilities.
いくつかのアプリケーションが標準的でない<atc>と上に記載されなかった<asc>値を使用するかもしれません。 設備デザイナーは、標準的でない転送能力/サービス能力の意味と含意に同意する必要があるでしょう。
The <subtype> field essentially serves as a subscript to the <asc> and <atc> fields. In general, it can take on any integer value, or the "-" value indicating that it does not apply or that the underlying data is to be known by other means, such as provisioning.
<「副-タイプ」>分野は添字として本質的には<asc>と<atc>分野に機能します。 一般に、どんな整数値、または基本的なデータが当てはまらないか、または他の手段によって知られていることであることを示す「-」値も呈することができます、食糧を供給するのなどように。
For an <asc> value of CBR and an <atc> value of DBR, the <subtype> field can be assigned values from Table 4-6 of ITU Q.2931 [15]. These are:
CBRの<asc>価値とDBRの<atc>価値のために、<「副-タイプ」>分野はITU Q.2931[15]のTable4-6からの割り当てられた値であるかもしれません。 これらは以下の通りです。
Kumar & Mostafa Standards Track [Page 32] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[32ページ]。
<asc>/<atc> <subtype> Meaning
<asc>/<atc><「副-タイプ」>意味
"CBR"/"DBR" 1 Voiceband signal transport
(ITU G.711, G.722, I.363)
"CBR"/"DBR" 2 Circuit transport (ITU I.363)
"CBR"/"DBR" 4 High-quality audio signal transport
(ITU I.363)
"CBR"/"DBR" 5 Video signal transport (ITU I.363)
"CBR"/"DBR"1Voiceband信号輸送(ITU G.711、G.722、I.363)"CBR"/"DBR"2サーキット輸送(ITU I.363)"CBR"/"DBR"4高品質な音声信号輸送(ITU I.363)"CBR"/"DBR"5ビデオ信号輸送(ITU I.363)
Note that [15] does not define a <subtype> value of 3.
[15]が3の<「副-タイプ」>価値を定義しないことに注意してください。
For other values of the <asc> and <atc> parameters, the following values can be assigned to the <subtype> field, based on [6] and [28].
<asc>と<atc>パラメタの他の値において、<「副-タイプ」>分野に以下の値を割り当てることができます、[6]と[28]に基づいて。
<asc>/<atc> <subtype> Meaning
<asc>/<atc><「副-タイプ」>意味
nrt-VBR 1 nrt-VBR.1
nrt-VBR 2 nrt-VBR.2
nrt-VBR 3 nrt-VBR.3
rt-VBR 1 rt-VBR.1
rt-VBR 2 rt-VBR.2
rt-VBR 3 rt-VBR.3
UBR 1 UBR.1
UBR 2 UBR.2
GFR 1 GFR.1
GFR 2 GRR.2
SBR 1 SBR1
SBR 2 SBR2
SBR 3 SBR3
nrt-VBR1nrt-VBR.1 nrt-VBR2nrt-VBR.2 nrt-VBR3 1nrt-VBR.3 rt-VBR rt-VBR.1 rt-VBR2rt-VBR.2 rt-VBR3rt-VBR.3UBR1UBR.1UBR2UBR.2GFR1GFR.1GFR2GRR.2SBR1SBR1 SBR2SBR2 SBR3SBR3
It is beyond the scope of this specification to examine the equivalence of some of the ATMF and ITU definitions. These need to be recognized from the ATMF and ITU source specifications and exploited, as much as possible, to simplify ATM node design.
それは、ATMFとITU定義のいくつかの等価性を調べるためにこの仕様の範囲を超えています。 これらのATMFとITUソース仕様から認識された、ATMノードデザインを簡素化するのにできるだけ利用されるべき必要性。
When the bearer connection is a single AAL2 CID connection within a multiplexed AAL2 VC, the 'capability' attribute does not apply.
運搬人接続が多重送信されたAAL2 VCの中の単独のAAL2 CID接続であるときに、'能力'属性は適用されません。
5.6.1.4 The 'qosClass' attribute
5.6.1.4 'qosClass'属性
When present, the 'qosClass' attribute indicates the QoS class specified in ITU I.2965.1 [34].
存在しているとき、'qosClass'属性は、QoSのクラスがITU I.2965.1[34]で指定したのを示します。
The 'qosClass' media attribute line is structured as follows:
メディアが結果と考える'qosClass'線は以下の通り構造化されます:
a=qosClass:<qosClass>
a=qosClass: <qosClass>。
Here, <qosClass> is an integer in the range 0 - 5.
ここで、<qosClass>は範囲0--5の整数です。
Kumar & Mostafa Standards Track [Page 33] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[33ページ]。
<qosClass> Meaning
<qosClass>意味
0 Default QoS
1 Stringent
2 Tolerant
3 Bi-level
4 Unbounded
5 Stringent bi-level
0 デフォルトQoS1Stringent2Tolerant3Bi-レベル4Unbounded5のStringentの両性愛者のレベル
5.6.1.5 The 'bcob' attribute
5.6.1.5 'bcob'属性
When present, the 'bcob' attribute represents the broadband connection oriented bearer class defined in [5], [15] and [33]. It can also be used to indicate whether end-to-end timing is required.
存在しているとき、'bcob'属性は指向の運搬人のクラスが[5]、[15]、および[33]で定義したブロードバンドの接続を表します。 また、終わりから終わりへのタイミングが必要であるかどうかを示すのにそれを使用できます。
The 'bcob' media attribute line is structured as follows:
メディアが結果と考える'bcob'線は以下の通り構造化されます:
a=bcob:<bcob> <eetim>
a=bcob: <bcob><eetim>。
Here, <bcob> is the decimal or hex representation of a 5-bit field. The following values are currently defined:
ここで、<bcob>は5ビットの分野の小数か十六進法表現です。 以下の値は現在、定義されます:
<bcob> Meaning
<bcob>意味
0x01 BCOB-A
0x03 BCOB-C
0x05 Frame relaying bearer service
0x10 BCOB-X
0x18 BCOB-VP (transparent VP service)
0×01 運搬人サービス0×10BCOB-X0x18BCOB-VPをリレーするBCOB-A0x03BCOB-C0×05Frame(わかりやすいVPサービス)
The <eetim> parameter can be assigned a value of "on" or "off" depending on whether end-to-end timing is required or not (Table 4-8 of [15]).
終わりから終わりへのタイミングが必要であるかどうかよって、<eetim>パラメタに“on"か“off"の値を割り当てることができます。([15])のテーブル4-8。
Either of these parameters can be left unspecified by setting it to a "-". A 'bcob' media attribute line with all parameters set to "-" carries no information and should be omitted.
「-」にそれを設定することによって、これらのパラメタのどちらかを不特定のままにできます。 「-」に設定されたすべてのパラメタがあるメディアが結果と考える'bcob'線は、情報を全く運ばないで、省略されるべきです。
5.6.1.6 The 'stc' attribute
5.6.1.6 'stc'属性
When present, the 'stc' attribute represents susceptibility to clipping. The 'stc' media attribute line is structured as follows:
存在しているとき、'stc'属性は敏感さを切り取りように表します。 メディアが結果と考える'stc'線は以下の通り構造化されます:
a=stc:<stc>
a=stc: <stc>。
Here, <stc> is the decimal equivalent of a 2-bit field. Currently, all values are unused and reserved with the following exceptions:
ここで、<stc>は2ビットの分野の10進同等物です。 すべての値が、現在、以下の例外のために未使用であって予約されています:
Kumar & Mostafa Standards Track [Page 34] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[34ページ]。
<stc> value Binary Equivalent Meaning
<stc>値のBinary Equivalent Meaning
0 00 Not susceptible to clipping
1 01 Susceptible to clipping
0 切り取りへの切り取1り01Susceptibleへの影響されやすくない00
5.6.1.7 The 'upcc' attribute
5.6.1.7 'upcc'属性
When present, the 'upcc' attribute represents the user plane connection configuration. The 'upcc' media attribute line is structured as follows:
存在しているとき、'upcc'属性はユーザ飛行機接続構成を表します。 メディアが結果と考える'upcc'線は以下の通り構造化されます:
a=upcc:<upcc>
a=upcc: <upcc>。
Here, <upcc> is the decimal equivalent of a 2-bit field. Currently, all values are unused and reserved with the following exceptions:
ここで、<upcc>は2ビットの分野の10進同等物です。 すべての値が、現在、以下の例外のために未使用であって予約されています:
<upcc> value Binary Equivalent Meaning
<upcc>値のBinary Equivalent Meaning
0 00 Point to point
1 01 Point to multipoint
0 多点への00ポイント・ツー・ポイント1 01Point
5.6.1.8 The 'atmQOSparms' attribute
5.6.1.8 'atmQOSparms'属性
When present, the 'atmQOSparms' attribute is used to describe certain key ATM QoS parameters.
存在しているとき、'atmQOSparms'属性は、ある主要なATM QoSパラメタについて説明するのに使用されます。
The 'atmQOSparms' media attribute line is structured as follows:
メディアが結果と考える'atmQOSparms'線は以下の通り構造化されます:
a=atmQOSparms:<directionFlag><cdvType><acdv><ccdv><eetd><cmtd><aclr>
a=atmQOSparms: <directionFlag><cdvType><acdv><ccdv><eetd><cmtd><aclr>。
The <directionFlag> can be assigned the following string values: "f", "b" and "fb". "f" and "b" indicate the forward and backward directions respectively. "fb" refers to both directions (forward and backward). Conventions for the forward and backward directions are per section 2.3.
以下のストリング値を<directionFlag>に割り当てることができます: 「f」、「b」、および"fb"。 「f」と「b」はそれぞれフォワードと逆方向を示します。 "fb"は両方の指示(前方と後方である)を示します。 フォワードと逆方向のためのコンベンションがセクション2.3単位であります。
The <cdvType> parameter can take on the string values of "PP" and "2P". These refer to the peak-to-peak and two-point CDV as defined in UNI 4.0 [5] and ITU Q.2965.2 [35] respectively.
<cdvType>パラメタは「pp」と"2P"のストリング値を呈することができます。 これらは[35] それぞれピークツーピーク、UNI4.0[5]で定義される2ポイントのCDV、およびITU Q.2965.2を示します。
The CDV parameters, <acdv> and <ccdv>, refer to the acceptable and cumulative CDVs respectively. These are expressed in units of microseconds and represented as the decimal equivalent of a 24-bit field. These use the cell loss ratio, <aclr>, as the "alpha" quantiles defined in the ATMF TM 4.1 specification [6] and in ITU I.356 [47].
CDVパラメタ(<acdv>と<ccdv>)は、それぞれ許容できて累積しているCDVsについて言及します。 これらは、ユニットのマイクロセカンドのときに言い表されて、24ビットの分野の10進同等物として表されます。 これらはセル損失率を使用します、<aclr>、ATMF TM4.1仕様[6]とITU I.356[47]で定義された「アルファ」分位として。
Kumar & Mostafa Standards Track [Page 35] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[35ページ]。
The transit delay parameters, <eetd> and <cmtd>, refer to the end- to-end and cumulative transit delays respectively in milliseconds. These are represented as the decimal equivalents of 16-bit fields. These parameters are defined in Q.2965.2 [35], UNI 4.0 [5] and Q.2931 [15].
ミリセカンドでトランジット遅れパラメタ(<eetd>と<cmtd>)は、それぞれ終わりの終わりの、そして、累積しているトランジット遅れについて言及します。 これらは16ビットの分野の10進同等物として表されます。 これらのパラメタはQ.2965.2[35]、UNI4.0[5]、およびQ.2931[15]で定義されます。
The <aclr> parameter refers to forward and backward acceptable cell loss ratios. This is the ratio between the number of cells lost and the number of cells transmitted. It is expressed as the decimal equivalent of an 8-bit field. This field expresses an order of magnitude n, where n is an integer in the range 1-15. The Cell Loss Ratio takes on the value 10 raised to the power of minus n.
<aclr>パラメタは前進の、そして、後方の許容できるセル損失率について言及します。 これは失われたセルの数と伝えられたセルの数の間の比率です。 それは8ビットの分野の10進同等物として言い表されます。 この分野はnが範囲1-15の整数であるところでnを1桁言い表します。 Cell Loss Ratioは巾乗されたマイナスnの値10を呈します。
The <directionFlag> is always specified. Except for the <directionFlag>, the remaining parameters can be set to "-" to indicate that they are not specified, inapplicable or implied. However, there must be some specified parameters for the line to be useful in an SDP description.
<directionFlag>はいつも指定されます。 <directionFlag>を除いて、「-」に残っているパラメタが、それらが指定されない、不適当であるか、または暗示しているのを示すように設定できます。 しかしながら、線がSDP記述で役に立ついくつかの指定されたパラメタがあるに違いありません。
There can be several 'atmQOSparms' lines in an SDP description.
SDP記述にはいくつかの'atmQOSparms'線があることができます。
An example use of these attributes for an rt-VBR, single-CID AAL2 voice VC is:
これらの属性のrt-VBRの例の使用であり、独身のCID AAL2声のVCは以下の通りです。
a=atmQOSparms:f PP 8125 3455 32000 - 11
a=atmQOSparms:b PP 4675 2155 18000 - 12
a=atmQOSparms: f pp8125 3455 32000--11a=atmQOSparms: b pp4675 2155 18000--12
This implies a forward acceptable peak-to-peak CDV of 8.125 ms, a backward acceptable peak-to-peak CDV of 4.675 ms, forward cumulative peak-to-peak CDV of 3.455 ms, a backward cumulative peak-to-peak CDV of 2.155 ms, a forward end-to-end transit delay of 32 ms, a backward end-to-end transit delay of 18 ms, an unspecified forward cumulative transit delay, an unspecified backward cumulative transit delay, a forward cell loss ratio of 10 raised to minus 11 and a backward cell loss ratio of 10 to the minus 12.
これは8.125msのCDV(4.675msの後方の許容できるピークツーピークCDV)が3.455msの累積しているピークツーピークCDVを送る前進の許容できるピークツーピークを含意して、後方の累積しているピークツーピークは2.155msのCDVです、前進の終わりから終わりへの32msのトランジット遅れ、終わりから終わりへの18msのトランジット後方の遅れ、不特定の前進の累積しているトランジット遅れ、不特定の後方の累積しているトランジット遅れ、マイナス1110対マイナス12のものの後方のセル損失率まで上げられた10の前進のセル損失率。
An example of specifying the same parameters for the forward and backward directions is:
フォワードと逆方向のための同じパラメタを指定する例は以下の通りです。
a=atmQOSparms:fb PP 8125 3455 32000 - 11
a=atmQOSparms: fb pp8125 3455 32000--11
This implies a forward and backward acceptable peak-to-peak CDV of 8.125 ms, a forward and backward cumulative peak-to-peak CDV of 3.455 ms, a forward and backward end-to-end transit delay of 32 ms, an unspecified cumulative transit delay in the forward and backward directions, and a cell loss ratio of 10 raised to minus 11 in the forward and backward directions.
これは8.125ms(3.455msのCDV、終わりから終わりへの32msのトランジット前進の、そして、後方の遅れ、フォワードと逆方向の不特定の累積しているトランジット遅れ、および10のセル損失率がフォワードと逆方向にマイナス11まで提起した前進の、そして、後方の累積しているピークツーピーク)のフォワードと後方の許容できるピークツーピークCDVを含意します。
Kumar & Mostafa Standards Track [Page 36] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[36ページ]。
5.6.1.9 The 'atmTrfcDesc' attribute
5.6.1.9 'atmTrfcDesc'属性
When present, the 'atmTrfcDesc' attribute is used to indicate ATM traffic descriptor parameters. There can be several 'atmTrfcDesc' lines in an SDP description.
存在しているとき、'atmTrfcDesc'属性は、ATM交通記述子パラメタを示すのに使用されます。 SDP記述にはいくつかの'atmTrfcDesc'線があることができます。
The 'atmTrfcDesc' media attribute line is structured as follows:
メディアが結果と考える'atmTrfcDesc'線は以下の通り構造化されます:
a=atmTrfcDesc:<directionFlag><clpLvl>
<pcr><scr><mbs><cdvt><mcr><mfs><fd><te>
a=atmTrfcDesc: <directionFlag><clpLvl><pcr><scr><mb><cdvt><mcr><mf><fd><Te>。
The <directionFlag> can be assigned the following string values: "f", "b" and "fb". "f" and "b" indicate the forward and backward directions respectively. "fb" refers to both directions (forward and backward). Conventions for the forward and backward directions are per section 2.3.
以下のストリング値を<directionFlag>に割り当てることができます: 「f」、「b」、および"fb"。 「f」と「b」はそれぞれフォワードと逆方向を示します。 "fb"は両方の指示(前方と後方である)を示します。 フォワードと逆方向のためのコンベンションがセクション2.3単位であります。
The <directionFlag> is always specified. Except for the <directionFlag>, the remaining parameters can be set to "-" to indicate that they are not specified, inapplicable or implied. However, there must be some specified parameters for the line to be useful in an SDP description.
<directionFlag>はいつも指定されます。 <directionFlag>を除いて、「-」に残っているパラメタが、それらが指定されない、不適当であるか、または暗示しているのを示すように設定できます。 しかしながら、線がSDP記述で役に立ついくつかの指定されたパラメタがあるに違いありません。
The <clpLvl> (CLP level) parameter indicates whether the rates and bursts described in these media attribute lines apply to CLP values of 0 or (0+1). It can take on the following string values: "0", "0+1" and "-". If rates and bursts for both <clpLvl> values are to be described, then it is necessary to use two separate media attribute lines for each direction in the same session descriptor. If the <clpLvl> parameter is set to "-", then it implies that the CLP parameter is known by other means such as default, MIB provisioning etc.
または、<clpLvl>(CLPレベル)パラメタが、属性が裏打ちするこれらのメディアで説明されたレートと炸裂が0のCLP値に適用されるかどうかを示す、(0、+1、) それは以下のストリング値を呈することができます: 「0インチ、「0、+1 」 「-」、」 両方の<clpLvl>値のためのレートと炸裂が説明されるつもりであるなら、2つの別々のメディアが同じセッション記述子の各指示のために線を結果と考えるのが使用に必要です。 <clpLvl>パラメタが「-」に設定されるなら、CLPパラメタがデフォルトなどの他の手段によって知られているのを含意します、MIBがなどに食糧を供給して
The meaning, units and applicability of the remaining parameters are per [6] and [28]:
残っているパラメタの意味、ユニット、および適用性が[6]と[28]単位であります:
PARAMETER MEANING UNITS APPLICABILITY
パラメタ意味ユニットの適用性
<pcr> PCR Cells/ CBR, rt-VBR, nrt-VBR,
second ABR, UBR, GFR;
CLP=0,0+1
<pcr>PCR Cells/ CBR、rt-VBR、nrt-VBR、第2ABR、UBR、GFR。 CLP=0、0、+1
<scr> SCR Cells/ rt-VBR, nrt-VBR;
second CLP=0,0+1
<scr>SCRセル/rt-VBR、nrt-VBR。 +1にCLP=0、0を後援してください。
<mbs> MBS Cells rt-VBR, nrt-VBR,
GFR;
CLP=0,0+1
<mb>mbセルrt-VBR、nrt-VBR、GFR。 CLP=0、0、+1
Kumar & Mostafa Standards Track [Page 37] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[37ページ]。
<cdvt> CDVT Microsec. CBR, rt-VBR, nrt-VBR,
ABR, UBR, GFR;
CLP=0,0+1
<cdvt>CDVTマイクロセカンド。 CBR、rt-VBR、nrt-VBR、ABR、UBR、GFR。 CLP=0、0、+1
<mcr> MCR Cells/ ABR,GFR;
second CLP=0+1
<mcr>MCRセル/ABR、GFR。 第2CLP=0+1
<mfs> MFS Cells GFR;
CLP=0,0+1
<mf>mfセルGFR。 CLP=0、0、+1
<fd> Frame "on"/"off" CBR, rt-VBR, nrt-VBR,
Discard ABR, UBR, GFR;
Allowed CLP=0+1
<fd>フレーム“on"/"off" CBR(rt-VBR、nrt-VBR)はABR、UBR、GFRを捨てます。 許容CLP=0+1
<te> CLP "on"/"off" CBR, rt-VBR, nrt-VBR,
tagging ABR, UBR, GFR;
Enabled CLP=0
<Te>CLP “on"/"off" CBR、rt-VBR、nrt-VBR、タグ付けABR、UBR、GFR。 可能にされたCLP=0
<fd> indicates that frame discard is permitted. It can take on the string values of "on" or "off". Note that, in the GFR case, frame discard is always enabled. Hence, this subparameter can be set to "-" in the case of GFR. Since the <fd> parameter is independent of CLP, it is meaningful in the case when <clpLvl> = "0+1". It should be set to "-" for the case when <clpLvl> = "0".
<fd>は、フレーム破棄が受入れられるのを示します。 それは“on"か“off"のストリング値を呈することができます。 フレーム破棄がGFR場合でいつも可能にされることに注意してください。 したがって、この「副-パラメタ」はGFRの場合で「-」に用意ができることができます。 <fd>パラメタがCLPから独立しているので、<clpLvl>=であるときに、それが場合で重要である、「0 +1」 <clpLvl>=「0インチ」であるときに、それはケースのための「-」に設定されるべきです。
<te> (tag enable) indicates that CLP tagging is allowed. These can take on the string values of "on" or "off". Since the <te> parameter applies only to cells with a CLP of 0, it is meaningful in the case when <clpLvl> = "0". It should be set to "-" for the case when <clpLvl> = "0+1".
<Te>、(タグが可能にする、)、CLPタグ付けが許されているのを示します。 これらは“on"か“off"のストリング値を呈することができます。 <Te>パラメタが0のCLPと共にセルだけに適用されるので、<clpLvl>=「0インチ」であるときに、それは場合で重要です。 <clpLvl>=であるときに、それがケースのための「-」に設定されるべきである、「0 +1」
An example use of these media attribute lines for an rt-VBR, single- CID AAL2 voice VC is:
属性がrt-VBR、独身のCID AAL2声のVCのために裏打ちするこれらのメディアの例の使用は以下の通りです。
a=atmTrfcDesc:f 0+1 200 100 20 - - - on -
a=atmTrfcDesc:f 0 200 80 15 - - - - off
a=atmTrfcDesc:b 0+1 200 100 20 - - - on -
a=atmTrfcDesc:b 0 200 80 15 - - - - off
a=atmTrfcDesc: f0+1 200 100 20------オン--、a=atmTrfcDesc: f、0 200 80 15--------オフa=atmTrfcDesc: b0+1 200 100 20------オン--、a=atmTrfcDesc: b0 200、80 15--、--、--、下に。
This implies a forward and backward PCR of 200 cells per second all cells regardless of CLP, forward and backward PCR of 200 cells per second for cells with CLP=0, a forward and backward SCR of 100 cells per second for all cells regardless of CLP, a forward and backward SCR of 80 cells per second for cells with CLP=0, a forward and backward MBS of 20 cells for all cells regardless of CLP, a forward
これはCLPにかかわらず200のセルの1秒あたり1前進の、そして、後方のPCRにすべてのセルを含意します、CLP=0があるセルのための秒あたり200のセルの前進の、そして、後方のPCR、CLPにかかわらずすべてのセルのための1秒あたり100のセルの前進の、そして、後方のSCR、CLP=0があるセルのための秒あたり80のセルの前進の、そして、後方のSCR、CLPにかかわらずすべてのセルのための20のセルの前進の、そして、後方のMBS、フォワード
Kumar & Mostafa Standards Track [Page 38] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[38ページ]。
and backward MBS of 15 cells for cells with CLP=0, an unspecified CDVT which can be known by other means, and an MCR and MFS which are unspecified because they are inapplicable. Frame discard is enabled in both the forward and backward directions. Tagging is not enabled in either direction.
そして、彼らが不適当であるので不特定のCLP=0があるセルのための15のセルの後方のMBS、他の手段が知ることができる、不特定のCDVT、MCR、およびMFS。 フレーム破棄はフォワードと逆方向の両方で可能にされます。 タグ付けはどちらの方向にも可能にされません。
The <pcr>, <scr>, <mbs>, <cdvt>, <mcr> and <mfs> are represented as decimal integers, with range as defined in Section 6. See section 2.2 regarding the omission of leading zeros in decimal representations.
<pcr>、<scr>、<mb>、<cdvt>、<mcr>、および<mf>は10進整数としてセクション6で定義される範囲で表されます。 10進表現における、先行ゼロの省略に関するセクション2.2を見てください。
5.6.1.10 The 'abrParms' attribute
5.6.1.10 'abrParms'属性
When present, the 'abrParms' attribute is used to indicate the ' additional' ABR parameters specified in the UNI 4.0 signaling specification [5]. There can be several 'abrParms' lines in an SDP description.
存在しているとき、'abrParms'属性は、'追加している'ABRパラメタがUNI4.0シグナリング仕様[5]で指定したのを示すのに使用されます。 SDP記述にはいくつかの'abrParms'線があることができます。
The 'abrParms' media attribute line is structured as follows:
メディアが結果と考える'abrParms'線は以下の通り構造化されます:
a=abrParms:<directionFlag><nrm><trm><cdf><adtf>
a=abrParms: <directionFlag><nrm><trm><cdf><adtf>。
The <directionFlag> can be assigned the following string values: "f", "b" and "fb". "f" and "b" indicate the forward and backward directions respectively. "fb" refers to both directions (forward and backward). Conventions for the forward and backward directions are per section 2.3.
以下のストリング値を<directionFlag>に割り当てることができます: 「f」、「b」、および"fb"。 「f」と「b」はそれぞれフォワードと逆方向を示します。 "fb"は両方の指示(前方と後方である)を示します。 フォワードと逆方向のためのコンベンションがセクション2.3単位であります。
The <directionFlag> is always specified. Except for the <directionFlag>, the remaining parameters can be set to "-" to indicate that they are not specified, inapplicable or implied. However, there must be some specified parameters for the line to be useful in an SDP description.
<directionFlag>はいつも指定されます。 <directionFlag>を除いて、「-」に残っているパラメタが、それらが指定されない、不適当であるか、または暗示しているのを示すように設定できます。 しかしながら、線がSDP記述で役に立ついくつかの指定されたパラメタがあるに違いありません。
These parameters are mapped into the ABR service parameters in [6] in the manner described below. These parameters can be represented in SDP as decimal integers, with fractions permitted for some. Details of the meaning, units and applicability of these parameters are in [5] and [6].
これらのパラメタは以下で説明された方法で[6]のABRサービスパラメタに写像されます。 断片がいくつかのために受入れられている状態で、10進整数としてSDPにこれらのパラメタを表すことができます。 これらのパラメタの意味の詳細、ユニット、および適用性が[5]と[6]にあります。
In SDP, these parameters are represented as the decimal or hex equivalent of the binary fields mentioned below.
SDPでは、2進の分野の小数か十六進法同等物が以下に言及したようにこれらのパラメタは表されます。
Kumar & Mostafa Standards Track [Page 39] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[39ページ]。
+-----------+----------------------------------+-----------------------+ | PARAMETER | MEANING | FIELD SIZE | +-----------+----------------------------------+-----------------------+ | <nrm> | Maximum number of cells per | 3 bits | | | forward Resource Management cell | | +-----------+----------------------------------+-----------------------+ | <trm> | Maximum time between | 3 bits | | | forward Resource Management cells| | +-----------+----------------------------------+-----------------------+ | <cdf> | Cutoff Decrease Factor | 3 bits | +-----------+----------------------------------+-----------------------+ | <adtf> | Allowed Cell Rate Decrease | 10 bits | | | Time Factor | | +-----------+----------------------------------+-----------------------+
+-----------+----------------------------------+-----------------------+ | パラメタ| 意味| 分野サイズ| +-----------+----------------------------------+-----------------------+ | <nrm>。| 最大数のセル| 3ビット| | | 前進のResource Managementセル| | +-----------+----------------------------------+-----------------------+ | <trm>。| 間の最大の時間| 3ビット| | | 前進のResource Managementセル| | +-----------+----------------------------------+-----------------------+ | <cdf>。| 締切りの減少要素| 3ビット| +-----------+----------------------------------+-----------------------+ | <adtf>。| 許容セルレート減少| 10ビット| | | 時間要素| | +-----------+----------------------------------+-----------------------+
5.6.1.11 The 'abrSetup' attribute
5.6.1.11 'abrSetup'属性
When present, the 'abrSetup' attribute is used to indicate the ABR parameters needed during call/connection establishment (Section 10.1.2.2 of the UNI 4.0 signaling specification [5]). This line is structured as follows:
存在しているとき、'abrSetup'属性が呼び出し/コネクション確立の間必要であるABRパラメタを示すのに使用される、(セクション10.1 .2 .2のUNI4.0シグナリング仕様[5])。 この線は以下の通り構造化されます:
a=abrSetup:<ficr><bicr><ftbe><btbe><crmrtt><frif><brif><frdf><brdf>
a=abrSetup: <ficr><bicr><ftbe><btbe><crmrtt><frif><brif><frdf><brdf>。
These parameters are defined as follows:
これらのパラメタは以下の通り定義されます:
Kumar & Mostafa Standards Track [Page 40] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[40ページ]。
+-----------+----------------------------------+-----------------------+ | PARAMETER | MEANING | REPRESENTATION | +-----------+----------------------------------+-----------------------+ | <ficr> | Forward Initial Cell Rate | Decimal equivalent | | | (Cells per second) | of 24-bit field | +-----------+----------------------------------+-----------------------+ | <bicr> | Backward Initial Cell Rate | Decimal equivalent | | | (Cells per second) | of 24-bit field | +-----------+----------------------------------+-----------------------+ | <ftbe> | Forward transient buffer | Decimal equivalent | | | exposure (Cells) | of 24-bit field | +-----------+----------------------------------+-----------------------+ | <btbe> | Backward transient buffer | Decimal equivalent | | | exposure (Cells) | of 24-bit field | +-----------+----------------------------------+-----------------------+ | <crmrtt> | Cumulative RM round-trip time | Decimal equivalent | | | (Microseconds) | of 24-bit field | +-----------+----------------------------------+-----------------------+ | <frif> | Forward rate increase factor | Decimal integer | | | (used to derive cell count) | 0 -15 | +-----------+----------------------------------+-----------------------+ | <brif> | Backward rate increase factor | Decimal integer | | | (used to derive cell count) | 0 -15 | +-----------+----------------------------------+-----------------------+ | <frdf> | Forward rate decrease factor | Decimal integer | | | (used to derive cell count) | 0 -15 | +-----------+----------------------------------+-----------------------+ | <brdf> | Backward rate decrease factor | Decimal integer | | | (used to derive cell count) | 0 -15 | +-----------+----------------------------------+-----------------------+
+-----------+----------------------------------+-----------------------+ | パラメタ| 意味| 表現| +-----------+----------------------------------+-----------------------+ | <ficr>。| 前進の初期のセルレート| 10進同等物| | | (1秒あたりのセル) | 24ビットの分野について| +-----------+----------------------------------+-----------------------+ | <bicr>。| 後方の初期のセルレート| 10進同等物| | | (1秒あたりのセル) | 24ビットの分野について| +-----------+----------------------------------+-----------------------+ | <ftbe>。| 前進の一時的なバッファ| 10進同等物| | | 暴露(セル)| 24ビットの分野について| +-----------+----------------------------------+-----------------------+ | <btbe>。| 後方の一時的なバッファ| 10進同等物| | | 暴露(セル)| 24ビットの分野について| +-----------+----------------------------------+-----------------------+ | <crmrtt>。| 累積しているRM往復の時間| 10進同等物| | | (マイクロセカンド) | 24ビットの分野について| +-----------+----------------------------------+-----------------------+ | <frif>。| 先物相場は要素を増強します。| 10進整数| | | (細胞計数を引き出すのにおいて中古)です。 | 0 -15 | +-----------+----------------------------------+-----------------------+ | <brif>。| 後方のレートは要素を増強します。| 10進整数| | | (細胞計数を引き出すのにおいて中古)です。 | 0 -15 | +-----------+----------------------------------+-----------------------+ | <frdf>。| 先物相場減少要素| 10進整数| | | (細胞計数を引き出すのにおいて中古)です。 | 0 -15 | +-----------+----------------------------------+-----------------------+ | <brdf>。| 後方のレート減少要素| 10進整数| | | (細胞計数を引き出すのにおいて中古)です。 | 0 -15 | +-----------+----------------------------------+-----------------------+
See Section 2.3 for a definition of the terms 'forward' and 'backward'.
'フォワード'という用語の定義に関してセクション2.3を見てください、そして、'後方に'。
If any of these parameters in the 'abrSetup' media attribute line is not specified, is inapplicable or is implied, then it is set to h "- ".
メディアが結果と考える'abrSetup'系列におけるこれらのパラメタのどれかが指定されないか、不適当であるか、または含意されるなら、それはh「-」に設定されます。
5.6.1.12 The 'bearerType' attribute
5.6.1.12 'bearerType'属性
When present, the 'bearerType' attribute is used to indicate whether the underlying bearer is an ATM PVC/SPVC, an ATM SVC, or a subchannel within an existing ATM SVC/PVC/SPVC. Additionally, for ATM SVCs and AAL2 CID connections, the 'bearerType' attribute can be used to indicate whether the media gateway initiates connection set-up via bearer signaling (Q.2931-based or Q.2630.1 based). The format of the 'bearerType' media attribute line is as follows:
存在しているとき、'bearerType'属性は、既存のATM SVC/PVC/SPVCの中に基本的な運搬人がATM PVC/SPVCであるか、そして、ATM SVC、またはサブチャネルを示すのに使用されます。 さらに、ATM SVCsとAAL2 CID接続において、運搬人シグナリング(Q.2931ベースの、または、Q.2630.1に基づいている)でメディアゲートウェイが接続セットアップに着手するかどうかを示すのに'bearerType'属性を使用できます。 メディアが結果と考える'bearerType'系列の形式は以下の通りです:
Kumar & Mostafa Standards Track [Page 41] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[41ページ]。
a=bearerType: <bearerType> <localInitiation>
a=bearerType: <bearerType><localInitiation>。
The <bearerType> field can take on the following string values:
<bearerType>分野は以下のストリング値を呈することができます:
"PVC", "SVC", "CID", with semantics as defined above. Here, "PVC" includes both the PVC and SPVC cases.
上で定義される意味論がある"PVC"、"SVC"「Cid。」 ここに、"PVC"はPVCとSPVCケースの両方を含んでいます。
In the case when the underlying bearer is a PVC/SPVC, or a CID assigned by the MGC rather than through bearer signaling, the <localInitiation> flag can be omitted or set to "-". In the case when bearer signaling is used, this flag can be omitted when it is known by default or by other means whether the media gateway initiates the connection set-up via bearer signaling. Only when this is to be indicated explicitly that the <localInitiation> flag takes on the values of "on" or "off". An "on" value indicates that the media gateway is responsible for initiating connection set-up via bearer signaling (SVC signaling or Q.2630.1 signaling), an "off" value indicates otherwise.
基本的な運搬人がPVC/SPVCであることのケース、または運搬人シグナリングを通してというよりむしろMGCによって割り当てられたCIDでは、<localInitiation>旗を「-」に省略するか、または設定できます。 運搬人シグナリングが使用されているときの場合では、それがデフォルトでか他の手段によって知られているとき、運搬人シグナリングでメディアゲートウェイが接続セットアップに着手するか否かに関係なく、この旗を省略できます。 これが明らかに示されることになっているときだけ、<localInitiation>が弛むのが“on"か“off"の値を呈します。 “on"値は、メディアゲートウェイが運搬人シグナリング(SVCシグナリングかQ.2630.1シグナリング)で接続セットアップに着手するのに原因となるのを示します、と“off"値は別の方法で示します。
5.6.1.13 The 'lij' attribute
5.6.1.13 'lij'属性
When present, the 'lij' attribute is used to indicate the presence of a connection that uses the Leaf-initiated-join capability described in UNI 4.0 [5], and to optionally describe parameters associated with this capability. The format of the 'lij' media attribute line is as follows:
存在しているとき、'lij'属性は、UNI4.0[5]で説明された開始されたLeafが接合している能力を使用する接続の存在を示して、任意にこの能力に関連しているパラメタについて説明するのに使用されます。 メディアが結果と考える'lij'系列の形式は以下の通りです:
a=lij: <sci><lsn>
a=lij: <sci><lsn>。
The <sci> (screening indication) is a 4-bit field expressed as a decimal or hex integer. It is defined in the UNI 4.0 signaling specification [5]. It is possible that the values of this field will be defined later by the ATMF and/or ITU. Currently, all values are reserved with the exception of 0, which indicates a 'Network Join without Root Notification'.
<sci>(選別指示)は小数か十六進法整数として言い表された4ビットの分野です。 それはUNI4.0シグナリング仕様[5]に基づき定義されます。 この分野の値が後でATMF、そして/または、ITUによって定義されるのは、可能です。 現在、0を除いて、すべての値が予約されます('Root NotificationのないネットワークJoin'を示します)。
The <lsn> (leaf sequence number) is a 32-bit field expressed as a decimal or hex integer. Per the UNI 4.0 signaling specification [5], it is used by a joining leaf to associate messages and responses during LIJ (leaf initiated join) procedures.
<lsn>(葉の一連番号)は小数か十六進法整数として言い表された32ビットの分野です。 それはUNI4.0シグナリング仕様[5]に従って接合葉によって使用されて、LIJ(開始された葉は接合する)手順の間、メッセージと応答を関連づけます。
Each of these fields can be set to a "-" when the intention is to not specify them in an SDP descriptor.
意志がSDP記述子でそれらを指定しないことであるなら「-」にそれぞれのこれらの分野を設定できます。
Kumar & Mostafa Standards Track [Page 42] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[42ページ]。
5.6.1.14 The 'anycast' attribute
5.6.1.14 'anycast'属性
When present, the 'anycast' attribute line is used to indicate the applicability of the anycast function described in UNI 4.0 [5]. Optional parameters to qualify this function are provided. The format of the 'anycast' attribute is:
存在しているとき、'anycast'属性系列は、UNI4.0[5]で説明されたanycast機能の適用性を示すのに使用されます。 この機能に資格を与える任意のパラメタを提供します。 'anycast'属性の形式は以下の通りです。
a=anycast: <atmGroupAddress> <cdStd> <conScpTyp> <conScpSel>
a=anycast: <atmGroupAddress><cdStd><conScpTyp><conScpSel>。
The <atmGroupAddress> is per Annex 5 of UNI 4.0 [5]. Within an SDP descriptor, it can be represented in one of the formats (NSAP, E.164, GWID/ALIAS) described elsewhere in this document.
<atmGroupAddress>がUNI4.0[5]のAnnex5単位であります。 SDP記述子の中では、ほかの場所で本書では説明された形式(NSAP、E.164、GWID/アリア)の1つでそれを表すことができます。
The remaining subparameters mirror the connection scope selection information element in UNI 4.0 [5]. Their meaning and representation is as shown below:
残っている「副-パラメタ」はUNI4.0[5]で接続範囲選択情報要素を反映します。 以下で示されるとして彼らの意味と表現があります:
PARAMETER MEANING REPRESENTATION
パラメタ意味表現
<cdStd> Coding standard for the Decimal or hex
connection scope selection IE equivalent of
Definition: UNI 4.0 [5] 2 bits
DefinitionのDecimalか十六進法接続範囲選択IE同等物の<cdStd>Coding規格: UNI4.0[5]2ビット
<conScpTyp> Type of connection scope Decimal or hex
Definition: UNI 4.0 [5] equivalent of
4 bits
接続範囲Decimalか十六進法Definitionの<conScpTyp>Type: 4ビットのUNI4.0[5]同等物
<conScpSel> Connection scope selection Decimal or hex
Definition: UNI 4.0 [5] equivalent of
8 bits
<conScpSel>Connection範囲の選択Decimalか十六進法Definition: 8ビットのUNI4.0[5]同等物
Currently, all values of <cdStd> and <conScpTyp> are reserved with the exception of <cdStd> = 3 (ATMF coding standard) and <conScpTyp> = 1 (connection scope type of 'organizational').
現在、<cdStd>=3(ATMFコーディング標準)と<conScpTyp>=1('組織的'の接続範囲タイプ)を除いて、<cdStd>と<conScpTyp>のすべての値が予約されます。
Each of these fields can be set to a "-" when the intention is to not specify them in an SDP descriptor.
意志がSDP記述子でそれらを指定しないことであるなら「-」にそれぞれのこれらの分野を設定できます。
5.6.1.15 The 'cache' attribute
5.6.1.15 'キャッシュ'属性
This attribute is used to enable SVC caching. This attribute has the following format:
この属性は、SVCキャッシュを可能にするのに使用されます。 この属性に、以下の形式があります:
a=cache:<cacheEnable><cacheTimer>
=キャッシュ: <cacheEnable><cacheTimer>。
Kumar & Mostafa Standards Track [Page 43] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[43ページ]。
The <cacheEnable> flag indicates whether caching is enabled or not, corresponding to the string values of "on" and "off" respectively.
それぞれ“on"と“off"のストリング値に対応している、<cacheEnable>旗は、キャッシュが可能にされるかどうかを示します。
The <cacheTimer> indicates the period of inactivity following which the SVC is to be released by sending an SVC release message into the network. This is specified as the decimal or hex equivalent of a 32-bit field, indicating the timeout in seconds. As usual, leading zeros can be omitted. For instance,
<cacheTimer>は、どれに続いて起こる不活発の期間にSVCがSVCリリースメッセージをネットワークに送ることによってリリースされることになっているのを示します。 秒のタイムアウトを示して、これは32ビットの分野の小数か十六進法同等物として指定されます。 いつものように、先行ゼロを省略できます。 例えば
a=cache:on 7200
=キャッシュ: 7200に関して
implies that the cached SVC is to be deleted if it is idle for 2 hours.
それが2時間活動していないなら、キャッシュされたSVCは削除されることになっているつもりです。
The <cacheTimer> can be set to "-" if it is inapplicable or implied.
それが不適当であるか、または暗示しているなら、<cacheTimer>は「-」に用意ができることができます。
5.6.1.16 The 'bearerSigIE' attribute
5.6.1.16 'bearerSigIE'属性
ATM signaling standards provide 'escape mechanisms' to represent, signal and negotiate higher-layer parameters. Examples are the B-HLI and B-LLI IEs specified in ITU Q.2931 [15], and the user-to-user information element described in ITU Q.2957 [48].
ATMシグナリング規格は、より高い層のパラメタに表して、合図して、交渉するために'逃避機制'を提供します。 例は、ITU Q.2931[15]、およびITU Q.2957[48]で説明されたユーザー間情報要素で指定されたB-HLIとB-LLI IEsです。
The 'bearerSigIE'(bearer signaling information element) attribute is defined to allow a similar escape mechanism that can be used with these ATM SDP conventions. The format of this media attribute line is as follows:
'bearerSigIE'(運搬人シグナリング情報要素)属性は、これらのATM SDPコンベンションと共に使用できる同様の逃避機制を許容するために定義されます。 このメディア属性系列の形式は以下の通りです:
a=bearerSigIE: <bearerSigIEType> <bearerSigIELng> <bearerSigIEVal>
a=bearerSigIE: <bearerSigIEType><bearerSigIELng><bearerSigIEVal>。
When an 'bearerSigIE' media attribute line is present, all its subparameters are mandatory. The "0x" prefix is not used since these are always represented in hex.
すべての「副-パラメタ」が'bearerSigIE'メディア属性がいつ立ち並ぶかが、存在しているのが義務的です。 これらが十六進法でいつも表されるので、"0x"接頭語は使用されていません。
The <bearerSigIEType> is represented as exactly 2 hex digits. It is the unique IE identifier as defined in the ITU Q-series standards. Leading zeros are not omitted. Some pertinent values are 7E (User- user IE per ITU Q.2957 [48]), 5F (B-LLI IE) and 5D (B-HLI IE). B-LLI and B-HLI, which stand for Broadband Low-layer Information and Broadband High-layer Information respectively, are defined in ITU Q.2931 [15]. Both of these refer to layers above the ATM adaptation layer.
<bearerSigIEType>はちょうど2十六進法ケタとして表されます。 それはITU Q-シリーズ規格で定義されるようにユニークなIE識別子です。 先行ゼロは省略されません。 いくつかの適切な値が7Eです。(5のITU Q.2957[48])あたりのユーザユーザIE、F(B-LLI IE)、および5D(B-HLI IE)。 B-LLIとB-HLI(それぞれBroadband Low-層の情報とBroadband High-層の情報を表す)はITU Q.2931[15]で定義されます。 これらの両方がATM適合層の上の層について言及します。
The <bearerSigIELng> consists of 1-4 hex digits. It is the length of the information element in octets. Leading zeros may be omitted.
<bearerSigIELng>は1-4 十六進法ケタから成ります。 それは八重奏で、情報要素の長さです。 先行ゼロは省略されるかもしれません。
Kumar & Mostafa Standards Track [Page 44] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[44ページ]。
The <bearerSigIEVal> is the value of the information element, represented as a hexadecimal bit map. Although the size of this bit map is network/ service dependent, setting an upper bound of 256 octets (512 hex digits) is adequate. Since this a bit map, leading zeros should not be omitted. The number of hex digits in this bit map is even.
<bearerSigIEVal>は16進ビットマップとして表された情報の価値要素です。 このビットマップのサイズはネットワーク/サービス扶養家族ですが、256の八重奏(512十六進法ケタ)の上限を設定するのは適切です。 これ以来、少し、地図、先行ゼロを省略するべきではありません。 このビットマップの十六進法ケタの数は偶数です。
5.6.2 ATM Adaptation Layer (AAL) attributes
5.6.2 ATM Adaptation Layer(AAL)属性
The following is a summary list of the SDP media attributes that can be used to describe the ATM Adaptation Layer (AAL). These are detailed in subsequent subsections.
↓これはATM Adaptation Layer(AAL)について説明するのに使用できるSDPメディア属性の概要リストです。 これらはその後の小区分で詳細です。
* The 'aalApp' attribute, which is used to point to the
controlling standard for an application layer above the ATM
adaptation layer.
* 'aalApp'属性。(その属性は、ATM適合層の上の応用層の制御規格を示すのに使用されます)。
* The 'cbrRate' attribute, which represents the CBR rate octet
defined in Table 4-6 of ITU Q.2931 [15].
* 'cbrRate'属性。(その属性はITU Q.2931[15]のTable4-6で定義されたCBRレート八重奏を表します)。
* The 'sbc' attribute, which denotes the subchannel count in the
case of n x 64 clear channel communication.
* 'sbc'属性。(その属性はn x64クリア・チャンネルコミュニケーションの場合でサブチャネルカウントを指示します)。
* The 'clkrec' attribute, which indicates the clock recovery
method for AAL1 unstructured data transfer (UDT).
* 'clkrec'属性。(その属性はAAL1の不統一なデータ転送(UDT)のために時計回復メソッドを示します)。
* The 'fec' attribute, which indicates the use of forward error
correction.
* 'fec'属性。(その属性は前進型誤信号訂正の使用を示します)。
* The 'prtfl' attribute, which indicates indicate the fill level
of partially filled cells.
* 'prtfl'属性。(その属性は部分的にいっぱいにされたセルの中詰めレベルを示すように示します)。
* The 'structure' attribute, which is used to indicate the
presence or absence of AAL1 structured data transfer (SDT), and
the size of the SDT blocks.
* '構造'属性とSDTブロックのサイズ。(それは、AAL1の存在か不在がデータ転送(SDT)を構造化したのを示すのに使用されます)。
* The 'cpsSDUsize' attribute, which is used to indicate the
maximum size of the CPCS SDU payload.
* 'cpsSDUsize'属性。(その属性は、CPCS SDUペイロードの最大サイズを示すのに使用されます)。
* The 'aal2CPS' attribute, which is used to indicate that an AAL2
CPS sublayer as defined in ITU I.363.2 [13] is associated with
the VCC referred to in the 'm' line. Optionally, it can be
used to indicate selected CPS options and parameter values for
this VCC.
* ''aal2CPS'属性、'立ち並んでください。(それは、ITU I.363.2[13]で定義されるAAL2 CPS副層が言及されていた状態で関連しているのを中のVCCを示すのに使用されます)。 任意に、このVCCのために選択されたCPSオプションとパラメタ値を示すのにそれを使用できます。
* The 'aal2CPSSDUrate' attribute, which is used to place an upper
bound on the SDU bit rate for an AAL2 CID.
* 'aal2CPSSDUrate'属性。(その属性は、AAL2 CIDのためにSDUビット伝送速度に上限を置くのに使用されます)。
Kumar & Mostafa Standards Track [Page 45] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[45ページ]。
* The 'aal2sscs3661unassured' attribute, which is used to
indicate the presence of an AAL2 SSCS sublayer with unassured
transmission as defined in ITU I.366.1 [12]. Optionally, it
can be used to indicate selected options and parameter values
for this SSCS.
* 'aal2sscs3661unassured'属性。(その属性は、ITU I.366.1[12]で定義されるように非保証されたトランスミッションでAAL2 SSCS副層の存在を示すのに使用されます)。 任意に、このSSCSのために選択されたオプションとパラメタ値を示すのにそれを使用できます。
* The 'aal2sscs3661assured' attribute, which is used to indicate
the presence of an AAL2 SSCS sublayer with assured transmission
as defined in ITU I.366.1 [12]. Optionally, it can be used to
indicate selected options and parameter values for this SSCS.
* 'aal2sscs3661assured'属性。(その属性は、ITU I.366.1[12]で定義されるように確実なトランスミッションでAAL2 SSCS副層の存在を示すのに使用されます)。 任意に、このSSCSのために選択されたオプションとパラメタ値を示すのにそれを使用できます。
* The 'aal2sscs3662' attribute, which is used to indicate the
presence of an AAL2 SSCS sublayer as defined in ITU I.366.2.
Optionally, it can be used to indicate selected options and
parameter values for this SSCS.
* 'aal2sscs3662'属性。(その属性は、ITU I.366.2で定義されるようにAAL2 SSCS副層の存在を示すのに使用されます)。 任意に、このSSCSのために選択されたオプションとパラメタ値を示すのにそれを使用できます。
* The 'aal5sscop' attribute, which is used to indicate the
existence of an SSCOP protocol layer over an AAL5 CPS layer,
and the parameters which pertain to this SSCOP layer.
* 'aal5sscop'属性と関係するパラメタはこのSSCOPに層にされます。(属性は、AAL5 CPS層の上にSSCOPプロトコル層の存在を示すのに使用されます)。
5.6.2.1 The 'aalApp' attribute
5.6.2.1 'aalApp'属性
When present, the 'aalApp' attribute is used to point to the controlling standard for an application layer above the ATM adaptation layer. The format of the 'aalApp' media attribute line is as follows:
存在しているとき、'aalApp'属性は、ATM適合層の上の応用層の制御規格を示すのに使用されます。 メディアが結果と考える'aalApp'系列の形式は以下の通りです:
a=aalApp: <appClass> <oui> <appId>
a=aalApp: <appClass><oui><appId>。
If any of the subparameters, <appClass>, <oui> or <appId>, is meant to be left, unspecified, it is set to "-". However, an 'aalApp' attribute line with all subparameters set to "-" carries no information and should be omitted.
「副-パラメタ」のどれか(<appClass>、<oui>または<appId>)が残されることになっているなら、不特定であることで、それは「-」に設定されます。 しかしながら、「-」に用意ができているすべての「副-パラメタ」がある'aalApp'属性系列は、情報を全く運ばないで、省略されるべきです。
The <appClass>, or application class, field can take on the string values listed below.
appClass>、またはアプリケーションのクラスがさばく<は以下に記載されたストリング値を呈することができます。
This list is not exhaustive. An "X-" prefix should be used with <appClass> values not listed here.
このリストは徹底的ではありません。 「X」接頭語はここに記載されていない<appClass>値と共に使用されるべきです。
<appClass> Meaning
<appClass>意味
"itu_h323c" Annex C of H.323 which specifies direct
RTP on AAL5 [45].
AAL5[45]でダイレクトRTPを指定するH.323の「itu_h323c」Annex C。
"af83" af-vtoa-0083.001, which specifies
variable size AAL5 PDUs with PCM voice
and a null SSCS [46].
「af83" af-vtoa-0083.001。」(af83" af-vtoa-0083.001はPCM声とヌルSSCS[46]で可変サイズAAL5 PDUsを指定します)。
Kumar & Mostafa Standards Track [Page 46] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[46ページ]。
"AAL5_SSCOP" SSCOP as defined in ITU Q.2110 [43]
running over an AAL5 CPS [21].
No information is provided regarding
any layers above SSCOP such as Service
Specific Coordination Function (SSCF)
layers.
AAL5 CPS[21]をひきながらITU Q.2110[43]で定義される「AAL5_SSCOP」SSCOP。 SSCOPの上のService Specific Coordination Function(SSCF)層などのどんな層に関しても情報を全く提供しません。
"itu_i3661_unassured" SSCS with unassured transmission,
per ITU I.366.1 [12].
1ITU I.366.1あたりの非保証されたトランスミッションがある「itu_i3661_は非保証した」SSCS[12]。
"itu_i3661_assured" SSCS with assured transmission,
per ITU I.366.1 [12]. This uses SSCOP [43].
1ITU I.366.1あたりの確実なトランスミッションがある「itu_i3661_は保証した」SSCS[12]。 これはSSCOP[43]を使用します。
"itu_i3662" SSCS per ITU I.366.2 [13].
ITU I.366.2[13]あたりの「itu_i3662」SSCS。
"itu_i3651" Frame relay SSCS per ITU I.365.1 [39].
「itu_i3651」FrameはITU I.365.1[39]あたりのSSCSをリレーします。
"itu_i3652" Service-specific coordination function,
as defined in ITU I.365.2, for Connection
Oriented Network Service (SSCF-CONS) [40].
This uses SSCOP [43].
ITU I.365.2で定義されるConnection Oriented Network Service(SSCF-コンズ)[40]のための「itu_i3652」Service特有のコーディネート機能。 これはSSCOP[43]を使用します。
"itu_i3653" Service-specific coordination function,
as defined in ITU I.365.3, for Connection
Oriented Transport Service (SSCF-COTS) [41].
This uses SSCOP [43].
ITU I.365.3で定義されるConnection Oriented Transport Service(SSCF-COTS)[41]のための「itu_i3653」Service特有のコーディネート機能。 これはSSCOP[43]を使用します。
"itu_i3654" HDLC Service-specific coordination function,
as defined in ITU I.365.4 [42].
ITU I.365.4[42]で定義されるような「itu_i3654」HDLC Service特有のコーディネート機能。
"FRF5" Use of the FRF.5 frame relay standard [53],
which references ITU I.365.1 [39].
「FRF.5フレームリレー規格[53]のFRF5" Use、どの参照ITU I.365.1[39]。」
"FRF8" Use of the FRF.8.1 frame relay standard [54].
This implies a null SSCS and the mapping of
the frame relay header into the ATM header.
「FRF.8.1フレームリレー規格[54]のFRF8" Use。」 これはヌルSSCSとフレームリレーヘッダーに関するマッピングをATMヘッダーに含意します。
"FRF11" Use of the FRF.11 frame relay standard [55].
「FRF.11フレームリレー規格[55]のFRF11" Use。」
"itu_h2221" Use of the ITU standard H.222.1 for
audiovisual communication over AAL5 [51].
AAL5[51]の上の視聴覚のコミュニケーションのためのITUの標準のH.222.1の「itu_h2221」Use。
The <oui>, or Organizationally Unique Identifier, refers to the organization responsible for defining the <appId>, or Application Identifier. The <oui> is maintained by the IEEE. One of its uses is in 802 MAC addresses. It is a three-octet field represented as one to six hex digits. Since this is always represented in hex, the "0x" prefix is not used. Leading zeros may be omitted.
<oui>、またはOrganizationally Unique Identifierが<appId>、またはApplication Identifierを定義するのに責任がある組織について言及します。 <oui>はIEEEによって維持されます。 用途の1つが802のMACアドレスにあります。 それは1〜6十六進法ケタとして表された3八重奏の分野です。 これが十六進法でいつも表されるので、"0x"接頭語は使用されていません。 先行ゼロは省略されるかもしれません。
Kumar & Mostafa Standards Track [Page 47] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[47ページ]。
The <appId> subparameter refers to the application ID, a hex number consisting of up to 8 digits. Leading zeros may be omitted. The "0x" prefix is not used, since the representation is always hexadecimal. Currently, the only organization that has defined application identifiers is the ATM forum. These have been defined in the context of AAL2 ([44], [52], Section 5 of [61]). Within SDP, these can be used with <appClass> = itu_i3662. The <oui> value for the ATM forum is 0x00A03E.
<appId>「副-パラメタ」はアプリケーションID、最大8ケタから成る十六進法番号を示します。 先行ゼロは省略されるかもしれません。 "0x"接頭語は、いつも表現が16進であるので、使用されていません。 現在、アプリケーション識別子を定義した唯一の組織がATMフォーラムです。 これらはAAL2([44]、[52]、[61])のセクション5の文脈で定義されました。 SDPの中では、<appClass>=itu_i3662と共にこれらを使用できます。 ATMフォーラムへの<oui>価値は0x00A03Eです。
In the following example, the aalApp media attribute line is used to indicate 'Loop Emulation Service using CAS (POTS only) without the Emulated Loop Control Protocol (ELCP) [52]. The Application ID is defined by the ATM forum [61]. The SSCS used is per ITU I.366.2 [13].
以下の例では、メディア属性が裏打ちするaalAppは、'Emulated Loop Controlプロトコル(ELCP)[52]なしでCAS(POTS専用)を使用する輪のEmulation Service'を示すのに使用されます。 Application IDはATMフォーラム[61]によって定義されます。 使用されるSSCSがITU I.366.2[13]単位であります。
a=aalApp:itu_i3662 A03E A
a=aalApp: itu_i3662 A03E A
If leading zeros are not dropped, this can be represented as:
先行ゼロが下げられないなら、以下としてこれを表すことができます。
a=aalApp:itu_i3662 00A03E 0000000A
a=aalApp: itu_i3662 00A03E 0000000A
Since application identifiers have been specified only in the context of the AAL2 SSCS defined in ITU I.366.2 [13],the <appClass> can be set to '-' without ambiguity. The aalApp media attribute line can be reduced to:
アプリケーション識別子がITU I.366.2[13]で定義されたAAL2 SSCSの文脈だけで指定されたので、<appClass>はあいまいさなしで'--'に用意ができることができます。 メディア属性が裏打ちするaalAppは以下のことのために減少できます。
a=aalApp:- A03E A
a=aalApp:、-、A03E A
or
または
a=aalApp:- 00A03E 0000000A
a=aalApp:、-、00A03E 0000000A
5.6.2.2 The 'cbrRate' attribute
5.6.2.2 'cbrRate'属性
When present, the 'cbrRate' attribute is used to represent the CBR rate octet defined in Table 4-6 of ITU Q.2931 [15]. The format of this media attribute line is:
存在しているとき、'cbrRate'属性は、ITU Q.2931[15]のTable4-6で定義されたCBRレート八重奏を表すのに使用されます。 このメディア属性系列の形式は以下の通りです。
a=cbrRate: <cbrRate>
a=cbrRate: <cbrRate>。
Here, <cbrRate> is represented as exactly two hex digits. The "0x" prefix is omitted since this parameter is always represented in hex. Values currently defined by the ITU are:
ここに、<cbrRate>はちょうど2十六進法ケタとして表されます。 このパラメタが十六進法でいつも表されるので、"0x"接頭語は省略されます。 現在ITUによって定義されている値は以下の通りです。
Kumar & Mostafa Standards Track [Page 48] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[48ページ]。
+------------+-----------------------------------------------+
| VALUE | MEANING |
| (hex) | |
+------------+-----------------------------------------------+
| 01 | 64 kbps |
+------------+-----------------------------------------------+
| 04 | 1544 kbps |
+------------+-----------------------------------------------+
| 05 | 6312 kbps |
+------------+-----------------------------------------------+
| 06 | 32064 kbps |
+------------+-----------------------------------------------+
| 07 | 44736 kbps |
+------------+-----------------------------------------------+
| 08 | 97728 kbps |
+------------+-----------------------------------------------+
| 10 | 2048 kbps |
+------------+-----------------------------------------------+
| 11 | 8448 kbps |
+------------+-----------------------------------------------+
| 12 | 34368 kbps |
+------------+-----------------------------------------------+
| 13 | 139264 kbps |
+------------+-----------------------------------------------+
| 40 | n x 64 kbps |
+------------+-----------------------------------------------+
| 41 | n x 8 kbps |
+------------+-----------------------------------------------+
+------------+-----------------------------------------------+ | 値| 意味| | (十六進法) | | +------------+-----------------------------------------------+ | 01 | 64キロビット毎秒| +------------+-----------------------------------------------+ | 04 | 1544年のキロビット毎秒| +------------+-----------------------------------------------+ | 05 | 6312年のキロビット毎秒| +------------+-----------------------------------------------+ | 06 | 32064キロビット毎秒| +------------+-----------------------------------------------+ | 07 | 44736キロビット毎秒| +------------+-----------------------------------------------+ | 08 | 97728キロビット毎秒| +------------+-----------------------------------------------+ | 10 | 2048年のキロビット毎秒| +------------+-----------------------------------------------+ | 11 | 8448年のキロビット毎秒| +------------+-----------------------------------------------+ | 12 | 34368キロビット毎秒| +------------+-----------------------------------------------+ | 13 | 139264キロビット毎秒| +------------+-----------------------------------------------+ | 40 | n x64キロビット毎秒| +------------+-----------------------------------------------+ | 41 | n x8キロビット毎秒| +------------+-----------------------------------------------+
It is preferable that the cbrRate attribute be omitted rather than set to an unspecified value of "-", since it conveys no information in the latter case.
cbrRate属性が「-」の不特定の値に設定するよりむしろ省略されるのは、望ましいです、後者のケースの中の情報を全く伝えないので。
5.6.2.3 The 'sbc' attribute
5.6.2.3 'sbc'属性
The 'sbc' media attribute line denotes the subchannel count and is meaningful only in the case of n x 64 clear channel communication. A clear n x 64 channel can use AAL1 (ATM forum af-vtoa-78) or AAL2 adaptation (ITU I.366.2). Although no such standard definition exists, it is also possible to use AAL5 for this purpose. An n x 64 clear channel is represented by the encoding names of "X-CCD" and "X-CCD-CAS" in Table 2.
メディアが結果と考える'sbc'系列は、サブチャネルカウントを指示して、n x64クリア・チャンネルコミュニケーションの場合だけで重要です。 明確なn x64チャンネルはAAL1(ATMフォーラムaf-vtoa-78)かAAL2適合(ITU I.366.2)を使用できます。 どんなそのような標準定義も存在していませんが、また、このためにAAL5を使用するのも可能です。 "X-CCD"と「X-CCD-CAS」というコード化名によってn x64クリア・チャンネルはテーブル2で代理をされます。
The format of the 'sbc' media attribute line is as follows:
メディアが結果と考える'sbc'系列の形式は以下の通りです:
a=sbc:<sbc>
a=sbc: <sbc>。
Kumar & Mostafa Standards Track [Page 49] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[49ページ]。
Here, <sbc> can be expressed as a decimal or hex integer. This attribute indicates the number of DS0s in a T1 or E1 frame that are aggregated for transmitting clear channel data. For T1-based applications, it can take on integral values in the inclusive range [1...24]. For E1-based applications, it can take on integral values in the inclusive range [1...31]. When omitted, other means are to be used to determine the subchannel count.
ここで、小数か十六進法整数として<sbc>を急送できます。 この属性はT1か1Eのフレームのクリア・チャンネルデータを送るために集められるDS0sの数を示します。 T1ベースのアプリケーションのために、それは包括的な範囲[1...24]で整数値を呈することができます。 E1ベースのアプリケーションのために、それは包括的な範囲[1...31]で整数値を呈することができます。 省略されると、他の手段はサブチャネルカウントを決定するのに使用されることです。
Use of the 'sbc' attribute provides a direct way to indicate the number of 64 kbps subchannels bundled into an n x 64 clear channel. An alternate mechanism to indicate this exists within the SDP bandwidth information, or 'b', line [1]. In this case, instead of specifying the number of subchannels, the aggregate bandwidth in kbps is specified. The syntax of the 'b' line, copied verbatim from [1], is as follows:
'sbc'属性の使用は64のキロビット毎秒サブチャネルの数が、xが64クリア・チャンネルであるとnに添付したのを示すダイレクト方法を提供します。 これを示す代替のメカニズムはSDP帯域幅情報、または'b'、系列[1]の中に存在しています。 この場合、サブチャネルの数を指定することの代わりに、キロビット毎秒における集合帯域幅は指定されます。 [1]から逐語的にコピーされた'b'系列の構文は以下の通りです:
b=<modifier>:<bandwidth-value>
<b=修飾語>: <帯域幅価値の>。
In the case of n x 64 clear channels, the <modifier> is assigned a text string value of "AS", indicating that the 'b' line is application-specific. The <bandwidth-value> parameter, which is a decimal number indicating the bandwidth in kbps, is limited to one of the following values in the n x 64 clear channel application context:
n x64人のクリア・チャンネルの場合では、“AS"のテキスト文字列値は<修飾語>に割り当てられます、'b'系列がアプリケーション特有であることを示して。 <はキロビット毎秒における帯域幅を示す10進数である>パラメタを帯域幅で評価して、n x64クリア・チャンネルアプリケーション文脈の以下の値の1つに制限されます:
64, 128, 192, 256, 320, 384, 448, 512, 576, 640, 704, 768, 832,
896, 960, 1024, 1088, 1152, 1216, 1280, 1344, 1408, 1472, 1600,
1664, 1728, 1792, 1856, 1920, 1984
64, 128, 192, 256, 320, 384, 448, 512, 576, 640, 704, 768, 832, 896, 960, 1024, 1088, 1152, 1216, 1280, 1344, 1408, 1472, 1600, 1664, 1728, 1792, 1856, 1920, 1984
Thus, for n x 64 circuit mode data service,
このようにして、n x64回路モードデータサービスのために
a=sbc:6
a=sbc: 6
is equivalent to
相当
b=AS:384
: 384としてのb=
The media attribute line
メディア属性は立ち並んでいます。
a=sbc:2
a=sbc: 2
is equivalent to
相当
b=AS:128
: 128としてのb=
Kumar & Mostafa Standards Track [Page 50] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[50ページ]。
5.6.2.4 The 'clkrec' attribute
5.6.2.4 'clkrec'属性
When present, the 'clkrec' attribute is used to indicate the clock recovery method. This attribute is meaningful in the case of AAL1 unstructured data transfer (UDT). The format of the 'clkrec' media attribute line is as follows:
存在しているとき、'clkrec'属性は、時計回復メソッドを示すのに使用されます。 この属性はAAL1の不統一なデータ転送(UDT)の場合で重要です。 メディアが結果と考える'clkrec'系列の形式は以下の通りです:
a=clkrec:<clkrec>
a=clkrec: <clkrec>。
The <clkrec> field can take on the following string values: "NULL", "SRTS" or "ADAPTIVE". SRTS and adaptive clock recovery are defined in ITU I.363.1 [10]. "NULL" indicates that the stream (e.g., T1/E1) encapsulated in ATM is synchronous to the ATM network or is retimed, before AAL1 encapsulation, via slip buffers.
<clkrec>分野は以下のストリング値を呈することができます: 「ヌル」、「SRTS」または「適応型です」。 SRTSと適応型の時計回復はITU I.363.1[10]で定義されます。 "NULL"は、ATMでカプセル化されたストリーム(例えば、1T1/E)がATMネットワークと同時であることを示すか、または再調節されます、AAL1カプセル化の前に、メモ用紙バッファで。
5.6.2.5 The 'fec' attribute
5.6.2.5 'fec'属性
When present, the 'fec' attribute is used to indicate the use of forward error correction. Currently, there exists a forward error correction method defined for AAL1 in ITU I.363.1 [10]. The format of the 'fec' media attribute line is as follows:
存在しているとき、'fec'属性は、前進型誤信号訂正の使用を示すのに使用されます。 現在、メソッドがAAL1のためにITU I.363.1[10]で定義した前進型誤信号訂正は存在します。 メディアが結果と考える'fec'系列の形式は以下の通りです:
a=fec:<fecEnable>
a=fec: <fecEnable>。
The <fecEnable> flag indicates the presence of absence of Forward Error Correction. It can take on the string values of "NULL", "LOSS_SENSITIVE" and "DELAY_SENSITIVE". An "NULL" value implies disabling this capability. FEC can be enabled differently for delay-sensitive and loss-sensitive connections.
<fecEnable>旗はForward Error Correctionの不在の存在を示します。 それは「損失_敏感で」「遅れ_敏感である」「ヌル」のストリング値を呈することができます。 この能力を無効にする値が含意する「ヌル。」 遅れ敏感で損失敏感な接続のためにFECを異なって有効にすることができます。
5.6.2.6 The 'prtfl' attribute
5.6.2.6 'prtfl'属性
When present, the 'prtfl' attribute is used to indicate the fill level of cells. When this attribute is absent, then other means (such as provisionable defaults) are used to determine the presence and level of partial fill.
存在しているとき、'prtfl'属性は、セルの中詰めレベルを示すのに使用されます。 この属性が欠けていると、他の手段(支給可能デフォルトなどの)は、部分的な中詰めの存在とレベルを決定するのに使用されます。
This attribute indicates the number of non-pad payload octets, not including any AAL SAR or convergence sublayer octets. For example, in some AAL1 applications that use partially filled cells with padding at the end, this attribute indicates the number of leading payload octets not including any AAL overhead.
この属性はどんなAAL SARや集合副層八重奏も含んでいるのではなく、非パッドペイロード八重奏の数を示します。 例えば、使用がセルを部分的に満たした終わりにそっと歩くいくつかのAAL1アプリケーションでは、この属性は少しのAALオーバーヘッドも含まない主なペイロード八重奏の数を示します。
The format of the 'prtfl' media attribute line is as follows:
メディアが結果と考える'prtfl'系列の形式は以下の通りです:
a=prtfl:<partialFill>
a=prtfl: <partialFill>。
Here, <partialFill> can be expressed as a decimal or a hex integer.
ここで、小数か十六進法整数として<partialFill>を急送できます。
Kumar & Mostafa Standards Track [Page 51] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[51ページ]。
In general, permitted values are integers in the range 1 - 48 inclusive. However, this upper bound is different for different adaptations since the AAL overhead, if any, is different. If the specified partial fill is greater than or equal to the maximum fill, then complete fill is used. Using a 'partial' fill of 48 always disables partial fill.
一般に、値が受入れられて、範囲1--48の整数は包括的ですか? しかしながら、もしあればAALオーバーヘッドが異なっているので、異なった適合において、この上限は異なっています。 指定された部分的な中詰めがそう以上なら、最大の中詰めであって、次に、完全な中詰めは使用されています。 48の'部分的な'中詰めを使用すると、部分的な中詰めはいつも無効にされます。
In the AAL1 context, this media attribute line applies uniformly to both P and non-P cells. In AAL1 applications that do not distinguish between P and non-P cells, a value of 47 indicates complete fill (i.e., the absence of partial fill). In AAL1 applications that distinguish between P and non-P cells, a value of 46 indicates no padding in P-cells and a padding of one in non-P cells.
AAL1文脈では、このメディア属性系列は一様にPと非Pセルの両方に適用されます。 Pを見分けないAAL1アプリケーションと非Pセルの中では、47の値は完全な中詰め(すなわち、部分的な中詰めの欠如)を示します。 Pを見分けるAAL1アプリケーションと非Pセルの中では、46の値はP-セルの中の水増しでなくて非Pセルにおける1の詰め物を示します。
If partial fill is enabled (i.e there is padding in at least some cells), then AAL1 structures must not be split across cell boundaries. These shall fit in any cell. Hence, their size shall be less than or equal to the partial fill size. Further, the partial fill size is preferably an integer multiple of the structure size. If not, then the partial fill size stated in the SDP description shall be truncated to an integer multiple (e.g., a partial fill size of 40 is truncated to 36 to support six 6 x 64 channels).
部分的な中詰めが可能にされるなら(そこのi.eは少なくともいくつかのセルの中でそっと歩いています)、セル境界の向こう側にAAL1構造を分けてはいけません。 これらはどんなセルもうまくはめ込むものとします。 したがって、それらのサイズは部分的な中詰めサイズによりなるでしょう。 さらに、望ましくは、部分的な中詰めサイズは構造サイズの整数倍数です。 そうでなければ、そして、SDP記述で述べられた部分的な中詰めサイズは整数倍数に先端を切られるものとします(例えば40の部分的な中詰めサイズは6x64が向ける6をサポートするために36に先端を切られます)。
5.6.2.7 The 'structure' attribute
5.6.2.7 '構造'属性
This attribute applies to AAL1 connections only. When present, the ' structure' attribute is used to indicate the presence or absence of structured data transfer (SDT), and the size in octets of the SDT blocks. The format of the 'structure' media attribute line is as follows:
この属性はAAL1接続だけに適用されます。 存在しているとき、'構造'属性は、構造化されたデータ転送(SDT)の存在か欠如、およびSDTブロックの八重奏におけるサイズを示すのに使用されます。 メディアが結果と考える'構造'系列の形式は以下の通りです:
a=structure: <structureEnable> <blksz>
=構造: <structureEnable><blksz>。
where the <structureEnable> flag indicates the presence of absence of SDT. It can take on the values of "on" or "off". An "on" value implies AAL1 structured data transfer (SDT), while an "off" value implies AAL1 unstructured data transfer (UDT).
<structureEnable>旗がSDTの不在の存在を示すところ。 それは“on"か“off"の値を呈することができます。 “on"値は、AAL1がデータ転送(SDT)を構造化したのを含意しますが、“off"値はAAL1の不統一なデータ転送(UDT)を含意します。
The block size field, <blksz>, is an optional 16-bit field [15] that can be represented in decimal or hex. It is set to a "-" when not applicable, as in the case of unstructured data transfer (UDT). For SDT, it can be set to a "-" when <blksz> is known by other means. For instance, af-vtoa-78 [7] fixes the structure size for n x 64 service, with or without CAS. The theoretical maximum value of <blksz> is 65,535, although most services use much less.
ブロック・サイズ分野(<blksz>)は小数か十六進法で表すことができる任意の16ビットの分野[15]です。 適切でないときに、それは不統一なデータ転送(UDT)に関するケースのように「-」に設定されます。 <blksz>が他の手段によって知られているとき、SDTにおいて、「-」にそれを設定できます。 例えば、af-vtoa-78[7]はCASのあるなしにかかわらずn x64サービスのための構造サイズを固定します。 ほとんどのサービスが多くの以下を使用しますが、<blksz>の理論上の最大値は6万5535です。
Kumar & Mostafa Standards Track [Page 52] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[52ページ]。
5.6.2.8 The 'cpsSDUsize' attribute
5.6.2.8 'cpsSDUsize'属性
When present, the 'cpsSDUsize' attribute is used to indicate the maximum size of the CPCS SDU payload. There can be several ' cpsSDUsize' lines in an SDP description.
存在しているとき、'cpsSDUsize'属性は、CPCS SDUペイロードの最大サイズを示すのに使用されます。 SDP記述にはいくつかの'cpsSDUsize'系列があることができます。
The format of this media attribute line is as follows:
このメディア属性系列の形式は以下の通りです:
a=cpsSDUsize:<directionFlag><cpcs>
a=cpsSDUsize: <directionFlag><cpcs>。
The <directionFlag> can be assigned the following string values: "f", "b" and "fb". "f" and "b" indicate the forward and backward directions respectively. "fb" refers to both directions (forward and backward). Conventions for the forward and backward directions are per section 2.3.
以下のストリング値を<directionFlag>に割り当てることができます: 「f」、「b」、および"fb"。 「f」と「b」はそれぞれフォワードと逆方向を示します。 "fb"は両方の方向(前方と後方である)を示します。 フォワードと逆方向のためのコンベンションがセクション2.3単位であります。
The <cpcs> fields is a 16-bit integer that can be represented in decimal or in hex. The meaning and values of these fields are as follows:
>がさばく<cpcsは小数か十六進法で表すことができる16ビットの整数です。 これらの分野の意味と値は以下の通りです:
Application Field Meaning Values
アプリケーション分野意味値
AAL5 <cpcs> Maximum CPCS-SDU size 1- 65,535
AAL5<cpcs>Maximum CPCS-SDUサイズ1- 65,535
AAL2 <cpcs> Maximum CPCS-SDU size 45 or 64
AAL2<cpcs>Maximum CPCS-SDUサイズ45か64
5.6.2.9 The 'aal2CPS' attribute
5.6.2.9 'aal2CPS'属性
When present, the 'aal2CPS' attribute is used to describe parameters associated with the AAL2 CPS layer.
存在しているとき、'aal2CPS'属性は、AAL2 CPS層に関連しているパラメタについて説明するのに使用されます。
The format of the 'aal2CPS' media attribute line is as follows: a=aal2CPS:<cidLowerLimit><cidUpperLimit><timerCU> <simplifiedCPS>
メディアが結果と考える'aal2CPS'系列の形式は以下の通りです: a=aal2CPS: <cidLowerLimit><cidUpperLimit><timerCU><simplifiedCPS>。
Each of these fields can be set to a "-" when the intention is to not specify them in an SDP descriptor.
意志がSDP記述子でそれらを指定しないことであるなら「-」にそれぞれのこれらの分野を設定できます。
The <cidLowerLimit> and <cidUpperLimit> can be assigned integer values between 8 and 255 [11], with the limitation that <cidUpperLimit> be greater than or equal to <cidLowerLimit>. For instance, for POTS applications based on [52], <cidLowerLimit> and <cidUpperLimit> can have values of 16 and 223 respectively.
<cidUpperLimit>がある制限がある8と255[11]の間の整数値を<cidLowerLimit>と<cidUpperLimit>により割り当てることができます。<cidLowerLimit>。 例えば、[52]に基づくPOTSアプリケーションのために、<cidLowerLimit>と<cidUpperLimit>はそれぞれ16と223の値を持つことができます。
The <timerCU> integer represents the "combined use" timerCU defined in ITU I.363.2. This timer is represented as an integer number of microseconds. It is represented as the decimal integer equivalent of 32 bits.
<timerCU>整数はtimerCUがITU I.363.2で定義した「結合した使用」を表します。 このタイマはマイクロセカンドの整数として表されます。 それは32ビットの10進整数同等物として表されます。
Kumar & Mostafa Standards Track [Page 53] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[53ページ]。
The <simplifiedCPS> parameter can be assigned the values "on" or "off". When it is "on", the AAL2 CPS simplification described in [52] is adopted. Under this simplification, each ATM cell contains exactly on AAL2 packet. If necessary, octets at the end of the cell are padded with zeros. Since the <timerCU> value in this context is always 0, it can be set to "-".
<simplifiedCPS>パラメタに値の“on"か“off"を割り当てることができます。 それが“on"であるときに、[52]で説明されたAAL2 CPS簡素化は採用されます。 この簡素化で、それぞれのATMセルはちょうどAAL2にパケットを含みます。 必要なら、セルの端の八重奏はゼロで水増しされます。 いつも<timerCU>価値がこのような関係においては0であるので、「-」にそれを設定できます。
5.6.2.10 The 'aal2CPSSDUrate' attribute
5.6.2.10 'aal2CPSSDUrate'属性
When present, the 'aal2CPSSDUrate' attribute is used to place an upper bound on the SDU bit rate for an AAL2 CID. This is useful for limiting the bandwidth used by a CID, specially if the CID is used for frame mode data defined in [13], or with the SSSAR defined in [12]. The format of this media attribute line is as follows:
存在しているとき、'aal2CPSSDUrate'属性は、AAL2 CIDのためにSDUビット伝送速度に上限を置くのに使用されます。 これはCIDが[13]で定義されたフレーム方式データ、または[12]で定義されるSSSARと共に使用されるなら特に、CIDによって使用された帯域幅を制限することの役に立ちます。 このメディア属性系列の形式は以下の通りです:
a=aal2CPSSDUrate: <fSDUrate><bSDUrate>
a=aal2CPSSDUrate: <fSDUrate><bSDUrate>。
The fSDUrate and bSDUrate are the maximum forward and backward SDU rates in bits/second. These are represented as decimal integers, with range as defined in Section 6. If any of these parameters in these media attribute lines is not specified, is inapplicable or is implied, then it is set to "-".
fSDUrateとbSDUrateはビット/秒の前方で最大の、そして、後方のSDUレートです。 これらは10進整数としてセクション6で定義される範囲で表されます。 属性が裏打ちするこれらのメディアによるこれらのパラメタのどれかが指定されないか、不適当であるか、または含意されるなら、それは「-」に設定されます。
5.6.2.11 The 'aal2sscs3661unassured' attribute
5.6.2.11 'aal2sscs3661unassured'属性
When present, the 'aal2sscs3661unassured' attribute is used to indicate the options that pertain to the unassured transmission SSCS defined in ITU I.366.1 [12]. This SSCS can be selected via the aalApp attribute defined below, or by virtue of the presence of the ' aal2sscs3661unassured' attribute. The format of this media attribute line is as follows:
存在しているとき、'aal2sscs3661unassured'属性は、ITU I.366.1[12]で定義された非保証されたトランスミッションSSCSに関係するオプションを示すのに使用されます。 以下で定義されたaalApp属性か'aal2sscs3661unassured'属性の存在によってこのSSCSを選択できます。 このメディア属性系列の形式は以下の通りです:
a=aal2sscs3661unassured: <ted> <rastimer> <fsssar> <bsssar>
a=aal2sscs3661unassured: <ted><rastimer><fsssar><bsssar>。
Each of these fields can be set to a "-" when the intention is to not specify them in an SDP descriptor.
意志がSDP記述子でそれらを指定しないことであるなら「-」にそれぞれのこれらの分野を設定できます。
The <ted> flag indicates the presence or absence of transmission error detection as defined in I.366.1. It can be assigned the values of "on" or "off". An "on" value indicates presence of the capability.
<ted>旗はI.366.1で定義されるように伝送エラー検出の存在か欠如を示します。 “on"か“off"の値をそれに割り当てることができます。 “on"値は能力の存在を示します。
The <rastimer> subparameter indicates the SSSAR reassembly timer in microseconds. It is represented as the decimal equivalent of 32 bits.
<rastimer>「副-パラメタ」はマイクロセカンドのときにSSSAR reassemblyタイマを示します。 それは32ビットの10進同等物として表されます。
Kumar & Mostafa Standards Track [Page 54] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[54ページ]。
The <fsssar> and <bsssar> fields are 24-bit integers that can be represented in decimal or in hex. The meaning and values of the <fsssar> and <bsssar> fields are as follows:
<fsssar>と<bsssar>分野は小数か十六進法で表すことができる24ビットの整数です。 <fsssar>と<bsssar>分野の意味と値は以下の通りです:
Field Meaning Values
分野意味値
<fsssar> Maximum SSSAR-SDU size 1- 65,568
forward direction
<fsssar>Maximum SSSAR-SDUサイズ1- 65,568順方向
<bsssar> Maximum SSSAR-SDU size 1- 65,568
backward direction
<bsssar>Maximum SSSAR-SDUサイズ1- 65,568逆方向
If present, the SSTED (Service-Specific Transmission Error Detection) sublayer is above the SSSAR (Service-Specific Segmentation and Reassembly) sublayer [12]. Since the maximum size of the SSTED-SDUs can be derived from the maximum SSSAR-SDU size, it need not be specified separately.
存在しているなら、SSTED(サービス特有のTransmission Error Detection)副層はSSSAR(サービス特有のSegmentationとReassembly)副層[12]を超えています。 最大のSSSAR-SDUサイズからSSTED-SDUsの最大サイズを得ることができるので、それは別々に指定される必要はありません。
5.6.2.12 The 'aal2sscs3661assured' attribute
5.6.2.12 'aal2sscs3661assured'属性
When present, the 'aal2sscs3661assured' attribute is used to indicate the options that pertain to the assured transmission SSCS defined in ITU I.366.1 [12] on the basis of ITU Q.2110 [43]. This SSCS can be selected via the aalApp attribute defined below, or by virtue of the presence of the 'aal2sscs3661assured' attribute. The format of this media attribute line is as follows:
存在しているとき、'aal2sscs3661assured'属性は、ITU Q.2110[43]に基づいてITU I.366.1[12]で定義された確実なトランスミッションSSCSに関係するオプションを示すのに使用されます。 以下で定義されたaalApp属性か'aal2sscs3661assured'属性の存在によってこのSSCSを選択できます。 このメディア属性系列の形式は以下の通りです:
a=aal2sscs3661assured: <rastimer> <fsssar> <bsssar> <fsscopsdu>
<bsscopsdu><fsscopuu> <bsscopuu>
a=aal2sscs3661assured: <rastimer><fsssar><bsssar><fsscopsdu><bsscopsdu><fsscopuu><bsscopuu>。
Each of these fields can be set to a "-" when the intention is to not specify them in an SDP descriptor.
意志がSDP記述子でそれらを指定しないことであるなら「-」にそれぞれのこれらの分野を設定できます。
The <rastimer> subparameter indicates the SSSAR reassembly timer in microseconds. It is represented as the decimal equivalent of 32 bits.
<rastimer>「副-パラメタ」はマイクロセカンドのときにSSSAR reassemblyタイマを示します。 それは32ビットの10進同等物として表されます。
The <fsssar> and <bsssar> fields are 24-bit integers that can be represented in decimal or in hex. The <fsscopsdu>, <bsscopsdu>, <fsscopuu> and <bsscopuu> fields are 16-bit integers that can be represented in decimal or in hex. The meaning and values of these fields is as follows:
<fsssar>と<bsssar>分野は小数か十六進法で表すことができる24ビットの整数です。 <fsscopsdu>、<bsscopsdu>、<fsscopuu>、および<bsscopuu>分野は小数か十六進法で表すことができる16ビットの整数です。 これらの分野の意味と値は以下の通りです:
Field Meaning Values
分野意味値
<fsssar> Maximum SSSAR-SDU size 1- 65,568
forward direction
<fsssar>Maximum SSSAR-SDUサイズ1- 65,568順方向
Kumar & Mostafa Standards Track [Page 55] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[55ページ]。
<bsssar> Maximum SSSAR-SDU size 1- 65,568
backward direction
<bsssar>Maximum SSSAR-SDUサイズ1- 65,568逆方向
<fsscopsdu> Maximum SSCOP-SDU size 1- 65,528
forward direction
<fsscopsdu>Maximum SSCOP-SDUサイズ1- 65,528順方向
<bsscopsdu> Maximum SSCOP-SDU size 1- 65,528
backward direction
<bsscopsdu>Maximum SSCOP-SDUサイズ1- 65,528逆方向
<fsscopuu> Maximum SSCOP-UU field 1- 65,524
size, forward direction
<fsscopuu>Maximum SSCOP-UU分野1- 65,524サイズ、順方向
<bsscopuu> Maximum SSCOP-UU field 1- 65,524
size, backward direction
<bsscopuu>Maximum SSCOP-UU分野1- 65,524サイズ、逆方向
The SSTED (Service-Specific Transmission Error Detection) sublayer is above the SSSAR (Service-Specific Segmentation and Reassembly) sublayer [12]. The SSADT (Service-Specific Assured Data Transfer) sublayer is above the SSTED sublayer. Since the maximum size of the SSTED-SDUs and SSADT-SDUs can be derived from the maximum SSSAR-SDU size, they need not be specified separately.
SSTED(サービス特有のTransmission Error Detection)副層はSSSAR(サービス特有のSegmentationとReassembly)副層[12]を超えています。 SSADT(サービス特有のAssured Data Transfer)副層はSSTED副層を超えています。 最大のSSSAR-SDUサイズからSSTED-SDUsとSSADT-SDUsの最大サイズを得ることができるので、彼らは別々に指定される必要はありません。
The SSCOP protocol defined in [43] is used by the Assured Data Transfer service defined in [12]. In the context of the ITU I.366.1 SSCS, it is possible to use the 'aal2sscs3661assured' attribute to limit the maximum sizes of the SSCOP SDUs and UU (user-to-user) fields in either direction. Note that it is necessary for the parameters on the 'aal2sscs3661assured' media attribute line to be consistent with each other.
[43]で定義されたSSCOPプロトコルは[12]で定義されたAssured Data Transferサービスで使用されます。 ITU I.366.1 SSCSの文脈では、SSCOP SDUsとUU(ユーザからユーザ)分野のどちらかの方向への最大サイズを制限するのに'aal2sscs3661assured'属性を使用するのは可能です。 メディアが結果と考える'aal2sscs3661assured'系列に関するパラメタが互いと一致しているのが必要であることに注意してください。
5.6.2.13 The 'aal2sscs3662' attribute
5.6.2.13 'aal2sscs3662'属性
When present, the 'aal2sscs3662' attribute is used to indicate the options that pertain to the SSCS defined in ITU I.366.2 [13]. This SSCS can be selected via the aalApp attribute defined below, or by the presence of the 'aal2sscs3662' attribute.
存在しているとき、'aal2sscs3662'属性は、ITU I.366.2[13]で定義されたSSCSに関係するオプションを示すのに使用されます。 以下で定義されたaalApp属性か'aal2sscs3662'属性の存在がこのSSCSを選択できます。
The format of this media attribute line is as follows:
このメディア属性系列の形式は以下の通りです:
a=aal2sscs3662: <sap> <circuitMode> <frameMode> <faxDemod>
<cas> <dtmf> <mfall> <mfr1> <mfr2>
<PCMencoding> <fmaxFrame> <bmaxFrame>
a=aal2sscs3662: <体液><circuitMode><frameMode><faxDemod><cas><dtmf><mfall><mfr1><mfr2><PCMencoding><fmaxFrame><bmaxFrame>。
Each of these fields can be set to a "-" when the intention is to not specify them in an SDP descriptor. Additionally, the values of these fields need to be consistent with each other. Inconsistencies should be flagged as errors.
意志がSDP記述子でそれらを指定しないことであるなら「-」にそれぞれのこれらの分野を設定できます。 さらに、これらの分野の値は、互いと一致している必要があります。 矛盾は誤りとして旗を揚げられるべきです。
Kumar & Mostafa Standards Track [Page 56] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[56ページ]。
The <sap> field can take on the following string values: "AUDIO" and "MULTIRATE". These correspond to the audio and multirate Service Access Points (SAPs) defined in ITU I.366.2.
<体液>分野は以下のストリング値を呈することができます: 「オーディオ」と「多速度。」 これらはService Access Points(SAPs)がITU I.366.2で定義したオーディオと多速度に対応しています。
For the multirate SAP, the following parameters on the aal2sscs3662 attribute line do not apply: <faxDemod>,<cas>, <dtmf>, <mfall>, <mfr1>, <mfr2> and <PCMencoding>. These are set to "-" for the multirate SAP.
多速度SAPのために、aal2sscs3662属性系列に関する以下のパラメタは申し込まれません: <faxDemod>、<cas>、<dtmf>、<mfall>、<mfr1>、<mfr2>、および<PCMencoding>。 これらは多速度体液のための「-」に設定されます。
The <circuitMode> flag indicates whether the transport of circuit mode data is enabled or disabled, corresponding to the string values of "on" and "off" respectively. For the multirate SAP, it cannot have a value of "off". For the audio SAP, it can be assigned a value of "on", "off" or "-". Note that the <sbc> attribute, defined elsewhere in this document, can be used to specify the number of 64 kbps subchannels bundled into a circuit mode data channel.
<circuitMode>旗は、回路モードデータの輸送が可能にされるか、または無効にされるかを示します、それぞれ“on"と“off"のストリング値に対応している。 多速度SAPのために、それは“off"の値を持つことができません。 オーディオのSAPに関しては、“on"、“off"または「-」の値をそれに割り当てることができます。 回路モードデータ・チャンネルに投げ込まれた64のキロビット毎秒サブチャネルの数を指定するのにほかの場所で本書では定義された<sbc>属性は使用できることに注意してください。
The <frameMode> flag indicates whether the transport of frame mode data is enabled or disabled, corresponding to the string values of "on" and "off" respectively.
<frameMode>旗は、フレーム方式データの輸送が可能にされるか、または無効にされるかを示します、それぞれ“on"と“off"のストリング値に対応している。
The <faxDemod> flag indicates whether facsimile demodulation and remodulation are enabled or disabled, corresponding to the string values of "on" and "off" respectively.
<faxDemod>旗は、ファクシミリ復調と再変調が有効にされるか、または無効にされるかを示します、それぞれ“on"と“off"のストリング値に対応している。
The <cas> flag indicates whether the transport of Channel Associated Signaling (CAS) bits in AAL2 type 3 packets is enabled or disabled, corresponding to the string values of "on" and "off" respectively.
<cas>旗は、AAL2タイプ3パケットのChannel Associated Signaling(CAS)ビットの輸送が可能にされるか、または無効にされるかを示します、それぞれ“on"と“off"のストリング値に対応している。
The <dtmf> flag indicates whether the transport of DTMF dialled digits in AAL2 type 3 packets is enabled or disabled, corresponding to the string values of "on" and "off" respectively.
<dtmf>旗は、DTMFの輸送がAAL2タイプ3パケットでケタにダイヤルしたかどうかが可能にされるか、または無効にされるのを示します、それぞれ“on"と“off"のストリング値に対応している。
The <mfall> flag indicates whether the transport of MF dialled digits in AAL2 type 3 packets is enabled or disabled, corresponding to the string values of "on" and "off" respectively. This flag enables MF dialled digits in a generic manner, without specifying type (e.g., R1, R2 etc.).
<mfall>旗は、MFの輸送がAAL2タイプ3パケットでケタにダイヤルしたかどうかが可能にされるか、または無効にされるのを示します、それぞれ“on"と“off"のストリング値に対応している。 ダイヤルされて、この旗はMFを有効にします。指定タイプのないジェネリック方法(例えば、R2R1など)によるケタ。
The <mfr1> flag indicates whether the transport, in AAL2 type 3 packets, of MF dialled digits for signaling system R1 is enabled or disabled, corresponding to the string values of "on" and "off" respectively.
<mfr1>旗は、AAL2タイプ3パケットのMFの輸送がシステムR1が有効にされるか、または無効にされるシグナリングのためにケタにダイヤルしたかどうかを示します、それぞれ“on"と“off"のストリング値に対応している。
The <mfr2> flag indicates whether the transport, in AAL2 type 3 packets, of MF dialled digits for signaling system R2 is enabled or disabled, corresponding to the string values of "on" and "off" respectively.
<mfr2>旗は、AAL2タイプ3パケットのMFの輸送がシステムR2が有効にされるか、または無効にされるシグナリングのためにケタにダイヤルしたかどうかを示します、それぞれ“on"と“off"のストリング値に対応している。
Kumar & Mostafa Standards Track [Page 57] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[57ページ]。
The <PCMencoding> field indicates whether PCM encoding, if used, is based on the A-law or the Mu-law. This can be used to qualify the ' generic PCM' codec stated in some of the AAL2 profiles. The <PCMencoding> field can take on the string values of "PCMA" and "PCMU".
<PCMencoding>分野は、使用されるならPCMコード化がA-法かMu-法に基づいているかどうかを示します。 いくつかのAAL2プロフィールに述べられた'ジェネリックPCM'コーデックに資格を与えるのにこれを使用できます。 <PCMencoding>分野は"PCMA"と"PCMU"のストリング値を呈することができます。
The <fmaxFrame> and <bmaxFrame> fields are 16-bit integers that can be represented in decimal or in hex. The meaning and values of the <fmaxFrame> and <bmaxFrame> fields are as follows:
<fmaxFrame>と<bmaxFrame>分野は小数か十六進法で表すことができる16ビットの整数です。 <fmaxFrame>と<bmaxFrame>分野の意味と値は以下の通りです:
Field Meaning Values
分野意味値
<fmaxFrame> Maximum length of a 1- 65,535
frame mode data unit,
forward direction
1- 65,535フレーム方式データ単位、順方向の<fmaxFrame>Maximumの長さ
<bmaxFrame> Maximum length of a 1- 65,535
frame mode data unit,
backward direction
1- 65,535フレーム方式データ単位、逆方向の<bmaxFrame>Maximumの長さ
5.6.2.14 The 'aal5sscop' attribute
5.6.2.14 'aal5sscop'属性
When present, the 'aal5sscop' attribute is used to indicate the existence of an SSCOP [43] protocol layer over an AAL5 CPS layer [21], and the parameters which pertain to this SSCOP layer. SSCOP over AAL5 can also be selected via the aalApp attribute defined below. The format of the 'aal5sscop' media attribute line is as follows:
存在しているとき、'aal5sscop'属性は、AAL5 CPS層[21]、およびこのSSCOP層に関係するパラメタの上にSSCOP[43]プロトコル層の存在を示すのに使用されます。 また、以下で定義されたaalApp属性でAAL5の上のSSCOPを選択できます。 メディアが結果と考える'aal5sscop'系列の形式は以下の通りです:
a=aal5sscop: <fsscopsdu> <bsscopsdu> <fsscopuu> <bsscopuu>
a=aal5sscop: <fsscopsdu><bsscopsdu><fsscopuu><bsscopuu>。
Each of these fields can be set to a "-" when the intention is to not specify them in an SDP descriptor.
意志がSDP記述子でそれらを指定しないことであるなら「-」にそれぞれのこれらの分野を設定できます。
The representation, meaning and values of the <fsscopsdu>, <bsscopsdu>, <fsscopuu> and <bsscopuu> fields are identical to those for the 'aal2sscs3661assured' media attribute line (Section 5.6.2.12). Note that it is necessary for the parameters on the ' aal5sscop' media attribute line to be consistent with each other.
メディアが結果と考える'aal2sscs3661assured'系列に、<fsscopsdu>、<bsscopsdu>、<fsscopuu>、および<bsscopuu>分野の表現、意味、および値がそれらと同じである、(セクション5.6 .2 .12)。 メディアが結果と考える'aal5sscop'系列に関するパラメタが互いと一致しているのが必要であることに注意してください。
5.6.3 Service attributes
5.6.3 サービス属性
The following is a summary list of the SDP media attributes that can be used to describe the services that use the ATM Adaptation Layer (AAL). These attributes are detailed in subsequent subsections.
↓これはATM Adaptation Layer(AAL)を使用するサービスについて説明するのに使用できるSDPメディア属性の概要リストです。 これらの属性はその後の小区分で詳細です。
* The 'atmmap' attribute. In the AAL1 and AAL5 contexts, this is
used to dynamically map payload types into codec strings.
* 'atmmap'属性。 AAL1とAAL5文脈では、これは、ダイナミックにペイロードタイプをコーデックストリングに写像するのに使用されます。
Kumar & Mostafa Standards Track [Page 58] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[58ページ]。
* The 'silenceSupp' attribute, used to indicate the use of of
voice activity detection for silence suppression, and to
optionally parameterize the silence suppression function.
* 沈黙抑圧、任意に沈黙抑圧機能をparameterizeするように声のアクティビティ検出について使用を示すのにおいて中古の'silenceSupp'属性。
* The 'ecan' attribute, used to indicate the use of of echo
cancellation, and to parameterize the this function.
* エコーキャンセルについて使用を示して、parameterizeするのにおいて中古の'ecan'属性、この機能。
* The 'gc' attribute, used to indicate the use of of gain
control, and to parameterize the this function.
* 利得制御について使用を示して、parameterizeするのにおいて中古の'gc'属性、この機能。
* The 'profileDesc' attribute, which can be used to describe AAL2
profiles. Although any AAL2 profile can be so described, this
attribute is useful for describing, at connection establishment
time, custom profiles that might not be known to the far end.
This attribute applies in the AAL2 context only.
* 'profileDesc'属性。(AAL2プロフィールについて説明するのにその属性を使用できます)。 そのようにどんなAAL2プロフィールについても説明できますが、この属性はコネクション確立時に遠端に知られていないかもしれないカスタムプロフィールについて説明することの役に立ちます。 この属性はAAL2文脈だけで適用されます。
* The 'vsel' attribute, which indicates a prioritized list of 3-
tuples for voice service. Each 3-tuple indicates a codec, an
optional packet length and an optional packetization period.
This complements the 'm' line information and should be
consistent with it.
* 'vsel'属性。(その属性は声のサービスのために3tuplesの最優先するリストを示します)。 各3-tupleはコーデック、任意のパケット長、および任意のpacketizationの期間を示します。 'これが補足となる、'系列情報であり、それと一致しているべきです。
* The 'dsel' attribute, which indicates a prioritized list of 3-
tuples for voiceband data service. Each 3-tuple indicates a
codec, an optional packet length and an optional packetization
period. This complements the 'm' line information and should
be consistent with it.
* 'dsel'属性。(その属性はvoicebandデータサービスのために3tuplesの最優先するリストを示します)。 各3-tupleはコーデック、任意のパケット長、および任意のpacketizationの期間を示します。 'これが補足となる、'系列情報であり、それと一致しているべきです。
* The 'fsel' attribute, which indicates a prioritized list of 3-
tuples for facsimile service. Each 3-tuple indicates a codec,
an optional packet length and an optional packetization period.
This complements the 'm' line information and should be
consistent with it.
* 'fsel'属性。(その属性はファクシミリサービスのために3tuplesの最優先するリストを示します)。 各3-tupleはコーデック、任意のパケット長、および任意のpacketizationの期間を示します。 'これが補足となる、'系列情報であり、それと一致しているべきです。
* The 'onewaySel' attribute, which indicates a prioritized list
of 3-tuples for one direction of an asymmetric connection.
Each 3-tuple indicates a codec, an optional packet length and
an optional packetization period. This complements the 'm'
line information and should be consistent with it.
* 'onewaySel'属性。(その属性は3-tuplesの最優先するリストを非対称の接続の一方向に示します)。 各3-tupleはコーデック、任意のパケット長、および任意のpacketizationの期間を示します。 'これが補足となる、'系列情報であり、それと一致しているべきです。
* The 'codecconfig' attribute, which is used to represent the
contents of the single codec information element (IE) defined
in ITU Q.765.5 [57].
* 'codecconfig'属性。(その属性は、ITU Q.765.5[57]で定義されたただ一つのコーデック情報要素(IE)のコンテンツを表すのに使用されます)。
* The 'isup_usi' attribute which is used to represent the bearer
capability information element defined in Section 4.5.5 of ITU
Q.931 [59], and reiterated as the user service information
element (IE) in Section 3.57 of ITU Q.763 [60].
* 運搬人能力情報要素を表すのに使用される'isup_usi'属性は、セクション4.5で.5ITU Q.931[59]を定義して、ユーザサービス情報要素としてITU Q.763[60]のセクション3.57で(IE)を繰り返しました。
Kumar & Mostafa Standards Track [Page 59] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[59ページ]。
* The 'uiLayer1_Prot' attribute, which is used to represent the '
User Information Layer 1 protocol' field within the bearer
capability information element defined in Section 4.5.5 of ITU
Q.931 [59].
* 'uiLayer1_Prot'属性。(その属性は、.5セクション4.5ITU Q.931[59]で定義された運搬人能力情報要素の中に'User情報Layer1プロトコル'分野を表すのに使用されます)。
5.6.3.1 The 'atmmap' attribute
5.6.3.1 'atmmap'属性
The 'atmmap' attribute is defined on the basis of the 'rtpmap' attribute used in RFC 2327.
'atmmap'属性はRFC2327で使用される'rtpmap'属性に基づいて定義されます。
a=atmmap:<payloadType> <encodingName>
a=atmmap: <payloadType><encodingName>。
The 'atmmap' attribute is used to dynamically map encoding names into payload types. This is necessary for those encoding names which have not been assigned a static payload type through IANA [31]. Payload types and encoding techniques that have been registered with IANA for RTP are retained for AAL1 and AAL5.
'atmmap'属性はペイロードタイプに名前をコード化するのにおいてダイナミックに写像するのにおいて使用されています。 これがIANA[31]を通して静的なペイロードタイプに割り当てられていない名前をコード化するものに必要です。 有効搭載量タイプとRTPのためにIANAに登録されたテクニックをコード化するのはAAL1とAAL5のために保有されます。
The range of statically defined payload types is in the range 0-95. All static assignments of payload types to codecs are listed in [31]. The range of payload types defined dynamically via the 'atmmap' attribute is 96-127.
静的に定義されたペイロードタイプの範囲が範囲0-95にあります。 コーデックへのペイロードタイプのすべての静的な課題が[31]に記載されています。 'atmmap'属性でダイナミックに定義されたペイロードタイプの範囲は96-127です。
In addition to reiterating the payload types and encoding names in [31], Table 2 defines non-standard encoding names (with "X-" prefixes). Note that [31], rather than Table 2, is the authoritative list of standard codec names and payload types in the ATM context.
ペイロードタイプを繰り返して、[31]で名前をコード化することに加えて、Table2は標準的でないコード化名(「X」接頭語がある)を定義します。 [31]がTable2よりむしろATM文脈の標準のコーデック名とペイロードタイプの正式のリストであることに注意してください。
Table 2: Encoding Names and Payload Types
テーブル2: 名前と有効搭載量をコード化するのはタイプされます。
|---------------------|--------------|---------------------------|
| Encoding Technique | Encoding Name| Payload type |
|---------------------|--------------|---------------------------|
| PCM - Mu law | "PCMU" | 0 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| 32 kbps ADPCM | "G726-32" | 2 (Statically Mapped) |
|---------------------|--------------|---------------------------|
|Dual rate 5.3/6.3kbps| "G723" | 4 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| PCM- A law | "PCMA" | 8 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| 7 KHz audio coding | "G722" | 9 (Statically Mapped) |
| within 64 kbps | | |
|---------------------|--------------|---------------------------|
| LD-CELP | "G728" | 15 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| CS-ACELP | "G729" | 18 (Statically Mapped) |
|(normal/low-complexity) | |
|---------------------|--------------|---------------------------| | テクニックをコード化します。| 名前をコード化します。| 有効搭載量タイプ| |---------------------|--------------|---------------------------| | PCM--μ法| "PCMU"| 0(静的に写像されます)| |---------------------|--------------|---------------------------| | 32キロビット毎秒ADPCM| 「G726-32インチ」| 2(静的に写像されます)| |---------------------|--------------|---------------------------| |二元的なレート5.3/6.3kbps| "G723"| 4(静的に写像されます)| |---------------------|--------------|---------------------------| | PCM法| "PCMA"| 8(静的に写像されます)| |---------------------|--------------|---------------------------| | 7kHzのオーディオ符号化| "G722"| 9(静的に写像されます)| | 64キロビット毎秒の中で| | | |---------------------|--------------|---------------------------| | LD-CELP| "G728"| 15(静的に写像されます)| |---------------------|--------------|---------------------------| | Cs-ACELP| "G729"| 18(静的に写像されます)| |(低標準/複雑さ) | |
Kumar & Mostafa Standards Track [Page 60] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[60ページ]。
|---------------------|--------------|---------------------------|
| Low-complexity | "X-G729a" | None, map dynamically |
| CS-ACELP | | |
|---------------------|--------------|---------------------------|
|Normal | "X-G729b" | None, map dynamically |
|CS-ACELP w/ ITU | | |
|defined silence | | |
|suppression | | |
+---------------------+--------------+---------------------------+
|Low-complexity | "X-G729ab" | None, map dynamically |
|CS-ACELP w/ ITU | | |
|defined silence | | |
|suppression | | |
|---------------------|--------------|---------------------------|
| 16 kbps ADPCM | "X-G726-16" | None, map dynamically |
|---------------------|--------------|---------------------------|
| 24 kbps ADPCM | "X-G726-24" | None, map dynamically |
|---------------------|--------------|---------------------------|
| 40 kbps ADPCM | "X-G726-40" | None, map dynamically |
|---------------------|--------------|---------------------------|
| Dual rate 5.3/6.3 |"X-G7231-H" | None, map dynamically |
| kbps - high rate | | |
|---------------------|--------------|---------------------------|
| Dual rate 5.3/6.3 |"X-G7231-L" | None, map dynamically |
| kbps - low rate | | |
|---------------------|--------------|---------------------------|
| Dual rate 5.3/6.3 |"X-G7231a-H" | None, map dynamically |
| kbps - high rate w/ | | |
| ITU-defined silence | | |
| suppression | | |
|----------------------------------------------------------------|
+---------------------+--------------+---------------------------+
| Dual rate 5.3/6.3 |"X-G7231a-L" | None, map dynamically |
| kbps - high rate w/ | | |
| ITU-defined silence | | |
| suppression | | |
|---------------------|--------------|---------------------------|
| 16 kbps EADPCM | "X-G727-16" | None, map dynamically |
|---------------------|--------------|---------------------------|
| 24 kbps EADPCM | "X-G727-24" | None, map dynamically |
|---------------------|--------------|---------------------------|
| 32 kbps EADPCM | "X-G727-32" | None, map dynamically |
|---------------------|--------------|---------------------------|
|n x 64 kbps Clear | "X-CCD" | None, map dynamically |
|Channel without CAS | | |
|per af-vtoa-78 [7] | | |
|---------------------|--------------|---------------------------|
|---------------------|--------------|---------------------------| | 低複雑さ| "X-G729a"| なにも、ダイナミックに写像| | Cs-ACELP| | | |---------------------|--------------|---------------------------| |標準| "X-G729b"| なにも、ダイナミックに写像| |ITUがあるCs-ACELP| | | |定義された沈黙| | | |抑圧| | | +---------------------+--------------+---------------------------+ |低複雑さ| "X-G729ab"| なにも、ダイナミックに写像| |ITUがあるCs-ACELP| | | |定義された沈黙| | | |抑圧| | | |---------------------|--------------|---------------------------| | 16キロビット毎秒ADPCM| 「X-G726-16インチ」| なにも、ダイナミックに写像| |---------------------|--------------|---------------------------| | 24キロビット毎秒ADPCM| 「X-G726-24インチ」| なにも、ダイナミックに写像| |---------------------|--------------|---------------------------| | 40キロビット毎秒ADPCM| 「X-G726-40インチ」| なにも、ダイナミックに写像| |---------------------|--------------|---------------------------| | 二元的なレート5.3/6.3|"X-G7231-H"| なにも、ダイナミックに写像| | キロビット毎秒--高い率| | | |---------------------|--------------|---------------------------| | 二元的なレート5.3/6.3|"X-G7231-L"| なにも、ダイナミックに写像| | キロビット毎秒--低率| | | |---------------------|--------------|---------------------------| | 二元的なレート5.3/6.3|"X-G7231a-H"| なにも、ダイナミックに写像| | キロビット毎秒--高い率| | | | ITUによって定義された沈黙| | | | 抑圧| | | |----------------------------------------------------------------| +---------------------+--------------+---------------------------+ | 二元的なレート5.3/6.3|"X-G7231a-L"| なにも、ダイナミックに写像| | キロビット毎秒--高い率| | | | ITUによって定義された沈黙| | | | 抑圧| | | |---------------------|--------------|---------------------------| | 16キロビット毎秒EADPCM| 「X-G727-16インチ」| なにも、ダイナミックに写像| |---------------------|--------------|---------------------------| | 24キロビット毎秒EADPCM| 「X-G727-24インチ」| なにも、ダイナミックに写像| |---------------------|--------------|---------------------------| | 32キロビット毎秒EADPCM| 「X-G727-32インチ」| なにも、ダイナミックに写像| |---------------------|--------------|---------------------------| |n x64キロビット毎秒Clear| "X-CCD"| なにも、ダイナミックに写像| |CASなしで精神を集中してください。| | | |af-vtoa-78[7]単位で| | | |---------------------|--------------|---------------------------|
Kumar & Mostafa Standards Track [Page 61] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[61ページ]。
|n x 64 kbps Clear | "X-CCD-CAS" | None, map dynamically |
|Channel with CAS | | |
|per af-vtoa-78 [7] | | |
|---------------------|--------------|---------------------------|
|GSM Full Rate | "GSM" | 3 (Statically Mapped) |
|---------------------|--------------|---------------------------|
|GSM Half Rate | "GSM-HR" | None, map dynamically |
|---------------------|--------------|---------------------------|
|GSM-Enhanced Full Rate "GSM-EFR" | None, map dynamically |
|---------------------|--------------|---------------------------|
|GSM-Enhanced Half Rate "GSM-EHR" | None, map dynamically |
|---------------------|--------------|---------------------------|
|Group 3 fax demod. | "X-FXDMOD-3" | None, map dynamically |
|---------------------|--------------|---------------------------|
| Federal Standard | "1016" | 1 (Statically Mapped) |
| FED-STD 1016 CELP | | |
|---------------------|--------------|---------------------------|
| DVI4, 8 KHz [3] | "DVI4" | 5 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| DVI4, 16 KHz [3] | "DVI4" | 6 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| LPC [3], Linear | "LPC" | 7 (Statically Mapped) |
| Predictive Coding | | |
|---------------------|--------------|---------------------------|
| L16 [3], Sixteen | "L16" | 10 (Statically Mapped) |
| Bit Linear PCM, | | |
| Double channel | | |
|---------------------|--------------|---------------------------|
| L16 [3], Sixteen | "L16" | 11 (Statically Mapped) |
| Bit Linear PCM, | | |
| Single channel | | |
|---------------------|--------------|---------------------------|
| QCELP [3] | "QCELP" | 12 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| MPEG1/MPEG2 audio | "MPA" | 14 (Statically Mapped) |
|---------------------|--------------|---------------------------|
+---------------------+--------------+---------------------------+
| DVI4, 11.025 KHz[3] | "DVI4" | 16 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| DVI4, 22.05 KHz [3] | "DVI4" | 17 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| MPEG1/MPEG2 video | "MPV" | 32 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| MPEG 2 audio/video | "MP2T" | 33 (Statically Mapped) |
| transport stream | | |
|---------------------|--------------|---------------------------|
| ITU H.261 video | "H261" | 31 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| n x64キロビット毎秒Clear| 「X-CCD-CAS」| なにも、ダイナミックに写像| |CASと共に精神を集中してください。| | | |af-vtoa-78[7]単位で| | | |---------------------|--------------|---------------------------| |GSM全額料金| "GSM"| 3(静的に写像されます)| |---------------------|--------------|---------------------------| |GSM半分レート| 「GSM-時間」| なにも、ダイナミックに写像| |---------------------|--------------|---------------------------| |GSM-エンハンストフルレート"GSM-EFR"| なにも、ダイナミックに写像| |---------------------|--------------|---------------------------| |GSMによって高められた半分レート"GSM-EHR"| なにも、ダイナミックに写像| |---------------------|--------------|---------------------------| |グループ3はdemodにファックスします。 | 「X-FXDMOD-3インチ」| なにも、ダイナミックに写像| |---------------------|--------------|---------------------------| | 連邦規格| "1016" | 1(静的に写像されます)| | 連邦政府-STD1016CELP| | | |---------------------|--------------|---------------------------| | DVI4、8KHz[3]| "DVI4""| 5(静的に写像されます)| |---------------------|--------------|---------------------------| | DVI4、16KHz[3]| "DVI4""| 6(静的に写像されます)| |---------------------|--------------|---------------------------| | LPC的[3]で、直線的です。| "LPC"| 7(静的に写像されます)| | 予言のコード化| | | |---------------------|--------------|---------------------------| | L16[3]、16| "L16""| 10(静的に写像されます)| | ビットの直線的なPCM| | | | 二重に、精神を集中してください。| | | |---------------------|--------------|---------------------------| | L16[3]、16| "L16""| 11(静的に写像されます)| | ビットの直線的なPCM| | | | 単独のチャンネル| | | |---------------------|--------------|---------------------------| | QCELP[3]| "QCELP"| 12(静的に写像されます)| |---------------------|--------------|---------------------------| | MPEG1/MPEG2オーディオ| "MPA"| 14(静的に写像されます)| |---------------------|--------------|---------------------------| +---------------------+--------------+---------------------------+ | DVI4、11.025KHz[3]| "DVI4""| 16(静的に写像されます)| |---------------------|--------------|---------------------------| | DVI4、22.05KHz[3]| "DVI4""| 17(静的に写像されます)| |---------------------|--------------|---------------------------| | MPEG1/MPEG2ビデオ| "MPV"| 32(静的に写像されます)| |---------------------|--------------|---------------------------| | MPEG2オーディオ/ビデオ| "MP2T"| 33(静的に写像されます)| | 輸送の流れ| | | |---------------------|--------------|---------------------------| | ITU H.261ビデオ| "H261"| 31(静的に写像されます)| |---------------------|--------------|---------------------------|
Kumar & Mostafa Standards Track [Page 62] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[62ページ]。
| ITU H.263 video | "H263" | 33 (Statically Mapped) |
|---------------------|--------------|---------------------------|
| ITU H.263 video |"H263-1998" | None, map dynamically |
| 1998 version | | |
|---------------------|--------------|---------------------------|
|MPEG 1 system stream | "MP1S" | None, map dynamically |
|---------------------|--------------|---------------------------|
|MPEG 2 program stream| "MP2P" | None, map dynamically |
|---------------------|--------------|---------------------------|
|Redundancy | "RED" | None, map dynamically |
|---------------------|--------------|---------------------------|
|Variable rate DVI4 | "VDVI" | None, map dynamically |
|---------------------|--------------|---------------------------|
|Cell-B | "CelB" | 25 |
|---------------------|--------------|---------------------------|
|JPEG | "JPEG" | 26 |
|---------------------|--------------|---------------------------|
|nv | "nv" | 28 |
|---------------------|--------------|---------------------------|
|L8, Eight Bit Linear | "L8" | None, map dynamically |
|PCM | | |
|---------------------|--------------|---------------------------|
| ITU-R Recommendation| "BT656" | None, map dynamically |
| BT.656-3 for | | |
| digital video | | |
|---------------------|--------------|---------------------------|
| Adaptive Multirate | "FR-AMR" | None, map dynamically |
|-Full Rate (3GPP)[58]| | |
|---------------------|--------------|---------------------------|
| Adaptive Multirate | "HR-AMR" | None, map dynamically |
|-Half Rate (3GPP)[58]| | |
|---------------------|--------------|---------------------------|
| Adaptive Multirate | "UMTS-AMR" | None, map dynamically |
|- UMTS(3GPP) [58] | | |
|---------------------|--------------|---------------------------|
| Adaptive Multirate | "AMR" | None, map dynamically |
|- Generic [58] | | |
|---------------------|--------------|---------------------------|
| ITU H.263ビデオ| "H263"| 33(静的に写像されます)| |---------------------|--------------|---------------------------| | ITU H.263ビデオ|"H263-1998"| なにも、ダイナミックに写像| | 1998年のバージョン| | | |---------------------|--------------|---------------------------| |MPEG1システムストリーム| 「MP1S」| なにも、ダイナミックに写像| |---------------------|--------------|---------------------------| |MPEG2プログラムストリーム| "MP2P"| なにも、ダイナミックに写像| |---------------------|--------------|---------------------------| |冗長| 「赤」| なにも、ダイナミックに写像| |---------------------|--------------|---------------------------| |変動金利DVI4| "VDVI"| なにも、ダイナミックに写像| |---------------------|--------------|---------------------------| |セルB| "CelB"| 25 | |---------------------|--------------|---------------------------| |JPEG| "JPEG"| 26 | |---------------------|--------------|---------------------------| |nv| "nv"| 28 | |---------------------|--------------|---------------------------| |L8、8は直線的に噛み付きました。| "L8""| なにも、ダイナミックに写像| |PCM| | | |---------------------|--------------|---------------------------| | ITU-R推薦| "BT656"| なにも、ダイナミックに写像| | BT.656-3| | | | デジタルビデオ| | | |---------------------|--------------|---------------------------| | 適応型の多速度| 「フラン-AMR」| なにも、ダイナミックに写像| |-全額料金(3GPP)[58]| | | |---------------------|--------------|---------------------------| | 適応型の多速度| 「時間-AMR」| なにも、ダイナミックに写像| |-半分レート(3GPP)[58]| | | |---------------------|--------------|---------------------------| | 適応型の多速度| "UMTS-AMR"| なにも、ダイナミックに写像| |- UMTS(3GPP)[58]| | | |---------------------|--------------|---------------------------| | 適応型の多速度| "AMR"| なにも、ダイナミックに写像| |- ジェネリック[58]| | | |---------------------|--------------|---------------------------|
5.6.3.2 The 'silenceSupp' attribute
5.6.3.2 'silenceSupp'属性
When present, the 'silenceSupp' attribute is used to indicate the use or non-use of silence suppression. The format of the 'silenceSupp' media attribute line is as follows:
存在しているとき、'silenceSupp'属性は、沈黙抑圧の使用か非使用を示すのに使用されます。 メディアが結果と考える'silenceSupp'線の形式は以下の通りです:
a=silenceSupp: <silenceSuppEnable> <silenceTimer> <suppPref> <sidUse>
<fxnslevel>
a=silenceSupp: <silenceSuppEnable><silenceTimer><suppPref><sidUse><fxnslevel>。
Kumar & Mostafa Standards Track [Page 63] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[63ページ]。
If any of the parameters in the silenceSupp media attribute line is not specified, is inapplicable or is implied, then it is set to "-".
メディア属性が裏打ちするsilenceSuppのパラメタのどれかが指定されないか、不適当であるか、または含意されるなら、それは「-」に設定されます。
The <silenceSuppEnable> can take on values of "on" or "off". If it is "on", then silence suppression is enabled.
<silenceSuppEnable>は“on"か“off"の値を呈することができます。 それが“on"であるなら、沈黙抑圧は可能にされます。
The <silenceTimer> is a 16-bit field which can be represented in decimal or hex. Each increment (tick) of this timer represents a millisecond. The maximum value of this timer is between 1 and 3 minutes. This timer represents the time-lag before silence suppression kicks in. Even though this can, theoretically, be as low as 1 ms, most DSP algorithms take more than that to detect silence. Setting <silenceTimer> to a large value (say 1 minute> is equivalent to disabling silence suppression within a call. However, idle channel suppression between calls on the basis of silence suppression is still operative in non-switched, trunking applications if <silenceSuppEnable> = "on" and <silenceTimer> is a large value.
<silenceTimer>は小数か十六進法で表すことができる16ビットの分野です。 このタイマの各増分(カチカチと音を立てる)は1人のミリセカンドを表します。 このタイマの最大値は1〜3分です。 沈黙抑圧が始まる前にこのタイマはタイムラグを表します。 これが理論的に1msと同じくらい低いことができますが、ほとんどのDSPアルゴリズムが、沈黙を検出するためにそれより取ります。 1分の>が呼び出しの中で沈黙抑圧を無効にするのに同等であると言ってください。<silenceTimer>を大きい値に設定する、(しかしながら、沈黙抑圧に基づいた呼び出しの間の無駄なチャンネル抑圧は<silenceSuppEnable>が“on"と等しく、<silenceTimer>が大きい値であるなら非切り換えられた中継方式アプリケーションでまだ作用しています。
The <suppPref> specifies the preferred silence suppression method that is preferred or already selected. It can take on the string values of "standard" and "custom". If its value is "standard", then a standard method (e.g., ITU-defined) is preferred to custom methods if such a standard is defined. Otherwise, a custom method may be used. If <suppPref> is set to "custom", then a custom method, if available, is preferred to the standard method.
<suppPref>は好まれるか、または既に選択される都合のよい沈黙抑圧方法を指定します。 それは「規格」と「習慣」のストリング値を呈することができます。 値が「標準である」なら、そのような規格が定義されるなら、標準方法(例えば、定義されたITU)はカスタム方法より好まれます。 さもなければ、カスタム方法は使用されるかもしれません。 <suppPref>が「習慣」に用意ができているなら、利用可能であるなら、カスタム方法は標準方法より好まれます。
The <sidUse> indicates whether SIDs (Silence Insertion Descriptors) are to be used, and whether they use fixed comfort noise or sampled background noise. It can take on the string values of "No SID", "Fixed Noise", "Sampled Noise".
<sidUse>は、SIDs(沈黙Insertion Descriptors)が使用されていることになっているかどうかと、彼らが固定安らぎ雑音か抽出されたバックグラウンドノイズを使用するかどうかを示します。 それは「雑音は修理されていた」「SIDがありません」「抽出された雑音」のストリング値を呈することができます。
If the value of <sidUse> is "Fixed Noise", then <fxnslevel> provides its level. It can take on integer values in the range 0-127, as follows:
<sidUse>の値に「雑音は修理されている」なら、<fxnslevel>がレベルを提供します。 それは0-127に、以下の通り範囲で整数値を呈することができます:
+-----------------------+---------------------+
| <fxnslevel> value | Meaning |
+-----------------------+---------------------+
| 0-29 | Reserved |
| 30 | -30 dBm0 |
| 31 | -31 dBm0 |
| . . . | . . . |
| 77 | -77 dBm0 |
| 78 | -78 dBm0 |
| 79-126 | reserved |
| 127 | Idle Code (no noise)|
+-----------------------+---------------------+
+-----------------------+---------------------+ | <fxnslevel>価値| 意味| +-----------------------+---------------------+ | 0-29 | 予約されます。| | 30 | -30 dBm0| | 31 | -31 dBm0| | . . . | . . . | | 77 | -77 dBm0| | 78 | -78 dBm0| | 79-126 | 予約されます。| | 127 | 使用されていないCode(雑音がありません)| +-----------------------+---------------------+
Kumar & Mostafa Standards Track [Page 64] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[64ページ]。
In addition to the decimal representation of <fxnslevel>, a hex representation, preceded by a "0x" prefix, is also allowed.
また、<fxnslevel>の10進表現に加えて、"0x"接頭語が先行した十六進法表現は許容されています。
5.6.3.3 The 'ecan' attribute
5.6.3.3 'ecan'属性
When present, the 'ecan' attribute s is used to indicate the use or non-use of echo cancellation. There can be several 'ecan' lines in an SDP description.
存在しているとき、'ecan'属性sは、エコーキャンセルの使用か非使用を示すのに使用されます。 SDP記述にはいくつかの'ecan'線があることができます。
The format of the 'ecan' media attribute line is as follows:
メディアが結果と考える'ecan'線の形式は以下の通りです:
a=ecan:<directionFlag><ecanEnable><ecanType>
a=ecan: <directionFlag><ecanEnable><ecanType>。
The <directionFlag> can be assigned the following string values: "f", "b" and "fb". "f" and "b" indicate the forward and backward directions respectively. "fb" refers to both directions (forward and backward). Conventions for the forward and backward directions are per section 2.3.
以下のストリング値を<directionFlag>に割り当てることができます: 「f」、「b」、および"fb"。 「f」と「b」はそれぞれフォワードと逆方向を示します。 "fb"は両方の指示(前方と後方である)を示します。 フォワードと逆方向のためのコンベンションがセクション2.3単位であります。
The <directionFlag> is always specified. Except for the <directionFlag>, the remaining parameters can be set to "-" to indicate that they are not specified, inapplicable or implied. However, there must be some specified parameters for the line to be useful in an SDP description.
<directionFlag>はいつも指定されます。 <directionFlag>を除いて、「-」に残っているパラメタが、それらが指定されない、不適当であるか、または暗示しているのを示すように設定できます。 しかしながら、線がSDP記述で役に立ついくつかの指定されたパラメタがあるに違いありません。
If the 'ecan' media attribute lines is not present, then means other than the SDP descriptor must be used to determine the applicability and nature of echo cancellation for a connection direction. Examples of such means are MIB provisioning, the local connection options structure in MGCP etc.
メディアが結果と考える'ecan'線が存在していないなら、接続指示のためのエコーキャンセルの適用性と本質を決定するのにSDP記述子以外の手段を使用しなければなりません。 そのような手段に関する例はMIBの食糧を供給するMGCPなどで市内接続オプション構造です。
The <ecanEnable> parameter can take on values of "on" or "off". If it is "on", then echo cancellation is enabled. If it is "off", then echo cancellation is disabled.
<ecanEnable>パラメタは“on"か“off"の値を呈することができます。 それが“on"であるなら、エコーキャンセルは可能にされます。 それが“off"であるなら、エコーキャンセルは障害があります。
The <ecanType> parameter can take on the string values "G165" and "G168" respectively.
<ecanType>パラメタはそれぞれストリング値"G165"と"G168"を呈することができます。
When SDP is used with some media gateway control protocols such as MGCP and Megaco [26], there exist means outside SDP descriptions to specify the echo cancellation properties of a connection. Nevertheless, this media attribute line is included for completeness. As a result, the SDP can be used for describing echo cancellation in applications where alternate means for this are unavailable.
SDPがMGCPやMegaco[26]などのいくつかのメディアゲートウェイ制御プロトコルと共に使用されるとき、接続のエコーキャンセルの特性を指定するSDP記述の外における手段は存在しています。 それにもかかわらず、このメディア属性線は完全性のために含まれています。 その結果、これのための交互の手段が入手できないアプリケーションにおけるエコーキャンセルについて説明するのにSDPを使用できます。
Kumar & Mostafa Standards Track [Page 65] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[65ページ]。
5.6.3.4 The 'gc' attributes
5.6.3.4 'gc'属性
When present, the 'gc' attribute is used to indicate the use or non- use of gain control. There can be several 'gc' lines in an SDP description.
存在しているとき、'gc'属性は、利得制御の使用か非使用を示すのに使用されます。 SDP記述にはいくつかの'gc'線があることができます。
The format of the 'gc' media attribute line is as follows:
メディアが結果と考える'gc'線の形式は以下の通りです:
a=gc:<directionFlag><gcEnable><gcLvl>
a=gc: <directionFlag><gcEnable><gcLvl>。
The <directionFlag> can be assigned the following string values: "f", "b" and "fb". "f" and "b" indicate the forward and backward directions respectively. "fb" refers to both directions (forward and backward). Conventions for the forward and backward directions are per section 2.3.
以下のストリング値を<directionFlag>に割り当てることができます: 「f」、「b」、および"fb"。 「f」と「b」はそれぞれフォワードと逆方向を示します。 "fb"は両方の指示(前方と後方である)を示します。 フォワードと逆方向のためのコンベンションがセクション2.3単位であります。
The <directionFlag> is always specified. Except for the <directionFlag>, the remaining parameters can be set to "-" to indicate that they are not specified, inapplicable or implied. However, there must be some specified parameters for the line to be useful in an SDP description.
<directionFlag>はいつも指定されます。 <directionFlag>を除いて、「-」に残っているパラメタが、それらが指定されない、不適当であるか、または暗示しているのを示すように設定できます。 しかしながら、線がSDP記述で役に立ついくつかの指定されたパラメタがあるに違いありません。
If the 'gc' media attribute lines is not present, then means other than the SDP descriptor must be used to determine the applicability and nature of gain control for a connection direction. Examples of such means are MIB provisioning, the local connection options structure in MGCP etc.
メディアが結果と考える'gc'線が存在していないなら、接続指示のために利得制御の適用性と本質を決定するのにSDP記述子以外の手段を使用しなければなりません。 そのような手段に関する例はMIBの食糧を供給するMGCPなどで市内接続オプション構造です。
The <gcEnable> parameter can take on values of "on" or "off". If it is "on", then gain control is enabled. If it is "off", then gain control is disabled.
<gcEnable>パラメタは“on"か“off"の値を呈することができます。 それが“on"であるなら、利得制御は可能にされます。 それが“off"であるなら、利得制御は障害があります。
The <gcLvl> parameter is represented as the decimal or hex equivalent of a 16-bit binary field. A value of 0xFFFF implies automatic gain control. Otherwise, this number indicates the number of decibels of inserted loss. The upper bound, 65,535 dB (0xFFFE) of inserted loss, is a large number and is a carryover from Megaco [26]. In practical applications, the inserted loss is much lower.
<gcLvl>パラメタは16ビットの2進の分野の小数か十六進法同等物として表されます。 0xFFFFの値は自動利得制御を含意します。 さもなければ、この数はデシベルの挿入された損失の数を示します。 上限(6万5535dB(0xFFFE)の挿入された損失)は、多くであり、Megaco[26]からの繰越しです。 実用化では、挿入された損失ははるかに低いです。
When SDP is used with some media gateway control protocols such as MGCP and Megaco [26], there exist means outside SDP descriptions to specify the gain control properties of a connection. Nevertheless, this media attribute line is included for completeness. As a result, the SDP can be used for describing gain control in applications where alternate means for this are unavailable.
SDPがMGCPやMegaco[26]などのいくつかのメディアゲートウェイ制御プロトコルと共に使用されるとき、接続の利得制御の特性を指定するSDP記述の外における手段は存在しています。 それにもかかわらず、このメディア属性線は完全性のために含まれています。 その結果、これのための交互の手段が入手できないアプリケーションにおける利得制御について説明するのにSDPを使用できます。
Kumar & Mostafa Standards Track [Page 66] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[66ページ]。
5.6.3.5 The 'profileDesc' attribute
5.6.3.5 'profileDesc'属性
There is one 'profileDesc' media attribute line for each AAL2 profile that is intended to be described. The 'profileDesc' media attribute line is structured as follows:
'profileDesc'メディア属性が説明されることを意図するそれぞれのAAL2プロフィールのために裏打ちする1つがあります。 メディアが結果と考える'profileDesc'線は以下の通り構造化されます:
a=profileDesc: <aal2transport> <profile> <uuiCodeRange#1>
<encodingName#1> <packetLength#1> <packetTime#1>
<uuiCodeRange#2> <encodingName#2> <packetLength#2>
<packetTime#2>... <uuiCodeRange#N> <encodingName#N>
<packetLength#N> <packetTime#N>
a=profileDesc: <aal2transport><プロフィール><uuiCodeRange#1><encodingName#1><packetLength#1><packetTime#1><uuiCodeRange#2><encodingName#2><packetLength#2><packetTime#2>… <uuiCodeRange#N><encodingName#N><packetLength#N><packetTime#N>。
Here, <aal2transport> can have those values of <transport> (Table 1) that pertain to AAL2. These are:
ここに、<aal2transport>はAAL2に関係する<輸送>(テーブル1)のそれらの値を持つことができます。 これらは以下の通りです。
AAL2/ATMF
AAL2/ITU
AAL2/custom
AAL2/<corporateName>
AAL2/IEEE:<oui>
AAL2/ATMF AAL2/ITU AAL2/習慣AAL2/<corporateName>AAL2/IEEE: <oui>。
The parameter <profile> is identical to its definition for the 'm' line (Section 5.5.4).
'パラメタ<プロフィール>が定義と同じである、'(セクション5.5.4)を裏打ちしてください。
The profile elements (rows in the profile tables of ITU I.366.2 or AF-VTOA-0113) are represented as four-tuples following the <profile> parameter in the 'profileDesc' media attribute line. If a member of one of these four-tuples is not specified or is implied, then it is set to "-".
'profileDesc'メディア属性における<プロフィール>パラメタに従う4tuplesが立ち並ぶとき、プロフィール要素(ITU I.366.2かAF-VTOA-0113のプロフィールテーブルの列)は表されます。 これらの4tuplesの1つのメンバーが指定されないか、または含意されるなら、それは「-」に設定されます。
The <uuiCodeRange> parameter is represented by D1-D2, where D1 and D2 are decimal integers in the range 0 through 15.
<uuiCodeRange>パラメタはD1-D2によって表されます。そこでは、D1とD2が0〜15に範囲の10進整数です。
The <encodingName> parameter can take one of the values in column 2 of Table 2. Additionally, it can take on the following descriptor strings: "PCMG", "SIDG" and "SID729". These stand for generic PCM, generic SID and G.729 SID respectively.
<encodingName>パラメタはTable2に関するコラム2の値の1つを取ることができます。 さらに、以下の記述子ストリングを帯びることができます: "PCMG"、"SIDG"、および"SID729"。 これらはそれぞれ一般的なPCM、一般的なSID、およびG.729 SIDを表します。
The <packetLength> is a decimal integer representation of the AAL2 packet length in octets.
<packetLength>は八重奏で、AAL2パケット長の10進整数表現です。
The <packetTime> is a decimal integer representation of the AAL2 packetization interval in microseconds.
<packetTime>はマイクロセカンドのAAL2 packetization間隔の10進整数表現です。
For instance, the 'profileDesc' media attribute line below defines the AAL2/custom 100 profile. This profile is reproduced in the Table 3 below. For a description of the parameters in this profile such as M and the sequence number interval, see ITU I.366.2 [13].
例えば、以下のメディアが結果と考える'profileDesc'線はAAL2/習慣100プロフィールを定義します。 このプロフィールは以下のTable3で複製されます。 Mや一連番号間隔などのこのプロフィールのパラメタの記述に関しては、ITU I.366.2[13]を見てください。
Kumar & Mostafa Standards Track [Page 67] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[67ページ]。
a=profileDesc:AAL2/custom 100 0-7 PCMG 40 5000 0-7 SIDG 1 5000 8-15
G726-32 40 10000 8-15 SIDG 1 5000
a=profileDesc: AAL2/習慣100 0-7PCMG40 5000 0-7SIDG1 5000 8-15G726-32 40 10000 8-15SIDG1 5000
If the <packetTime> parameter is to be omitted or implied, then the same profile can be represented as follows:
<packetTime>パラメタが省略されるか、または含意されることであるなら、以下の通り同じプロフィールを表すことができます:
a=profileDesc:AAL2/custom 100 0-7 PCMG 40 - 0-7 SIDG 1 - 8-15
G726-32 40 - 8-15 SIDG 1 -
a=profileDesc: AAL2/習慣100 0-7PCMG40--0-7 SIDG1--8-15 G726-32 40--8-15 SIDG1、-
If a gateway has a provisioned or hard coded definition of a profile, then any definition provided via the 'profileDesc' line overrides it. The exception to this rule is with regard to standard profiles such as ITU-defined profiles and ATMF-defined profiles. In general, these should not be defined via a 'profileDesc' media attribute line. If they are, then the definition needs to be consistent with the standard definition else the SDP session descriptor should be rejected with an appropriate error code.
ゲートウェイにプロフィールの食糧を供給されたか困難なコード化された定義があるなら、'profileDesc'線を通して提供されたどんな定義もそれをくつがえします。 ITUによって定義されたプロフィールやATMFによって定義されたプロフィールなどの標準のプロフィールに関してこの規則への例外があります。 一般に、'profileDesc'メディア属性線を通してこれらを定義するべきではありません。 彼らがいるなら、定義は、ほかに標準定義と一致している必要があります。SDPセッション記述子は適切なエラーコードで拒絶されるべきです。
Table 3: Example of a custom AAL2 profile
テーブル3: カスタムAAL2プロフィールに関する例
|---------------------------------------------------------------| | UUI | Packet |Encoding | | |Packet|Seq.No. | | Code | Length |per ITU |Description of | M |Time |Interval| |point |(octets)|I.366.2 | Algorithm | |(ms) |(ms) | |Range | | 2/99 | | | | | | | | version | | | | | |---------------------------------------------------------------| | 0-7 | 40 | Figure | PCM, G.711-64,| 1 | 5 | 5 | | | | B-1 | generic | | | | |------|--------|---------|---------------|-----|------|--------| | 0-7 | 1 | Figure | Generic SID | 1 | 5 | 5 | | | | I-1 | | | | | |------|--------|---------|---------------|-----|------|--------| | 8-15 | 40 | Figure | ADPCM, | 2 | 10 | 5 | | | | E-2 | G.726-32 | | | | |------|--------|---------|---------------|-----|------|--------| | 8-15 | 1 | Figure | Generic SID | 1 | 5 | 5 | | | | I-1 | | | | | |------|--------|---------|---------------|-----|------|--------|
|---------------------------------------------------------------| | UUI| パケット|コード化| | |パケット|Seqいいえ | | コード| 長さ|ITU単位で|記述| M|時間|間隔| |ポイント|(八重奏)|I.366.2| アルゴリズム| |(ms) |(ms) | |範囲| | 2/99 | | | | | | | | バージョン| | | | | |---------------------------------------------------------------| | 0-7 | 40 | 図| PCM、G.711-64| 1 | 5 | 5 | | | | B-1| ジェネリック| | | | |------|--------|---------|---------------|-----|------|--------| | 0-7 | 1 | 図| 一般的なSID| 1 | 5 | 5 | | | | I-1| | | | | |------|--------|---------|---------------|-----|------|--------| | 8-15 | 40 | 図| ADPCM| 2 | 10 | 5 | | | | E-2| G.726-32| | | | |------|--------|---------|---------------|-----|------|--------| | 8-15 | 1 | 図| 一般的なSID| 1 | 5 | 5 | | | | I-1| | | | | |------|--------|---------|---------------|-----|------|--------|
5.6.3.6 The 'vsel' attribute
5.6.3.6 'vsel'属性
The 'vsel' attribute indicates a prioritized list of one or more 3- tuples for voice service. Each 3-tuple indicates a codec, an optional packet length and an optional packetization period. This complements the 'm' line information and should be consistent with it.
'vsel'属性は声のための3tuplesが修理する1つ以上の最優先するリストを示します。 各3-tupleはコーデック、任意のパケット長、および任意のpacketizationの期間を示します。 'これが補足となる、'線情報であり、それと一致しているべきです。
Kumar & Mostafa Standards Track [Page 68] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[68ページ]。
The 'vsel' attribute refers to all directions of a connection. For a bidirectional connection, these are the forward and backward directions. For a unidirectional connection, this can be either the backward or forward direction.
'vsel'属性は接続のあらゆる方向について言及します。 双方向の接続において、これらは、フォワードと逆方向です。 単方向の接続において、これは後方の、または、前進の指示であるかもしれません。
The 'vsel' attribute is not meant to be used with bidirectional connections that have asymmetric codec configurations described in a single SDP descriptor. For these, the 'onewaySel' attribute (section 5.6.3.9) should be used. See section 5.6.3.9 for the requirement to not use the 'vsel' and 'onewaySel' attributes in the same SDP descriptor.
'vsel'属性はただ一つのSDP記述子で説明された非対称のコーデック構成を持っている双方向の接続と共に使用されることになっていません。 これら、'onewaySel'属性、(セクション5.6 .3 .9は)使用されるべきです。 セクション5.6を見てください。.3 .9 同じSDP記述子で'vsel'と'onewaySel'属性を使用しないという要件のために。
The 'vsel' line is structured as follows:
'vsel'線は以下の通り構造化されます:
a=vsel:<encodingName #1> <packetLength #1><packetTime #1>
<encodingName #2> <packetLength #2><packetTime #2>
...
<encodingName #N> <packetLength #N><packetTime #N>
a=vsel: <encodingName#1><packetLength#1><packetTime#1><encodingName#2><packetLength#2><packetTime#2>… <encodingName#N><packetLength#N><packetTime#N>。
where the <encodingName> parameter can take one of the values in column 2 of Table 2. The <packetLength> is a decimal integer representation of the packet length in octets. The <packetTime> is a decimal integer representation of the packetization interval in microseconds. The parameters <packetLength> and <packetTime> can be set to "-" when not needed. Also, the entire 'vsel' media attribute line can be omitted when not needed.
<encodingName>パラメタがTable2に関するコラム2の値の1つを取ることができるところ。 <packetLength>は八重奏で、パケット長の10進整数表現です。 <packetTime>はマイクロセカンドのpacketization間隔の10進整数表現です。 必要でないと、パラメタの<packetLength>と<packetTime>は「-」に用意ができることができます。 また、必要でないと、メディアが結果と考える全体の'vsel'線を省略できます。
For example,
例えば
a=vsel:G729 10 10000 G726-32 40 10000
a=vsel: G729 10 10000G726-32 40 10000
indicates first preference of G.729 or G.729a (both are interoperable) as the voice encoding scheme. A packet length of 10 octets and a packetization interval of 10 ms are associated with this codec. G726-32 is the second preference stated in this line, with an associated packet length of 40 octets and a packetization interval of 10 ms. If the packet length and packetization interval are intended to be omitted, then this media attribute line becomes
計画をコード化する声としてG.729かG.729a(ともに共同利用できる)の最優先を示します。 10の八重奏のパケット長と10msのpacketization間隔はこのコーデックに関連しています。G726-32がこの線で述べられた2番目の好みである、40の八重奏の関連パケット長と10原稿Ifのpacketization間隔で、パケット長とpacketization間隔は省略されるつもりであり、次に、このメディア属性線はなります。
a=vsel:G729 - - G726-32 - -
a=vsel: G729--、--G726-32--、-
The media attribute line
メディア属性は立ち並んでいます。
a=vsel:G726-32 40 10000
a=vsel: G726-32 40 10000
indicates preference for or selection of 32 kbps ADPCM with a packet length of 40 octets and a packetization interval of 10 ms.
40の八重奏のパケット長と10原稿のpacketization間隔がある32キロビット毎秒ADPCMの好みか選択を示します。
Kumar & Mostafa Standards Track [Page 69] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[69ページ]。
This media attribute line can be used in ATM as well as non-ATM contexts. Within the ATM context, it can be applied to the AAL1, AAL2 and AAL5 adaptations. The <packetLength> and <packetTime> are not meaningful in the AAL1 case and should be set to "-". In the AAL2 case, this line determines the use of some or all of the rows in a given profile table. If multiple 3-tuples are present, they can indicate a hierarchical assignment of some rows in that profile to voice service (e.g., row A preferred to row B etc.). If multiple profiles are present on the 'm' line, the profile qualified by this attribute is the first profile. If a single profile that has been selected for a connection is indicated in the 'm' line, the 'vsel' attribute qualifies the use, for voice service, of codecs within that profile.
非ATM文脈と同様にATMでこのメディア属性線を使用できます。 ATM文脈の中では、AAL1、AAL2、およびAAL5適合にそれを適用できます。 <packetLength>と<packetTime>はAAL1場合で重要でなく、「-」に用意ができるべきです。 AAL2場合では、この線は与えられたプロフィールテーブルにおける列のいくつかかすべての使用を決定します。 複数の3-tuplesが存在しているなら、彼らはそのプロフィールのいくつかの列の階層的な課題を声のサービスに示すことができます(例えば、列Aは、Bなどをこぐのを好みました)。 '線、プロフィールは資格があります。プレゼントが'複数のプロフィールであるならオンである、この属性は最初のプロフィールです。 '接続のために選択された単一のプロフィールが中に示される、'線、属性がコーデックの声のサービスの使用に資格を与えるそれが輪郭を描く'vsel'はそうです。
With most of the encoding names in Figure 2, the packet length and packetization period can be derived from each other. One of them can be set to "-" without a loss of information. There are some exceptions such as the IANA-registered encoding names G723, DVI4 and L16 for which this is not true. Therefore, there is a need to retain both the packet length and packetization period in the definition of the 'vsel' line.
コード化の大部分で、互いから図2の名前、パケット長、およびpacketizationの期間を得ることができます。 情報の損失なしで「-」にそれらの1つを設定できます。 これが本当でないIANAによって登録されたコード化名のG723や、DVI4やL16などのいくつかの例外があります。 したがって、'vsel'の定義におけるパケット長とpacketizationの期間が裏打ちする両方を保有する必要があります。
5.6.3.7 The 'dsel' attribute
5.6.3.7 'dsel'属性
The 'dsel' attribute indicates a prioritized list of one or more 3-
tuples for voiceband data service. The <fxIncl> flag indicates
whether this definition of voiceband data includes fax ("on" value)
or not ("off" value). If <fxIncl> is "on", then the 'dsel' line must
be consistent with any 'fsel' line in the session description. In
this case, an error event is generated in the case of inconsistency.
Each 3-tuple indicates a codec, an optional packet length and an
optional packetization period. This complements the 'm' line
information and should be consistent with it.
'dsel'属性はvoicebandデータサービスのために1の最優先するリストか、より多くの3tuplesを示します。 <fxIncl>旗は、voicebandデータのこの定義がファックス(“on"値)を含んでいるかどうかを(“off"値)示します。 <fxIncl>が“on"であるなら、'dsel'線はセッション記述でどんな'fsel'線とも一致しているに違いありません。 この場合、誤り出来事は矛盾の場合で発生します。 各3-tupleはコーデック、任意のパケット長、および任意のpacketizationの期間を示します。 'これが補足となる、'線情報であり、それと一致しているべきです。
The 'dsel' attribute refers to all directions of a connection. For a bidirectional connection, these are the forward and backward directions. For a unidirectional connection, this can be either the backward or forward direction.
'dsel'属性は接続のあらゆる方向について言及します。 双方向の接続において、これらは、フォワードと逆方向です。 単方向の接続において、これは後方の、または、前進の指示であるかもしれません。
The 'dsel' attribute is not meant to be used with bidirectional connections that have asymmetric codec configurations described in a single SDP descriptor. For these, the 'onewaySel' attribute (section 5.6.3.9) should be used. See section 5.6.3.9 for the requirement to not use the 'dsel' and 'onewaySel' attributes in the same SDP descriptor.
'dsel'属性はただ一つのSDP記述子で説明された非対称のコーデック構成を持っている双方向の接続と共に使用されることになっていません。 これら、'onewaySel'属性、(セクション5.6 .3 .9は)使用されるべきです。 セクション5.6を見てください。.3 .9 同じSDP記述子で'dsel'と'onewaySel'属性を使用しないという要件のために。
Kumar & Mostafa Standards Track [Page 70] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[70ページ]。
The 'dsel' line is structured as follows:
'dsel'線は以下の通り構造化されます:
a=dsel:<fxIncl> <encodingName #1> <packetLength #1><packetTime #1>
<encodingName #2> <packetLength #2><packetTime #2>
...
<encodingName #N> <packetLength #N><packetTime #N>
a=dsel: <fxIncl><encodingName#1><packetLength#1><packetTime#1><encodingName#2><packetLength#2><packetTime#2>… <encodingName#N><packetLength#N><packetTime#N>。
where the <encodingName> parameter can take one of the values in column 2 of Table 2. The <packetLength> and <packetTime> parameters are per their definition, above, for the 'vsel' media attribute line. The parameters <packetLength> and <packetTime>) can be set to "-" when not needed. The <fxIncl> flag is presumed to be "off" if it is set to "-". Also, the entire 'dsel' media attribute line can be omitted when not needed.
<encodingName>パラメタがTable2に関するコラム2の値の1つを取ることができるところ。 メディアが結果と考える'vsel'線には<packetLength>と<packetTime>パラメタが上に彼らの定義単位であります。 パラメタの<packetLength>と<packetTime>) 必要でないと、「-」に設定できます。 それが「-」に設定されるなら、<fxIncl>旗はあえて“off"です。 また、必要でないと、メディアが結果と考える全体の'dsel'線を省略できます。
For example,
例えば
a=dsel:- G726-32 20 5000 PCMU 40 5000
a=dsel:、-、G726-32 20 5000 PCMU40 5000
indicates that this line does not address facsimile, and that the first preference for the voiceband data codes is 32 kbps ADPCM, while the second preference is PCMU. The packet length and the packetization interval associated with G726-32 are 20 octets and 5 ms respectively. For PCMU, they are 40 octets and 5 ms respectively.
2番目の好みはPCMUですが、この線がファクシミリを記述しないで、voicebandデータコードのための最優先が32キロビット毎秒ADPCMであることを示します。 パケット長とG726-32に関連しているpacketization間隔は、それぞれ20の八重奏と5msです。 PCMUに関しては、それらは、それぞれ40の八重奏と5msです。
This media attribute line can be used in ATM as well as non-ATM contexts. Within the ATM context, it can be applied to the AAL1, AAL2 and AAL5 adaptations. The <packetLength> and <packetTime> are not meaningful in the AAL1 case and should be set to "-". In the AAL2 case, this line determines the use of some or all of the rows in a given profile table. If multiple 3-tuples are present, they can indicate a hierarchical assignment of some rows in that profile to voiceband data service (e.g., row A preferred to row B etc.) If multiple profiles are present on the 'm' line, the profile qualified by this attribute is the first profile. If a single profile that has been selected for a connection is indicated in the 'm' line, the ' dsel' attribute qualifies the use, for voiceband data service, of codecs within that profile.
非ATM文脈と同様にATMでこのメディア属性線を使用できます。 ATM文脈の中では、AAL1、AAL2、およびAAL5適合にそれを適用できます。 <packetLength>と<packetTime>はAAL1場合で重要でなく、「-」に用意ができるべきです。 AAL2場合では、この線は与えられたプロフィールテーブルにおける列のいくつかかすべての使用を決定します。 複数の3-tuplesが存在しているなら、彼らはそのプロフィールのいくつかの列の階層的な課題をvoicebandデータサービスに示すことができます(例えば、列Aは、Bなどをこぐのを好みました)。 '線、プロフィールは資格があります。プレゼントが'複数のプロフィールであるならオンである、この属性は最初のプロフィールです。 '接続のために選択された単一のプロフィールが中に示される、'線、属性がコーデックのvoicebandデータサービスの使用に資格を与えるそれが輪郭を描く'dsel'はそうです。
With most of the encoding names in Figure 2, the packet length and packetization period can be derived from each other. One of them can be set to "-" without a loss of information. There are some exceptions such as the IANA-registered encoding names G723, DVI4 and L16 for which this is not true. Therefore, there is a need to retain both the packet length and packetization period in the definition of the 'dsel' line.
コード化の大部分で、互いから図2の名前、パケット長、およびpacketizationの期間を得ることができます。 情報の損失なしで「-」にそれらの1つを設定できます。 これが本当でないIANAによって登録されたコード化名のG723や、DVI4やL16などのいくつかの例外があります。 したがって、'dsel'の定義におけるパケット長とpacketizationの期間が裏打ちする両方を保有する必要があります。
Kumar & Mostafa Standards Track [Page 71] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[71ページ]。
5.6.3.8 The 'fsel' attribute
5.6.3.8 'fsel'属性
The 'fsel' attribute indicates a prioritized list of one or more 3- tuples for facsimile service. If an 'fsel' line is present, any ' dsel' line with <fxIncl> set to "on" in the session description must be consistent with it. In this case, an error event is generated in the case of inconsistency. Each 3-tuple indicates a codec, an optional packet length and an optional packetization period. This complements the 'm' line information and should be consistent with it.
'fsel'属性はファクシミリサービスのために1の最優先するリストか、より多くの3tuplesを示します。 'fsel'線が存在しているなら、セッション記述で“on"に用意ができている<fxIncl>があるどんな'dsel'線もそれと一致しているに違いありません。 この場合、誤り出来事は矛盾の場合で発生します。 各3-tupleはコーデック、任意のパケット長、および任意のpacketizationの期間を示します。 'これが補足となる、'線情報であり、それと一致しているべきです。
The 'fsel' attribute refers to all directions of a connection. For a bidirectional connection, these are the forward and backward directions. For a unidirectional connection, this can be either the backward or forward direction.
'fsel'属性は接続のあらゆる方向について言及します。 双方向の接続において、これらは、フォワードと逆方向です。 単方向の接続において、これは後方の、または、前進の指示であるかもしれません。
The 'fsel' attribute is not meant to be used with bidirectional connections that have asymmetric codec configurations described in a --single SDP descriptor. For these, the 'onewaySel' attribute (section 5.6.3.9) should be used. See section 5.6.3.9 for the requirement to not use the 'fsel' and 'onewaySel' attributes in the same SDP descriptor.
'fsel'属性はaで説明された非対称のコーデック構成を持っている双方向の接続と共に使用されることになっていません--ただ一つのSDP記述子。 これら、'onewaySel'属性、(セクション5.6 .3 .9は)使用されるべきです。 セクション5.6を見てください。.3 .9 同じSDP記述子で'fsel'と'onewaySel'属性を使用しないという要件のために。
The 'fsel' line is structured as follows:
'fsel'線は以下の通り構造化されます:
a=fsel:<encodingName #1> <packetLength #1><packetTime #1>
<encodingName #2> <packetLength #2><packetTime #2>
...
<encodingName #N> <packetLength #N><packetTime #N>
a=fsel: <encodingName#1><packetLength#1><packetTime#1><encodingName#2><packetLength#2><packetTime#2>… <encodingName#N><packetLength#N><packetTime#N>。
where the <encodingName> parameter can take one of the values in column 2 of Table 2. The <packetLength> and <packetTime> parameters are per their definition, above, for the 'vsel' media attribute line. The parameters <packetLength> and <packetTime> can be set to "-" when not needed. Also, the entire 'fsel' media attribute line can be omitted when not needed.
<encodingName>パラメタがTable2に関するコラム2の値の1つを取ることができるところ。 メディアが結果と考える'vsel'線には<packetLength>と<packetTime>パラメタが上に彼らの定義単位であります。 必要でないと、パラメタの<packetLength>と<packetTime>は「-」に用意ができることができます。 また、必要でないと、メディアが結果と考える全体の'fsel'線を省略できます。
For example,
例えば
a=fsel:FXDMOD-3 - -
a=fsel: FXDMOD-3--、-
indicates demodulation and remodulation of ITU-T group 3 fax at the gateway.
ゲートウェイでITU-Tグループ3ファックスの復調と再変調を示します。
a=fsel:PCMU 40 5000 G726-32 20 5000
a=fsel: PCMU40 5000G726-32 20 5000
Kumar & Mostafa Standards Track [Page 72] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[72ページ]。
indicates a first and second preference of Mu-law PCM and 32 kbps ADPCM as the facsimile encoding scheme. The packet length and the packetization interval associated with G726-32 are 20 octets and 5 ms respectively. For PCMU, they are 40 octets and 5 ms respectively.
計画をコード化するファクシミリとしてMu-法のPCMと32キロビット毎秒ADPCMの第1と2番目の好みを示します。 パケット長とG726-32に関連しているpacketization間隔は、それぞれ20の八重奏と5msです。 PCMUに関しては、それらは、それぞれ40の八重奏と5msです。
This media attribute line can be used in ATM as well as non-ATM contexts. Within the ATM context, it can be applied to the AAL1, AAL2 and AAL5 adaptations. The <packetLength> and <packetTime> are not meaningful in the AAL1 case and should be set to "-". In the AAL2 case, this line determines the use of some or all of the rows in a given profile table. If multiple 3-tuples are present, they can indicate a hierarchical assignment of some rows in that profile to facsimile service (e.g., row A preferred to row B etc.). If multiple profiles are present on the 'm' line, the profile qualified by this attribute is the first profile. If a single profile that has been selected for a connection is indicated in the 'm' line, the 'fsel' attribute qualifies the use, for facsimile service, of codecs within that profile.
非ATM文脈と同様にATMでこのメディア属性線を使用できます。 ATM文脈の中では、AAL1、AAL2、およびAAL5適合にそれを適用できます。 <packetLength>と<packetTime>はAAL1場合で重要でなく、「-」に用意ができるべきです。 AAL2場合では、この線は与えられたプロフィールテーブルにおける列のいくつかかすべての使用を決定します。 複数の3-tuplesが存在しているなら、彼らは、サービスを電送するためにそのプロフィールのいくつかの列の階層的な課題を示すことができます(例えば、列Aは、Bなどをこぐのを好みました)。 '線、プロフィールは資格があります。プレゼントが'複数のプロフィールであるならオンである、この属性は最初のプロフィールです。 '接続のために選択された単一のプロフィールが中に示される、'線、属性がコーデックのファクシミリサービスの使用に資格を与えるそれが輪郭を描く'fsel'はそうです。
With most of the encoding names in Figure 2, the packet length and packetization period can be derived from each other. One of them can be set to "-" without a loss of information. There are some exceptions such as the IANA-registered encoding names G723, DVI4 and L16 for which this is not true. Therefore, there is a need to retain both the packet length and packetization period in the definition of the 'fsel' line.
コード化の大部分で、互いから図2の名前、パケット長、およびpacketizationの期間を得ることができます。 情報の損失なしで「-」にそれらの1つを設定できます。 これが本当でないIANAによって登録されたコード化名のG723や、DVI4やL16などのいくつかの例外があります。 したがって、'fsel'の定義におけるパケット長とpacketizationの期間が裏打ちする両方を保有する必要があります。
5.6.3.9 The 'onewaySel' attribute
5.6.3.9 'onewaySel'属性
The 'onewaySel' (one way select) attribute can be used with connections that have asymmetric codec configurations. There can be several 'onewaySel' lines in an SDP description. The 'onewaySel' line is structured as follows:
非対称のコーデック構成を持っている接続と共に'onewaySel'(1つの方法選ぶ)の属性を使用できます。 SDP記述にはいくつかの'onewaySel'線があることができます。 'onewaySel'線は以下の通り構造化されます:
a=onewaySel:<serviceType> <directionFlag>
<encodingName #1> <packetLength #1><packetTime #1>
<encodingName #2> <packetLength #2><packetTime #2>
...
<encodingName #N> <packetLength #N><packetTime #N>
a=onewaySel: <serviceType><directionFlag><encodingName#1><packetLength#1><packetTime#1><encodingName#2><packetLength#2><packetTime#2>… <encodingName#N><packetLength#N><packetTime#N>。
The <serviceType> parameter can be assigned the following string values: "v", "d", "f", "df" and "all". These indicate voice, voiceband data (fax not included), fax, voiceband data (fax included) and all services respectively.
<serviceType>パラメタに以下のストリング値を割り当てることができます: 「v」、「d」、「f」、"df"、および「すべて。」 これらはそれぞれ声、voicebandデータ(含まれていなかったファックス)、ファックス、voicebandデータ(ファックスを含んでいる)、およびすべてのサービスについて簡単に述べます。
The <directionFlag> can be assigned the following string values: "f", "b" and "fb". "f" and "b" indicate the forward and backward directions respectively. "fb" refers to both directions (forward and
以下のストリング値を<directionFlag>に割り当てることができます: 「f」、「b」、および"fb"。 「f」と「b」はそれぞれフォワードと逆方向を示します。 そして"fb"が両方の指示を示す、(前進。
Kumar & Mostafa Standards Track [Page 73] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[73ページ]。
backward) and shall not be used with the 'onewaySel' line. Conventions for the forward and backward directions are per section 2.3.
後方に)、'onewaySel'線と共に使用しないでしょう。 フォワードと逆方向のためのコンベンションがセクション2.3単位であります。
Following <directionFlag>, there is a prioritized list of one or more 3-tuples. Each 3-tuple indicates a codec, an optional packet length and an optional packetization period. This complements the 'm' line information and should be consistent with it.
<directionFlag>に続いて、1 3-tuplesの最優先するリストがあります。 各3-tupleはコーデック、任意のパケット長、および任意のpacketizationの期間を示します。 'これが補足となる、'線情報であり、それと一致しているべきです。
Within each 3-tuple, the <encodingName> parameter can take one of the values in column 2 of Table 2. The <packetLength> is a decimal integer representation of the packet length in octets. The <packetTime> is a decimal integer representation of the packetization interval in microseconds.
各3-tupleの中では、<encodingName>パラメタはTable2に関するコラム2の値の1つを取ることができます。 <packetLength>は八重奏で、パケット長の10進整数表現です。 <packetTime>はマイクロセカンドのpacketization間隔の10進整数表現です。
The 'onewaySel' attribute must not be used in SDP descriptors that have one or more of the following attributes: 'vsel', 'dsel', 'fsel'. If it is present, then command containing the SDP description may be rejected. An alternate response to such an ill-formed SDP descriptor might the selective ignoring of some attributes, which must be coordinated via an application-wide policy.
以下の属性の1つ以上を持っているSDP記述子で'onewaySel'属性を使用してはいけません: 'vsel'、'dsel''fsel'。 それが存在しているなら、SDP記述を含むコマンドは拒絶されるかもしれません。 そのような不適格なSDP記述子への交互の応答はいくつかの属性の選択している無視がそうするかもしれません。(アプリケーション全体の方針で属性を調整しなければなりません)。
The <serviceType>, <directionFlag> and <encodingName> parameters may not be set to "-". However, the parameters <packetLength> and <packetTime> can be set to "-" when not needed.
<serviceType>、<directionFlag>、および<encodingName>パラメタは「-」に用意ができないかもしれません。 しかしながら、必要でないと、パラメタの<packetLength>と<packetTime>は「-」に用意ができることができます。
For example,
例えば
a=onewaySel:v f G729 10 10000
a=onewaySel:v b G726-32 40 10000
a=onewaySel: f G729 10 10000a=onewaySel: v b G726-32 40 10000に対して
indicates that for voice service, the codec to be used in the forward direction is G.729 or G.729a (both are interoperable), and the codec to be used in the backward direction is G726-32. A packet length of 10 octets and a packetization interval of 10 ms are associated with the G.729/G.729a codec. A packet length of 40 octets and a packetization interval of 10 ms are associated with the G726-32 codec.
順方向に使用されるべきコーデックが声のサービスのための、G.729かG.729a(両方が共同利用できる)であり、逆方向に使用されるべきコーデックがG726-32であることを示します。 10の八重奏のパケット長と10msのpacketization間隔はG.729/G.729aコーデックに関連しています。40の八重奏のパケット長と10msのpacketization間隔はG726-32コーデックに関連しています。
For example,
例えば
a=onewaySel:d f G726-32 20 5000
a=onewaySel:d b PCMU 40 5000
a=onewaySel: d f G726-32 20 5000 a=onewaySel: d b PCMU40 5000
indicates that for voiceband service (fax not included), the codec to be used in the forward direction is G726-32), and the codec to be used in the backward direction is PCMU. A packet length of 20 octets
表示、voicebandサービス(含まれていなかったファックス)のために、順方向に使用されるべきコーデックはG726-32です)、逆方向に使用されるべきコーデックはPCMUです。 20の八重奏のパケット長
Kumar & Mostafa Standards Track [Page 74] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[74ページ]。
and a packetization interval of 5 ms are associated with the G726-32 codec. A packet length of 40 octets and a packetization interval of 5 ms are associated with the PCMU codec.
そして、5msのpacketization間隔はG726-32コーデックに関連しています。40の八重奏のパケット長と5msのpacketization間隔はPCMUコーデックに関連しています。
This media attribute line can be used in ATM as well as non-ATM contexts. Within the ATM context, it can be applied to the AAL1, AAL2 and AAL5 adaptations. The <packetLength> and <packetTime> are not meaningful in the AAL1 case and should be set to "-". In the AAL2 case, these lines determine the use of some or all of the rows in a given profile table. If multiple 3-tuples are present, they can indicate a hierarchical assignment of some rows in that profile to voice service (e.g., row A preferred to row B etc.). If multiple profiles are present on the 'm' line, the profile qualified by this attribute is the first profile.
非ATM文脈と同様にATMでこのメディア属性線を使用できます。 ATM文脈の中では、AAL1、AAL2、およびAAL5適合にそれを適用できます。 <packetLength>と<packetTime>はAAL1場合で重要でなく、「-」に用意ができるべきです。 AAL2場合では、これらの線は与えられたプロフィールテーブルにおける列のいくつかかすべての使用を決定します。 複数の3-tuplesが存在しているなら、彼らはそのプロフィールのいくつかの列の階層的な課題を声のサービスに示すことができます(例えば、列Aは、Bなどをこぐのを好みました)。 '線、プロフィールは資格があります。プレゼントが'複数のプロフィールであるならオンである、この属性は最初のプロフィールです。
With most of the encoding names in Figure 2, the packet length and packetization period can be derived from each other. One of them can be set to "-" without a loss of information. There are some exceptions such as the IANA-registered encoding names G723, DVI4 and L16 for which this is not true. Therefore, there is a need to retain both the packet length and packetization period in the definition of the 'onewaySel' line.
コード化の大部分で、互いから図2の名前、パケット長、およびpacketizationの期間を得ることができます。 情報の損失なしで「-」にそれらの1つを設定できます。 これが本当でないIANAによって登録されたコード化名のG723や、DVI4やL16などのいくつかの例外があります。 したがって、'onewaySel'の定義におけるパケット長とpacketizationの期間が裏打ちする両方を保有する必要があります。
5.6.3.10 The 'codecconfig' attribute
5.6.3.10 'codecconfig'属性
When present, the 'codecconfig' attribute is used to represent the contents of the single codec information element (IE) defined in [57]. The contents of this IE are: a single-octet Organizational Identifier (OID) field, followed by a single-octet Codec Type field, followed by zero or more octets of a codec configuration bit-map. The semantics of the codec configuration bit-map are specific to the organization [57, 58]. The 'codecconfig' attribute is represented as follows:
存在しているとき、'codecconfig'属性は、[57]で定義されたただ一つのコーデック情報要素(IE)のコンテンツを表すのに使用されます。 このIEの内容は以下の通りです。 コーデック構成ビットマップのただ一つの八重奏Codec Type分野があとに続いたOrganizational Identifier(OID)分野がゼロか以上を続けたただ一つの八重奏八重奏。 コーデック構成ビットマップの意味論は組織[57、58]に特定です。 'codecconfig'属性は以下の通り表されます:
a=codecconfig:<q7655scc>
a=codecconfig: <q7655scc>。
The <q7655scc> (Q.765.5 single codec IE contents) parameter is represented as a string of hex digits. The number of hex digits is even (range 4 -32). The "0x" prefix shall be omitted since this value is always hexadecimal. As with other hex values [Section 2.2], digits to the left are more significant than digits to the right. Leading zeros shall not be omitted.
<q7655scc>(Q.765.5のただ一つのコーデックIEコンテンツ)パラメタは一連の十六進法ケタとして表されます。 十六進法ケタの数は(範囲4 -32)でさえあります。 "0x"接頭語は、いつもこの値が16進であるので、省略されるものとします。 他の十六進法値[セクション2.2]のように、左へのケタはケタより右に重要です。 先行ゼロを省略しないものとします。
An example of the use of this media attribute is:
このメディア属性の使用に関する例は以下の通りです。
a=codecconfig:01080C
a=codecconfig: 01080C
Kumar & Mostafa Standards Track [Page 75] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[75ページ]。
The first octet indicates an Organizational Identifier of 0x01 (the ITU-T). Using ITU Q.765.5 [57], the second octet (0x08) indicates a codec type of G.726 (ADPCM). The last octet, 0x0C indicates that 16 kbps and 24 kbps rates are NOT supported, while the 32 kbps and 40 kbps rates ARE supported.
最初の八重奏は0×01(ITU-T)のOrganizational Identifierを示します。 ITU Q.765.5[57]を使用して、2番目の八重奏(0×08)はG.726(ADPCM)のコーデックタイプを示します。 最後の八重奏、0x0Cは、16キロビット毎秒と24のキロビット毎秒レートが支持されないのを示します、32キロビット毎秒と40のキロビット毎秒レートが支持されますが。
5.6.3.11 The 'isup_usi' attribute
5.6.3.11 'isup_usi'属性
When present, the 'isup_usi' attribute is used to represent the bearer capability information element defined in Section 4.5.5 of ITU Q.931 [59] (excluding the information element identifier and length). This information element is reiterated as the user service information element (IE) in Section 3.57 of ITU Q.763 [60]. The ' isup_usi' attribute is represented as follows:
存在しているとき、'isup_usi'属性は、.5セクション4.5ITU Q.931[59](情報要素識別子と長さを除いた)で定義された運搬人能力情報要素を表すのに使用されます。 この情報要素はITU Q.763[60]のセクション3.57のユーザサービス情報要素(IE)として繰り返されます。 'isup_usi'属性は以下の通り表されます:
a=isup_usi:<isupUsi>
a=isup_usi: <isupUsi>。
The <isupUsi> parameter is represented as a string of hex digits. The number of hex digits is even (allowed range 4 -24). The "0x" prefix shall be omitted since this value is always hexadecimal. As with other hex values [Section 2.2], digits to the left are more significant than digits to the right. Leading zeros shall not be omitted.
<isupUsi>パラメタは一連の十六進法ケタとして表されます。 十六進法ケタの数は偶数です(範囲4 -24を許容します)。 "0x"接頭語は、いつもこの値が16進であるので、省略されるものとします。 他の十六進法値[セクション2.2]のように、左へのケタはケタより右に重要です。 先行ゼロを省略しないものとします。
5.6.3.12 The 'uiLayer1_Prot' attribute
5.6.3.12 'uiLayer1_Prot'属性
When present, the 'uiLayer1_Prot' attribute is used to represent the 'User Information Layer 1 protocol' field within the bearer capability information element defined in Section 4.5.5 of [59], and reiterated as the user service information element (IE) in Section 3.57 of [60]. The 'User Information Layer 1 protocol' field consists of the five least significant bits of Octet 5 of this information element.
存在しているとき、'uiLayer1_Prot'属性は、セクション4.5.5で定義された運搬人能力情報要素の中に'ユーザ情報Layer1プロトコル'分野を表すのに[59]について使用されて、[60]のセクション3.57のユーザサービス情報要素(IE)として繰り返されます。 'ユーザ情報Layer1プロトコル'分野はこの情報要素のOctet5の5つの最下位ビットから成ります。
Within SDP, the 'uiLayer1_Prot' attribute is represented as follows:
SDPの中では、'uiLayer1_Prot'属性は以下の通り表されます:
a='uiLayer1_Prot':<uiLayer1Prot>
='uiLayer1_Prot': <uiLayer1Prot>。
The <uiLayer1Prot> parameter is represented as a string of two hex digits. The "0x" prefix shall be omitted since this value is always hexadecimal. As with other hex values [Section 2.2], digits to the left are more significant than digits to the right. These hex digits are constructed from an octet with three leading '0' bits and last five bits equal to the 'User Information Layer 1 protocol' field described above. As specified in [59] and [26], bit 5 of this field is the most significant bit. The resulting values of the <uiLayer1Prot> parameter are as follows:
<uiLayer1Prot>パラメタは一連の2十六進法ケタとして表されます。 "0x"接頭語は、いつもこの値が16進であるので、省略されるものとします。 他の十六進法値[セクション2.2]のように、左へのケタはケタより右に重要です。 これらの十六進法ケタは3がある'0'ビットと最後に上で説明された'ユーザ情報Layer1プロトコル'分野と等しい5ビットを導く八重奏から構成されます。 [59]と[26]で指定されるように、この分野のビット5は最も重要なビットです。 <uiLayer1Prot>パラメタの結果として起こる値は以下の通りです:
Kumar & Mostafa Standards Track [Page 76] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[76ページ]。
VALUE MEANING 0x01 CCITT standardized rate adaption V.110 and X.30 0x02 Recommendation G.711 Mu-law 0x03 Recommendation G.711 A-law 0x04 Recommendation G.721 32 kbps ADPCM and Recommendation I.460 0x05 Recommendations H.221 and H.242 0x06 Recommendation H.223 and H.245 0x07 Non-ITU-T standardized rate adaption 0x08 ITU-T standardized rate adaption V.120 0x09 CCITT standardized rate adaption X.31 HDLC flag stuffing
VALUE MEANING 0x01 CCITT standardized rate adaption V.110 and X.30 0x02 Recommendation G.711 Mu-law 0x03 Recommendation G.711 A-law 0x04 Recommendation G.721 32 kbps ADPCM and Recommendation I.460 0x05 Recommendations H.221 and H.242 0x06 Recommendation H.223 and H.245 0x07 Non-ITU-T standardized rate adaption 0x08 ITU-T standardized rate adaption V.120 0x09 CCITT standardized rate adaption X.31 HDLC flag stuffing
5.6.4 Miscellaneous media attributes
5.6.4 種々雑多なメディア属性
The 'chain' media attribute line, which is used to chain consecutive SDP descriptions, cannot be classified as an ATM, AAL or service attribute. It is detailed in the following subsection.
ATM、AALまたはサービス属性としてメディアが結果と考える'チェーン'線(連続したSDP記述をチェーニングするのに使用される)を分類できません。 それは以下の小区分で詳細です。
5.6.4.1 The 'chain' attribute
5.6.4.1 'チェーン'属性
The start of an SDP descriptor is marked by a 'v' line. In some applications, consecutive SDP descriptions are alternative descriptions of the same session. In others, these describe different layers of the same connection (e.g., IP, ATM, frame relay). This is useful when these connectivity at these layers are established at the same time (e.g., an IP-based session over an ATM SVC). To distinguish between the alternation and concatenation of SDP descriptions, a 'chain' attribute can be used in the case of concatenation.
SDP記述子の始まりは'v'線によって示されます。 使用目的によっては、連続したSDP記述は同じセッションの代替の記述です。 他のものでは、これらは異なった層の同じ接続(例えば、IP、ATM、フレームリレー)について説明します。 これらの層のこれらの接続性が同時に(例えば、ATM SVCの上のIPベースのセッション)確立されるとき、これは役に立ちます。 SDP記述の交互と連結を見分けるために、連結の場合に'チェーン'属性を使用できます。
When present, the 'chain' attribute binds an SDP description to the next or previous SDP description. The next or previous description is separated from the current one by a 'v' line. It is not necessary that this description also have a 'chain' media attribute line.
存在しているとき、'チェーン'属性は次か前のSDP記述にSDP記述を縛ります。 次か前の記述は'v'線によって現在のものと切り離されます。 また、'チェーン'メディア属性がこの記述で立ち並ぶのは必要ではありません。
Chaining averts the need to set up a single SDP description for a session that is simultaneously created at multiple layers. It allows the SDP descriptors for different layers to remain simple and clean. Chaining is not needed in the Megaco context, where it is possible to create separate terminations for the different layers of a connection.
推論は同時に複数の層に作成されるセッションのためにただ一つのSDP記述をセットアップする必要性を逸らします。 それは、異なった層が簡単であって、清潔なままで残るようにSDP記述子を許容します。 推論はMegaco文脈で必要ではありません。そこでは、接続の異なった層のための別々の終了を作成するのが可能です。
The 'chain' media attribute line has the following format:
メディアが結果と考える'チェーン'線には、以下の形式があります:
a=chain:<chainPointer>
=チェーン: <chainPointer>。
The <chainPointer> field can take on the following string values: "NEXT", "PREVIOUS" and "NULL". The value "NULL" is not equivalent to omitting the chain attribute from a description since it expressly
<chainPointer>分野は以下のストリング値を呈することができます: 「次」で、「前で」「ヌルです」。 値の「ヌル」はそれ以来の記述からチェーン属性を明白に省略するのに同等ではありません。
Kumar & Mostafa Standards Track [Page 77] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[77ページ]。
precludes the possibility of chaining. If the 'chain' attribute is absent in an SDP description, chaining can still be realized by the presence of a chain media attribute line in the previous or next description.
推論の可能性を排除します。 'チェーン'属性がSDP記述で欠けるなら、メディア属性が前であるか次の記述で裏打ちするチェーンの存在はまだ推論を実現できます。
5.6.5 Use of the second media-level part in H.323 Annex C applications
5.6.5 H.323 Annex Cアプリケーションにおける2番目のメディアレベル部分の使用
Section 4 mentions that H.323 annex C applications have a second media level part for the ATM session description. This is used to convey information about the RTCP stream. Although the RTP stream is encapsulated in AAL5 with no intervening IP layer, the RTCP stream is sent to an IP address and RTCP port. This media-level part has the following format:
セクション4は、第2のメディアレベルがATMセッション記述のためにH.323別館Cアプリケーションで離れていると言及します。 これは、RTCPの流れに関して情報を伝達するのに使用されます。 AAL5で介入しているIP層なしでRTP小川を要約しますが、IPアドレスとRTCPポートにRTCP小川を送ります。 このメディアレベル部分には、以下の形式があります:
m= control <rtcpPortNum> H323c -
c= IN IP4 <rtcpIPaddr>
m=コントロール<rtcpPortNum>H323c--cはIN IP4<rtcpIPaddr>と等しいです。
Consistency with RFC 2327 is maintained in the location and format of these lines. The <fmt list> in the 'm' line is set to "-". The 'c' line in the second media-level part pertains to RTCP only.
RFC2327がある一貫性はこれらの線の位置と形式で維持されます。 '中の<fmtリスト>、'線は「-」に設定されます。 2番目のメディアレベル部分の'c'線はRTCPだけに関係します。
The <rtcpPortNum> and <rtcpIPaddr> subparameters indicate the port number and IP address on which the media gateway is prepared to receive RTCP packets.
<rtcpPortNum>と<rtcpIPaddr>「副-パラメタ」はメディアゲートウェイがRTCPパケットを受けるように準備されるポートナンバーとIPアドレスを示します。
Any of the subparameters on these lines can be set to "-" if they are known by other means.
それらが他の手段によって知られているなら、これらの線の上の「副-パラメタ」のいずれも「-」に用意ができることができます。
The range and format of the <rtcpPortNum> and <rtcpIPaddr> subparameters is per [1]. The <rtcpPortNum> is a decimal number between 1024 and 65535. It is an odd number. If an even number in this range is specified, the next odd number is used. The <rtcpIPaddr> is expressed in the usual dotted decimal IP address representation, from 0.0.0.0 to 255.255.255.255.
<rtcpPortNum>と<rtcpIPaddr>「副-パラメタ」の範囲と形式が[1]単位であります。 <rtcpPortNum>は1024〜65535の10進数です。 それは奇数です。 この範囲の偶数が指定されるなら、次の奇数は使用されています。 <rtcpIPaddr>が0.0から普通のドット付き10進法IPアドレス表現で急送される、.0、.0、255.255 .255 .255。
5.6.6 Use of the eecid media attribute in call establishment
procedures
5.6.6 呼設定手順におけるeecidメディア属性の使用
This informative section supplements the definition of the eecid attribute (Section 5.6.1.1) by describing example procedures for its use. These procedures assume a bearer-signaling mechanism for connection set-up that is independent of service-level call control. These procedures are independent of the media gateway control protocol (MGCP, Megaco, SIP etc.), the protocol used between media gateway controllers (ITU Q.1901, SIP etc.) and the protocol used for bearer connection set-up (Q.2931, UNI, PNNI, AINI, IISP, Q.2630.1 etc.).
この有益なセクションがeecid属性の定義を補う、(セクション5.6 .1 .1) 使用のための例の手順について説明することによって。 これらの手順はサービスレベル呼び出しコントロールから独立している接続セットアップのために運搬人シグナル伝達機構を仮定します。 これらの手順はメディアゲートウェイ制御プロトコル(MGCP、SIP Megacoなど)から独立しています、そして、プロトコルはメディアの間でゲートウェイコントローラ(SIP ITU Q.1901など)を使用しました、そして、プロトコルは運搬人接続に、セットアップ(Q.2931、UNI、PNNI、AINI、Q.2630.1IISPなど)を使用しました。
Kumar & Mostafa Standards Track [Page 78] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[78ページ]。
Inter-MGC
+---------+ Protocol +---------+
| MGC |------------------| MGC |
+---------+ +---------+
| |
|Media Gateway |Media Gateway
|Control Protocol |Control Protocol
| |
+------------+ (ATM Network) +------------+
|Originating |------------------|Terminating |
|Media | Bearer Setup |Media |
|Gateway | Protocol |Gateway |
+------------+ +------------+
相互MGC+---------+ プロトコル+---------+ | MGC|------------------| MGC| +---------+ +---------+ | | |メディアゲートウェイ|メディアゲートウェイ|制御プロトコル|制御プロトコル| | +------------+ (気圧ネットワーク)+------------+ |由来します。|------------------|終わります。| |メディア| 運搬人セットアップ|メディア| |ゲートウェイ| プロトコル|ゲートウェイ| +------------+ +------------+
In the diagram above, the originating media gateway originates the service-level call. The terminating media gateway terminates it. In the forward bearer connection set-up model, the originating media gateway initiates bearer connection set-up. In the backward bearer connection set-up model, the terminating gateway initiates bearer connection set-up.
ダイヤグラムで、上では、由来しているメディアゲートウェイがサービスレベル呼び出しを溯源します。 終わっているメディアゲートウェイはそれを終えます。 前進の運搬人接続セットアップモデルで、由来しているメディアゲートウェイは運搬人接続セットアップに着手します。 遅れている運搬人接続セットアップモデルで、終わりゲートウェイは運搬人接続セットアップに着手します。
Example use of the Backward Bearer Connection Set-up Model:
Backward Bearer Connection Set上がっているModelの例の使用:
(1) The originating media gateway controller (OMGC) initiates
service-level call establishment by sending the appropriate
control message to the originating media gateway (OMG).
(1) 由来しているメディアゲートウェイコントローラ(OMGC)は、由来しているメディアゲートウェイ(OMG)に適切なコントロールメッセージを送ることによって、サービスレベル呼び出し設立を開始します。
(2) The originating media gateway (OMG) provides its NSAP address
and an eecid value to the OMGC, using the following SDP
description:
(2) 由来しているメディアゲートウェイ(OMG)はNSAPアドレスとeecid値をOMGCに供給します、以下のSDP記述を使用して:
v=0
o=- 2873397496 0 ATM NSAP
47.0091.8100.0000.0060.3E64.FD01.0060.3E64.FD01.00
s=-
c=ATM NSAP
47.0091.8100.0000.0060.3E64.FD01.0060.3E64.FD01.00
t=0 0
m=audio $ AAL2/ITU 8
a=eecid:B3D58E32
0 0v=0o=-2873397496 0ATM NSAP47.0091.8100.0000.0060.3E64.FD01.0060.3E64.FD01.00 s=c=ATM NSAP47.0091.8100.0000.0060.3E64.FD01.0060.3E64.FD01.00t=mはAAL2/ITU8a=eecid: オーディオの$B3D58E32と等しいです。
(3) The originating media gateway controller (OMGC) signals the
terminating media gateway controller (TMGC) through the
appropriate mechanism (ISUP with Q.1901 extensions, SIP etc.).
It provides the TMGC with the NSAP address and the eecid
provided by the OMG.
(3) 由来しているメディアゲートウェイコントローラ(OMGC)は適切な手段(Q.1901SIP拡張子などがあるISUP)を通して終わっているメディアゲートウェイコントローラ(TMGC)に合図します。 それはNSAPアドレスとOMGによって提供されたeecidをTMGCに提供します。
Kumar & Mostafa Standards Track [Page 79] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[79ページ]。
(4) The TMGC sends the appropriate control message to the TMG. This
includes the session descriptor received from the OMG. This
descriptor contains the NSAP address of the OMG and the EECID
assigned by the OMG. Additionally, the TMGC instructs the TMG
to set up an SVC to the OMG. It also requests the TMG to notify
the TMGC when SVC set-up is complete. Depending on the control
protocol used, this can be done through a variety of means. In
the Megaco context, the request to set-up an SVC (not the
notification request for the SVC set-up event) can be made
through the following local descriptor:
(4) TMGCは適切なコントロールメッセージをTMGに送ります。 これはOMGから受け取られたセッション記述子を含んでいます。 この記述子はOMGによって割り当てられたOMGとEECIDのNSAPアドレスを含んでいます。 さらに、TMGCは、OMGにSVCをセットアップするようTMGに命令します。 また、それは、SVCセットアップが完全であるときにはTMGCに通知するようTMGに要求します。 使用される制御プロトコルによって、さまざまな手段でこれができます。 Megaco文脈では、以下のローカルの記述子を通してSVC(SVCセットアップイベントを求める通知要求でない)をセットアップするという要求をすることができます:
v=0 o=- 2873397497 0 ATM - - s=- c=ATM - - t=0 0 m=audio $ - - a=bearerType:SVC on
0 0--s=-c=ATM----t=mがオーディオの$と等しいというv=0o=-2873397497 0ATM--a=bearerType: SVC、オン
The 'bearerType' attribute indicates that an SVC is to be used and that the <localInitiation> flag is on i.e., the SVC is to be set up by the TMG.
SVCが使用されていることになっていて、<localInitiation>旗がオンであり、すなわち、SVCがTMGがセットアップされることになっているのを、'bearerType'属性は、示します。
(5) The TMG acknowledges the control message from the TMGC. It
returns the following SDP descriptor with the acknowledge:
(5) TMGはTMGCからのコントロールメッセージを承認します。 以下のSDP記述子を返す、承認します:
v=0
o=- 2873397498 0 ATM NSAP
47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00
s=-
c=ATM NSAP
47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00
t=0 0
m=audio $ AAL2/ITU 8
0 0v=0o=-2873397498 0ATM NSAP47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00 s=c=ATM NSAP47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00t=mはオーディオとAAL2/ITU8ドル等しいです。
The NSAP address information provided in this descriptor is not needed. It can be omitted (by setting it to "- -").
この記述子に提供されたNSAPアドレス情報は必要ではありません。 それを省略できる、(それを設定する、「-、--、」、)
(6) The TMG sends an SVC set-up message to the OMG. Within the GIT
information element, it includes eecid (B3D58E32) received from
the OMG.
(6) TMGはSVCセットアップメッセージをOMGに送ります。 GIT情報要素の中では、それはOMGから受け取られたeecid(B3D58E32)を含んでいます。
(7) The OMG uses the eecid to correlate the SVC set-up request with
service-level control message received before from the OMGC.
(7) OMGは、以前OMGCからサービスレベルコントロールメッセージを受け取っていてSVCセットアップ要求を関連させるのにeecidを使用します。
(8) The OMG returns an SVC connect message to the TMG. On receiving
this message, the TMG sends an event notification to the TMGC
indicating successful SVC set-up.
OMGがSVCを返す(8)はメッセージをTMGに接続します。 このメッセージを受け取ると、TMGはうまくいっているSVCセットアップを示すTMGCにイベント通知を送ります。
Kumar & Mostafa Standards Track [Page 80] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[80ページ]。
Note that, for this example, the "v=", "o=", "s=" and "t=" lines
can be omitted in the Megaco context.
Megaco文脈でこの例に関して「v=」、「o=」、「s=」、および「t=」線を省略できることに注意してください。
Example use of the Forward Bearer Connection Set-up Model:
Forward Bearer Connection Set上がっているModelの例の使用:
(1) The originating media gateway controller (OMGC) initiates
service-level call establishment by sending the appropriate
controlsmessage to the originating media gateway (OMG).
(1) 由来しているメディアゲートウェイコントローラ(OMGC)は、由来しているメディアゲートウェイ(OMG)に適切なcontrolsmessageを送ることによって、サービスレベル呼び出し設立を開始します。
(2) The originating media gateway (OMG) provides its NSAP address to
the OMGC, using the following SDP description:
(2) 以下のSDP記述を使用して、由来しているメディアゲートウェイ(OMG)はNSAPアドレスをOMGCに供給します:
v=0
o=- 2873397496 0 ATM NSAP
47.0091.8100.0000.0060.3E64.FD01.0060.3E64.FD01.00
s=-
c=ATM NSAP
47.0091.8100.0000.0060.3E64.FD01.0060.3E64.FD01.00
t=0 0
m=audio $ AAL2/ITU 8
0 0v=0o=-2873397496 0ATM NSAP47.0091.8100.0000.0060.3E64.FD01.0060.3E64.FD01.00 s=c=ATM NSAP47.0091.8100.0000.0060.3E64.FD01.0060.3E64.FD01.00t=mはオーディオとAAL2/ITU8ドル等しいです。
The NSAP address information provided in this descriptor is not needed. It can be omitted (by setting it to "- -").
この記述子に提供されたNSAPアドレス情報は必要ではありません。 それを省略できる、(それを設定する、「-、--、」、)
(3) The originating media gateway controller (OMGC) signals the
terminating media gateway controller (TMGC) through the
appropriate mechanism (ISUP with Q.1901 extensions, SIP etc.).
Although this is not necessary, it can provide the TMGC with the
NSAP address provided by the OMG.
(3) 由来しているメディアゲートウェイコントローラ(OMGC)は適切な手段(Q.1901SIP拡張子などがあるISUP)を通して終わっているメディアゲートウェイコントローラ(TMGC)に合図します。 これは必要ではありませんが、それはOMGによって提供されたNSAPアドレスをTMGCに提供できます。
(4) The TMGC sends the appropriate control message to the TMG. This
includes the session descriptor received from the OMG. This
descriptor contains the NSAP address of the OMG.
(4) TMGCは適切なコントロールメッセージをTMGに送ります。 これはOMGから受け取られたセッション記述子を含んでいます。 この記述子はOMGのNSAPアドレスを含んでいます。
(5) The TMG acknowledges the control message from the TMGC. Along
with the acknowledgement, it provides an SDP descriptor with a
locally assigned eecid.
(5) TMGはTMGCからのコントロールメッセージを承認します。 承認と共に、それは局所的に割り当てられたeecidをSDP記述子に提供します。
v=0
o=- 2873397714 0 ATM NSAP
47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00
s=-
c=ATM NSAP
47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00
t=0 0
m=audio $ AAL2/ITU 8
a=eecid:B3D58E32
0 0v=0o=-2873397714 0ATM NSAP47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00 s=c=ATM NSAP47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00t=mはAAL2/ITU8a=eecid: オーディオの$B3D58E32と等しいです。
Kumar & Mostafa Standards Track [Page 81] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[81ページ]。
(6) The terminating media gateway controller (TMGC) signals the
originating media gateway controller (OMGC) through the
appropriate mechanism (ISUP with Q.1901 extensions, SIP etc.).
It provides the OMGC with the NSAP address and the eecid
provided by the TMG.
(6) 終わっているメディアゲートウェイコントローラ(TMGC)は適切な手段(Q.1901SIP拡張子などがあるISUP)を通して由来しているメディアゲートウェイコントローラ(OMGC)に合図します。 それはNSAPアドレスとTMGによって提供されたeecidをOMGCに提供します。
(7) The OMGC sends the appropriate control message to the OMG. This
includes the session descriptor received from the TMG. This
descriptor contains the NSAP address of the TMG and the EECID
assigned by the TMG. Additionally, the OMGC instructs the OMG
to set up an SVC to the TMG. It also requests the OMG to notify
the OMGC when SVC set-up is complete. Depending on the control
protocol used, this can be done through a variety of means. In
the Megaco context, the request to set-up an SVC (not the
notification request for the SVC set-up event) can be made
through the following local descriptor:
(7) OMGCは適切なコントロールメッセージをOMGに送ります。 これはTMGから受け取られたセッション記述子を含んでいます。 この記述子はTMGによって割り当てられたTMGとEECIDのNSAPアドレスを含んでいます。 さらに、OMGCは、TMGにSVCをセットアップするようOMGに命令します。 また、それは、SVCセットアップが完全であるときにはOMGCに通知するようOMGに要求します。 使用される制御プロトコルによって、さまざまな手段でこれができます。 Megaco文脈では、以下のローカルの記述子を通してSVC(SVCセットアップイベントを求める通知要求でない)をセットアップするという要求をすることができます:
v=0 o=- 2873397874 0 ATM - - s=- c=ATM - - t=0 0 m=audio $ - - a=bearerType:SVC on
0 0--s=-c=ATM----t=mがオーディオの$と等しいというv=0o=-2873397874 0ATM--a=bearerType: SVC、オン
The 'bearerType' attribute indicates that an SVC is to be used and that the <localInitiation> flag is on i.e., the SVC is to be set up by the TMG.
SVCが使用されていることになっていて、<localInitiation>旗がオンであり、すなわち、SVCがTMGがセットアップされることになっているのを、'bearerType'属性は、示します。
(8) The OMG acknowledges the control message from the OMGC.
(8) OMGはOMGCからのコントロールメッセージを承認します。
(9) The OMG sends an SVC set-up message to the TMG. Within the GIT
information element, it includes eecid (B3D58E32) received from
the TMG.
(9) OMGはSVCセットアップメッセージをTMGに送ります。 GIT情報要素の中では、それはTMGから受け取られたeecid(B3D58E32)を含んでいます。
(10) The TMG uses the eecid to correlate the SVC set-up request with
the service-level control message received before from the TMGC.
(10) TMGは、以前TMGCからサービスレベルコントロールメッセージを受け取っていてSVCセットアップ要求を関連させるのにeecidを使用します。
(11) The TMG returns an SVC connect message to the OMG. On receiving
this message, the OMG sends an event notification to the OMGC
indicating successful SVC set-up.
TMGがSVCを返す(11)はメッセージをOMGに接続します。 このメッセージを受け取ると、OMGはうまくいっているSVCセットアップを示すOMGCにイベント通知を送ります。
Note that, for this example, the "v=", "o=", "s=" and "t="
lines can be omitted in the Megaco context.
Megaco文脈でこの例に関して「v=」、「o=」、「s=」、および「t=」線を省略できることに注意してください。
Kumar & Mostafa Standards Track [Page 82] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[82ページ]。
6. List of Parameters with Representations
6. 表現があるパラメタのリスト
This section provides a list of the parameters used in this document, and the formats used to represent them in SDP descriptions. In general, a "-" value can be used for any field that is not specified, is inapplicable or is implied.
このセクションは本書では使用される、パラメタのリスト、およびSDP記述でそれらを表すのに使用される形式を提供します。 一般に、指定されないか、不適当であるか、または含意されるどんな分野にも「-」値を使用できます。
PARAMETER MEANING REPRESENTATION
パラメタ意味表現
<username> User name Constant "-"
>User名前Constant「-」という<ユーザ名
<sessionID> Session ID Up to 32 decimal or
hex digits
32小数か十六進法ケタへの<sessionID>Session ID Up
<version> Version of "0" or 10 decimal digits
SDP descriptor
「0インチか10 10進数字SDP記述子」の<バージョン>バージョン
<networkType> Network type Constant "ATM" for ATM transport
<networkType>Networkは気圧輸送のためにConstant「気圧」をタイプします。
<addressType> Address type String values:
"NSAP", "E164", "GWID",
"ALIAS"
<addressType>AddressはString値をタイプします: "NSAP"、「164E」、"GWID"「アリア」
<address> Address "NSAP": 40 hex digits, dotted
"E164": up to 15 decimal digits
"GWID": up to 32 characters
"ALIAS": up to 32 characters
<アドレス>アドレス"NSAP": 40 「164E」点を打たれた十六進法ケタ: 最大15 10進数字"GWID": 最大32キャラクタ「別名」: 最大32のキャラクタ
<sessionName> Session name Constant "-"
<sessionName>Session名前Constant「-」
<startTime> Session start "0" or 10 decimal digits
time
<startTime>Sessionは「0インチか10 10進数字時間」を始めます。
<stopTime> Session stop Constant "0"
time
<stopTime>SessionはConstant「0インチの回」を止めます。
<vcci> Virtual Circuit Decimal or hex equivalent
Connection of 16 bits
Identifier
16ビットのIdentifierの<vcci>Virtual Circuit Decimalか十六進法の同等なConnection
<ex_vcci> Explicit "VCCI-" prefixed to <vcci>
representation
of <vcci>
vcci>Explicit"VCCI"が<vcci>の<vcci>表現へ前に置いた<の元の_
<bcg> Bearer Connection Decimal or hex equivalent
Group of 8 bits
8ビットの<bcg>Bearer Connection Decimalか十六進法の同等なGroup
Kumar & Mostafa Standards Track [Page 83] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[83ページ]。
<ex_bcg> Explicit "BCG-" prefixed to <bcg>
representation
of <bcg>
bcg>Explicit"BCG"が<bcg>の<bcg>表現へ前に置いた<の元の_
<portId> Port ID Hex number of up to 32 digits
最大32ケタの<portId>Port ID Hex番号
<ex_portId> Explicit "PORT-" prefixed to <portId>
representation
of <portId>
<portId>の<portId>表現へ前に置かれた<の元の_portId>Explicit「ポート」
<vpi> Virtual Path Decimal or hex equivalent
Identifier of 8 or 12 bits
8ビットか12ビットの<vpi>Virtual Path Decimalか十六進法の同等なIdentifier
<ex_vpi> Explicit "VPI-" prefixed to <vpi>
representation
of <vpi>
vpi>Explicit"VPI"が<vpi>の<vpi>表現へ前に置いた<の元の_
<vci> Virtual Circui t Decimal or hex equivalent
Identifier of 16 bits
16ビットの<vci>Virtual Circui t Decimalか十六進法の同等なIdentifier
<ex_vci> Explicit "VCI-" prefixed to <vci>
representation
of <vci>
vci>Explicit"VCI"が<vci>の<vci>表現へ前に置いた<の元の_
<vpci> Virtual Path Decimal or hex equivalent
Connection of 16 bits
Identifier
16ビットのIdentifierの<vpci>Virtual Path Decimalか十六進法の同等なConnection
<ex_vpci> Explicit "VPCI-" prefixed to <vpci>
representation
of <vpci>
vpci>Explicit"VPCI"が<vpci>の<vpci>表現へ前に置いた<の元の_
<cid> Channel Decimal or hex equivalent
Identifier of 8 bits
8ビットの<Cid>Channel Decimalか十六進法の同等なIdentifier
<ex_cid> Explicit "CID-" prefixed to <cid>
representation
of <cid>
<の元の_Cid>Explicit「Cid」は<Cidの<Cid>表現へ>を前に置きました。
<payloadType> Payload Decimal integer 0-127
Type
<payloadType>有効搭載量Decimal整数0-127Type
<transport> Transport Values listed in
Table 1.
<輸送>Transport ValuesはTable1に記載しました。
<profile> Profile Decimal integer 1-255
<プロフィール>Profile Decimal整数1-255
Kumar & Mostafa Standards Track [Page 84] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[84ページ]。
<eecid> End-to-end Up to 8 hex digits
Connection
Identifier
<eecid>Endから終わりへの8十六進法ケタConnection IdentifierへのUp
<aalType> AAL type String values:
"AAL1","AAL1_SDT","AAL1_UDT",
"AAL2", "AAL3/4",
"AAL5", "USER_DEFINED_AAL"
<aalType>AALはString値をタイプします: 「「」 AAL1"、AAL1_SDT」、「AAL1_UDT」、「AAL2"、「何AAL3/4インチも、「AAL5"、「ユーザ_は_AALを定義」でした」。
<asc> ATM service String values:
category defined "CBR", "nrt-VBR", "rt-VBR",
by the ATMF "UBR", "ABR", "GFR"
<asc>ATMはString値を修理します: カテゴリはATMF"UBR"、"ABR""GFR"で"CBR"、"nrt-VBR""rt-VBR"を定義しました。
<atc> ATM transfer String values:
capability "DBR","SBR","ABT/IT","ABT/DT",
defined by the "ABR"
ITU
<atc>ATMはString値を移します: 「アプト/DT」という"DBR"、"SBR"「アプト/IT」が"ABR"ITUで定義した能力
<subtype> <asc>/<atc> Decimal integer 1-10
subtype
<「副-タイプ」><asc>/<atc>Decimal整数1-10「副-タイプ」
<qosClass> QoS Class Decimal integer 0-5
<qosClass>QoS Class Decimal整数0-5
<bcob> Broadband Bearer Decimal or hex representation
Class of 5-bit field
5ビットの分野の<bcob>Broadband Bearer Decimalか十六進法表現Class
<eetim> End-to-end timing String values: "on",
required "off".
<eetim>Endから終わりへのタイミングString値: "on"、必要な“off"。
<stc> Susceptibility Decimal equivalent of
to clipping a 2-bit field
<は2ビットの分野を切り取るのに同等な状態で>Susceptibility Decimalをstcします。
<upcc> User plane Decimal equivalent of
connection a 2-bit field
configuration
接続の<upcc>User飛行機Decimal同等物は2ビットの分野構成です。
<directionFlag> Direction Flag String values: "f", "b",
"fb"
<directionFlag>Direction Flag String値: 「f」、「b」"fb"
<cdvType> CDV type String values:
"PP", "2P"
<cdvType>CDVはString値をタイプします: 「pp」、"2P"
<acdv> Acceptable CDV Decimal equivalent
of 24-bit field
24ビットの分野の<acdv>Acceptable CDV Decimal同等物
<ccdv> Cumulative CDV Decimal equivalent
of 24-bit field
24ビットの分野の<ccdv>Cumulative CDV Decimal同等物
Kumar & Mostafa Standards Track [Page 85] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[85ページ]。
<eetd> End-to-end transit Decimal equivalent
delay of 16-bit field
16ビットの分野のEndから終わりへの<eetd>トランジットDecimal同等な遅れ
<cmtd> Cumulative transit Decimal equivalent
delay of 16-bit field
16ビットの分野の<の>のCumulativeのトランジットのDecimalの同等なcmtd遅れ
<aclr> Acceptable Decimal equivalent
Cell Loss Ratio of 8-bit field
8ビットの分野の<のaclrの>のAcceptable Decimalの同等なCell Loss Ratio
<clpLvl> CLP level String values:
"0", "0+1"
<clpLvl>CLPはString値を平らにします: "0", "0+1"
<pcr> Peak Decimal
Cell Rate equivalent of a 24-bit field.
24ビットの分野の<pcr>Peak Decimal Cell Rate同等物。
<scr> Sustained Decimal
Cell Rate equivalent of a 24-bit field
24ビットの分野の<scr>Sustained Decimal Cell Rate同等物
<mbs> Maximum Decimal
Burst Size equivalent of 16-bit field
16ビットの分野の<mb>Maximum Decimal Burst Size同等物
<cdvt> CDVT Decimal equivalent of 24-bit
field.
24ビットの分野の<cdvt>CDVT Decimal同等物。
<mcr> Minimum Decimal
Cell Rate equivalent of a 24-bit field
24ビットの分野の<mcr>Minimum Decimal Cell Rate同等物
<mfs> Maximum Decimal
Frame Size equivalent of a 16-bit field
16ビットの分野の<mf>Maximum Decimal Frame Size同等物
<fd> Frame Discard String Values:
Allowed "on", "off"
<fd>フレームはストリング値を捨てます: 許容“on"、“off"
<te> CLP tagging String Values:
"on", "off"
String Valuesにタグ付けをする<Te>CLP: "on"、“off"
<nrm> NRM Decimal/hex equivalent
of 3 bit field
3ビットの分野の<nrm>NRM Decimal/十六進法同等物
<trm> TRM -ditto-
<trm>TRM-同上、-
<cdf> CDF -ditto-
<cdf>CDF-同上、-
<adtf> ADTF Decimal/Hex equivalent
of 10 bit field
10ビットの分野の<adtf>ADTF Decimal/十六進法同等物
Kumar & Mostafa Standards Track [Page 86] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[86ページ]。
<ficr> Forward Initial Decimal equivalent of
Cell Rate 24-bit field
Cell Rateの24ビットの分野の<ficr>Forward Initial Decimal同等物
<bicr> Backward Initial Decimal equivalent of
Cell Rate 24-bit field
Cell Rateの24ビットの分野の<bicr>Backward Initial Decimal同等物
<ftbe> Forward Transient Decimal equivalent of
Buffer Exposure 24-bit field
Buffer Exposureの24ビットの分野の<ftbe>Forward Transient Decimal同等物
<btbe> Backward Transient Decimal equivalent of
Buffer Exposure 24-bit field
Buffer Exposureの24ビットの分野の<btbe>Backward Transient Decimal同等物
<crmrtt> Cumulative RM Decimal equivalent of
round-trip time 24-bit field
(Microseconds)
往復の時間24ビットの分野の<crmrtt>Cumulative RM Decimal同等物(マイクロセカンド)
<frif> Forward rate Decimal integer
increase factor 0 -15
<frif>Forwardは、Decimal整数増加が要素0 -15であると評定します。
<brif> Backward rate Decimal integer
increase factor 0 -15
<brif>Backwardは、Decimal整数増加が要素0 -15であると評定します。
<frdf> Forward rate Decimal integer
decrease factor 0 -15
<frdf>ForwardレートDecimal整数減少要素0 -15
<brdf> Backward rate Decimal integer
decrease factor 0 -15
<brdf>BackwardレートDecimal整数減少要素0 -15
<bearerType> Bearer Type String Values:
"PVC", "SVC", "CID"
<bearerType>運搬人タイプは値を結びます: "PVC"、"SVC"「Cid」
<localInitiation> Local Initiation String values:
"on", "off"
<localInitiation>Local Initiation String値: "on"、“off"
<sci> Screening Indication Decimal or hex
equivalent of 4 bits.
4ビットの<sci>Screening Indication Decimalか十六進法同等物。
<lsn> Leaf Sequence Number Decimal or hex
equivalent of 32 bits.
32ビットの<lsn>Leaf Sequence Number Decimalか十六進法同等物。
<cdStd> Coding standard for Decimal or hex
connection scope equivalent of 2 bits.
selection IE
Definition: UNI 4.0 [5]
2ビット選択IE DefinitionのDecimalか十六進法接続範囲同等物の<cdStd>Coding規格: UNI4.0[5]
<conScpTyp> Type of connection scope Decimal or hex
Definition: UNI 4.0 [5] equivalent of 4 bits
接続範囲Decimalか十六進法Definitionの<conScpTyp>Type: 4ビットのUNI4.0[5]同等物
Kumar & Mostafa Standards Track [Page 87] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[87ページ]。
<conScpSel> Connection scope selection Decimal or hex
Definition: UNI 4.0 [5] equivalent of 8 bits
<conScpSel>Connection範囲の選択Decimalか十六進法Definition: 8ビットのUNI4.0[5]同等物
<cacheEnable> Enable SVC caching String values: "on",
"off"
String値をキャッシュする<cacheEnable>Enable SVC: "on"、“off"
<cacheTimer> Timer for cached SVC Decimal or hex equivalent
deletion of 32-bit field
32ビットの分野のキャッシュされたSVC Decimalか十六進法の同等な削除のための<cacheTimer>Timer
<bearerSigIEType> Bearer Signaling IE Type 2 hex digits
<bearerSigIEType>Bearer Signaling IE Type2十六進法ケタ
<bearerSigIELng> Bearer Signaling IE Length 1-4 hex digits
<bearerSigIELng>Bearer Signaling IE Length1-4十六進法ケタ
<bearerSigIEVal> Bearer Signaling IE Value Even number of hex
digits, 2-512
十六進法ケタ、2-512の<bearerSigIEVal>Bearer Signaling IE Value Even番号
<appClass> Application String values:
specification "itu_h323c","af83",
"AAL5_SSCOP",
"itu_i3661_unassured",
"itu_i3661_assured",
"itu_i3662",
"itu_i3651", "itu_i3652",
"itu_i3653", "itu_i3654",
"FRF5", "FRF8","FRF11",
"itu_h2221"
<appClass>Application String値: 仕様「itu_h323c」、「af83"、「AAL5_SSCOP」、「イツー_i3661_は非保証した」「イツー_i3661_は保証した」「_イツーi3662」、「_イツーi3651」、「_イツーi3652」、「_イツーi3653」「イツー_i3654」、「FRF5"、"FRF8""、FRF11"、「itu_h2221」」
<oui> Organizationally 1 to 6 hex digits
Unique Identifier
<oui>Organizationally1〜6十六進法ケタUnique Identifier
<appId> Application Identifier 1 to 8 digits
<appId>Application Identifier1〜8ケタ
<cbrRate> CBR Rate Two hex digits.
<cbrRate>CBR Rate Two十六進法ケタ。
<sbc> Subchannel Count T1: Decimal integer 1-24
or hex equivalent
E1: Decimal integer 1-31
or hex equivalent
<sbc>サブチャネルカウントT1: 10進整数1-24か十六進法同等なE1: 10進整数1-31か十六進法同等物
<clkrec> Clock Recovery String values:
Method "NULL", "SRTS",
"ADAPTIVE"
<clkrec>Clock Recovery String値: 「SRTS」の、そして、「適応型」の方法「ヌル」
<fecEnable> Forward Error String values:
Correction Enable "NULL", "LOSS_SENSITIVE"
"DELAY_SENSITIVE"
<fecEnable>Forward Error String値: 修正が可能にする、「ヌル」で、「損失_敏感である」、「遅れ_敏感」
Kumar & Mostafa Standards Track [Page 88] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[88ページ]。
<partialFill> Partial Fill Decimal integer 1-48
or hex equivalent
<partialFill>Partial Fill Decimal整数1-48か十六進法同等物
<structureEnable> Structure Present String values:
"on", "off"
<structureEnable>Structure Present String値: "on"、“off"
<blksz> Block Size Decimal or hexadecimal
equivalent of 16 bits
16ビットの<blksz>Block Size Decimalか16進同等物
<cpcs> Maximum AAL5: Decimal or hex
CPCS SDU size equivalent of 16 bits
AAL2: 45 or 64, decimal
or hex representation
<のcpcsの>の最大のAAL5: 16ビットのAAL2の小数か十六進法CPCS SDUサイズ同等物: 45、64、小数または十六進法表現
<cidLowerLimit> AAL2 CID lower limit Decimal integer 8-255
or hex equivalent
<cidLowerLimit>AAL2 CID下限Decimal整数8-255か十六進法同等物
<cidUpperLimit> AAL2 CID upper limit Decimal integer 8-255
or hex equivalent
<cidUpperLimit>AAL2 CID上限Decimal整数8-255か十六進法同等物
<timerCU> Timer, combined use Integer decimal; range
(microseconds) determined by application.
Use decimal equivalent of
32 bits.
<timerCU>Timer、結合されて、Integerを使用してください、小数。 アプリケーションで断固としていた状態で及んでください(マイクロセカンド)。 32ビットの10進同等物を使用してください。
<simplifiedCPS> Simplified CPS [52] String values:
"on", "off"
<simplifiedCPS>Simplified CPS[52]は値を結びます: "on"、“off"
<fSDUrate> Forward SDU rate Decimal equivalent of
(bits per second) 24-bit field
(bps)24ビットの分野の<fSDUrate>Forward SDUレートDecimal同等物
<bSDUrate> Backward SDU rate Decimal equivalent of
(bits per second) 24-bit field
(bps)24ビットの分野の<bSDUrate>Backward SDUレートDecimal同等物
<ted> Transmission Error String values:
Detection Enable "on", "off"
<ted>Transmission Error String値: 検出は“on"、“off"を有効にします。
<rastimer> SSSAR reassembly Integer decimal,
(microseconds) Range determined by
application. Use decimal
equivalent of 32 bits.
アプリケーションによる10進<rastimer>SSSAR reassembly Integer(マイクロセカンド)特定された範囲。 32ビットの10進同等物を使用してください。
<fsssar> Maximum SSSAR-SDU Decimal 1- 65568
size, forward or hex equivalent
direction
<fsssar>Maximum SSSAR-SDU Decimal1- 65568サイズ、フォワードまたは十六進法同等物指示
Kumar & Mostafa Standards Track [Page 89] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[89ページ]。
<bsssar> Maximum SSSAR-SDU Decimal 1- 65568
size, backward or hex equivalent
direction
<bsssar>Maximum SSSAR-SDU Decimal1- 65568サイズ、後方の、または、十六進法同等な指示
<fsscopsdu> Maximum SSCOP-SDU Decimal 1- 65528
size, forward or hex equivalent
direction
<fsscopsdu>Maximum SSCOP-SDU Decimal1- 65528サイズ、フォワードまたは十六進法同等物指示
<bsscopsdu> Maximum SSCOP-SDU Decimal 1- 65528
size, backward or hex equivalent
direction
<bsscopsdu>Maximum SSCOP-SDU Decimal1- 65528サイズ、後方の、または、十六進法同等な指示
<fsscopuu> Maximum SSCOP-UU Decimal 1- 65524
field size, forward or hex equivalent
direction
<fsscopuu>Maximum SSCOP-UU Decimal1- 65524分野サイズ、フォワードまたは十六進法同等物指示
<bsscopuu> Maximum SSCOP-UU Decimal 1- 65524
field size, backward or hex equivalent
direction
<bsscopuu>Maximum SSCOP-UU Decimal1- 65524分野サイズ、後方の、または、十六進法同等な指示
<sap> Service Access String values:
Point "AUDIO", "MULTIRATE"
<体液>Service Access String値: ポイント「オーディオ」、「多速度」
<circuitMode> Circuit Mode String values:
Enable "on", "off"
<circuitMode>Circuit Mode String値: “on"、“off"を有効にしてください。
<frameMode> Frame Mode String values:
Enable "on", "off"
<frameMode>Frame Mode String値: “on"、“off"を有効にしてください。
<faxDemod> Fax Demodulation String values:
Enable "on", "off"
<faxDemod>ファックスDemodulation String値: “on"、“off"を有効にしてください。
<cas> Enable CAS transport String values:
via Type 3 packets "on", "off"
<cas>Enable CASはString値を輸送します: Type3パケット“on"、“off"を通して
<dtmf> Enable DTMF transport String values:
via Type 3 packets "on", "off"
<dtmf>Enable DTMFはString値を輸送します: Type3パケット“on"、“off"を通して
<mfall> Enable MF transport String values:
via Type 3 packets "on", "off"
<mfall>Enable MFはString値を輸送します: Type3パケット“on"、“off"を通して
<mfr1> Enable MF (R1) String values:
transport via "on", "off"
Type 3 packets
<mfr1>Enable MF(R1)は値を結びます: “on"を通した輸送、“off" Type3パケット
<mfr2> Enable MF (R2) String values:
transport via "on", "off"
Type 3 packets
<mfr2>Enable MF(R2)は値を結びます: “on"を通した輸送、“off" Type3パケット
Kumar & Mostafa Standards Track [Page 90] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[90ページ]。
<PCMencoding> PCM encoding String values:
"PCMA", "PCMU"
String値をコード化する<PCMencoding>PCM: "PCMA"、"PCMU"
<fmaxFrame> Maximum length of a Decimal or hex
frame mode data unit, equivalent of
forward direction 16-bit field
Decimalの<fmaxFrame>Maximumの長さか十六進法フレーム方式データ単位、順方向の16ビットの分野の同等物
<bmaxFrame> Maximum length of a -ditto-
frame mode data unit,
backward direction
aフレーム方式を写しているデータ単位、逆方向の<bmaxFrame>Maximumの長さ
<silenceSuppEnable> Silence suppression String values:
Enable "on", "off"
<silenceSuppEnable>Silence抑圧String値: “on"、“off"を有効にしてください。
<silenceTimer> Kick-in timer Decimal or hex representation
for silence of 16-bit field
suppression
16ビットの分野抑圧の沈黙の<silenceTimer>中のKickタイマDecimalか十六進法表現
<suppPref> Preferred Silence String values:
Suppression Method "standard", "custom"
<suppPref>Preferred Silence String値: 抑圧方法「規格」、「習慣」
<sidUse> SID Use String values:
Method "No SID", "Fixed Noise",
"Sampled Noise"
<sidUse>SID Use String値: 方法「雑音は修理されていた」「SIDがありません」「抽出された雑音」
<fxnslevel> Fixed Noise Decimal or hex representation
Level of a 7-bit field
7ビットの分野の<fxnslevel>Fixed Noise Decimalか十六進法表現Level
<ecanEnable> Enable Echo String values:
Cancellation "on", "off"
<ecanEnable>Enable Echo String値: キャンセル“on"、“off"
<ecanType> Type of Echo String values:
Cancellation "G165", "G168"
Echo String値の<ecanType>Type: キャンセル"G165"、"G168"
<gcEnable> Enable Gain String values:
Control "on", "off"
<gcEnable>Enable Gain String値: コントロール“on"、“off"
<gcLvl> Level of inserted Decimal or hex equivalent
Loss of 16-bit field
挿入されたDecimalの<gcLvl>Levelか16ビットの分野の十六進法の同等なLoss
<aal2transport> AAL2 transport Values listed in Table 1
that begin with the string
"AAL2"
ストリング"AAL2""と共に始まるTable1に記載された<aal2transport>AAL2輸送Values
<uuiCodeRange> UUI code range Decimal integer 0-15
<uuiCodeRange>UUIコード範囲Decimal整数0-15
Kumar & Mostafa Standards Track [Page 91] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[91ページ]。
<encodingName> Encoding name String values:
"PCMG", "SIDG", "SID729",
any value from column 2
of Table 2
<encodingName>EncodingはString値を命名します: テーブル2に関するコラム2からの"PCMG"、"SIDG"、"SID729"、どんな値
<packetLength> Packet length Decimal integer 0-45
<packetLength>Packet長さのDecimal整数0-45
<packetTime> Packetization Decimal integer 1-65,536
Interval in microsec.
マイクロセカンドの<packetTime>Packetization Decimal整数1-65,536Interval。
<fxIncl> Facsimile included String values: "on", "off"
<fxIncl>FacsimileはString値を含んでいました: "on"、“off"
<serviceType> Service type String values: "v", "d", "f",
"df", "all"
<serviceType>ServiceはString値をタイプします: 「v」、「d」「f」、"df"「すべて」
<q7655scc> Contents of the Even number of hex
Q.765.5 Single digits (4-32)
Codec IE
十六進法Q.765.5 Singleケタ(4-32)コーデックIEのEven番号の<q7655scc>Contents
<isupUsi> ISUP User Service Even number of hex digits
Information (4-24)
十六進法ケタ情報の<isupUsi>ISUP User Service Even番号(4-24)
<uiLayer1Prot> User Information Two hex digits
Layer 1 Protocol
<uiLayer1Prot>User情報Two十六進法ケタLayer1プロトコル
<chainPointer> Chain pointer String values: "NEXT",
"PREVIOUS", "NULL"
<chainPointer>ChainポインタString値: 「次」で、「前で」、「ヌルです」。
<rtcpPortNum> RTCP port number for Odd decimal in range 1,024 to
H.323 Annex C 65,535.
applications Preferred: Odd number in
the range 49,152 to 65,535
<rtcpPortNum>RTCPは範囲1,024でH.323 Annex C65,535アプリケーションPreferredに10進でOddの数を移植します: 範囲4万9152〜65,535の奇数
<rtcpIPaddr> IP address for receipt Dotted decimal, 7-15 chars
of RTCP packets
RTCPパケットの領収書Dotted10進の7-15の雑用のための<rtcpIPaddr>IPアドレス
Kumar & Mostafa Standards Track [Page 92] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[92ページ]。
7. Examples of ATM session descriptions using SDP
7. SDPを使用するATMセッション記述に関する例
An example of a complete AAL1 session description in SDP is:
SDPの完全なAAL1セッション記述に関する例は以下の通りです。
v=0
o=- A3C47F21456789F0 0 ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
s=-
c=ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
t=0 0
m=audio $ AAL1/AVP 18 0 96
a=atmmap:96 X-G727-32
a=eecid:B3D58E32
0 0v=0o=A3C47F21456789F0 0 ATM NSAP47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00 s=c=ATM NSAP47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00t=mの=オーディオのAAL1/AVP18 0ドル96a=atmmap: 96X-G727-32 a=eecid: B3D58E32
An example of a complete AAL2 session description in SDP is:
SDPの完全なAAL2セッション記述に関する例は以下の通りです。
v=0
o=- A3C47F21456789F0 0 ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
s=-
c=ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
t=0 0
m=audio $ AAL2/ITU 8 AAL2/custom 100 AAL2/ITU 1
a=eecid:B3E32
AAL2/ITU1オーディオのAAL2/ITU8ドルのAAL2/習慣100 0 0v=0o=A3C47F21456789F0 0 ATM NSAP47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00 s=c=ATM NSAP47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00t=m=a=eecid: B3E32
The AAL2 session descriptor below is the same as the one above except that it states an explicit preference for a voice codec, a voiceband data codec and a voiceband fax codec. Further, it defines the profile AAL2/custom 100 rather than assume that the far-end is cognizant of the elements of this profile.
音声コーデック、voicebandデータコーデック、およびvoicebandファックスコーデックのための明白な優先を述べるのを除いて、以下のAAL2セッション記述子は上のものと同じです。さらに、遠端がこのプロフィールの要素を認識していると仮定するよりそれはむしろプロフィールAAL2/習慣100を定義します。
v=0
o=- A3C47F21456789F0 0 ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
s=-
c=ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
t=0 0
m=audio $ AAL2/ITU 8 AAL2/custom 100 AAL2/ITU 1
a=eecid:B3E32
a=profileDesc:AAL2/custom 100 0-7 PCMG 40 5000 0-7 SIDG 1
5000 8-15 G726-32 40 10000 8-15 SIDG 1 5000
a=vsel:G726-32 40 10000
a=dsel:off PCMU - -
a=fsel:G726-32 40 10000
AAL2/ITU1オーディオのAAL2/ITU8ドルのAAL2/習慣100 0 0v=0o=A3C47F21456789F0 0 ATM NSAP47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00 s=c=ATM NSAP47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00t=m=a=eecid: B3E32 a=profileDesc: AAL2/習慣100 0-7PCMG40 5000 0-7SIDG1 5000 8-15G726-32 40 10000 8-15SIDG1 5000a=vsel: G726-32 40 10000 a=dsel: PCMUで--、--、a=fsel: G726-32 40 10000
Kumar & Mostafa Standards Track [Page 93] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[93ページ]。
An example of an SDP session descriptor for an AAL5 switched virtual circuit for delivering MPEG-2 video:
MPEG-2ビデオを届けるためのAAL5交換仮想回路のためのSDPセッション記述子に関する例:
v=0
o=- A3C47F21456789F0 0 ATM NSAP
47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
s=-
c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
t=0 0
m=video $ AAL5/ITU 33
a=eecid:B3E32
a=aalType:AAL5
a=bearerType:SVC on
a=atmTrfcDesc:f 0+1 7816 - - - - - off -
a=atmTrfcDesc:b 0+1 0 - - - - - on -
a=cpsSDUsize:f 20680
a=aalApp:itu_h2221 - -
0 0v=0o=A3C47F21456789F0 0 ATM NSAP47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00 s=c=ATM NSAP47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00t=mはa=atmTrfcDesc: f0+1 7816でAAL5/ITU33a=eecid: ビデオ$B3E32 a=aalType:AAL5 a=bearerType:SVCと等しいです--、--、--、--、下に、--a=atmTrfcDesc: b0+1 0----------オン--、a=cpsSDUsize: f20680a=aalApp: itu_h2221--、-
An example of an SDP session descriptor for an AAL5 permanent virtual circuit for delivering MPEG-2 video:
MPEG-2ビデオを届けるためのAAL5相手固定接続のためのSDPセッション記述子に関する例:
v=0
o=- A3C47F21456789F0 0 ATM - -
s=-
c=ATM - -
t=0 0
m=video PORT-$/VPI-0/VCI-$ AAL5/ITU 33
a=bearerType:PVC -
a=atmTrfcDesc:f 0+1 7816 - - - - - off -
a=atmTrfcDesc:b 0+1 0 - - - - - on -
a=cpsSDUsize:f 20680
a=aalApp:itu_h2221 - -
0 0--s=-c=ATM----t=mがAAL5/ITU33a=bearerType: ビデオPORT-$/VPI-0/VCI-$PVCと等しいという(a=atmTrfcDesc: f0+1 7816)v=0o=-A3C47F21456789F0 0 ATM------オフ(a=atmTrfcDesc: b0+1 0)--、--、--、--、オン(a=cpsSDUsize: f20680a=aalApp: itu_h2221)である、-
8. Security Considerations
8. セキュリティ問題
8.1 Bearer Security
8.1 運搬人セキュリティ
At present, standard means of encrypting ATM and AAL2 bearers are not conventionalized in the same manner as means of encrypting RTP payloads. Nor has the authentication of ATM or AAL2 bearer signaling.
現在のところ、ATMとAAL2運搬人をコード化する標準の手段はRTPペイロードをコード化する手段と同じ方法で慣例化されません。 ATMかAAL2運搬人シグナリングの認証もそうしません。
The SDP encryption key line (k=) defined in RFC 2327 can be used to represent the encryption key and the method of obtaining the key. In the ATM and AAL2 contexts, the term 'bearer' can include 'bearer signaling' as well as 'bearer payloads'.
暗号化キーとキーを入手する方法を表すのにRFC2327で定義されたSDPの暗号化の主要な線(k=)は使用できます。 ATMとAAL2文脈では、'運搬人'という用語は'運搬人ペイロード'と同様に'運搬人シグナリング'を含むことができます。
Kumar & Mostafa Standards Track [Page 94] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[94ページ]。
8.2 Security of the SDP description
8.2 SDP記述のセキュリティ
The SDP session descriptions might originate in untrusted areas such as equipment owned by end-subscribers or located at end-subscriber premises. SDP relies on the security mechanisms of the encapsulating protocol or layers below the encapsulating protocol. Examples of encapsulating protocols are the Session Initiation Protocol (SIP), MGCP and Multimedia Gateway Control Protocol (MEGACO). No additional security mechanisms are needed. SIP, MGCP and MEGACO can use IPSec authentication as described in RFC 1826 [Ref. 27]. IPSec encryption can be optionally used with authentication to provide an additional, potentially more expensive level of security. IPSec security associations can be made between equipment located in untrusted areas and equipment located in trusted areas through configured shared secrets or the use of a certificate authority.
SDPセッション記述は終わり加入者によって所有されているか、または終わり加入者構内に位置する設備などの信頼されていない領域で起こるかもしれません。 SDPが要約プロトコルのセキュリティー対策を当てにするか、または要約の下における層は議定書を作ります。 要約プロトコルに関する例は、Session Initiationプロトコル(SIP)と、MGCPとMultimediaゲートウェイControlプロトコル(MEGACO)です。 追加担保メカニズムは全く必要ではありません。 SIP、MGCP、およびMEGACOはRFC1826で説明されるようにIPSec認証を使用できます。[審判。 27]. 追加していて、潜在的により高価なレベルのセキュリティを提供するのに認証と共にIPSec暗号化を任意に使用できます。 信頼されていない領域に位置する設備と構成された共有秘密キーを通して信じられた領域に位置する設備か認証局の使用の間でIPSecセキュリティ協会を作ることができます。
9. ATM SDP Grammar
9. 気圧SDP文法
This appendix provides an Augmented BNF (ABNF) grammar for the ATM conventions for SDP. ABNF is defined in rfc2234. This is not a complete ABNF description of SDP. Readers are referred to [1] for an ABNF description of the SDP base line protocol, and to rfc2848, rfc2543, rfc2045 and rfc2326 for application-specific conventions for SDP use. For case conventions, see section 2.4.
この付録はSDPのためにAugmented BNF(ABNF)文法をATMコンベンションに提供します。 ABNFはrfc2234で定義されます。 これはSDPの完全なABNF記述ではありません。 読者はSDP使用のためのアプリケーション特有のコンベンションのためのSDPベースラインプロトコルのABNF記述のための[1]、rfc2848、rfc2543、rfc2045、およびrfc2326を参照されます。 ケースコンベンションに関しては、セクション2.4を見てください。
; Constant definitions
; 一定の定義
safe = alpha-numeric / "'" / "-" / "." / "/" / ":" / "?" / DQUOTE /
"#" / "$" / "&" / "*" / ";" / "=" / "@" / "[" / "]" / "^" / "_" /
"`" / "{" / "|" / "}" / "+" / "~"
DQUOTE = %x22 ; double quote
alpha-numeric = ALPHA / DIGIT
ALPHA = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" / "j" /
"k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" / "s" / "t" /
"u" / "v" / "w" / "x" / "y" / "z" /
"A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" /
"K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" / "T" /
"U" / "V" / "W" / "X" / "Y" / "Z"
DIGIT = "0" / POS-DIGIT
POS-DIGIT = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
hex-prefix = "0" ("x" / "X")
HEXDIG = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" /
"A" / "B" / "C" / "D" / "E" / "F"
space = %d32
EOL = (CR / LF / CRLF) ; as per Megaco RFC
CR = %d13
LF = %d10
金庫はアルファベット数字式/「'「/「-」/」'」と等しいです。 / "/" / ":" / "?" 「/ DQUOTE /「#」 /「$」/“&"/「*」/」」 /「=」/"@"/「[「/」]」/"^"/"_"/、「'、「/、「「/、「| 」 /」、」 /「+ 」 /「~」DQUOTE=%x22」、' double quote alpha-numeric = ALPHA / DIGIT ALPHA = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" / "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / "Y" / "Z" DIGIT = "0" / POS-DIGIT POS-DIGIT = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" hex-prefix = "0" ("x" / "X") HEXDIG = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" / "A" / "B" / "C" / "D" / "E" / "F" space = %d32 EOL = (CR / LF / CRLF) ; Megaco RFC CR=%d13 LF=%d10に従って
Kumar & Mostafa Standards Track [Page 95] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[95ページ]。
decimal-uchar = DIGIT
/ POS-DIGIT DIGIT
/ ("1" 2*(DIGIT))
/ ("2" ("0"/"1"/"2"/"3"/"4") DIGIT)
/ ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))
10進ucharがDIGIT / POS-DIGIT DIGIT /と等しい、(「1インチ2*(ケタ)/、(「2インチ、(「0インチ/」の1インチ/「2インチ/」3インチ/、「4インチ) ケタ) /」("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))
generic-U8 = (hex-prefix hex-U8) / decimal-uchar generic-U12 = (hex-prefix hex-U12) / 1*4 (DIGIT) generic-U16 = (hex-prefix hex-U16) / 1*5(DIGIT) generic-U24 = (hex-prefix hex-U24) / 1*8(DIGIT) generic-U32 = (hex-prefix hex-U32) / 1*10(DIGIT) hex-U8 = 1*2(HEXDIG) hex-U12 = 1*3(HEXDIG) hex-U16 = 1*4(HEXDIG) hex-U24 = 1*6(HEXDIG) hex-U32 = 1*8(HEXDIG) generic-U8-or-null = generic-U8 / "-" generic-U12-or-null = generic-U12 / "-" generic-U16-or-null = generic-U16 / "-" generic-U24-or-null = generic-U24 / "-" generic-U32-or-null = generic-U32 / "-" decimal-U8-or-null = decimal-uchar / "-" decimal-U12-or-null = 1*4(DIGIT) / "-" decimal-U16-or-null = 1*5(DIGIT) / "-" decimal-U24-or-null = 1*8 (DIGIT) / "-" decimal-U32-or-null = 1*10(DIGIT) / "-" on-off-or-null = "on" / "off" / "-"
generic-U8 = (hex-prefix hex-U8) / decimal-uchar generic-U12 = (hex-prefix hex-U12) / 1*4 (DIGIT) generic-U16 = (hex-prefix hex-U16) / 1*5(DIGIT) generic-U24 = (hex-prefix hex-U24) / 1*8(DIGIT) generic-U32 = (hex-prefix hex-U32) / 1*10(DIGIT) hex-U8 = 1*2(HEXDIG) hex-U12 = 1*3(HEXDIG) hex-U16 = 1*4(HEXDIG) hex-U24 = 1*6(HEXDIG) hex-U32 = 1*8(HEXDIG) generic-U8-or-null = generic-U8 / "-" generic-U12-or-null = generic-U12 / "-" generic-U16-or-null = generic-U16 / "-" generic-U24-or-null = generic-U24 / "-" generic-U32-or-null = generic-U32 / "-" decimal-U8-or-null = decimal-uchar / "-" decimal-U12-or-null = 1*4(DIGIT) / "-" decimal-U16-or-null = 1*5(DIGIT) / "-" decimal-U24-or-null = 1*8 (DIGIT) / "-" decimal-U32-or-null = 1*10(DIGIT) / "-" on-off-or-null = "on" / "off" / "-"
; ABNF definition of SDP with ATM conventions
; ATMコンベンションに伴うSDPのABNF定義
SDP-infoset = 1*(announcement)announcement = proto-version origin-field session-name-field information-field uri-field email-fields phone-fields connection-field bandwidth-fields time-fields key-field attribute-fields media-descriptions
SDP-infosetは1*(発表)発表=proto-バージョン起源分野セッション名前欄情報フィールドuri-分野メール分野電話分野接続分野帯域幅分野時間分野キーフィールド属性分野メディア記述と等しいです。
proto-version = ["v=" 1*4(DIGIT) EOL] ; use "v=0" for ATM SDP
proto-バージョンは[「v=」1*4(DIGIT)EOL]と等しいです。 「ATM SDPのためのv=0インチ」を使用してください。
origin-field = ["o=" username space sess-id space sess-version space net-type-addr EOL]
起源分野=[「o=」ユーザ名スペースsess-イドスペースsess-バージョンスペースのネットのタイプaddr EOL]
username = 1* safe ; for ATM use "-"
ユーザ名は1*金庫と等しいです。 ATMには、「-」を使用してください。
sess-id = (1*32 DIGIT) / (hex-prefix 1*32 HEXDIG) sess-version = (1*10 DIGIT) / (hex-prefix 1*8 HEXDIG)
sess-イド=(1*32DIGIT)/(十六進法接頭語1*32HEXDIG)sess-バージョン=(1*10DIGIT)/(十六進法接頭語1*8HEXDIG)
net-type-addr= nettype space addrtype-addr
ネットのタイプaddr= nettypeスペースaddrtype-addr
netttype = "ATM" / "IN" / "TN" / "-" / "$"
netttypeは「気圧」/「IN」/「テネシー」/「-」/「$」と等しいです。
Kumar & Mostafa Standards Track [Page 96] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[96ページ]。
; Other nettype values may be defined in the future in other documents ; Validity of nettype and addrtype-addr combination to be checked at ; application level, not protocol syntax level
; 他のnettype値は将来、他のドキュメントで定義されるかもしれません。 チェックされるnettypeとaddrtype-addr組み合わせの正当性。 プロトコル構文レベルではなく、アプリケーションレベル
addrtype-addr = atm-addrtype-addr / ip-addrtype-addr / tn-addrtype-addr ; ip-addrtype-addr per rfc2327 ; tn-addrtype-addr per rfc2848
addrtype-addrは気圧-addrtype-addr/ip-addrtype-addr/tn-addrtype-addrと等しいです。 1rfc2327あたりのip-addrtype-addr。 1rfc2848あたりのtn-addrtype-addr
; ATM address definition
; ATMアドレス定義
atm-addrtype-addr = atm-nsap-addr / atm-e164-addr / atm-alias-addr
気圧-addrtype-addrは気圧別名気圧気圧-nsap-addr/e164-addr/addrと等しいです。
atm-nsap-addr = ("NSAP" / "-" / "$") space (nsap-addr / "-" / "$")
atm-e164-addr = ("E164" / "-" / "$") space (e164-addr / "-" / "$")
atm-alias-addr = ("GWID" / "ALIAS" / "-" / "$") space (alias-addr /
"-" / "$")
気圧..スペース..気圧..スペース..気圧..アリア..別名..スペース(別名-addr/「-」/「$」)
nsap-addr = 2(HEXDIG) "." 9(4(HEXDIG) ".") 2(HEXDIG)
「nsap-addr=2(HEXDIG)」、」 「9、(4(HEXDIG)、」、」、)、2(HEXDIG)
e164-addr = 1*15 (DIGIT) alias-addr = 1*32(alpha-numeric / "-" / "." / "_")
e164-addrは1*15(DIGIT)別名-addr=1*32と等しいです。「(アルファベット数字式/「-」/」 . 」 /"_")
session-name-field = ["s=" text EOL] ; for ATM use "s=-"
text = byte-string
byte-string = 1*(byte-string-char) ; definition per rfc2327
byte-string-char = %x01-09/ %x0B/ %x0C/ %x0E-FF ; all ASCII except
NUL, CR & LF
; Definitions of information-field, uri-field, email-fields,
; phone-fields per rfc2327. These fields are omitted in
; ATM SDP descriptions. If received, they are ignored in the ATM
; context
セッション名前欄は[「s=」テキストEOL]と等しいです。 ATM使用、「s、= -」 テキストは1バイトストリングバイトストリング=*(バイトストリング炭)と等しいです。 rfc2327バイトストリング炭あたりの定義=%x01-09/%x0B/%x0C/%x0E-FF。 NUL、CR、およびLFを除いたすべてのASCII。 情報フィールドの定義、uri-分野、メール分野。 1rfc2327あたりの電話分野。 これらの分野は中で省略されます。 ATM SDP記述。 受け取るなら、ATMでそれらを無視します。 文脈
connection-field = ["c=" c-net-type-addr]
接続分野=[「c=」cネットのタイプaddr]
; connection-field required, not optional, in ATM
; 任意であるのではなく、ATMで必要な接続分野
c-net-type-addr = nettype space c-addrtype-addr
c-addrtype-addr = atm-addrtype-addr / c-ip-addrtype-addr /
tn-addrtype-addr
nettype cネットのタイプaddr=スペースc-addrtype-addr c-addrtype-addrは気圧-addrtype-addr/c-ip-addrtype-addr/tn-addrtype-addrと等しいです。
; atm-addrtype-addr defined above
; 上で定義された気圧-addrtype-addr
; c-ip-addrtype-addr per rfc2327 ; difference in address usage between 'o' and 'c' lines per rfc2327
; 1rfc2327あたりのc-ip-addrtype-addr。 1rfc2327あたりの'o'と'c'線の間のアドレス用法の違い
; tn-addrtype-addr per rfc2848
; 1rfc2848あたりのtn-addrtype-addr
bandwidth-fields = *("b=" bwtype ":" bandwidth EOL)
帯域幅分野は*と等しいです。「(「bは」 bwtypeと等しい」: 」 帯域幅EOL)
Kumar & Mostafa Standards Track [Page 97] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[97ページ]。
bwtype = 1*(alpha-numeric) bandwidth = 1*(DIGIT)
1*(アルファベット数字式)bwtype=帯域幅は1*と等しいです。(ケタ)
time-fields = *( "t=" start-time space stop-time
*(EOL repeat-fields) EOL)
[zone-adjustments EOL]
start-time = time / "0"
stop-time = time / "0" ; always "0" in ATM
time = POS-DIGIT 9*(DIGIT) ; same as rfc2327
; repeat-fields and zone-adjustments per rfc2327, not used in ATM
時間分野=*(「t=」開始時刻スペース停止時間の*(EOL反復分野)EOL)[ゾーン調整EOL]開始時刻=時間/、「0インチ停止時間= /「0インチ」調節してください。 いつも、「気圧時間における0インチはPOS-ケタ9*(ケタ)と等しいです」。 rfc2327と同じ。 1ATMで使用されないrfc2327あたりの反復分野とゾーン調整
; Definition of optional key-field per rfc2327 ;
; 1rfc2327あたりの任意のキーフィールドの定義。
attribute-fields = *("a=" attribute EOL)
属性分野は*と等しいです。(「=」属性EOL)
; SDP descriptors for ATM do not have session-level media attribute ; lines. If these are provided, they should be ignored.
; ATMのためのSDP記述子には、セッションレベルメディア属性がありません。 線。 これらを提供するなら、それらを無視するべきです。
media-descriptions = *(media-description)
media-description = media-field information-field *(connection-field)
bandwidth-fields key-field attribute-fields
メディア記述=*(メディア記述)メディア記述はメディア分野情報フィールド*(接続分野)帯域幅分野キーフィールド属性分野と等しいです。
; Definitions of information-field per RFC 2327. These fields are ; omitted in ATM SDP descriptions. If received, they are ignored in ; the ATM context ; ; In ATM, the connection-field is used in media-description to indicate ; the IP address associated with the RTCP control protocol in H.323.C ; applications. In this case, the connection field is per the RFC 2327 ; definition for IP v4-based connections. Otherwise, it is not used in ; media-description. If received as part of media-description, ; it is ignored. ; ; Definition of optional bandwidth-fields as above. : Definition of optional key-field as in RFC 2327
; RFC2327あたりの情報フィールドの定義。 これらの分野はそうです。 ATM SDP記述では、省略されます。 受け取るなら、中でそれらを無視します。 ATM文脈。 ; ATMでは、接続分野は示すメディア記述に使用されます。 IPアドレスはH.323.CのRTCP制御プロトコルと交際しました。 アプリケーション。 この場合、接続分野がRFC2327単位であります。 IPのv4ベースの接続のための定義。 さもなければ、それは中で使用されません。 メディア記述。 メディア記述の一部として受け取るなら。 それは無視されます。 ; ; 上の任意の帯域幅分野の定義。 : RFC2327のような任意のキーフィールドの定義
media-field = rfc2327-media-field / rfc2848-media-field /
atm-media-field
; rfc2327-media-field and rfc2848-media-field defined in those rfc's
atm-media-field = "m=" media space vcId space transport-fmts EOL
; superset of rfc2327 definition
メディア分野は気圧メディアrfc2848メディアrfc2327メディア分野/分野/分野と等しいです。 メディアがさばくrfc2327とそれらで定義されたrfc2848メディア分野rfcの気圧メディア分野は「m=」メディアスペースvcIdスペース輸送-fmts EOLと等しいです。 rfc2327定義のスーパーセット
media = "audio" / "video" / "data" / "application" / "control" /
1*(alpha-numeric)
メディアは「オーディオ」/「ビデオ」/「データ」/「アプリケーション」/「コントロール」/1*と等しいです。(アルファベット数字式)
vcId = "$" / "-" / ex-vcci / (ex-vcci "/" ex-cid) /
(atm-type-addr-m "/" ex-vcci) /
「vcIdがvcciからの「$」/「-」//と等しい、(」 /を元の連れ合いと同じくらいvcciする、」 元のCid) /(」 気圧タイプaddr m」 /元のvcci)/
Kumar & Mostafa Standards Track [Page 98] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[98ページ]。
(atm-type-addr-m "/" ex-vcci "/" ex-cid) /
(ex-bcg "/" ex-vcci) / (ex-bcg "/" ex-vcci "/" ex-cid)
(ex-portid "/" ex-vpi "/" ex-vci) /
(ex-portid "/" ex-vpi "/" ex-vci "/" ex-cid) /
(ex-bcg "/" ex-vpi "/" ex-vci) /
(ex-bcg "/" ex-vpi "/" ex-vci "/" ex-cid) /
(ex-vpci "/" ex-vci) /
(ex-vpci "/" ex-vci "/" ex-cid) /
(atm-type-addr-m "/" ex-vpci "/" ex-vci) /
(atm-type-addr-m "/" ex-vpci "/" ex-vci "/" ex-cid)
(atm-type-addr-m "/" ex-vcci "/" ex-cid) / (ex-bcg "/" ex-vcci) / (ex-bcg "/" ex-vcci "/" ex-cid) (ex-portid "/" ex-vpi "/" ex-vci) / (ex-portid "/" ex-vpi "/" ex-vci "/" ex-cid) / (ex-bcg "/" ex-vpi "/" ex-vci) / (ex-bcg "/" ex-vpi "/" ex-vci "/" ex-cid) / (ex-vpci "/" ex-vci) / (ex-vpci "/" ex-vci "/" ex-cid) / (atm-type-addr-m "/" ex-vpci "/" ex-vci) / 「(」 気圧タイプaddr m」 /元のvpci、」 」 /元のvci、」 /、」、元のCid)
atm-type-addr-m = atm-nsap-addr-m / atm-e164-addr-m / atm-alias-addr-m atm-nsap-addr-m = ["NSAP-"] (nsap-addr / "$") atm-e164-addr-m = ["E164-"] (e164-addr / "$") atm-alias-addr-m = ["GWID-" / "ALIAS-"] (alias-addr / "$") ; The -m at the end indicates use in the media field ; Wildcarding rules different from ATM address on 'o' and 'c' lines
気圧タイプaddr m=気圧nsap-addr m/気圧e164-addr m/気圧別名addr m気圧nsap-addr m=["NSAP"](nsap-addr/「$」)気圧e164-addr-mが等しい、[「164E、-、」、]、(e164-addr/「$」)気圧別名addr mは["GWID"/「アリア」]と等しいです(別名-addr/「$」)。 終わりの-mはメディア分野で使用を示します。 'o'と'c'線に関するATMアドレスと異なった規則をWildcardingします。
ex-vcci = "VCCI-" vcci ex-cid = "CID-" cid ex-bcg = "BCG-" bcg ex-portid = "PORT-" portid ex-vpi = "VPI-" vpi ex-vci = "VCI-" vci ex-vpci = "VPCI-" vpci
"VCI"vciの元の"VPI"vpiの元の「ポート」portidの元の"BCG"bcgの元の"VCCI"vcciの元の元のvcci=Cid=「Cid」Cidの元のbcg=portid=vpi=vci=vpciは"VPCI"vpciと等しいです。
vcci = generic-U16 cid = generic-U8 bcg = generic-U8 portid = 1*32 (HEXDIG) vpi = generic-U12 vci = generic-U16 vpci = generic-U16
ジェネリック-U16vcci=Cidはジェネリック-U8 bcg=ジェネリック-U8 portid=1*32(HEXDIG)vpi=ジェネリック-U12 vci=ジェネリック-U16 vpci=ジェネリック-U16と等しいです。
transport-fmts = generic-transport-fmts / known-transport-fmts / "- -" generic-transport-fmts = generic-transport 1*(space fmt) generic-transport = 1*(alpha-numeric / "/") fmt = 1*(alpha-numeric)
「輸送-fmtsが知られている輸送一般的な輸送fmts/fmts/と等しい、「-、--、」 一般的な輸送fmtsが一般的な輸送1*(スペースfmt)一般的な輸送=1*と等しい(アルファベット数字式/、」 /、」、)、fmt=1*(アルファベット数字式)
known-transport-fmts = aal1-transport space aal1-fmt-list /
aal2-transport space aal2-fmt-list
*(space aal2-transport space aal2-fmt-list) /
aal5-transport space aal5-fmt-list /
rtp-transport space rtp-fmt-list /
tn-proto space tn-fmt-list /
h323c-proto "-"
h323c-proto = "H323c"
知られている輸送fmtsはh323c-proto rtp-輸送スペースrtp-fmt-リスト/tn-protoスペースtn-fmt-リスト/「-」h323c-プロト=aal2aal1-輸送スペースaal1-fmt-リスト/輸送スペースaal2-fmt-リスト*(スペースaal2-輸送スペースaal2-fmt-リスト)/aal5-輸送スペースaal5-fmt-リスト/"H323c"と等しいです。
Kumar & Mostafa Standards Track [Page 99] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[99ページ]。
; h323c-proto used for RTCP control ports in H.323 annex C
; applications. tn-proto and tn-fmt-list per rfc2848
; h323c-protoはRTCPにH.323別館Cの制御ポートを使用しました。 アプリケーション1rfc2848あたりのtn-protoとtn-fmt-リスト
aal1-transport = "AAL1" "/" aal1-transport-list
aal1-transport-list = "ATMF" / "ITU" / "custom" / "IEEE:" oui /
corporate-name
corporate-name = 1*(safe)
aal2-transport = "AAL2" "/" aal2-transport-list
aal2-transport-list = aal1-transport-list
aal5-transport = "AAL5" "/" aal5-transport-list
aal5-transport-list = aal1-transport-list
rtp-transport = "RTP" "/" rtp-transport-list
rtp-transport-list = "AVP"
「aal1-輸送は"AAL1""/と等しく」aal1輸送リストaal1輸送リスト="ATMF"/「ITU」/「習慣」/、「IEEE:」 「企業名oui/企業名=1*(金庫)aal2-輸送は」 "AAL2""/"AAL5""aal2輸送リストaal2輸送リスト=aal1輸送リストaal5-輸送=/」 aal5輸送リストaal5輸送リスト=aal1輸送リストrtp-輸送="RTP"と等しく」/」 rtp輸送リストrtp輸送リスト="AVP"
aal1-fmt-list = (payload-type *(space payload-type)) / "-"
payload-type = decimal-uchar
aal5-fmt-list = aal1-fmt-list
rtp-fmt-list = aal1-fmt-list
aal2-fmt-list = (profile *(space profile)) / "-"
profile = decimal-uchar
attribute-fields = *("a=" attribute EOL)
attribute = known-attribute / (generic-att-field ":" att-value) /
generic-att-field
generic-att-field = 1*(alpha-numeric)
att-value = byte-string
known-attribute = atm-attribute / PINT-attribute / rfc2327-attribute
; PINT-attribute as defined in rfc2848
; rfc2327 attribute as defined in that rfc
aal1-fmt-list = (payload-type *(space payload-type)) / "-" payload-type = decimal-uchar aal5-fmt-list = aal1-fmt-list rtp-fmt-list = aal1-fmt-list aal2-fmt-list = (profile *(space profile)) / "-" profile = decimal-uchar attribute-fields = *("a=" attribute EOL) attribute = known-attribute / (generic-att-field ":" att-value) / generic-att-field generic-att-field = 1*(alpha-numeric) att-value = byte-string known-attribute = atm-attribute / PINT-attribute / rfc2327-attribute ; rfc2848で定義されるPINT-属性。 そのrfcで定義されるrfc2327属性
atm-attribute =
"eecid" ":" eecid /
"aalType" ":" aalType /
"capability" ":" (asc / atc) space subtype /
"qosclass" ":" qosclass /
"bcob" ":" bcob space eetim /
"stc" ":" stc /
"upcc" ":" upcc /
"atmQOSparms" ":" directionFlag space cdvType
space acdv space ccdv space eetd space cmtd
space aclr /
"atmTrfcDesc" ":" directionFlag space clpLvl
space pcr space scr space mbs space cdvt space
mcr space mfs space fd space te /
"abrParms" ":" directionFlag space nrm space trm space cdf
space adtf /
"abrSetup" ":" ficr space bicr space ftbe space btbe space
crmrtt space frif space brif space frdf space brdf /
"bearertype" ":" bearerType space localInitiation /
「気圧属性="eecid"」:、」 「eecid/"aalType"」:、」 「aalType/「能力」」:、」 (asc / atc) 「スペース「副-タイプ」/"qosclass"」:、」 「qosclass/"bcob"」:、」 「bcobスペースeetim/"stc"」:、」 「stc/"upcc"」:、」 「upcc/「atmQOSparms」」:、」 「directionFlagスペースcdvTypeスペースacdvスペースccdvスペースeetdスペースcmtdスペースaclr/"atmTrfcDesc"」:、」 「directionFlagスペースclpLvlスペースpcrスペースscrスペースmbスペースcdvtスペースmcrスペースmfスペースfdスペースTe/「abrParms」」:、」 「directionFlagスペースnrmスペースtrmスペースcdfスペースadtf/"abrSetup"」:、」 「ficrスペースbicrスペースftbeスペースbtbeスペースcrmrttスペースfrifスペースbrifスペースfrdfスペースbrdf/"bearertype"」:、」 bearerTypeスペースlocalInitiation/
Kumar & Mostafa Standards Track [Page 100] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[100ページ]。
"lij" ":" sci space lsn /
"anycast" ":" atmGroupAddress space cdStd space
conScpTyp space conScpSel /
"cache" ":" cacheEnable space cacheTimer /
"bearerSigIE" ":" bearerSigIEType space
bearerSigIELng space bearerSigIEVal /
"aalApp" ":" appClass space oui space appId /
"cbrRate" ":" cbrRate /
"sbc" ":" sbc /
"clkrec" ":" clkrec /
"fec" ":" fecEnable /
"prtfl" ":" partialFill /
"structure" ":" structureEnable space blksz /
"cpsSDUsize" ":" directionFlag space cpcs /
"aal2CPS" ":" cidLowerLimit space cidUpperLimit space
timerCU space simplifiedCPS /
"aal2CPSSDUrate" ":" fSDUrate space bSDUrate /
"aal2sscs3661unassured" ":" ted space rastimer space fsssar
space bsssar /
"aal2sscs3661assured" ":" rastimer space fsssar space bsssar
space fsscopsdu space bsscopsdu space fsscopuu
space bsscopuu /
"aal2sscs3662" ":" sap space circuitMode space frameMode
space faxDemod space cas space dtmf space mfall space mfr1
space mfr2 space PCMencoding space fmaxFrame
space bmaxFrame /
"aal5sscop" ":" fsscopsdu space bsscopsdu space fsscopuu
space bsscopuu /
"atmmap" ":" payload-type space encoding-name /
"silenceSupp" ":" silenceSuppEnable space silenceTimer
space suppPref space sidUse space fxnslevel /
"ecan" ":" directionFlag space ecanEnable space ecanType /
"gc" ":" directionFlag space gcEnable space gcLvl /
"profileDesc" ":" aal2-transport space profile space
1*(profile-row) /
"vsel" ":" 1*(encoding-name space packet-length space
packet-time space) /
"dsel" ":" fxIncl space
1*(encoding-name space packet-length space
packet-time space) /
"fsel" ":" 1*(encoding-name space packet-length space
packet-time space) /
"onewaySel" ":" serviceType space directionFlag space
1*(encoding-name space packet-length space
packet-time space) /
「"lij"」:、」 「sciスペースlsn/"anycast"」:、」 「atmGroupAddressスペースcdStdスペースconScpTypスペースconScpSel/「キャッシュ」」:、」 「cacheEnableスペースcacheTimer/"bearerSigIE"」:、」 「bearerSigIETypeスペースbearerSigIELngスペースbearerSigIEVal/"aalApp"」:、」 「appClassスペースouiスペースappId/"cbrRate"」:、」 「cbrRate/"sbc"」:、」 「sbc/"clkrec"」:、」 「clkrec/"fec"」:、」 「fecEnable/"prtfl"」:、」 「partialFill/「構造」」:、」 「structureEnableスペースblksz/"cpsSDUsize"」:、」 「directionFlagスペースcpcs/「aal2CPS」」:、」 「cidLowerLimitスペースcidUpperLimitスペースtimerCUスペースsimplifiedCPS/"aal2CPSSDUrate"」:、」 「fSDUrateスペースbSDUrate/"aal2sscs3661unassured"」:、」 「tedスペースrastimerスペースfsssarスペースbsssar/"aal2sscs3661assured"」:、」 「rastimerスペースfsssarスペースbsssarスペースfsscopsduスペースbsscopsduスペースfsscopuuスペースbsscopuu/"aal2sscs3662"」:、」 「体液スペースcircuitModeスペースframeModeスペースfaxDemodスペースcasスペースdtmfスペースmfallスペースmfr1スペースmfr2スペースPCMencodingスペースfmaxFrameスペースbmaxFrame/"aal5sscop"」:、」 「fsscopsduスペースbsscopsduスペースfsscopuuスペースbsscopuu/"atmmap"」:、」 「ペイロードタイプ宇宙のコード化している名/"silenceSupp"」:、」 「silenceSuppEnableスペースsilenceTimerスペースsuppPrefスペースsidUseスペースfxnslevel/"ecan"」:、」 「directionFlagスペースecanEnableスペースecanType/"gc"」:、」 「directionFlagスペースgcEnableスペースgcLvl/"profileDesc"」:、」 「aal2-輸送スペースプロフィールスペース1*(プロフィール列)/"vsel"」:、」 「1*(コード化して名義のスペースパケット長スペースパケット時間スペース)/"dsel"」:、」 「fxInclスペース1*(コード化している名前スペースパケット長スペースパケット時間スペース)/"fsel"」:、」 「1*(コード化して名義のスペースパケット長スペースパケット時間スペース)/"onewaySel"」:、」 serviceTypeスペースdirectionFlagスペース1*(コード化している名前スペースパケット長スペースパケット時間スペース)/
"codecconfig" ":" q7655scc /
"isup_usi" ":" isupUsi /
「"codecconfig"」:、」 「q7655scc/「isup_usi」」:、」 isupUsi/
Kumar & Mostafa Standards Track [Page 101] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[101ページ]。
"uiLayer1_Prot" ":" uiLayer1Prot /
"chain" ":" chainPointer
「「uiLayer1_Prot」」:、」 「uiLayer1Prot/「チェーン」」:、」 chainPointer
eecid = 8 (HEXDIG) aalType = "AAL1" / "AAL2" / "AAL3/4" / "AAL5" / "USER_DEFINED_AAL" asc = "CBR" / "nrt-VBR" / "rt-VBR" / "UBR" / "ABR" / "GFR" atc = "DBR" / "SBR" / "ABT/IT" / "ABT/DT" / "ABR" subtype = decimal-U8-or-null qosclass = decimal-U8-or-null bcob = generic-U8 eetim = on-off-or-null stc = decimal-uchar upcc = decimal-uchar directionFlag = "f" / "b" / "fb" cdvType = "PP" / "2P" / "-" acdv = decimal-U32-or-null ccdv = decimal-U32-or-null eetd = decimal-U16-or-null cmtd = decimal-U16-or-null aclr = decimal-U8-or-null clpLvl = "0" / "0+1" / "-" pcr = decimal-U24-or-null scr = decimal-U24-or-null mbs = decimal-U16-or-null cdvt = decimal-U24-or-null mcr = decimal-U24-or-null mfs = decimal-U16-or-null fd = on-off-or-null te = on-off-or-null nrm = generic-U8-or-null trm = generic-U8-or-null cdf = generic-U8-or-null adtf = generic-U16-or-null ficr = decimal-U24-or-null bicr = decimal-U24-or-null ftbe = decimal-U24-or-null btbe = decimal-U24-or-null crmrtt = decimal-U24-or-null frif = 1*2 (DIGIT) brif = 1*2 (DIGIT) frdf = 1*2 (DIGIT) brdf = 1*2 (DIGIT) bearerType = "PVC" / "SVC" / "CID" localInitiation = on-off-or-null sci = generic-U8-or-null lsn = generic-U32-or-null atmGroupAddress = atm-type-addr cdStd = generic-U8-or-null
eecid = 8 (HEXDIG) aalType = "AAL1" / "AAL2" / "AAL3/4" / "AAL5" / "USER_DEFINED_AAL" asc = "CBR" / "nrt-VBR" / "rt-VBR" / "UBR" / "ABR" / "GFR" atc = "DBR" / "SBR" / "ABT/IT" / "ABT/DT" / "ABR" subtype = decimal-U8-or-null qosclass = decimal-U8-or-null bcob = generic-U8 eetim = on-off-or-null stc = decimal-uchar upcc = decimal-uchar directionFlag = "f" / "b" / "fb" cdvType = "PP" / "2P" / "-" acdv = decimal-U32-or-null ccdv = decimal-U32-or-null eetd = decimal-U16-or-null cmtd = decimal-U16-or-null aclr = decimal-U8-or-null clpLvl = "0" / "0+1" / "-" pcr = decimal-U24-or-null scr = decimal-U24-or-null mbs = decimal-U16-or-null cdvt = decimal-U24-or-null mcr = decimal-U24-or-null mfs = decimal-U16-or-null fd = on-off-or-null te = on-off-or-null nrm = generic-U8-or-null trm = generic-U8-or-null cdf = generic-U8-or-null adtf = generic-U16-or-null ficr = decimal-U24-or-null bicr = decimal-U24-or-null ftbe = decimal-U24-or-null btbe = decimal-U24-or-null crmrtt = decimal-U24-or-null frif = 1*2 (DIGIT) brif = 1*2 (ケタ) 1*2(DIGIT)frdf=brdfは気圧がaddr cdStdをタイプしている1*2(DIGIT)bearerType=オフであるかヌルの「Cid」localInitiation=sci=一般的なU8かヌルlsn=ジェネリックU32か"PVC"/"SVC"/ヌル==ジェネリックU8かatmGroupAddressヌルと等しいです。
Kumar & Mostafa Standards Track [Page 102] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[102ページ]。
conScpTyp = generic-U8-or-null
conScpSel = generic-U8-or-null
cacheEnable = on-off-or-null
cacheTimer = generic-U32-or-null
bearerSigIEType = 2 * (HEXDIG)
bearerSigIELng = 1*4 (HEXDIG)
bearerSigIEVal = 2*512 (HEXDIG)
appClass = "-" /
"itu_h323c" / "af83" / "AAL5_SSCOP" / "itu_i3661_unassured" /
"itu_ i3661_assured"/ "itu_i3662"/ "itu_i3651" /
"itu_i3652" / "itu_i3653" / "itu_i3654" / "FRF11" / "FRF5" /
"FRF8" / "itu_h2221"
oui = "-" / 1*6 (HEXDIG)
appId = "-" / 1*8 (HEXDIG)
cbrRate = 2 (HEXDIG)
sbc = generic-U8
clkrec = "NULL" / "SRTS" / "ADAPTIVE"
fecEnable = "NULL" / "LOSS_SENSITIVE" / "DELAY_SENSITIVE"
partialFill = generic-U8
structureEnable = on-off-or-null
blksz = generic-U16-or-null
cpcs = generic-U16
cidLowerLimit = generic-U8-or-null
cidUpperLimit = generic-U8-or-null
timerCU = decimal-U32-or-null
simplifiedCPS = on-off-or-null
fSDUrate = decimal-U24-or-null
bSDUrate = decimal-U24-or-null
ted = on-off-or-null
rastimer = decimal-U32-or-null
fsssar = generic-U24-or-null
bsssar = generic-U24-or-null
fsscopsdu = generic-U16-or-null
bsscopsdu = generic-U16-or-null
fsscopuu = generic-U16-or-null
bsscopuu = generic-U16-or-null
sap = "AUDIO" / "MULTIRATE" / "-"
circuitMode = on-off-or-null
frameMode = on-off-or-null
faxDemod = on-off-or-null
cas = on-off-or-null
dtmf = on-off-or-null
mfall = on-off-or-null
mfr1 = on-off-or-null
mfr2 = on-off-or-null
PCMencoding = "PCMA" / "PCMU" / "-"
fmaxframe = generic-U16-or-null
bmaxframe = generic-U16-or-null
オフであるかヌルの「損失_敏感な」「遅れ_敏感な」/=ジェネリック-U8 structureEnable=blksz=ジェネリックU16かpartialFill「適応型」のfecEnable=「ヌル」/「SRTS」/「ヌル」/ヌルジェネリック-U8 clkrec=cpcsは一般的なU8かヌルジェネリック-U16 cidLowerLimit=cidUpperLimitと等しいです; = 10進U32かヌルオフであるかヌルの10進U24かヌル10進U24かヌルオフであるかヌルの10進U32かヌル一般的なU8かヌルtimerCU=simplifiedCPS=fSDUrate=bSDUrate=ted=rastimer=fsssarは一般的なU24か一般的なU24かヌルbsssar=ヌルと等しいです。一般的なU16かヌル"PCMA"/"PCMU"/「-」オフであるかヌルのオフであるかヌルのオフであるかヌルのオフであるかヌルのオフであるかヌルのオフであるかヌルのオフであるかヌルのオフであるかヌルの「オーディオ」/「多速度」/「-」一般的なU16かヌル一般的なU16かヌル一般的なU16かヌル一般的なU16かヌルfsscopsdu=bsscopsdu=fsscopuu=bsscopuu=体液=circuitMode=frameMode=faxDemod=cas=dtmf=mfall=mfr1=mfr2=PCMencoding=fmaxframe=bmaxframeは一般的なU16かヌルと等しいです。
Kumar & Mostafa Standards Track [Page 103] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[103ページ]。
silenceSuppEnable = on-off-or-null silenceTimer = generic-U16-or-null suppPref = "standard" / "custom" / "-" sidUse = "No SID" / "Fixed Noise" / "Sampled Noise" / "-" fxnslevel = generic-U8-or-null ecanEnable = on-off-or-null ecanType = "G165" / "G168" / "-" gcEnable = on-off-or-null gcLvl = generic-U16-or-null
オフであるかヌルの"G165"/"G168"/「-」オフであるかヌルの一般的なU8かヌル「規格」/「習慣」/「-」一般的なU16かヌルオフであるかヌルのsilenceSuppEnable=silenceTimer=suppPref=sidUse=「シドがありません」/「固定雑音」/「抽出された雑音」/「-」fxnslevel=ecanEnable=ecanType=gcEnable=gcLvlは一般的なU16かヌルと等しいです。
profile-row = uuiCodeRange space encoding-name space packet-length
space packet-time space
uuiCodeRange = decimal-uchar "-" decimal-uchar / "-"
encoding-name = "-" /
"PCMG" / "SIDG" / "SID729" /
"PCMU" / "G726-32" / "G723" / "PCMA" / "G722" / "G728" /
"G729" / "X-G729a" / "X-G729b" / "X-G729ab" /
"X-G726-16" / "X-G726-24" / "X-G726-40" / "X-G7231-H" /
"X-G7231-L" / "X-G7231a-H" / "X-G7231a-L" /
"X-G727-16" / "X-G727-24" / "X-G727-32" /
"X-CCD" / "X-CCD-CAS" / "GSM" / "GSM-HR" / "GSM-EFR" /
"GSM-EHR" / "X-FXDMOD-3" / "1016" / "DVI4" / "L16" /
"LPC" / "MPA" / "QCELP" / "H263" / "H263-1998" /
"JPEG" / "H261" / "MPV" / "MP2T" / "nv" / "RED" /
"CelB" / "L8" / "VDVI" / "MP1S" / "MP2P" / "BT656" /
"FR-AMR" / "HR-AMR" / "UMTS-AMR" / "AMR"
packet-length = decimal-U8-or-null
packet-time = decimal-U16-or-null
fxIncl = on-off-or-null
serviceType = "v" / "d" / "f" / "df" / "all"
q7655scc = 4*32 (HEXDIG)
isupUsi = 4*24 (HEXDIG)
uiLayer1Prot = 2 (HEXDIG)
profile-row = uuiCodeRange space encoding-name space packet-length space packet-time space uuiCodeRange = decimal-uchar "-" decimal-uchar / "-" encoding-name = "-" / "PCMG" / "SIDG" / "SID729" / "PCMU" / "G726-32" / "G723" / "PCMA" / "G722" / "G728" / "G729" / "X-G729a" / "X-G729b" / "X-G729ab" / "X-G726-16" / "X-G726-24" / "X-G726-40" / "X-G7231-H" / "X-G7231-L" / "X-G7231a-H" / "X-G7231a-L" / "X-G727-16" / "X-G727-24" / "X-G727-32" / "X-CCD" / "X-CCD-CAS" / "GSM" / "GSM-HR" / "GSM-EFR" / "GSM-EHR" / "X-FXDMOD-3" / "1016" / "DVI4" / "L16" / "LPC" / "MPA" / "QCELP" / "H263" / "H263-1998" / "JPEG" / "H261" / "MPV" / "MP2T" / "nv" / "RED" / "CelB" / "L8" / "VDVI" / "MP1S" / "MP2P" / "BT656" / "FR-AMR" / "HR-AMR" / "UMTS-AMR" / "AMR" packet-length = decimal-U8-or-null packet-time = decimal-U16-or-null fxIncl = on-off-or-null serviceType = "v" / "d" / "f" / "df" / "all" q7655scc = 4*32 (HEXDIG) isupUsi = 4*24 (HEXDIG) uiLayer1Prot = 2 (HEXDIG)
chainPointer = "NEXT" / "PREVIOUS" / "NULL"
chainPointerは「次」か「前」の/「ヌル」と等しいです。
References
参照
[1] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[1] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[2]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。
RFC 1889 will be obsoleted, in a substantially backwards
compatible manner, by a work in progress that will become an
RFC.
RFC1889は時代遅れにされるでしょう、実質的に遅れているコンパチブル方法で、RFCになる処理中の作業で。
Kumar & Mostafa Standards Track [Page 104] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[104ページ]。
[3] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
with Minimal Control", RFC 1890, January 1996.
[3]Schulzrinne、H.、「最小量のコントロールがあるオーディオとテレビ会議システムのためのRTPプロフィール」、RFC1890、1996年1月。
RFC 1890 will be obsoleted, in a fully backwards compatible
manner, by a work in progress that will become an RFC.
RFC1890は時代遅れにされるでしょう、完全に遅れているコンパチブル方法で、RFCになる処理中の作業で。
[4] ATMF UNI 3.1 Specification, af-uni-0010.002. Of special
interest for this document is Section 5.4.5.5, ATM Adaptation
Layer Parameters.
[4] ATMF UNI3.1Specification、af-uni-0010.002。 このドキュメントに関する特別な関心はセクション5.4です。.5 .5、ATM Adaptation Layer Parameters。
[5] ATMF UNI 4.0 Signaling Specification, af-sig-0061.000.
[5] ATMF UNI4.0Signaling Specification、af-sig-0061.000。
[6] ATMF Traffic Management Specification, Version 4.1, af-tm-
0121.000.
[6] ATMF Traffic Management Specification、バージョン4.1、af-tm0121.000。
[7] ATMF Circuit Emulation Service (CES) Interoperability
Specification, version 2.0, af-vtoa-0078.000, Jan. 97.
[7] ATMF Circuit Emulation Service(CES)相互運用性Specification、バージョン2.0、af-vtoa-0078.000、1月97日。
[8] ATMF Voice and Telephony over ATM - ATM Trunking using AAL1 for
Narrowband Services, version 1.0, af-vtoa-0089.000, July 1997.
ATMの上の[8]ATMF VoiceとTelephony--1997年7月のNarrowband Services、バージョン1.0、af-vtoa-0089.000にAAL1を使用するATM Trunking。
[9] ATMF Specifications of (DBCES) Dynamic Bandwidth Utilization -
in 64kbps Timeslot Trunking over ATM - using CES, af-vtoa-
0085.000, July 1997.
[9] ATMの上の64kbps Timeslot Trunkingの0085.000と、1997年7月にCES、af-vtoaを使用する(DBCES)ダイナミックなBandwidth UtilizationのATMF Specifications。
[10] ITU-T I.363.1, B-ISDN ATM Adaptation Layer Specification: Type 1
AAL, August 1996.
[10]ITU-T I.363.1、B-ISDN気圧適合層の仕様: 1AAL、1996年8月をタイプしてください。
[11] ITU-T I.363.2, B-ISDN ATM Adaptation Layer Specification: Type 2
AAL, Sept. 1997.
[11]ITU-T I.363.2、B-ISDN気圧適合層の仕様: 2AAL、1997年9月をタイプしてください。
[12] ITU-T I.366.1, Segmentation and Reassembly Service Specific
Convergence Sublayer for AAL Type 2, June 1998.
[12] ITU-TのI.366.1、分割、およびReassemblyはAALタイプ2、1998年6月のための特定の集合副層を修理します。
[13] ITU-T I.366.2, AAL Type 2 Reassembly Service Specific
Convergence Sublayer for Trunking, Feb. 99.
[13] ITU-T I.366.2、AALは中継方式、2月99日の2のReassemblyのサービスの特定の集合副層をタイプします。
[14] Petrack, S., "RTP payloads for Telephone Signal Events", Work in
Progress.
[14]Petrack、S.、「Telephone Signal EventsのためのRTPペイロード」、ProgressのWork。
[15] ITU-T Q.2931, B-ISDN Application Protocol for Access Signaling.
[15] ITU-T Q.2931、アクセスシグナリングのためのB-ISDNアプリケーション・プロトコル。
[16] Amendment 1, 2, 3 and 4 to ITU-T Q.2931, B-ISDN Application
Protocol for Access Signaling.
ITU-T Q.2931の[16]修正1、2、3、および4、アクセスシグナリングのためのB-ISDNアプリケーション・プロトコル。
[17] Handley, M., Perkins C. and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[17] ハンドレーとM.とパーキンスC.とE.ウィーラン、「セッション発表プロトコル」、RFC2974、2000年10月。
Kumar & Mostafa Standards Track [Page 105] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[105ページ]。
[18] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"Session Initiation Protocol (SIP)", RFC 2543, March 1999.
[18] ハンドレーとM.とSchulzrinneとH.と学生とE.とJ.ローゼンバーグ、「セッション開始プロトコル(一口)」、RFC2543、1999年3月。
[19] Almquist, P., "Type of Service in the Internet Protocol Suite",
July 1992.
[19]Almquist、P.、「インターネットプロトコル群のサービスのタイプ」、1992年7月。
[20] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", December 1998.
[20] ニコルズとK.とブレークとS.とベイカーとF.とD.黒、「IPv4とIPv6ヘッダーとの微分されたサービス分野(DS分野)の定義。」(1998年12月)
[21] ITU-T I.363.5, B-ISDN ATM Adaptation Layer Specification: Type 5
AAL, Aug. 1996.
[21]ITU-T I.363.5、B-ISDN気圧適合層の仕様: 5AAL、1996年8月をタイプしてください。
[22] ATMF PNNI 1.0, af-pnni-0055.000, March 1996.
[22] ATMF PNNI1.0、af-pnni-0055.000、1996年3月。
[23] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", Work in
Progress.
[23]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、処理中の作業。
[24] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", Work in Progress.
[24] 「最小量のコントロールがあるオーディオとテレビ会議システムのためのRTPプロフィール」というSchulzrinne、H.、およびS.Casnerは進行中で働いています。
[25] Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett,
"Media Gateway Control Protocol (MGCP)", RFC 2705, October 1999.
[25] Arango、M.、デュガン、A.、エリオット、I.、Huitema、C.、およびS.ピケット、「メディアゲートウェイコントロールは(MGCP)について議定書の中で述べます」、RFC2705、1999年10月。
[26] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and
J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November
2000.
[26]CuervoとF.とグリーン、N.とRayhanとA.とHuitemaとC.とローゼン、B.とJ.Segers、「Megacoはバージョン1インチについて議定書の中で述べます、RFC3015、2000年11月。」
[27] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[27] アトキンソン、R.、「IP認証ヘッダー」、RFC1826、1995年8月。
[28] ITU I.371, Traffic Control and Congestion Control in the BISDN.
[28] ITU I.371、トラフィックコントロール、および混雑はBISDNで制御されます。
[29] ITU E.191, BISDN Numbering and Addressing.
[29] ITU E.191、BISDN付番、およびアドレシング。
[30] ATM Forum Addressing: Reference Guide, af-ra-0106.000.
[30] 気圧フォーラムアドレシング: 参照ガイド、af-ra-0106.000。
[31] http://www.iana.org/assignments/rtp-parameters for a list of
codecs with static payload types.
[31] 静的なペイロードがあるコーデックのリストのための http://www.iana.org/assignments/rtp-parameters はタイプされます。
[32] ITU Q.2941-2, Digital Subscriber Signalling System No. 2 (DSS
2): Generic identifier transport extensions.
[32]ITU Q.2941-2、デジタル加入者合図システムNo.2(DSS2): 一般的な識別子輸送拡張子。
[33] ITU Q.2961, Digital subscriber signalling system no.2 (DSS 2) -
additional traffic parameters. Also, Amendment 2 to Q.2961.
[33]ITU Q.2961、Digital加入者合図システムno.2(DSS2)--追加交通パラメタ。 Q.2961の修正2も。
[34] ITU Q. 2965.1, Digital subscriber signalling system no.2 (DSS 2)
- Support of Quality of Service classes.
[34]ITU Q.2965.1、Digital加入者合図システムno.2(DSS2)--ServiceのQualityのサポートは属します。
Kumar & Mostafa Standards Track [Page 106] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[106ページ]。
[35] ITU Q. 2965.2, Digital subscriber signalling system no.2 (DSS 2)
- Signalling of individual Quality of Service parameters.
[35]ITU Q.2965.2、Digital加入者合図システムno.2(DSS2)--Serviceパラメタの個々のQualityに合図します。
[36] ITU Q.1901, Bearer Independent Call Control Protocol.
[36]ITU Q.1901、運搬人の独立している呼び出し制御プロトコル。
[37] ITU Q.2630.1, AAL type 2 signaling protocol - capability set 1.
[37]ITU Q.2630.1、AALタイプ2シグナリングプロトコル--能力は1を設定しました。
[38] ITU I.363.5, B-ISDN ATM Adaptation Layer specification: Type 5
AAL.
[38]ITU I.363.5、B-ISDN ATM Adaptation Layer仕様: 5AALをタイプしてください。
[39] I.365.1,Frame relaying service specific convergence sublayer
(FR-SSCS).
[39] I.365.1、サービス特定の集合副層(フラン-SSCS)をリレーするFrame。
[40] I.365.2, B-ISDN ATM adaptation layer sublayers: service specific
coordination function to provide the connection oriented network
service.
[40]I.365.2、B-ISDN ATM適合層の副層: 特定のコーディネート機能を修理して、指向のネットワーク・サービスを接続に提供してください。
[41] I.365.3, B-ISDN ATM adaptation layer sublayers: service specific
coordination function to provide the connection-oriented
transport service.
[41]I.365.3、B-ISDN ATM適合層の副層: 特定のコーディネート機能を修理して、接続指向の輸送サービスを提供してください。
[42] I.365.4, B-ISDN ATM adaptation layer sublayers: Service specific
convergence sublayer for HDLC applications.
[42]I.365.4、B-ISDN ATM適合層の副層: HDLCアプリケーションのために特定の集合副層を修理してください。
[43] Q.2110, B-ISDN ATM adaptation layer - service specific
connection oriented protocol (SSCOP).
[43]Q.2110、B-ISDN ATM適合層--特定の接続指向のプロトコル(SSCOP)を修理してください。
[44] af-vtoa-0113.000, ATM trunking using AAL2 for narrowband
services.
[44]af-vtoa-0113.000、狭帯域サービスにAAL2を使用するATM中継方式。
[45] H.323-2, Packet-based multimedia communications systems.
[45]H.323-2、Packetベースのマルチメディア通信システム。
[46] af-vtoa-0083.000, Voice and Telephony Over ATM to the Desktop.
[46] Desktopへのaf-vtoa-0083.000、Voice、およびTelephony Over ATM。
[47] I.356, BISDN ATM layer cell transfer performance.
[47] I.356、BISDN ATMはセル転送性能を層にします。
[48] ITU Q.2957, Digital Subscriber Signaling System No. 2, User to
user signaling.
[48]ITU Q.2957、Digital Subscriber Signaling System No.2、ユーザシグナリングへのUser。
[49] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation and Analysis", RFC 1305, March 1992.
[49] 工場、D.、「ネットワーク時間は仕様、実現、および分析について議定書の中で述べ(バージョン3)」RFC1305、1992年3月。
[50] TIA/EIA/IS-J-STD-025-A, Lawfully Authorized Electronic
Surveillance, May 2000.
[50] TIA/EIA/、-、J-STD-025-A、合法的に認可された電子監視、5月2000
[51] ITU-T H.222.1, Multimedia multiplex and synchronization for
audiovisual communication in ATM environments.
[51] ATM環境における視聴覚のコミュニケーションのためのITU-T H.222.1、Multimediaマルチプレックス、および同期。
Kumar & Mostafa Standards Track [Page 107] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[107ページ]。
[52] af-vmoa-0145.000, Voice and Multimedia over ATM, Loop Emulation
Service using AAL2.
[52] ATM、Loop Emulation Serviceの上のAAL2を使用するaf-vmoa-0145.000、Voice、およびMultimedia。
[53] FRF.5, Frame Relay/ATM PVC Network Interworking Implementation
Agreement.
[53] FRF.5、実現協定を織り込むPVCがネットワークでつなぐフレームリレー/気圧。
[54] FRF.8.1, Frame Relay/ATM PVC Service Interworking Implementation
Agreement.
[54] FRF.8.1、実現協定を織り込むフレームリレー/気圧PVCサービス。
[55] FRF.11, Voice over Frame Relay Implementation Agreement.
[55] FRF.11、フレームリレー実現の上で協定を声に出してください。
[56] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[56] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[57] ITU Q.765.5, Application Transport Mechanism - Bearer
Independent Call Control.
[57] ITU Q.765.5、アプリケーションはメカニズムを輸送します--運搬人の独立している呼び出しコントロール。
[58] http://www.3gpp.org/ftp/Specs for specifications related to
3GPP, including AMR codecs.
[58] AMRコーデックを含んでいて、仕様のための http://www.3gpp.org/ftp/Specs は3GPPに関連しました。
[59] ITU Q.931, Digital Subscriber Signaling System No. 1: Network
Layer.
[59]ITU Q.931、デジタル加入者シグナリングシステムNo.1: ネットワーク層。
[60] ITU Q.763, SS7 - ISUP formats and codes.
[60]ITU Q.763、SS7--ISUP形式とコード。
[61] http://www.atmforum.com/atmforum/specs/specs.html, ATM Forum,
Well-known addresses and assigned codes.
[61] http://www.atmforum.com/atmforum/specs/specs.html (ATM Forum)はアドレスをWell知って、コードを割り当てました。
[62] Bradner, S., "Keywords for use in RFCs to indicate requirement
levels", BCP 14, RFC 2119, March 1997.
[62] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
Kumar & Mostafa Standards Track [Page 108] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[108ページ]。
Acknowledgements
承認
The authors wish to thank several colleagues at Cisco and in the industry who have contributed towards the development of these SDP conventions, and who have reviewed, implemented and tested these constructs. Valuable technical ideas that have been incorporated into this internet document have been provided by Hisham Abdelhamid, Flemming Andreasen, David Auerbach, Robert Biskner, Bruce Buffam, Steve Casner, Alex Clemm, Bill Foster, Snehal Karia, Raghu Thirumalai Rajan, Joe Stone, Bruce Thompson, Dan Wing and Ken Young of Cisco, Michael Brown, Rade Gvozdanovic, Graeme Gibbs, Tom-PT Taylor, Mark Watson and Sophia Scoggins of Nortel Networks, Brian Rosen, Tim Dwight and Michael Mackey of Marconi, Ed Guy and Petros Mouchtaris of Telcordia, Christian Groves of Ericsson, Charles Eckel of Vovida Networks, Tom Jepsen, Dal Chohan, Sagar Gordhan and Chris Gallon of Fujitsu, Mahamood Hussain of Hughes Software Systems and Sean Sheedy of nCUBE Corporation, Narendra Tulpule of Intel, Albrecht Schwarz of Alcatel, and Jonathan Rosenberg of Dynamicsoft. The authors also wish to thank the ISC device control group, and the MMUSIC and MEGACO subgroups of the IETF, especially Bill Foster, Joerg Ott, Sean Sheedy and Brian Rosen for their help in the preparation of this document. Finally, thanks are due to Narendra Tulpule of Intel whose ABNF grammar was adapted for this document.
作者はこれらの構造物をこれらのSDPコンベンションの発展を寄付して、見直して、実行して、テストしたシスコにおける産業の数人の同僚に感謝したがっています。 このインターネットドキュメントに組み入れられた貴重な技術的な考えはノーテルNetworksのシスコ、Michael Brown、ラーデGvozdanovic、グレーム・ギブズ、太平洋標準時のトム・テイラー、マーク・ワトソン、およびソフィアScogginsのHisham Abdelhamid、フレミングAndreasen、デヴィッド・アウアーバック、ロバートBiskner、ブルースBuffam、スティーブCasner、アレックス・クレム、ビル・フォスター、Snehalカリア、Raghu Thirumalai Rajan、ジョー・ストーン、ブルーストンプソン、ダンWing、およびケン・ヤングによって提供されました; ブライアン・ローゼン、マルコニーのティム・ドワイトとマイケル・マッケイ、Telcordiaのエド・ガイとペトロスMouchtaris、エリクソンのクリスチャンの木立、Vovidaネットワーク、トム・ジェプセン、ダーリChohan、セイガーGordhan、およびクリスGallonの富士通のチャールズEckel、ヒューズソフトウェア・システムのMahamoodフセインとnCUBE社のショーン・シーディ、インテルのNarendra Tulpule、アルカテルのアルブレヒト・シュワーツ、およびDynamicsoftのジョナサン・ローゼンバーグ。 また、作者がIETFのISC装置制御集団、MMUSIC、およびMEGACOサブグループに感謝したがっていて、特にビルは、このドキュメントの準備における彼らの助けのためのフォスターと、ヨルク・オットと、ショーン・シーディとブライアン・ローゼンです。 最終的に、感謝はABNF文法がこのドキュメントのために適合させられたインテルのNarendra Tulpuleのためです。
Authors' Addresses
作者のアドレス
Rajesh Kumar Cisco Systems, Inc. M/S SJC01/3 170 West Tasman Drive San Jose, CA 95134-1706
ラジェッシュクマーシスコシステムズInc.SのSJC01/3 170の西タスマン・Driveサンノゼ、M/カリフォルニア95134-1706
Phone: 1-800-250-4800 EMail: rkumar@cisco.com
以下に電話をしてください。 1-800-250-4800メール: rkumar@cisco.com
Mohamed Mostafa Cisco Systems, Inc. M/S SJC01/3 170 West Tasman Drive San Jose, CA 95134-1706
モハメドMostafaシスコシステムズInc.SのSJC01/3 170の西タスマン・Driveサンノゼ、M/カリフォルニア95134-1706
Phone: 1-800-250-4800 EMail: mmostafa@cisco.com
以下に電話をしてください。 1-800-250-4800メール: mmostafa@cisco.com
Kumar & Mostafa Standards Track [Page 109] RFC 3108 ATM SDP May 2001
クマーとMostafa規格は気圧SDP2001年5月にRFC3108を追跡します[109ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Kumar & Mostafa Standards Track [Page 110]
クマーとMostafa標準化過程[110ページ]
一覧
スポンサーリンク
