Cisco Bug: CSCsz37429 - when connection trunk signals DSP to start new call also restart encoder
Jan 28, 2017
- Cisco IOS
Known Affected Releases
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 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. 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. 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 firmware: ##### 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 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