次の方法で共有

Azure Communication Services ダイレクト ルーティング: SIP プロトコルの詳細

  • [アーティクル]

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

受信要求の処理: Communication Services リソースの検索

Note

Azure Communication Services では、ダイレクト ルーティングによる SIP オプションが既定で有効になっており、無効にすることはできません。 SIP プロキシは SBC が交換を開始するまで待機するため、SBC は最初に OPTIONS 交換を開始する必要があります。

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

パラメーター名 値の例
Request-URI OPTIONS sip:sip.pstnhub.microsoft.com:5061 SIP /2.0
Via ヘッダー Via: SIP/2.0/TLS sbc1.contoso.com:5061;alias;branch=z9hG4bKac2121518978
Max-Forwards ヘッダー Max-Forwards:68
From ヘッダー From ヘッダー: sip:sbc1.contoso.com:5061
To ヘッダー To: sip:sip.pstnhub.microsoft.com:5061
CSeq ヘッダー CSeq: 1 INVITE
Contact ヘッダー Contact: sip:sbc1.contoso.com:5061;transport=tls

Note

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

着信呼び出しでは、SIP プロキシは、呼び出し先の Azure Communication リソースを検索する必要があります。 このセクションでは、SIP プロキシがリソースを検索し、受信接続で SBC の認証を実行する方法について説明します。

着信コールの SIP 招待メッセージの例:

パラメーター名 値の例
Request-URI INVITE sip:+54321@sip.pstnhub.microsoft.com SIP /2.0
Via ヘッダー Via: SIP/2.0/TLS sbc1.contoso.com:5061;alias;branch=z9hG4bKac2121518978
Max-Forwards ヘッダー Max-Forwards:68
From ヘッダー From ヘッダー: <sip:+12345@sbc1.contoso.com;transport=udp;tag=1c68821811
To ヘッダー To: sip:+54321@sbc1.contoso.com
CSeq ヘッダー CSeq: 1 INVITE
Contact ヘッダー Contact: sip:+12345@sbc1.contoso.com:5061;transport=tls

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

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

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

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

  2. 連絡先ヘッダーに表示される完全な FQDN 名を使用して、Microsoft 365 テナントを検索してみてください。

    連絡先ヘッダー (sbc1.contoso.com) の FQDN 名が、Microsoft 365 または Office 365 組織の DNS 名として登録されているかどうかを確認してください。 登録されている場合、SBC FQDN がドメイン名として登録されているテナントでユーザーの参照が実行されます。 登録されていない場合は、手順 3 が適用されます。

  3. Contact ヘッダーに表示される完全な FQDN 名を使用して、Azure Communication リソースを検索してみてください。

    Contact ヘッダー (sbc1.contoso.com) の FQDN 名が、任意の Azure Communication リソースで SBC FQDN として登録されているかどうかを確認します。 登録されている場合は、そのリソースに呼び出しが送信されます。 登録されていない場合は、手順 4 が適用されます。

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

    連絡先ヘッダー (FQDN: sbc1.contoso.com、ホスト部分 contoso.com を削除した後) に表示される FQDN からホスト部分を削除し、この名前が Microsoft 365 または Office 365 組織の DNS 名として登録されているかどうかを確認します。 登録されている場合は、このテナントでユーザー参照が実行されます。 登録されていない場合、呼び出しは失敗します。

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

    ホスト部分を削除した後、Contact ヘッダー (FQDN: sbc1.contoso.com、ホスト部分: contoso.com) に表示される FQDN からホスト部分を削除し、この名前が任意の Azure Communication リソースで SBC FQDN として登録されているかどうかを確認します。 登録されている場合は、そのリソースに呼び出しが送信されます。 登録されていない場合、呼び出しは失敗します。

  6. リソースに Dynamics Omnichannel デプロイが関連付けられている場合は、Request-URI に表示される電話番号の検索を実行します。 表示された電話番号を、前の手順で見つかったオムニチャネル ユーザー (キュー) と一致させます。

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

    通信リソースにオムニチャネルデプロイが存在しない場合、または Request-URI の番号が構成されたオムニチャネル番号と一致しない場合は、Event Grid に呼び出しを送信します。

  8. 手順 8 は、手順 7 で失敗した場合にのみ適用されます。

    Event Grid が構成されていない場合、または着信呼び出しを管理する規則がない場合、呼び出しは破棄されます。

Contact ヘッダーと Request-URI の詳細な要件

Contact ヘッダー

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

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

RFC 3261、セクション 11.1 に従って、OPTIONS メッセージに Contact ヘッダー フィールドが存在する場合があります。 ダイレクト ルーティングでは、連絡先ヘッダーが必要です。 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 but not bar.com と一致します。"

