Fehlerbehebung bei Faxfehlern aufgrund mehrerer M-Leitungen im CUBE

Einführung

In diesem Dokument wird beschrieben, wie ein Problem mit dem Cisco Unified Border Element (CUBE) behoben werden kann, wenn ausgehende Faxausfälle aufgrund mehrerer m-lines eines Providers auftreten. Das CUBE versteht nicht mehrere m-Zeilen, es kann jedoch eine Lösung auf dem CUBE implementiert werden, um das Problem mithilfe von SIP-Profilen (Session Initiation Protocol) zu beheben.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Hardware- und Softwareversionen:

• Faxserver
• Cisco Unified Communications Manager (CUCM)
• CUBE

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Netzwerktopologie

Im in diesem Dokument beschriebenen Beispiel wird die folgende Netzwerktopologie verwendet:

Problem

Wenn ein Anbieter eine Einladungs-Nachricht an das CUBE während eines Switchovers zwischen Voice und Fax sendet und ein Session Description Protocol (SDP) mit zwei m-Leitungen enthält, war das ursprüngliche Verhalten des CUBE, den Anruf mit einer SIP 488 Not Acceptable Here-Nachricht abzulehnen.

Nach der Cisco Bug-ID CSCtw96549 hat sich dieses Verhalten geändert. Wenn ein Anbieter nun ein SDP mit zwei m Leitungen sendet, wird der Anruf wie erwartet weitergeleitet.

Hier ein Beispiel für ein akzeptiertes m-line-Format:

m=Audio
m=Bild

Wenn ein Anbieter jedoch ein SDP mit umgekehrtem m-Line-Format sendet, verarbeitet das CUBE es nicht korrekt und sendet ein fehlerhaftes SDP an den Faxserver in der Einladungs-Nachricht. Aus diesem Grund schlagen alle Anrufe fehl.

Hier ein Beispiel für ein nicht akzeptiertes m-line-Format:

m=Bild
m=Audio

Tipp: Weitere Informationen finden Sie unter Cisco Bug ID CSCue70469.

Lösung

Um dieses Problem zu beheben, führen Sie einen ausgehenden Faxtestaufruf durch, und sammeln Sie die SIP-Debug-Meldungen (debug ccsip-Meldungen). Aus der Debugausgabe können folgende Beobachtungen gemacht werden:

• Der Anruf wird ohne Probleme eingerichtet.
  
  
• Wenn es an der Zeit ist, den Anruf an das Fax zu eskalieren, wird der Switchover vom Provider initiiert, sobald die V.21-Präambel erkannt wird.
  

  Hinweis: Es ist nicht immer zwingend erforderlich, dass die Seite, die aufgerufen wird, den Switchover zu initiieren. Mehrere Fax-Server können den Switchover initiieren, obwohl sie das Terminal sind, von dem der Anruf stammt. Dies erfolgt über die Kapselung des Anruftons (CNG) in den T.30-Indikatorpaketen.

• Die Re-invite-Funktion für den Switchover verfügt über zwei Medienleitungen (m=), sodass die m=image-Leitung über der m=audio-Leitung platziert wird. In diesem Fall tritt der in der Cisco Bug-ID CSCue70469 beschriebene Fehler auf, und das CUBE trennt den Anruf.

Derzeit gibt es für dieses Problem keine Lösung für das CUBE, Sie können jedoch die externen Faktoren ändern, um das Problem zu umgehen:

• Verwenden Sie nur eine m-Leitung für den Wechsel zwischen Voice und Fax.
  
  
• Verwenden Sie protokollbasiertes Passthrough.
  
  
• Lassen Sie den Anbieter die m=Audio-Leitung über der m=image-Leitung platzieren.
  
  
• Verwenden Sie den Faxserver, um den Switchover mithilfe von CNG in einem T.30-Anzeigepaket zu initiieren.

Die CUBE Version 10.0 nutzt eine neue Funktion für eingehende SIP-Profile, bei denen die SIP-Profile auf eine eingehende SIP-Nachricht angewendet werden, bevor sie dem SIP-Stack präsentiert und verarbeitet wird. Die Idee hinter der Verwendung der eingehenden SIP-Profile in diesem Szenario besteht darin, die m=audio-Leitung alle zusammen zu entfernen, sodass das CUBE mit nur einer m=image-Leitung arbeiten kann.

Hier ein Beispiel für die Re-Invite-Nachricht, wenn der Anbieter den Sprachanruf an das Fax eskalieren möchte:

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
================================

Diese SIP-Profilkonfiguration kann angewendet werden, um die m=Audio-Leitung zu entfernen:

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

Dieses SIP-Profil ändert die m=Audio-Leitung auf a=sendrecv, was als nicht relevante Leitung im SDP fungiert. Auf diese Weise kann das CUBE eine Re-Invite-Nachricht an den Faxserver senden und die 200 OK-Antwort abwarten.

Ein weiterer wichtiger Aspekt ist: Wenn die 200-OK-Nachricht als Antwort auf die empfangene Re-Invite an den Anbieter gesendet wird, muss sie beide m-Zeilen enthalten, um RFC einzuhalten und sicherzustellen, dass die Antwortnachricht dieselbe Anzahl von Medienattributen aufweist wie die Offertnachricht.

Dies kann über ein standardmäßiges ausgehendes SIP-Profil erreicht werden, das auf den Dial-Peer angewendet wird, der auf den Anbieter verweist:

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

Dadurch wird sichergestellt, dass die Re-Invite mit mehreren m-Zeilen ordnungsgemäß behandelt wird und dass die Antwort auf den Anbieter RFC-konform ist, da die "t38UDPRedundancy" durch folgende Elemente ersetzt wird:

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

Zusammenfassend können Sie die in diesem Dokument beschriebenen Workarounds (von denen die meisten anbieterabhängig sind) verwenden, um das Problem mit mehreren m-lines zu beheben. Außerdem wurde beobachtet, dass der Xmedius-Server auch den Switchover initiieren kann, da er den Server zwingt, die T.38-Re-Invite-Nachricht zu senden, und die Darstellung mehrerer M-Leitungen vermeidet.