Questions regarding dialplan

Asterisk Asterisk Support
1

Hello

Can someone explain to me why is Asterisk 11, act as it doesn.
I have two contexts for incoming calls, which look like this:

[general]
autofallthrough=no

[incoming]
exten => _30003038512345678,1,Goto(users,${EXTEN:6},1)
exten => _X.,n,Hangup

[users]
exten => 38512345678,1,Dial(SIP/5678)
exten => 38512345678,n,Hangup

Now even if the incoming number is only 38512345678, without the 300030 prefix, it still goes through, to the context users and what is even stranger it does not strip the first six digits.

Here is the debug from the asterisk console:

== Using SIP RTP CoS mark 5
[Sep 24 12:46:32] NOTICE[3057][C-00000004]: chan_sip.c:25381 handle_request_invite: Call from ‘BADBC61651673’ (10.160.4.7:5060) to extension ‘38512345678’ rejected because extension not found in context ‘incoming’.
== Using SIP RTP CoS mark 5
– Executing [30003038512345678@incoming:1] Goto(“SIP/test-00000006”, “users,38512345678,1”) in new stack
– Goto (users,38512345678,1)
– Executing [38512345678@users:1] Dial(“SIP/test-00000006”, “SIP/5678”) in new stack
== Using SIP RTP CoS mark 5
– Called SIP/5678
– SIP/5678-00000007 is ringing
== Spawn extension (users, 38512345678, 1) exited non-zero on ‘SIP/test-00000006’

Channel test in sip.conf is mapped to context incoming. Channel is a trunk with registration, so DID is supported.

Thank you on your answers

2

This definitly looks a bit strange. If I read the CLI output correctly, Asterisk denys the call (because it does not find any valid routes) and then goes on with executing a dialplan in a route that is a partial match.

Did you try changing your dialplan a bit:

[incoming]
exten => 30003038512345678,1,Goto(users,${EXTEN:6},1)
exten => _X.,n,Hangup
3

Sorry that was a typo, the original pattern was “_300030!” and that is the one I need to get working.
But when that one did not work I tried with a specific number just for the testing purposes.
I also tried “_300030X.” and “_300030XXXXXXXXXXX”, with the same results.
It all looks like a bug in asterisk, so I was asking here to see if someone has any thought on it, before I try to report a bug?

4

Show us the output of the cli command: dialplan show. Then make a call an paste the complete output without edition.

5

I really do not understand, I did post you unedited output, but here it goes again, also with the “dialplan show”

And the debug:

6

I also tried to remove all of the entries created by extensions.ael and features.conf, but the results are still the same.

7

i Think, Your interpretation of the process is quite incorrect:

The incoming call (to the non-existing extension 38512345678) gets rejected - that’s ok from Your configuration.
After the reject the calling party (10.160.4.7:5060) sends (whyever) a new INVITE, this time with 30003038512345678 which is matched in incoming and processed as defined in this context (strup first 6 digits and goto users …)

Thus the question should be: Why the originator sends a fiorst incorrect invite and after the rejection a correct one ?

You should - if possible - have a look at originator (10.160.4.7:5060) to see what happens or ask them, what they are doing when comunicating with Your box.

8

Sorry it looks like you are right, there is second invite, sorry on wasting your time.
I will investigate further.

9

Thank you all on all your help