cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
777
Views
10
Helpful
4
Replies

Call Routing Between TDM VGW Dial Peers

Michael Mertens
Level 1
Level 1

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
!
!

2 Accepted Solutions

Accepted Solutions

Scott Leport
Level 7
Level 7

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

 

 

 

 

 

View solution in original post

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.

 

 



Response Signature


View solution in original post

4 Replies 4

Scott Leport
Level 7
Level 7

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

 

 

 

 

 

Thank you Scott! That did it!

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.

 

 



Response Signature


Thank you Nithin- that was the problem...