With regard to (1), yes, very good point there and certainly reason enough to leave it alone. I had completely forgotten about a use case like that.
With regard to (2), I'm pretty sure there's been work done in the recent past to make chan_local more state aware so that this might not be the case any more depending on what version you are using. I might be wrong there, but I know I've got a patch or two hanging around that did make this work. Matt King wrote: > Two use-cases where autofill=no is desirable: > > 1) If it's important that you answer your callers in strict order > (i.e. in order to meet estimated wait time commitments etc). > > 2) If your queue members/agents are local channels (as local channels > are always available, so call attempts will be made regardless of > who's talking). > > Kind regards, > > Matt. > > BJ wrote > > >/ This was something I put in a long while back on 1.2 branch because we > >really needed it for 1.2 > > to "bug fix" the behavior, but also needed to prevent the change in > > behavior for those that > > didn't want it to change. > />/ > />/ That being the case and we're in the day and age of 1.6 branches now, > it'd be interesting to > > think of what people would think of deprecating this option completely > > now in /trunk in favor > > of the "autofill=yes" behavior being the only behavior available. I > > cannot think of any use > > cases where the autofill=no behavior might be desirable. That being said, > > I also might have > > blinders on so would be curious to here what the rest of the community > > has to say about it. > />/ > />/ BJ/ > -- -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users