Expressway を介した B2B 通話での最も一般的な問題のトラブルシューティング
内容
概要
このドキュメントでは、Business to Business（B2B）の導入での最も一般的な問題について説明します。Expressway を介した B2B 通話のトラブルシューティング方法です。
前提条件
要件
次の項目に関する知識があることが推奨されます。
- Expressway-C（Exp-C）
- Expressway-E
- Cisco Unified Call Manager（CUCM）
- Telepresence Video Communication Server-C（VCS-C）
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
- Expressway C および E X8.1.1 以降
- Unified Communications Manager（CUCM）10.0 またはそれ以降。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
一般的な問題
1. エラー「//SIP/SIPTcp/wait_SdlReadRsp:Ignoring large message.Only allow up to 5000 bytes.Resetting connection.（サイズの大きなメッセージを無視します。表示可能なメッセージは 5000 バイトまでです。接続をリセットします）」
VCS に登録されている TelePresence エンドポイントから、Session Initiation Protocol（SIP） トランクで着信し、CUCM に送信されるコールが、次で失敗します。「//SIP/SIPTcp/wait_SdlReadRsp:Ignoring large message.Only allow up to 5000 bytes.Resetting connection.（サイズの大きなメッセージを無視します。表示可能なメッセージは 5000 バイトまでです。接続をリセットします）」
Expressway-C/VCS-C でのコール ルーティングの設定は正しく、コールは CUCM に送信されます。SIP Invite メッセージは CUCM に 送信されますが、SDL ログには SIP メッセージはありません。このエラーは SDL ログで確認できます。
"|AppInfo |SIPTcp - xxx.xxx.xxx:[27469]からの大きなメッセージを無視します。Only allow up to 5000 bytes.Resetting connection.（サイズの大きなメッセージを無視します。表示可能なメッセージは 5000 バイトまでです。接続をリセットします）」
CUCM 8.6以降では、SIP Max Incoming Message Sizeのデフォルト値は5000でしたが、CUCM 9.Xが11000に変更された後に、バージョン9または10にアップグレードすると、以前のバージョン(5000)の0のデフォルト値がになります。
解決方法
この問題は不具合 CSCts00642 に関連しています。
CUCM の [高度なサービス パラメータ（Advanced Service Parameter）] の [SIP の最大受信メッセージ サイズ（SIP Max Incoming Message Size）] を、デフォルト値の 5000 からこのタイプのコールに適したサイズに増やしてください。想定される顧客シナリオの大半では 11000 の値で問題ないようです。
CUCM の [管理（Administration）] ページで、[サービス パラメータ（Service Parameters）] に移動し、CUCM サーバと CallManager サービスを選択します。
[高度（Advanced ）] オプションを選択し、[SIP の最大受信メッセージ サイズ（SIP Max Incoming Message Size）] を検索します。
2.別のコールサーバがコールを転送すると、メディアストリームが停止します。
この問題はモバイルおよびリモート アクセス（MRA）および B2B コールで発生することがあります。
コールの転送後に、片方で音が鳴らなかったり、ブーンという音（暗号化された音声でキャプチャを再生しようとするときに聞こえるものと同じノイズ）が発生したりすることがあります。この問題は、転送先のエンドポイントでサポートされていない暗号スイートがコールのセットアップで選択されているために発生します。
コールの転送前後のSIPネゴシエーションを比較できます。VCSまたはCUCMログの最初のネゴシエーションでは、VCSからの200 OKメッセージに暗号行が表示されます。
m=audio 54582 RTP/SAVP 9 96 97 0 8 18 101 a=rtpmap:9 G722/8000 a=rtpmap:96 G7221/16000 a=fmtp:96 bitrate=32000 a=rtpmap:97 G7221/16000 a=fmtp:97 bitrate=24000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:ckXijkT3CcVY+xlOf3ozX/TjHPz05OzEdY49rAHA|2^48 a=sendrecv a=rtcp:54583 IN IP4 10.1.201.7 m=video 54658 RTP/SAVP 96 97 b=TIAS:4000000 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42e01e;max-fs=1621;packetization-mode=1;max-rcmd-nalu-size=32000;level-asymmetry-allowed=1 a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=42e01e;max-fs=1621;packetization-mode=0;level-asymmetry-allowed=1 a=rtcp-fb:* nack pli a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:S8BJvGB/2l6F7XP8izXxId443Xd9f27oUI/4gxSt|2^48
暗号行は最初のコールでは受け入れられていますが、2 番目のコールでは ACK メッセージによって暗号行が削除されていることがわかります。
m=audio 24826 RTP/AVP 0 c=IN IP4 10.1.231.30 a=ptime:20 a=rtpmap:0 PCMU/8000 m=video 0 RTP/AVP 126 c=IN IP4 10.1.98.80 b=TIAS:448000 a=label:11 a=rtpmap:126 H264/90000 a=fmtp:126 profile-level-id=42E01F;packetization-mode=1;max-fs=3601;max-rcmd-nalu-size=32000;level-asymmetry-allowed=1 a=content:main
VCS は、コールの転送先であるエンドポイントが暗号化をサポートしていない場合でも、最初にネゴシエートされた暗号行の使用を試みます。
解決方法
この問題は不具合 CSCuv11790 に関連しています。
この問題を修正するには、VCS/Expressway を x8.6.1 にアップグレードしてください。
3. CUCMでトップレベルドメインが設定されていない
[最上位ドメイン（Top Level domain）] エンタープライズ パラメータが CUCM で設定されていない場合、CUCM によって着信コールが独自のドメインにルーティングされ、SIP ルート パターンが使用されます。コールが Exp-C に送り返される可能性が非常に高いため、これが原因でループが生じることがあります。また、「404 Not Found エラー」で失敗することもあります。
解決方法
CUCM の [管理（Administration）] ページで、[システム（System）] > [エンタープライズ パラメータ（Enterprise Parameters）] に移動してこの設定を変更してください。
4. CUCM証明書にクライアント認証属性が適用されていること。
Exp-C と CUCM 間でセキュアな接続を設定した場合（TLS 検証をオン）、コールの方向に応じて、特定のコール サーバによって SSL ハンドシェイクが開始されます。このため、両方のサーバの証明書にクライアントおよびサーバの認証が必要になります。このエラーは、属性が存在しない場合に VCS/Expressway ログに記録されます。
Line 190: 2015-05-07T07:34:01-04:00 XXXXXXXXXXXXXXXX tvcs: UTCTime="2015-05-07 11:34:01,060" Module="network.tcp" Level="DEBUG": Src-ip="10.50.47.16" Src-port="45215" Dst-ip="10.50.47.51" Dst-port="5061" Detail="TCP Connecting" Line 239: 2015-05-07T07:34:01-04:00 XXXXXXXXXXXXXXXX tvcs: UTCTime="2015-05-07 11:34:01,071" Module="network.tcp" Level="DEBUG": Src-ip="10.50.47.16" Src-port="45215" Dst-ip="10.50.47.51" Dst-port="5061" Detail="TCP Connection Established" Line 249: 2015-05-07T07:34:01-04:00 XXXXXXXXXXXXXXXX tvcs: UTCTime="2015-05-07 11:34:01,081" Module="network.tcp" Level="DEBUG": Src-ip="10.50.47.16" Src-port="45215" Dst-ip="10.50.47.51" Dst-port="5061" Detail="TCP Connection Closed" Reason="no certificate returned"
解決方法
Web クライアント属性とサーバ属性の両方を持つテンプレートを設定する方法については、VCS 証明書ガイドを参照してください。
5.インターワーキングの問題
VCS/Expressway バージョン X8.6.x で、インターワー キング プロセスにいくつかの問題がありました。
問題に関連するバグ：
VCS/Expressway からの診断ログで拒否状態のビデオ m 行をチェックした場合、不具合 CSCuw85626 が検出されることがあります。
H323 フローの TCS 部分のメディア行がネゴシエートされている場合、次のエラー メッセージが表示されます。
medialine index:1
rejected:true, direction:SDP_MEDIA_DIR_SENDRECV
type：video / SDP_MF_AU_VID
不具合 CSCuw85715 は同様ですが、この場合は、VCS/Expressway のログによって原因は dataTypeNotSupported であることが示されます。
2015-10-29T09:49:00+04:00 XXXXXXXXXXXXXXXX tvcs: UTCTime="2015-10-29 05:49:00,197" Module="network.h323" Level="INFO": Action="Sent" Dst-ip="XXXXXXXXXXXXXXXX" Dst-port="49162"
Detail="Sending H.245 OpenLogicalChannelRejResponse "
2015-10-29T09:49:00+04:00 XXXXXXXXXXXXXXXX tvcs: UTCTime="2015-10-29 05:49:00,197" Module="network.h323" Level="DEBUG": Dst-ip="XXXXXXXXXXXXXXXX" Dst-port="49162"
Sending H.245 PDU:
value MultimediaSystemControlMessage ::= response : openLogicalChannelReject :
{
forwardLogicalChannelNumber 3,
cause dataTypeNotSupported : NULL
}
解決方法
X8.7 以降にアップグレードしてください。
6. CUCMから受信したACKメッセージがVCS-E/Expressway-Eに送信されない
これは通常、設定されているトラバーサル ゾーンが VCS Expressway/Expressway-E の正しい IP アドレスをポイントしていない場合に発生します。
シングル NIC の展開（Expressway/Edge 上）では、Control/Core のトラバーサル クライアント ゾーンはトラバーサル サーバのパブリック IP アドレスをポイントする必要があります。
デュアル NIC の展開では、トラバーサル クライアントはトラバーサル サーバの内部 IP アドレスをポイントする必要があります（内部 NIC は通常は LAN1 ですが LAN2 の場合もあります）。これは内部 LAN の内部 IP アドレスであることに注意してください。
解決方法
さまざまなネットワーク展開の詳細と図については、『Cisco VCS Expressway と VCS Control - 基本設定』の付録 4 を参照してください。
7. CUCMが着信コールでTCPセッションをドロップする
コールが VCS control/Expressway Core から転送されるとき、CUCM で TCP セッションのドロップによりコールが拒否されることがあります。
これは、ネイバー ゾーンと sip トランク セキュリティ プロファイルの間でポートが一致しない場合、またはポートが 5060/5061 となるように設定されている場合に発生する可能性があります。
MRA ではインライン通信が使用されますが、B2B コールではトランク通信が使用されます。CUCM の制限のため、インライン通信とトランク通信が同じポートを通過することはできません。ほとんどの場合、MRA は自動的に設定されるため、B2B の展開で別のポートを使用する必要があります。
解決方法
そのためには、ネイバー ゾーンで CUCM（VCS-C/Expressway-C 上）に設定する宛先ポートを 5060/5061 以外にする必要があります。通常は 5065 を使用しますが他のポートも使用できます。設定するポートは、CUCM 上のこのサーバへの sip トランクに割り当てられている sip トランク セキュリティ プロファイルで設定されているポートに合わせる必要があります。
CUCM の [管理（Administration）] ページで、[デバイス（Device）] > [トランク（Trunk）] に移動します。
ポートが 5065 の SIP トランク セキュリティ プロファイル。
SIP トランク宛先ポートは、図に示すように 5060/5061 にすることができます。
図に示すように、VCS/Expressway のネイバー ゾーンの SIP ポートを、SIP トランク セキュリティ プロファイルで設定されているポートに合わせる必要があります。
Expressway の [管理（Administration）] ページで、[設定（Configuration）] > [プロトコル（Protocols）] > [SIP] に移動します。
VCS では、この制限がないか、このシナリオには適用されません、つまり、SIP トランク自体を 5060/5061 を使用して設定できます。
8. VCSがFQDNを正しく解決できないか、SRVレコードのクエリに失敗します。
CUCM から発信される B2B コールでは、CUCM におけるコールの処理方法とルーティング方法の性質上、問題が生じることがあります。
CUCMがVCSサーバにコールを転送する場合、CUCMは、expresswayに到達してDNSゾーンに対する検索ルールをヒットするときに、ダイヤルされたURIの最後に：5060または：5061（設定によって0）を0)追加0)する0 AAAレコード用のie。これは、VCS/Expressway から診断ログで確認できます。
解決方法
この問題を解決するには、単に、DNS ゾーンに到達する前に最後にポートを削除するトランスフォーメーションを作成します（どちらのサーバでも問題ありません）。
[Expressway Administration]ページから、 [Configuration] > [Dial Plan] > [Transforms] y [Configuration] > [Dial Plan] > [Transform]に移動します。
トランスフォーメーションの例：
何らかの理由でトランスフォーメーションを作成できない場合は、検索ルールを使用することもできますが、トランスフォーメーションを使用することをお勧めします。
Expressway の [管理（Administration）] ページで、[設定（Configuration）] > [ダイヤル プラン（Dial Plan）] > [トランスフォーメーション（Transforms）] y [設定（Configuration）] > [ダイヤル プラン（Dial Plan）] > [検索ルール（Search Rules）] に移動します。
フィードバック