次の方法で共有

ダイレクト ルーティング - SIP プロトコル

  • [アーティクル]
  • 適用対象:
    Microsoft Teams

この記事では、ダイレクト ルーティングがセッション開始プロトコル (SIP) を実装する方法について説明します。 セッション ボーダー コントローラー (SBC) と SIP プロキシの間でトラフィックをルーティングするには、一部の SIP パラメーターに特定の値が必要です。 この記事は、オンプレミスの SBC と SIP プロキシ サービス間の接続の構成を担当する音声管理者を対象としています。

受信要求の処理: テナントとユーザーの検索

着信または送信呼び出しを処理する前に、SIP プロキシと SBC の間で OPTIONS メッセージが交換されます。 これらの OPTIONS メッセージを使用すると、SIP プロキシは SBC に許可される機能を提供できます。 OPTIONS ネゴシエーションを成功させるには (200OK 応答)、呼び出しを確立するための SBC と SIP プロキシ間の通信をさらに許可することが重要です。 SIP プロキシへの OPTIONS メッセージの SIP ヘッダーは、例として提供されます。

パラメーター名 値の例
Request-URI OPTIONS sip:sip.pstnhub.microsoft.com:5061 SIP /2.0
ヘッダー経由 Via: SIP/2.0/TLS sbc1.adatum.biz:5058;エイリアス;branch=z9hG4bKac2121518978
Max-Forwards ヘッダー Max-Forwards:68
ヘッダーから From Header From: sip:sbc1.adatum.biz:5058
ヘッダーへ To: sip:sip.pstnhub.microsoft.com:5061
CSeq ヘッダー CSeq: 1 INVITE
連絡先ヘッダー 連絡先: sip:sbc1.adatum.biz:50588;transport=tls

注意

SIP ヘッダーには、使用中の SIP URI に userinfo が含まれていません。 RFC 3261、セクション 19.1.1 に従って、URI の userinfo 部分は省略可能であり、宛先ホストにユーザーの概念がない場合、またはホスト自体が識別されるリソースである場合は存在しない可能性があります。 @記号が SIP URI に存在する場合は、ユーザー フィールドを空にしないでください。 SIPS URI はサポートされていないため、ダイレクト ルーティングでは使用しないでください。 セッション ボーダー コントローラーの構成を確認し、SIP 要求で "置換" ヘッダーを使用していないことを確認します。 ダイレクト ルーティングでは、置換ヘッダーが定義されている SIP 要求が拒否されます。

着信呼び出しでは、SIP プロキシは、通話の送信先のテナントを検索し、このテナント内の特定のユーザーを見つける必要があります。 テナント管理者は、複数のテナントで DID 以外の番号 (+1001 など) を構成できます。 そのため、複数の Microsoft 365 またはOffice 365組織で DID 以外の番号が同じ場合があるため、番号検索を実行する特定のテナントを見つけることが重要です。

このセクションでは、SIP プロキシがテナントとユーザーを検索し、受信接続で SBC の認証を実行する方法について説明します。

着信コールの SIP 招待メッセージの例を次に示します。

パラメーター名 値の例
Request-URI INVITE sip:+18338006777@sip.pstnhub.microsoft.com SIP /2.0
ヘッダー経由 Via: SIP/2.0/TLS sbc1.adatum.biz:5058;エイリアス;branch=z9hG4bKac2121518978
Max-Forwards ヘッダー Max-Forwards:68
ヘッダーから From Header From: <sip:+17168712781@sbc1.adatum.biz;transport=udp;tag=1c747237679
ヘッダーへ To: sip:+183338006777@sbc1.adatum.biz
CSeq ヘッダー CSeq: 1 INVITE
連絡先ヘッダー 連絡先: sip:+17168712781@sbc1.adatum.biz:5058;transport=tls

