[asterisk-dev] Timestamps in RTP bridged calls

[Olle E. Johansson]

On 02 Jul 2014, at 11:58, Olle E. Johansson <oej at 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