[asterisk-dev] Clearing pick-up groups on Zap/ channels

[Tzafrir Cohen]

On Tue, Nov 07, 2006 at 09:17:18AM +1300, Nic Bellamy wrote:
> Olle E Johansson wrote:
> 
> >
> >5 nov 2006 kl. 16.43 skrev Gil Kloepfer:
> >
> >>I've discovered that in configuration files such as the one for
> >>chan_zap (where all the options "cascade down" rather than being
> >>specific for each category, there is no way to indicate that
> >>channels have no pick-up group after the first group has been
> >>set.  For example (simplified), in zapata.conf:
> >>
> >>  [channels]
> >>  ; These two phones are in call group/pick-up group #1
> >>  callerid="Green Phone"<(256) 428-6121>
> >>  callgroup=1
> >>  pickupgroup=1
> >>  channel => 1
> >>  callerid="Black Phone"<(256) 428-6122>
> >>  channel => 2
> >>
> >>  ; These three channels should not be in ANY pick-up groups, but  there
> >>  ; is no way to clear the previous settings
> >>  callerid="CallerID Phone" <(256) 428-6123>
> >>  channel => 3
> >>  callerid="CallerID Phone" <(256) 704-4666>
> >>  channel => 4
> >>  callerid="CallerID Phone" <(630) 372-1564>
> >>  channel => 5
> >>
> >>In the case of channels 3, 4, and 5, there is no valid way to  "clear 
> >>out"
> >>the "current" callgroup / pickupgroup without encountering an error
> >>(you could say pickupgroup=none, but that actually throws an error
> >>from ast_get_group(), although it happens to work).
> >>
> >>I'd like to propose making a change to ast_get_group() to allow
> >>the option "none" that returns a ast_group_t containing no groups set,
> >>basically zero.  So you could say 'callgroup=none' for example.
> >>
> >>Note that callgroup=0 would not do what I am suggesting because 0 is
> >>a valid group number.  The group/callgroup/pickupgroup is actually a
> >>bit mask (bits numbered 0 to 63).
> >>
> >>If this seems reasonable, please indicate so and I will submit a patch
> >>for both 1.2 and -trunk (they are essentially the same patch).
> >
> >Sounds very reasonable. Whether we can see this as a bug or a new
> >feature is up to Russell to decide. If it's a bug fix, which I think,  
> >we need
> >patches for the 1.2 and 1.4 branches plus trunk. Please open an issue
> >in the bug tracker, upload patches and we'll discuss there.

Actually, the format there is fine: just set:

  callgroup=

Sadly, parsing this will not yield the expected result. Seems to be that
ast_set_group does not know how to parse an empty string correctly.

> 
> I've been trying to think of an easy, minimal-change way out of the 
> zapata.conf inheritence problem (since it's not just pickupgroups that 
> have this behaviour, it's just worse with that since you can't reset it 
> at present).
> 
> What about something simple like a "resetdefaults" item that will 
> restore all zapata.conf settings to hardcoded defaults, and clear out 
> the pickupgroup/callgroup stuff?
> 
> Ie.
> 
>    pickupgroup=1
>    callgroup=1
>    channel => 1-3
> 
>    resetdefaults=yes ; likely need the =yes since it's key=value based
> 
>    otherconfig=123
>    channel => 4
> 
> This wouldn't break any existing configs out there, since it'd only 
> happen if you explicitly used resetdefaults.
> 
> Thoughts? Or shall I just whip up a patch? :-)

It should be rather trivial to reset almost anything once
http://bugs.digium.com/view.php?id=7877 is commited. The code would be
in the lines of:

  if (!strcasecmp(v->name, "resetconfig"))
  	chan_conf = zt_chan_conf_default();

However, suggestion like that make it obvious that the configuration of 
chan_zap needs revision. It is impossible to automatically edit that file 
because every change has side effects.

So there's now way you could "just add" a channel or a span.
genzaptelconf takes a very defensive approach and sets every value it
touches even if it is irrelevant, because you can't assume a sane
default.

-- 
               Tzafrir Cohen       
icq#16849755                    jabber:tzafrir at jabber.org
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com       
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir