Meeting Serverのコールルーティングロジックについて

概要

このドキュメントでは、複数のコールルーティングテーブルに分割されたCisco Meeting Server(CMS)（旧Acano製品）のコールルーティングロジックについて説明します。このドキュメントでは、コールがこれらのコールルーティングテーブルを通過できるさまざまな段階とシナリオについて説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• Cisco Meeting Server Call Bridgeコンポーネント。

使用するコンポーネント

このドキュメントの情報は、バージョン2.3.xのCisco Meeting Server(CMS)に基づくものです。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

Cisco Meeting Server(CMS)のコールルーティングロジックとは何ですか。

CMSのコールルーティングには、いくつかのコールルーティングの異なるテーブルが含まれます。ダウンロード可能なフローチャートを使用して、CMSに着信する各コールのコールルーティングロジックに従うことができます。これは、すべてのタイプのコールに有効です。Cisco Meeting App（CMA：シッククライアントまたはWebRTC）、標準セッション開始プロトコル(SIP)コール、またはMicrosoft SIPコール（特に指定がない限り）

注：唯一の例外は、CMSが開始したコール(TelePresence Management Suite(TMS)の直接スケジュールされた発信コールまたはCMAクライアントが発信コール)で、コール転送テーブルがバイパスされる場合です。

CMS内のコールルートプロセスの順序は次のとおりです。 

1. 着信コール照合テーブル
2. 着信コール転送テーブル
3. 発信コールテーブル

各テーブルについては、ドキュメントの後半で詳しく説明します。これには、の関連部分だけを示すイメージが含まれます。

注：CMSは、ドメインルーティングに基づいてだけコールルーティングを実行するため、Uniform Resource Identifier(URI)の右側(RHS)に基づいて実行されます。 DirectoryNumberルーティング（ルートパターン）を使用するCisco Unified Communications Manager(CUCM)と同様に、URIの左側(LHS)に基づくコールルーティング機能はありません。

注：各テーブルは、priority属性によって設定された順序付きリストです。優先順位が高い場合は、最初に照合が試行されます。一致しない場合は、リスト内の次のルールに進みます。一般的なルールとして、より一般的なルール（任意のドメインに一致する*など）を、より具体的なルールより低い優先度で指定します。これにより、特定のルールが最初に処理され、より一般的なルールにフォールバックされる可能性があります。

ステップ1：着信コール照合テーブル

これは、CMSが着信コールをCisco Meeting Server自体に宛てて処理する必要があるかどうかを判断するプロセスの最初のステップです。または、コールを相互接続し、メディアとシグナリング(f.e.Skypeゲートウェイから標準SIPエンドポイントへのコール（またはその逆）。

着信URIのドメイン部分が着信照合テーブルと一致するかどうかをチェックします。一致する場合は、このダイヤルプランルールの設定に従って、スペース、ユーザ、IVRにコールをルーティングするか、Lync会議ルックアップ（オンプレミスルックアップまたはオフプレム）を実行できます。このテーブルではワイルドカードドメインを使用できません。完全な一致が必要です。

注：ドメインに一致する着信コールが設定されていない場合、CMSはSIPまたはLyncからの着信URIをすべて受け入れ、コールブリッジに到達します。CMAクライアント（WebRTCまたはシッククライアント）の場合、コールを受け入れますが、正しいスペースやユーザに自動的にルーティングされることはありません。したがって、CMAクライアントを使用してスペースやユーザにダイヤルする場合は、正しいドメインに入ることが重要です。

たとえば、コールマッチングテーブルが図に示されます(簡略化のためターゲット・スペースとターゲット・ユーザーのオプションのみが表示されます)。

ここでは、クライアントが通常ダイヤルするacano.steven.labとしてドメインが設定されています。ただし、CUCM（またはExpresswayの検索ルール）からのアドホックコールまたは特定のSIPルートパターンは、callbridge(この場合は10.48.54.160)のIPアドレスまたはcallbridge(acano1.acsteano.fqdn)に一致するテーブルの1番目と2番目のフォールバックルールでのみ対象になりますこの場合はven.lab)。

ステップ2：着信コール転送テーブル

コールが着信コール照合テーブルのルールに一致しなかった場合、またはコールの続行に一致しなかった場合（ユーザが既存でないスペースURIをダイヤルした場合、コール転送テーブルと呼ばれる2番目のテーブルを通ります）。これはドメインベースのみであり、特定のドメインへのコールを明確にブロックしたり、特定のドメインへのコールのみを具体的に許可したりできます。これを行う場合は、より高い優先度を持つ特定のルールを設定することが重要です。そのため、最初にチェックされます。

