Is there an advantage to having a Queue members URI in the form: SIP/User (or indeed IAX2/User) Over Local/<number>@context ? I know that the latter will allow you to do things like set counting logic etc. through dialplan operations, but the former appears to be a more direct route to calling the party. (and if need be, there is the ability in queues to run a script on connection iirc). TIA for any clarification.
Thomas Kenyon wrote:> Is there an advantage to having a Queue members URI in the form: > > SIP/User (or indeed IAX2/User) > Over > Local/<number>@context > > ? > > I know that the latter will allow you to do things like set counting > logic etc. through dialplan operations, but the former appears to be a > more direct route to calling the party. (and if need be, there is the > ability in queues to run a script on connection iirc).In 1.4, you can run an agi script on connection to an agent. In trunk you can also run a macro upon agent connection. However, we use Local channels so that we can do more things *before* we dial the Agent's phone (check Jabber status / check database status etc) so we find it more useful. Indeed, someone pointed out on the irc that you *could* have a single Local/SingleAgent member of a queue and the dialplan itself could determine the correct / most appropriate agent to send the call to. Julian.> > TIA for any clarification. > > _______________________________________________ > --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 > > ______________________________________________________________________ > This email for dotr.com has been scanned by MessageLabs > ______________________________________________________________________ > >
On Tuesday 02 October 2007 19:30:44 Thomas Kenyon wrote:> Is there an advantage to having a Queue members URI in the form: > > SIP/User (or indeed IAX2/User) > Over > Local/<number>@context > > ? > > I know that the latter will allow you to do things like set counting > logic etc. through dialplan operations, but the former appears to be a > more direct route to calling the party. (and if need be, there is the > ability in queues to run a script on connection iirc).I'm migrating to Local/<number>@context right now (from Agent/ channels), and it seems to me that Local channels doesn't show (busy) in "show queues". This will probably require for me to do some overhead work for correctly displaying agent status in monitoring software, but i think i will be able to do it by combining "core show channels" with "show queues". I'm not sure is it related to Agent channels that could accept only one call or SIP channel status. I would expect queue to show even Local channel as busy if there is active call trough it. I think this really can't be accomplished by dialplan logics, as dialplan is not executed upon "show queues" Regards, Atis -- Atis Lezdins VoIP Developer, IQ Labs Inc. atis at iq-labs.net Skype: atis.lezdins Cell Phone: +371 28806004 Work phone: +1 800 7502835
I believe that using the Local/xxx at ctxt format will give you a bit more flexibility in the dialplan design, as there is an added degree of indirection. In the end I think this is only marginally costier than the "raw" channel format (unless you use the /n option) and should provide for a better laid-out dialplan. Just my $0.02, l. In data Tue, 02 Oct 2007 18:30:44 +0200, Thomas Kenyon <digium at sanguinarius.co.uk> ha scritto:> Is there an advantage to having a Queue members URI in the form: > > SIP/User (or indeed IAX2/User) > Over > Local/<number>@context > > ? > > I know that the latter will allow you to do things like set counting > logic etc. through dialplan operations, but the former appears to be a > more direct route to calling the party. (and if need be, there is the > ability in queues to run a script on connection iirc). > > TIA for any clarification. >-- Home of QueueMetrics - http://queuemetrics.com
Hi all, sorry to rehash this - but I'm having similar issues. I'm on Asterisk 1.0 and have been using Queues without any problems locally. I mean, all the SIP devices on my local server can be added to queues using AddQueueMember. However, I now need to allow agents from other servers to log in to the queue ....and I thought I could do this with IAX2/calleridnum or something ..but it doesn't work. The only way I was able to get it to work was by defining them as Local/<number>@context But this has major drawbacks. They are in the queue and can receive calls -- but when the queue directs a call to them, it loses control over it and calls are just transfered to the one agent and don't timeout ....the caller in the queue isn't really in the queue anymore... The reason it didn't work with IAX2 was that every time an agent logged in ... Add QueueMember would put them in as IAX2/iaxpeer/<random port> ... because that's where they were connecting over at that very moment. But the queue is unable to locate them at that same port when an actual call comes into the queue! Since they are always moving around ports under the IAX2 protocol. So using Local works cause it uses the dialplan's intelligence in locating an extension on an iaxpeer -- but it's not really a channel like Zap or Sip ... so queue functionality is lost So I'm revisiting this now --- is there any way to use IAX2 peers as queue members? Maybe I'm writing the URI's wrong.... Or is this something that has been fixed drasically in asterisk 1.2/1.4 anyone know? Ideas/suggestions appreciated ... -- Chris Earle "Thomas Kenyon" <digium at sanguinarius.co.uk> wrote in message news:47027234.1010607 at sanguinarius.co.uk...> Is there an advantage to having a Queue members URI in the form: > > SIP/User (or indeed IAX2/User) > Over > Local/<number>@context > > ? > > I know that the latter will allow you to do things like set counting > logic etc. through dialplan operations, but the former appears to be a > more direct route to calling the party. (and if need be, there is the > ability in queues to run a script on connection iirc). > > TIA for any clarification. > > _______________________________________________ > --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 >