Strange dialplan behaviour

Hi guys!

got a SIP Trunk to which the context for incoming calls is “from-siptrunk”.

Testing a call to +351300999999, the call gets to Asterisk correctly, but then I get this reply:

[Oct 1 22:01:40] == Using SIP RTP CoS mark 5
[Oct 1 22:01:40] NOTICE[26933][C-00000117]: chan_sip.c:26457 handle_request_invite: Call from ‘siptrunk’ (10.XXX.XXX.XXX:5060) to extension ‘+351300999999’ rejected because extension not found in context ‘from-siptrunk’.

The dialplan does have the extension specified as I have a pattern. To check and debug the pattern and dialplan, I used the following CLI command:

asterisk*CLI> dialplan show +351300999999@from-siptrunk
[ Context ‘from-siptrunk’ created by ‘pbx_config’ ]
‘_+351300999999’ => 1. Answer() [pbx_config]
2. Echo() [pbx_config]

To the best of my knowledge, this means that the context has the extension specified and calls matching that extension pattern should be handled with these 2 lines, but still incoming calls to not get a match and the call fails!

Does anybody understand why? How can I solve this?

Using Asterisk 13.23.1 .

thanks in advance!

Does 'sudo asterisk -C <path-to-asterisk.conf> -x 'sip show peer siptrunk' | grep Context' show 'from-siptrunk'?

Hi sedwards,

Yes it does. In fact, many other patterns match correctly, in that specific context, for calls coming from siptrunk.
I know, this is weird…

BTW , from-siptrunk is the default context in sip.conf

What happens if you use it as static match, not as a pattern?
Like:

exten => +351300999999,1,Answer()
same => n,Echo()

it would be usefull to see all dialplan from-siptrunk , to see if there any other entries for more help
call comes to the 5060 port of asterisk, where chan_sip is listening - right?

This is the exact dialplan

[from-siptrunk]
exten => _+351300526[45]XX,1,Answer()
exten => _+351300526[45]XX,n,Echo()

exten => _+351300999999,1,Answer()
exten => _+351300999999,n,Echo()

exten => _+351[23]XXXXXXXX,1,NoOp()
exten => _+351[23]XXXXXXXX,n,Macro(callid-A)
exten => _+351[23]XXXXXXXX,n,Macro(trunk_multi_dial,1,SIP/{EXTEN},{PROVIDER1})

${PROVIDER1} is a global variable in the [globals] context.

According to Asteirsk docs, pattern matches the 1st occurrence in the dialplan or context. So, the call to +351300999999 should match with +351300999999 pattern.
Even if I remove the _+351[23]XXXXXXXX rules from context, the call pattern does not match.
I really can’t see where the issue is, to be honest.

I thought that Asterisk would match the most specific matching pattern, but if you have current dox that state otherwise, who am I to object :slight_smile:

I added plus, three, five, one, three, zero, zero, nine, nine, nine, nine, nine, nine as a contact in my desk set and changed it’s context to from-siptrunk and Asterisk 13.14.1~dfsg-2+deb9u4 executes it as expected:

  == Using SIP RTP CoS mark 5
       > 0x2364350 -- Strict RTP learning after remote address set to: 192.168.0.139:2262
    -- Executing [+351300999999@from-siptrunk:1] Answer("SIP/poly-77a1-000000b5", "") in new stack
       > 0x2364350 -- Strict RTP switching to RTP target address 192.168.0.139:2262 as source
    -- Executing [+351300999999@from-siptrunk:2] Echo("SIP/poly-77a1-000000b5", "") in new stack
       > 0x2364350 -- Strict RTP learning complete - Locking on source address 192.168.0.139:2262
  == Spawn extension (from-siptrunk, +351300999999, 2) exited non-zero on 'SIP/poly-77a1-000000b5'

so I’m at a bit of a loss of what to suggest.

Maybe logging everything in logger.conf:

        syslog.local0                   = *

and bumping up debug and verbose from the CLI will yield clues.

Also, maybe retyping the context and the pattern just to make sure some funky invisible character gremlin hasn’t crept in.

as you are not doing any pattern matching you should remove the “_” and do it this way

exten => +351300999999,1,Answer()
exten => +351300999999,n,Echo()

also can you do a "asterisk -rx “dialplan show from-siptrunk” and post it as it will show the matching order
asterisk will use the most specific matching pattern, so the order you write them in the config file do not matter

Just FYI, ‘-x’ implies ‘-r’