次の例は、dummy.comへのコールが拒否され、tplab.localへのコールが転送されることを示しています。

コール転送テーブルを空白のままにすると、CMSがSkypeとSIP参加者の間のゲートウェイとして機能しない状態になります。たとえば、コール転送ルールがないためです。着信コールのドメインが着信照合テーブルで一致しないか、ドメインが一致するが、スペース、ユーザ、またはIVR（またはSkype会議）で一致しないと仮定すると、発信コールテーブルに関してコールが転送されません。

注：これは、CMAクライアント（シッククライアントおよびWebRTC）が発信コールを行うことができるため（3.0の*Web Appでは発信コールを行えず、CMSではCallbridgeによる発信コールを行います）。 同様に、TMSスケジュール会議の場合など、APIを使用して行った場合も、CMSの発信コールは正常に動作します。 一般に、CMS自体（CMSから直接またはCMA経由）から開始されるコールは、コール転送ロジックに従ってはなりません。

イベントログには、CMSがSIPコールおよびSkypeコールのゲートウェイとして機能する場合など、強調表示された転送メッセージが表示されます。その直前に、着信コールと発信コールが表示されます。

2018-10-04  06:36:24.612  Info     call 788: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-04  06:36:24.624  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@any.com'
2018-10-04  06:36:24.625  Info     call 789: outgoing SIP call to "stejanss@any.com"

転送テーブルにルールまたは拒否ルールがない場合、イベントログには明示的に表示されません。SIPコールが一致せず（スペース、ユーザ、IVRまたはLync会議）、転送ルールが失われ（または拒否に設定されている）、送信ルールセクションに移動したことを通知するだけです。

2018-10-04  06:47:12.482  Info     call 790: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-04  06:47:12.495  Info     call 790: ending; local teardown, destination URI not matched - not connected after 0:00

TMSスケジュール会議を通じて開始されるCMSからのCMAクライアントのコールまたは発信コールの場合、イベントログに着信コールは表示されません。コールはすぐに発信ダイヤルプランテーブルに移動し、コール転送テーブルによって処理されません。

コール転送テーブルには、他に2つの設定オプションがあります。ドメインと発信者IDを書き換えます。

リライトドメイン

このオプションを使用すると、着信コールのドメインを別のドメインに書き換え、SIP Request-URIのドメイン部分とSIPメッセージのToヘッダを変更できます。

たとえば、このイメージの設定では、ドメインany.comの着信コールに対してイベントログ（SIPトレースが有効）が表示されます。ただし、着信コール照合テーブル（スペース、ユーザ、IVR、またはSkype会議）には一致しません。

2018-10-04  07:02:24.818  Info     SIP trace: connection 0: incoming SIP TCP data from 10.48.36.215:56457 to 10.48.80.71:5060, size 1000:
2018-10-04  07:02:24.818  Info     SIP trace: INVITE sip:stejanss@any.com SIP/2.0
2018-10-04  07:02:24.818  Info     SIP trace: Via: SIP/2.0/TCP 10.48.36.215:5060;branch=z9hG4bK53e4c4ce29394
2018-10-04  07:02:24.818  Info     SIP trace: From: "EX60 Steven" <sip:1060@steven.lab>;tag=742103~ee545a46-516a-4de6-87d7-7b1f5a5b848a-26001856
2018-10-04  07:02:24.818  Info     SIP trace: To: <sip:stejanss@any.com>
..
2018-10-04  07:02:24.822  Info     call 797: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-04  07:02:24.834  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@newany.com'
2018-10-04  07:02:24.835  Info     call 798: outgoing SIP call to "stejanss@newany.com"
..
2018-10-04  07:02:24.838  Info     SIP trace: connection 19: outgoing SIP TCP data to 10.48.36.215:5060 from 10.48.80.71:57854, size 3286:
2018-10-04  07:02:24.838  Info     SIP trace: INVITE sip:stejanss@newany.com SIP/2.0
2018-10-04  07:02:24.838  Info     SIP trace: Via: SIP/2.0/TCP 10.48.80.71:5060;branch=z9hG4bKefc98b81a2961b37aee24f03c2142d8e
2018-10-04  07:02:24.839  Info     SIP trace: Call-ID: 18644f28-e998-4032-a7df-75325e9d11b0
2018-10-04  07:02:24.839  Info     SIP trace: CSeq: 659590315 INVITE
2018-10-04  07:02:24.839  Info     SIP trace: Max-Forwards: 70
2018-10-04  07:02:24.839  Info     SIP trace: Contact: <sip:1060@10.48.80.71;transport=tcp>
2018-10-04  07:02:24.839  Info     SIP trace: To: <sip:stejanss@newany.com>
2018-10-04  07:02:24.839  Info     SIP trace: From: "EX60 Steven" <sip:1060@steven.lab>;tag=2aa2a49bba231a1b

