Summary:	ASTERISK-12042: [patch] Transcoding breaks jitterbuffering
Reporter:	Damjan Jovanovic (damjan)	Labels:
Date Opened:	2008-05-19 03:46:43	Date Closed:	2009-03-16 15:11:36
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) asterisk-transcoding-copy-timestamps.patch
Description:	Asterisk doesn't copy or regenerate ts, len or seqno when transcoding from the original frame to the transcoded frame. The jitterbuffer then sees a frame with bad timing info and fails to dejitter the frame. ****** ADDITIONAL INFORMATION ****** This warning is printed out on each frame: [May 15 18:15:02] WARNING[10473] abstract_jb.c: VGSM/1/1 recieved frame with invalid timing info: has_timing_info=0, len=0, ts=0, src=g729tolin_frameout I've got a patch that fixed the problem by copying ts, len and seqno from the original frame to the transcoded frame. Let me just figure out how to upload it.
Comments:	By: snuffy (snuffy) 2008-07-26 20:56:45 anyone going to comment/update? By: jolan (jolan) 2008-09-09 12:04:28 I think this is the root cause of issue ASTERISK-12034 however this patch doesn't fix my issue but this one does: Index: rtp.c =================================================================== --- rtp.c (revision 120859) +++ rtp.c (working copy) @@ -2663,8 +2663,10 @@     if (rtp->lastts > rtp->lastdigitts)         rtp->lastdigitts = rtp->lastts; + /* XXX polycoms can't cope with high timestamps on the initial packet     if (ast_test_flag(f, AST_FRFLAG_HAS_TIMING_INFO))         rtp->lastts = f->ts * 8; + */ By: Marcus Salles (msalles) 2008-09-27 12:57:29 Yes, it really happens in my setup, transcoding between ZAP and SIP, with jbenable=yes on zapata.conf. I´ve tested with: asterisk-1.4.18.1 asterisk-1.4.20-1 asterisk-1.4.21.2 They all have the same problem. The jitterbuffer can´t work properly because transcoding has ripped the timing info. I´ve got the following in the logs: [Sep 26 20:30:09] WARNING[3200] abstract_jb.c: Zap/106-1 recieved frame with invalid timing info: has_timing_info=0, len=0, ts=0, src=g729tolin_f rameout PS: I´ve tested the patch and it worked! By: snuffy (snuffy) 2008-09-27 17:27:47 Minor thing you should only use '/* */' not '//' for comments By: Marcus Salles (msalles) 2008-09-27 18:18:18 I´ve done some more testing and found out that it only happens with g729. And it  only happens with SOME g729 implementations, not all of them. So it must NOT be an asterisk issue, I think. By: Leif Madsen (lmadsen) 2008-11-19 16:37:13.000-0600 Does this mean this issue should be closed? Anyone else having this issue? By: Leif Madsen (lmadsen) 2008-11-19 16:38:17.000-0600 Or can we at least get an update from the original reporter? There is a patch sitting here ready for you to test with. By: Tilghman Lesher (tilghman) 2009-01-21 12:27:49.000-0600 damjan:  your response would be greatly appreciated. By: Damjan Jovanovic (damjan) 2009-01-21 12:57:41.000-0600 I've already asked the authors of the G.729 codec I use and they claim their codec does everything it should (http://groups.google.com/group/asterisk-g729/browse_thread/thread/b8e0cef917704682#). So it seems to be an Asterisk bug. My patch has been used in heavy production for months, and I'm happy with it. By: Leif Madsen (lmadsen) 2009-01-26 11:17:13.000-0600 I guess this is only happening when you transcode to G.729 with a jitterbuffer? I don't get this issue with GSM. I was trying to test on this machine which doesn't have G.729 on it. By: Leif Madsen (lmadsen) 2009-02-10 11:49:14.000-0600 Sorry, I'm unassigning myself from this issue as I can't reproduce it locally. By: Leif Madsen (lmadsen) 2009-02-26 17:15:01.000-0600 Since mnicholson has been doing some jitterbuffer stuff recently, I'm going to assign this issue to him, if only to take a gander at what has been done, and to have another set of eyes look it over. Feel free to reassign if you determine you can't do anything else other than that :) By: Matthew Nicholson (mnicholson) 2009-02-27 17:09:02.000-0600 Hmm... it looks like ast_translate() already copies the ts information, except in the case where f->delivery is set.  I'll look at this some more. By: Leif Madsen (lmadsen) 2009-03-11 12:07:56 Unassigned from mnicholson upon request By: Matt Riddell (zx81) 2009-03-11 16:03:04 So is this just an issue with the illegal g729 codec?  If it only happens with g729, does it happen with the Digium version? By: Tilghman Lesher (tilghman) 2009-03-16 15:11:09 Given that we've had no complaints about jitterbuffer and the legal G.729 codec, I'm inclined to close this one out as a "won't fix".  Please note that any support we give to an illegal implementation of a codec could find us in legal difficulty.  So unless we have someone with a legitimate license to the G.729 codec correlate this issue, this issue is closed.