[asterisk-bugs] [Asterisk 0019111]: [regression] When using extenpatternmatchnew=yes, dialplan-based callerid fails using forward slash

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=19111 
====================================================================== 
Reported By:                amessina
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   19111
Category:                   PBX/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.8.3.2 
JIRA:                       SWP-3441 
Regression:                 Yes 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2011-04-13 01:48 CDT
Last Modified:              2011-05-20 13:48 CDT
====================================================================== 
Summary:                    [regression] When using extenpatternmatchnew=yes,
dialplan-based callerid fails using forward slash
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
====================================================================== 

---------------------------------------------------------------------- 
 (0135206) jrose (manager) - 2011-05-20 13:48
 https://issues.asterisk.org/view.php?id=19111#c135206 
---------------------------------------------------------------------- 
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.

This could very easily be related to something I was just playing with
involving user options in the uri which prior to 1.8 would simply be
stripped via semicolon delimination.

You could also try the latest trunk build with the general sip option:
legacy_useroption_parsing=yes 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-05-20 13:48 jrose          Note Added: 0135206                          
======================================================================