この転送コール回線では、発生した変更が表示されます。SIPトレースが有効になっていない場合でも、any.comからnewany.comへの変更が表示されます。

このドメインの書き換えの最も一般的な使用は、CMSクラスタとのオンプレミスLync統合です。ここでは、発信ルールの連絡先ヘッダーとFromヘッダーをLync/Skypeに設定し、callbridge固有の完全修飾ドメイン名(FQDN s s)をにすることを推奨します。 これは、次のルーティングルールが原因です。

• Skypeは、ダイアログ内で新しいトランザクション（たとえば、INVITEの後のACK - 200 OKなど）を、CMSから受信した200 OKで指定された連絡先ヘッダに送信します。  SkypeからCMSへの着信接続では、Skypeは最初にToヘッダーにms-feヘッダーを含むNEGOTIATE SIPメッセージを送信します。このメッセージは、INVITEの200 OK応答に連絡先ヘッダーをどのように入力するかを指定します
• Skypeは新しいダイアログ(コンテンツの共有など)を、元のINVITEのFromヘッダーに送信します(別の通話の場合はコールバック、不在時はコールバック)

ドメインを書き換えると、Lyncコールからのコールバックに関連します。不在着信INVITEのFromヘッダーは、コールの発信元である特定のcallbridgeを指します。次に、Lyncは、callbridge FQDNと一致するSIP要求URIを持つ新しい要求(INVITE)を送信します。次に、この書き換えルールを使用してSIPドメインに変換されます。コールが転送されると、SIPエンドポイントが登録されるCUCMまたはにに向Expressway-C向にに向送信送信ルールルールがされます。

発信者 ID

転送ルールには2つのオプションがあります。pass throughに設定されているが、発信INVITEのFromヘッダーに変更が加えられていないか、またはシステムが発信ルールに従ってFromヘッダーを変更できるようにするダイヤルプランを使用するように設定されている。この設定は、SIP要求URIおよび発信INVITEのToヘッダーに関するドメインの書き換えがあるかどうかとは関係ありません。

たとえば、以前と同じコールが行われましたが、現在はnewany.comへの発信ダイヤルプランルール（着信コール転送テーブルの書き換え後と同様）がLyncタイプのコール（Ms-Conversation-IDは追加のSIPヘッダーなど）として設定されています。 Lyncコールに関して前述したように、適切に[Local From Domain]（および[Local Contact Domain]）がcallbridge FQDNをポイントするように入力されます。次に、送信SIP INVITEのFromおよびContactヘッダーの変更が反映されます。図に示すように、これらの値は同じ値で入力され、要件に応じて個別に選択できます。

2018-10-12  09:09:24.488  Info     SIP trace: connection 28: incoming SIP TCP data from 10.48.36.215:44460 to 10.48.80.71:5060, size 1000:
2018-10-12  09:09:24.489  Info     SIP trace: INVITE sip:stejanss@any.com SIP/2.0
2018-10-12  09:09:24.489  Info     SIP trace: Via: SIP/2.0/TCP 10.48.36.215:5060;branch=z9hG4bKf4a230ec178e
2018-10-12  09:09:24.489  Info     SIP trace: From: "EX60 Steven" <sip:1060@steven.lab>;tag=118288~ee545a46-516a-4de6-87d7-7b1f5a5b848a-32900729
2018-10-12  09:09:24.489  Info     SIP trace: To: <sip:stejanss@any.com>
2018-10-12  09:09:24.489  Info     SIP trace: Call-ID: 81e67f80-bc0164c4-f2c6-d724300a@10.48.36.215

2018-10-12  09:09:24.494  Info     call 803: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-12  09:09:24.506  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@newany.com'
2018-10-12  09:09:24.507  Info     call 804: outgoing SIP call to "stejanss@newany.com" (Lync)

