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.

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.

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 [s@macro-dialout-trunk:12] GosubIf("SIP/100-280037a0", "1?sub-flp-1|s|1") in new stack
    -- Executing [s@sub-flp-1: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.

ancosgrove,

the subroutine above and the trace don't match.

Your trace has:

    -- Executing [s@sub-flp-1: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).

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).