linphone-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-developers] Handling of marker bit during a rtp session


From: Simon Morlat
Subject: Re: [Linphone-developers] Handling of marker bit during a rtp session
Date: Wed, 10 Sep 2008 23:58:21 +0200
User-agent: KMail/1.9.9

Hi Damico,

To me this is clearly an asterisk bug.
The sender of an RTP stream must not change SSRC, sequence number and 
timestamp numbering within a session.
The marker bit is set to indicate the beginning of a talkspurt, nothing more.
On cvs head it is fixed in audiostream.c by calling rtp_session_resync() upon 
detection of timestamp jump and ssrc changed (which is the case here).
Your patch can't be merged because as you said it breaks video because marker 
bit has a different meaning.
However you can avoid the one second delay by reducing the 
SSRC_CHANGED_THRESHOLD macro.
The stable linphone release is now too outdated. I'd like to make a new 
release but I have big problems connecting the website admin pages that 
prevents me from doing it.

Simon


Le Friday 05 September 2008 18:22:59 damico, vous avez écrit :
> Hi Simon,
> I'm using linphone and others voip phones with some asterisk's based
> registars. While I'm trying to work by a newer version of asterisk
> (1.4.20) I fond a new issue while conversations are placed in HOLD state.
>
> Yes, of course, I know that linphone doesn't handle the re-invite to
> check the hold state; but asterisk doesn't forward these transactions
> and replace the rtp stream with music or silence according to its
> configuration.
>
> Maybe you know yet what I'm writing, but I would like to spend some rows
> to clear the topic of that mail.
> The older asterisk (1.2.22) didn't change ssrc, sequence number  and
> timestamp while the conversations are placed in HOLD; but the newer
> versions use a different approach: when the hold stream is started the
> rtp stream is replaced with a new stream with a newer ssrc, sequence
> number and timestamp sources, the first packet of that stream has the
> marker bit set in order to indicate the beginning of a talkspurt.
>
> ORTP doesn't care the marker bit and :
> 1) discard the first SSRC_CHANGED_THRESHOLD [50] packets because have a
> different ssrc;
> 2) doesn't reset the fields of the section in order to have a new
> sequence and timestamp sources;
> 3) doesn't reset the jitter buffer in order to remove delay;
> Where 1 is either on CVS and in the last released version; but 2 and 3
> are fixed on CVS HEAD.
>
> The real issue is on the released version on linphone; but on the CVS
> HEAD ortp discard 1 second of stream where there are good packets.
>
> I took a look to rfc 3550/1 to see if that is a Asterisk's bug or a
> feature missed in ortp: IMHO, the rfc is not clear enough on that point
> "For applications which send either no packets or occasional comfort-
> noise packets during silence, the first packet of a talkspurt, that
> is, the first packet after a silence period during which packets have
> not been transmitted contiguously, SHOULD be distinguished by setting
> the marker bit in the RTP data header to one. The marker bit in all
> other packets is zero. The beginning of a talkspurt MAY be used to
> adjust the playout delay to reflect changing network delays.
> Applications without silence suppression MUST set the marker bit to
> zero."
>
> So, asterisk set the marker bit to 1 in order to inform the remote
> endpoint that is the "beginning of a talkspurt". Maybe there are some
> other methods to check a change of timestamp source of streams without
> using the marker bit.
>
> IMHO: that approach is on the borderline of the rfc but I think ortp
> could handle that with a little effort:
>
> I attach a simple patch for CVS HEAD that work for audio streams but I
> think that it could create some regressions for video streams (the
> marker bit has different means in video streams); I don't work with
> video but you can test it and change it to work with video.
>
> I fixed the release too but I think that you aren't interested on that
> topic.
> A question:
> where you have fixed that issue in HEAD? In jitter  control?
>
> Regards
>
> --Michele
>
> ### Eclipse Workspace Patch 1.0
> #P linphone_upstream
> Index: oRTP/src/rtpparse.c
> ===================================================================
> RCS file: /sources/linphone/linphone/oRTP/src/rtpparse.c,v
> retrieving revision 1.50
> diff -u -r1.50 rtpparse.c
> --- oRTP/src/rtpparse.c    22 Jul 2008 13:58:16 -0000    1.50
> +++ oRTP/src/rtpparse.c    5 Sep 2008 16:11:31 -0000
> @@ -136,7 +136,7 @@
>                  session->inc_same_ssrc_count=0;
>                  session->inc_ssrc_candidate=rtp->ssrc;
>              }
> -            if (session->inc_same_ssrc_count>SSRC_CHANGED_THRESHOLD){
> +            if (session->inc_same_ssrc_count>SSRC_CHANGED_THRESHOLD ||
> rtp->markbit == 1){
>                  session->rcv.ssrc=rtp->ssrc;
>                  rtp_signal_table_emit(&session->on_ssrc_changed);
>              }else{
>
>
> _______________________________________________
> Linphone-developers mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/linphone-developers






reply via email to

[Prev in Thread] Current Thread [Next in Thread]