Summary:	ASTERISK-10369: Incorrectly sized IAX2 frames sent from mISDN with b410p
Reporter:	Matt Riddell (zx81)	Labels:
Date Opened:	2007-09-23 04:27:31	Date Closed:	2011-06-07 14:02:41
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_misdn
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) chan_iax2.patch
Description:	With the following setup PSTN -- BRI --> B410P -> * -> IAX2 Phone/Softphone The packet sizes are 16ms with a g711.ulaw or alaw codec to the phone. The phone is expecting 20ms packets (and timestamp differences). If we use the SIP component of the same softphone (and the same codec) we get the following: PSTN -- BRI --> B410P -> * -> SIP Phone/Softphone With this setup there are no problems. So, with IAX2 we get a distorted voice (sounds like it is playing 16ms of samples followed by 4ms of silence every 20ms). The problem does not occur if you are transcoding to GSM for example (maybe because the packet sizes have to change anyway). The reason that the problem occurred in IAX2 and not in SIP is because SIP is using the ast_smoother. I saw the patch on 10229 for a problem with choppy audio from incorrect packet sizes for chan_mobile.  Basically adding a smoother in to the struct and then initialising it if it hadn't been used followed by filling and emptying it. I added it to chan_iax2.c and the problem went away instantly. My implementation of the smoother is probably somewhat lacking. I think the problem may be caused by the mISDN channel reading 128 instead of 160 bytes (is it bytes) from the PSTN. I also saw the issue with choppy audio when using recent versions of GCC, and tried the patches for it. If someone wants me to upload a patch as an example I can, but I'm not sure how many people will be able to test it (you'd need to have 128 instead of 160 coming in). It may be that IAX2 is not the place to do the smoothing either.  Anyway let me know and I'll help how I can. ****** STEPS TO REPRODUCE ****** In my case, just dial a number via the PSTN without smoother and alaw or ulaw from an IAX2 phone or softphone and you hear it.
Comments:	By: Matt Riddell (zx81) 2007-09-23 05:22:14 I've uploaded a patch. This is not for production use. You get warnings if the remote end puts the call on hold (the smoother fills up), and there are warnings about not being able to pass a voice frame when the early audio arrives, but the patch is working to resolve the audio issues on my machine. The patch is against 1.4.11 By: Matt Riddell (zx81) 2007-09-23 05:24:50 An excerpt of the mISDN logs: P[ 0] misdn_jb_fill: written:160 | Bufferstatus:160 p:8312798 P[ 0] misdn_jb_empty: read:128 | Bufferstatus:32 p:8312798 P[ 2] Transmitting 128 samples 2 misdn P[ 2] writing 128 bytes 2 asterisk P[ 2] Sending :160 bytes 2 MISDN P[ 0] misdn_jb_fill: written:160 | Bufferstatus:192 p:8312798 P[ 2] Sending :160 bytes 2 MISDN P[ 0] misdn_jb_fill: written:160 | Bufferstatus:352 p:8312798 P[ 0] misdn_jb_empty: read:128 | Bufferstatus:224 p:8312798 P[ 2] Transmitting 128 samples 2 misdn P[ 2] writing 128 bytes 2 asterisk P[ 2] Sending :160 bytes 2 MISDN By: Matt Riddell (zx81) 2007-09-23 05:26:47 Oh, and there were no problems with the audio going from the IAX phones to the pstn. By: Matt Riddell (zx81) 2007-09-27 20:02:15 In thinking about this, I'm not sure it should go into iax. I think it should happen on the misdn side as it caused problems with other IAX2 connections. Thoughts? By: crich (crich) 2007-09-28 02:17:30 Reading Audiodata from the hfcmulti chip is done in the timer interrupt which can be configured to every 8 16 32 64 128 256 samples. So a mISDN audio chunk is about of one of those sizes, you can configure that in the misdn-init.conf with the poll parameter. Anyways I think a Telephony device should be able to handle a different paket size than the one itself uses. I've seen numerous SIP Phones sending Audio with Packetsizes X and others using Packetsizes Y (Y!=X) and it still worked flawlessly.. To achieve different chunksizes on needs to buffer the data, that could be done in hfcmulti/mISDN_dsp/chan_misdn or even in Asterisks generic bridge.  I thought it might be possible to use the generic jitterbuffer for such a problem am i mistaken? By: Matt Riddell (zx81) 2007-09-30 04:49:32 With SIP it works fine because it uses a smoother to allow X to become Y. IAX2 is missing this so needs to be passed the correct packet sizes. It seems the JitterBuffer is not fixing this. I have a jitterbuffer on both IAX and mISDN By: Matt Riddell (zx81) 2007-10-11 19:52:30 The other possibility is that the CLK_TCK value being 100 is not liked by mISDN.  I changed the Hz value in the kernel, recompiled, started with the new kernel but it still showed as 100 (whether I set it to 100,250 or 1000hz). I therefore set it to 100 because at least it was then the same as the running kernel. To display current CLK_TCK I used: getconf CLK_TCK By: Matt Riddell (zx81) 2007-10-23 22:03:29 Well, it seems getconf CLK_TCK doesn't work!  :) It will always display 100 no matter what your kernel is set to. The best reproducible way I've found to find the current HZ is: cat /boot/config-`uname -r`|grep CONFIG_HZ= By: Moises Silva (moy) 2007-10-27 20:13:12 I had a similar problem today, and found this bug open. It gave me some ideas. I modified app_conference to use smoothers and I have changed mISDN to generate 256 samples instead of 128 in misdn-init.conf Both changes were required, since smoothers did not helped alone since app_conference mix up only frames of 160 samples. I suggest you to try to increment mISDN sampling to 256. That way may be smoothers are not even required in IAX chan. By: Moises Silva (moy) 2007-10-27 20:14:48 By the way, I forgot. I do agree that mISDN channel driver should take care of "playing nice" by calling ast_queue_frame only when have at least 160 samples to create the frame. By: crich (crich) 2007-11-16 07:15:50.000-0600 which Softphone are you using? i used zoiper like: ISDN Phone <---> Asterisk <---> Zoiper and had not this issue, i also tried connecting 2 Asterisk Servers via IAX like: ISDN Phone <---> Asterisk <--- IAX ---> Asterisk <---> SIP Phone also no issues.. ( i have also 128 bytes chunksize when reading from ISDN ) By: Matt Riddell (zx81) 2007-11-25 20:34:41.000-0600 I'm using Zoiper too. PSTN <---> mISDN <---> Asterisk <---> Zoiper I'm also getting lots of complaints about echo - b410p card - same with echocan set to 128 or 256 By: Matt Riddell (zx81) 2007-12-24 04:01:40.000-0600 The echo issues seem to be gone since I've installed the Octasic echo canceller with 1024 taps.  Would be nice if I didn't have to patch machines though.  Is there some information I could provide which would assist in debugging this? I'm assuming its some oddity with the New Zealand telephone network. By: Joshua C. Colp (jcolp) 2008-06-04 08:30:55 crich: What size are frames coming from mISDN? By: crich (crich) 2008-06-04 08:58:06 the hfc chip can be configured to generate timer IRQs when X bytes are in the fifo, where X can be a value of: 8bytes, 16bytes, 32bytes, 64bytes, 128bytes, 256bytes where 256bytes = 32 ms , 128bytes = 16ms , 64bytes = 8ms  and so forth This timer IRQ is syncronized by the Telco, which is necessary for Slip free Audio transmission. So it is not possible to generate 20ms packets with the hfcmulti driver at the moment. It would be possible to fill a smoother buffer in chan_misdn to produce only 20ms packets, but this creates additional delay (which makes an Echocancelor  mandatory). Anyway this requires some bit of work in chan_misdn. By: Kevin P. Fleming (kpfleming) 2008-08-05 17:50:52 I don't believe there is any problem in Asterisk here at all; the IAX2 protocol allows for specification of media stream format and sampling rate, but NOT framing rate. In other words, an IAX2 endpoint must be prepared to receive media frames consisting of any legal number of bytes for the codec in use. For sample-based codecs like G.711, this could be any amount from one sample up to maximum size that can be carried in a UDP packet using IAX2. The only problem here is that the IAX2 implementation in the softphone you are testing with assumes it will receive only media frames of 20ms of samples, but that assumption is in error. It must be prepared to receive frames with any number of samples, and do smoothing (and jitter handling) on its own. The same is true of any applications in Asterisk, by the way: if the application requires frames of a known size, it must its own smoother to achieve that.