招待を受信すると、SIP プロキシは次の手順を実行します。

  1. 証明書を確認します。 最初の接続では、ダイレクト ルーティング サービスは Contact ヘッダーに表示される FQDN 名を受け取り、提示された証明書の共通名またはサブジェクトの別名と一致します。 SBC 名は、次のいずれかのオプションと一致する必要があります。

    • オプション 1。 Contact ヘッダーに表示される完全な FQDN 名は、提示された証明書の共通名/サブジェクトの別名と一致する必要があります。

    • オプション 2。 Contact ヘッダーに表示される FQDN 名のドメイン部分 (FQDN 名 sbc1.adatum.biz の adatum.biz など) は、共通名/サブジェクトの別名 (例: *.adatum.biz) のワイルドカード値と一致する必要があります。

  2. 連絡先ヘッダーに表示される完全な FQDN 名を使用してテナントを見つけてください。

    連絡先ヘッダー (sbc1.adatum.biz) の FQDN 名が、Microsoft 365 または Office 365 organizationの DNS 名として登録されているかどうかを確認します。 見つかった場合、SBC FQDN がドメイン名として登録されているテナントでユーザーの検索が実行されます。 見つからない場合は、手順 3 が適用されます。

  3. 手順 3 は、手順 2 が失敗した場合にのみ適用されます。

    連絡先ヘッダー (ホスト部分を削除した後、FQDN: sbc12.adatum.biz: adatum.biz) に表示されている FQDN からホスト部分を削除し、この名前が Microsoft 365 または Office 365 organizationで DNS 名として登録されている場合はチェックします。 見つかった場合、このテナントでユーザー参照が実行されます。 見つからない場合、呼び出しは失敗します。

  4. Request-URI に表示されている電話番号を使用して、手順 2 または 3 で見つかったテナント内で逆引き番号の参照を実行します。 提示された電話番号を、前の手順で見つかったテナント内のユーザー SIP URI と一致させます。

  5. トランク設定を適用します。 この SBC のテナント管理者によって設定されたパラメーターを見つけます。

    Microsoft では、Microsoft SIP プロキシとペアリングされた SBC の間にサードパーティの SIP プロキシまたはユーザー エージェント サーバーを使用することはサポートされていません。これにより、ペアリングされた SBC によって作成された要求 URI が変更される可能性があります。

    1 つの SBC が多くのテナントに相互接続されるシナリオ (通信事業者のシナリオ) に必要な 2 つの参照 (手順 2 と 3) の要件については、この記事の後半で説明します。

連絡先ヘッダーと Request-URI の詳細な要件

連絡先ヘッダー

Microsoft SIP プロキシへのすべての受信 SIP メッセージ (OPTIONS、INVITE) の場合、連絡先ヘッダーには、次のように URI ホスト名にペアリングされた SBC FQDN が必要です。

構文: 連絡先: <SBC の sip:phone または sip address@FQDN。transport=tls>

RFC 3261 セクション 11.1 に従って、連絡先ヘッダー フィールドが OPTIONS メッセージに存在する場合があります。 ダイレクト ルーティングでは、連絡先ヘッダーが必要です。 上記の形式の INVITE メッセージの場合、OPTIONS メッセージの場合、userinfo を SIP URI から削除し、次のように形式で送信された FQDN のみを削除できます。

構文: 連絡先: <SBC の sip:FQDN;transport=tls>

この名前 (FQDN) は、提示された証明書の [共通名] フィールドまたは [サブジェクトの別名] フィールドにも存在する必要があります。 Microsoft では、証明書の [共通名] フィールドまたは [サブジェクトの別名] フィールドの名前のワイルドカード値の使用がサポートされています。

ワイルドカードのサポートについては、 RFC 2818 セクション 3.1 で説明されています。 具体的には：

"名前にはワイルドカード文字 *が含まれている場合があります。これは、単一のドメイン名コンポーネントまたはコンポーネント フラグメントと一致すると見なされます。 たとえば、*.a.com は foo.a.com と一致しますが、bar.foo.a.com は一致しません。 f*.com は foo.com と一致しますが、bar.com は一致しません。

SIP メッセージで提示される Contact ヘッダーの複数の値が SBC によって送信される場合、Contact ヘッダーの最初の値の FQDN 部分のみが使用されます。

ダイレクト ルーティングの場合は、IP ではなく SIP URI を設定するために FQDN を使用することが重要です。 ホスト名が FQDN ではなく IP で表される連絡先ヘッダーを含む SIP プロキシへの着信 INVITE または OPTIONS メッセージは、403 Forbidden で拒否されます。

Request-URI

すべての着信呼び出しでは、Request-URI を使用して電話番号をユーザーに一致させます。

