Preview Tool

Cisco Bug: CSCsz34614 - trunk conditioning waits too long to tell IOS to open up the audio path

Last Modified

Jan 28, 2017

Products (1)

  • Cisco IOS

Known Affected Releases

12.4(18a) 12.4(24.6)T8 12.4(25) 12.4T

Description (partial)

Consider the following "connection trunk" configuration between two Cisco IOS
Voice GateWays:

            [PBX1]---T1[ VGW1 ]=====IP Cloud=====[ VGW2 ]T1---[PBX2]
                        |<----- 24 x VoX trunks ----->|

                        VoX = VoFR, VoATM, VoAAL2, VoIP
If PBX1 initiates a call towards PBX2 and sends digits over the VoX trunks, the
first DTMF digit in the digit stream is missing and the call fails due to 
insufficient routing digits at PBX2.  It may actually be necessary to implement
a workaround at PBX1 to prepend a copy of the leading digit to the digit stream,
so that when the leading digit is consumed in transit over the trunk, at the 
other end there are the correct number of digits received by PBX2 to further 
process the call.

This behaviour may be observed on an Cisco IOS Voice GateWay which has been
configured for "connection trunk" voice services, installed with any IOS which
supports voice features.  It is necessary that the trunk conditioning feature
be enabled and applied to the "connection trunk" calls -- something like:

 voice class permanent 1
 signal pattern idle transmit 0000
 signal pattern idle receive 0000
 signal pattern oos transmit 1111
 signal pattern oos receive 1111
 signal timing idle suppress-voice 10

If trunk conditioning is disabled all the digits are reliably received by the
far-end over the VoX connection trunks.  If the trunk conditioning is enabled 
the first digit is lost in 19 of 20 call attempts.

The root-cause of the problem as a timing problem between when PBX1 starts 
playing out digits to the IOS VGW1 and when the VoX trunk actually opens up the
audio path.  When the trunk conditioning feature is enabled the delay between 
the detection of incoming seizure and when the DSP-to-IOS interaction to open 
up the audio path is initiated is about 500ms.  By this time PBX1 may have 
already received an acknowledgement from the far-end PBX2 and begun playing out
digits.  The first DTMF digit is received before the audio path is open, and 
hence we lose this first digit.

This defect report is a request to lower the hardcoded delay of 500ms to 
something more reasonable like 60ms.
Bug details contain sensitive information and therefore require a account to be viewed.

Bug Details Include

  • Full Description (including symptoms, conditions and workarounds)
  • Status
  • Severity
  • Known Fixed Releases
  • Related Community Discussions
  • Number of Related Support Cases
Bug information is viewable for customers and partners who have a service contract. Registered users can view up to 200 bugs per month without a service contract.