内容

概要

前提条件

要件

使用するコンポーネント

Network Topology

問題

解決方法

概要

このドキュメントでは、プロバイダーからの複数の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行の表示を回避するため、スイッチオーバーを開始できることも確認されています。