[Home]

Summary:ASTERISK-17685: [regression] When using extenpatternmatchnew=yes, dialplan-based callerid fails using forward slash
Reporter:Anthony Messina (amessina)Labels:
Date Opened:2011-04-13 01:48:00Date Closed:2012-03-23 14:23:50
Priority:MinorRegression?Yes
Status:Closed/CompleteComponents:PBX/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 0019111_sip_debug.txt
Description:[mss]
exten => 333/2201,1,SayDigits(${CALLERID(num)})

Phone dials 333...

NOTICE[23160]: chan_sip.c:21358 handle_request_invite: Call from 'sip1' to extension '*333' rejected because extension not found in context 'mss'.

This 'feature' worked previously in 1.6.2.17
Comments:By: Leif Madsen (lmadsen) 2011-04-13 09:00:59

When you say it worked in 1.6.2.17, did the forward slash callerid matching work in 1.6.2.17 with this feature enabled? It isn't clear if it is or not.
By: Anthony Messina (amessina) 2011-04-13 11:03:02

Sorry.  Yes, in 1.6.2.17, with extenpatternmatchnew=yes, the forward slash callerid matching worked properly.

In addition, subscriptions to dynamic hints are affected as well.  With the following:

; Toggle per-extension call recording
exten => *72,1,Goto(${EXTEN}${CALLERID(num)},1)
exten => _*7222XX,1,NoCDR()
same => n,Set(RECORD=${DB(RECORD/${CALLERID(num)})})
same => n,ExecIf($["${RECORD}" = "0"]?Set(DB(RECORD/${CALLERID(num)})=1):Set(DB(RECORD/${CALLERID(num)})=0))
same => n,ExecIf($["${RECORD}" = "0"]?Set(DEVICE_STATE(Custom:RECORD-${CALLERID(num)})=INUSE):Set(DEVICE_STATE(Custom:RECORD-${CALLERID(num)})=UNAVAILABLE))
same => n,ExecIf($["${RECORD}" = "0"]?Playback(dictate/record_mode&on&vm-goodbye):Playback(dictate/record_mode&ha/off&vm-goodbye))
same => n,Hangup()

Using extenpatternmatchnew=yes in 1.8.3.2, when a phone attempts to subscribe to the hint:
WARNING[8640] pbx.c: Unable to register extension '*722201', priority -1 in 'hints', already in use

Using extenpatternmatchnew=no in 1.8.3.2, the phone subscribes properly.

Using extenpatternmatchnew=yes (or no) in 1.6.2.17: the phone subscribes properly.
By: Jonathan Rose (jrose) 2011-05-20 13:48:56

Could you please show me what the SIP messages for this attempted call look like?

sip set debug on

make the call

And then just post the various sip messages related to it for me to have a look at.


By: Anthony Messina (amessina) 2011-05-24 16:18:29

SIP debug uploaded.
By: Jonathan Rose (jrose) 2011-09-27 14:12:36.187-0500

Hi, I tested this feature just now using 1.8 from the svn repo, and it appears to be working as you would expect it to.

exten => 21234/707,1,Answer()
exten => 21234/707,n,Saydigits(${CALLERID(num)})

Calling this number from a phone with a callerid num set to this 707 answers and repeats the number 707.  Calling from a phone with any other number fails.  So the callerid matching itself seems to be working fine.

Also, looking over this little bit... I see something that I don't think I should be seeing:
NOTICE[23160]: chan_sip.c:21358 handle_request_invite: Call from 'sip1' to extension '*333' rejected because extension not found in context 'mss'.

If there is a '*' at the beginning of the extension, you are getting an extra star in there before the rest of what you dial somehow.  That could be something phone related that might just have been ignored before or something.  There's no way *333 would ever match 333.

At the same time though, looking at your sip debug I saw one that looked pretty correct:

[May 24 16:14:14] NOTICE[18204]: chan_sip.c:21581 handle_request_invite: Call from 'sip1' to extension '333' rejected because extension not found in context 'mss-chicago'.
Scheduling destruction of SIP dialog 'b9f227c13acff83f35e71c0b2fde5abc@192.168.1.21' in 6400 ms (Method: INVITE)

These inconsistencies really bug me and lead me to believe that there are some critical pieces of data missing here.  If I'm going to continue on this one I need to see relavent sip.conf profiles, the section of the dialplan in use, and another log all pertaining to one test of your setup.
By: Matt Jordan (mjordan) 2012-03-23 14:23:41.005-0500

Thank you for the bug report. However I am unable to reproduce this issue. We are now going to close this report - please feel free to reopen when you have more information at hand.