現在、電話番号には、次の例に示すようにプラス記号 (+) が含まれている必要があります。

INVITE sip:+18338006777@sip.pstnhub.microsoft.com SIP /2.0

ヘッダーから

すべての着信呼び出しでは、From ヘッダーを使用して、発信者の電話番号を呼び出し先のブロックされた電話番号リストと照合し、逆引き番号検索を実行して、既存のテナントおよびユーザー レコードから発信者の名前を検索するために使用されます。

これらの検索を機能させるには、次の例に示すように、電話番号に + を含める必要があります。

From: <sip:+17168712781@sbc1.adatum.biz;transport=udp;tag=1c747237679

連絡先ヘッダーと Record-Route ヘッダーに関する考慮事項

SIP プロキシは、新しいダイアログ内クライアント トランザクション (例: Bye や Re-Invite) のネクスト ホップ FQDN を計算し、SIP オプションに応答する場合に計算する必要があります。 連絡先または Record-Route が使用されます。

RFC 3261、セクション 8.1.1.8 によると、新しいダイアログが発生する可能性がある要求には Contact ヘッダーが必要です。 Record-Route は、プロキシがダイアログ内の今後の要求のパスを維持する場合にのみ必要です。 プロキシ SBC が 直接ルーティング用のローカル メディア最適化で使用されている場合は、プロキシ SBC がルートに留まる必要がある場合は、レコード ルートを構成する必要があります。

プロキシ SBC が使用されていない場合は、Contact ヘッダーのみを使用することをお勧めします。

  • RFC 3261 セクション 20.30 では、プロキシがダイアログ内の将来の要求のパスを維持したい場合に Record-Route が使用されます。これは、すべてのトラフィックが Microsoft SIP プロキシとペアリングされた SBC の間を行く際にプロキシ SBC が構成されていない場合は必須ではありません。

  • Microsoft SIP プロキシは、送信 ping オプションを送信するときに、Contact ヘッダー (Record-Route ではなく) のみを使用して次ホップを決定します。 プロキシ SBC が使用されていない場合は、2 つのパラメーター (Contact と Record-Route) ではなく 1 つのパラメーター (Contact) のみを構成すると、管理が簡略化されます。

次ホップを計算するために、SIP プロキシは次を使用します。

  • 優先度 1。 最上位のレコード ルート。 最上位の Record-Route に FQDN 名が含まれている場合は、FQDN 名を使用して送信インダイアログ接続を行います。

  • 優先順位 2。 連絡先ヘッダー。 Record-Route が存在しない場合、SIP プロキシは Contact ヘッダーの値を検索して送信接続を確立します。 (これは推奨される構成です)。

連絡先と Record-Route の両方を使用する場合、SBC 管理者は値を同じにしておく必要があります。これにより、管理オーバーヘッドが発生します。

連絡先または Record-Route での FQDN 名の使用

ip アドレスの使用は、Record-Route または連絡先ではサポートされていません。 唯一サポートされるオプションは FQDN です。これは、SBC 証明書の共通名またはサブジェクトの別名 (証明書のワイルドカード値がサポートされています) と一致する必要があります。

  • [レコード ルート] または [連絡先] に IP アドレスが表示されている場合、証明書チェック失敗し、呼び出しは失敗します。

  • 提示された証明書の Common または Subject Alternative Name の値と FQDN が一致しない場合、呼び出しは失敗します。

受信呼び出し: SIP ダイアログの説明

次の表は、非バイパス モードとバイパス モードの間の呼び出しフローの違いと類似点をまとめたものです。

パラメーター名 非バイパス モード バイパス モード
183 および 200 メッセージのメディア候補 メディア プロセッサ クライアント
SBC が受信できる 183 メッセージの数 セッションごとに 1 つ 複数
通話は暫定的な回答で行うことができます (183) はい Yes
通話は仮応答なしで実行できます (183) はい Yes

メディア以外のバイパス フロー

