Voice Class URI pattern options ping on 2 different dial-peers

[gurungs]

Hi,

Currently on our Cisco CUBE we receive calls from SP for 2 different DDI ranges.

For options ping, SP requires 200 OK response from the SP Facing IP, for e.g loopback2 , but the CUBE uses its physical IP as default for this response.

So we've used voice class uri as below:

!

voice class uri 1 sip

pattern ping@[SP_IP]

!

then added this on the 2 incoming dial-peer as below:

Dial-peer voice 1 voip

incoming uri from 1

voice-class sip bind control source-interface Loopback2

voice-class sip bind media source-interface Loopback2

!

Dial-peer voice 2 voip

incoming uri from 1

voice-class sip bind control source-interface Loopback2

voice-class sip bind media source-interface Loopback2

!

However this doesn't seem to be working as the CUBE is still replying via the physical IP.

And then I tried with Host ipv4: and pattern IP as below:

!

voice class uri 1 sip

pattern [SP_IP]

!

and also

!

voice class uri 1 sip

host ipv4:[SP_IP]

!

Dial-peer voice 1 voip

incoming uri from 1

voice-class sip bind control source-interface Loopback2

voice-class sip bind media source-interface Loopback2

!

Dial-peer voice 2 voip

incoming uri from 1

voice-class sip bind control source-interface Loopback2

voice-class sip bind media source-interface Loopback2

!

With Host or Pattern IP, the response to options ping is responding back via the Loopback 2 IP which is the correct SP facing IP, however the call for incoming dial-peer 2 fails as it tries to use the dial-peer 1 even the incoming pattern matches to dial-peer 2.

Any suggestions would be very helpful.

[Jonathan Schulenberg]

I have read your post several times and can’t decipher what you’re actually trying to accomplish here. For starters, I see no difference between dial-peers 1 and 2 in the OP; of course IOS will match the first one.

Also, I don’t understand why you’re not using the IP address of the physical interface facing the service provider.

[gurungs]

Hi Jonathan,

Thanks your your response.

The scenario is that we have 2 different service providers sending calls to our SBC CUBE, hence we've got each service provider as e.g. Loopback 5 and Loopback 6.

So for from Service Provider 1 we have multiple DDI ranges as coming in so we need to have different dial-peers for different DDI ranges from this Service Provide 1. For e.g ddi 0551111.... on dial-peer 1 and 0552222... on dial-peer 2.

However if we use the SIP URI here then when the call comes is for DDI 055222... it doesn't match against the DDI and goes with the first URI which is going to be dial-peer 1 but the incoming number won't match so the call fails here.

Also the reason we have to use SIP URI is to response the Options Ping back to the service provider with the specified loopback IP as if they receive the keep-alive response from a different IP then it will be blocked.

So what I'm trying to achieve here is for Service provider 1, to make sure the keep-alive response goes back via the specified IP and then incoming calls can got to multiple dial-peers based on the incoming number even they have the same URI on the dial-peer. 

Hope this makes sense.

Thanks,

Sajan

[Jonathan Schulenberg]

You can't have multiple incoming dial-peer match criteria for the same call leg. There is a priority and the first match will be chosen. It may be worth watching the recording of this Cisco Live presentation, especially the section on CUBE Dial-Peers Call Routing starting at slide 58:
https://ciscolive.cisco.com/on-demand-library/?search=border%20element%20call%20routing#/session/BRKCOL-2125

I use `incoming uri` as my standard config/approach - though I match the host portion of the VIA header instead of From - so this by itself won't make a call fail. Without seeing the full config and debugs of a call it's a little difficult to see what is off here. What else is different between DP1 and 2? What happens on DP2 that allows an outbound call leg to be successfully matched that doesn't happen on DP1?