Cisco Bug: CSCsz34614 - trunk conditioning waits too long to tell IOS to open up the audio path
Jan 28, 2017
- Cisco IOS
Known Affected Releases
12.4(18a) 12.4(24.6)T8 12.4(25) 12.4T
Symptom: ======== 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. Conditions: =========== 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 Cisco.com account to be viewed.
Bug Details Include
- Full Description (including symptoms, conditions and workarounds)
- Known Fixed Releases
- Related Community Discussions
- Number of Related Support Cases