Summary:	ASTERISK-06607: [patch] [post 1.4] Add option to support regexten addition and removal on qualify status
Reporter:	Bradley Watkins (marquis)	Labels:
Date Opened:	2006-03-23 17:33:43.000-0600	Date Closed:	2007-07-11 19:58:55
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) regextenonqualify.diff
Description:	This patch adds support for a global setting called regextenonqualify, which will add or remove an extension based on the reachable/unreachable status of a SIP peer. Patch is against Olle's test-this-branch r14568.
Comments:	By: Serge Vecher (serge-v) 2006-05-08 00:27:47 should this be also available for IAX an other channel drivers that support device state? By: Russell Bryant (russell) 2006-05-20 09:26:03 Perhaps it makes sense to add a new option for peers called "qualifyexten".  It's not really a "regexten" if it's not based on registrations.  That would also allow for more refined settings where you could use regexten for some peers and qualifyexten for others. An updated patch will need to be against the svn trunk, and not test-this-branch. Thanks By: Serge Vecher (serge-v) 2006-06-07 14:50:12 Marquis: need your response here. Thank you. By: Bradley Watkins (marquis) 2006-06-11 12:10:33 If it's preferred, I can update the patch to work in the way you describe.  This will be a different behavior than what the original patch offers, but in practice I believe that making both parameters equal will result in the functionality I originally desired. Let me know, and I will make the changes (and yes, to trunk and not test-this-branch, sorry). By: Serge Vecher (serge-v) 2006-06-11 12:36:37 Marquis: yes, please update the patch that implements russell's suggestions. Thanks By: Olle Johansson (oej) 2006-06-11 13:32:41 Would it be more clever to change to "dynexten = [qualify, register], extension@context" Is there a need for both at the same time for one peer? By: Russell Bryant (russell) 2006-06-11 16:32:33 I just didn't want this new behavior to be associated with "regexten" since I didn't feel that made much since.  Combining it into a single option works, too, I guess.  I just think the syntax for that looks a bit cryptic.  "regexten" and "qualifyexten" are a bit simpler, in my opinion. By: Olle Johansson (oej) 2006-07-03 09:52:04 Ok, let's go for "dynexten" then. Do not remove "regexten", it needs to have the old function for a release. By: Bradley Watkins (marquis) 2006-07-03 12:07:57 I saw a little action here, and I just wanted to update that I expect to be able to submit a new patch the week after next.  Sorry for the delays, but since this was obviously a post-1.4 feature I decided a few things had higher priority. I will make it dynexten as suggested by Olle and keep the old regexten behavior. One question that I had, though, is regarding the regcontext global setting.  Should I just duplicate it and go with dyncontext? By: Olle Johansson (oej) 2006-07-05 02:23:51 Moving this to post 1.4 By: jmls (jmls) 2006-10-31 12:56:12.000-0600 Marquis, any update ? Thanks. By: Olle Johansson (oej) 2006-11-12 14:35:05.000-0600 yeah, use the global regcontexts. Any time you are ready to produce a patch, I can include it in trunk. By: Serge Vecher (serge-v) 2007-01-09 13:14:52.000-0600 last call ... By: Russell Bryant (russell) 2007-01-09 21:58:02.000-0600 last call?  There is no reason to close this.  The patch here still has value, and someone will pick it up and make the necessary changes at some point. By: Serge Vecher (serge-v) 2007-01-10 09:13:32.000-0600 don't know how else to convey a sense of urgency ... By: Olle Johansson (oej) 2007-05-15 11:26:21 This has been on the queue for far too long. Will look into this next week. By: Olle Johansson (oej) 2007-05-16 02:36:39 I did update the patch for svn trunk and commit it in rev 64497 Thank you for your contribution. Sorry it took so long to handle it.