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:[EMAIL PROTECTED] +972-50-7952406 mailto:[EMAIL PROTECTED] http://www.xorcom.com iax:[EMAIL PROTECTED]/tzafrir _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
