- はじめに
- 取得ログ
- REGISTER ステータスの確認
- トラブルシューティング
- DNS の確認
- DNS サーバへの導通確認
- アウトバウンド SIP プロキシの IP アドレスの取得の確認
- TLS コネクションの確認
- TCP コネクション
- TLS コネクション
- Cisco SCAN (CSCAN) ツール
- SIP メッセージの確認
- 参考情報
はじめに
本ドキュメントでは、Cisco Webex Calling サービスにおいて、ローカルゲートウェイから Webex Calling クラウドへの登録が失敗する問題のトラブルシューティングについて紹介します。
本ドキュメントは、以下のドキュメントの内容を理解していることを前提としています。
- Webex Calling サービスのネットワーク要件
- Webex Calling - ローカルゲートウェイの設定例 (1: Control Hub)
- Webex Calling - ローカルゲートウェイの設定例 (2: LGW の登録)
- Webex Calling - ローカルゲートウェイの設定例 (3: LGW のルーティング)
- Webex Calling - ローカルゲートウェイ Registration フロー
- Webex Calling - ローカルゲートウェイ コールフロー (WxC ↔ PRI)
- Webex Calling - ローカルゲートウェイで SR オープン時に取得するログ一覧
取得ログ
REGISTER ステータスの確認
show sip-ua register status コマンドで reg が yes になっていることを確認します。yes になっている場合は REGISTER 登録が正常に完了しています。expires は次の再 REGISTER までの時間(秒)を表示します。
LGW#show sip-ua register status
Tenant: 200
--------------------- Registrar-Index 1 ---------------------
Line peer expires(sec) reg survival P-Associ-URI
================================ ========= ============ === ======== ============
LGW9045_LGU -1 48 yes normal
トラブルシューティング
show sip-ua register status コマンドの結果、何も出力されない、もしくは reg が no になっている場合、設定の見直しを実施し、show コマンドやデバッグコマンドやキャプチャなどによって原因を特定する必要があります。
DNS の確認
ローカルゲートウェイは、設定したドメインを名前解決したアドレスに対して REGISTER を送信します。DNS が正しく設定されているか確認します。
DNS サーバへの導通確認
ip name-server <DNSサーバの IP アドレス> が設定されているか、DNS サーバに対して ping が通るか確認します。ping が通らない場合はネットワークを確認してください（ファイアウォールで意図的に遮断されている可能性もあります）。
LGW#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/3/4 ms
名前解決ができるか確認します。
LGW#ping www.cisco.com
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to x.x.x.x, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/6/11 ms
名前解決が失敗する場合は、debug ip udp port 53 や、パケットキャプチャによって、ローカルゲートウェイが UDP ポート 53 (DNS) でパケットを送信しているか、DNS サーバから応答を受信しているか確認してください。DNS サーバからの応答がない場合は別の DNS サーバを試したり、ファイアウォールの設定を再度確認してください。
LGW#debug ip udp port 53
UDP packet debugging is on
LGW#
LGW#ping www.cisco.com
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to x.x.x.x, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/8/17 ms
LGW#
Nov 19 04:39:56.639: UDP: sent src=192.168.43.197(57990), dst=8.8.8.8(53), length=62
Nov 19 04:39:56.646: UDP: rcvd src=8.8.8.8(53), dst=192.168.43.197(57990), length=78
Nov 19 04:39:56.647: Released port 57990 in Transport Port Agent for IP type 1
Nov 19 04:39:56.647: Released port 57990 in Transport Port Agent for IP type 1
アウトバウンド SIP プロキシの IP アドレスの取得の確認
REGISTER の送信先であるアウトバウンド SIP プロキシの IP アドレスは、DNS サーバから SIPS SRV レコードを引いて取得します。
まず、ローカルゲートウェイのネットワークから SIPS の SRV が取得できるかどうかを確認するために、ローカルゲートウェイと同じネットワークから nslookup などで SIPS SRV レコードを引けるかどうかを確認します。
Control Hub で表示された [Outbound Proxy Address] が ty01.sipconnect-jp10.bcld.webex.com の場合に PC で nslookup を実行した結果の例は以下のとおりです (なお、アウトバウンド SIP プロキシの各サーバに ping してもフィルタされているため応答はありません)。
$ nslookup -type=SRV _sips._tcp.ty01.sipconnect-jp10.bcld.webex.com
Server: x.x.x.x
Address: x.x.x.x#53
Non-authoritative answer:
_sips._tcp.ty01.sipconnect-jp10.bcld.webex.com service = 10 50 8934 sipconnect51a-jp10.bcld.webex.com.
_sips._tcp.ty01.sipconnect-jp10.bcld.webex.com service = 5 50 8934 sipconnect50a-jp10.bcld.webex.com.
...
DNS クエリが失敗している場合、show sip-ua statistics | b Global Counters コマンドで DNS Query failed などが表示されます。
LGW#show sip-ua statistics | b Global Counters
SIP Global Counters:
<File Id, Line: Count First Occurence Most Recent Occurence
<snip>
0x12 , 1126 : 3 Nov 19 2019 05:23:21 Nov 19 2019 05:24:21
DNS Query failed for query_type:%d
debug コマンドやパケットキャプチャでも DNS で SIPS SRV レコードが取得できているか確認できます。
DNS SIPS SRV レコード取得失敗例
LGW#debug ccsip error
LGW#debug ccsip info
LGW#debug ccsip non-call
LGW#debug ccsip feature miscellaneous
LGW#
LGW#show logging | include dns
<snip>
Nov 19 05:29:54.111: //-1/xxxxxxxxxxxx/SIP/Info/notify/8192/sip_dns_type_srv_query: TYPE SRV query for _sips._tcp.ty01.sipconnect-jp99.bcld.webex.com and type:1
Nov 19 05:29:54.113: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: DNS query for ty01.sipconnect-jp99.bcld.webex.com and type:1
Nov 19 05:29:54.114: //-1/xxxxxxxxxxxx/SIP/Error/sip_dns_type_a_query:
Nov 19 05:29:54.114: //-1/xxxxxxxxxxxx/SIP/Error/_send_dns_fail:
Nov 19 05:29:54.114: //3554/000000000000/SIP/Error/act_register_dns_resolved:
DNS SIPS SRV 取得に失敗する場合は、Control Hub で表示された [Outbound Proxy Address] の値が正しくテナントに設定されているか、そのテナントがダイヤルピアにアサインされているか再度確認してください。
DNS SIPS SRV レコード取得成功例
LGW#show logging | include dns
<snip>
Nov 19 05:58:13.054: //-1/xxxxxxxxxxxx/SIP/Info/notify/8192/sip_dns_type_srv_query: TYPE SRV query for _sips._tcp.ty01.sipconnect-jp10.bcld.webex.com and type:1
Nov 19 05:58:13.055: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_srv_query: Server Name sipconnect50a-jp10.bcld.webex.com
Nov 19 05:58:13.055: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_srv_query: Server Name sipconnect51a-jp10.bcld.webex.com
Nov 19 05:58:13.056: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_srv_query: Selected Server is sipconnect50a-jp10.bcld.webex.com
Nov 19 05:58:13.057: //-1/xxxxxxxxxxxx/SIP/Info/notify/8192/sip_dns_type_a_query: TYPE A query successful for sipconnect50a-jp10.bcld.webex.com
Nov 19 05:58:13.057: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_query: ttl for A records = 3519 seconds
Nov 19 05:58:13.057: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_srv_query: IP Address of sipconnect50a-jp10.bcld.webex.com is:
Nov 19 05:58:13.057: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_srv_query: 135.84.169.X
Nov 19 05:58:13.057: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_srv_query: ttl for SRV records = 2147483seconds
参考
Collaboration Solutions Analyzer (CSA) の SRV Checker ツールで取得されるべき Outbound Proxy Address の SIPS SRV レコードを簡単に確認することができます。
TLS コネクションの確認
ローカルゲートウェイは、DNS SIPS SRV で取得したアウトバウンド SIP プロキシと TCP ポート 8934 で TLS コネクションを確立し、SIP メッセージを送信します。show コマンドやデバッグによって TLS コネクションが正常に確立されているか確認します。
TCP コネクション
show tcp brief コマンドでアウトバウンド SIP プロキシと TCP コネクションが確立されていることを確認してください。TCP ポート 8934 の TCP コネクションが ESTAB になっていることを確認します。
LGW#show tcp brief
TCB Local Address Foreign Address (state)
7F149DED3248 192.168.43.197.44598 135.84.169.X.8934 ESTAB
TLS コネクション
show sip-ua connections tcp tls details コマンドでアウトバウンド SIP プロキシと TLS コネクションが確立されていることを確認してください。Remote-Port 8934 との接続が Established になっているか確認します。
LGW#show sip-ua connections tcp tls detail
<snip>
Remote-Agent:135.84.169.X, Connections-Count:1
Remote-Port Conn-Id Conn-State WriteQ-Size Local-Address TLS-Version
=========== ======= =========== =========== ============== ===========
8934 7 Established 0 192.168.43.197 TLSv1.2
TLS コネクションの確立が失敗する場合、show sip-ua connections tcp tls brief を数十秒の間隔を空けて実行すると No. of conn. failures のカウンタが増加し続けます。
LGW#show sip-ua connections tcp tls brief
<snip>
Total active connections : 0
No. of send failures : 0
No. of remote closures : 0
No. of conn. failures : 22 <<<<<
No. of inactive conn. ageouts : 0
Max. tls send msg queue size of 1, recorded for 135.84.169.x:8934
TLS client handshake failures : 0
TLS server handshake failures : 0
TLS コネクションの確立の様子は、debug コマンドでも確認することができます。
TLS 接続に失敗している場合
LGW#debug ccsip error
LGW#debug ccsip transport
LGW#debug ccsip non-call
LGW#
LGW#show logging | include TLS
Nov 19 07:37:39.243: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostRequestConnection: Posting TLS conn create request for addr=135.84.169.x, port=8934, context=0x7F143401D410
Nov 19 07:37:39.243: //-1/xxxxxxxxxxxx/SIP/Transport/sipCreateConnInstance: Created new initiated conn=0x7F149BE89090, connid=-1, addr=135.84.169.x, port=8934, local_addr=192.168.43.197, transport=TLS Over TCP, vrfid = 0
Nov 19 07:37:39.244: //-1/xxxxxxxxxxxx/SIP/Transport/sipConnectionManagerProcessConnCreated: gConnTab=0x7F143401D410, addr=135.84.169.x, port=8934, local_addr=192.168.43.197, connid=15, transport=TLS Over TCP
Nov 19 07:37:59.243: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostCloseConnection: Posting TLS conn close for addr=135.84.169.x, port=8934, local_addr=192.168.43.197, connid=15
Nov 19 07:37:59.243: //-1/xxxxxxxxxxxx/SIP/Transport/sipDeleteConnInstance: Deleted conn=0x7F149BE89090, connid=15, remote_addr=135.84.169.x, remote_port=8934, local_addr=192.168.43.197, local_port=52327, transport=TLS Over TCP
Send Error to 135.84.169.x:8934 for transport TLS Over TCP
TLS 接続に成功した場合
LGW#show logging | include TLS
Nov 19 07:57:39.361: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostRequestConnection: Posting TLS conn create request for addr=135.84.169.x, port=8934, context=0x7F143401D410
Nov 19 07:57:39.362: //-1/xxxxxxxxxxxx/SIP/Transport/sipCreateConnInstance: Created new initiated conn=0x7F1434DD12E8, connid=-1, addr=135.84.169.x, port=8934, local_addr=192.168.43.197, transport=TLS Over TCP, vrfid = 0
Nov 19 07:57:39.364: //-1/xxxxxxxxxxxx/SIP/Transport/sipConnectionManagerProcessConnCreated: gConnTab=0x7F143401D410, addr=135.84.169.x, port=8934, local_addr=192.168.43.197, connid=39, transport=TLS Over TCP
Nov 19 07:57:39.373: //-1/xxxxxxxxxxxx/SIP/Transport/sip_tls_tcp_handshake_proc: TLS handshake initiated for new connection - remote_addr=135.84.169.x, remote port=8934, local_address=192.168.43.197, local_port=49832
Nov 19 07:57:39.457: //-1/xxxxxxxxxxxx/SIP/Transport/sip_tls_tcp_handshake_proc: TLS HANDSHAKE is successful with trunk peer 135.84.169.x
Nov 19 07:57:39.457: //-1/xxxxxxxxxxxx/SIP/Transport/sip_tcp_tls_handshake_success: TLS handshake success - remote_addr=135.84.169.x, remote_port=8934, local_addr=192.168.43.197, local_port=49832
Nov 19 07:57:39.458: //-1/xxxxxxxxxxxx/SIP/Transport/sipConnectionManagerProcessConnCreated: gConnTab=0x7F143401D410, addr=135.84.169.x, port=8934, local_addr=192.168.43.197, connid=39, transport=TLS Over TCP
TLS 接続に失敗する原因としては以下の原因が考えられます。ローカルゲートウェイ上もしくはローカルゲートウェイに接続されているスイッチでパケットをキャプチャし、アウトバウンド SIP プロキシへ送信した TCP パケットの応答が返信されているか、TLS のネゴシエーションでエラーが返信されていないかなどを確認してください。
- ローカルゲートウェイからインターネットへアクセスできない
→ ネットワークを確認してください。 - ファイアウォールのポートがオープンされていない（Webex Calling クラウドネットワークの TCP 8934 ポート宛）
→ ファイアウォールの設定を確認してください。 - ローカルゲートウェイのトラストプールへ証明書がインストールされていない
→ トラストプールの設定を確認し、証明書を再度インポートしてください。
取得したパケットキャプチャを Wireshark で開き、tcp.port==8934 でフィルタすると TCP ポート 8934 のパケットでフィルタできます。
Cisco SCAN (CSCAN) ツール
Cisco SCAN (CSCAN) ツールを使うと、Webex Calling クラウドに対して、TCP ポート 8934 がオープンされているか確認することができます（UDP は今後対応予定）。ローカルゲートウェイと同じネットワークから確認してください。
SIP メッセージの確認
show sip-ua register status コマンドで reg が yes になっていることを確認します。yes になっている場合は REGISTER 登録が正常に完了しています。expires は次の再 REGISTER までの時間(秒)を表示します。
LGW#show sip-ua register status
Tenant: 200
--------------------- Registrar-Index 1 ---------------------
Line peer expires(sec) reg survival P-Associ-URI
================================ ========= ============ === ======== ============
LGW9045_LGU -1 48 yes normal
TLS コネクションが確立していて REGISTER が失敗している場合、ローカルゲートウェイが送信する SIP REGISTER に対してエラーレスポンスが返信されている可能性があります。debug ccsip message、debug ccsip non-call によって Webex Calling クラウドから返信される SIP メッセージを確認します。
SIP メッセージの内容は、以下の方法で確認できます。
401 Unauthorized / 403 Authentication Failure / 404 Not Found
Line/Port や Registrar Domain などが間違っている可能性があります。Control Hub に表示された Line/Port (@の前のみを入力) や Registrar Domain などを正しく voice class tenant に設定してください。
特に、回線ポートとユーザ名は間違えやすいのでご注意ください。
回線/ポート (Line/Port): LGW02623_LGU ( @の前のみを使用します)
ユーザ名 (Username): LGW06676_LGU
credentials number LGW02623_LGU username LGW06676_LGU password qgOqfn--3( realm BroadWorks
SIP/2.0 401 Unauthorized
<snip>
Reason: Q.850;cause=1;text="User not Found"
SIP/2.0 404 Not Found
<snip>
Reason: Q.850;cause=1;text="User not Found"
検索バーにキーワード、フレーズ、または質問を入力し、お探しのものを見つけましょう
シスコ コミュニティをいち早く使いこなしていただけるよう役立つリンクをまとめました。みなさんのジャーニーがより良いものとなるようお手伝いします
