CUBE での複数の M 回線によるファックス障害のトラブルシューティング

概要

このドキュメントでは、プロバイダーからの複数のm回線が原因で発信ファックス障害が発生した場合に、Cisco Unified Border Element(CUBE)の問題を解決する方法について説明します。CUBEは複数のm行を認識しませんが、Session Initiation Protocol(SIP)プロファイルを使用して問題を解決するために、CUBEに回避策を実装できます。

前提条件

要件

このドキュメントに特有の要件はありません。

使用するコンポーネント

このドキュメントの情報は、次のハードウェアとソフトウェアのバージョンに基づいています。

• Fax Server
• Cisco Unified Communications Manager（CUCM）
• CUBE

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。

Network Topology

このドキュメントで説明する例では、次のネットワークトポロジを使用しています。

問題

プロバイダーがVoice-to-faxスイッチオーバー中にCUBEにInviteメッセージを送信し、2つのm行を含むSession Description Protocol(SDP)を含む場合、CUBEの元の動作はSIP 488 Not Acceptable Hereメッセージででコールをを拒否することでした。

Cisco Bug ID CSCtw96549以降、この動作は変更されています。ここで、プロバイダーが2つのm行を含むSDPを送信すると、コールは期待どおりに処理されます。

受け入れられたM線形式の例を次に示します。

m=音声
m=イメージ

ただし、プロバイダーがM回線形式を逆にしてSDPを送信すると、CUBEはSDPを正しく処理せず、Inviteメッセージでファックスサーバに不正なSDPを送信します。したがって、すべてのコールが失敗します。

受け入れられないM線形式の例を次に示します。

m=イメージ
m=音声

ヒント：詳細については、Cisco Bug ID CSCue70469を参照してください。

解決方法

この問題のトラブルシューティングを行うには、発信ファックステストコールを発信し、SIPデバッグ(debug ccsip messages)を収集します。 デバッグ出力から、次の確認を行うことができます。

• 音声コールは問題なく確立されます。
  
  
• コールをファックスにエスカレーションする時間になると、V.21プリアンブルが検出されると、プロバイダー側でスイッチオーバーが開始されます。
  

  注：スイッチオーバーを開始するために呼び出される側では、必ずしも必須とは限りません。複数のFAXサーバーには、呼び出し元の端末であっても、スイッチオーバーを開始する機能があります。これは、T.30インジケータパケットの発信側(CNG)トーンのカプセル化によって行われます。

• スイッチオーバーのre-inviteには2つのメディア回線(m=)があり、m=image行がm=audio行の上に配置されます。この場合、Cisco Bug ID CSCue70469で説明されている不具合が発生し、CUBEがコールを切断します。

現在、CUBEでこの問題を解決することはできませんが、この問題を回避するために外部要因を変更できます。

• Voice-to-Fax Switch-overには1本のm回線のみを使用します。
  
  
• プロトコルベースのパススルーを使用します。
  
  
• プロバイダにm=audio行をm=image行の上に配置してもらいます。
  
  
• T.30インジケータパケットでCNGを使用してスイッチオーバーを開始するには、ファックスサーバを使用します。

CUBEバージョン10.0では、着信SIPプロファイルに新しい機能が使用されます。この機能では、SIPプロファイルがSIPスタックに提示されて処理される前に、着信SIPメッセージに適用されます。このシナリオで着信SIPプロファイルを使用する背後にある考え方は、m=audio回線をすべて一緒に削除して、CUBEが1つのm=image回線だけで動作できるようにする。

プロバイダーが音声コールをファクスにエスカレーションする場合のre-Inviteメッセージの例を次に示します。

Received:
INVITE sip:025027141@192.0.2.2:5060 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnm30rd10dofho0fo9011sb0000g00.1
Call-ID: 6B6CB982-B41D11E3-898F851F-F1ADD198@192.0.2.2
From: <sip:026455288@25027100.xyz>;tag=7qapqh6u-CC-36
To: "Administrator" <sip:025027141@25027100.xyz>;tag=85A6C018-2489
CSeq: 1 INVITE
Contact: <sip:192.0.2.1:5060;transport=udp>
Max-Forwards: 69
Content-Length: 431
Content-Type: application/sdp
v=0
o=HuaweiSoftX3000 22157305 22157306 IN IP4 192.0.2.1
s=Sip Call
c=IN IP4 192.0.2.1
t=0 0
m=image 53200 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy
m=audio 53190 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=silenceSupp:off - - - -
a=ecan:fb on -
a=X-fax
================================

次のSIPプロファイル設定を適用して、m=オーディオ回線を削除できます。

voice class sip-profiles 966
request REINVITE sdp-header Audio-Media modify "(.*)" "a=sendrecv"
voice service voip
sip
voice-class sip profiles 966 inbound
or 
dial-peer voice XYZ voip
voice-class sip profiles 966 inbound

このSIPプロファイルはm=audio行をa=sendrecvに変更します。これは、関連のないSDPの行として機能します。これにより、CUBEはFAXサーバー側に再招待メッセージを送信し、200 OK応答を待つことができます。

また、次の重要な点にも対処する必要があります。受信したre-Inviteに応答して200 OKメッセージがプロバイダーに送信されると、RFCに準拠し、応答メッセージがofferメッセージと同じ数のメディア属性を持つようにするために、両方のm行を示す必要があります。

これは、プロバイダーを指すダイヤルピアに適用される標準の発信SIPプロファイルを使用して実現できます。

voice class sip-profiles 200
response 200 method re-invite sdp-header Attribute modify "t38UDPRedundancy"
 "t38UDPRedundancy\x0D\x0Am=audio 0 RTP/AVP"

これにより、複数のm行を含むre-Inviteが正しく処理され、「t38UPRedundancy」が次のように置き換えられるため、プロバイダーへの応答がRFC準拠になります。

"t38UDPRedundancy"
New line ( \x0D\x0A )
m=audio 0 RTP/AVP

要約すると、複数のm回線の問題を解決するには、このドキュメントで説明されている回避策（ほとんどの場合、プロバイダー依存）を使用します。また、XmediusサーバがT.38 re-Inviteメッセージを強制的に送信し、複数のm行の表示を回避するため、スイッチオーバーを開始できることも確認されています。