Teams ユーザーは、同時に複数のエンドポイントを持つ場合があります。 たとえば、Teams for Windows クライアント、Teams for iPhone クライアント、Teams 電話 (Teams Android クライアント) などです。 各エンドポイントは、次のように HTTP Rest を通知する場合があります。

  • 通話の進行状況 – SIP プロキシによって SIP メッセージ 180 に変換されます。 メッセージ 180 の受信時に、SBC はローカル呼び出しを生成する必要があります。

  • メディア応答 – SIP プロキシによって、セッション記述プロトコル (SDP) のメディア候補を含むメッセージ 183 に変換されます。 メッセージ 183 を受信すると、SBC は SDP メッセージで受信したメディア候補に接続することを想定します。

    注意

    場合によっては、メディアの応答が生成されず、エンドポイントが "Call Accepted" メッセージで応答する場合があります。

  • 通話が受け入れ済み – SIP プロキシによって SDP を使用して SIP メッセージ 200 に変換されます。 メッセージ 200 の受信時に、SBC は提供された SDP 候補との間でメディアを送受信する必要があります。

    注意

    ダイレクト ルーティングでは、遅延オファーの招待 (SDP なしで招待) はサポートされていません。

暫定的な回答で複数のエンドポイントが呼び出される

  1. SBC から最初の招待を受信すると、SIP プロキシは "SIP SIP/2.0 100 Trying" というメッセージを送信し、着信呼び出しについてすべてのエンド ユーザー エンドポイントに通知します。

  2. 通知時に、各エンドポイントが呼び出しを開始し、SIP プロキシに "通話の進行状況" メッセージを送信します。 Teams ユーザーは複数のエンドポイントを持つ可能性があるため、SIP プロキシは複数の通話進行状況メッセージを受信する可能性があります。

  3. クライアントから受信した通話の進行状況メッセージごとに、SIP プロキシは通話の進行状況メッセージを SIP メッセージ "SIP/2.0 180 Ringing" に変換します。 このようなメッセージを送信する間隔は、呼び出しコントローラーからのメッセージを受信する間隔によって定義されます。 次の図では、SIP プロキシによって生成された 2 つの 180 メッセージがあります。 これらのメッセージは、ユーザーの 2 つの Teams エンドポイントから送信されます。 クライアントはそれぞれ一意のタグ ID を持っています。 異なるエンドポイントから送信されるすべてのメッセージは個別のセッションです ("To" フィールドのパラメーター "tag" は異なります)。 ただし、次の図に示すように、エンドポイントでメッセージ 180 が生成され、メッセージ 183 がすぐに送信されない場合があります。

  4. エンドポイントがエンドポイントのメディア候補の IP アドレスを含む Media Answer メッセージを生成すると、SIP プロキシは、受信したメッセージを、メディア プロセッサの SDP に置き換えられたクライアントからの SDP を使用して、受信したメッセージを "SIP 183 セッションの進行状況" メッセージに変換します。 次の図では、Fork 2 のエンドポイントが呼び出しに応答しました。 トランクがバイパスされていない場合、183 SIP メッセージは 1 回だけ生成されます (リング ボットまたはクライアント エンドポイント)。 183 は、既存のフォークに付属するか、新しいフォークを開始する可能性があります。

  5. 通話の受け入れメッセージは、呼び出しを受け入れたエンドポイントの最終的な候補と共に送信されます。 通話受付メッセージは SIP メッセージ 200 に変換されます。

暫定的な回答で複数のエンドポイントが呼び出されていることを示す図。

暫定的な回答なしで呼び出される複数のエンドポイント

  1. SBC から最初の招待を受信すると、SIP プロキシは "SIP SIP/2.0 100 Trying" というメッセージを送信し、着信呼び出しについてすべてのエンド ユーザー エンドポイントに通知します。

  2. 通知時に、各エンドポイントが呼び出しを開始し、SIP プロキシに "通話の進行状況" というメッセージを送信します。 Teams ユーザーは複数のエンドポイントを持つ可能性があるため、SIP プロキシは複数の通話進行状況メッセージを受信する可能性があります。

  3. クライアントから受信した通話進行状況メッセージごとに、SIP プロキシは通話の進行状況メッセージを SIP メッセージ "SIP/2.0 180 Trying" に変換します。 メッセージを送信する間隔は、呼び出しコントローラーからメッセージを受信する間隔によって定義されます。 次の図では、SIP プロキシによって生成される 2 つの 180 メッセージがあります。つまり、ユーザーが 3 つの Teams クライアントにログインし、各クライアントが通話の進行状況を送信しています。 すべてのメッセージは個別のセッションです ("To" フィールドのパラメーター "tag" は異なります)

  4. 通話の受け入れメッセージは、呼び出しを受け入れたエンドポイントの最終的な候補と共に送信されます。 通話受付メッセージは SIP メッセージ 200 に変換されます。

