CUBE, SIP, One Way Routing and dial-peers

[David Baker]

Hi all, have a question that has me stumped (not terribly hard to do).   I'm setting up dial-peers on my CUBE to handle the call leg from the gateway to CUCM.   I have a default .T dial-peer setup that seems to work.   When I create more granular dial-peers, the call will ring through to my test phone, but I only have one way audio.   The only difference between my dial-peers is the destination pattern.   Below are the two dial-peers in question, dial-peer 101 does not work, dial-peer 102 does.  

!
dial-peer voice 101 voip
description Verizon calls to CUCM - all digits
destination-pattern .1T
session protocol sipv2
session server-group 1
voice-class codec 2
voice-class sip bind control source-interface GigabitEthernet0/0/1
voice-class sip bind media source-interface GigabitEthernet0/0/1
dtmf-relay rtp-nte
fax rate 14400
fax protocol pass-through g711ulaw
no vad
!
!
dial-peer voice 102 voip
description Verizon calls to CUCM - all digits
destination-pattern .T
session protocol sipv2
session server-group 1
voice-class codec 2
voice-class sip bind control source-interface GigabitEthernet0/0/1
voice-class sip bind media source-interface GigabitEthernet0/0/1
dtmf-relay rtp-nte
fax rate 14400
fax protocol pass-through g711ulaw
no vad
!

I'm sure you'll ask what I'm attempting to achieve.  The goal is to setup dial-peers for the various numbers we have coming into the gateway, separated by area code and exchange.   I'm just in the testing phase at the moment and relatively new to voice (routing and switch was my mainstay).   Also, the numbers we are getting from our service provider all contain +1 at the beginning.   Once I can get the calls moving through readily, I was going to work on stripping that off the front so the caller ID on the phone simply shows the 10 digit number.   

Any suggestions are greatly appreciated.

[Nithin Eluvathingal]

One way audio is mostly due to route issue. based on which side voice you hear you need to check the route. 

Second thing since its an incoming dial-peer to CUCM its not required to do that. send all incoming call to CUCM servers. When we  are sending it outside to ISP , we normally make it more precise dial-peers than using .T. 

[David Baker]

Thanks.   The one way audio is an interesting situation.  If I remove dial-peer 101 so that dp102 is the only one processing the inbound calls, I have no audio issues at all.  I'm still not sure why the variation in the destination pattern is causing the audio issue.

[Nithin Eluvathingal]

Since 101 and 102 dial-peer is for incoming why do you want to separate it. 

[David Baker]

Essentially testing.  I had created a number of dial-peers and when they were failing, minus the .T, I started stripping them down to find out why.   Those two dial-peers are essentially what works and what doesn't work in its simplest form.  Problem for me is, that it is either too simple, or I'm too simple, to see the solution.

Too add, the provider sends us numbers with a leading +1.   Our objective has been to strip the +1 off.

[TONY SMITH]

Are you sure your good and bad call examples are actually different outbound dial peers, and that this is the only difference?  And that they are not also using different inbound dial peers.  You can confirm the dial peer in use in a number of ways, but for test if you just have one call active at the time then "show call active voice | i PeerId" will give both inbound and outbound DPs.

And similarly, with just your test call active then you can show the addresses in use with  "sh call act voice | i IPAddress"

I must say I don't really get why you want different inbound dial peers for different number ranges, is there some different treatment you want for each range, that can only be done by using a different DP?