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.
Ce document décrit l'analyse du journal des débogages générés dans l'interface de ligne de commande pour les téléphones IP Cisco 7800/8800 pour un problème audio unidirectionnel.
Lorsque vous dépannez un problème audio unidirectionnel, la première tâche consiste à dessiner la topologie et à déterminer le chemin et les périphériques des supports RTP (Real-Time Protocol) qui envoient et reçoivent des flux RTP. Une tâche particulièrement complexe consiste à déterminer si le téléphone IP envoyait et recevait les flux.
La méthode la plus courante consiste à collecter une capture de paquets à partir d'un téléphone IP Cisco, comme décrit dans l'article correspondant. Mais dans la plupart des cas, lorsque le problème est intermittent, il est difficile de déterminer le téléphone qui sera affecté par le problème audio unidirectionnel la prochaine fois.
Dans cet article, une autre méthode est utilisée. Il peut s'avérer très utile, en particulier lorsqu'il s'agit de problèmes audio à sens unique sporadiques.
Étape 1. Activez SSH sur le téléphone IP.
Étape 2. Étape facultative. Configurez le vidage des journaux téléphoniques vers le serveur Syslog.
Comme mentionné précédemment, un problème audio unidirectionnel est généralement intermittent. Si plusieurs téléphones sont affectés, vous devez configurer l'option de déversement des journaux vers un serveur Syslog distant.
Dans Cisco Unified Communications Manager (CUCM), activez les paramètres suivants.
Réinitialisez le téléphone.
Étape 3. Connectez-vous à l'interface de ligne de commande du téléphone via le protocole SSH.
Étape 4. Activez les journaux téléphoniques.
DEBUG> settmask -p ms -t 0xfffff -b LOG_DEBUG
DEBUG> debug lsm vcm fim fsm gsm
debugs: fim fsm gsm lsm sip-state sip-messages sip-reg-state ccdefault vcm
DEBUG> debug jvm SIPCC
DEBUG> Successfully executed the command.
Étape 5. Commencez à déverser les journaux.
DEBUG> sdump
Étape 6. Annulez la collection de journaux en réinitialisant le téléphone.
Calling phone firmware: sip78xx.10-3-1-12 Calling phone ip address: 10.62.153.20 Calling phone number: 5035 Called phone ip address: 10.229.16.243 Called phone number: 2211 CUCM version: 11.0.1.20000-2 CUCM Publisher ip address: 10.48.47.143 CUCM Subscriber ip address: 10.48.47.136 CUBE: 10.62.150.10
Premièrement, il est nécessaire de trouver la signalisation de l'appel qui présente un problème audio unidirectionnel.
Le moyen le plus simple est d'utiliser le numéro appelé comme paramètre de recherche.
Note: Dans les téléphones IP Cisco 7800/8800, tous les messages SIP envoyés et reçus sont disponibles avec des chaînes de recherche « sipio-sent » et « sipio-recv ».
Le téléphone envoie un message INVITE au serveur d'abonnés CUCM. Et reçoit des réponses standard. L'enregistrement d'ID d'appel permet de suivre tous les messages associés pour cet appel particulier.
0611 DEB Dec 21 14:33:00.127717 JAVA-sipio-sent---> INVITE sip:2211@10.48.47.136;user=phone SIP/2.0^M Via: SIP/2.0/TCP 10.62.153.20:52464;branch=z9hG4bK2037857c^M From: "5035" <sip:5035@10.48.47.136>;tag=c80084aa872103164b6d6bb1-699aac4f^M To: <sip:2211@10.48.47.136>^M Call-ID: c80084aa-8721000b-302564ee-403d3d01@10.62.153.20^M Max-Forwards: 70^M Date: Wed, 21 Dec 2016 14:33:00 GMT^M CSeq: 101 INVITE^M User-Agent: Cisco-CP7821/10.3.1^M Contact: <sip:2fbf6265-bffc-4f99-b8b2-40dce7ed2d19@10.62.153.20:52464;transport=tcp>^M Expires: 180^M Accept: application/sdp^M Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO^M Remote-Party-ID: "5035" <sip:5035@10.48.47.136>;party=calling;id-type=subscriber;privacy=off;screen=yes^M Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-7.0.0,X-cisco-xsi-8.5.1^M Allow-Events: kpml,dialog^M Content-Length: 348^M Content-Type: application/sdp^M Content-Disposition: session;handling=optional^M ^M v=0^M o=Cisco-SIPUA 7726 0 IN IP4 10.62.153.20^M s=SIP Call^M t=0 0^M m=audio 27986 RTP/AVP 9 0 8 116 18 101^M c=IN IP4 10.62.153.20^M a=rtpmap:9 G722/8000^M a=rtpmap:0 PCMU/8000^M a=rtpmap:8 PCMA/8000^M a=rtpmap:116 iLBC/8000^M a=fmtp:116 mode=20^M a=rtpmap:18 G729/8000^M a=fmtp:18 annexb=yes^M a=rtpmap:101 telephone-event/8000^M a=fmtp:101 0-15^M a=sendrecv^M 0650 DEB Dec 21 14:33:00.171483 JAVA-sipio-recv<--- SIP/2.0 100 Trying^M 0782 DEB Dec 21 14:33:00.249127 JAVA-sipio-recv<--- SIP/2.0 180 Ringing^M
En huit secondes, l'appelé répond à l'appel et les flux audio sont établis. Il est important de noter les adresses multimédias négociées. Les adresses multimédias sont négociées dans les messages INVITE et 200 OK pour le mode SIP d'offre anticipée, et dans 200 OK suivi par ACK pour le mode d'offre différée.
1150 DEB Dec 21 14:33:08.179266 JAVA-sipio-recv<--- SIP/2.0 200 OK^M Via: SIP/2.0/TCP 10.62.153.20:52464;branch=z9hG4bK2037857c^M From: "5035" <sip:5035@10.48.47.136>;tag=c80084aa872103164b6d6bb1-699aac4f^M To: <sip:2211@10.48.47.136>;tag=59591~c6f18c49-d13e-4c97-aefc-039c35dcaca0-37698453^M Date: Wed, 21 Dec 2016 14:32:59 GMT^M Call-ID: c80084aa-8721000b-302564ee-403d3d01@10.62.153.20^M CSeq: 101 INVITE^M Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY^M Allow-Events: presence^M Supported: replaces^M Server: Cisco-CUCM11.0^M Call-Info: ; security= NotAuthenticated; orientation= to; gci= 2-6064; isVoip; call-instance= 1^M Send-Info: conference, x-cisco-conference^M Remote-Party-ID: <sip:2211@10.48.47.136>;party=called;screen=no;privacy=off^M Session-ID: f329a19bdd6e9960881d66e6bab59592;remote=7d416919fab94807bcc061c4baa59591^M Remote-Party-ID: <sip:2211@10.48.47.136;user=phone>;party=x-cisco-original-called;privacy=off^M Contact: <sip:2211@10.48.47.136:5060;transport=tcp>^M Content-Type: application/sdp^M Content-Length: 236^M ^M v=0^M o=CiscoSystemsCCM-SIP 59591 1 IN IP4 10.48.47.136^M s=SIP Call^M c=IN IP4 10.62.150.10^M b=TIAS:64000^M b=AS:64^M t=0 0^M m=audio 23672 RTP/AVP 0 101^M a=ptime:20^M a=rtpmap:0 PCMU/8000^M a=rtpmap:101 telephone-event/8000^M a=fmtp:101 0-15^M
Enfin, recherchez le message de fin d'appel.
2081 DEB Dec 21 14:33:18.688956 JAVA-sipio-recv<--- BYE sip:2fbf6265-bffc-4f99-b8b2-40dce7ed2d19@10.62.153.20:52464;transport=tcp SIP/2.0^M Via: SIP/2.0/TCP 10.48.47.136:5060;branch=z9hG4bK17c47b18ed76^M From: <sip:2211@10.48.47.136>;tag=59591~c6f18c49-d13e-4c97-aefc-039c35dcaca0-37698453^M To: "5035" <sip:5035@10.48.47.136>;tag=c80084aa872103164b6d6bb1-699aac4f^M Date: Wed, 21 Dec 2016 14:33:07 GMT^M Call-ID: c80084aa-8721000b-302564ee-403d3d01@10.62.153.20^M User-Agent: Cisco-CUCM11.0^M Max-Forwards: 70^M CSeq: 101 BYE^M Reason: Q.850;cause=16^M Session-ID: f329a19bdd6e9960881d66e6bab59592;remote=7d416919fab94807bcc061c4baa59591^M Remote-Party-ID: <sip:2211@10.48.47.136;user=phone>;party=x-cisco-original-called;privacy=off^M Content-Length: 0^M ^M
Lors de l'analyse d'un périphérique de boîte noire, prêtez attention aux horodatages, en particulier en relation avec un contexte d'appel.
Vérifiez que la transmission n'est pas encore active.
0407 NOT Dec 21 14:33:00.082822 ms-RTCPMGR.rtcpm_getSr[A:17] TX stream state not connected [ingress=0][state=0] 1144 NOT Dec 21 14:33:08.152988 ms-RTCPMGR.rtcpm_getSr[A:17] TX stream state not connected [ingress=7][state=1]
Messages à mettre à jour les paramètres des flux audio de réception (RX).
1380 NOT Dec 21 14:33:08.220957 ms-RTPSESSION.ms_updateRTPRxParam[A:17] UPDATE RX [mediaType(codec)=4][dynamicPayloadType=0][hootNumTalkers=0][dtmfPayloadType=101][pktperiod=20][security=0] 1481 INF Dec 21 14:33:08.282028 ms-RCVMGR.receiveManagerStartReceive[A:17] Start RX 5: syncId 5, codec 16, rtnCode 0
Messages qui affichent des informations sur le flux audio transmis (TX).
1668 DEB Dec 21 14:33:08.380273 ms-RTPSESSION.startRTPSessionTx[A:17] enter 1670 DEB Dec 21 14:33:08.380395 ms-RTPMGR.rtpmgr_txStart[A:17] [streamId=7] enter 1673 INF Dec 21 14:33:08.380609 ms-MGRRTP.rtpTransmitStart[A:17] TX [CT=1][msPktSz=20][Ssrc=0xE322D7C2][Csrc=0x0][fTyp=0][SPF=80][FPP=2][pktSz=236][Buf=Y] 1674 INF Dec 21 14:33:08.380670 ms-MGRRTP.rtpTransmitStart[A:17] RFC2833: [PT=101][tsscale=8][pktPeriod=20][step=10][sizeof=4] 1771 NOT Dec 21 14:33:08.407650 ms-RTPSESSION.ms_startRTPSessionTx[A:17] START TX: [mediaType(codec)=4][pkt size=20][remote IPv4=10.62.150.10][rport=23672][groupid=8][callid=8]
La fin de l'appel est possible avec la transition d'état ONHOOK.
2113 NOT Dec 21 14:33:18.699974 JAVA-SIPCC-CC_API: 1/8, cc_int_onhook: GSM -> SIP: ONHOOK After the call is terminated RTP statistics will be displayed. From this message it is clear that the phone did not receive any packets, so the next step would be to enable packet captures on the CUBE. 2121 NOT Dec 21 14:33:18.701225 ms-MS.statm_printDecoderStats[A:17] [Rx Count=0][Rx Lost=0][Pkts Discarded=0][Rx Octets=0] [Avg Jitter=0][Max Jitter=0] [RFC2833=0] [CCR=0.0000][ICR=0.0000][MaxCR=0.0000][CS=0][SCS=0] Encoder stats display that 514 packets were sent. 2124 NOT Dec 21 14:33:18.701897 ms-MS.statm_printEncoderStats[A:17] [Tx Count=514][TX Octets=82240]
Astuce : La durée de l'appel peut être comptée en divisant le nombre de paquets transmis sur la période de mise en paquets. Dans l'exemple 514 / 50 = 10,28 secondes.