Summary:	ASTERISK-01762: timestamp issue with codec conversion and sound quality
Reporter:	Dmytro Mishchenko (arkadia)	Labels:
Date Opened:	2004-06-04 06:23:29	Date Closed:	2004-09-25 02:40:23
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) translate.c.timestamp.diff
Description:	There is a setup: Ast1 -- GSM codec -- Ast2 -- iLBC codec -- Ast3 When I'm making a call from Ast1 console to Ast3 packets sent from Ast1 to Ast2 goes with 20ms step, but packets send back from Ast2 to Ast1 goes with steps like 40ms,20ms,40ms,20ms... I believe such timestamps caused problems with sound quality when we have Cisco 7960 connected to the Ast1 box. Mark, could you give me details why packets are not buffered at Ast2 side and not transmitted back with 20 ms interval?
Comments:	By: Mark Spencer (markster) 2004-06-04 10:45:08 iLBC uses 30ms frames, while GSM uses 20ms frames.  The correct behavior is that on the one side they should step 20ms (the GSM side) and on the other iLBC side, they should step by 30ms.  Please be sure that you have latest CVS *head* (not stable!) at *all three* locations and then if the problem persists, find me on IRC and I"ll look at it.  Note that there will be 10-20ms of jitter introduced in this process by its very nature, but the timestamps contained within the RTP headers themselves should be accurate. By: Dmytro Mishchenko (arkadia) 2004-06-09 03:35:26 Mark, please let me know at what time you are available on irc. I'm online every working day at 10:00-19:00 GMT+2 and ready to assist you with this issue at any time. I'm using the latest CVS-HEAD. By: Mark Spencer (markster) 2004-06-09 08:43:22 I wil be available at 9:30 a.m. CST By: Mark Spencer (markster) 2004-06-14 00:10:55 The 20/40 was okay because it was on the IAX2 side.  Any more insight after doing some more captures? By: Paul Cadach (pcadach) 2004-06-14 04:06:25 arkadia, could you check timestamps (could be 20 or 20-then-40 ms) and packet scheduling time (must be around 30 ms) for RTP stream going from Ast1 to Cisco-7960? Cisco's hardware (except for old ones) is very sensitive for timestamps... PS: Attached patch is my "point-of-view" to simplify timestamp re-calculation when frame goes through codec translation. PPS: Is calculation of "len * s->samplesperbyte" is more accurate than just "s->f.samples" at smoother in frame.c? By: Dmytro Mishchenko (arkadia) 2004-06-15 04:35:14 markster: no results for now. I'm preparing another request for test for the guy with Cisco phone. As soon as I'll get feedback from him I'll post the results. PCadach: Mark saying that timeframes 20,40,20,40ms... is a correct issue at Ast1 side. But at Cisco phone side which is connected with SIP using g711 timeframes should be exactly 20 ms. Mark, could you post your comments about PCadach patch? By: Paul Cadach (pcadach) 2004-06-15 11:24:57 Oops, patch have missing path->delivery rounding when usecs >= 1000000. Any way, forgot about my patch - Mark's way is more complicated but looks like more correct to play with out-of-order frames. But for out-of-order frames there must be small "de-jitter" buffer to pass frames into codec input in correct order or notify it about missing frames and drop extra ones. Anyway, codec will not work correctly on mis-ordered frames except for simplest G.711 (where previous data isn't used to process current frame). By: Mark Spencer (markster) 2004-06-23 23:51:40 Is this ready to be closed? By: Dmytro Mishchenko (arkadia) 2004-06-24 01:23:27 Yup. Lets close it for now. Recent tests didn't show anything bad. Also we found and fix a bug in iaxclient lib when using with such setup. Thanks!