SBC によって SIP メッセージに表示される Contact ヘッダー内の複数の値の場合、Contact ヘッダーの最初の値の FQDN 部分のみが使用されます。 直接ルーティングの経験則として、FQDN を使用して IP ではなく SIP URI を設定することが重要です。 ホスト名が FQDN ではなく IP で表される SIP プロキシへの着信 INVITE または OPTIONS メッセージ。接続は 403 Forbidden で拒否されます。

Request-URI

すべての着信呼び出しでは、Request-URI を使用して呼び出し先を識別します。 現在、電話番号には、次の例に示すようにプラス記号 (+) が含まれている必要があります。

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

From ヘッダー

すべての着信呼び出しでは、発信者の電話番号と一致させるために From ヘッダーが使用されます。

電話番号は、次の例に示すように + が含まれている必要があります。

From: <sip:+12345@sbc1.contoso.com;transport=udp;tag=1c68821811

連絡先ヘッダーとレコード ルート ヘッダーに関する考慮事項

SIP プロキシは、新しいダイアログ内クライアント トランザクション (Bye や Re-Invite など) の次ホップ FQDN を計算し、SIP OPTIONS に応答する場合に計算する必要があります。 これは、Contact または Record-Route を使用して実行できます。 RFC 3261、セクション 8.1.1.8 によると、新しいダイアログが発生する可能性のある要求には Contact ヘッダーが必要です。 Record-Route は、プロキシがダイアログ内の今後の要求のパスを維持する必要がある場合にのみ必要です。

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

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

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

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

連絡先またはレコード ルートでの FQDN 名の使用

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

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

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

呼び出しコンテキスト ヘッダー

呼び出しコンテキスト ヘッダーは現在、Call Automation SDK でのみ利用できます。 Call Automation SDK では、ユーザー間ヘッダーと最大 5 つのカスタム SIP ヘッダーがサポートされます。 これらのヘッダーは INVITE メソッドと REFER メソッドでサポートされています。

ユーザー間ヘッダー

SIP ユーザー間 (UUI) ヘッダーは、呼び出し設定プロセス中に前後関係情報を渡す業界標準です。 UUI ヘッダー キーの最大長は 64 文字です。 UUI ヘッダー値の最大長は 256 文字です。 UUI ヘッダー値は、英数字と、=、;、.、!、%、*、_、+、~、- など、一部の記号で構成されることがあります。

カスタム ヘッダー

Azure Communication Services では、最大 5 つのカスタム SIP ヘッダーもサポートされています。 カスタム SIP ヘッダー キーは、必須の X-MS-Custom- プレフィックスで始まる必要があります。 SIP ヘッダー キーの最大長は、X-MS-Custom- プレフィックスを含めて 64 文字です。 SIP ヘッダー キーは、英数字と、.、!、%、*、_、+、~、- など、一部の記号で構成されることがあります。 SIP ヘッダー値の最大長は 256 文字です。 SIP ヘッダー値は、英数字と、=、;、.、!、%、*、_、+、~、- など、一部の記号で構成されることがあります。

実装の詳細については、「呼び出し間でコンテキスト データを渡す方法」を参照してください。

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

SIP プロキシが着信呼び出しを処理する方法の詳細を次に示します。

パラメーター名 値
183 および 200 メッセージのメディア候補 メディア プロセッサ
SBC が受信できる 183 メッセージの数 セッションごとに 1 つ
呼び出しは仮応答で行うことができます (183) はい
呼び出しは仮応答なしで行うことができます (183) はい

Azure Communication Services ID は、複数のエンドポイント (アプリケーション) で同時に使用される場合があります。 たとえば、Web アプリ、iPhone アプリ、Android アプリなどです。 各エンドポイントは、次のように HTTP Rest を通知する場合があります。

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

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

    Note

    場合によっては、メディア応答が生成されず、エンドポイントが「呼び出し受付済み」メッセージで応答することがあります。。

  • 呼び出し受付済み – SIP プロキシによって SDP を使用して SIP メッセージ 200 に変換されました。 メッセージ 200 の受信後に、SBC は提供された SDP 候補との間でメディアを送受信することを期待します。

    Note

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

