8.1.2 能力交換・通信モード決定
1) H.242による能力交換・通信モード決定
ISDNは汎用的なネットワークですから，同じオーディオビジュアル通信に属するとしても，多様な種類の端末（あるいは同じ種類であっても世代の異なる端末）がネットワークを介して相互接続の可能性があります．このとき双方の端末が適切なモード（通常，共通に持つ最大限の機能による）で通信できることが重要です．勧告H.242はそのための通信手順を規定しています．
H.242によるネゴシエーションは，図3-8に示しましたように次の順番で進みます．
- 受信側の能力を送信側に提示する．音声符号化，映像符号化，転送レート，データ伝送，暗号化などの能力がネゴシエーションの対象となる．
- 送信側は自分の送信能力と相手側の受信能力を比べ，共通最大機能によりその通信で使用するモードを決定する．
- 送信側は受信側にそのモードへの切り替えを指示する．
能力表示のBAS符号は，図7-6の中で属性が(100)，(101)，(110)の符号です．例えば，G.711 A則，G.711μ則，G.722 64 kbit/sモード，G.729の音声符号化ストリームを受信可能であれば，(100)[2]，(100)[1]，(100)[3]，(110)[4]の4個のBAS符号を送り，送信側で品質重視であればG.722 64 kbit/sモードが選ばれてコマンド(000)[6]が送出されます．もし，ビットレート重視であればG.729が選ばれコマンド(000)[11]が送出されます．なお，()内はBAS符号最初の3ビットの2進表示，[]内は後続5ビットの10進表示です．
ここで重要なのは，H.320システムではG.711 A則およびG.711μ則のサポートを必須としていることです．これはH.320テレビ電話が既存電話とも通信できるように設計されていることもありますが，相互接続の点ではどのような世代の端末が対向しても最悪このモードで通信できるようにしています．
双方向通信の場合，ネゴシエーションの仕組みを用意することとデフォールトの必須機能を定めることで，時代とともに得られる技術進歩を採り入れることと相互接続性の確保を両立させることができます．時代が進むと，旧来の機能を搭載していてもそれが起動されることはない，という資源的な無駄を生じますが，技術進歩に追随した連続的なシステム更改が可能になります．
技術進歩の範疇に，各社独自の非標準モードがあり，他社製品との差別化のため採り入れられることがあります．その能力表示は(111)[30]で始まるマルチバイト符号で，ITU-T T.35[8-15] Annex Aで定める国別コードと各国で定めるメーカコード，各メーカで定めるタイプコードの組み合わせで非標準機能を特定します．同様に非標準モードを起動するコマンドは(111)[31]で始まるマルチバイト符号です．この場合もデフォールトの必須機能により，他社端末との互換性は保たれます．
2) H.245による能力交換・通信モード決定
H.245における能力交換・通信モード決定の考え方は，H.242のそれを継承しています．ただし，H.245はH.323以外にもパケットベースのシステムで共通に使えるように設計されていること，確認形のプロトコルであること，ASN.1によるプロトコル記述を用いていること，などの点でH.242とは違いがあります．
H.245による能力交換・通信モード決定の流れを図8-3に示します．H.242の場合の図3-8と比べますと，能力提示ならびにモード決定のメッセージにACKが返されている点が異なります．
まず，メディアストリームの受信側からH.245 TCS (Terminal Capability Set) メッセージで受信能力を提示します．次に，メディアストリームの送信側では，相手の受信能力と自らの送信能力を比べて最善の送信モードを決定し，受信側にH.245 LCS (Logical Channel Signalling)メッセージでそれを伝えます．H.245メッセージは受信確認（ACK）を必要とします．また，H.245メッセージはエラーフリーのTCPで運ばれます．能力交換・通信モード決定の後で，UDPの上のRTPパケットによりメディア情報が運ばれます．
能力交換では，多様な端末間で最良の通信を実現するため，受信側からサポートする符号化の種類，ビットレートなどを提示し，送信側では自らの送信能力と比較して最適な通信モードを選択します．H.245では，端末の処理パワーで制限される受信能力と送信能力の組み合わせ，複数モード間の優先順位，あるいは非標準モードのサポートなど，より高度な能力表現も可能です．
あるテレビ会議端末から送出されている能力メッセージの例を図8-4に示します．左側は能力表（capabilityTable）で，1〜18のエントリー番号と能力内容（メディア種別，送/受信の別，符号化，最大ビットレートなど）が対応づけられます．音声符号化（1〜6），映像符号化（7〜10），遠隔カメラ制御（11），PC画面表示のためのH.239デュアルビデオ制御（12），マルチポイント会議における議長制御（13），ユーザ入力（14〜18）の機能を持っています．右側の表（capabilityDescriptors）は，この装置で同時に動作できる能力を示していて，1〜11のモードが同時動作可能であることを意味し，番号1や2のモードのように{}内に複数の能力が記されているのは，そのうちの一つだけを選択して起動できることを表しています．その際，複数能力の記載順は優先順位を示します．図8-4の能力記述子1番の例では，G.722が第1優先，G,722.1 24kが第2優先，・・・，第6優先がG.723.1を意味しています．
動作しているテレビ会議端末から出ているH.245能力メッセージを記録した結果です．この装置でサポートしている能力の一覧と，同時に起動できる能力の組み合わせを示しています．
図8-4でも示されていますように，時代とともに多数の音声，映像符号化が標準化され，能力定義メッセージが膨らんでいます．新たな符号化が定義される度に勧告H.245を改訂するのは時間と労力を要することから，ジェネリック・ケイパビリティ（generic capability，汎用能力，H.245 Appendix VIIで説明）と呼ばれる定義手法が導入されました．新たな能力が必要な場合，ID番号を始め，定められたテンプレートに記入することで能力定義ができます．また，端末の外に存在して複数端末からのメッセージを受けるMCU（Multipoint Control Unit，多地点通信制御装置）などは，端末の能力の細部を解釈しなくても，そのパラメータ番号値を見るだけで共通最大の能力を見出すことができるよう，パラメータ定義は大が小をかねること（collapsing，折りたためるの意）が推奨されています．
ジェネリック・ケイパビリティの定義内容を図8-5に示します．ここでは，例としてG.719（21 kHz帯域フルバンド音声を32〜128 kbit/sで符号化）の能力定義を記しています．ケイパビリティを特定するIDは能力識別子のタイプで表されますが，ITU-Tで定義するケイパビリティにはOID (Object IDentifier)[8-16]が用いられます（コラム8-3参照）．なお，図8-4の装置では，能力番号7のH.264映像符号化と能力番号12のH.239制御がジェネリック・ケイパビリティで表されています．
ジェネリック・ケイパビリティを用いた能力定義はH.245のAnnex（例えばMPEG-4映像符号化能力はH.245 Annex E）あるいは該当標準の中（例えばG.719音声符号化の能力はG.719 Annex C）に記されます．定義済みジェネリック・ケイパビリティの一覧はH.245 Appendix VIII[8-3]に記されています．
3) SDPによる能力交換・通信モード決定
IP網のうえで展開する電話，テレビ電話，テレビ会議などリアルタイム・オーディオビジュアル通信の呼接続について，IETFではSIP（読みはシップ，Session Initiation Protocol）をRFC 3261[8-12]で規定しています．
このSIP呼接続メッセージ（INVITE, ACK, BYEなど）に，その通信（セッション）で使用する音声符号化，映像符号化など通信モードを決定するための能力情報を埋め込む仕組みとしてSDP（Session Description Protocol，セッション記述プロトコル，RFC 4566）[8-14]が使われています．SDPは，音声，映像，データのストリーム内容を示すため，使用する帯域幅，符号化方法，符号化パラメータ，フレームレートなどを記述する方法（文法と意味）を規定した標準です．具体的には，次の内容を記述します．
- セッション記述：セッションを識別する情報（セッション名，識別子，目的）
- 時間記述：セッションの有効時間（開始・終了時刻と繰り返し回数）
- メディア記述：メディアに関する情報（IPアドレス，メディアの種別，コーデック）
記述の表現方法は<type>=<value>の形で，<value>は1もしくは複数のフィールドからできています．例えばtypeがoであればセッションの創設者を示し，mであればメディアの種類を示します．またtypeがaであれば追加情報を示しています．SDPメッセージはセッションレベルの記述とメディアレベルの記述からなり，それぞれa=行で属性情報を含めることができます．セッションレベルのa=行はその後のメディア全体に有効です．
SDPメッセージの例[8-14]を図8-6に示します．このセッションで用いる音声符号化，映像符号化，セッション開始ならびに終了時刻などの情報が提示しています．a=recvonlyはセッションレベルに書かれていますので，後続のメディア全てに有効です．もし個別メディアの記述に例えばa=sendrecvと書かれれば，セッションレベルの記述を上書きして送信および受信の双方向通信の属性であることを示します．
RFC 4566に記載の例です．オーディオビジュアル情報を受信するセッションを記述しています．そのことはa=recvonlyの記述で分かります．音声符号化にはG.711μ則を用い，映像符号化H.263 1998年版を用いるセッションであることを示しています．
SDPによるセッション内容の記述を，通信開始時の能力交換と通信モード決定に利用する仕組みは，SDPオファ・アンサ・モデルとしてRFC 3264[8-17]に規定されています．その原理は，セッションを創設するオファ側（すなわちSIPで発呼する側）から望ましいと考えるメディアの種類，符号化方法などからなる通信モードをアンサ側（すなわちSIPで着呼する側）に提示し，アンサ側はそれへの応答として対応する項目に自らが望ましいと考える内容を示します．このオファとアンサの交換によりセッションの両当事者間で動作可能な通信モードを見つけることになります．
オファ・アンサのSDPメッセージ例を図8-7に示します．これはRFC 4317[8-18]に記載されています．この例では，音声符号化として優先順にG.711μ則，G.711A則，iLBCが，映像符号化として優先順にH.261とMPEGがオファされ，それに対しアンサ側は音声符号化としてG.711μ則，映像符号化としてMPEGを回答しています．結果として，この通信では，G.711μ則音声とMPEGビデオのストリームが双方向に送られることになります．
各メディア符号化に関するオファ・アンサモデルで用いるSDPメッセージの詳細は，パケット化方法を規定したRFCに記されます．例えば，H.264/AVCに関してはRFC 6184[8-19]に記述されています．
RFC 4566に記載の例です．セッションを開始させるオファ側はa)のSDPメッセージを送ります．複数の音声，映像能力を提示しています．これを受けたアンサ側はb)のSDPメッセージで希望のモードを特定しています．このSDPメッセージのやりとりにより，c)の通信モードが決定します．送受信方向に関するa=sendonly/recvonly/sendrecv行は，デフォールトがsendrecvなので省略されればsendrecvを意味します．