Summary:	ASTERISK-12979: stdexten no longer logs incoming dialled digits in CDR
Reporter:	David Woolley (davidw)	Labels:
Date Opened:	2008-10-29 10:56:04	Date Closed:	2008-11-19 11:35:11.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	PBX/pbx_ael
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	This is really about the deprecation of Macro(), but stdexten provides a good example of the failure that results from trying to replicate Macro with Gosub. Just adding: exten => _X.,1,Gosub(stdexten,s,1(${EXTEN},SIP/${EXTEN}) to the sample extensions.conf and dialling 6106 produced the following CDR: "","6906","s","stdexten","""XXXXXXXXXXXX 6906"" <6906>","SIP/192.168.10.10-0939dec8","SIP/6106-093925e8","Dial","SIP/6106,20","2008-10-29 14:54:52","2008-10-29 14:54:54","2008-10-29 14:54:55",3,1,"ANSWERED","DOCUMENTATION","1225292092.19"," " Historically, "s" would have been "6106" and "stdexten" would have been "default", which I believe are much more useful. ****** ADDITIONAL INFORMATION ****** Macro still provides the old style CDR information, and I may be forced to re-deprecate our dialplan, to ensure that we get useful CDRs.  I am somewhat concerned though, because we were calling a Macro, that fits in the same place as stdexten, from a Gosub, as well as directly from the channel.
Comments:	By: Tilghman Lesher (tilghman) 2008-10-29 11:58:54 There's no reason you need to be using "s" as the extension within the Gosub.  Sure, that was required for Macro, but no such limitation exists in Gosub routines.  You could just as easily make the extension within the Gosub routine be "_X.". By: Tilghman Lesher (tilghman) 2008-10-29 12:00:09 (and thus you wouldn't need to pass ${EXTEN} as a separate extension).  Just Gosub(stdexten,${EXTEN},1(args)) By: David Woolley (davidw) 2008-10-29 12:47:49 I did think about that, but the two problems I had were: 1) you still don't get the original context logged; 2) you limit the character set for extensions and, with   that pattern, require at least two digit numbers.  The   use of _. is discouraged; we did try, elsewhere, and were   caught out. Both are surmountable, but there is a strong temptation to roll back to the 1.4 version of the dialplan. For (1) you can have a separate Gosub context for each significant context (e.g. tenant in a multi-tenanted system).  For (2) there will almost certainly be a pattern that will match everything that will be thrown at it on a particualar site. By: Tilghman Lesher (tilghman) 2008-10-29 13:06:06 For that matter, you don't even need a separate context for Gosubs.  Just create a context like: [stdexten] exten => _X.,50000(stdexten),NoOp(whatever you want) and include that context from everywhere.  Then you just need a Gosub(stdexten(args)). By: Tilghman Lesher (tilghman) 2008-10-29 13:07:56 In terms of the extension, if you really need everything to match, then something along the lines of "_[A-Za-z0-9*#]!" would work. By: Chris Walton (crjw) 2008-10-29 21:46:46 I happen to be using AEL which converts "macro" calls to "gosub" calls. For each macro, AEL creates a dedicated context with one extension named "s". Since I use an AEL "stdexten" macro in the dialplan, all my CDRs end up containing "stdexten" and "s" instead of the original context and the dialed extension. Note: the variables ${CDR(dcontext)} and ${CDR(dst)}, when referenced in the AEL macro, show the original context and the dialed extension. I discovered this by adding two lines to the begining of my stdexten AEL macro:    NoOp(${CDR(dst)});    NoOp(${CDR(dcontext)}); The fact that these CDR variables don't reflect what is being logged in the CDR should be treated as a bug. For those not using AEL, the bug can be seen with the following dialplan in extension.conf: [junk] exten => 750,1,GoSub(subroutines,stdexten,1(SIP/750)) [subroutines] exten => stdexten,1,NoOp(${CDR(dst)}) exten => stdexten,n,NoOp(${CDR(dcontext)}) exten => stdexten,n,Dial(${ARG1}) exten => stdexten,n,Return ;;;; compare the output from the "NoOp" operations with the entries logged in the CDR; you will find they are not the same. If anybody wishes to tackle this bug, I would prefer to see the CDR fixed to match the variables instead of the variables fixed to match the CDR! And if anybody asks, I am using 1.6.0.1 on top of Solaris. By: Tilghman Lesher (tilghman) 2008-10-29 22:54:45 crjw:  in that case, it's a bug with AEL.  You can do many things that aren't advisable in the dialplan.  Just because you can, doesn't mean you should.  The examples I've provided above make it perfectly clear that you can create the necessary dialplans to get the intended CDR values. By: Digium Subversion (svnbot) 2008-10-29 23:15:47 Repository: asterisk Revision: 152765 U   trunk/configs/extensions.conf.sample ------------------------------------------------------------------------ r152765 | tilghman | 2008-10-29 23:15:47 -0500 (Wed, 29 Oct 2008) | 5 lines Set up an example stdexten that preserves the original context and extension in the CDR. (Related to issue ASTERISK-12979) Reported by: davidw ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=152765 By: David Woolley (davidw) 2008-10-30 07:05:40 > In terms of the extension, if you really need everything to match, > then something along the lines of "_[A-Za-z0-9*#]!" would work. Doesn't that have the same problem as "_.", namely it matches s, h, i, etc. By: Tilghman Lesher (tilghman) 2008-10-30 10:44:55 davidw: only if you have a priority 1.  Note that I explicitly suggested using priority 50000 and above, and since you don't have a priority 1 which references it, nothing happens. By: Tilghman Lesher (tilghman) 2008-11-19 11:35:11.000-0600 Closing; the examples have been updated, but there is no code change necessary.