FS skips an RTP timestamp after an RTCP Sender Report
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
participants (1)
-
David Witham