Thread: [Asterisk-java-users] AsteriskQueue Interface
Brought to you by:
srt
Menu
▾
▴
asterisk-java-users
|
From: Chris H. <ch...@as...> - 2006-09-26 13:49:42
|
Hi All, I'm working on a system that needs to know exactly what's happening in a queue at all times. What the system needs to know is: 1. Number of queue members logged into the queue. 2. Number of queue members available to take calls 3. Number of channels currently waiting in the queue (looks like AsteriskQueue will do this one) 4. Average wait time. It looks like the AsteriskQueue interface is a good start for this but I'm not sure if it's even possible to get the other information without parsing through a big list of queuemember responses. I'm thinking about adding an action to asterisk QueueStatSummaryRequest that will take as an argument the queue name and return the above info as a response (I really hate the way asterisk tries to send events as a response). Any thoughts? -- Chris Howard Email: ch...@as... Director Software Development Direct: 256.705.0262 Asteria Solutions Group, Inc. Main: 256.705.0277 2904 WestCorp BLVD, Suite 203 Fax: 256.705.0280 Huntsville, AL, 35805 Fax2Mail: 256.705.0262 http://www.asteriasgi.com Toll-Free: 877.ASGI.4.ME |
|
From: Stefan R. <sr...@re...> - 2006-09-27 00:08:01
Attachments:
signature.asc
|
Hey Chris, > 1. Number of queue members logged into the queue. > 2. Number of queue members available to take calls > 3. Number of channels currently waiting in the queue (looks like=20 > AsteriskQueue will do this one) > 4. Average wait time. Yes these sound like a good fit for AsteriskQueue. > It looks like the AsteriskQueue interface is a good start for this but = > I'm not sure if it's even possible to get the other information without= =20 > parsing through a big list of queuemember responses. There already is an empty method in live.internal.QueueManager called handleQueueMemberEvent() that is called on initialization, where we could put some meat in. A new live object QueueMember (or AsteriskAgent) will be needed to represent agents. The interesting part starts after initialization, i.e. tracking agent events and updating the model. The relevant ones seem to be - AgentLoginEvent - AgentLogoffEvent - AgentCallbackLoginEvent - AgentCallbackLogoffEvent To associate agents with the callers they are serving (and to see whether they are busy or not) looking for AgentCalledEvents will be needed as well as observing the associated channel for hangup or redirection so we know when the agent is available again. Once that has been done some new methods could be added to AsteriskQueue and AsteriskAgent like support for easy login/logout, etc. > I'm thinking about=20 > adding an action to asterisk QueueStatSummaryRequest that will take as = > an argument the queue name and return the above info as a response (I=20 > really hate the way asterisk tries to send events as a response). Any = > thoughts? I hope that this is not needed because the idea of the live package is to observe asterisk events and update an in memory model of asterisks state so you dont have to talk to asterisk each time you query the state.= =3DStefan --=20 reuter network consulting Neusser Str. 110 50760 Koeln Germany Telefon: +49 221 1305699-0 Telefax: +49 221 1305699-90 E-Mail: ste...@re... Jabber: ste...@re... |
|
From: Chris H. <ch...@as...> - 2006-09-27 13:22:37
|
Stefan Reuter wrote: > Hey Chris, > > >> 1. Number of queue members logged into the queue. >> 2. Number of queue members available to take calls >> 3. Number of channels currently waiting in the queue (looks like >> AsteriskQueue will do this one) >> 4. Average wait time. >> > > Yes these sound like a good fit for AsteriskQueue. > > >> It looks like the AsteriskQueue interface is a good start for this but >> I'm not sure if it's even possible to get the other information without >> parsing through a big list of queuemember responses. >> > > There already is an empty method in live.internal.QueueManager called > handleQueueMemberEvent() that is called on initialization, where we > could put some meat in. > A new live object QueueMember (or AsteriskAgent) will be needed to > represent agents. > The interesting part starts after initialization, i.e. tracking agent > events and updating the model. The relevant ones seem to be > - AgentLoginEvent > - AgentLogoffEvent > - AgentCallbackLoginEvent > - AgentCallbackLogoffEvent > To associate agents with the callers they are serving (and to see > whether they are busy or not) looking for AgentCalledEvents will be > needed as well as observing the associated channel for hangup or > redirection so we know when the agent is available again. > > Once that has been done some new methods could be added to AsteriskQueue > and AsteriskAgent like support for easy login/logout, etc. > We are doing something similar in our queue management application (external from Asterisk-Java). Getting the initial state is fun as you probably already have callers in the queue and agents on the phone. I'm willing to invest some resources in this as it would make my life much easier to keep this info in Aasterisk-Java and make my presentation piece more light weight. Where do we start? > >> I'm thinking about >> adding an action to asterisk QueueStatSummaryRequest that will take as >> an argument the queue name and return the above info as a response (I >> really hate the way asterisk tries to send events as a response). Any >> thoughts? >> > I hope that this is not needed because the idea of the live package is > to observe asterisk events and update an in memory model of asterisks > state so you dont have to talk to asterisk each time you query the state. > For our immediate needs we created a QueueSummary action that returns the info needed. This patch has already been accepted in trunk. http://bugs.digium.com/view.php?id=8035 -- Chris Howard Email: ch...@as... Director Software Development Direct: 256.705.0262 Asteria Solutions Group, Inc. Main: 256.705.0277 2904 WestCorp BLVD, Suite 203 Fax: 256.705.0280 Huntsville, AL, 35805 Fax2Mail: 256.705.0262 http://www.asteriasgi.com Toll-Free: 877.ASGI.4.ME |
|
From: Carlos G M. <tr...@ac...> - 2006-09-28 11:57:06
|
Hi, I'm also looking into this... A start could be defining the AsteriskAgent model data ? -ID -Associated extension (as reported by Loginchan) -Associated channel (as in SIP/XXX used for login) -Mode (call back/dedicated) -Status (inbound/outbound/free/<queueName>) (I'm a litle confused though because of the capacity of an agent to have more than one call at one time..., invalidating this approach, but I'm trying to have some way of mapping agent to logical extension) -Since (i.e. time at which entered current state) and an association from AsteriskQueue to AsteriskAgent, which needs also some data: -Membership -CallsTaken -Penalty -LastCall -Paused AsteriskQueue could be extended to have some running averages like avgHold, avgConnTime. Thoughts ? I hope my abrupt chime in is ok :) -Carlos Chris Howard @ 27/09/2006 10:24 -0300 dixit: > Stefan Reuter wrote: >> Hey Chris, >> >> >>> 1. Number of queue members logged into the queue. >>> 2. Number of queue members available to take calls >>> 3. Number of channels currently waiting in the queue (looks like >>> AsteriskQueue will do this one) >>> 4. Average wait time. >>> >> Yes these sound like a good fit for AsteriskQueue. >> >> >>> It looks like the AsteriskQueue interface is a good start for this but >>> I'm not sure if it's even possible to get the other information without >>> parsing through a big list of queuemember responses. >>> >> There already is an empty method in live.internal.QueueManager called >> handleQueueMemberEvent() that is called on initialization, where we >> could put some meat in. >> A new live object QueueMember (or AsteriskAgent) will be needed to >> represent agents. >> The interesting part starts after initialization, i.e. tracking agent >> events and updating the model. The relevant ones seem to be >> - AgentLoginEvent >> - AgentLogoffEvent >> - AgentCallbackLoginEvent >> - AgentCallbackLogoffEvent >> To associate agents with the callers they are serving (and to see >> whether they are busy or not) looking for AgentCalledEvents will be >> needed as well as observing the associated channel for hangup or >> redirection so we know when the agent is available again. >> >> Once that has been done some new methods could be added to AsteriskQueue >> and AsteriskAgent like support for easy login/logout, etc. >> > We are doing something similar in our queue management application > (external from Asterisk-Java). Getting the initial state is fun as you > probably already have callers in the queue and agents on the phone. I'm > willing to invest some resources in this as it would make my life much > easier to keep this info in Aasterisk-Java and make my presentation > piece more light weight. Where do we start? > >> >>> I'm thinking about >>> adding an action to asterisk QueueStatSummaryRequest that will take as >>> an argument the queue name and return the above info as a response (I >>> really hate the way asterisk tries to send events as a response). Any >>> thoughts? >>> >> I hope that this is not needed because the idea of the live package is >> to observe asterisk events and update an in memory model of asterisks >> state so you dont have to talk to asterisk each time you query the state. >> > For our immediate needs we created a QueueSummary action that returns > the info needed. This patch has already been accepted in trunk. > http://bugs.digium.com/view.php?id=8035 > -- Carlos G Mendioroz <tr...@ac...> |
|
From: Carlos G M. <tr...@hu...> - 2006-09-28 18:13:56
|
Following myself: I kind of solved the out/in issue via dialplan programming using automatic pausing of agents when receiving calls direct or generating calls, but I don't like the idea of the library functionality being dependent on certain dialplan logic. Also, elaborating on AsteriskQueue information, it would be nice to have counters by "buckets" like answered in less than 5, 5-15, 15-30, 30-60, 60-120, 120-300, 300+ or whatever scale. Missing from before is abandon counters and bucket counters too. Longest talk time and hold time with timestamps ? Buckets are hard to do w/o some backing store, so I guess some of this will have to go to a special implementation and not to standard library. -Carlos Carlos G Mendioroz @ 28/09/2006 08:56 -0300 dixit: > Hi, > I'm also looking into this... > > A start could be defining the AsteriskAgent model data ? > -ID > -Associated extension (as reported by Loginchan) > -Associated channel (as in SIP/XXX used for login) > -Mode (call back/dedicated) > -Status (inbound/outbound/free/<queueName>) > (I'm a litle confused though because of the capacity of an agent to > have more than one call at one time..., invalidating this approach, > but I'm trying to have some way of mapping agent to logical extension) > > -Since (i.e. time at which entered current state) > > and an association from AsteriskQueue to AsteriskAgent, > which needs also some data: > -Membership > -CallsTaken > -Penalty > -LastCall > -Paused > > AsteriskQueue could be extended to have some running averages like > avgHold, avgConnTime. > > Thoughts ? > I hope my abrupt chime in is ok :) > -Carlos > > Chris Howard @ 27/09/2006 10:24 -0300 dixit: >> Stefan Reuter wrote: >>> Hey Chris, >>> >>> >>>> 1. Number of queue members logged into the queue. >>>> 2. Number of queue members available to take calls >>>> 3. Number of channels currently waiting in the queue (looks like >>>> AsteriskQueue will do this one) >>>> 4. Average wait time. >>>> >>> Yes these sound like a good fit for AsteriskQueue. >>> >>> >>>> It looks like the AsteriskQueue interface is a good start for this but >>>> I'm not sure if it's even possible to get the other information without >>>> parsing through a big list of queuemember responses. >>>> >>> There already is an empty method in live.internal.QueueManager called >>> handleQueueMemberEvent() that is called on initialization, where we >>> could put some meat in. >>> A new live object QueueMember (or AsteriskAgent) will be needed to >>> represent agents. >>> The interesting part starts after initialization, i.e. tracking agent >>> events and updating the model. The relevant ones seem to be >>> - AgentLoginEvent >>> - AgentLogoffEvent >>> - AgentCallbackLoginEvent >>> - AgentCallbackLogoffEvent >>> To associate agents with the callers they are serving (and to see >>> whether they are busy or not) looking for AgentCalledEvents will be >>> needed as well as observing the associated channel for hangup or >>> redirection so we know when the agent is available again. >>> >>> Once that has been done some new methods could be added to AsteriskQueue >>> and AsteriskAgent like support for easy login/logout, etc. >>> >> We are doing something similar in our queue management application >> (external from Asterisk-Java). Getting the initial state is fun as you >> probably already have callers in the queue and agents on the phone. I'm >> willing to invest some resources in this as it would make my life much >> easier to keep this info in Aasterisk-Java and make my presentation >> piece more light weight. Where do we start? >> >>> >>>> I'm thinking about >>>> adding an action to asterisk QueueStatSummaryRequest that will take as >>>> an argument the queue name and return the above info as a response (I >>>> really hate the way asterisk tries to send events as a response). Any >>>> thoughts? >>>> >>> I hope that this is not needed because the idea of the live package is >>> to observe asterisk events and update an in memory model of asterisks >>> state so you dont have to talk to asterisk each time you query the state. >>> >> For our immediate needs we created a QueueSummary action that returns >> the info needed. This patch has already been accepted in trunk. >> http://bugs.digium.com/view.php?id=8035 >> > -- Carlos G Mendioroz <tr...@hu...> LW7 EQI Argentina |
|
From: Carlos G M. <tr...@ac...> - 2006-09-28 18:14:09
|
Following myself: I kind of solved the out/in issue via dialplan programming using automatic pausing of agents when receiving calls direct or generating calls, but I don't like the idea of the library functionality being dependent on certain dialplan logic. Also, elaborating on AsteriskQueue information, it would be nice to have counters by "buckets" like answered in less than 5, 5-15, 15-30, 30-60, 60-120, 120-300, 300+ or whatever scale. Missing from before is abandon counters and bucket counters too. Longest talk time and hold time with timestamps ? Buckets are hard to do w/o some backing store, so I guess some of this will have to go to a special implementation and not to standard library. -Carlos Carlos G Mendioroz @ 28/09/2006 08:56 -0300 dixit: > Hi, > I'm also looking into this... > > A start could be defining the AsteriskAgent model data ? > -ID > -Associated extension (as reported by Loginchan) > -Associated channel (as in SIP/XXX used for login) > -Mode (call back/dedicated) > -Status (inbound/outbound/free/<queueName>) > (I'm a litle confused though because of the capacity of an agent to > have more than one call at one time..., invalidating this approach, > but I'm trying to have some way of mapping agent to logical extension) > > -Since (i.e. time at which entered current state) > > and an association from AsteriskQueue to AsteriskAgent, > which needs also some data: > -Membership > -CallsTaken > -Penalty > -LastCall > -Paused > > AsteriskQueue could be extended to have some running averages like > avgHold, avgConnTime. > > Thoughts ? > I hope my abrupt chime in is ok :) > -Carlos > > Chris Howard @ 27/09/2006 10:24 -0300 dixit: >> Stefan Reuter wrote: >>> Hey Chris, >>> >>> >>>> 1. Number of queue members logged into the queue. >>>> 2. Number of queue members available to take calls >>>> 3. Number of channels currently waiting in the queue (looks like >>>> AsteriskQueue will do this one) >>>> 4. Average wait time. >>>> >>> Yes these sound like a good fit for AsteriskQueue. >>> >>> >>>> It looks like the AsteriskQueue interface is a good start for this but >>>> I'm not sure if it's even possible to get the other information without >>>> parsing through a big list of queuemember responses. >>>> >>> There already is an empty method in live.internal.QueueManager called >>> handleQueueMemberEvent() that is called on initialization, where we >>> could put some meat in. >>> A new live object QueueMember (or AsteriskAgent) will be needed to >>> represent agents. >>> The interesting part starts after initialization, i.e. tracking agent >>> events and updating the model. The relevant ones seem to be >>> - AgentLoginEvent >>> - AgentLogoffEvent >>> - AgentCallbackLoginEvent >>> - AgentCallbackLogoffEvent >>> To associate agents with the callers they are serving (and to see >>> whether they are busy or not) looking for AgentCalledEvents will be >>> needed as well as observing the associated channel for hangup or >>> redirection so we know when the agent is available again. >>> >>> Once that has been done some new methods could be added to AsteriskQueue >>> and AsteriskAgent like support for easy login/logout, etc. >>> >> We are doing something similar in our queue management application >> (external from Asterisk-Java). Getting the initial state is fun as you >> probably already have callers in the queue and agents on the phone. I'm >> willing to invest some resources in this as it would make my life much >> easier to keep this info in Aasterisk-Java and make my presentation >> piece more light weight. Where do we start? >> >>> >>>> I'm thinking about >>>> adding an action to asterisk QueueStatSummaryRequest that will take as >>>> an argument the queue name and return the above info as a response (I >>>> really hate the way asterisk tries to send events as a response). Any >>>> thoughts? >>>> >>> I hope that this is not needed because the idea of the live package is >>> to observe asterisk events and update an in memory model of asterisks >>> state so you dont have to talk to asterisk each time you query the state. >>> >> For our immediate needs we created a QueueSummary action that returns >> the info needed. This patch has already been accepted in trunk. >> http://bugs.digium.com/view.php?id=8035 >> > -- Carlos G Mendioroz <tr...@ac...> |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X