Voix et communications unifiées : Logiciel Cisco Unified Border Element

Dépannez les pannes de télécopie dues à de plusieurs M-lignes sur le CUBE

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document décrit comment résoudre un problème sur le Logiciel Cisco Unified Border Element (CUBE) quand les pannes sortantes de télécopie se produisent en raison de plusieurs m-lignes d'un fournisseur. Le CUBE ne comprend pas de plusieurs m-lignes, mais un contournement peut être mis en application sur le CUBE afin de résoudre le problème avec l'utilisation des profils de Protocole SIP (Session Initiation Protocol).

Contribué par Kaustubh Inamdar et Mudit Mathur, ingénieurs TAC Cisco.

Conditions préalables

Conditions requises

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

Composants utilisés

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

  • Serveur de télécopie
  • Cisco Unified Communications Manager (CUCM)
  • CUBE

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Topologie du réseau

L'exemple qui est décrit dans ce document utilise cette topologie du réseau :

Problème

Quand un fournisseur envoie un message d'invitation au CUBE pendant une Voix-à-télécopie commutée, et il inclut une Session Description Protocol (SDP) qui contient deux m-lignes, le comportement d'origine du CUBE était de rejeter l'appel avec un message non acceptable du SIP 488 ici.

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

Voici un exemple d'un format ligne reçu :

m=audio
m=image

Cependant, si un fournisseur envoie un SDP avec le format ligne renversé, le CUBE ne le traite pas correctement et envoie un SDP mal formé au serveur de télécopie dans le message d'invitation. Par conséquent, tout l'échouer d'appels.

Voici un exemple d'un format ligne inaccepté :

m=image
m=audio

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

Solution

Afin de dépanner cette question, faire un appel d'essai sortant de télécopie et collecter le SIP met au point (debug ccsip messages). De la sortie de débogage, ces observations peuvent être faites :

  • La communication voix établit sans des questions.

  • Quand il est temps de faire suivre l'appel faxer, le commuté est initié par le fournisseur-side à la découverte du préambule V.21.

    Remarque: Il n'est pas toujours obligatoire pour le côté qui s'appelle pour initier le commuté. Plusieurs serveurs de télécopie ont la capacité pour initier le commuté, quoiqu'ils soient le terminal dont l'appel commence. Ceci est fait par l'intermédiaire de l'encapsulation de la tonalité (CNG) appelante dans les paquets de l'indicateur T.30.

  • La re-invitation pour le commuté a deux lignes de medias (m=) tels que la ligne de m=image est placée au-dessus de la ligne de m=audio, dans ce cas le défaut qui est décrit dans l'ID de bogue Cisco CSCue70469 surgit et le CUBE déconnecte l'appel.

Actuellement, il n'y a aucune résolution pour cette question sur le CUBE, mais vous pouvez modifier le contournement externe de facteurs la question :

  • Utilisez seulement un m-line pour la Voix-à-télécopie commutée.

  • Intercommunication basée sur des protocoles d'utilisation.

  • Faites placer le fournisseur la ligne de m=audio au-dessus de la ligne de m=image.

  • Utilisez le serveur de télécopie afin d'initier le commuté avec l'utilisation de CNG dans un paquet de l'indicateur T.30.

La version 10.0 de CUBE influence une nouvelle caractéristique pour des profils d'arrivée de SIP, où les profils de SIP sont appliqués sur un message SIP d'arrivée avant qu'il soit présenté à la pile de SIP et traité. L'idée derrière l'utilisation des profils d'arrivée de SIP dans ce scénario est de retirer toute de m=audio la ligne ensemble de sorte que le CUBE puisse fonctionner avec seulement une ligne simple de m=image.

Voici un exemple du message de re-invitation quand le fournisseur désire faire suivre la communication voix pour faxer :

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 de SIP peut être appliquée afin de retirer la ligne de 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 de SIP change la ligne de m=audio à l'a=sendrecv, qui agit en tant que ligne dans le SDP qui n'est pas approprié. Ceci permet au CUBE pour envoyer un message de re-invitation au côté de serveur de télécopie et pour attendre la réponse de 200 OKS.

Vous devez également aborder un aspect plus important : Quand le message de 200 OKS est envoyé au fournisseur en réponse au reçu re-invitez, il doit présenter chacun des deux m-lignes afin de se conformer au RFC et s'assurer que le message de réponse a le même nombre d'attributs de medias que le message d'offre.

Vous pouvez accomplir ceci par l'intermédiaire d'un profil sortant standard de SIP qui est appliqué sur le cadran-pair ces points au fournisseur :

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

Ceci s'assure que la re-invitation avec de plusieurs m-lignes est correctement manipulée et que la réponse au fournisseur est RFC-conforme parce que le "t38UDPReddundancy" est remplacé par :

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

En résumé, utilisez l'utilisation les des contournements qui sont décrits dans ce document (les la plupart dont soyez fournisseur-dépendant) la question de résolution de plusieurs m-lignes. En outre, on l'a observé que le serveur de Xmedius peut également initier le commuté, car il force le serveur à envoyer T.38 le message de re-invitation et évite la présentation de plusieurs m-lignes.


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 118939