On 02 Jul 2014, at 13:00, Olle E. Johansson <[email protected]> wrote:
> > On 02 Jul 2014, at 11:58, Olle E. Johansson <[email protected]> wrote: > >> Related issue: >> >> https://issues.asterisk.org/jira/browse/ASTERISK-23142 >> >> >> In the big jitterbuffer patch in 2006 ther was code that sets a flag on a >> AST_FRAME >> that it contains time stamp information. This is set on all incoming RTP >> audio frames. >> >> When sending RTP we reset the timestamp to the one in the frame if this flag >> is set. >> >> Now, if we have a call on hold this is dangerous. >> >> Alice calls Bob and he answers. >> -> we take the incoming TS and send out to Bob in the RTP stream >> >> Alice puts Bob on hold >> -> we activate MOH and raise the TS with 160 for every RTP packet >> >> Alice puts Bob off hold >> -> We get RTP from Alice with a new time stamp and reset ours >> >> This can lead to a big jump in time stamps and in our case lead to loss of >> audio. >> >> I don't see any reason to change the TS like this in the outbound stream. >> It's an >> unrelated stream and we set the TS on different grounds. >> >> We could shange the SSRC when this happens, but I already have systems >> complaining over the way Asterisk change SSRC every time we detect a >> problem, so I don't think it's a good idea (TM). >> >> I can understand why the jitter buffer for an incoming RTP stream needs to >> know if a >> stream has timing info, but I don't see a reason for us using the same >> timing on the >> outbound stream. >> >> Does anyone see any harm in deleting the piece of code that resets the >> timestamp, >> overriding the calculations for a new time stamp already done in the RTP >> write code? > > Apart from incoming RTP, the translate.c file sets this flag if the > translation means > that the number of samples has changed (if I understand it correctly). But > since we > normally calculate the TS based on number of samples and the outbound rate > that should not be a problem for us. > > Or? We have been running hundreds of different tests and only see improvements. Looking forward to your comments. /O -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
