Re: [asterisk-dev] devicestate

2008-01-16 Thread Atis Lezdins
On 1/16/08, Kevin P. Fleming [EMAIL PROTECTED] wrote: Clod Patry wrote: After a quick discussion with Russell on IRC, he told me the answers is pretty long why we can explicitly change a device state. So let's start a discussion around this :) There's no discussion to be had; you can't

Re: [asterisk-dev] devicestate

2008-01-16 Thread Leif Madsen
I agree for real devices. However i wonder - why i can't change state for Local channels. Funny enough, I had this same issue today within Queue(). I'm using queue_member in extconfig.conf (realtime members) which delivers calls to a Local channel which then finds the physical location

Re: [asterisk-dev] devicestate

2008-01-16 Thread Clod Patry
i realized that with writing Custom values to astDB. But i dont understand why we could not change existing state. Is that a possibility of writing a state to memory and not the astDB or multi-thread will cause severe damage? On Jan 16, 2008 6:44 AM, Kevin P. Fleming [EMAIL PROTECTED] wrote:

Re: [asterisk-dev] devicestate

2008-01-16 Thread Kevin P. Fleming
Atis Lezdins wrote: I agree for real devices. However i wonder - why i can't change state for Local channels. They don't exist, they are virtual channels. You *can* create your own state in the dialplan for those local channels though using the DEVSTATE() function and any custom prefix you'd

Re: [asterisk-dev] devicestate

2008-01-16 Thread Kevin P. Fleming
Leif Madsen wrote: Once the call was answered the status changed to In Use, and then everything worked as expected. I had a patch made that caused Queue() to not deliver calls to members with a status of Unknown -or- In Use, and that solved my problem for now, but not entirely sure what

Re: [asterisk-dev] devicestate

2008-01-16 Thread Atis Lezdins
On 1/16/08, Leif Madsen [EMAIL PROTECTED] wrote: I agree for real devices. However i wonder - why i can't change state for Local channels. Funny enough, I had this same issue today within Queue(). I'm using queue_member in extconfig.conf (realtime members) which delivers calls to a

Re: [asterisk-dev] devicestate

2008-01-16 Thread Clod Patry
excellent news so far. On Jan 16, 2008 9:58 AM, Kevin P. Fleming [EMAIL PROTECTED] wrote: Leif Madsen wrote: Once the call was answered the status changed to In Use, and then everything worked as expected. I had a patch made that caused Queue() to not deliver calls to members with a

Re: [asterisk-dev] Query about CHECK_BLOCKING(chan) in ast_write()

2008-01-16 Thread Tony Mountifield
While waiting for any replies to my first posting from the experts, I have been doing some more studying of the usage of CHECK_BLOCKING() and the flag AST_FLAG_BLOCKING. See below: Tony Mountifield [EMAIL PROTECTED] wrote: Yesterday I ported the MeetMe 'F' option (pass through DTMF) back to 1.2,

Re: [asterisk-dev] devicestate

2008-01-16 Thread Johansson Olle E
16 jan 2008 kl. 15.56 skrev Atis Lezdins: On 1/16/08, Leif Madsen [EMAIL PROTECTED] wrote: I agree for real devices. However i wonder - why i can't change state for Local channels. Funny enough, I had this same issue today within Queue(). I'm using queue_member in extconfig.conf

Re: [asterisk-dev] devicestate

2008-01-16 Thread Joel Vandal
I've made several test using the 'queue-state' branches (now integrated on SVN trunk) and I can confirm that this solve all our problems using Queue and Local channels, we can now specify an alternate device to monitor the state. I have also backport the change to Asterisk 1.4.17 and already

Re: [asterisk-dev] devicestate

2008-01-16 Thread Mark Michelson
Johansson Olle E wrote: 16 jan 2008 kl. 15.56 skrev Atis Lezdins: On 1/16/08, Leif Madsen [EMAIL PROTECTED] wrote: I agree for real devices. However i wonder - why i can't change state for Local channels. Funny enough, I had this same issue today within Queue(). I'm using queue_member

[asterisk-dev] Zaptel-1.4.8; Zap trunk reverts to dialtone instead of processing call

2008-01-16 Thread syd wonder
Hi All. Sorry if this issue should have been raised as a bug, I'm not too familiar with the proper protocol. I've had to revert back to Zaptel-1.4.7.1. I installed 1.4.8 but it resulted in outbound Zap calls not being processed, It appears as though the appropriate info is sent but once the

Re: [asterisk-dev] devicestate

2008-01-16 Thread Clod Patry
would you like to provide your patch somewhere so users can use it? On Jan 16, 2008 11:32 AM, Joel Vandal [EMAIL PROTECTED] wrote: I've made several test using the 'queue-state' branches (now integrated on SVN trunk) and I can confirm that this solve all our problems using Queue and Local

Re: [asterisk-dev] Easy packaging (Was unstable releases)

2008-01-16 Thread Daniel Hazelbaker
On Jan 16, 2008, at 12:46 AM, Tzafrir Cohen wrote: 3) An automated stock packaging process that builds for as many platforms as we can accommodate without funky patching etc. scripts (hence #1). Good packaging is highly distribution-specific. For isntance, what init.d scripts do you use?

Re: [asterisk-dev] Zaptel-1.4.8; Zap trunk reverts to dialtone instead of processing call

2008-01-16 Thread Tzafrir Cohen
On Wed, Jan 16, 2008 at 11:50:39AM -0500, syd wonder wrote: Hi All. Sorry if this issue should have been raised as a bug, I'm not too familiar with the proper protocol. http://bugs.digium.com/ , generally. I've had to revert back to Zaptel-1.4.7.1. I installed 1.4.8 but it resulted in

Re: [asterisk-dev] devicestate

2008-01-16 Thread Joel Vandal
Hi Clod, Here the patch against asterisk 1.4.17. http://www.scopserv.com/download/asterisk-1.4.17-state_interface.diff would you like to provide your patch somewhere so users can use it? On Jan 16, 2008 11:32 AM, Joel Vandal [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I've made