Summary:ASTERISK-11523: Dial plan pattern matching not working from odbc tables
Reporter:Kamil Czajko (kactus)Labels:
Date Opened:2008-02-26 22:44:51.000-0600Date Closed:2011-06-07 14:03:12
Versions:Frequency of
Description:It appears that pattern matching has either changed or is broken from 1.4 when reading dial information out of the database.

when using the flat files, ie extensions.conf,

;switch => Realtime/from-sip3@extensions
exten => _XXX,1,Dial(SIP/DestinationAccount)

this matches all 3 digit numbers such as 141 etc correctly.

when using

switch => Realtime/from-sip3@extensions
;exten => _XXX,1,Dial(SIP/DestinationAccount)

with the database looking like:
context     exten         priority        app         appdata
from-sip3   _XXX          1               Dial        SIP/DestinationAccount

the system throws a notice of:

[Feb 27 22:31:31] NOTICE[25133]: chan_sip.c:16314 handle_request_invite: Call from 'OriginalDialingAccount' to extension '141' rejected because extension not found.

and is unable to continue. Changing exten to 141 in the extensions database table allows the call to proceed normally.

Please investigate
Comments:By: Kamil Czajko (kactus) 2008-02-26 23:40:31.000-0600

Just some additional information from testing, it also does not match the period wildcard '.'

ie _. or _X. do not get matched

By: Tilghman Lesher (tilghman) 2008-02-27 09:21:57.000-0600

What database backend are you using?

By: Kamil Czajko (kactus) 2008-02-27 17:32:57.000-0600

Hi we are using odbc with a freetds driver talking back to a microsoft SQL 2005 server standard.

By: Kamil Czajko (kactus) 2008-02-27 17:35:02.000-0600

Also should note that the odbc connecter is unixodbc 2.2.11 (have tried on second box with 2.2.12 as well) and freetds version is 0.64

By: Tilghman Lesher (tilghman) 2008-02-27 17:48:25.000-0600

Do you have "backslash_is_escape => no" in your res_odbc.conf?

By: Kamil Czajko (kactus) 2008-02-27 19:23:44.000-0600


backslash_is_escape => no

was missing. Have now tested on both freebsd(beta4) and centos(latest svn) and can confirm that it is working correctly on both.

Please close this case, sorry for the mixup.