Queue -> Sip trunk -> Trixbox Pro

[KernelPanic]

We've been evaluating an Elastix installation with very positive results so far. We've even bought some support hours, and elastix support has been excellent.

However, we have a Trixbox pro sitting in a far away remote office.

The Elastix box is running a couple of queues which include some trixbox extensions.
However, the trixbox answers with a 100 Trying, and then responds with 200 OK - essentially answering the call immediately and stealing all calls from the queue. We've contacted fonality support for some assistance from their end, however is there anything we can do from this end? (The trixbox pro is relatively closed, and only allows limited configuration.)

Long term plans is to ditch the trixbox and replace it all with Elastix's installs. (Including the very expensive Cisco UCCM that the Elastix install is currently working with.)

 

[KernelPanic]

Well, Fonality have advised that its the standard behaviour of the trix box pro and can not be changed. So im out of options. It seems like there is no was to integrate the TrixBox Pro into a queue on a elastix server.

 

[Bob1]

Take their advice under advisement :unsure:

That is the standard answer when you are doing something that they have not tried or interfacing with a system that they do not have knowledge about. You do it their way or not at all. I say this from experience, and I could go on with a story or two....but that's not what this thread is about.

Can you explain more of how you are using the Trixbox extensions??? to take calls from the Elastix Queues???

Regards

Bob

 

[KernelPanic]

We have the Elastix Server in Australia. Receives calls from a E1 via a Cisco 2800 gateway.
The Elastix server has a sip trunk to the gateway.
The Elastix server has a sip trunk to a Cisco CCM in Australia.
The Elastix server also has a sip trunk to the Trixbox Pro in Malaysia.
Calls can be made between all of the servers servers and transfers run successfully.

Incoming calls go through an IVR on the Elastix Server, which forwards calls to a queue.
The queue includes extensions on the elastix server, the CCM and the TrixBox. The queue is set to "ring all".
As soon as someone enters the queue, all phones begin to ring. However, the Trixbox instantly answers any call sent to it and plays ring tone to the caller. All the other phones stop ringing - as the first extension on the trixbox now has the call. That extension is still ringing, as the phone hasn't been answered yet.

Short of dropping the trixbox out of the very tall skyscraper it currently sits in, I dont really see any options, as via the SIP channel, the trixbox never acknowledges when a phone is actually answered - its only the fact you are connected to the channel rather than the delivered ring tone. From a sip trunking point of view, it answers immediately - which in my point of view is a very stupid thing to do. In locations like Australia, where unanswered calls are not charged, a trixbox could be eating up a lot of callers money.


(I note that it's also good that there's quite an active community around here! Theres nothing quite like a bit of enthusiasm for a product. However I'm still waiting on a pricing enquiry about Support Contracts from PaloSanto..)

 

[Bob1]

Due to the closed nature of the Trixbox Pro, we are left clutching straws....

Out of interest setup an Custom Extension on the Australian Elastix box named 204

and in the dial entry, type Local/304@from-internal

Now I am assuming that you have different numbered extensions on the Malaysian box than the Australian box. Change the 304 to an extension number that is on the Malaysian box.

Add 204 to the Australian Queues and see if that works

So in effect, the Australian Queue will only have local numbers (or what it sees as local numbers).....

Naturally if this works, then assign all the Malaysian numbers with a local Australian number for the purpose of the Queues. for instance from the Australian box, they can still dial the original malaysian number of 304.

I have had to do this for a couple of solutions....

No promises, but better than nothing at the moment...

Regards

Bob

 

[KernelPanic]

Unfortunately, that doesnt help us. The Trixbox still accepts the phone call immediately, stealing it from the queue. It does come in useful in presenting our cisco extensions in the operator panel however. So its a win for us.

I think with the trixbox playing unfairly, we are pushing it up hill.

Our only options:
Replace the trixbox - not really an option now.
Perhaps add a second line to the polycom phones over there - registering to the Adelaide Elastix Server - and presenting themselves to the queue in that manner. Im not sure how well that is going to work being done remotely, because I havent worked with Polycom phones much before - but worth a try.

Thanks for your help!

 

[Bob1]

Sorry for the late reply.....had to deal with a server from hell (normal server - not PBX). Two 14 hour days....glad its done.....thats what happens with a cheap server box and using an embedded raid controller with no smarts...and looking after 50 users....even prewarned that we had concerns with drive subsystem reliability, and thankful that when we took over a couple of months ago, we forced a reliable backup image system. Thats about the only thing that saved them

Anyhow sorry, it didn't fix your trixbox problem. But you found likewise regarding the use of local extension numbers, is that the tools work well.

Your idea with the phones multihoming, I think is the best bet....we do similar for our disaster recovery option, and works well. You shouldn't have any issues with the Polycom...should do this well.

Regards

Bob

 

[KernelPanic]

Plan B. Install an Elastix Installation - Done.
Gain all the missing features you do not get with a Trix Box Pro. - Done.

Very happy so far.

 

[Bob1]

I like your plan B.....much better.. :laugh:

Have you actually implemented into production in Malaysia???

Regards

Bob

 

[KernelPanic]

Well, plan B has been functioning for almost a week now. Yes, we are in production in both Australia and Malaysia. Poor old Fonality support has been calling to find out where our extensions went.

I'll detail a report up in the success stories, but this one will go down as a major success and will serve as a model for some of our other offices..