01-19-2021 09:53 AM
I have just provisioned two TDM VGWs side-by-side to interface to a ROLM PBX, and will provide access from the existing ROLM PBX stations to a new VoIP infrastructure, but more immediately will connect to two SIP SBCs for PSTN access. At this point I just have the two TDM VGWs connected to the PBX with two T-1 CAS trunks each. On VGW 06B, I have an analog phone directly connected on fxs 0/2/0 and can receive calls from either trunk directly connected to VGW 06B. However, when a call comes in over either T-1 CAS trunk to VGW 06A destined for the test phone on 06B, the caller gets a fast-busy. I have my dial-peers set up to take incoming calls over the T-1 CAS trunks, and for eventual redundancy routing for calls coming in from the SBC and destined for stations on the PBX, routing to the other TDM VGW via dial peers 20001 and 40001 for calls coming into extensions 2.... and 4.... in case the local TDM VGWs T-1's are down.
Thin config is below. Please see diagram and debug CCAPI/dialpeer attached. It's been about 7 years since I've done ANY voice and assume I'm missing something really stupid with my dialpeers.
Any/all help is appreciated!!!
Mike
VGW05A
!
interface Loopback1
ip address 10.45.0.128 255.255.255.255
h323-gateway voip interface
!
dial-peer voice 29976 voip
description NEFK322PBXVGWTDM06B Analog Test Phone
destination-pattern 29976
session target ipv4:10.45.0.129
voice-class codec 1
voice-class h323 1
dtmf-relay h245-alphanumeric
ip qos dscp cs3 signaling
no vad
!!
dial-peer voice 20001 voip
preference 2
destination-pattern 2....
session target ipv4:10.45.0.129
voice-class codec 1
voice-class h323 1
dtmf-relay h245-alphanumeric
ip qos dscp cs3 signaling
no vad
!
dial-peer voice 40001 voip
preference 2
destination-pattern 4....
session target ipv4:10.45.0.129
voice-class codec 1
voice-class h323 1
dtmf-relay h245-alphanumeric
ip qos dscp cs3 signaling
no vad
!
!
dial-peer voice 1 pots
incoming called-number .
direct-inward-dial
!
!
-------------------------
VGW 05B
!
interface Loopback1
ip address 10.45.0.129 255.255.255.255
h323-gateway voip interface
!
!
voice-port 0/2/0
description 29976 Analog Test Phone
!
!
dial-peer voice 29976 pots
description Test Analog Phone
destination-pattern 29976
port 0/2/0
!
dial-peer voice 20001 voip
preference 2
destination-pattern 2....
session target ipv4:10.45.0.128
voice-class codec 1
voice-class h323 1
dtmf-relay h245-alphanumeric
ip qos dscp cs3 signaling
no vad
!
dial-peer voice 40001 voip
preference 2
destination-pattern 4....
session target ipv4:10.45.0.128
voice-class codec 1
voice-class h323 1
dtmf-relay h245-alphanumeric
ip qos dscp cs3 signaling
no vad
!
dial-peer voice 1 pots
incoming called-number .
direct-inward-dial
!
!
Solved! Go to Solution.
01-19-2021 02:53 PM - edited 01-19-2021 02:54 PM
Hi Mike,
It looks like the call from 06B to 06A is matching a dial-peer tag of 2, but I don't see that listed above in the configs you've supplied?
The disconnect cause code I have taken from your outputs below from on 06A is 21, which is call rejected.
Jan 15 14:43:57.815: //32381/EC9D9B8D837F/CCAPI/cc_process_call_setup_ind:
>>>>CCAPI handed cid 32381 with tag 2 to app "_ManagedAppProcess_TOLLFRAUD_APP"
Jan 15 14:43:57.815: //32381/EC9D9B8D837F/CCAPI/ccCallDisconnect:
Cause Value=21, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
Jan 15 14:43:57.815: //32381/EC9D9B8D837F/CCAPI/ccCallDisconnect:
Cause Value=21, Call Entry(Responsed=TRUE, Cause Value=21)
My first thoughts were it might be the toll fraud app introduced in IOS 15.X being invoked, but that would only occur if you didn't already have an authorized call source configured in your dial-peers. Do you have all call processing sources configured in your dial-peers? If not, please add the following to gateway A:
voice service voip
ip address trusted list
ipv4 10.1.1.1 255.255.255.255 (replace with your call processing server)
Regards,
Scott
01-19-2021 08:45 PM - edited 01-19-2021 08:45 PM
Add the Source IP on both gateways using below command.
voice service voip
ip address trusted list
ipv4 Source IP
i can see dial peer with destination pattern 2.... and 4.... pointing to each device as a loop . its not a good design.
01-19-2021 02:53 PM - edited 01-19-2021 02:54 PM
Hi Mike,
It looks like the call from 06B to 06A is matching a dial-peer tag of 2, but I don't see that listed above in the configs you've supplied?
The disconnect cause code I have taken from your outputs below from on 06A is 21, which is call rejected.
Jan 15 14:43:57.815: //32381/EC9D9B8D837F/CCAPI/cc_process_call_setup_ind:
>>>>CCAPI handed cid 32381 with tag 2 to app "_ManagedAppProcess_TOLLFRAUD_APP"
Jan 15 14:43:57.815: //32381/EC9D9B8D837F/CCAPI/ccCallDisconnect:
Cause Value=21, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
Jan 15 14:43:57.815: //32381/EC9D9B8D837F/CCAPI/ccCallDisconnect:
Cause Value=21, Call Entry(Responsed=TRUE, Cause Value=21)
My first thoughts were it might be the toll fraud app introduced in IOS 15.X being invoked, but that would only occur if you didn't already have an authorized call source configured in your dial-peers. Do you have all call processing sources configured in your dial-peers? If not, please add the following to gateway A:
voice service voip
ip address trusted list
ipv4 10.1.1.1 255.255.255.255 (replace with your call processing server)
Regards,
Scott
01-20-2021 08:22 AM
Thank you Scott! That did it!
01-19-2021 08:45 PM - edited 01-19-2021 08:45 PM
Add the Source IP on both gateways using below command.
voice service voip
ip address trusted list
ipv4 Source IP
i can see dial peer with destination pattern 2.... and 4.... pointing to each device as a loop . its not a good design.
01-20-2021 08:24 AM
Thank you Nithin- that was the problem...
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