SIP Trunk Optimisation (Revisited

As I mentioned in a previous post we have an ongoing issue with SIP channels remaining in use when a call is transferred back to the Avaya switch from the Genesys switch after in-queue treatments via Stream Manager. This can be seen on the Avaya Trunk utilisation report shown below for the SIP trunks between Avaya and Genesys:

Image

Not only was this causing Avaya SIP channel licenses to be used unnecessarily, there were also knock-on implications during SIP Server failover. We also identified a problem which was causing Verint voice recording to fail because the Trunk ID in CTI events when delivered to an Advisor contained the SIP trunk ID rather than the ISDN trunk ID that the call was actually on and therefore Verint could not initiate recording of the call.

We have at last fixed this problem. There are two parts to the fix:

  • On the SIP trunk from Genesys to Avaya (trunk 82 in our case) set the option ‘oosp-transfer-enabled’ to true. With this option, when set to true, SIP Server puts itself in the Out Of Signaling Path (OOSP) after the single-step transfer or routing to the external destination has been completed:

Image

  • Transfer calls back to External Routing Points (ERP) on the Avaya switch via an intermediate VDN which is not monitored by Genesys. To do this, we modified the access code on each of our Avaya ERPs. In the example shown below, 45100 is an Avaya ERP which is monitored by Genesys and 47100 is an intermediate VDN which is not monitored by Genesys. The access number ’82 47100′ forces the call to be routed to this unmonitored VDN via SIP trunk 82.

Image

  • The intermediate VDN (47100) is associated with a vector that routes the call to the real ERP (45100) using a route-to 45100 step. In this way standard Genesys ISCC functionality works e.g. attached data is preserved.

The diagram below shows the end to end call flow:

Image

Share

Leave a Reply