On 02 Jul 2014, at 11:58, Olle E. Johansson <o...@edvina.net> 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? /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
