MRA経由のJabber SIP URIコール

概要

このドキュメントでは、Cisco Unified Communications Manager(CUCM)とExpressway CおよびEで設定を行い、Mobile Remote Access(MRA)経由で接続したときに、別の組織からSession Initiation Protocol(SIP)Uniform Resource Identifier(URI)を呼び出出出します。 Expresswayのコンテキストでも同じことをB2Bコールフローと呼びます。

シナリオ

組織1がMRAを導入し、組織2が導入しないシナリオを想定します。組織2の場合、境界は適応型セキュリティアプライアンス(ASA)で終わり、その先には組織2のCUCMクラスタと統合されたCUBEがあります。

図に示すように、Jabber AはMRA経由または内部で接続できますが、CUCM、Expressway C、およびEの設定は組織1でも同じです。

前提

Jabber AユーザとJabber Bユーザは、Extensible Messaging and Presence Protocol(XMPP)フェデレーションを介してIMとプレゼンスを交換でき、それらのIMアドレスも作業SIP URIであると仮定できます。

また、Jabber AとJabber Bは、それぞれの組織内でSIP URIを介して正常にダイヤルできます。

上記のシナリオでは、組織2にコール制御サーバとしてCUCMがあると仮定します。ただし、別のベンダーのコール制御サーバである可能性もあります。

CUCM、Jabber、VCS for MRAを統合する際には、バージョンを認識する必要があります。

Jabber AがJabber Bにコールするときの組織1の設定

ステップ1：図に示すように、リスニングポートが5065の新しいSIPトランクセキュリティプロファイルを作成します。

ステップ2：図に示すように、ExpressWay-CをポイントするSIPトランクを作成し、SIPトランクセキュリティプロファイルを割り当てます。

注：5065ポートでリッスンする新しいトランクセキュリティプロファイルが作成されます。Expressway-Cを指すこの新しいSIPトランクに割り当てられます。Expressway-Cは、JabberユーザがMRAを介してログインするときに、5060上のJabber非セキュア登録をCUCMにに送信するように設定済であるため。デフォルトのトランクセキュリティプロファイルを使用する場合、MRA経由でログインしたjabberがCUCMのポート5060に登録できません。

ステップ3：図に示すように、組織2のURIのSIPルートパターンを作成し、それをSIPトランクポイントにExpressway-Cに割り当てます。

ステップ4：図に示すように、CUCMを指すネイバーゾーンをExpressway-Cに作成します。

ステップ5：図に示すように、Expressway-C上にトラバーサルクライアントゾーンを作成します(UCトラバーサルではない)。

 ステップ6：図に示すように、Expressway-E上にトラバーサルサーバゾーンを作成します(UCトラバーサルではない)。

ステップ7：図に示すように、Expressway-CでDNSゾーンを作成します。このゾーンは、組織2のURIのDNS SRVルックアップを実行するために使用されます。

すべてのゾーンを作成したら、ルーティングを実行できるように、Expressway CとExpressway Eで検索ルールを定義する必要があります。

ステップ8:Expressway-Cの検索ルールは、図に示すように、作成した新しいトラバーサルゾーンでURI starlabs.com用のSIP InviteをExpressway-Eに転送します。

ステップ9：図に示すように、コールがトラバーサルゾーンを経由してExpressway-Eに到達すると、Expressway-Eの検索ルールでURI starlabs.com用のSIP InviteをDNS ZONEに転送します。

ステップ10：コールがDNSゾーン（DNSゾーン）に到達すると、Expressway-CはパブリックDNSサーバに対しては_sips.tcp.starlabs.com、_sip._tcp.starlabs.com、_sip._udp.starlabs.comををルックアップします。

Exp-Eログでは、次のように表示されます。

 

2016-03-09T09:48:35+05:30 VCSECOL tvcs: UTCTime="2016-03-09 04:18:35,399" Module="network.dns" Level="DEBUG":  Detail="Sending DNS query" Name="_sip._tcp.starlabs.com" Type="SRV (IPv4 and IPv6)"

2016-03-09T09:48:35+05:30 VCSECOL tvcs: UTCTime="2016-03-09 04:18:35,400" Module="network.dns" Level="DEBUG":  Detail="Resolved hostname to:  ['IPv4''TCP''14.160.103.10:5060'] (A/AAAA) Number of relevant records retrieved: 1"

DNS SRVルックアップから、Exp-EはネクストホップのIPとポートを取得し、組織2に到達します。このシナリオでは、DNS SRV_sip._tcp.starlabs.comは、組織2のASAのパブリックFQDN/IPおよびポート5060に0に0に00に0060に00000000000000000000000000000000000000000000000000000000000

アウトバウンドコールフロー全体が 

1. Jabber AがSIP URIとしてuserB@starlabs.comにダイヤルします。
2. SIP InviteがCUCMに到達します（Exp-E —> Exp-C経由）。
3. CUCMは、SIPルートパターンに一致する番号分析を行います。
4. CUCMは、SIPトランク経由でコールをExp-Cにルーティングします。
5. Exp-Cは、「CUCMネイバーゾーン」（CUCMネイバーゾーン）でコールを受信し、「検索ルール」はコールをトラバーサルゾーンに転送します。
6. コールは「トラバーサルゾーン」を経由してExp-Eに到達し、ここで検索ルールは「DNSゾーン」にコールを転送します。
7. DNSゾーンに到達すると、パブリックDNSサーバに対する_sip._tcp.starlabs.comのDNS SRVルックアップが行われ、組織2に到達するためのネクストホップに解決されます。

Jabber BがJabber Aにコールするときの組織1の設定

ここでは、Jabber BがJabber Aにコールしたときに、Organization 2にSIP URIコールをOrganization 1にルーティングするように独自のダイヤルプランが設定されていると仮定します。必要な変更を確認し、Organization 1のCUCMにルーティングします。

ステップ1：図に示すように、組織2からExp-Cに着信SIP INVITEを送信するためのExpressway-Eの着信検索ルール。fed.sollab1.comのSIP URIドメインに関しては、次の通りです。

ステップ2：図に示すように、fed.sollab1.com SIP URIドメインのExpressway-Cの着信検索ルール。Exp-EからCUCMに着信SIP INVITEを送信します。

全体的な着信コールフローが 

1. Jabber BからuserA@fed.sollab1.comへのインバウンドSIP INVITEがExp-Eにヒットします。
2. Exp-Eの検索ルールは、「トラバーサルゾーン」経由でExp-Cにコールを転送します。
3. Exp-C(Exp-C)の検索ルールは、「CUCMネイバーゾーン」経由でCUCMクラスタにコールを転送します。
4. CUCMは（Exp-C —> Exp-E経由で）MRAで登録されたJabber AにSIP Inviteを送信します。

注：リッチメディアライセンスは、B2Bコールが動作するためにExpressway-CとExpressway-Eの両方で必要です。

注：顧客がファイアウォールで正しいポートを開いていることを確認します。