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?
Route Optimization in a Call centre environment
Route Optimization in a Call centre environment
ACSE, Advanced IP, 4760, Dect, 4635
-
krzysioD
- Alcatel Unleashed Certified Guru
- Posts: 1165
- Joined: 30 Aug 2006 13:43
- Location: Europe, Poland
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?
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?
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!
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
