Summary:	ASTERISK-03546: [PATCH] activate/deactivate dialplan contexts automatically
Reporter:	Kevin P. Fleming (kpfleming)	Labels:
Date Opened:	2005-02-19 03:01:39.000-0600	Date Closed:	2011-06-07 14:05:00
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) context_active_state_rev1.diff.txt ( 1) context_active_state_rev2.diff.txt
Description:	This patch adds the ability for channels (or other modules) to cause dialplan contexts to become "inactive" or "active" (default is active, of course). When a context is inactive, it will not respond to extension match requests, but is otherwise unchanged. The patch also modifies three channel drivers to use this new feature: - chan_sip and chan_iax2 get a new paramater for peers "qualifycontext", which contains a context name to be activated/deactivated based on the qualify status of the peer - chan_zap gets a new parameter for PRI spans "activecontext" which does the same based on the up/down status of the span This can be used in a number of ways, the most obvious are: - if you have a PRI span you use for outbound calls, and a context with all the extensions (number patterns) you will accept for that span, and you make that context available to other servers via DUNDi or a direct switch, this will stop the context from providing matches when the span is down, rather than accepting the match and failing to dial - if you have a SIP or IAX2 peer you use for services (LD termination, whatever), same process applies: if they are unreachable (determined via "qualify"), don't accept any matches for numbers you would send there, because the dial would fail anyway This allows quick alternate route selection (especially in the case of DUNDi). I have tested the changes to chan_sip and chan_iax2; I have not tested the changes to chan_zap because my test server does not have a PRI span attached to it :-( ****** ADDITIONAL INFORMATION ****** Disclaimer is on file.
Comments:	By: Kevin P. Fleming (kpfleming) 2005-02-19 03:10:46.000-0600 I'm already aware of a flaw in rev1 that I will fix tomorrow: the active/inactive state will not be preserved across an "extensions reload". By: Mark Spencer (markster) 2005-02-19 10:30:02.000-0600 We already have a regexten/regcontext in iax2 and sip... By: Kevin P. Fleming (kpfleming) 2005-02-19 11:10:05.000-0600 Which means you didn't read what this actually does... :-) Those are related to registration, and activate/deactivate a single extension within a context. This is not related to registration, but to connectivity, and activates/deactivates an entire context. By: Mark Spencer (markster) 2005-02-20 18:21:52.000-0600 Lets talk on IRC more about the similarities between the generalized goals of regexten/regcontext and this new activate/deactivate stuff.  Either way, it would probably make sense to try to find commonality to merge this stuff if at all possible, potentially even if it means breaking backwards compatibility on regexten (which is only in head afaik). By: Kevin P. Fleming (kpfleming) 2005-02-23 01:50:12.000-0600 rev2 uploaded with a few changes: - active/inactive state is now preserver across "extension reload" - multiple peers/spans can now activate/deactivate the same context; if any of them have deactivated, it's inactive... when the last one reactivates, it becomes active again I have not yet done anything to merge in the regcontext/regexten feature, but will do so in a day or two. As before, I have not tested the chan_zap portion of this patch, other than compiling it cleanly. By: Mark Spencer (markster) 2005-03-01 00:48:18.000-0600 Does it really make sense that anyone can deactivate it?  Would it not be more logical that if anyone has it activated then it's activated?  i.e. if I have four PRI's serving the same context, and one goes down, it should still be active because i have three others, no? By: Kevin P. Fleming (kpfleming) 2005-03-01 01:06:26.000-0600 Yes, that is a bug in the current implementation (it's backwards). I've been thinking about the proper way to fix it, haven't quite got it to where I'm happy that it will work well, so I suspect I'll be finishing it up this week (on my way to get San Jose, I'm sure <G>). By: Kevin P. Fleming (kpfleming) 2005-03-10 11:59:09.000-0600 I will revisit this issue when the new event system has been merged, since it will be a good base to build this functionality on top of.