ダイレクト ルーティング - 定義と RFC 標準
この記事では、ダイレクト ルーティングTeams 電話インターネット エンジニアリング タスク フォースのコメント要求 (RFC) によって定義された標準プロトコルを使用する方法について説明します。 この記事は、オンプレミスのセッション ボーダー コントローラー (SBC) とセッション開始プロトコル (SIP) プロキシ サービスの間の接続の構成を担当する音声管理者を対象としています。
顧客 SBC は、Microsoft Teams バックエンドで次のコンポーネントとインターフェイスします。
シグナリング用の SIP プロキシ。 このコンポーネントは、SBC とダイレクト ルーティング間の SIP (TLS) 接続を処理するダイレクト ルーティングのインターネットに接続するコンポーネントです。
メディアのメディア プロセッサ 。 このコンポーネントは、メディア トラフィックを処理するダイレクト ルーティングのインターネットに接続するコンポーネントです。 このコンポーネントでは、SRTP プロトコルと SRTCP プロトコルが使用されます。
ダイレクト ルーティングの詳細については、「ダイレクト ルーティングのTeams 電話」を参照してください。
ダイレクト ルーティングが SIP プロトコルを実装する方法の詳細については、「 ダイレクト ルーティング - SIP プロトコル」を参照してください。
RFC 標準
ダイレクト ルーティングは RFC 標準に準拠しています。 ダイレクト ルーティングに接続されている SBC は、次の RFC (またはその後続の RFC) にも準拠している必要があります。
メディア以外のバイパス モードをサポートするデバイスに適用される標準
メディア以外のバイパス モードのみをサポートするデバイスには、次の標準が適用されます。
- RFC 3261 SIP: セッション開始プロトコル
- RFC 3325 信頼されたネットワーク内のアサートされた ID に対するセッション開始プロトコルのプライベート拡張機能 --P-Asserted-Identity ヘッダーの処理に関するセクション。 ダイレクト ルーティングは、プライバシー ID ヘッダーを使用して P-Asserted-Identity を送信します。
- RFC 4244 必要な履歴情報のセッション開始プロトコル (SIP) の拡張機能。 詳細については、「ルーティング SIP プロトコルの説明」も参照してください。
- RFC 3892 セッション開始プロトコルの Referred-By メカニズム
- RFC 3891 セッション開始プロトコル (SIP) の "置換" ヘッダー
- RFC 6337 オファー/応答モデルのセッション開始プロトコル (SIP) の使用。 「RFC からの逸脱」セクションを参照してください。
- RFC 3711 と RFC 4771。 SRTP を使用して RTP トラフィックを保護します。 SBC は、SDES を使用してキーを確立できる必要があります。
- RFC 8035 RTP/RTCP マルチプレクシングのセッション記述プロトコル (SDP) オファー/回答の説明
メディア バイパス モードをサポートするデバイスに適用される標準
ノンバイパス モードに適用できる標準に加えて、メディア バイパス モードには次の標準が使用されます。
-
メディア バイパス用の RFC 5245 対話型接続確立 (ICE)。 SBC は、次の ICE 要素をサポートする必要があります。
- ICE Lite - Teams クライアントは完全な ICE クライアントです
- ICE 再起動。 ICE 再起動のユース ケースと例の詳細については、「ICE 再起動: メディア バイパスをサポートしていないエンドポイントに転送されたメディア バイパス呼び出し」を参照してください
- RFC RFC 5589 セッション開始プロトコル (SIP) 通話制御 – 転送。
- セッション開始プロトコル (SIP) での RFC 3960 の初期メディアと呼び出し音の生成(セクション 3.1、フォーク、3.2、リンギング トーン生成)を参照してください
- NAT 用 RFC 5389 セッション トラバーサル ユーティリティ (STUN)
- RFC 5766 NAT を中心としたリレーを使用したトラバーサル (TURN): NAT (STUN) のセッション トラバーサル ユーティリティへのリレー拡張機能
E911 プロバイダーへの位置情報の伝達をサポートするために適用される標準
RFC からの逸脱
次の表に、MICROSOFT の SIP またはメディア スタックの実装が標準から逸脱する RFC のセクションを示します。
| RFC とセクション | 説明 | 偏差 |
|---|---|---|
| RFC 6337、セクション 5.3 メディアの保留と再開 | RFC では、"a=inactive"、"a=sendonly"、a=recvonly" を使用して通話を保留にできます。 | SIP プロキシは "a=inactive" のみをサポートしており、SBC が "a=sendonly" または "a=recvonly" を送信するかどうかはわかりません。 |
| RFC 6337、セクション 5.4 c=0.0.0.0 での SDP の受信に関する動作 | RFC3264 では、エージェントが 0.0.0.0 の接続アドレスを持つ SDP を受信でき、RTP または RTCP をピアに送信しないことを示す必要があります。 | SIP プロキシはこのオプションをサポートしていません。 |
| RFC 3261、セクション 25 SIP プロトコルの拡張 BNF | '#' 文字は '%23' として送信する必要があります | SIP プロキシは、要求 URI の '#' 文字をエスケープ解除して送信します。 |
| RFC 3264、セクション 8.3.1 SDP を使用したオファー/回答モデル | RFC 3264 では、セッションの確立後にメディア ポート、IP アドレス、またはトランスポートを変更できる MAY (省略可能) メディア リターゲット メカニズムについて詳しく説明します。 | オプションのメディアリターゲットはサポートされていません。 通話中、メディア ポート、IP アドレス、またはトランスポートを更新するための SIP 要求はサポートされていません。 メディアは更新されたセッション ターゲットに送信されません。ダイレクト ルーティングからのメディアは、引き続き元のターゲットに流れ続けます。 |
選択をサポートする RFC からの注意。オファーは、オファーが送信されるとすぐに、古いポートと新しいポートの両方でメディアを受信するように準備する必要があります。 オファー担当者は、応答が受信され、メディアが新しいポートに到着するまで、古いポートでのメディアのリッスンを停止しないでください。|
TCP/TLS トランスポートに関する考慮事項
Microsoft の SIP プロキシが SIP 要求 (新規またはインダイアログ) を送信すると、新しい TCP/TLS 接続を開いたり、既存の接続が存在する場合は再利用したりできます。
リモート FQDN/IP ごとに、各 SIP プロキシ仮想マシンごとに最大 2 つの TCP/TLS 接続が許可されます。 SIP 要求を送信する前に、SIP プロキシは、ターゲット SBC/トランク FQDN の解決された IP アドレスを使用してアクティブな TCP 接続をチェックします。 2 つの接続が存在する場合は、再利用されます。 2 つの接続が存在しない場合は、新しい接続が開きます。
このロジックは、SIP プロキシ仮想マシンごとです。
SIP プロキシ IP は、リージョンごとに複数の仮想マシンによって処理されます。
SBC の観点からは、すべての SIP プロキシ リージョンから複数の受信プロキシ接続が存在する可能性があります。
SIP プロキシによって開かれた TCP/TLS 接続は、呼び出しが行われる限り、必ずしも開いたままであるとは限りません。 ただし、SIP 要求への応答の直後に接続が閉じられません。 接続がタイムアウトしない場合は、他の SIP 要求で再利用される可能性があります。
SIP プロキシは、「 RFC 5923: セッション開始プロトコル (SIP) での接続の再利用」で説明されているように、接続の別名設定をサポートしていません。
送信 SIP プロキシ TCP 接続は、送信 SIP プロキシ要求 (SBC) と関連する応答のみをサービスします。
受信 SIP プロキシ TCP 接続 (SBC からの) は、受信 SIP 要求と関連する応答のみをサービスします。
特定の状況では、サードパーティのゲートウェイ/SBC が O365 サービスの TLS 接続リセットにフラグを設定する場合があることに注意してください。 ユーザー エクスペリエンスに影響を与えずに新しい接続が動的に構築されるため、接続のリセット動作が予想されます。
タイムアウト ポリシー
SIP プロキシ TCP アイドル タイムアウトは 2 分です。 接続を介して SIP トランザクションが発生すると、タイマーがリセットされます。
SIP プロキシは、RFC 5626: セッション開始プロトコル (SIP) での Client-Initiated Connections の管理に従ってアプリケーション CRLF キープアライブを送信します。
キープアライブは TCP アイドル タイマーをリセットしません。
サプライヤー SBC によって送信された CRLF キープアライブは、TCP アイドル タイマーをリセットします。
前述のエイリアシング制約により、サプライヤー SBC は、SIP プロキシがサプライヤー SBC に送信して作成した接続でタイマーをリセットするために、インダイアログ SIP 要求を使用しないでください。
2 分間のアイドリング (FIN、ACK) が、約 10 ~ 20 秒以内に SIP プロキシによってサプライヤー SBC に送信されます。
メモ
SBC は、SIP プロキシなどの接続をアクティブに再利用する必要があります。 このメソッドは、TCP および TLS 接続に必要な時間を節約します。
SBC は、少なくとも 1 時間に 1 回接続を更新する必要があります。
新しい SBC の証明書がアップロードされると、SBC はすべての接続を更新する必要があります。
ドメイン構成を更新するときは、SBC の接続を更新することをお勧めします。 それ以外の場合、内部 SIP プロキシ キャッシュが更新された後に新しい構成が適用されます (最大 4 時間)。
運用モード
ダイレクト ルーティングには、次の 2 つの操作モードがあります。
メディア バイパスなし 。すべての RTP トラフィックが Teams クライアント、メディア プロセッサ、および SBC の間を流れます。
Teams エンドポイントと SBC の間ですべての RTP メディアが流れるメディア バイパス。
SIP トラフィックは常に SIP プロキシを通過します。
DTMF
メディア スタックでは、インバンド DTMF はサポートされていません。