Hi,
I don't remember what was the use-case that concluded to this value of 50
packets.
Concerning the timestamp fix, you are right.
I think I never saw this bug because I called rtp_session_resync() within the
ssrc-changed callback.
I've added this line into my svn tree, it will be commited soon.
Simon
Le Thursday 14 May 2009 08:19:21 Rudolf Svanda, vous avez écrit :
> Hi,
>
> i have a question to validity checks after sender change its SSRC. Ortp
> discarts SSRC_CHANGED_THRESHOLD RTP Pakets till declaring source as valid.
> In RFC 3550 is a code snippet with MIN_SEQUENTIAL set to 2.
> SSRC_CHANGED_THRESHOLD is set to 50 Pakets. What is the reason for such a
> high value (in Time it's 1s)?
>
> And there ist possibly a bug in validity check. Sender sends following RTP
> stream: SSRC:a;Seq: b;Time: c
> SSRC:a;Seq: b+1;Time: c+160
> SSRC:a;Seq: b+2;Time: c+320
> ...
> SSRC:a;Seq: b+k;Time: c+(k*160)
> now sender change it SSRC, Seq and Time
> SSRC:x;Seq: y;Time: z
> SSRC:x;Seq: y+1;Time: z+160
> SSRC:x;Seq: y+2;Time: z+320
>
> if z ist lower than c+(k*160), all RTP Pakets will be discarded till sender
> sends RTP Paket with Timestamp higher than c+(k*160). I think after SSRC is
> decrared as valid, Timestamp should be set to current RTP Paket Timestamp.
> Something like this (rtpparce.c in version 15):
>
> ***************
> *** 148,153 ****
> --- 148,154 ----
> }
>
> session->rcv.ssrc=rtp->ssrc;
> + session->rtp.rcv_last_ts = rtp->timestamp;
>
> rtp_signal_table_emit(&session->on_ssrc_changed); }else{
> /*discard the packet*/
> ***************
>
> BR
> Rudi
>
>
> _______________________________________________
> Linphone-users mailing list
> [email protected]
> http://lists.nongnu.org/mailman/listinfo/linphone-users
_______________________________________________
Linphone-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/linphone-users
