cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2248
Views
0
Helpful
15
Replies

Voice call flow working just one direction in VOIP CUCM to POTS CME

ggomes63
Level 1
Level 1

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:

  • Branch Phones are registered in CUCM
  • On-net calls work fine
  • CUCM has a SIP trunk to the branch Router 1751 via VPN
  • Branch IOS router serves as Gateway to PTSN with a FXO access

Problem description:

  • Either trying to call PTSN -> On-Premises or the other way around, audio doesn’t come in but can go out, i.e, we can’t listen to outsiders.

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:

  1. For the tx stream destination IP is correct (IP phone registered in CUCM), but source IP missing
  2. For the rx stream destination IP is still the IP phone when should be the router, source IP missing
  3. rtp session is created as I believe correctly, 10.b.b.b (CME 1751 router) + 10.a.a.a (CUCM phone that makes the call)

 

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:

  • Telephone web GUI show sent rtp packets but receives none
  • Messing with MRGL to restrict the resources used to the subscriber used in the trunk
  • Changing dial-peers config

 

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

1 Accepted Solution

Accepted Solutions

ggomes63
Level 1
Level 1

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.

View solution in original post

15 Replies 15

b.winter
VIP
VIP

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?

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.

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).

It is the phone in CUCM making the call. No routing problems, everything is reachable. No FW drops.

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.

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:

  1. For the tx stream destination IP is correct (IP phone registered in CUCM), but source IP missing
  2. For the rx stream destination IP is still the IP phone when should be the router, source IP missing
  3. rtp session is created as I believe correctly, 10.b.b.b (CME 1751 router) + 10.a.a.a (CUCM phone that makes the call)

 

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.

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.

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.



Response Signature


Phone show Tx packets and zero Rx packet. No drops indicated.

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.

If you RX is Zero then packets are not reaching phones check your network.

I still stick with routing.



Response Signature


Most probably this could be routing issues. From gateway ping the phone Subnet.check network rechability.



Response Signature


No routing problems, everything is reachable.

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.



Response Signature