Delay in IVR station going idle after call is dropped


Doc ID    SOLN215354
Version:    1.0
Status:    Published
Published date:    07 Oct 2013
Author:   
keicksteadt
 

Details

Delay in IVR station going idle after call is dropped
Found that station type set to DS1SA for station on IVR

Here is the response from Dialogic.

This appears to say that the "A" signaling bit is toggled when the call is disconnected.

From our testing, we were not seeing the A bit toggled when the call disconnected.

Problem Clarification

list trace station 16764 Page 1

LIST TRACE

time data

11:51:14 active station 16764 cid 0x1d8
11:51:14 digit 026 originated by trunk-group 4 member 128 cid 0x1d8
11:51:14 digit 026 sent to station 16764 cid 0x1d8
11:51:15 digit # originated by trunk-group 4 member 128 cid 0x1d8
11:51:15 digit # sent to station 16764 cid 0x1d8
11:51:17 digit 7204495512 originated by trunk-group 4 member 128 cid 0x1d8
11:51:17 digit 7204495512 sent to station 16764 cid 0x1d8
11:51:19 digit # originated by trunk-group 4 member 128 cid 0x1d8
11:51:19 digit # sent to station 16764 cid 0x1d8
11:51:40 idle trunk-group 4 member 128 cid 0x1d8 <<< caller hang up
11:51:50 tone-receiver 02D0301 cid 0x242
11:51:52 idle station 16764 cid 0x242 <<

Cause

After cm3, CM stopped downlinking the correct station port type out to the DS1 board for DS1SA/DS1FD type stations, so the stations stop sending the FD signaling out.

Because the fix was tied to a new administration field it doesn’t get fixed until cm6.2.

According to the MR, supposedly the VRUSA station type still works, but using that station type may be tied to a license issues to be used.

Solution

 use VRUSA station type

Restricted Solutions Elements

MR defsw110693 may apply here. Basically it indicates that sometime after cm3, CM stopped downlinking the correct station port type out to the DS1 board for DS1SA/DS1FD type stations, so the stations stop sending the FD signaling out. Because the fix was tied to a new administration field it doesn’t get fixed until cm6.2.

According to the MR, supposedly the VRUSA station type still works, but using that station type may be tied to a license issues to be used.

 

The “fix” for the MR as it stands today is in a workspace tied in with a new administration field to allow for sending of the signaling on DS1FD/DS1SA/VRUFD/VRUSA stations as normal or inverted.  The capability was added to allow for further flexibility in interfacing these ports to other vendor VRUs. 

So as the “fix” currently stands, it can’t be put into a patch because of the prec changes involved with adding the new admin field.  To back port something into a patch for cm5.2.1 we would have to write a new MR and ask for the correction to the DS1FD/DS1SA port type that is sent in the CCMS message to the DS1 board when the port is administered/board initialized, to be separated from the new administration.  If the MR is accepted it would probably take anywhere from few weeks to a couple of months to get this done.

 


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