[Freeswitch-users] FS skips an RTP timestamp after an RTCP Sender Report

[David Witham]

Hi all,

Wondering if others have seen this. Running FS 1.6.20 on Debian 8 as B2BUA,
no proxy media. I'm not sure if this is a bug or whether its environmental
in some way. If we dig further and think it really is a bug we'll log a
proper bug tomorrow.

A call comes in interface A, does not have any RTCP packets. Call is
bridged to interface B which does contain RTCP packets. Same confg on both
sofia profiles. The RTP packet in the A->B stream immediately after the
RTCP packet sent by FS skips a timestamp, even though the sequence number
increments correctly.

e.g
Interface A packets
4.58 seconds RTP timestamp=855198950 seq=53269
4.60 seconds RTP timestamp=855199110 seq=53270
4.62 seconds RTP timestamp=855199270 seq=53271
4.64 seconds RTP timestamp=855199430 seq=53272

Interface B packets
4.77 seconds RTP timestamp=855198950 seq=20446
4.79 seconds RTP timestamp=855199110 seq=20447
4.80 seconds RTCP Sender Report
???
4.83 seconds RTP timestamp=855199430 seq=20448

In the above example, the packet with timestamp 855199270 does not appear
at 4.81 seconds as expected and the next packet contains the next
timestamp 855199430
but the sequence numbers keep incrementing normally. Its like FS has
dropped that packet internally. We can hear this as an audio artefact when
listening to the call.

In this case I don't think rewriting timestamps will help if the packet is
being dropped - we'll still hear the missing audio.

Secondly, in troubleshooting this issue, I've noticed that most of our
traffic does not contain RTCP packets, but some do and I can't seem to find
any rhyme or reason for this behaviour. Does anyone know why a call will or
won't contain RTCP? I had 2 calls in a minute go via 2 FS boxes running the
same config, same FS version, same A to B numbers and path through the
network and one had RTCP and one didn't. You'd think if the same CPE made
the same call to the same FS configuration (albeit a different physical box
on the same LAN segment), that you'd see the same behaviour.

thanks,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20180607/9fdf3a2e/attachment-0001.html>