2018-10-12  09:09:24.507  Info     SIP trace: connection 33: allocated for outgoing connection to 10.48.36.46:5060
2018-10-12  09:09:24.508  Info     SIP trace: connection 33: outgoing connection successful, 10.48.80.71:39782 to 10.48.36.46:5060
2018-10-12  09:09:24.510  Info     SIP trace: connection 33: outgoing SIP TCP data to 10.48.36.46:5060 from 10.48.80.71:39782, size 2971:
2018-10-12  09:09:24.510  Info     SIP trace: INVITE sip:stejanss@newany.com SIP/2.0
2018-10-12  09:09:24.510  Info     SIP trace: Via: SIP/2.0/TCP 10.48.80.71:5060;branch=z9hG4bK15bdde97ab641b586f162187cfdd98b5
2018-10-12  09:09:24.510  Info     SIP trace: Call-ID: c366ddaf-e602-4fa5-b1d6-2e16ec08534a
2018-10-12  09:09:24.510  Info     SIP trace: CSeq: 1498747095 INVITE
2018-10-12  09:09:24.510  Info     SIP trace: Max-Forwards: 70
2018-10-12  09:09:24.510  Info     SIP trace: Contact: <sip:1060@callbridgefqdn.any.com;transport=tcp>
2018-10-12  09:09:24.510  Info     SIP trace: Ms-Conversation-ID: 3P5Hu8grR1GGDF1BSMZAmw==
2018-10-12  09:09:24.510  Info     SIP trace: To: <sip:stejanss@newany.com>
2018-10-12  09:09:24.510  Info     SIP trace: From: "EX60 Steven" <sip:1060@callbridgefqdn.any.com>;tag=fb4ae780677e9d9b

転送ルールがpass throughに設定された場合、前の例と同様にFromヘッダーに変更はありません（この場合、pass throughが転送ルールに設定されています）。 Contactヘッダーは、CMSが新しいcallLegを開始すると常に適応されるため、Contactヘッダーを自身に追加する必要があります。

発信者IDとローカル連絡先ドメインの組み合わせと、ローカルからドメインの組み合わせの組み合わせを使用できます。発信SIP INVITEのFromヘッダーは、着信コールがFromヘッダーがusera@from.comのCMSに入る表に示すように作成されます。

ステップ3：発信コールテーブル

これは、別のサーバにコールを発信するコールルーティングロジックの最後のテーブルです。

• 着信コールは（着信照合ドメインで）ローカルに処理されません。
• これは、CMSスペース(CMAまたはAPIを介したTMSスケジュール会議の場合、またはCisco Meeting Manager(CMM)が指示した発信コールの場合)またはCMAクライアントからの発信コールです。

図から、ロジックが比較的簡単であることがわかります。テーブルにエントリがまったく存在しない場合でも、発信コールは許可されますが、SIP要求URIで指定した特定のドメインのSIP SRVレコード(_sips._tcp / _sip._tcp / _sip._udp)でCMSサーバが解決できると想定されます。テーブルが空ではなく、ダイヤルされたドメインに一致するエントリがない場合、同じDNSルックアップロジックが実行されます。ドメインに一致がある場合、その特定のルールのロジックに従います。これに関して、CMAからの発信コールをブロックする場合、またはTMSまたはCMMを介して発信コールをブロックする場合は、次の2つの方法があります。DNS SRVレコードがないか（CMSによって解決できない）、またはコールをコール制御（CUCMやExpresswayなど）にルーティングし、そこでコールをブロックします。

次の図に、発信コールテーブルの例を示します。

最後に一般的な<match all domains>ルールを指定し、SIPプロキシを使用せずにsteven.labのドメインに対する最初のルールを指定します（そのため、DNS SRVレコードに依存しています）。

これは、優先順位の高い値を最初にカバーする順序付きリストであることに注意してください。[動作(Behavior)] を[停止(Stop)]に設定したルールを照合する場合、その照合後にコールがテーブルの残りの部分を通過せず、そのSIPプロキシがコールのルーティングに失敗した場合などにコールが失敗します。この設定を[Continue]に設定すると、クラスタ内の別のルートまたは別のノードへのフォールバックを許可できます。たとえば、同じドメインに対してルールごとに異なるSIPプロキシを指定できます。 

ローカルコンタクトドメインとローカルドメインの設定は、着信転送テーブルの前のセクションで説明しています。トランクタイプを使用すると、どのタイプのコールを発信する必要があるかを指定できます。これは、受信システムに応じて標準SIP、Lync、またはAvayaのいずれかになります。

[Encryption] フィールドは、コールのシグナリングを暗号化する必要があるかどうかを決定します。ただし、[設定(Configuration)] > [コールの設定(Call Settings)]メニューに表示されるSIPメディア暗号化の設定で設定されたメディア暗号化を意味しない点に注意してください。この設定では、[Auto]を選択することもできます。この場合、暗号化されていないシグナリングにフォールバックする可能性がある暗号化されたシグナリングを使用して、コールを最初に発信しようとします。相手側が暗号化または暗号化されていないことを事前に確認している場合は、フォールバックプロセスによるコールセットアップ遅延を回避するために、それに応じて定義することを強く推奨します。