暫定的な回答なしで複数のエンドポイントが呼び出されていることを示す図。

メディア バイパス フロー

メディア バイパス シナリオでは、同じメッセージ (100 Trying、180、183) が使用されます。

次のスキーマは、バイパス呼び出しフローの例を示しています。

注意

メディア候補は、さまざまなエンドポイントから取得できます。

メディア バイパス フローを示す図。

Replaces オプション

SBC は、置換による招待をサポートする必要があります。

SDP に関する考慮事項のサイズ

ダイレクト ルーティング インターフェイスは、1,500 バイトを超える SIP メッセージを送信する可能性があります。 SDP のサイズは主にこれが原因です。 ただし、SBC の背後に UDP トランクがある場合は、メッセージが Microsoft SIP プロキシから変更されていないトランクに転送されている場合は、メッセージを拒否する可能性があります。 メッセージを UDP トランクに送信するときに、SBC の SDP の一部の値を削除することをお勧めします。 たとえば、ICE 候補や未使用のコーデックを削除できます。

呼び出し転送

ダイレクト ルーティングでは、呼び出し転送に次の 2 つの方法がサポートされています。

  • オプション 1。 SIP プロキシ プロセス クライアントからローカルで参照し、RFC 3892 のセクション 7.1 で説明されているようにレフリーとして機能します。

    このオプションを使用すると、SIP プロキシは転送を終了し、新しい招待を追加します。

  • オプション 2。 SIP プロキシは SBC に参照を送信し、RFC 5589 のセクション 6 で説明されているように転送者として機能します。

    このオプションを使用すると、SIP プロキシは Refer to the SBC を送信し、SBC が転送を完全に処理することを想定します。

SIP プロキシは、SBC によって報告される機能に基づいてメソッドを選択します。 SBC がメソッド "Refer" をサポートすることを示している場合、SIP プロキシは通話転送にオプション 2 を使用します。

次に、Refer メソッドがサポートされているというメッセージを送信する SBC の例を示します。

ALLOW: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

SBC で [サポートされている方法として参照する] が示されていない場合、ダイレクト ルーティングではオプション 1 が使用されます (SIP プロキシはレフリーとして機能します)。 また、SBC は Notify メソッドをサポートしていることを通知する必要があります。

Refer メソッドがサポートされていないことを示す SBC の例:

ALLOW: INVITE, ACK, CANCEL, BYE, INFO, NOTIFY, PRACK, UPDATE, OPTIONS

SIP プロキシ プロセス クライアントからローカルで参照し、レフリーとして機能する

SBC が Refer メソッドがサポートされていないことを示した場合、SIP プロキシはレフリーとして機能します。

クライアントから送信された Refer 要求は、SIP プロキシで終了します。 次の図では、クライアントからの Refer 要求が "Dave への呼び出し転送" として表示されます。 詳細については、 RFC 3892 のセクション 7.1 を参照してください。

クライアント Bob から Dave への参照要求を示す図。

SIP プロキシは SBC を参照し、転送者として機能します送信します

これは通話転送に推奨される方法であり、メディア バイパス認定を求めるデバイスでは必須です。 SBC が Refer を処理できない通話転送は、メディア バイパス モードではサポートされていません。

標準は RFC 5589 のセクション 6 で説明されています。 関連する RFC は次のとおりです。

このオプションは、SIP プロキシが転送者として機能し、Refer メッセージを SBC に送信することを前提としています。 SBC は譲渡者として機能し、移転のための新しいオファーを生成するために参照を処理します。 次の 2 つのケースが考えられます。

  • 通話は外部 PSTN 参加者に転送されます。
  • 呼び出しは、ある Teams ユーザーから、SBC 経由で同じテナント内の別の Teams ユーザーに転送されます。

通話が SBC を介して Teams ユーザーから別の Teams ユーザーに転送された場合、SBC は、参照メッセージで受信した情報を使用して、転送先 (Teams ユーザー) に対して新しい招待 (新しいダイアログを開始) を発行する必要があります。

