Route Optimization in a Call centre environment

Go ahead, shoot for the feature requests, and if anyone knows the solution, they will share it with you. If there is a lot of people who request something, I will make a marketing request directly with Alcatel. A good idea would be to create a poll with each request. Alcatel-Lucent is aware of this forum.
Post Reply
User avatar
johank
Member
Posts: 11
Joined: 01 Feb 2010 11:11
Location: South Africa

Route Optimization in a Call centre environment

Post by johank » 01 Jul 2010 19:48

Route Optimization (or path replacement) in the ABC-F network or on QSIG / DPNSS etc... is a great feature but why does it not work when dialing a pilot number or voice mail?

I checked the manual and it clearly states that these are 2 of the 3 restrictions when it comes to route optimization. The 3rd has got something to do with the attendant.

Surely, when it comes to call centres you would want to optimize as much as possible.

Maybe someone could shed some light on that?
ACSE, Advanced IP, 4760, Dect, 4635

krzysioD
Alcatel Unleashed Certified Guru
Alcatel Unleashed Certified Guru
Posts: 1155
Joined: 30 Aug 2006 13:43
Location: Europe, Poland

Post by krzysioD » 03 Jul 2010 14:00

IT's by design :(
But to show you some light on it:
when OXE's is sending path replacement it's no longer aware of that call. In case of ABC-F with Piot "1", normal Q and remote PG, and pilot + virtual Q in another node, first node SHOULD monitor call for pilot "1", write it in stat files, count how many calls are in transit etc... when it's optimalized, oxe will lost track of this call (no "B" channel !), so 1st node is not aware IF its ended or if it's still in conversation with agent.
It could be done by some improvment in ABC-F protocol, but to my knowleage, from R5.x there are not many improvements ( have 2 nodes with drlink recorder in one node and recording equipment in second, call from one node to 2nd, do dr-link recording and you use 2 B channels, when audio data is avalible in 1st node, because you started this call in 1st node -- same thing for as long as i could remember !) also: only 16 E1 links from one node to another one.
So, OXE has limits, it's one of them. But as ALU said some time ago: Alcatel OmniPCX 4400 (now known as Enterprise) is not a transit PBX, it's end-user pbx with CCD, VM, etc..
And believe me: on my whiteboard there is shema where we have 4 nodes with 16 E1 ABC-F on some of them. It's call center. Customer wants an upgrade... and we have no place to put NPRAE-2 boards... we got so much traffic that ALU said: what the hell you need so many IVRs for?

So, in telco world there is magic word: dimensioning. At some level your CCD grows to scale that, well you need some more gear that ABC-F network of OXE.
BTW: say some more on this limit, are you facing same problem as I described above?

User avatar
johank
Member
Posts: 11
Joined: 01 Feb 2010 11:11
Location: South Africa

Post by johank » 05 Jul 2010 03:55

Thanks for the reply. It makes more sense now... I guess.

My setup is not that complicated. But it looks like we might have found a work-arround. When using SIP trunking (or SIP ext. gateway) the B-channels on the other side drops when they transfer the call back, even though they stay up on the oxe side.

This will work for that speciffic client, because the resource limit was with the 3rd party IVR equipment.

Good luck!
ACSE, Advanced IP, 4760, Dect, 4635

krzysioD
Alcatel Unleashed Certified Guru
Alcatel Unleashed Certified Guru
Posts: 1155
Joined: 30 Aug 2006 13:43
Location: Europe, Poland

Post by krzysioD » 11 Oct 2010 16:27

sip trunk?
R8.01?

just need to confirm before doing some real-world tests.

Post Reply

Return to “Feature Request”