CM: No ringback when using Interactive Intelligence (ININ), a third Party IP agent software, to place outbound calls.

Doc ID    SOLN302857
Version:    2.0
Status:    Published
Published date:    17 Jul 2017
Created Date:    10 Jan 2017
Author:   
Elckyn Bejarano
 

Details

CM: 6.3.11.1-SP11.1

SM: Release: 6.3.16.0.631601
 

ININ-TsServer/16.1.16.22

 

Problem Clarification

 

The customer is using Interactive Intelligence (ININ), a third Party IP agent software, to place outbound calls. The connectivity between the CM and the ININ server is via SIP. The agents place the calls from the ININ agent soft client in their computers, and the call will connect through their Avaya Desk phones.
The problem they are reporting is that when they make an outbound call, they do not hear the ring back indications, so they only know the call connected fine when they hear the other party.
 
This is happening only in one of several locations. When comparing the traces of a good scenario call with a bad call, we can see a difference in the audio connection points requested in the session descriptor protocol sdp section of the INVITE coming from the ININ server for the second leg of the call.

Cause

 

The reason why the ring back tone is not being heard in the bad scenario, is because the ININ server is shuffling the audio out to the Avaya Media Gateway, before the end point is connected to the audio stream. This behavior is not observed on the good scenario, the ININ server.

 <<SEE ATTACHED DIAGRAM>>

The two legs of the call are mark in different colors.
The first leg is the connection between the ININ media server and the agent’s Avaya desk phone.
The second leg is between the ININ Media server and the Avaya Media Gateway.
The Avaya Media Gateway has the audio coming from the external ISDN line.
 
 
The key point is the audio point requested  by the ININ server during the INVITE message of the second leg of the call. The bad scenario server requests the audio to be sent to the Avaya Media Server. The good scenario ININ server requests the audio to be sent to the ININ media server, instead.
 
 
15:44:25.567 |--INVITE-->|
 
o=ININ 1915390904 1915390905 IN IP4 10.31.41.225 <<< ININ server -- signaling
c=IN IP4 10.81.40.10 <<< Avaya MG -- media
m=audio 16388 RTP/AVP 0 101                                                                                                      
 
The ring back audio is sent to this endpoint.
 
15:44:31.015 |           |<--Ringing-|           | (145) 180 Ringing
o=- 1481899465 2 IN IP4 172.20.40.99 <<<  CM server -- signaling                                                                                           
c=IN IP4 10.81.40.10  <<< Avaya MG -- media
m=audio 16372 RTP/AVP 0 101
 
The problem here is that there is no audio connection between the agent phone and the Avaya Media Gateway at this point. The first leg is connected between the ININ Media server and the Avaya Media Gateway. And the second leg between the Avaya Media Gateway port 16388 and the Avaya MG port 16372.
 
Compare to the invite sent by the ININ server in the good scenario:
 
 
Invite:
    o=ININ 3529319147 3529319148 IN IP4 10.31.41.225   <<< ININ server -- Signaling
    c=IN IP4 10.64.15.2      <<< ININ media server -- media                      
    m=audio 16430 RTP/AVP 0 101 
 
Session Progress, Ringing, 200 OK
 
   o=- 1481123105 2 IN IP4 172.20.40.99  <<<  CM server -- signaling                                                                                                                               
   c=IN IP4 10.64.102.10     <<  Avaya MG -- media  
   m=audio 16370 RTP/AVP 0 101
 
 
Unlike in the bad scenario, here the first leg of the call is connected at this point, between the agent phone and the ININ media server. So, the ringback audio can be heard.
 
On the First leg of the call the initial end points for audio are the ININ Media Server and the Avaya Media Gateway. Then the call is shuffled, by CM to send the audio directly to the agent phone set instead of the Avaya Media Gateway.
In the bad scenario, the ININ server is initiating the second leg of the call before the first leg of the call shuffles to the agent phone.

Solution

 

The recommendation is to review the configuration of the ININ server in the bad scenario site, with respect to call shuffling or anchoring of the call audio and compare it to that of the ININ server in a good scenario site. In the good scenario the ININ server never tries to shuffle, or move the audio, from the ININ media server to the Avaya Media server.
 

https://www.devconnectprogram.com/fileMedia/download/da9d570c-c45d-4cd0-8c17-d3521302292c

As per the recommendation here (section 7.1.2) use Audio Path as Always-In, this is solving the ringback problem. Other settings are not supported by Avaya.

Attachment File


Avaya -- Proprietary. Use pursuant to the terms of your signed agreement or Avaya policy