Preview Tool

Cisco Bug: CSCsz37429 - when connection trunk signals DSP to start new call also restart encoder

Last Modified

Jan 28, 2017

Products (1)

  • Cisco IOS

Known Affected Releases


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 or distorted 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.

Bug ID CSCsz34614 "trunk conditioning waits too long to tell IOS to open up the
audio path" resolves this timing issue by lowering the hardcoded delay of 500ms
to something more reasonable like 60ms.  At the same time however, another 
parallel effort to mitigate this problem is handled by modifying the DSP

The connection trunk uses packets start/stop to control a call. However, the
encoder should reset after a long period of silence gap. We'd like to try an 
idea that when host sends to DSP the starting generate packet command, there is
additional control flag for resetting the codec. Then DSP will reset encoder and
start sending the packets again.

Testing of instrumented DSPware has proven to be successful -- even though the
problem described in CSCsz34614 is still present and the delayed audio path 
cut-through truncates the incoming DTMF digit, at the far-end the regenerated 
DTMF is clean and undistorted.
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.