Experiencing Call Collisions? We Have a Solution!

No matter the care with which complex or extensive telecommunications systems are developed, inherent obstacles to providing flawless inbound and outbound interactions are introduced through SIP stack delays, slow PBXs, and automated IVRs. Call collisions, also known as glare, occur when a channel or phone line is seized to make an outbound call at the same time as it is offered an inbound call. The result of a call collision might end in the inbound call being dropped – a frustrating experience for customers calling in to the IVR. The Pronexus development and support teams offer the following guidance for IVR developers hoping to eliminate call collisions from their IVR.

The best way to prevent collisions from occurring is to designate two line groups, one for inbound and one for outbound. The inbound line group should maintain a minimum number of channels in WaitForRing mode to ensure that there are always available channels to take new incoming calls. The other line group, however, should have all its channels in Idle mode for the IVR to actively select and launch outbound calls. Grouping channels by functionality and separating inbound and outbound channels eliminates a chance for any collision.

The problem, however, is harder to solve when channels are limited or the required number of outbound channels and inbound channels is high, dynamic or needs to change during the course of a day. This is when sharing line groups is needed and channels with dual functionality will be used.

The general rule is that if a channel is put in WaitForRing state and the application later decides to place an outbound call on that channel, glare may occur. When a line group is designed to serve calls in both directions, the best approach is to put the line group in Idle mode and programmatically set several channels to wait for ring as required, leaving some in the Idle state to serve an anticipated number of outbound calls.

When a call is finished, whether it is an inbound or an outbound call, the channel returns to Idle state (the default state set for the line group), and the application determines how the channel will be used next. Channel status can be decided in LineGroup’s Released event; if an outbound call is needed, this channel can be used. An added benefit of this is that the IVR avoids looping through all channels to find one that is idle to serve an outbound. If an outbound is not needed or there are more Idle channels than WaitingForRing, the IVR application can set this one to WaitForRing. Starting a call or waiting for ring actions, however, cannot be executed in Release event; a queuing mechanism with a small timer is used to ensure that the suitable action occurs shortly after Release. This gives the system higher availability performance.

By designating channels and ensuring a minimum number of WaitForRing and Idle channels at all times, your IVR should smoothly handle inbound and outbound calls without encountering the call collisions that are so annoying for end customers.