[asterisk-dev] Timestamps in RTP bridged calls

[Olle E. Johansson]

On 02 Jul 2014, at 13:00, Olle E. Johansson <oej at edvina.net> wrote:

> 
> 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?


We have been running hundreds of different tests and only see improvements. 

Looking forward to your comments.

/O