[Home]

Summary:ASTERISK-06234: Reproduceable one-way audio problem with bridged iax2 calls that have passed DTMF
Reporter:kb1_kanobe2 (kb1_kanobe2)Labels:
Date Opened:2006-02-01 21:50:04.000-0600Date Closed:2006-03-22 23:28:40.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I am having a 100% repeatable problem with one way audio on calls coming in a PRI/Zap channel, being passed IAX2 to a remote server and then coming back IAX2 to the first server. Native bridging in chan_iax2.c seems to be the culprit when DTMF has been present in the channel.

The servers involved are all fresh installations of 1.2.4 from the tarballs on the ftp site and have had no compliation related configuration changes. This problem may have been present in previous versions, however I just jumped up from a late-October CVS-HEAD last night and am not able to downgrade just to test for occurance of this issue.

Lets lay out the connections path thus:

Norstar<---[pri1]--->AsteriskA<---[iax2]--->AsteriskB<---[pri2]--->(PSTN)

Note that:
- Calls being placed from the Norstar, across pri1 to AsteriskA, and then being directly dial()ed back into the Norstar via a different b-channel work fine - there is full audio in both directions upon answer regardless if DTMF is passed.

- Calls being placed from the Norstar, across pri1 to AsteriskA, across iax to AsteriskB, across pri2 to the telco CO and then back in all the way to the Norstar work fine - again, full audio in both directions upon answer.

The first dialplan scenario involving native bridging inside AsteriskB Which works perfectly with two way audio every time:

[directloop]
exten => s,1,Answer
exten => s,2,monitor(wav,test)
exten => s,3,Dial(IAX2/AsteriskA/2003@out-t1nstar-hybrids,8)


The second dialplan scenario involving native bridging inside AsteriskB:

[loopwithdtmf]
exten => s,1,Answer
exten => s,2,SetVar(ivrflag=isd)
exten => s,3,Background(isd-ivr/special-announcement)           ; If it exists, play the special service notice
exten => s,4,Background(isd-ivr/grtg)                           ; Play initial greeting

exten => _1,1,monitor(wav,test)
exten => _1,2,Dial(IAX2/AsteriskA/2003@out-t1nstar-hybrids,8)

- Calls being placed from the Norstar, across pri1 to AsteriskA, across iax to AsteriskB, transmitting DTMF '1' and then being dial()ed back into the Norstar via AsteriskA do not work correctly - audio transmitted from the called party after entering the ANSWER state makes it all the way back into AsteriskB (and shows up in Monitor() captures on that server) but does not go back out of AsteriskB (ie. the wav file from Monitor() for the incoming audio side of the originating leg of the call on AsteriskA is only ever 44 bytes long). The relevant output on AsteriskB at that time reads:

   -- IAX2/AsteriskA-2 is proceeding passing it to IAX2/AsteriskA-1
   -- IAX2/AsteriskA-2 is ringing
   -- IAX2/AsteriskA-2 stopped sounds
   -- IAX2/AsteriskA-2 answered IAX2/AsteriskA-1
   -- Attempting native bridge of IAX2/AsteriskA-1 and IAX2/AsteriskA-2


In my environment and under normal operating conditions all iax calls are configured g726, trunk=no, notransfer=yes.

- Switching to a different codec all around or purposely mismatching codecs in and out of AsteriskB makes no difference to the observed behaviour.
- Enabling IAX Native Transfers (notransfer=no) works around the problem, presumably because the call is being unwound all the way back down to a zap native bridge within AsteriskA. 'nuff said.
- Enabling IAX Trunking (trunk=yes) on both systems, but leaving IAX Native Transfers disabled works around the problem, which is more telling. However, console output on AsteriskB during this configuration reads essentially the same as without trunking. Ie:

   -- Attempting native bridge of IAX2/AsteriskA-1 and IAX2/AsteriskA-16385

- Enabling IAX Trunking on AsteriskA only (ie. trunked packets going towards AsteriskB, but not coming back) _also_ works around the problem, however the opposite (enabling trunking on AsteriskB only) does not.

As an additional point of information, the same behaviours are observed if calls are placed from AsteriskA to a third asterisk server via AsteriskB and so on.

It looks like there is something unwell in the iax2 native bridge code related to DTMF detection. Perhaps someone more adept that me could take a look inside and see exactly which bit is not being used in trunked vs. non-trunked modes?

I'm open to suggestions and/or further questions however my opportunity to do further testing is severely limited.

****** ADDITIONAL INFORMATION ******

I have gone through protocol debugging on the PRIs and have found no errors with the call states - initially I assumed this behavior was occuring because a d-channel ANSWER was not being properly passed.

I have chosen to mark this as major, rather than minor, as it reproducibly but quite obscurely affects an otherwise simple call path - ie. call an IVR server, punch in some DTMF and be transfered to somewhere on a different server - poof! one way audio. Something tells me this might just be the case with someone pressing '0' to get out of a voicemail box greeting on a dedicated voicemail server in an IAX network too...
Comments:By: Mark Spencer (markster) 2006-02-20 12:30:28.000-0600

Can you try to find me on IRC or calling Digium, I'd like to see this in action.
By: kb1_kanobe2 (kb1_kanobe2) 2006-02-23 11:24:48.000-0600

Sorry for the delay, but the hardware involved in the configuration that was manifesting the problem has been removed from service due to some architecture changes. I'll dig it out and get it set up seperately just as a testbed to demostrate/test the problem.
By: Joshua C. Colp (jcolp) 2006-03-22 18:26:04.000-0600

Any update on this so we can get an environment setup that exhibits the issue?
By: kb1_kanobe2 (kb1_kanobe2) 2006-03-22 23:28:13.000-0600

Grrr... I wish I'd been able to dig into this at the time the hardware was set up and it was occuring in production. Unfortunatly I can't reproduce the exact hardware arrangement that used to be in place and, for all my fiddling, I can't get the test platforms to misbehave in the same manner even though it's the same versions of the code.

Chalk this one up to the phase of the moon and the positions of the planets. Perhaps someone else will stumble on the correct combinations of conditions in the future and reopen this ticket. For now, consider it closed.

:-/