Summary:ASTERISK-02078: iaxy with one-way audio
Reporter:duncan (duncan)Labels:
Date Opened:2004-07-21 15:33:11Date Closed:2008-01-15 15:03:22.000-0600
Versions:Frequency of
Environment:Attachments:( 0) codec_problem.txt
( 1) fine_inbound_call.txt
( 2) iax2debug.txt
( 3) successful_call.txt
( 4) working_but_rx_lost_after_12_seconds.txt
Description:so then i went to spain for a week, come back and suddenly the iaxys are needed for a demonstration and misbehaving.  when they connect you can speak for a second or two then its just one way audio (the user cant hear anyone but the person whos been called is able to hear the user saying "hello?  hello?  can you hear me?"

it appears to be that the iaxys try and bridge the call and connect directly to the Asterisk server with the TE410P connected.  

i have no idea whats been changed since i last used the iaxy (not the versions of the asterisk machines for sure), but perhaps someone has locked down the firewall and closed off the IP addresses that can get through over the IAX2 port (very likely).

so naturally i try adding the notransfer=yes to the Iaxy account, but this doesnt seem to help.  

we thought this might be down to the fact that the server with the TE410P card in it is running an older version of asterisk (8 weeks ago stable branch) than the server the iaxy is registered with (2 weeks ago head)

so we upgraded the registration server to latest cvs head to see if that made a difference (none), then decided to downgrade it to the same cvs install as the server with the TE410P on it, and again no difference.  

we are planning on upgrading both to CVS head to see if this makes a difference but the one with the TE410P is a production machine with lots of IVR applications on it, and this time of the week is always the busiest for it, so we are trying to plan the best time to take it down without upsetting any customers.  

any suggestions on how we can stop this happening?  i really hate the transfer feature, its really only good for small situations where the phones are on the same network and you want to take the load off the server - we never seem to want this functionality.

tomorrow am i will know if anything has changed on the firewall, and if so what.  but in the meantime are there any suggestions to get the calls working ok?


   -- Accepted AUTHENTICATED TBD call from
   -- Accepting DIAL from, formats = 0x4
   -- Executing AbsoluteTimeout("IAX2[205712878@205712878]/14", "3600") in new stack
   -- Set Absolute Timeout to 3600
   -- Executing NoOp("IAX2[205712878@205712878]/14", "") in new stack
   -- Executing SetCallerID("IAX2[205712878@205712878]/14", "205712878") in new stack
   -- Executing Dial("IAX2[205712878@205712878]/14", "IAX2/ACCOUNT:PASSWORD@IPADDRESS/381638887260|90") in new stack
   -- Called ACCOUNT:PASSWORD@IPADDRESS/381638887260
   -- Call accepted by IPADDRESS (format ULAW)
   -- Format for call is ULAW
   -- IAX2[IPADDRESS:4569]/2 is ringing
   -- IAX2[IPADDRESS:4569]/2 stopped sounds
   -- IAX2[IPADDRESS:4569]/2 answered IAX2[205712878@205712878]/14
   -- Attempting native bridge of IAX2[205712878@205712878]/14 and IAX2[IPADDRESS:4569]/2

it goes silent when this happens, and the iaxy appears to lose its registration with the server (light goes off inside it).

Comments:By: Mark Spencer (markster) 2004-07-22 00:01:21

Can you perhaps provide a debug trace from the perspective of the Asterisk in the middle?

By: duncan (duncan) 2004-07-22 04:33:44

ok spoken with the firewall guy and he's claiming innocence, apparently no changes to the firewall in ages, and no ip address restrictions.  so i guess i'll update both machines to latest cvs and see what happens.

By: duncan (duncan) 2004-07-22 05:49:04

ok so this debug (iax2debug.txt) is from my iaxy.  ringing my mobile number.  call started, and after a few seconds the mobile could no longer hear the iaxy's transmissions.  the iaxy had terrible echo of itself as well.  although this could be down to my terrible internet connection right now.

more debugs to follow.  hope this helps.

oh and its from todays cvs-head of course....

edited on: 07-22-04 08:36

By: duncan (duncan) 2004-07-22 09:06:31

working_but_rx_lost_after_12_seconds.txt = another iax2 debug from a different iaxy again appears to lose sound when the transfer attempt happens.

By: Mark Spencer (markster) 2004-07-22 20:08:30

According to the log, it's attempting to do a firmware upgrade...  What did you change that made this problem show up?

By: duncan (duncan) 2004-07-23 04:48:47

the only thing i can think of is that we do regular cvs-head upgrades to that machine to test out sip features.  the last time, before this problem started showing up (allegedly it was working fine at the beginning of the week), was when we physically put a new machine down and gave it a new cvs install.  this happened just over 2 weeks ago.

but anyway, that debug was taken from it running yesterdays cvs.

so whats the best solution?  remove the iaxy.bin from /var/lib/asterisk/firmware/iax/iaxy.bin?

By: duncan (duncan) 2004-07-23 05:26:24

successful_call.txt: so this call was fine, i moved the /var/lib/asterisk/firmware/iaxy.bin out of that directory and reloaded asterisk, then attempted a call.  no one-way audio... everything seemed to go ok.

this was the iaxy calling out to a fixed line.

edited on: 07-23-04 05:30

By: duncan (duncan) 2004-07-23 06:13:03

ok now we have one-way audio on the other way around.  when someone calls to our iaxy.  

see the attached file codec_problem.txt

ok problem investigated some more.  added disallow=all in the iax.conf entry for the device and allow=ulaw.  this seemed to resolve the problem (we still experience echo) but both sides could hear each other.  im sure the echo is a result of something in the telecom network rather than the asterisk server or iaxy.

so the debug of a good call is fine_inbound_call.txt

By: duncan (duncan) 2004-07-23 06:16:02

yeah so to summarise, it appears to work ok in both directions now we have removed the iaxy.bin from the server.  

our are iaxys able to be upgraded?  someone on irc mentioned that the newer iaxys should upgrade automatically, but the older ones need to go back to digium to be upgraded.

By: Mark Spencer (markster) 2004-07-23 12:20:26

Your iaxy's definitely are able to upgrade (and downgrade).  Basically the iaxy will look at the version of firmware available on the server it registers with, and if that's different from what it has, then it will upgrade or downgrade to it.

By: duncan (duncan) 2004-07-23 14:08:01

well if my iaxys are fine, why are they crashing and causing one-way audio when they try and download new firmware.  surely this is a bug...

By: Mark Spencer (markster) 2004-07-23 22:15:58

Actually the most likely cause was that you did a "make install" (thus replacing the iaxy.bin binary) without then executing a "reload" which would cause it to actually load the correct parameters from the file you replaced.

By: Mark Spencer (markster) 2004-07-23 23:04:37

Okay I modifed Asterisk to make a copy of the firmware file and work from that so that overwriting the original firmware will not affect a runnign asterisk.

By: Digium Subversion (svnbot) 2008-01-15 15:03:22.000-0600

Repository: asterisk
Revision: 3500

U   trunk/channels/chan_iax2.c

r3500 | markster | 2008-01-15 15:03:22 -0600 (Tue, 15 Jan 2008) | 2 lines

Work on copy of firmware so that it doesn't get corrupted on a "make install" (bug ASTERISK-2078)