ダイレクト ルーティング - メディア プロトコル
この記事では、 RFC 5245 で説明されているように、ICE Lite でセッション ボーダー コントローラー (SBC) が有効になっているメディア バイパスをダイレクト ルーティングでサポートする方法について説明します。 この記事は、オンプレミスの SBC と SIP プロキシ サービス間の接続の構成を担当する音声管理者を対象としています。
この記事では、ICE Lite のシナリオの概要と相互運用性の要件について説明します。 この記事では、信頼性の高い呼び出しとメディア フローを確保するために必要なステート マシンのメッセージ形式と遷移について説明します。
用語
First Hello – 呼び出し元と呼び出し先が話す最初の単語。 エンドポイントからの最初のパケットがほとんどのユース ケースで確実に配信されるように、すべての作業が行われるようにすることが重要です。
フォーク – 呼び出し先が複数のデバイスで使用できる場合は、呼び出し元からのオファーが複数の呼び出し先エンドポイントに配信される場合があります (たとえば、Teams ユーザーが Windows 用 Teams にサインインし、Teams for Android または iPhone にサインインしている場合など)。
暫定応答 (183) – 通話設定を高速化するための呼び出し先エンドポイントは、メディア フローを確立するために必要な候補とキーと共に回答を送信します。 この回答は、ユーザーが特定の呼び出し先インスタンスからの呼び出し (200OK) に応答する可能性があることを想定して行われます。 フォークを使用すると、呼び出し元は複数の暫定的な回答を受け取る準備が整う必要があります。
Re-Invite – ICE 制御エンドポイントによって選択された最終的な候補を含むオファー。 このオファーには、複数のフォークの処理から競合状態を解決するための a=remote-candidate 属性があります。
Teams エンドポイント – このエンドポイントは、サーバー (メディア プロセッサ、トランスポート リレー) または Teams クライアントのいずれかです。
メッセージ形式
Teams インフラストラクチャは、ICE-Lite 用 RFC 5245 に従います。 すべての STUN メッセージは RFC 5389 に準拠しています。
RFC 5389 で必要とされる SBC は、認識されない STUN 属性を無視し、既知の属性を使用してメッセージを処理し続ける必要があります。
不正な形式のパケットが受信された場合は、メディア セッションの確立に影響を与えずにパケットを破棄する必要があります。
ICE Lite の要件
このセクションでは、ICE Lite の要件について簡単に説明します。
候補者の集まり
SBC は、1 つの候補のみを提供する必要があります。 現時点では、IPV4 候補のみがサポートされています。
接続チェック
ICE Lite の実装は、受信した接続チェックに応答する必要があります。 ICE Lite エンドポイントは、接続チェック要求を送信してはなりません。 (接続チェックが違反で送信された場合、完全な実装が応答します。これにより、予期しないピア派生候補が検出され、呼び出しエラーが発生する可能性があります)。
ノミネート
ICE 完全実装エンドポイントは制御エンドポイントであり、メディア フローに使用する最終的な候補を選択するための "標準" の指名に従います。 ICE Lite エンドポイントは、指名を使用して、メディアおよび完全な呼び出し確立に使用されるパスを終了できます。
ピア エンドポイントを使用してフォークすると 183 の暫定回答が送信される場合、SBC は複数のエンドポイントからのチェックに応答する準備が整い、200OK より前に指名が行われる場合は複数のエンドポイントからの指名にも対応できる必要があります。 最終的なパス上の ICE ステート マシンの収束と、ユーザーが応答するタイミングによっては、200OK の前または後に指名が行われる可能性があります。 SBC は両方のケースを処理できる必要があります。
フォークの収束
SBC から複数の Teams エンドポイントへのオファーがフォークする場合、Teams エンドポイントは暫定的な回答で応答し、接続チェックを開始する可能性があります。 接続チェックを受け取り、複数のピア エンドポイントからの接続チェックに応答するには、SBC を準備する必要があります。 たとえば、Teams ユーザーはデスクトップと携帯電話の両方にサインオンできます。 どちらのデバイスも着信呼び出しの通知を受け取り、SBC との接続チェックを試みます。
最終的に、呼び出しに応答するエンドポイントの 1 つだけ (200OK)。 200OK を受信すると、SBC はメディア パケットを処理するための適切なコンテキストを設定できます。
シナリオ
SBC からの着信呼び出し
このシナリオでは、SBC で処理する必要があるピア エンドポイントがいくつかあります。
通常、サーバー エンドポイントは 200OK で直接応答します。 これらの ICE フル エンドポイントは、通常、ボイスメール、通話キュー、自動応答のシナリオに関与します。
クライアント エンドポイントは、異なる From/To タグ (183) を持つ複数の暫定応答を送信し、その後、呼び出しに応答するエンドポイントから 200OK を送信できます。 通常、これらの ICE Full エンドポイントはエンド ユーザー クライアントを表します。
その他の SBC エンドポイント。 これらの ICE Lite エンドポイントは、通常、クライアント エンドポイントと別の電話番号を同時に呼び出すシナリオに関与します。
SBC は、ICE Full エンドポイントから受信したすべての有効な接続チェック要求に応答する必要があります。 RFC ごとに、ICE Full エンドポイントは制御エンドポイントになります。 Teams (クライアント/サーバー) エンドポイントは、接続チェックを完了するために "標準" の指名を実行します。 最後の 200Ok は、初期メディアを送信したエンドポイントから、または別のエンドポイントから送信できます。 200Ok を受信すると、SBC はメディア フローの適切なコンテキストを設定する必要があります。
初期メディア
初期メディア フローがある場合、SBC はストリーミング メディアを開始する最初のエンドポイントにラッチする必要があります。メディア フローは、候補が指名される前に開始できます。 SBC では、IVR/ボイスメール シナリオを有効にするために、このフェーズ中に DTMF を送信するサポートが必要です。 SBC は、指名が完了していないかどうかを確認した最も優先度の高いパスを使用する必要があります。
SBC への送信呼び出し
Teams エンドポイントは、このシナリオの呼び出し元であり、制御エンドポイントです。 暫定的な回答 (183) または最終的な回答 (200OK) を受け取った場合、Teams エンドポイントは接続チェックを開始し、"標準" の指名に進んで接続チェックを完了します。
注: SBC が暫定的な回答 (183) を送信する場合、SBC は接続チェック要求を受信する準備ができていて、200OK を送信する前に指名を完了する可能性があります。 200OK を受け取る前にチェックや指名が完了した場合、200OK が受信された後、チェックや指名は再度実行されません。 SBC は、183 から 200 の間に ICE 候補、パスワード、および ufrag (ユーザー名フラグメント) を変更してはなりません。
初期メディアをサポートするために、SBC は、Teams エンドポイントによって指名が完了する前であっても、受信した接続チェックに基づいて最も優先順位の高いピア ICE 候補へのメディアのストリーミングを開始できます。 SBC は、指名が完了するまで、任意の候補者に Teams のメディアを期待する必要があります。 候補が指名されたら、SBC はメディア パケットを送受信するために適切なコンテキストにリセットする必要があります。
SDP での M ラインの処理
通話シナリオによっては、PSTN への呼び出しで他のメディア モダリティが提供される場合があります。 たとえば、Teams ビデオ通話が PSTN に転送される場合、m=video です。 顧客 SBC がメディア バイパスで構成されている場合、これらの行はサービスによって削除されないため、次のRFC3264 SBC によって処理される必要があります。オファー内の "m=audio" 行ごとに、SBC は対応する "m=" 行を応答に含める必要があり、この行のポート番号を 0 に設定する必要があります。 オーディオ以外のすべてのストリームを効果的に拒否します。
SRTP サポート要件
SBC は、次の形式のオファーと回答のために SRTP 暗号化暗号AES_CM_128_HMAC_SHA1_80をサポートする必要があります。
"inline:" <key||salt> ["|" lifetime]
SBC からの SDP オファーの暗号化属性の例を次に示します。
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:V/Lr6Lsvhad/crSB9kCQ28jrYDxR2Yfk5bXryH5V|2^31
MKI パラメーターと Length パラメーターは必要ありません。
詳細については、 RFC 4568、セクション 6.1 を参照してください。
SDES サポート要件
デバイスは、次の形式で SDES を提供できる必要があります。 Microsoft Media Processors では、常に SDES が優先されます。
メディア以外のバイパスでは、クライアントが DTLS のみをサポートしている場合でも、メディア プロセッサは SDES に変換します。
メディア バイパスでは、クライアントが DTLS のみの場合 (今後の Google Chrome の状態)、ダイレクト ルーティングによってパスに MP が挿入され、メディア バイパスからの呼び出しがメディア バイパスから非メディア バイパスに変換されます。 ダイレクト ルーティングの SBC とメディア プロセッサ コンポーネントの間では、SDES が常に使用されます。
現時点では、DTLS のみを提供する Teams クライアントはありません。しかし、Googleは、ある時点でSDESのサポートを停止すると発表しました。
バイパス モードでの SBC からのオファーの形式
オファーには SDES が含まれている必要があり、次の形式でオプションの DTLS を含めることができます。
m=audio 54056 UDP/TLS/RTP/SAVP 0 8 76 77 18 9 101 13
a=rtcp:54056
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:krXco0QRglwErMqtbMs2zSw29tBdmdgXpEYZhQmp|2^31
a=fingerprint:sha-256 AE:24:07:15:5C:B7:45:1A:E4:45:60:C1:1E:68:0E:CC:8D:A6:78:3B:76:65:BB:B0:77:88:07:F8:98:18:62:34
a=setup:actpass
a=rtcp-mux
SBC への SDES を含む回答の形式
m=audio 54056 RTP/SAVP 111 103 104 9 0 8 description 106 13 110 112 113 126
a=rtcp:54056
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:fBc61ikv1kMy0sF85DblNqTzVAbFa7hJQ9GKb6Yj|2^31|1:1
a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:O1qT9tWbs/NwJVwhfrgF5tCrbNOxnVDqkIqTx4rz|2^31
a=rtcp-mux
Teams から SBC へのオファーの形式
SBC にのみ提供される SDES の形式
m=audio 52884 RTP/SAVP 111 103 104 9 0 8 106 13 110 112 113 126
a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:Hr4D2cgUu9+Uza5Igz/JkVx59DAxDbaxJg862ibQ|2^31
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:JPEaIxHegfuv53ykBPZk8hV0GO8kTiiqRMfHimEE|2^31
a=rtcp:52884
a=rtcp-mux