Summary:	ASTERISK-14288: TDM call over IAX trunk gives choppy audio, SIP call over same IAX trunk sounds fine.
Reporter:	Alec Davis (alecdavis)	Labels:
Date Opened:	2009-06-09 07:03:45	Date Closed:	2009-09-22 09:31:12
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_iax2
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Testing to an Asterisk 1.4.20 -> Milliwatt application. Also tested to an elderly 1.6.x r178446M release. same problems. senarios are as below: Analog phone <-> FXS-TDM800P/Asterisk 1.6.1.0 <-IAX internet-> Asterisk 1.4.20 Milliwatt App. SIP phone <-> Asterisk 1.6.1.0 <-IAX internet-> Asterisk 1.4.20 Milliwatt App. Analog phone audio sounds very choppy, SIP phone audio sounds fine. Tried with GSM only IAX trunks, and ALAW only trunks, same result, no improvement. ****** ADDITIONAL INFORMATION ****** Server with TDM800P and FXS module. Asterisk SVN-branch-1.6.1-r199300, also tried with Asterisk SVN-trunk as of weekend, both choppy audio when using TDM over IAX. Additonal non internet tests to; Same server Milliwatt app, TDM and SIP sound fine. Local network Asterisk SVN-trunk-r192214M, TDM and SIP sound fine.
Comments:	By: Alec Davis (alecdavis) 2009-06-11 06:31:40 Tonight tested between 2 locally connected boxes on the same ethernet switch. Both Asterisk SVN-branch-1.6.1-r199300 and DAHDI SVN-trunk-r6675. Both with DAHDI timing hardware, BOX1 TDM800P, BOX2 X100P. CISCO 7912 SIP <-> BOX 1 IAX <-> 100M SWITCH <-> BOX 2 IAX [Milliwatt App] The symptom was the audio from the Milliwatt generator cuts out after 2-3 seconds every time noise is made at the CISCO end, IE a packet is transmitted, which then restarts the packets being sent from the remote Milliwatt app. Surely, the Milliwatt generator is 'talking' all the time, so packets should be coming to the CISCO? This I believe is the answer, packets are sent asynchrounously, one received, one sent, where the Milliwatt app is the slave, the Cisco is the master. On Box 2 if 'internal_timing = yes' is enabled in asterisk.conf that fixes the CISCO silence issue, but I think that IAX is switching in and out of synchronous mode and asynchronous mode when packets arn't received, thus if network jitter is present in both directions, the audio sounds twice as bad. Also checked with a Grandstream phone, when you press MUTE, the audio received from the Milliwatt App stops. Again at BOX 2 enabling 'internal_timing = yes' fixes the audio stopping issue. By: Alec Davis (alecdavis) 2009-06-11 07:14:19 FWIW I Found the 'internal timing' here https://issues.asterisk.org/view.php?id=5374 By: Leif Madsen (lmadsen) 2009-09-18 08:30:14 Honestly, I'm not even sure what I should ask for here, other than to ask if this is still an issue on boxes that are using a recent version of Asterisk and DAHDI? By: Alec Davis (alecdavis) 2009-09-18 18:34:01 When silence suppresion is enabled the cisco, it stops packets going towards asterisk during silence, the Milliwatt application seems to stop sending packets when nothing comes in. Surely the Milliwatt app should keep sending packets. So this leads me to IAX, if packets have jitter getting to asterisk over the internet, then as reply packets traverse the internet will have more jitter added, making for choppy audio, with twice the amount of jitter. By: Dmitry Andrianov (dimas) 2009-09-18 18:44:50 If internal timing=yes fixes everything, what iis the problem then? By: Alec Davis (alecdavis) 2009-09-18 19:49:25 Such an obscure setting, /etc/asterisk/asterisk.conf doesn't even advise what it's about, one line ';internal_timing = yes' What other loading/performance implications does it have? However, what I suspect is internal_timing when set to yes kicks in and out, but yet to verify. By: Dmitry Andrianov (dimas) 2009-09-18 19:59:54 I never understood why internal_timing is not YES by default. Everybody I know turn it on as the first thing after Asterisk installation. And I see lots of "i have bad audio" topics on forums where people eventually get advice "turn internal timing on". From the other hand, I have not seen any probler which is solved by turning that timing off.. By: Leif Madsen (lmadsen) 2009-09-22 09:31:11 I'm closing this issue as 'resolved by a configuration change' However, it might be advisable if someone could create a simple patch and open an issue with the subject of, "make internal timing enabled by default"