PSTN to Aspect to IVR Circuit question...

[dass2]

Hi All,

I am trying to educate myself on the hardware issues of telephony so I can understand Aspect even more. The question I have is as follows...

We have an ACD which operates a DPNSS link to an IVR system. The question is relating to the established circuit from PSTN to ASPECT to IVR, back into ASPECT. When the caller dials the relevant number they are connected to the ACD, so a channel has been used on the PSTN, lets call it x, and a channel will be used on Aspect, lets call it y. If the call needs to be connected to the IVR a DPNSS link channel is selected, lets call this z. If the caller wants to talk with an agent a channel back into the ACD is selected, lets call this z(i) Okay, Im pretty sure that the x channel will always remain until the call is ended, i.e the caller hangs up. My difficulty is understanding what happens with the other channels??? When the ACD goes to the IVR via DPNSS is channel y deselected i.e freeing up an Aspect channel meaning the circuit path is x-z? When The caller comes back into the ACD is channel z deselected i.e freeing up a channel onto the IVR, meaning the circuit path is x-z(i)?Or, is the whole path of the circuit in operation until the phone is put down (x-y-z-z(i)) which would mean 1 PSTN channel, 2 Aspect Channels and 2 IVR channels in operation. Im pretty sure the latter isnt the case, Im pretty sure the physical circuit path would be x-z(ii) whereby channels y and z would be freed up to facilitated other calls from PSTN to Aspect. However Im not 100% sure and telephony is a very funny subject Any help would be good

Thanks

 

[chris13]

Hi,
at first be shure: the telephony stuff IS a very funny subject, indeed. Enjoy it ;-)

OK, assuming your IVR sits behind the ACD, has no direct connection to the CO, the configuration of the ACD and the IVR are not customized for this question and there is nothing like CTI , then no channels are freed when an customer is transfered back from IVR to ACD.
When z(i) is active, 2 connections between IVR and ACD are active.
The first channel (x) from the customer to the ACD will stay active as long as the call is not disconnected by the customer or any of your systems (except the ACD transfers the call to another external party and special protocol features are in use, read on...).

Using DPNSS (or Q.SIG) between ACD and IVR it is possible to release all the channels between IVR and ACD (z and z(i)) when a call is transferred back from IVR to ACD.
The feature within these ISDN-protocolls is called "route optimization" or "path replacement".
It has to be supported by all parties of these connections.

It's supported by Aspect Rel. 8 for DPNSS and Q.SIG, they call it "Anti Trunk Tromboning". It has to be enabled in the tech-applet and you'll probably have to reboot the switch.

Your IVR-system has to support this feature, too. It is the key in the game: The transfer back to ACD z(i) is a totally new incoming call from point of view of the ACD. This is why it generates additional CDRs for these calls...
Only the IVR knows, that the channel used by z and z(i) belong to the same call. They might use even different cards. If your IVR supports route optimization/path-replacement, it can tell the ACD to connect the external customer with the agent by a new internal connection within the ACD and to free the channels between ACD and IVR.

We 've done this successfull but had to learn some lessons:
The ACD is not able to do anti-trunk-tromboning until the 2nd transfer (from IVR to agent) is successfully connected to an additional ressource of the ACD. That means connect to an agent, a dedicated voice-port or an external trunk. Just reaching the ACD and listening to MOH in queue is not enought... even if the call (z(i)) is connected from pont of view of the IVR ;-)
And to give us more fun, the ACD is queueing the protocol messages. Every 90 seconds (hard coded) it looks if there are anti-trunk-tromboning messages and checks if the given channels are both connected... THEN it frees up the channels betweeen ACD and IVR and the connection is y->z(i) ;-)

If your reports are based on calldetail, you'll have to pay some attention: The talk_time of the destination-agent may be splittet and stored into two different CDRs, and the wrapup_time may be stored within the 1st or the 2nd record depending on the occurance of anti-trunk-tromboning...
Hope I could help.

Kind regards
Chris

 

[genki]

If you have a Contact Server link to the ACD and the IVR supports it, sending a TCR (Transfer Call Request) would transfer call x into a new CCT and possibly an agent if you want. All trunk allocations between ACD-IVR are resolved and at no point 2 trunks are used between ACD-IVR. You don't need support for anti tromboning.