Dépannage des échecs de télécopie dus à plusieurs lignes M sur le CUBE

Introduction

Ce document décrit comment résoudre un problème sur Cisco Unified Border Element (CUBE) lorsque des échecs de fax sortants se produisent en raison de plusieurs lignes m d'un fournisseur. Le CUBE ne comprend pas plusieurs lignes m, mais une solution de contournement peut être implémentée sur le CUBE afin de résoudre le problème avec l'utilisation de profils SIP (Session Initiation Protocol).

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Components Used

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Serveur de télécopie
• Gestionnaire de communications unifiées de Cisco (version CUCM)
• CUBE

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Topologie du réseau

L'exemple décrit dans ce document utilise cette topologie de réseau :

Problème

Lorsqu'un fournisseur envoie un message d'invitation au CUBE lors d'un basculement voix-télécopie, et qu'il inclut un SDP (Session Description Protocol) contenant deux lignes m, le comportement initial du CUBE était de rejeter l'appel avec un message SIP 488 Not Acceptable Here.

Après l'ID de bogue Cisco CSCtw96549, ce comportement a changé. Maintenant, si un fournisseur envoie un SDP avec deux lignes m, l'appel passe comme prévu.

Voici un exemple de format de ligne m accepté :

m=audio
m=image

Cependant, si un fournisseur envoie un SDP dont le format de ligne m est inversé, le CUBE ne le traite pas correctement et envoie un SDP incorrect au serveur de télécopie dans le message d'invitation. Par conséquent, tous les appels échouent.

Voici un exemple de format de ligne M non accepté :

m=image
m=audio

Astuce : Pour plus de détails, référez-vous à l'ID de bogue Cisco CSCue70469.

Solution

Afin de résoudre ce problème, passez un appel de test de fax sortant et collectez les débogages SIP (debug ccsip messages). À partir de la sortie de débogage, ces observations peuvent être faites :

• L'appel vocal s'établit sans problème.
  
  
• Lorsqu'il est temps de transférer l'appel vers la télécopie, le basculement est initié par le fournisseur lors de la détection du préambule V.21.
  

  Note: Il n'est pas toujours obligatoire pour le côté appelé d'initier le basculement. Plusieurs serveurs de télécopie peuvent initier le basculement, même s'ils sont le terminal à partir duquel l'appel provient. Cela se fait via l'encapsulation de la tonalité d'appel (CNG) dans les paquets de l'indicateur T.30.

• La réinvitation pour le basculement a deux lignes de média (m=) de sorte que la ligne m=image soit placée au-dessus de la ligne m=audio, auquel cas le défaut décrit dans l'ID de bogue Cisco CSCue70469 survient et le CUBE déconnecte l'appel.

Actuellement, il n'y a pas de solution à ce problème sur le CUBE, mais vous pouvez modifier les facteurs externes afin de contourner le problème :

• Utilisez une seule ligne m pour le commutateur voix-télécopie.
  
  
• Utiliser le transfert basé sur le protocole.
  
  
• Demandez au fournisseur de placer la ligne m=audio au-dessus de la ligne m=image.
  
  
• Utilisez le serveur de télécopie afin de lancer le basculement avec l'utilisation de GNC dans un paquet d'indicateur T.30.

La version CUBE 10.0 exploite une nouvelle fonctionnalité pour les profils SIP entrants, où les profils SIP sont appliqués sur un message SIP entrant avant qu'il ne soit présenté à la pile SIP et traité. L'idée derrière l'utilisation des profils SIP entrants dans ce scénario est de supprimer la ligne m=audio ensemble de sorte que CUBE puisse fonctionner avec une seule ligne m=image.

Voici un exemple du message de nouvelle invitation lorsque le fournisseur souhaite transférer l'appel vocal vers la télécopie :

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

Cette configuration de profil SIP peut être appliquée afin de supprimer la ligne m=audio :

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

Ce profil SIP modifie la ligne m=audio en a=sendrecv, qui agit comme une ligne dans le SDP qui n'est pas pertinente. Cela permet au CUBE d'envoyer un message de réinvitation au serveur de télécopie et d'attendre la réponse 200 OK.

Vous devez également aborder un aspect plus important : Lorsque le message 200 OK est envoyé au fournisseur en réponse à la nouvelle invitation reçue, il doit présenter les deux lignes m afin de se conformer à RFC et s'assurer que le message de réponse a le même nombre d'attributs de média que le message d'offre.

Pour ce faire, vous pouvez utiliser un profil SIP sortant standard appliqué sur le terminal de numérotation dial-peer qui pointe vers le fournisseur :

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

Cela garantit que la réinvitation avec plusieurs lignes m est correctement gérée et que la réponse au fournisseur est conforme RFC car la « t38UDPReddundancy » est remplacée par :

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

En résumé, utilisez les solutions de contournement décrites dans ce document (dont la plupart dépendent du fournisseur) afin de résoudre le problème de plusieurs lignes m. En outre, il a été observé que le serveur Xmedius peut également initier le basculement, car il force le serveur à envoyer le message de nouvelle invitation T.38 et évite la présentation de plusieurs lignes m.