この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版(リンクからアクセス可能)もあわせて参照することを推奨します。
このドキュメントでは、複数のコールルーティングテーブルに分割されたCisco Meeting Server(CMS)(旧Acano製品)のコールルーティングロジックについて説明します。このドキュメントでは、コールがこれらのコールルーティングテーブルを通過できるさまざまな段階とシナリオについて説明します。
次の項目に関する知識があることが推奨されます。
このドキュメントの情報は、バージョン2.3.xのCisco Meeting Server(CMS)に基づくものです。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
CMSのコールルーティングには、いくつかのコールルーティングの異なるテーブルが含まれます。ダウンロード可能なフローチャートを使用して、CMSに着信する各コールのコールルーティングロジックに従うことができます。これは、すべてのタイプのコールに有効です。Cisco Meeting App(CMA:シッククライアントまたはWebRTC)、標準セッション開始プロトコル(SIP)コール、またはMicrosoft SIPコール(特に指定がない限り)
注:唯一の例外は、CMSが開始したコール(TelePresence Management Suite(TMS)の直接スケジュールされた発信コールまたはCMAクライアントが発信コール)で、コール転送テーブルがバイパスされる場合です。
CMS内のコールルートプロセスの順序は次のとおりです。
各テーブルについては、ドキュメントの後半で詳しく説明します。これには、の関連部分だけを示すイメージが含まれます。
注:CMSは、ドメインルーティングに基づいてだけコールルーティングを実行するため、Uniform Resource Identifier(URI)の右側(RHS)に基づいて実行されます。 DirectoryNumberルーティング(ルートパターン)を使用するCisco Unified Communications Manager(CUCM)と同様に、URIの左側(LHS)に基づくコールルーティング機能はありません。
注:各テーブルは、priority属性によって設定された順序付きリストです。優先順位が高い場合は、最初に照合が試行されます。一致しない場合は、リスト内の次のルールに進みます。一般的なルールとして、より一般的なルール(任意のドメインに一致する*など)を、より具体的なルールより低い優先度で指定します。これにより、特定のルールが最初に処理され、より一般的なルールにフォールバックされる可能性があります。
これは、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)。
コールが着信コール照合テーブルのルールに一致しなかった場合、またはコールの続行に一致しなかった場合(ユーザが既存でないスペース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:[email protected]" to local URI "sip:[email protected]" 2018-10-04 06:36:24.624 Info forwarding call to 'sip:[email protected]' to '[email protected]' 2018-10-04 06:36:24.625 Info call 789: outgoing SIP call to "[email protected]"
転送テーブルにルールまたは拒否ルールがない場合、イベントログには明示的に表示されません。SIPコールが一致せず(スペース、ユーザ、IVRまたはLync会議)、転送ルールが失われ(または拒否に設定されている)、送信ルールセクションに移動したことを通知するだけです。
2018-10-04 06:47:12.482 Info call 790: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]" 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:[email protected]>;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:[email protected]" 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:[email protected];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:[email protected]>;tag=2aa2a49bba231a1b
この転送コール回線では、発生した変更が表示されます。SIPトレースが有効になっていない場合でも、any.comからnewany.comへの変更が表示されます。
このドメインの書き換えの最も一般的な使用は、CMSクラスタとのオンプレミスLync統合です。ここでは、発信ルールの連絡先ヘッダーとFromヘッダーをLync/Skypeに設定し、callbridge固有の完全修飾ドメイン名(FQDN s s)をにすることを推奨します。 これは、次のルーティングルールが原因です。
ドメインを書き換えると、Lyncコールからのコールバックに関連します。不在着信INVITEのFromヘッダーは、コールの発信元である特定のcallbridgeを指します。次に、Lyncは、callbridge FQDNと一致するSIP要求URIを持つ新しい要求(INVITE)を送信します。次に、この書き換えルールを使用してSIPドメインに変換されます。コールが転送されると、SIPエンドポイントが登録されるCUCMまたはにに向Expressway-C向にに向送信送信ルールルールがされます。
転送ルールには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:[email protected] 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:[email protected]> 2018-10-12 09:09:24.489 Info SIP trace: Call-ID: [email protected] 2018-10-12 09:09:24.494 Info call 803: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]" 2018-10-12 09:09:24.506 Info forwarding call to 'sip:[email protected]' to '[email protected]' 2018-10-12 09:09:24.507 Info call 804: outgoing SIP call to "[email protected]" (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:[email protected] 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:[email protected]> 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ヘッダーが[email protected]のCMSに入る表に示すように作成されます。
これは、別のサーバにコールを発信するコールルーティングロジックの最後のテーブルです。
図から、ロジックが比較的簡単であることがわかります。テーブルにエントリがまったく存在しない場合でも、発信コールは許可されますが、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:[email protected]" to local URI "sip:[email protected]" 2018-10-12 11:25:16.179 Info forwarding call to 'sip:[email protected]' to '[email protected]' 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:[email protected] 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用)
OutboundDialPlanRules(コールの発信を許可する必要があるすべての非USコールブリッジ)(コールブリッジごとに1つ必要)
現在、この設定に使用できる確認手順はありません。
現在、この構成に関する特定のトラブルシューティング情報はありません。
注:設定例については、次のガイドを参照してください。
改定 | 発行日 | コメント |
---|---|---|
1.0 |
30-Sep-2021 |
初版 |