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?
/O
Index: res/res_rtp_asterisk.c
===================================================================
--- res/res_rtp_asterisk.c (revision 417744)
+++ res/res_rtp_asterisk.c (working copy)
@@ -1238,9 +1238,14 @@
rtp->lastdigitts = rtp->lastts;
}
+#ifdef MAYBE_BROKEN_CODE
+ /* This means that we strictly follow the timestamps of the incoming
stream, which may
+ be unrelated to our send stream. I think it's a bad idea. /OEJ
+ */
if (ast_test_flag(frame, AST_FRFLAG_HAS_TIMING_INFO)) {
rtp->lastts = frame->ts * rate;
}
+#endif
ast_rtp_instance_get_remote_address(instance, &remote_address);
--
_____________________________________________________________________
-- 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
