[Freeswitch-dev] Question about RTP marker

Tue Jul 3 20:45:59 MSD 2012

Hi there,
 Quick point -- if one changes the SSRC, one is going to so change to RTCP sender & receiver reports (and a few other bits).
Has anyone looked at the implications for the RTCP code of this change to SSRC?
Off the top of my head, changing SSRC if the stream changes IS a good idea, but the SR accumulators would need to be reset, and RR code needs to not barf if it receives a new RR SSRC.

all the best,
  Lawrence

On 3 Jul 2012, at 17:07, Peter Olsson wrote:
> Thank you for your replies, both Tony and Kristian - it made things a little bit clearer for me :)
> 
> I will submit a proposed patch to Jira later on (probably tomorrow), and you can review my changes there, it's a small change.
> 
> /Peter
> 
> -----Ursprungligt meddelande-----
> Från: freeswitch-dev-bounces at lists.freeswitch.org [mailto:freeswitch-dev-bounces at lists.freeswitch.org] För Kristian Kielhofner
> Skickat: den 3 juli 2012 17:33
> Till: freeswitch-dev at lists.freeswitch.org
> Ämne: Re: [Freeswitch-dev] Question about RTP marker
> 
> +1
> 
> The use of the RTP marker has been broken and misunderstood by many implementations...
> 
> The references the OP found about "talkspurts" are probably referring to the use of markers with VAD (voice activity detection).  When VAD detects speech the first RTP packet is supposed to have the marker set, almost as a way of saying "Hey! I'm talking again".  Of course with VAD a new talkspurt will also have a different timestamp...
> 
> FreeSWITCH (out of respect for jitter buffers, as Anthony said) tries to pass original (read: meaningful) timestamps and use markers wherever possible.  Consider the following scenario:
> 
> Call -> IVR (FS starts generating RTP)
> IVR -> bridge to external SIP device (device starts generating RTP)
> 
> In this scenario FS will generate the initial RTP stream with it's own timestamps.  When the call is bridged to the remote device FS will set the marker and pass the timestamps from the B leg to the A leg.  This allows the far end jitterbuffers (not FS) to buffer jitter based on the actual end to end RTP stream.
> 
> Unfortunately this can cause all kinds of confusion with broken implementations.
> 
> While changing the SSRC is (of course) a hack if it improves compatibility while maintaining the usefulness and integrity of timestamps (and jitter buffers) I'm for it.
> 
> On Tue, Jul 3, 2012 at 11:18 AM, Anthony Minessale <anthony.minessale at gmail.com> wrote:
>> The line is really blurry between what is right and what works better.
>> I think the only real rule about the marker bit is that you are 
>> supposed to set it any time the timestamp is not the next expected 
>> timestamp.
>> 
>> This is supposed to help you to understand that you are purposely 
>> sending a packet that has a different timestamp base or that you are 
>> resuming after intentionally not sending packets for a period of time.
>> This tells the remote end to flush its jitter buffer which probably 
>> explains the drop in audio.
>> 
>> If changing the SSRC is an acceptable workaround for when the rtp 
>> streams change that do not result in audio gaps, I'm more than happy 
>> to accept it as a default and we can always make it a config option if 
>> it presents any problems.
>> 
>> 
>> 
>> On Tue, Jul 3, 2012 at 9:39 AM, Peter Olsson 
>> <peter.olsson at visionutveckling.se> wrote:
>>> When I've been debugging RTP streams in Wireshark, I've noticed that 
>>> Whireshark will get "everything wrong" when the timestamp changes (is 
>>> reset). For instance, if I call a conference, by the time I get into 
>>> the conference, the RTP timestamps will start over, and FS will send 
>>> the marker bit By that time Wireshark will report strange figures for jitter etc.
>>> 
>>> 
>>> 
>>> After some Googling I've found that the meaning of the RTP marker is 
>>> to indicate "the beginning of a talkspurt". Which is not very clear 
>>> to me... :)
>>> 
>>> 
>>> 
>>> So my question is - is RTP marker really enough when starting a "new 
>>> RTP stream" (not really new, but since the timestamps are reset we 
>>> can think of it like that) - according to what I've been able to 
>>> find, maybe the SSRC should also be changed?
>>> 
>>> 
>>> 
>>> I have created a patch that will change the SSRC when a reset like 
>>> this occurs, and after that Wireshark detects my audio streams 
>>> without problems (though, it will detect more streams), but no strange jitter figures etc.
>>> are reported.
>>> 
>>> 
>>> 
>>> The reason I started digging into this was because a PBX I was 
>>> connecting to lost about the first second of audio after connecting 
>>> to the conference, after also changing the SSRC the problem seems resolved.
>>> 
>>> 
>>> 
>>> I could make a RTP_BUG setting for this, but I'm not really sure if I 
>>> should really care - that's why I'm asking here, if anyone has more 
>>> knowledge about this?
>>> 
>>> 
>>> 
>>> /Peter
>>> 
>>> 
>>> 
>>> 
>>> _____________________________________________________________________
>>> ____ Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>> 
>>>  
>>> 
>>> 
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://wiki.freeswitch.org
>>> http://www.cluecon.com
>>> 
>>> Join Us At ClueCon - Aug 7-9, 2012
>>> 
>>> FreeSWITCH-dev mailing list
>>> FreeSWITCH-dev at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de
>>> v
>>> http://www.freeswitch.org
>>> 
>> 
>> 
>> 
>> --
>> Anthony Minessale II
>> 
>> FreeSWITCH http://www.freeswitch.org/
>> ClueCon http://www.cluecon.com/
>> Twitter: http://twitter.com/FreeSWITCH_wire
>> 
>> AIM: anthm
>> MSN:anthony_minessale at hotmail.com
>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>> IRC: irc.freenode.net #freeswitch
>> 
>> FreeSWITCH Developer Conference
>> sip:888 at conference.freeswitch.org
>> googletalk:conf+888 at conference.freeswitch.org
>> pstn:+19193869900
>> 
>> ______________________________________________________________________
>> ___ Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>> 
>>  
>> 
>> 
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>> 
>> Join Us At ClueCon - Aug 7-9, 2012
>> 
>> FreeSWITCH-dev mailing list
>> FreeSWITCH-dev at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>> http://www.freeswitch.org
> 
> 
> 
> --
> Kristian Kielhofner
> 
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
> 
>  
> 
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
> 
> Join Us At ClueCon - Aug 7-9, 2012
> 
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
> 
> !DSPAM:4ff3106232761496470876!
> 
> 
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
> 
> 
> 
> 
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
> 
> Join Us At ClueCon - Aug 7-9, 2012
> 
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org