Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Le but de ce document est de fournir une explication détaillée des tonalités de rappel audio communément appelées tonalités de progression d'appel ou tonalités CPtones pour abréger.
Ce document tentera de discuter et de fournir une analyse du fonctionnement de la reconnexion dans tous les protocoles VoIP (Voice over IP) et de signalisation analogique.
Bien qu'il n'y ait pas de condition préalable formelle nécessaire pour lire ce document ; il a été écrit en espérant que le lecteur possède déjà une certaine connaissance pratique des protocoles de signalisation vocale sous-jacents utilisés pour établir et connecter des appels téléphoniques. Ces protocoles sont référencés plusieurs fois dans ce document.
Protocoles de signalisation : SIP (Session Initiation Protocol), H323 (h225 / h245), MGCP (Media Gateway Control Protocol), SCCP (Skinny Client Control Protocol), RNIS Q931, E1 R2.
Protocoles multimédias : protocole RTP (Real Time Protocol), codecs vocaux, codecs vidéo.
Technologies analogiques : Ear and Mouth (E&M), Foreign Exchange Subscriber (FXS), Foreign Exchange Office (FXO) et E1 R2.
Les informations de ce document sont basées sur les logiciels et le matériel suivants :
Passerelles Cisco IOS et IOS-XE (2800 / 3800 / 2900 / 3900 / 4300 / 4400 / CSR1000v / ASR100X) exécutant n'importe quelle version d'IOS/IOS-XE.
Cisco Unified Communications Manager (CUCM) versions 9.X et ultérieures
Cisco Unity Connection (CUC) versions 9.x et ultérieures
Customer Voice Portal (CVP) version 9.x et ultérieure
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. Si votre réseau est actif, assurez-vous de bien comprendre l'impact potentiel de toute commande ou configuration.
Rinback n'est pas un protocole VoIP ou analogique, mais il est présent dans tous les téléphones portables, les lignes fixes, les téléphones de bureau et les clients logiciels. Ainsi, comprendre comment cela fonctionne, d'où il vient et comment résoudre les problèmes de retour en arrière est une partie importante de l'outil des ingénieurs de collaboration.
La sonnerie est une séquence de tonalités jouées à la personne qui passe un appel téléphonique, qui permet à l'appelant de savoir que la personne appelée sonne réellement. L'absence de sonnerie doit être considérée comme un mauvais signe car l'appelant suppose que l'appelé ne sonne pas. Les tonalités Ringback / CPtones varient d'un pays à l'autre. Si une personne doit appeler un numéro des États-Unis, elle recevra un autre jeu de sonneries que si cette même personne appelait un numéro du Royaume-Uni.
Dans la plupart des scénarios, la sonnerie est lue par l'appelé distant à l'appelant. Pour que cela se produise, le son doit être coupé dans la direction arrière (Appelé à l'appelant).
Ce document examine les différents protocoles et la manière dont ils négocient le retour d'appel ainsi que la façon de manipuler le retour d'appel lors de l'utilisation de ce protocole.
La norme RNIS Q.931 a utilisé le concept des indicateurs de progrès (PI) qui peuvent être affichés dans la signalisation Q.931. Ceci est visible sur les passerelles vocales Cisco en exécutant debug isdn q931. Les indicateurs de progression peuvent être envoyés dans les messages Alert, Progress, Call Proceeding, Setup Ack et Disconnect. Une valeur d'indicateur de progression de 1 ou 8 permet de couper le son vers l'arrière pour les messages de retour d'appel et d'erreur. Les valeurs de l'indicateur de progression 0, 2 et 3 ne traversent pas les supports à l'envers. Un DSP attribué au canal RNIS peut lire la sonnerie sur la ligne RNIS si le destinataire distant ne peut pas le faire.
Cavasses connues avec Ringback RNIS
Indicateurs d'avancement Q931
Valeur | Définition | Message Q.931 |
Indicateur de progression = 0 | hors bande | Configuration |
Indicateur de progression = 1 | L'appel n'est pas un RNIS de bout en bout. Des informations supplémentaires sur la progression des appels peuvent être disponibles en bande | Alerte, connexion, progression, configuration |
Indicateur de progression = 2 | L'adresse de destination n'est pas RNIS. | Alerte, connexion, progression |
Indicateur de progression = 3 | L'adresse de destination n'est pas RNIS. | Configuration |
Indicateur de progression = 8 | Des informations intrabande ou un modèle approprié sont désormais disponibles. | Alerte, connexion, progression, déconnexion |
Exemples d’indicateurs de progression intrabande Q.931 RNIS
Jun 22 15:16:36.790: ISDN Se0/2/0:23 Q931: TX -> ALERTING pd = 8 callref = 0x80A3 Progress Ind i = 0x8188 - In-band info or appropriate now available
Nov 28 21:25:41.754: ISDN Se0/1/1:15 Q931: TX -> PROGRESS pd = 8 callref = 0x805C Progress Ind i = 0x8188 - In-band info or appropriate now available
Configuration
La sonnerie RNIS fonctionne de manière fiable par défaut. Aucune configuration supplémentaire n’est donc requise. Cependant, il existe des commandes permettant de modifier le comportement en cas de besoin d'interopérabilité.
Modification manuelle de la valeur progress_ind.
Remarques importantes :
Syntaxe complète des commandes :http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr3/vcr3-cr-book/vcr-p2.html#wp1001337490
! progress_ind { alert | callproc } { enable pi-number | disable | strip [strip-pi-number] } progress_ind { connect | disconnect | progress | setup } { enable pi-number | disable } ! dial-peer voice 1 pots destination-pattern 8675309$ progress_ind alert enable 8 progress_ind callproc enable 8 progress_ind connect enable 8 progress_ind disconnect enable 8 progress_ind progress enable 8 progress_ind progress setup 1 ! dial-peer voice 2 pots destination-pattern 8675309$ progress_ind alert strip 8 progress_ind callproc strip 8 ! dial-peer voice 3 pots destination-pattern 8675309$ progress_ind alert disable progress_ind callproc disable progress_ind connect disable progress_ind disconnect disable progress_ind progress disable progress_ind progress disable !
Exiger qu'une passerelle vocale envoie toujours des messages d'alerte
Si un administrateur a besoin d'une passerelle vocale, il doit toujours envoyer un message d'alerte avant qu'une commande Connect isdn send-alerting puisse être configurée sous une interface série. Ceci est désactivé par défaut
Syntaxe complète des commandes : http://www.cisco.com/c/en/us/td/docs/ios/dial/command/reference/dia-cr-book/dia_i2.html
! interface Serial0/0/0:23 isdn send-alerting !
Déboguages
debug isdn q931 debug voip ccapi inout
Le protocole H.323 et plus précisément le protocole de signalisation VOIP H.225 ont été construits sur le protocole Q.931 de RNIS. Ils partagent donc beaucoup d'éléments communs. La plupart des commandes présentes et des idées derrière la requête d'appel Q.931 sont présentes dans H.323/H.225. Cela inclut les valeurs de l'indicateur de progression, les types de message et les commandes.
Exemple de message H.225 pour Rinback
*Jun 22 11:32:52.080: H225.0 INCOMING PDU ::= value H323_UserInformation ::= { h323-uu-pdu { h323-message-body alerting :
Configuration
Les normes H.323 et H.225 ne nécessitent aucune configuration pour la reconnexion hors du boîtier. Cependant, les commandes spécifiées dans la section RNIS Q.931 s'appliquent également à la technologie Ringback H.323. En outre, des commandes sont disponibles pour la signalisation H.323.
Commande | Définition |
voice call send-alert |
|
voice rtp send-recv | Ouvre le canal audio RTP dans les deux directions. |
! dial-peer voice 1 voip tone ringback alert-no-pi ! dial-peer voice 2 pots tone ringback alert-no-pi ! |
|
Configurations CUCM
Il existe certaines configurations H.323 spécifiques pour la reconnexion dans CUCM>
Chemin de navigation : CUCM > System > Service Parameters > Pub > CallManager > Send H225 User Info Message > Use ANN For Ringback
Valeur | Définition |
Utiliser ANN pour la sonnerie arrière | Utiliser Cisco SCCP Annunciator pour lire la tonalité de retour d'appel (disponible dans Cisco CallManager version 4.0 et ultérieure) |
Informations utilisateur pour la tonalité de progression d'appel | Envoyer un message d'informations utilisateur H.225 à la passerelle IOS pour lire la tonalité de retour d'appel ou la tonalité en attente (il s'agit de la tonalité par défaut.) |
Infos H225 pour tonalité de progression d'appel | Envoyer un message d'information H.225 à la passerelle IOS pour lire la tonalité de retour ou la tonalité d'attente |
Déboguages
debug voip ccapi inout debug h225 asn1
Il s'agit également d'un excellent document sur le dépannage de la fonction Ringback H.323
http://www.cisco.com/c/en/us/support/docs/voice/h323/22983-ringback.html
La sonnerie SIP implique généralement l'un des deux messages. 180 et 183. Le document RFC 3261 indique que 0, 1 ou plus de ces messages 1XX peuvent être reçus après un message INVITE. Par conséquent, il n'est pas contraire au document RFC de ne pas recevoir l'un de ces messages. Si aucun n'est reçu, il n'y aura pas de retour. Par conséquent, si un appelant attend une sonnerie sous une forme ou une autre, un 180 ou 183 sont requis.
Un 180 et un 183 peuvent tous deux contenir le protocole SDP (Session Description Protocol) que CUBE traitera comme support initial. Lorsque le SDP est présent dans un message 18X, CUBE et CUCM s'attendent à ce que le périphérique distant qui envoie le 18X avec le SDP lise la sonnerie à partir de l'adresse IP spécifiée dans le SDP. Il n'existe aucune configuration pour modifier ce comportement dans CUCM ou CUBE. Certains périphériques nécessitent un échange PRACK (rel1xx) sur le message 18X avant l'envoi de la sonnerie.
Le RFC3960 présente des détails supplémentaires sur la signalisation de retour d'appel avec SIP.
Il est important de noter que pour SIP à RNIS et SIP à H.323, un 18X avec SDP correspond à un indicateur de progression intrabande tandis qu'un 18X sans SDP correspond à une alerte.
Exemple 183 avec SDP
SIP/2.0 183 Session Progress Via: SIP/2.0/TCP 10.10.10.10:5060;branch=z9hG4bK6350828126b1a From: <sip:8675309@10.10.10.10>;tag=85512413~796a13c3-49d2-74ec-19db-f4258d9eef64-40934478 To: <sip:123456789@10.10.10.1>;tag=BA0FA04C-97B Date: Wed, 22 Jun 2016 11:32:51 GMT Call-ID: 575b0c00-76a177e1-57ea4-2009000a CSeq: 101 INVITE Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER Allow-Events: telephone-event Remote-Party-ID: <sip:8675309@10.10.10.10>;party=called;screen=no;privacy=off Contact: <sip:8675309@10.10.10.10:5060;transport=tcp> Supported: sdp-anat Server: Cisco-SIPGateway/IOS-15.4.3.M2 Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 250 v=0 o=CiscoSystemsSIP-GW-UserAgent 9474 3602 IN IP4 172.16.37.129 s=SIP Call c=IN IP4 10.10.10.10 t=0 0 m=audio 17606 RTP/AVP 8 101 c=IN IP4 10.10.10.10 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20
Exemple 180 sans SDP
SIP/2.0 180 Ringing Via: SIP/2.0/TCP 10.10.10.10:5060;branch=z9hG4bKd34f2a2080 From: <sip:2002@10.10.10.10>;tag=17170~21823a7a-6ec3-4a2f-9307-df98bca4b011-23314477 To: <sip:3001@10.10.10.1> ;tag=1ADFB1AC-3CB Date: Tue, 26 Jan 2016 22:05:06 GMT Call-ID: d859d700-6a71ed8f-26-a21030e CSeq: 102 INVITE Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER Allow-Events: telephone-event Remote-Party-ID: < sip:3001@10.10.10.10> ;party=called;screen=yes;privacy=off Contact: < sip:3001@10.10.10.10:5060;transport=tcp> Server: Cisco-SIPGateway/IOS-12.x Content-Length: 0
Configuration
Commande | Définition |
! sip-ua disable-early-media 180 ! |
Utilisé pour spécifier quel traitement d'appel, support précoce ou sonnerie locale, est fourni pour 180 réponses avec 180 réponses avec le protocole SDP (Session Description Protocol) |
! voip voice service sip bloc {180 | 181 | 183} sdp {actuel | absent} ! |
Bloque les messages spécifiques relatifs à la sonnerie |
Profil SIP pour transformer une session 183 en cours en session 180.
! voice service voip sip sip-profiles inbound ! voice class sip-profiles 777 response 183 sip-header SIP-StatusLine modify "SIP/2.0 183 Session Progress" "SIP/2.0 180 Ringing" ! dial-peer voice 777 voip voice-class sip profile 777 inbound !
Activation de PRACK (rel1xx) dans CUCM.
Chemin du menu système : Périphérique > Paramètres du périphérique > Profil Sip > Choisir un profil SIP > SIP Rel1XX
Options
Activation de PRACK (rel1xx) sur les passerelles
Déboguages
debug voip ccapi inout debug ccsip messages
MGCP est le côté VOIP qui contrôle les ports FXS et RNIS T1/E1. Vous pouvez vérifier si CUCM envoie la signalisation de retour d'appel appropriée au port spécifique, mais il n'y a pas beaucoup de configuration à faire.
Exemple de message de rappel MGCP de CUCM vers un port VG224 FXS
Apr 29 01:01:38.264: MGCP Packet received from 14.50.244.2:2427---> RQNT 37 AALN/S2/1@vg224 MGCP 0.1 X: 1b R: L/hu S: G/rt Q: process,loop <---
S : = Événements Signalés et g/rt = Package générique / Tonalité de retour
Configuration CUCM
Chemin du menu système : Système > Paramètres de service > Pub > CallManager > Désactiver l'indicateur de progression des alertes
Configuration de la passerelle
Déboguages
debug mgcp packet
debug voip ccapi nout
debug vpm signal debug voip vtsp session
Pour les téléphones IP SCCP enregistrés à CUCM ou CME, un message StartToneMessage est envoyé au téléphone IP qui indique au téléphone local de lire la sonnerie de la personne qui passe l'appel.
Débogages de retour pour tous les ports vocaux analogiques :
debug voip ccapi inout debug vpm signal debug voip vtsp session
GATEWAY(config)#voice-port 0/2/0 GATEWAY(config-voiceport)#cptone ? locale 2 letter ISO-3166 country code AR Argentina IN India PA Panama AU Australia ID Indonesia PE Peru AT Austria IE Ireland PH Philippines BE Belgium IL Israel PL Poland BR Brazil IT Italy PT Portugal CA Canada JP Japan RU Russian Federation CL Chile JO Jordan SA Saudi Arabia CN China KE Kenya SG Singapore CO Colombia KR Korea Republic SK Slovakia C1 Custom1 KW Kuwait SI Slovenia C2 Custom2 LB Lebanon ZA South Africa CY Cyprus LU Luxembourg ES Spain CZ Czech Republic MY Malaysia SE Sweden DK Denmark MT Malta CH Switzerland EG Egypt MX Mexico TW Taiwan FI Finland NP Nepal TH Thailand FR France NL Netherlands TR Turkey DE Germany NZ New Zealand AE United Arab Emirates GH Ghana NG Nigeria GB United Kingdom GR Greece NO Norway US United States HK Hong Kong OM Oman VE Venezuela HU Hungary PK Pakistan ZW Zimbabwe IS Iceland
Sortie de debug ccapi inout, debug vpm signal et debug voip vtsp session pour l'appel E1 R2 indiquant la reconnexion.
042446: May 12 14:51:15.816 GMT: //2475488/47922BA59254/CCAPI/cc_api_call_alert: Interface=0x3ECE2770, Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1) 042447: May 12 14:51:15.816 GMT: //2475488/47922BA59254/CCAPI/cc_api_call_alert: Call Entry(Retry Count=0, Responsed=TRUE) 042448: May 12 14:51:15.816 GMT: //2475487/47922BA59254/CCAPI/ccCallAlert: Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1) 042449: May 12 14:51:15.816 GMT: //2475487/47922BA59254/CCAPI/ccCallAlert: Call Entry(Responsed=TRUE, Alert Sent=TRUE)htsp_alert_notify 042450: May 12 14:51:15.816 GMT: r2_reg_event_proc(0/0/1:1(1)) ALERTING RECEIVED 042451: May 12 14:51:15.816 GMT: R2 Incoming Voice(0/1): DSX (E1 0/0/1:0): STATE: R2_IN_WAIT_REMOTE_ALERT R2 Got Event R2_ALERTING 042452: May 12 14:51:15.816 GMT: rx R2_ALERTING in r2_comp_wait_remote_alert 042453: May 12 14:51:15.816 GMT: r2_reg_generate_digits(0/0/1:1(1)): Tx digit '1' 042454: May 12 14:51:16.672 GMT: //2475487/47922BA59254/VTSP:(0/0/1:1):0:1:1/vtsp_report_cas_digit: End Digit=2, Mode=CC_TONE_R2_MF_BACKWARD_MODE 042455: May 12 14:51:16.672 GMT: htsp_digit_ready(0/0/1:1(1)): Rx digit='#'
CVP signale à la passerelle VXML de lire la tonalité en envoyant un message INVITE avec un numéro spécifique.
Exemple : 9191
Le SDP de cet INVITE sera l'endroit où nous voulons que la passerelle VXML envoie une sonnerie.
Cela correspond à un terminal de numérotation dial-peer configuré avec un service de retour d'appel configuré.
Le retard de la liaison de retour d’appel est généralement dû à un retard de la signalisation sous-jacente. Les débogages et les journaux pour le périphérique et les protocoles utilisés doivent être consultés pour savoir pourquoi la signalisation est retardée.
En cas d'échec de signalisation de la passerelle vocale sur les terminaux de numérotation dial-peer et de re-chasse des terminaux de numérotation dial-peer, le périphérique tente de trouver un saut suivant pour l'appel.
Comme vous pouvez le voir tout au long du document, la collecte de débogages ccapi est très importante pour TOUT problème de retour d'appel.
l'API de contrôle d'appel (CCAPI) est responsable du pontage des deux côtés d'un appel sur une passerelle vocale et, par conséquent, de l'assemblage de la sonnerie d'un appel à l'autre.
Exemples de sortie de débogage de CCAPI pour la restauration
Feb 2 21:27:18.884: //22/9285F23E801B/CCAPI/cc_api_call_alert: Interface=0x3AB79E8, Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
Jun 23 13:32:34 EDT: //1204/77232A800001/CCAPI/cc_api_call_cut_progress: Interface=0x7FD5FD1CEE10, Progress Indication=INBAND(8), Signal Indication=INTERCEPT(2), Cause Value=0 Jun 23 13:32:34 EDT: //1203/77232A800001/CCAPI/ccCallCutProgress: Progress Indication=INBAND(8), Signal Indication=INTERCEPT(2), Cause Value=0 Voice Call Send Alert=FALSE, Call Entry(Alert Sent=FALSE)
Jun 22 11:32:52.096: //204706/575B0C000000/CCAPI/ccCallAlert: Progress Indication=INBAND(8), Signal Indication=SIGNAL RINGBACK(1)
Nov 28 21:25:41.748: //43495/0C82F2F380B7/CCAPI/cc_api_call_cut_progress: Interface=0x7F8028B60F90, Progress Indication=INBAND(8), Signal Indication=SIGNAL RINGBACK(1), Cause Value=0 Nov 28 21:25:41.749: //43494/0C82F2F380B7/CCAPI/ccCallCutProgress: Progress Indication=INBAND(8), Signal Indication=SIGNAL RINGBACK(1), Cause Value=0 Voice Call Send Alert=FALSE, Call Entry(Alert Sent=FALSE) Nov 28 21:25:41.749: //43494/0C82F2F380B7/CCAPI/ccGenerateToneInfo: Stop Tone On Digit=FALSE, Tone=Null, Tone Direction=Network, Params=0x0, Call Id=43494
Selon votre signalisation, tout peut sembler correct. Cependant, il se peut qu'il n'y ait toujours pas de retour arrière. Si le signal indique qu'une partie spécifique doit renvoyer une tonalité à votre périphérique, il est utile de saisir une capture de paquets ou de PCM à partir du port vocal pour vérifier si la tonalité est effectivement lue ou non.
Il est également important de vérifier le routage de couche 3 à partir de la source et de la destination. s'ils ne peuvent pas envoyer de paquets RTP à votre périphérique, vous n'entendrez pas le son. En outre, si vous ne pouvez pas envoyer de paquets à un périphérique spécifique, ils n'entendront pas votre rappel.
Commandes de routage de couche 3 utiles
show ip route show ip cef <remote_ip> ping a.b.c.d source <interface> traceroute a.b.c.d
Documentation de capture PCM :
http://www.cisco.com/c/en/us/support/docs/voice/h323/116078-technologies-technote-commandrefe.html