Summary:	ASTERISK-04333: [patch] Improving the regexten functionality in SIP and IAX2
Reporter:	Luigi Rizzo (rizzo)	Labels:
Date Opened:	2005-06-03 10:38:57	Date Closed:	2011-06-07 14:02:53
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) regcommand.diff
Description:	if you specify 'regcontext' in sip.conf, asterisk registers new        $EXTEN,1,Noop(${EXTEN}) entries in the dialplan when a peer registers. The new 'regcommand' option for sip.conf implemented by this patch allows you to replace the Noop(${EXTEN}) with an arbitrary command. As an example, it is very convenient to have    regcommand = Dial(SIP/${EXTEN}) or    regcommand = Macro(new-peer,${EXTEN}) in sip.conf so that dialplan entries for peers that have successfully registered are handled without having to put explicit entries in the dialplan (the Noop per se would not be enough to make them reachable). Default behaviour is unchanged.
Comments:	By: Kevin P. Fleming (kpfleming) 2005-06-03 15:19:30 This is totally unnecessary. As I posted on asterisk-dev, you can already do exactly what you want: == sip.conf == [general] regcontext=sip_peers [peer1] type=peer regexten=3456 ... [peer2] type=peer regexten=4231 == extensions.conf == [sip_peers] exten => _XXXX,2,Macro(new-peer,${EXTEN}) This will do the exact same thing as your patch, without requiring any code changes. By: Luigi Rizzo (rizzo) 2005-06-03 15:43:04 kevin: i still believe my approach has the following pros: 1) easier to maintain:   a peer (or a set of peers) needs to be configured only with lines   in sip.conf, instead of requiring also one (or more, if peers have   odd extensions) pattern-matching rules in extension.conf 2) more readable:   if you lookup the dialplan, with my approach you immediately see the        '3456' =>   1. Dial(SIP/${EXTEN})            [SIP]   line instead of having to go hunt the continuation line        '3456' =>   1. Noop(${EXTEN})                [SIP]        .... potentially long list like this        '_XXXX' =>  2.  Dial(SIP/${EXTEN})           [pbx_config]   Not to mention that in presence of multiple patterns there is   often some ambiguity. 3) cheaper at runtime:   with my patch you only have to lookup a specific extension once   (which could be as cheap as a hash lookup), with your suggested   approach you have to do the first lookup for the nop, and then   a pattern lookup, which is always more expensive because you have   to scan the entire list (hopefully short, but you cannot tell...), On the cons side, yes you have to change the code, but the change is small and the code is there. Up to you guys, it's your baby... By: Kevin P. Fleming (kpfleming) 2005-06-03 15:59:37 But you are missing a major point: the code to be executed when calling out to these peers may be many, many lines of complex logic, and might very well be impossible (or at least difficult) to implement in a macro. The existing method lends itself very well to that sort of thing, since it just adds the 'starting' step to the existing code when the peer registers. Your 'regcommand' also cannot reference global variables from the dialplan, since those are parsed at loading time, although I'll grant that is a very minor point :-) As far as the dialplan execution goes, while that is a potential savings, it is very small (although all improvements are welcome). If this is going to go anywhere at all, I'd say it would have to be an extension to 'regexten' itself, that just allowed both the extension number and the command to be supplied, so that we didn't need yet another config option. We will also need to provide the same ability for chan_iax2, so that things will stay consistent. If you are willing to supply a patch which implements it that way, I think I can get it committed. The patch will also need to provide at least one example of the new usage in both sip.conf.sample and iax2.conf.sample. By: Olle Johansson (oej) 2005-06-04 06:59:49 I tend to agree with Kevin. Remember that this has to work for autocreatedpeers as well. And I don't like mixing extensions with peer/user names in configurations, but that's a personal opinion. By: Michael Jerris (mikej) 2005-06-23 15:54:25 Suspended due to no response in almost 3 weeks now.  If you intend on persuing this please reopen with a response. Thanks!