[Home]

Summary:ASTERISK-22345: Realtime dialplan extension matching fails when extension includes "/" character
Reporter:Philip Mullis (philipmullis)Labels:
Date Opened:2013-08-20 08:57:42Date Closed:2013-10-18 15:23:58
Priority:MajorRegression?
Status:Closed/CompleteComponents:PBX/pbx_realtime
Versions:11.3.0 Frequency of
Occurrence
Related
Issues:
Environment:Tested multiple versions of asterisk 10 thru 11 on ubuntu/centos linux and freebsdAttachments:
Description:Description : Asterisk not matching any extension logic with / present ie.. number/callerid.

Versions tested : Asterisk Version 11.4.0 (tested from 10.3 and up issue prevalent in all version, most likely in trunk too)

{noformat}
SQL DATA test realtime data

Full Texts id context exten priority app appdata comment
from-test 1234 1 NoOp Test ${CALLERID(num)}
from-test 1234567890/1111 1 NoOp Helloooooooooooooooooooooooo
{noformat}

extensions.conf

{noformat}
[from-test]

switch => Realtime
;exten => 1234567890/1111,1,NoOp("GOT HERE") ; manual test passes
;confirmed ext 1234 works from realtime
{noformat}

error :

[2013-08-20 10:13:24] NOTICE[22970][C-00000009]: chan_sip.c:25288 handle_request_invite: Call from 'philtest' (10.0.0.100:63026) to extension '1234567890' rejected because extension not found in context 'from-test'.
Scheduling destruction of SIP dialog 'ZTViYjA5YzkxZjcyYWI2ODY3ZjhjMTYyMzUyYzFmNmU.' in 32000 ms (Method: INVITE)


*note the callerid of my test sip client is 1111, tested working with static entry for sanity.

Conclusion: flat file logic working (commented manual test abovc), realtime version failing, although we can see exten 1234 has no issue, only seems to be when / is in there.. could this be some missed escape matching in the c code somewhere?
Comments:By: Walter Doekes (wdoekes) 2013-08-20 09:18:13.938-0500

I'm betting this simply isn't implemented.

For realtime, a relatively expensive lookup has to be done. Implementing this feature means that most lookups (normal entries, without the callerid-extension) will get a second (first) lookup.

(a) find in realtime an entry with ${EXTEN}/${CALLERID(num)}
(b) find in realtime an entry with only ${EXTEN}


By: Philip Mullis (philipmullis) 2013-08-20 09:22:48.983-0500

Realtime currently has a switch to not match patterns, surley this could be added and for those with the requirement for the less expensive lookup hits just use the additional switch to turn of pattern matching?

This could be a trivial patch?
By: Michael L. Young (elguero) 2013-08-20 10:18:08.463-0500

Philip,

This doesn't appear to be a bug.  Like Walter said, it hasn't been implemented yet.  The documentation states that callerid fields are not supported in realtime.

{quote}
/* Realtime switch looks up extensions in the supplied realtime table.

       [context@][realtimetable][/options]

       If the realtimetable is omitted it is assumed to be "extensions".  If no context is
       specified the context is assumed to be whatever is the container.

       The realtime table should have entries for context,exten,priority,app,args

       The realtime table currently does not support callerid fields.

*/
{quote}

If you would like to supply a patch to add this feature, it will be considered for addition to Asterisk.  Otherwise, without a patch we will have to close this issue out since we do not accept feature requests through the issue tracker.

Thanks
By: Philip Mullis (philipmullis) 2013-08-20 10:47:06.271-0500

Thank you I will look at making and benching a patch, if anyone else wishes to aid the more the merrier.

By: Rusty Newton (rnewton) 2013-09-04 19:06:30.087-0500

I'll keep this in Waiting on Feedback for a while to give you time to look at making a patch.  Thanks!
By: Rusty Newton (rnewton) 2013-10-18 15:23:58.425-0500

Philip, when you have a patch, you can post on here, or ping a bug marshal in #asterisk-bugs and we'll re-open the issue.