Routing of calls

Class Of Service, looks like this:

billede

Try with a “Route Selection” on COS and define your Trunks.
How do you know its going the wrong trunk?
Did you read the siptrace yet with asterisk -r -vvvvvvvvvv ?
Might share it here via pastebin.

I can see from my voipmonitor that is using the wrong trunk,
I have not yet looked at the siptrace, as I could wrong trunk is being used

I have tried with “route selection” on COS - still the same issue.
it do not respect the prefix, and uses the route where no prefix is required

That was why, I was asking - there must be some way to prioritize the different routes, to different trunks

We have this working exactly as it should many times before. Share siptrace via pastebin. And explain callflow from start to finish.

Priority is like this: the more exact it matches it will use that outbound route.

The callflow is very simply:

Extensions will call what ever number they like, and the call is routed via our main trunk.

if a number is prefixed with 99 it should use a specific trunk

And why should I do that?
Because, mobile numbers (mobile numbers using our RI/CI must be routed via the correct SIP trunk, to our MVNO core, to be terminated in the mobile network.

I noticed you wrote “Priority is like this: the more exact it matches it will use that outbound route.”
That is a bit concerning, if that is the case, as

A catchall routing will catch all, no matter if you have other routes with prefix

So in my case, no matter what I do, since we have a route where you can “dial as you please” and a route that needs prefix 99 - and, as I understand, there is no option to prioritize, it will never work, without also giving the “catchall route” a prefix, which is not an option (e.g. press 0 for outbound linie) -

So if you have 4 different trunks (e.g. 4 different providers)
e.g.
Prefix 77, 88 and 99 and a trunk were no prefix is needed.- it will never work, if you have trunk were no prefix is needed, as you can not prioritize the routes,

Please do what I ask for or i can not help you.
The problem will be easy but it seems hard to find without a siptrace.
And what version of vitalpbx are you on? You applied changes I guess and tried a reboot of VitalPBX as well?

Did you check both trunks are 100% working? You called out on both of them already via VitalPBX?

My apologies, I did not see your siptrace message.
I just look over the menu for a sip trace, can you point me to the location.

We are running
VitalPBX 3.1.1-1
Asterisk 18.5.1-1

Both trunks are working perfect.
Changes have been applied - reboot have been tried aswell

It will work since you use
77 X. TunkA
88 X. TrunkB

So if you dial 7712345 it will go via Trunk A
If you dial 8812345 it will go Trunk B

You sure have some rules for mobile numbers in your country. You can use those as patterns as well. No need for prefix then.

  1. There are no rules for mobiles,

  2. It is only mobile numbers using our Ri/CI that should be routed that way (we are a mobile operator)

  3. I do not use
    77 X. TunkA
    88 X. TrunkB

I use
X. Trunk A
99 X. Trunk for mobile

This would still work. We use it that way as well.

Siptrace:
SSH (Putty) into Vitalpbx. Default Port 22.
Type a and hit Enter or
asterisk -r -vvvvvvvvv and hit Enter
ctrl + C to stop again

Then do your 2 scenarios:

  • 12345678
  • 9912345678

Copy trace to pastebin and share it here. Make sure to change sensitive data a little.

@Mads_Mortensen
Seems to be a Bug once you change the prefixes/patterns! I just checked again for you.
@miguel

Delete both Outbound Routes and create again! Should work then. Do not change. Create new.

Problem/to replicate:
Create 2 Outbound Routes
One for Trunk A other for Trunk B
Trunk A Prefix 99 Pattern X.
Trunk B no Prefix Pattern X.
Save and test. Works
If you then change Prefix 99 to 88 and save it will stop working. Will go the wrong Trunk.
So editing Outbound Routes causes issues.

I use
X. Trunk A
99 X. Trunk for mobile

Unless you specify in your class of service the second outbound to be used first, your Trunk A pattern basically catches all numbers dialed with the pattern you have

X = 0-9
. = One or more characters

MATCHES TRUNK A when trying to dial via Trunk B

99 123456
99 234
99 1923457668
99 992344555

If you specify a number length in your patterns, lets say the default US 10 digit length on both outbound routes, the system will be able to match with your trunk B as it will contain 12 digits, with two extra digits being your prefix

So either specify the secound outbound route to be checked first in a class of service or change your pattern matching.

1 Like

thank you for your input - however - the case remains the same

ALL calls with a certain prefix, must be routed via a specific trunk.
All other calls must be routed via a other trunk

Lenght, “number prefix” etc. is not useable. Route must be based on a specfic prefix.

No matter how this is done, setup, class of service, outbound routing etc. it will not work.

Hey Mads,

The problem is, that your other route’s dial pattern allows calls with prefix as well.

I’ll give you an example, in the states, most outbound routes will look like this

|Prepend |Prefix  |Pattern|
|               1| |  NXXNXXXXXX|
|        1519| |          NXXXXXX|
|                 | |1NXXNXXXXXX|

So, if you want a route that only works with a prefix, you’d have it like this:

|Prepend|Prefix|Pattern              |
|1             |     74|  NXXNXXXXXX|
|1519      |     74|          NXXXXXX|
|               |     74|1NXXNXXXXXX|

Resulting that you can only pass this route if you use the prefix

@Mads_Mortensen
Did you try that? Was working fine for me.

Thank you very much
Was a bug
Works perfect now

@PitzKey got me thinking:
Route Selection inside Class Of Serice should help with this issue:
Use Outbound Route with 99 X. first
X. second
on Route Selection.

And sure: X. is not very specific. Better use more precise patterns.

Mentioned here.

The correct way of doing outbound routing is by matching the full pattern. Avoid as much as possible to use the period.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.