Calls not routing based on Dialing Plan

ajlindy · Brekeke Talented Joined: 12 Sep 2017 Posts: 53

1. Brekeke Product Name and Version: Brekeke Version 3.9.4.3, Advanced ID: 9100000319

2. Java version: (build 1.8.0_251-b08)

3. OS type and the version: Windows 2016

4. UA (phone), gateway or other hardware/software involved:

5. Your problem:

I have rules in place that should route a specific phone number to a specific place.

This rule is called Inbound and is listed first

Matching Patterns

$request = ^INVITE
To = sip:(25173)@
From = sip:(.+)@

Deploy Patterns

$b2bua = true
To = sip:%1@10.60.blah.blah:5060

The very next rule is called Cisco:

Matching Patterns

$request = ^INVITE
To = sip:(.....)@

Deploy Patterns

To = sip:%1@10.60.different.IP:5060

We have an agent calling from a Cisco system. Their extension if 51234 and they call 25173 and we see it hit Brekeke but it triggers on the Cisco rule, not the Inbound rule.

What have I done wrong? I am looking at a completely different Brekeke system we have set up that works properly with a set of rules that is almost identical.

Harold · Posted: Thu Jul 23, 2020 5:28 pm Post subject:

Check the Dial Plan History to see whether the To-URI indicates sip:25173@ and which rule is matched.

ajlindy · Brekeke Talented Joined: 12 Sep 2017 Posts: 53

The log has the following information:

From URI: 25098@ExternalCiscoIP
To URI: 25173@ExternalCiscoIP

Rule: Cisco

So the only reason the To URI has the same IP is because it hit the Cisco rule, which is listed lower in order than the Inbound Rule

We have a WireShark capture that shows

Request-Line: INVITE sip:25173@BrekekeSIPProxyIP:5060
So I know it gets there and obviously Brekeke deals with it, but using the wrong dialing plan rule.

We tried changing the Inbound Rule so the Matching Pattern was

To = sip:25173@ but that did not resolve the issue.
I have also gotten rid of the From = sip:(.+)@ because I don't think that's even necessary and it also did not help.

Thoughts?

ajlindy · Brekeke Talented Joined: 12 Sep 2017 Posts: 53

We now have the pattern matching on the rule.
I had $b2bua = true and removed it.
Once I removed it, it triggered properly.

Please do not close or ignore just yet though, because now I get a TCP Failure due to timeout.

ajlindy · Brekeke Talented Joined: 12 Sep 2017 Posts: 53

And.....that is also resolved!

Had to use $transport = UDP on the deploy pattern.

All is good!

Harold · Posted: Fri Jul 24, 2020 9:14 am Post subject:

It seems the INVITE was sent over TCP from the UAC but you want to convert it to UDP?

Do you push [Apply Rules] button each time after you edit DialPlan?

Were there any possibilities DialPlan make a looped call?
For example.. it sent an INVITE back to the SIP Server again and then it hit the "Cisco" rule.