01-17-2023 05:04 AM - edited 01-19-2023 04:10 AM
Greetings everyone,
For weeks now that I’m struggling with the problem above. We have, as an institution a CUCM cluster in Headquarters connected through SIP trunks to our branches CME IOS Gateways.
This specific branch we have a more complex schema as we had hardware restrictions:
Problem description:
Configurations for the R1751 dial-peer and voice-port:
voice-port 0/0
no battery-reversal
disc_pi_off
cptone PT
timeouts interdigit 2
timeouts call-disconnect 3
timeouts wait-release 3
timing hookflash-out 50
timing guard-out 1000
connection plar 4XXXXX //Number registred in CUCM that serves that Branch reception
impedance complex2
!
voice-port 0/1
impedance complex2
!
dial-peer voice 110 voip
tone ringback alert-no-PI
destination-pattern [2-6].....
progress_ind setup enable 3
progress_ind progress enable 2
progress_ind connect enable 2
voice-class codec 1
session protocol sipv2
session target ipv4:10.c.c.c //CUCM Subscriber
!
dial-peer voice x25365514 pots
incoming called-number x25365514
destination-pattern [2,9]........
progress_ind setup enable 3
progress_ind alert enable 8
progress_ind progress enable 8
progress_ind connect enable 8
port 0/0
forward-digits 9
!
This is some rtp debug for an On-Premisses to PTSN that I think indicates the problem since the RTP streams IP doesn´t make sense. Traces are collected from the R1751 and two aspects must be noticed:
Jan 13 07:17:28.291: voip_rtp_create_session: callID=11, dstCallID=12 laddr=10.b.b.b, lport=17052,raddr=10.a.a.a, rport=22032, type=3, sig_tos=3, ip_tos=5
Jan 13 07:17:28.291: voip_rtcp_get_cname: cname=0.0.0@10.b.b.b
Jan 13 07:17:28.291: voip_rtp_update_xmit_info
Jan 13 07:17:28.291: voip_rtp_update_xmit_info, dstvdbptr: 825F83FC, dstCallID 12, gccb: 81532334, xmitFunc 8027E1D8,context 824530F4
Jan 13 07:17:28.291: voip_rtp_update_xmit_info Xmit Info node current values xmit_info->dstvdbptr: 825F83FC, xmit_info->dstCallID 12, xmit_info->xmitFunc 8027E1D8, xmit_info->context 824530F4
Jan 13 07:17:28.295: voip xmit info count: 1
Jan 13 07:17:28.295: voip_rtp_set_non_rtp_call: Non-RTP call end
Jan 13 07:17:28.295: voip_rtp_exchange_context_info
Jan 13 07:17:28.295: voip_rtp_update_xmit_info
Jan 13 07:17:28.295: voip_rtp_update_xmit_info, dstvdbptr: 825F83FC, dstCallID 12, gccb: 81532334, xmitFunc 8027E1D8,context 824530F4
Jan 13 07:17:28.295: voip_rtp_update_xmit_info Xmit Info node current values xmit_info->dstvdbptr: 825F83FC, xmit_info->dstCallID 12, xmit_info->xmitFunc 8027E1D8, xmit_info->context 824530F4
Jan 13 07:17:28.295: voip xmit info count: 1
Jan 13 07:17:28.295: voip_rtp_exchange_context_info
Jan 13 07:17:28.295: voip_rtp_update_xmit_info
Jan 13 07:17:28.295: voip_rtp_update_xmit_info, dstvdbptr: 825F83FC, dstCallID 12, gccb: 81532334, xmitFunc 8027E1D8,context 824530F4
Jan 13 07:17:28.295: voip_rtp_update_xmit_info Xmit Info node current values xmit_info->dstvdbptr: 825F83FC, xmit_info->dstCallID 12, xmit_info->xmitFunc 8027E1D8, xmit_info->context 824530F4
Jan 13 07:17:28.299: voip xmit info count: 1
Jan 13 07:17:28.299: voip_rtp_exchange_context_info
Jan 13 07:17:28.299: voip_rtp_update_xmit_info
Jan 13 07:17:28.299: voip_rtp_update_xmit_info, dstvdbptr: 825F83FC, dstCallID 12, gccb: 81532334, xmitFunc 8027E1D8,context 824530F4
Jan 13 07:17:28.299: voip_rtp_update_xmit_info Xmit Info node current values xmit_info->dstvdbptr: 825F83FC, xmit_info->dstCallID 12, xmit_info->xmitFunc 8027E1D8, xmit_info->context 824530F4
Jan 13 07:17:28.299: voip xmit info count: 1
Jan 13 07:17:28.303: voip_rtcp_start_session:
Jan 13 07:17:28.303: voip_rtcp_start_session: start session
Jan 13 07:17:28.315: RTP(101): fs tx d=10.a.a.a(22032), pt=8, ts=3F20, ssrc=24D204FD
Jan 13 07:17:28.335: RTP(102): fs tx d=10.a.a.a(22032), pt=8, ts=3FC0, ssrc=24D204FD
Jan 13 07:17:28.355: RTP(103): fs tx d=10.a.a.a(22032), pt=8, ts=4060, ssrc=24D204FD
----------(….)-------------
Jan 13 07:17:37.167: RTP(64628): ps rx d=10.a.a.a(22032), pt=8, ts=41562816, ssrc=F0E34107
Jan 13 07:17:37.175: RTP(255): fs tx d=10.a.a.a(22032), pt=8, ts=15400, ssrc=24D204FD
--------------------
MMP-R1751-VGW-FXO#sh voice call status
CallID CID ccVdb Port DSP/Ch Called # Codec Dial-peers
0x3C 1 0x825F83FC 0/0 0/1 *933333333 g711alaw 110/225365514
1 active call found
MMP-R1751-VGW-FXO#sh voice dsp
DSP DSP DSPWARE CURR BOOT PAK TX/RX
TYPE NUM CH CODEC VERSION STATE STATE RST AI VOICEPORT TS ABORT PACK COUNT
==== === == ======== ======= ===== ======= === == ========= == ===== ============
C549 000 00 g711alaw 4.1.41 Busy Idle 0 0 0/0 0 0 842135/30073
C549 000 01 g711ulaw 4.1.41 Idle Idle 0 0 0/1 NA 0 10/6
Active Voice Call details
C549 000 00 g711alaw 4.1.41 Busy Idle 0 0 0/0 0
Current total analog signalling channels: 2
Current max allowed digital timeslot for voice: 30
Current number of DSP group: 1
Group 0:
Current allocated analog signalling channels: 2
Current free analog signalling channels: 0
Current allocated digital signalling channels: 0
Current free digital signalling channels: 30
Port(s) served: 0/0 0/1
Current Available MIPS: 550
SPMM DSPRM State Image D-sig D-sig A-sig A-sig Mips Voice/Xcode
Dsp Dsp allocate free allocate free Free Chan
0/0 0 UP FIXHC 0 0 2 0 50 1
0/1 1 UP FLEX6 0 6 0 0 100 0
0/2 2 UP FLEX6 0 6 0 0 100 0
1/0 3 UP FLEX6 0 6 0 0 100 0
1/1 4 UP FLEX6 0 6 0 0 100 0
1/2 5 UP FLEX6 0 6 0 0 100 0
What did I went through:
I'm in a point without ideas, hopping the experts can help me, or tell me that it ain't possible because of router and card used for the FXO access (WIC/VIC-2FXO-EU)
[Edit]
R1751 config and requested debug for a call test attached. CUCM traces give Normal call clearing.
10.a.a.a - CUCM calling Phone IP
10.b.b.b - GW R1751
10.c.c.c - Subscriber
10.d.d.d - Publisher
411111 - CUCM Calling Number
93333333 - Called Number
Solved! Go to Solution.
01-30-2023 03:21 AM
Good morning everyone,
After some weeks of understanding the problem and trying to find a solution... I finally got it...
I used this Cisco one-way audio troubleshooting guide (https://www.cisco.com/c/en/us/support/docs/voice/voice-quality/5219-fix-1way-voice.pdf), and for me:
Binding the mgcp control and media to specific interface plus voice rtp send−recv.
Thank you for the support given.
01-17-2023 11:25 PM
Please post the full config (without sensitive data like username, password, enable secret, ...) and not just small pieces of it, this helps nobody to troubleshoot.
And also post the output of the following debugs in the GW:
debug voice ccapi ind 1
debug voice ccapi ind 2
debug voice ccapi ind 74
debug ccsip messages
And maybe also the logs of CUCM for one test call.
On your GWs, do you also have IP phones registered? Or are the only used for PSTN connection?
01-18-2023 02:06 AM
I updated my post with your contributes. IOS version in 1751 doesnt allow the debug commands you mentioned. GW only has the PTSN access nothing else.
01-18-2023 02:14 AM
Which device has this IP 10.105.3.81? Is this the phone?
If yes, is the GW able to reach this IP? As @Nithin Eluvathingal said, check basic IP routing (route from/to phone, route from/to GW, possible FW, ...).
According to the SIP messages, the media IP's involved are 10.105.3.81 (phone?) and the 10.b.b.b (GW).
01-18-2023 07:40 AM
It is the phone in CUCM making the call. No routing problems, everything is reachable. No FW drops.
01-18-2023 08:34 AM
The next step would be taking a packet capture on the router interface and confirming, that RTP packets are sent to the phone.
If that's the case, then the packets will get lost somewhere in between.
01-19-2023 02:47 AM
Packets are not being sent to Phone. I'm suspecting the problem can be identified by the RTP capture I did on the gateway:
This is some rtp debug for an On-Premisses to PTSN that I think indicates the problem since the RTP streams IP doesn´t make sense. Traces are collected from the R1751 and two aspects must be noticed:
Jan 13 07:17:28.291: voip_rtp_create_session: callID=11, dstCallID=12 laddr=10.b.b.b, lport=17052,raddr=10.a.a.a, rport=22032, type=3, sig_tos=3, ip_tos=5
Jan 13 07:17:28.291: voip_rtcp_get_cname: cname=0.0.0@10.b.b.b
Jan 13 07:17:28.291: voip_rtp_update_xmit_info
I just can't understand why are the rtp streams correctly build if the session creation is.
01-19-2023 03:25 AM - edited 01-19-2023 03:26 AM
Maybe someone, who uses the command regularly can spot an error in the output.
But I never used that command. I always take a pcap trace and open it in wireshark, because I see what really goes on on the interface and can be sure, that the packets go out or not. Additionally I see all the IP details I want to know. And it doesn't take me more than 5 mins.
But it's your decision, how and what you troubleshoot, we can only provide suggestions based on the knowledge each helper has and the info you provide.
01-19-2023 04:01 AM
One quick way if the phone receive RTP packets is by While you are on call, go to phone status and check the call status it shows RX and TX. if you dont see RX on phone you need to find out which device drop the packets.
01-19-2023 06:06 AM
Phone show Tx packets and zero Rx packet. No drops indicated.
01-19-2023 06:44 AM
Then you have problems somewhere in between.
But again, if you wanna confirm, that the router is sending the packet, you have to do a packet capture.
01-19-2023 06:51 AM
If you RX is Zero then packets are not reaching phones check your network.
I still stick with routing.
01-18-2023 02:05 AM
Most probably this could be routing issues. From gateway ping the phone Subnet.check network rechability.
01-18-2023 07:39 AM
No routing problems, everything is reachable.
01-18-2023 10:55 AM
The Media will be from gateway to phone. if gateway is not able to reach phone subnet audio will not be heard on the phone.
Theses kind of issues are mostly due to network. you can alos Try a different line card and see if it makes any change.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide