Another alternative would be to create your own status port follower and a
minimal desktop app that receives 'call waiting' notifications from the
follower. The follower could then route the call to the first one to
accept it.
On Fri, 02 Dec 2011 11:11:26 -0600, Ian Blenke <ian@xxxxxxxxxx> wrote:
> 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
>> the first answers) 'call forking'.
>>
>> Currently GnuGk doesn't support this. But what you can do is try
>> multiple destinations with call failover: Define how long an endpoint
>> may ring (AltertingTimeout), enable failover and let GnuGk try multiple
>> endpoint one after another.
>>
>
>
> 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.
>
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
------------------------------------------------------------------------------
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/
