5.1 Unicast Streams (ユニキャストストリーム)

5.1 Unicast Streams (ユニキャストストリーム)

オファー側がストリーム上でピアにのみメディアを送りたい場合, a=sendonly 属性でそのストリームを sendonly とマークしなければならない (MUST). 方向属性がメディアストリーム属性またはセッション属性のいずれかとして存在する場合, そのストリームが特定の方向でマークされたとみなす. ピアからのみメディアを受信したい場合は recvonly とマークしなければならない. 通信したいが現時点では送受信どちらも望まない場合は, a=inactive 属性で inactive とマークしなければならない. inactive 方向属性は RFC 3108 [3] で規定される. Real Time Transport Protocol (RTP) [4] の場合, sendonly, recvonly, inactive のストリームでも RTCP は引き続き送受信されることに注意する. すなわち, メディアストリームの方向性は RTCP の利用に影響しない. ピアと送受信両方を行いたい場合は a=sendrecv を含めてもよいし, 省略してもよい; sendrecv がデフォルトだからである.

recvonly および sendrecv ストリームでは, オファー内のポート番号とアドレスは, オファー側がそのメディアストリームを受信したい場所を示す. sendonly の RTP ストリームでは, アドレスとポート番号は, オファー側が RTCP レポートを受信したい場所を間接的に示す. 明示的な別指示がない限り, レポートは示された番号より 1 大きいポートに送られる. オファーに現れる IP アドレスとポートは, オファー側が送る RTP および RTCP パケットの送信元 IP アドレスと送信元ポートについて何も示さない. オファーでポート番号がゼロの場合, ストリームは提供されるが使用してはならない (MUST NOT) ことを示す. 初期オファーでは実用的な意味はないが, アンサーがゼロポートで拒否ストリームを示し得るため (第 6 節), 完全性のために許される. さらに, ポートをゼロに設定することで既存ストリームを終了できる (第 8 節). 一般に, ポート番号ゼロはそのメディアストリームが望まれないことを示す.

各メディアストリームのメディア形式リストは 2 つの情報を伝える. すなわち, オファー側が送信および/または受信可能な形式の集合 (RTP の場合はコーデックおよびコーデックに関連するパラメータ), および RTP の場合それらの形式を識別する RTP ペイロードタイプ番号である. 複数形式が列挙されていれば, オファー側はセッション中にそれらのいずれも利用できることを意味する. 言い換えれば, アンサー側は新しいオファーを送らずに, 列挙された形式のいずれかにセッション途中で切り替えてもよい. sendonly ストリームでは, オファーはこのストリームについてオファー側が送る意思のある形式を示すべきである (SHOULD). recvonly では受信する意思のある形式を, sendrecv では送受信の両方に使う意思のあるコーデックを示すべきである.

recvonly の RTP ストリームでは, ペイロードタイプ番号は, そのコーデックについてオファー側が受信を期待する RTP パケットのペイロードタイプフィールドの値を示す. sendonly では, オファー側がそのコーデックについて送信を計画する RTP パケットのペイロードタイプフィールドの値を示す. sendrecv では, オファー側が受信を期待し, 送信を望むペイロードタイプフィールドの値を示す. ただし sendonly および sendrecv では, アンサーが同一コーデックに異なるペイロードタイプ番号を示すことがあり, その場合オファー側はアンサーのペイロードタイプ番号で送らなければならない (MUST).

H.323 との相互運用上の理由から, 方向ごとに異なるペイロードタイプ番号が必要になることがある.

RFC 2327 に従い, メディア形式の追加パラメータを与えるために fmtp パラメータが存在してもよい (MAY).

RTP ストリームの場合, すべてのメディア記述に RTP ペイロードタイプからエンコーディングへの a=rtpmap マッピングを含めるべきである (SHOULD). a=rtpmap がない場合, 使用中の現在のプロファイル (例: RFC 1890 [5]) で定義されるデフォルトのペイロードタイプマッピングを用いる.

これにより静的ペイロードタイプからの移行が容易になる.

いずれの場合も, m= 行の形式は優先度順に列挙され, 最初が最も優先される. ここで優先とは, オファーの受信側が, 自分にとって受容可能なもののうち最も優先度の高い形式を使うべきである (SHOULD) ことを意味する.

ストリームに ptime 属性がある場合, オファー側が受信したい希望のパケット化間隔を示す. ptime 属性はゼロより大きくなければならない (MUST).

ストリームに帯域 (bandwidth) 属性がある場合, オファー側が受信したい希望帯域を示す. ゼロは許されるが推奨されない; メディアを送らないことを示す. RTP の場合, すべての RTCP も無効になる.

異なる種類のメディアストリームが複数ある場合, オファー側はそれらを同時に使いたいことを意味する. 典型的にはテレビ会議の音声と映像である.

同一タイプのメディアストリームが複数ある場合, オファー側は同時にそのタイプのストリームを複数送受信したいことを意味する. 同一タイプの複数ストリームを送る場合, 各メディアソース (映像ならカメラと VCR など) を各ストリームにどうマッピングするかはローカル方針である. ユーザーが特定メディアタイプで単一ソースしか持たない場合, 合理的な方針は 1 つだけである: そのソースを同一タイプの各ストリームに送る. 各ストリームは異なるエンコーディングを使ってもよい (MAY). 同一タイプの複数ストリームを受信する場合, 各ストリームをそのタイプの各メディアシンク (音声ならスピーカーや録音装置など) にどうマッピングするかはローカル方針である. ただし方針には制約がある. 第一に, 同一タイプの複数ストリームを受信する場合, 各ストリームはユーザーへの提示目的で少なくとも 1 つのシンクにマッピングされなければならない (MUST). 言い換えれば, 同一タイプの複数ストリームを受信する意図は, 1 つだけ選ぶのではなくすべて並行して提示することである. 第二に, 複数ストリームが受信され同一シンクに送られる場合, メディア固有の何らかの方法で結合しなければならない (MUST). 例えば 2 つの音声ストリームがそれぞれスピーカーにマッピングされる場合, 結合操作はミキシングである. 複数のインスタントメッセージングストリームでシンクが画面の場合, 結合は UI 上ですべて提示することである. 第三に, 複数ソースが同一ストリームにマッピングされる場合, ストリーム上に送る前にメディア固有の方法でそれらを結合しなければならない (MUST). これらの制約を超える方針は柔軟だが, 会議サーバでない限り, シンクからソースへメディアをコピーする方針は一般に望ましくない (すなわち, 一方のストリームで受信したメディアを他方のストリームにコピーしない).

同一タイプの複数メディアストリームの典型的な使用例はプリペイド電話カードアプリケーションである. ユーザーは通話中いつでもポンド (#) キーを押し続けることで切断し同じカードで新しい呼をかけられる. これにはユーザからのメディアを 2 つの宛先, リモートゲートウェイとポンドを監視する DTMF 処理アプリケーションに送る必要がある. これは 2 つのメディアストリームで実現できる. 1 つはゲートウェイへの sendrecv, もう 1 つは (ユーザ視点で) DTMF アプリケーションへの sendonly である.

オファー側がオファーを送った後, そのオファーで記述された recvonly ストリームについてメディアを受信する準備をしなければならない (MUST). オファー内の sendrecv ストリームについて送受信の準備をし, sendonly ストリームについて送信の準備をしなければならない (もちろん, ピアが必要なアドレスとポート情報を含むアンサーを提供するまで実際には送れない). RTP の場合, アンサー前にメディアを受信してもよいが, アンサーが届くまで RTCP 受信者レポートは送れない.