要求のトランザクションに対して To/Transferor フィールドを内部的に設定するには、SIP プロキシで REFER-TO/REFERRED-BY ヘッダー内でこの情報を伝達する必要があります。

SIP プロキシは、ホスト名内の SIP プロキシ FQDN と次のいずれかで構成される SIP URI として REFER-TO を形成します。

  • 転送先が電話番号の場合、URI のユーザー名部分の E.164 電話番号。

  • 完全転送ターゲット MRI とテナント ID をそれぞれエンコードする x-m パラメーターと x-t パラメーター

REFERRED-BY ヘッダーは、次の表に示すように、転送元の MRI がエンコードされた SIP URI と、転送者テナント ID およびその他の転送コンテキスト パラメーターです。

パラメーター 値 説明
x-m Mri CCによって設定された転送器/転送ターゲットの完全なMRI
x-t テナント ID x-t テナント ID CC によって設定されるオプションのテナント ID
x-ti Transferor の関連付け ID 転送者への呼び出しの相関 ID
x-tt 転送先の呼び出し URI エンコードされた呼び出し置換 URI

この場合、参照ヘッダーのサイズは最大 400 個のシンボルにすることができます。 SBC では、最大 400 個のシンボルを持つ Refer メッセージの処理をサポートする必要があります。

参照プロセスを示す図。

転送を呼び出す

Teams ユーザーは、別の番号または Teams ユーザーに着信通話を転送したり、他のユーザーまたはユーザーを並行して呼び出したり (同時呼び出し)、ユーザーまたは番号のグループを呼び出したりできます。 次の状況について検討しましょう。

  • SIP プロキシからユーザー C への INVITE 要求の Request-URI には 、cause パラメーターが含まれています。

  • トランク構成 (ForwardCallHistory パラメーター) に基づいて、History-Info ヘッダーが設定されます。

  • ユーザー A が別の PSTN ユーザーである場合、SIP プロキシは、ユーザー A に対して "SIP SIP/2.0 181 通話が転送されている" 暫定的な応答を生成します。

  • ユーザー A とユーザー C が PSTN ユーザーの場合、SIP プロキシは"SIP SIP/2.0 181 通話が転送されている" 暫定的な応答を保持します。

  • History-Info ヘッダーは、ループ防止に使用する必要があります。

セッション タイマー

SIP プロキシは、非バイパス呼び出しではセッション タイマーをサポート (常に提供) しますが、バイパス呼び出しでは提供しません。 SBC によるセッション タイマーの使用は必須ではありません。

Request-URI パラメーター user=phone の使用

SIP プロキシは要求 URI を分析し、パラメーター user=phone が存在する場合、サービスは要求 URI を電話番号として処理し、その番号をユーザーに一致させます。 パラメーターが存在しない場合、SIP プロキシはヒューリスティックを適用して、要求 URI ユーザーの種類 (電話番号または SIP アドレス) を決定します。

Microsoft では、呼び出しのセットアップ プロセスを簡略化するために、常に user=phone パラメーターを適用することをお勧めします。

History-Info ヘッダー

History-Info ヘッダーは、SIP 要求の再ターゲットに使用され、「要求履歴情報をキャプチャするための標準的なメカニズムを提供して、ネットワークとエンド ユーザーに対してさまざまなサービスを有効にする」。 詳細については、「 RFC 4244 – セクション 1.1」を参照してください。 Microsoft Phone System の場合、このヘッダーは Simulring シナリオと通話転送シナリオで使用されます。

送信する場合、History-Info は次のように有効になります。

  • SIP プロキシは、PSTN コントローラーに送信される History-Info ヘッダーを構成する個々の History-Info エントリに、関連付けられた電話番号を含むパラメーターを挿入します。 PSTN コントローラーは、電話番号パラメーターを持つエントリのみを使用して、新しい History-Info ヘッダーを再構築し、SIP プロキシ経由で SIP トランク プロバイダーに渡します。

  • History-Info ヘッダーは、同時呼び出しと呼び出し転送の場合に追加されます。

  • History-Info ヘッダーは、通話転送ケースには追加されません。

  • 再構築された History-Info ヘッダーの個々の履歴エントリには、URI のホスト部分として設定されたダイレクト ルーティング FQDN (sip.pstnhub.microsoft.com) と組み合わせて提供される電話番号パラメーターが含まれます。'user=phone' のパラメーターが SIP URI の一部として追加されます。 元の History-Info ヘッダーに関連付けられているその他のパラメーター (電話コンテキスト パラメーターを除く) は、再作成された History-Info ヘッダーで渡されます。

    注意

    プライベート (RFC 4244 のセクション 3.3 で定義されているメカニズムによって決定される) エントリは、SIP トランク プロバイダーが信頼できるピアであるため、そのまま転送されます。

  • ForwardCallHistory パラメーターが有効になっている場合、受信 History-Info は保持されます。 保持された History-Info は、ループ防止に使用できます。

