Match CUBE inbound dial-peer by calling number

[Paul Reck]

Hi all,

I've been out of the Cisco collab world for a while and need some advice for a use case where we need to get a CUBE to distinguish between calls from two groups either on an inbound or outbound dial-peer by calling number.  

dial-peer voice 100 voip
description Inbound from Teams Group 1
rtp payload-type comfort-noise 13
session protocol sipv2
destination dpg 100
incoming calling e164-pattern-map 100
voice-class codec 1
voice-class sip tenant 1
voice-class sip options-keepalive profile 1
dtmf-relay rtp-nte
srtp
no vad

dial-peer voice 100 voip
description Inbound from Teams Group 2
rtp payload-type comfort-noise 13
session protocol sipv2
destination dpg 101
incoming calling e164-pattern-map 101
voice-class codec 1
voice-class sip tenant 1
voice-class sip options-keepalive profile 1
dtmf-relay rtp-nte
srtp
no vad

The config is accepted and the debugs show the calling number matching the e164 pattern map but the dial-peers do not match, and it ends up matching a destination-pattern .T dial peer.  I've tried this several things on the outbound and inbound dial-peers but the documentation I've read seems to suggest that matching on calling number may only be available on pots dial peers.  I was wondering if anyone has a solution for this particular requirement? And of course whether I've missed something simple.

If I can't get calling number to work I may have to look at setting a separate URI for the different Groups and configuring the Teams end to send to different trunks on the same CUBE and match on 'to uri', but I'd prefer to solve it with the calling number if possible.

Any pointers appreciated

Paul 

[Roger Kallberg · Accepted solution]

Matching on calling numbers works on voip dial peers as well. Are the dial peer(s) referenced by the DPG in an up/operational state? Could you please share your complete configuration and the output from these debugs running simultaneously, debug ccsip message, debug voip dialpeer and debug voip ccapi inout?

[Paul Reck]

Thanks for the response Roger, that's exactly what I needed to know.

It's a live customer, relatively complex, environment so I have only had limited access to make changes and test, but your response encouraged me to run up a lab environment to work out what was happening.  Turned out to be an 'incoming called-number .T' on another dial peer that took preference over the 'incoming calling e164-pattern-map' on the dial-peers in question.

The cisco documentation I've been looking at is a little vague on where in the order it sits when that matching command is used for SIP call legs

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/cube-dp.html

• voice class uri URI-class-identifier with incoming uri {via} URI-class-identifier
• voice class uri URI-class-identifier with incoming uri {request} URI-class-identifier
• voice class uri URI-class-identifier with incoming uri {to} URI-class-identifier
• voice class uri URI-class-identifier with incoming uri {from} URI-class-identifier
• incoming called-number DNIS-string
• answer-address ANI-string

Anyway, I think I have a solution for the problem now, so thanks again

Paul

[Roger Kallberg]

I would reference you to this document. Explain Cisco IOS and IOS XE Call Routing