Summary:	ASTERISK-04780: One way audio when doing IAX2 transfer
Reporter:	lth (lth)	Labels:
Date Opened:	2005-08-05 02:06:39	Date Closed:	2011-06-07 14:10:19
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) a ( 1) b ( 2) c
Description:	Dear Everybod, I think this one has been up a few times but never really got resolved.  Among other it's dealt with in ASTERISK-2742773, but I couldn't find out how to append to a closed bug report. Anyway - this problem is still there.  Let me describe the setup: *A: Public static IP address located in Denmark *B: Public dynamic IP located in Malaysia *C: Public dynamic IP located in Malaysia Since only the Danish system has got a public IP - each of the other systems register there - in other words *B -> *A and *C -> *A.  Calls from B->A, A->B, C->A, A->C are all fine - absolutely no problems.  The problem is when calls goes betwen B and C.  In approximately half of the situations I end up with one way audio - and one of the system consoles writing the following: chan_iax2.c:6288 socket_read: Received trunked frame before first full voice frame A SAMPLE setup from system B is included, BUT I have tried everything - enable/disable jitterbuffer, use trunking/non-trunking (the error message is different - Received mini frame before first full voice frame), timestamps/no timestamps. All systems are CVS HEAD as of one hour ago. The only stable solution is to disable transfer, but that's really a poor solution, because the delay between system B and C is small whereas the delay between Malaysia and Denmark is HORRIBLE (we're talking 500 ms here - so round trip with two systems is close to a second). ****** ADDITIONAL INFORMATION ****** Relevant parts from iax.conf [general] ;bindport=4569 iaxcompat=yes nochecksums=no delayreject=no bandwidth=low disallow=all allow=gsm allow=ilbc jitterbuffer=yes forcejitterbuffer=no dropcount=2 maxjitterbuffer=500 maxjitterinterps=10 resyncthreshold=500 maxexcessbuffer=80 minexcessbuffer=10 jittershrinkrate=1 trunkfreq=20 trunktimestamps=yes
Comments:	By: Michael Jerris (mikej) 2005-08-09 13:08:19 we need full debug and verbose of a call having this behavior.  Downgrading to minor until we get a complete bug report so we can determin the priority. By: Michael Jerris (mikej) 2005-08-17 22:12:29 suspending this bug until a debug of the call is available.  Unfortunately we can not address this issue further without the requested debugs.  Please re-open this bug when you have that information ready to upload. By: lth (lth) 2005-08-24 03:57:21 Ok - managed to capture a situation where it happened. I'll attach 3 files - debug log from systems A, B and C (appropriately named a, b and c). A SIP UA is placing a call on system A that is routed via system B to a CAPI channel on system C.  After system B cuts itself out of the loop, voice from system A to system C disappears. By: lth (lth) 2005-08-24 03:57:55 Ah - have to mention that this is not even in trunking mode - this is a normal IAX transfer. By: lth (lth) 2005-08-24 04:04:47 Final note - sorry for the naming confusion (the A, B and C).  The log files the call is going from A -> B -> C where B is the system with public IP address. By: lth (lth) 2005-08-24 04:10:10 If running in trunk mode the transfer almost never works.  If running in non-trunk mode I would say that it fails around 10-20 % of the times. By: lth (lth) 2005-09-01 19:06:32 Hi, I am not sure if this reminder is appropriate.  I have submitted the requested debug information for bug id 4905, but perhaps you're not monitoring the bug any longer and have missed that.  If you're just busy then my apologies for this reminder. By: Michael Jerris (mikej) 2005-09-01 21:26:04 Just very little time and too much to do at the moment.  If anyone can take a look at this please? By: lth (lth) 2005-09-01 23:59:01 Perhaps it would be appropriate to change the category?  It is not only related to IAX trunking - I get the problem both with and without trunking.  Only - using trunking it happens almost every single time - when not using trunking I would say maybe 1 out of 3 fails. My guess is that IAX got some trouble recovering from certain lost packages (the long link malaysia->denmark and denmark->malaysia) do have a packet loss of around 2-3 % - not something that normally causes any real trouble - but perhaps that is what screw up the handover?  In any case even if this is not a functionality that is being used by a lot of people I think it's a relatively critical bug.  Searches in the mailing list and here does show that it has been the cause of many mysterious problems int the past. Anyway - I know and understand Open Source.  I can't expect anybody to jump just because I got a problem.  Unfortunately I am no C programmer (or any other language for that matter), but I will be happy to assist in anyway I can with testing, debugging and anything else necessary to solve this problem. By: Kevin P. Fleming (kpfleming) 2005-09-13 18:37:37 Unfortunately this will require packet dumps, not just 'set debug' and 'set verbose'. This is going to be _very_ hard to debug without them, and we will need from all three systems involved. By: lth (lth) 2005-09-14 01:20:19 I have no problem making dumps from all three systems, but how.   Can asterisk make one by itself or do you want it at network level (tcpdump?). As mentioned - to me this one is quite serious and I am OK doing whatever it takes to get the problem solved once and for all. Please let me know exactly what info you need and I will make it. By: Michael Jerris (mikej) 2005-09-14 05:30:40 yes, he is asking for tcpdumps from each of the 3 systems. By: lth (lth) 2005-09-14 19:42:54 No problem at all - I'll make those. Also - if anybody care to look into this (which is a pretty serious problem with the current iax implementation) I can arrange access to the systems in question. Meanwhile - I'll make the dumps along with new debug output and upload later. By: Matt O'Gorman (mogorman) 2005-09-29 10:05:29 Hi, after setting this up locally we were unable to generate the same bug here locally.  Can you provide me with access and when a good time for me to test would be.  You can reach me at mogorman@digium.com By: Matt O'Gorman (mogorman) 2005-09-29 10:09:18 waiting on access By: Olle Johansson (oej) 2005-10-20 02:17:42 Any updates? /Housekeeping By: Matt O'Gorman (mogorman) 2005-10-22 23:55:46 Got initial feedback and then no word for quite some time if the bug is still present please contact me and we will get to work and reopen the bug. Matt