[Top][All Lists]

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

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

From: damico
Subject: [Linphone-developers] Handling of marker bit during a rtp session
Date: Fri, 05 Sep 2008 18:22:59 +0200
User-agent: Mozilla-Thunderbird (X11/20080110)

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

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?



### 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 @@
-            if (session->inc_same_ssrc_count>SSRC_CHANGED_THRESHOLD){
+ if (session->inc_same_ssrc_count>SSRC_CHANGED_THRESHOLD || rtp->markbit == 1){

reply via email to

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