cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
418
Views
0
Helpful
7
Replies
Highlighted
Rising star

Inbound SIP URI Dial Peer matching

All the CUCM servers from multiple clusters have IP addresses that start 10.22<something>.

 

Also have two dialers with very specific ip addresses.  

We have two dial peers that are using SIP URI matching on the from field.  The URIs are defined this way:

 

voice class uri FROMCUCM sip
host ^10.22

voice class uri FROMDIALER sip
host ipv4:10.222.0.133
host ipv4:10.222.0.5

 

I would expect that a longer match would take priority.  However, when the dialer is making its calls, all the calls are matching the first URI.

The documentation for CUBE doesn't indicate a preference order for choices between SIP URIs when all of them are the same type.  It specifies the order of preference only as via, request, to, from.

Withing a type, you can have the following:

  • host hostname-pattern
  • host ipv4: ipv4-address
  • host ipv6: ipv6-address
  • host dns: dns-address
  • pattern uri-pattern
  • user-id username-pattern

 

the only documented caveat I see is that only one user-id and host combination can appear in a single uri.  Up to 10 ipv4 addresses can appear in a URI class.

 

How is preference handled within this set? (i.e. why doesn't my more specific URI get matched shown at the top)?

Everyone's tags (1)
7 REPLIES 7
Highlighted

Re: Inbound SIP URI Dial Peer matching

Hello Clifford,

 

Could you please share dial peers configuration as well?

 

Kalliopi

Please Rate Posts (by clicking on Star) and/or Mark Solutions as Accepted, when applies
Highlighted
Rising star

Re: Inbound SIP URI Dial Peer matching

DIal peers shown below.  But the question is about precedence in SIP URI matching on dial peers within a type (i.e. TO, FROM, VIA, etc.).

 

voice class uri FROMDIALER sip
host ipv4:10.222.0.133
host ipv4:10.222.0.5

voice class uri FROMCUCM2CLOUD sip
host ^10.22

 

dial-peer voice 302 voip
incoming uri from FROMDIALER
destination dpg 1002
session protocol sipv2
voice-class codec 300
voice-class sip rel1xx supported "100rel"
voice-class sip early-offer forced
dtmf-relay rtp-nte
ip qos dscp cs3 signaling
no vad

dial-peer voice 321 voip
incoming uri from FROMCUCM2CLOUD
translation-profile incoming CUCM2CLOUD
session protocol sipv2
session target sip-server
destination dpg 1001
voice-class codec 300
voice-class sip rel1xx supported "100rel"
voice-class sip early-offer forced
dtmf-relay rtp-nte
ip qos dscp cs3 signaling
no vad

Highlighted
Enthusiast

Re: Inbound SIP URI Dial Peer matching

If i understand corectly you want to use single sip uri for all your dial-peers  Is it correct ?

Highlighted
Rising star

Re: Inbound SIP URI Dial Peer matching

No....what I want is to understand the preference order by which URI dial peers are selected based on their criteria.

Highlighted
VIP Mentor

Re: Inbound SIP URI Dial Peer matching

Highlighted
Rising star

Re: Inbound SIP URI Dial Peer matching

Not really.



The problem is not the order of preference of dial peer types. The problem is the order of preference WITHIN a dial peer type (specifically URI).



For example,



Based on testing so far, I've been able to determine the following:



voice class uri URI1 sip

host ^10.1



voice class uri URI2 sip

host ipv4:10.100.3.4



Based on my testing using the above, if there are two dial peers present, and both are using the same URI FROM setup on a dial peer, the second dial peer (using URI2) will NEVER be matched.



This kind of goes counter (in at least my mind) to the longest match rule we normally apply. It would appear that if there is a partial or wildcard match involved, that we are going with the very first match we can get, and then ignoring everything else. This is a bit disconcerting, as it now brings other factors into play that would also be potentially problematic (i.e. which one got put into the configuration first, are they processed in alphabetical order, something else, etc.).








Highlighted
Enthusiast

Re: Inbound SIP URI Dial Peer matching

Hi

 

I thing probably sip uri regex alghorithm has some difference than expected regex.

 

Can you try that.

 

Some charecters is not accepted as we expected other regex application like voice transnlation rule I was face smilar case before.

 

 

HEre you cans ee two smilar example but that first URI (USER) is never matching anymore.

It looks same but normaly it wont match firts (USER) sip uri  so can you please use it without ^ characters

 

voice class uri USER sip

user-id 7[34]..$

 

voice class uri PATTERN sip

pattern 7[34](.*)

 

 

voice class uri 203 sip
host dns:xxx.yyy.com
host dns:abc.def.com
host ipv4:10.10.10.10
host ipv4:10.9.10.11
host ipv4:10.10.10.10

dial-peer voice 103 voip
session protocol sipv2
incoming uri via 203

CreatePlease to create content
Content for Community-Ad
Future of Work Virtual Summit Day 5

Cisco COVID-19 Survey