steven.labへのコールのログファイル（着信転送テーブルのドメインの書き換え後）の出力例で、DNSトレースとSIPトレースをdetailedに設定すると、クエリされたSRVレコードとフォールバックメカニズムがAutoに設定されます。

2018-10-12  11:25:16.168  Info     call 821: incoming SIP call from "sip:1060@steven.lab" to local URI "sip:stejanss@any.com"
2018-10-12  11:25:16.179  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@steven.lab'
2018-10-12  11:25:16.180  Info     call 822: outgoing SIP call to "stejanss@steven.lab"

2018-10-12  11:25:16.180  Info     DNS trace: resolving "steven.lab" (SRV "_sips._tcp", dnsType:1) for call 822
2018-10-12  11:25:16.181  Info     DNS trace: resolution of "steven.lab" (SRV "_sips._tcp") for call 822 returned result, addresses: 1
2018-10-12  11:25:16.181  Info     DNS trace: resolution of "steven.lab" (SRV "_sips._tcp") for call 822 succeeded; results: 1
2018-10-12  11:25:16.181  Info     DNS trace: resolution of "steven.lab" (SRV "_sips._tcp") for call 822 using 10.48.36.215:5061
2018-10-12  11:25:16.181  Info     SIP trace: connection 45: allocated for outgoing encrypted connection to 10.48.36.215:5061
2018-10-12  11:25:16.201  Info     handshake error 336151576 on outgoing connection 45 to 10.48.36.215:5061 from 10.48.80.71:54864
2018-10-12  11:25:16.201  Info     SIP trace: connection 45: shutting down...

2018-10-12  11:25:16.201  Info     call 822: falling back to unencrypted control connection...

2018-10-12  11:25:16.201  Info     DNS trace: resolving "steven.lab" (SRV "_sip._tcp", dnsType:1) for call 822
2018-10-12  11:25:16.202  Info     DNS trace: resolution of "steven.lab" (SRV "_sip._tcp") for call 822 returned result, addresses: 1
2018-10-12  11:25:16.202  Info     DNS trace: resolution of "steven.lab" (SRV "_sip._tcp") for call 822 succeeded; results: 1
2018-10-12  11:25:16.202  Info     DNS trace: resolution of "steven.lab" (SRV "_sip._tcp") for call 822 using 10.48.36.215:5060
2018-10-12  11:25:16.202  Info     SIP trace: connection 46: allocated for outgoing connection to 10.48.36.215:5060
2018-10-12  11:25:16.203  Info     SIP trace: connection 46: outgoing connection successful, 10.48.80.71:59776 to 10.48.36.215:5060
2018-10-12  11:25:16.205  Info     SIP trace: connection 46: outgoing SIP TCP data to 10.48.36.215:5060 from 10.48.80.71:59776, size 3290:
2018-10-12  11:25:16.205  Info     SIP trace: INVITE sip:stejanss@steven.lab SIP/2.0

注：複数のcallbridgeを持つクラスタ環境の場合、APIを介してcallbridgeを設定し、APIオブジェクトでcallbridge ID（またはcallbridgeGroup ID）を指定すると、callbridgeごとにアウトバウンドダイヤルプランルールを設定できます。 たとえば、特定のドメインの1つの特定のcallbridgeからすべてのコールを発信するとします（たとえば、us.example.comにダイヤルする場合、USベースのサーバから発信するとします）。 次に、USベースのcallbridge以外の相互callbridgeがコールをUScallbridgeにルーティングできるように、outboundDialPlanRulesのAPI設定があることを確認します（この例の場合）。

OutboundDialPlanRule(US callbridge用)

• domain = us.example.com
• sipProxy = <手動で設定した場合のDNS SRV/IPまたはFQDN使用時の空>
• scope = callbridge
• callbridge = <UScallbridge-ID>

OutboundDialPlanRules（コールの発信を許可する必要があるすべての非USコールブリッジ）（コールブリッジごとに1つ必要）

• domain = us.example.com
• sipProxy = <IP-or-FQDN-of-US-Callbridge>
• scope = callbridge
• callbridge = <non-US-callbridge-ID>

確認 

現在、この設定に使用できる確認手順はありません。

トラブルシュート 

現在、この構成に関する特定のトラブルシューティング情報はありません。

関連情報

• テクニカル サポートとドキュメント – Cisco Systems
• Collaboration Solutions Analyzerツール 
• CMSドキュメント

---

注：設定例については、次のガイドを参照してください。

• CMS Single Combined Guideの設定と統合
• 『Configure Cisco Meeting Server and CUCM Guide』