Probleemoplossing bij fax-fouten vanwege meerdere M-lijnen in CUBE

Inleiding

Dit document beschrijft hoe een probleem op het Cisco Unified Border Element (CUBE) moet worden opgelost wanneer uitgaande faxfouten optreden vanwege meerdere m-lijnen van een provider. CUBE begrijpt geen meerdere m-lijnen, maar er kan een tijdelijke oplossing worden gevonden in CUBE om de kwestie op te lossen met de profielen Session Initiation Protocol (SIP).

Voorwaarden

Vereisten

Er zijn geen specifieke vereisten van toepassing op dit document.

Gebruikte componenten

De informatie in dit document is gebaseerd op deze hardware- en softwareversies:

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

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.

Netwerktopologie

Het voorbeeld dat in dit document wordt beschreven gebruikt deze netwerktopologie:

Probleem

Wanneer een provider een Invite bericht naar CUBE stuurt tijdens een spraak-naar-fax-switch, en een SDP-protocol (Session Description Protocol) bevat dat twee m-lijnen bevat, was het oorspronkelijke gedrag van CUBE om de oproep te verwerpen met een SIP 488 Not Acceptable here-bericht.

Na Cisco bug-ID CSCtw96549 is dit gedrag gewijzigd. Als een provider een SDP verstuurt met twee m-lijnen, gaat de oproep door zoals verwacht.

Hier is een voorbeeld van een geaccepteerd m-line formaat:

m=audio
m=afbeelding

Als een provider echter een SDP verstuurt met teruggedraaid m-line formaat, verwerkt CUBE deze niet correct en stuurt u een foutieve SDP naar de faxserver in het Invite-bericht. Daarom faalden alle oproepen.

Hier is een voorbeeld van een niet-geaccepteerd m-line formaat:

m=afbeelding
m=audio

Tip: Raadpleeg voor meer informatie Cisco bug-ID CSCue70469.

Oplossing

Als u een oplossing voor deze kwestie wilt vinden, belt u een uitgaande faxtest en verzamelt u de SIP-apparaten (debug csip-berichten). Vanaf de debug-uitvoer kunnen deze observaties worden uitgevoerd:

• De spraakoproepen vinden plaats zonder problemen.
  
  
• Wanneer het tijd is om de roep om te faxen op te voeren, wordt de switch-over geïnitieerd door de provider-kant bij detectie van de V.21-preambule.
  

  Opmerking: Het is niet altijd verplicht voor de kant die wordt aangeroepen om de schakelaar te openen. Verschillende faxservers hebben de mogelijkheid om de switch-over te starten, ook al zijn het de terminal waarvan de oproep afkomstig is. Dit gebeurt via de insluiting van de tint (CNG) in de pakketten T.30.

• De re-nodig voor de schakelaar heeft twee media lijnen (m=) zodat de m=image lijn boven de m=audio lijn wordt geplaatst, in welk geval het defect dat in Cisco bug ID CSC70469 wordt beschreven en CUBE sluit de oproep af.

Op dit moment is er geen oplossing voor dit probleem in de CUBE, maar u kunt de externe factoren wijzigen om het probleem op te lossen:

• Gebruik slechts één m-lijn voor de spraak-aan-fax schakelaar-over.
  
  
• Gebruik op protocol gebaseerde doorloop.
  
  
• Laat de provider de m=audio lijn boven de m=image lijn plaatsen.
  
  
• Gebruik de faxserver om de schakelaar met het gebruik van CNG te openen in een T.30-indicatielampje.

CUBE versie 10.0 maakt gebruik van een nieuwe functie voor inkomende SIP-profielen, waarbij de SIP-profielen worden toegepast op een inkomende SIP-bericht voordat deze wordt aangeboden aan de SIP-stack en verwerkt. Het idee achter het gebruik van de inkomende SIP profielen in dit scenario is om de m=audio lijn samen te verwijderen zodat CUBE met slechts één m=image lijn kan werken.

Hier is een voorbeeld van het re-Invite bericht wanneer de leverancier de stemvraag aan fax wil verhogen:

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

Deze SIP-profielconfiguratie kan worden toegepast om de m=audio-lijn te verwijderen:

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

Dit SIP-profiel verandert de m=audio-lijn in a=sendrecv, die als een lijn in de SDP fungeert die niet relevant is. Hiermee kan CUBE een nieuw uitnodigingsbericht naar de kant van de faxserver sturen en in afwachting van de reactie van 200 OK.

U moet ook een ander belangrijk aspect aan de orde stellen: Wanneer het OK-bericht van 200 naar de aanbieder wordt gestuurd in antwoord op de ontvangen uitnodiging, moet deze beide m-lijnen presenteren om aan de RFC te voldoen en ervoor zorgen dat het antwoordbericht hetzelfde aantal media-eigenschappen heeft als het offertebericht.

U kunt dit bereiken via een standaard uitgaande SIP-profiel dat wordt toegepast op de dial-peer die op de provider wijst:

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

Dit waarborgt dat het opnieuw uitnodigen met meerdere m-lijnen correct wordt afgehandeld en dat de reactie op de leverancier RFC-conform is omdat de "t38UDPR-declerdancy" wordt vervangen door:

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

Samenvattend, gebruik maken van de in dit document beschreven (meestal van de leverancier afhankelijke) werkronden om het probleem van meerdere m-lijnen op te lossen. Ook is opgemerkt dat de Xmedius Server ook de switch-over kan initiëren, omdat het de server dwingt om het T.38-bericht opnieuw uit te zenden en de presentatie van meerdere m-lijnen vermijdt.