Most likely, like you say, I would be writing my own status port follower that will respond to RouteRequest messages. Here is our situation in more detail: We have many agents who work for us that have the necessary video phone equipment to do work at home. Some of these agents might want to earn some extra money by answering emergency calls after hours. The idea is that they would log onto our website and basically in our database we would set that agent’s phone to “available”. Now at that point, this does not mean the agent is actually going to answer calls, just that he wants his phone to ring. The agent has the option of not answering calls (could have fallen asleep, or is making dinner, whatever). This is why call forking is important to us, so we can ring all the available agents at once – and the agent that actually answers the call gets paid for his work (call minutes are to be logged). We would like to minimize how long the customer needs to wait - most of our customers would be emergency federal or hospital workers. When the agent leaves home to go to work, or decides that he definitely won’t be able to answer calls, he would log onto the website again and in our database the agent’s phone would be set to “unavailable” so it doesn’t ring any more. Hopefully that explanation is clear! J Marvin Herbold From: Ian Blenke [mailto:ian@xxxxxxxxxx] On Fri, Dec 2, 2011 at 11:49 AM, Jan Willamowius <jan@xxxxxxxxxxxxxx> wrote: I would call such a feature (letting multiple endpoints ring until If you're running a call center, what you are probably wanting to do is build an automatic call distribution (ACD) system. With the gnugk vqueue option, you can either use the Java based ACD system available on the gnugk.org website, or you can write your own status port follower that response to RouteRequest messages with a RouteToAlias command to ring one an available phone. Alternatively, you could use a "hunt group", which is effectively a bunch of phones chained to one another so that whatever phone isn't offline or busy would ring next. This is what Jan is suggestion. I second his suggestion. It should work for the purposes of approximating an ACD. Doing a simultaneous ring ("call forking") isn't something presently possible with GNUGK. You can call fork with other SIP options, but then you need to interwork back and forth between SIP and H.323, and that can prove more difficult than you may be prepared for. Another thing to consider with simultaneous ring is that the behavior of a "busy" or "offline" member can change the simultaneous ring policy. Take the case of a consumer with many phones in a "find me" configuration: if the customer is on a call on one of their phones, do you automatically map a busy result code to a forward to videomail? What about a phone that is offline, do you ignore it, or do you treat that as an automatic roll to videomail as well? My bet is that in your case you would want to ignore any "busy" or "offline" phones and simply ring all of the other phones: this is decidedly a different simultaneous ring policy than a customer might have for their phones. Simultaneous ring policy is an important consideration if we go down this path with gnugk. -- |
------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d
_______________________________________________________ Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users Homepage: http://www.gnugk.org/
