Re: [asterisk-dev] Clearing pick-up groups on Zap/ channels
On Nov 8, 2006, at 9:44 AM, Kevin P. Fleming wrote: Tzafrir Cohen wrote: Note that I don't aim that high. I just aim at keeping this option open (let alone making 'reload chan_zap.so' work as defined). As the US Air Force recruitment ads say: AIM HIGH! Seriously... lots of people will be very happy if someone out there can find the time to re-do chan_zap's config system to make it compatible with the rest of Asterisk, compatible with Realtime (for those who want to use it) and easier to manage from automated maintenance tools like GUIs. It's on our internal list of projects, but it's there with 30+ other things that are probably going to happen first... Yeah, to be honest, I've been saving such major changes to config files and such for whenever I can start working on a new version of chan_zap that would replace it (or supersede it) for some configurations. There is a lot of reorganizational work that should be done, and personally I think we need to break the CCS signalling protocols (ISDN/SS7) out into another channel driver. There are things more important than the config file format that I would like to see change in chan_zap. Matthew Fredrickson ___ --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
Re: [asterisk-dev] Clearing pick-up groups on Zap/ channels
On Wed, Nov 08, 2006 at 09:44:54AM -0600, Kevin P. Fleming wrote: > Tzafrir Cohen wrote: > > Note that I don't aim that high. I just aim at keeping this option open > > (let alone making 'reload chan_zap.so' work as defined). > > As the US Air Force recruitment ads say: AIM HIGH! But first I'd like to fix bugs. The current implementation is buggy, and I have suggested a simple way to fix it. It has some other nice side effect for future modifications, but my short-term aim is simpler. The long-term goal and short-term goal are not exactly conflicting here. > > Seriously... lots of people will be very happy if someone out there can > find the time to re-do chan_zap's config system to make it compatible > with the rest of Asterisk, compatible with Realtime (for those who want > to use it) and easier to manage from automated maintenance tools like > GUIs. It's on our internal list of projects, but it's there with 30+ > other things that are probably going to happen first... Naturally... -- Tzafrir Cohen icq#16849755jabber:[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
Re: [asterisk-dev] Clearing pick-up groups on Zap/ channels
Tzafrir Cohen wrote: > Note that I don't aim that high. I just aim at keeping this option open > (let alone making 'reload chan_zap.so' work as defined). As the US Air Force recruitment ads say: AIM HIGH! Seriously... lots of people will be very happy if someone out there can find the time to re-do chan_zap's config system to make it compatible with the rest of Asterisk, compatible with Realtime (for those who want to use it) and easier to manage from automated maintenance tools like GUIs. It's on our internal list of projects, but it's there with 30+ other things that are probably going to happen first... ___ --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
Re: [asterisk-dev] Clearing pick-up groups on Zap/ channels
Why not allow group= or make group 0 mean "no group". What I do is set channels that I don't want in a group to be group 0 and never use g0 anywhere 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. 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? :-) Regards, Nic. ___ --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
Re: [asterisk-dev] Clearing pick-up groups on Zap/ channels
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#16849755jabber:[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
Re: [asterisk-dev] Clearing pick-up groups on Zap/ channels
On Monday, November 6, 2006, 15:17:18, Nic Bellamy wrote: > ... > 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 What about just setting it to an empty value? e.g. pickupgroup = -or- pickupgroup = "" (or some other empty value designation) That way you could reset just the ones you want to. -- [EMAIL PROTECTED] "The avalanche has already started, it is too Rod Dorman late for the pebbles to vote." - Ambassador Kosh ___ --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
Re: [asterisk-dev] Clearing pick-up groups on Zap/ channels
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. 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? :-) Regards, Nic. -- Nic Bellamy, Head Of Engineering, Vadacom Ltd - http://www.vadacom.co.nz/ ___ --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
Re: [asterisk-dev] Clearing pick-up groups on Zap/ channels
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. /O ___ --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
