[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 2.0.0.9 (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
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] Handling of marker bit during a rtp session,
damico <=