SIP プロキシによって送信される履歴情報ヘッダーの形式を次に示します。

<sip:UserB@sip.pstnhub.microsoft.com?Privacy=history&Reason=SIP%3Bcause%3D486>;index=1.2

呼び出しが複数回リダイレクトされた場合、すべてのリダイレクトに関する情報は、コンマ区切りのリストに、時系列で適切な理由で含まれます。

ヘッダーの例:

History-Info:
  <sip:+14257123456@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D302%3Btext%3D%22Moved%20temporarily%22>;index=1,
  <sip:+14257123456@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D496%3Btext%3D%22User%20Busy%22>;index=1.1

History-Info ヘッダーの SIP URI は、RFC 3261 のセクション 25 に従って書式設定されます (の addr-spec定義を参照してください)。 前の例では、URI ヘッダーReasonの元のテキストは ですSIP;cause=496;text="User Busy"。これは、それぞれ、ASCII の 16 進値 %3B、、%22および 3Dにエスケープされた文字を取得;"=します。

History-Info は、必須の TLS メカニズムによって保護されます。

ダイレクト ルーティングとフェールオーバー メカニズムへの SBC 接続

「 ダイレクト ルーティングの計画」の「SIP シグナリングのフェールオーバー メカニズム」セクションを参照してください。

Retry-After

ダイレクト ルーティング データセンターがビジー状態の場合、サービスは 1 秒間隔で Retry-After メッセージを SBC に送信できます。 SBC が INVITE に応答して Retry-After ヘッダーを持つ 503 メッセージを受信した場合、SBC はその接続を終了し、次に使用可能な Microsoft データセンターを試す必要があります。

再試行の処理 (603 応答)

エンド ユーザーが着信呼び出しを拒否した後に 1 回の通話に対して複数の不在着信を確認した場合、SBC または PSTN トランク プロバイダーの再試行メカニズムが正しく構成されていないことを意味します。 603 応答の再試行作業を停止するには、SBC を再構成する必要があります。

ICE 再起動: メディア バイパスをサポートしていないエンドポイントに転送されるメディア バイパス呼び出し

SBC は、 RFC 5245、セクション 9.1.1.1 で説明されているように、ICE 再起動をサポートする必要があります。

ダイレクト ルーティングでの再起動は、RFC の次の段落に従って実装されます。

ICE を再起動するには、エージェントがオファー内のメディア ストリームの ice-pwd と ice-ufrag の両方を変更する必要があります。 1 つのオファーでセッション レベルの属性を使用することは許可されますが、それ以降のオファーでメディア レベルの属性と同じ ice-pwd または ice-ufrag を提供できます。 これはパスワードの変更ではなく、表現の変更に過ぎず、ICE の再起動は発生しません。

エージェントは、このメディア ストリームの初期オファーと同様に、このメディア ストリームの SDP 内の残りのフィールドを設定します (セクション 4.3 を参照)。 そのため、候補のセットには、そのストリームの前の候補の一部、なし、またはすべてを含めることができます。また、セクション 4.1.1 で説明されているように収集された新しい候補のセットが含まれる場合があります。

呼び出しが最初にメディア バイパスで確立され、呼び出しがSkype for Business クライアントに転送された場合、ダイレクト ルーティングはメディア プロセッサを挿入する必要があります。これは、ダイレクト ルーティングをメディア バイパスでSkype for Business クライアントで使用できないためです。 ダイレクト ルーティングは、ice-pwd と ice-ufrag を変更し、新しいメディア候補を再招待で提供することで、ICE 再起動プロセスを開始します。