仮回答で呼び出される複数のエンドポイント

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

  2. 通知後、各エンドポイントが呼び出しを開始し、"呼び出しの進行状況” メッセージを SIP プロキシに送信します。 Azure Communication Services ID は複数のエンドポイントで使用されるため、SIP プロキシは複数の呼び出しの進行状況メッセージを受信する可能性があります。

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

  4. エンドポイントが、エンドポイントのメディア候補の IP アドレスを含むメディア応答メッセージを生成すると、SIP プロキシは、受信したメッセージを、メディア プロセッサの SDP に置き換えられたエンドポイントからの SDP を含む "SIP 183 セッションの進行状況" メッセージに変換します。 次の図では、Fork 2 のエンドポイントが呼び出しに応答しました。 183 SIP メッセージは 1 回だけ生成されます。 183 は、既存のフォークから起動されるか、新しいフォークが起動されます。

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

    仮回答で呼び出される複数のエンドポイントを示す図。

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

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

  2. 通知後、各エンドポイントが呼び出しを開始し、"呼び出しの進行状況” メッセージを SIP プロキシに送信します。 複数のアプリケーションで同じ Azure Communication Services ID を使用できるため、SIP プロキシは複数の呼び出しの進行状況メッセージを受信する可能性があります。

  3. エンドポイントから受信した呼び出しの進行状況メッセージごとに、SIP プロキシは呼び出しの進行状況メッセージを SIP メッセージ "SIP/2.0 180 リング" に変換します。 メッセージを送信する間隔は、呼び出しコントローラーからメッセージを受信する間隔に関連付けられます。 図には、SIP プロキシによって生成された 2 つの 180 メッセージがあります。つまり、呼び出しは 2 つの異なるクライアントにフォークされ、各クライアントは呼び出しの進行状況を送信します。 すべてのメッセージは個別のセッションです (「To」フィールドのパラメーター「タグ」が異なります)

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

    仮回答なしで呼び出される複数のエンドポイントを示す図。

置換オプション

SBC は置換を使用した招待をサポートしている必要があります。

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

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

コール転送

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

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

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

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

    このオプションを使用すると、SIP プロキシは Refer を SBC に送信し、SBC が転送をすべて処理することを期待します。

SIP プロキシは、SBC によって報告される機能に基づいてメソッドを選択します。 SBC が “Refer” メソッドをサポートしていることを示している場合、SIP プロキシは呼び出し転送にオプション 2 を使用します。 Refer メソッドがサポートされているというメッセージを送信する SBC の例を次に示します。

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

SBC が Refer をサポートされているメソッドとして示していない場合、ダイレクト ルーティングはオプション 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 を参照してください。

SIP プロキシがレフリーとして機能する通話転送を示す図。

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

転送者としての SIP プロキシは、呼び出し転送に推奨される方法です。

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

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

  • 呼び出しは外部 PSTN 参加者に転送されます。
  • 呼び出しは、SBC を介して、ある SDK エンドポイントから同じリソース内の別の SDK エンドポイントに転送されます。

呼び出しが SBC を介して 1 つの SDK エンドポイントから別の SDK エンドポイントに転送された場合、SBC は、Refer メッセージで受信した情報を使用して、転送ターゲットに対して新しい招待 (新しいダイアログを開始) を発行することを期待します。 要求のトランザクションの 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

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

SIP プロキシが転送者として機能する通話転送を示す図。

着信の転送

Azure Communication Services Call Automation SDK では、着信呼び出しを別の番号または SDK/Teams エンドポイントにリダイレクトしたり、他のユーザーまたはユーザーを並行して呼び出したり (同時呼び出し)、ユーザーまたは番号のグループを呼び出したりすることができます。 また、以下の点を考慮してください。

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

  • History-Info ヘッダーが設定されます。

  • ユーザー A が別の PSTN ユーザーである場合、SIP プロキシは、ユーザー A に対する "SIP SIP/2.0 181 呼び出しが転送されています" という仮応答を生成します。

  • ユーザー A とユーザー C が PSTN ユーザーの場合、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 ヘッダー

Note

Azure Communication Services では、ダイレクト ルーティング History-Info ヘッダーは既定で有効になっており、無効にすることはできません。

Azure Communication Services では、ダイレクト ルーティング History-Info ヘッダーは既定で有効になっており、無効にすることはできません。 詳細については、RFC 4244 – セクション 1.1 を参照してください。 ダイレクト ルーティングの場合、このヘッダーは同時呼び出しと着信転送のシナリオで使用されます。

History-Info は次のようにして有効にすることができます。

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

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

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

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

    Note

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

  • 受信 History-Info は、ループ防止のために保持されます。

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

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

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

ヘッダーの例:

History-Info:
  <sip:+123456@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D302%3Btext%3D%22Moved%20temporarily%22>;index=1,
  <sip:+113579@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 秒間隔で再試行後メッセージを SBC に送信できます。 SBC が INVITE に応答して Retry-After ヘッダーを含む 503 メッセージを受信した場合、SBC はその接続を終了し、次に使用可能な Microsoft データセンターを試す必要があります。

再試行の処理 (603 応答)

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