2.8.0beta2.4 - Trunks - Dialed Number Manipulation Rules

Beta Program Issues
#1

When a pattern is matched in an outbound route and sent to the trunk freepbx is not properly honoring my dialing rules.

Example: end user dials a 10 digit US number i.e. 404-555-1212
In trunks I have a rule to prepend 1 + NXXNXXXXXX
result: number is sent to trunk as dialed

-- Executing GotoIf("SIP/pbx.aretta.net-081febc0", "0?match") in new stack
-- Executing ExecIf("SIP/pbx.aretta.net-081febc0", "0|Return|") in new stack
-- Executing ExecIf("SIP/pbx.aretta.net-081febc0", "0|Return|") in new stack
-- Executing Return("SIP/pbx.aretta.net-081febc0", "") in new stack
-- Executing Set("SIP/pbx.aretta.net-081febc0", "OUTNUM=4044782200") in new stack
-- Executing Set("SIP/pbx.aretta.net-081febc0", "custom=SIP/arettasip") in new stack
-- Executing ExecIf("SIP/pbx.aretta.net-081febc0", "0|Set|DIAL_TRUNK_OPTIONS=M(setmusic^default)") in new stack
-- Executing Macro("SIP/pbx.aretta.net-081febc0", "dialout-trunk-predial-hook|") in new stack
-- Executing MacroExit("SIP/pbx.aretta.net-081febc0", "") in new stack
-- Executing GotoIf("SIP/pbx.aretta.net-081febc0", "0?bypass|1") in new stack
-- Executing GotoIf("SIP/pbx.aretta.net-081febc0", "0?customtrunk") in new stack
-- Executing Dial("SIP/pbx.aretta.net-081febc0", "SIP/arettasip/4044782200|300|") in new stack
-- Called arettasip/4044782200
-- SIP/arettasip-081f2028 is circuit-busy

In the above snippet the correct behavior would dial 1 + number. This call is failing since the proxy is expecting 11 digits.

Right now the end user is dialing 11 digits as a work around but they want the ability to do 10 and 7 digit dialing. Anyone else experiencing this with beta 2.4?

Thanks

#2

There’s not enough information in that trace to see:

  1. If they have configured the trunk rules correctly
  2. What the dialplan is seeing wrt to manipulation rules and thus why it might be failing
#3

This was an upgrade from a working 2.7.0.2 install so nothing was touched/changed between outbound routes pattern matching and trunking dialing rules. I’ll get a pastebin of the conf files posted as soon as possible along with a dump of the Asterisk CLI as the call is being processed.

Thanks

#4

Looks like things are done quite a bit differently in 2.8

It appears that the prepending needs to happen in outbound routes now instead of in trunks. One of my guys solved the issue. Thanks!

#5

That is not the case.

Outbound Routes have added the ability to prepend which was not previously an option. This provides new capabilities that couldn’t previously be done. But the ability at the trunk level has not gone away.

It is also more efficient to prepend in the Outbound Route vs. the trunk though there are times this is not an option. (e.g. you may have two trunks that require different formats and are both in the same route, in which case your manipulation needs to be done at the trunk level and not the route level).

However, you should be able to prepend in the trunk, and the migration should pull forward the previous settings. It would be (or would have been) very helpful to see what was going on with the system in question to determine why it broke as it is very possibly a bug in the migration code or elsewhere that has not yet been detected.

So … if you can still reproduce the scenario where you believe the trunk pattern manipulation rules are correct but are not being executed properly, it would be greatly appreciated to see the data presented here so we can determine if it is a bug or not. This is one of the “sensitive” parts of the system that changed in 2.8. The trunk level manipulation used to be done in an AGI script and is now done in dialplan for better efficiency. So it’s important to track if there are bugs that have not yet been detected.

#6

Not a problem. I’m going to spin up a demo system that starts in 2.7.0.2 and upgrade it. I can give you access to this machine if you’d like (SSH, web). Let me know if you want it, otherwise I’ll get the info I mentioned earlier (screenshots and CLI dump).

#7

If you can simply reproduce the issue, that would be greatly helpful as it will help to isolate if this is the migration process or the current code.

If I need access we can let you know.

Thanks.

#8

CLI output: http://pastebin.com/WYitTEX0

#9

It looks like it’s trying to do something.

This is where it should be call the subroutine: sub-flp-1 to make any needed changes:

    -- Executing [[email protected]:12] GosubIf("SIP/100-280037a0", "1?sub-flp-1|s|1") in new stack
    -- Executing [[email protected]:1] ExecIf("SIP/100-280037a0", "1|Return|") in new stack

So can you paste in two things:

  • The configuration for the trunk dialpatterns
  • The generated code in extensions_additional.conf for su-flp-1

Lastly, if you have it, you can also provide what was in the textbox before the migration or the old /etc/asterisk/localprefixe.cnf file which would have what was last configured before the migration (the file is no longer used).

Those will help to determine if either the migration went south or the code being generated is not functioning properly.

#10

Trunk dialpattern @ https://npx1601690.aretta.net/Trunk_Screenshot.png
Generated code for extensions_additional.conf:


[sub-flp-1]
include => sub-flp-1-custom
exten => s,1,ExecIf($[${REGEX("^[2-9][0-9][0-9][2-9][0-9][0-9][0-9][0-9][0-9][0-9]$" ${DIAL_NUMBER})} = 1],Set,TARGET_FLP41=1${DIAL_NUMBER})
exten => s,n,GotoIf($[${LEN(${TARGET_FLP41})} != 0]?match)
exten => s,n,ExecIf($[${REGEX("^1[2-9][0-9][0-9][2-9][0-9][0-9][0-9][0-9][0-9][0-9]$" ${DIAL_NUMBER})} = 1],Return,)
exten => s,n,Return()
exten => s,n(match),Set(DIAL_NUMBER=${TARGET_FLP41})
exten => s,n,Return()

; end of [sub-flp-1]

The file localprefixes.conf was empty.

#11

ancosgrove,

the subroutine above and the trace don’t match.

Your trace has:

    -- Executing [[email protected]:1] ExecIf("SIP/100-280037a0", "1|Return|") in new stack

Which would imply that the first ExecIf() command to execute is a Return() yet if you look at what the first priority is, it is:

exten => s,1,ExecIf($[${REGEX("^[2-9][0-9][0-9][2-9][0-9][0-9][0-9][0-9][0-9][0-9]$" ${DIAL_NUMBER})} = 1],Set,TARGET_FLP41=1${DIAL_NUMBER})

which would have resulted in the log message showing the Set command and not Return???

What it looks like to me is that your second rule may have been first or may have been the only one, because the executed instruction is exactly what the 3rd priority would have looked like, other than it would have been third not 1st. (And note - that instruction is not necessary at all to be in there).

#12

Next steps?

#13

Next steps would be to see a trace execution that matches what is in the dialplan.

As mentioned, your trace is not what you printed above so it’s all fairly inconclusive.

If what you have above is consistent with what should have been migrated then the migration worked because the subroutine looks consistent.

You need to run another trace that shows the above subroutine running to determine if it is running properly or not. (And it does look correct).

#14

Hmmm… can’t seem to reproduce it anymore. I’ll keep playing with it and send along the trace if I come across it again.

#15