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

[damico]

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{