Hello : i am doing rtp analysis i see during stream analysis that there is large max delta in thousands but no jitter .. also has 1-3 percent packet loss and sequence errors. .. During the call, i noticed silence for few seconds so that equates to packet loss. but do you think large delta alarming? thanks
To see if comfort noise is send during periods of silence in a conversation a filter can be used in the pcap trace "rtp.p_type==13" will show if comfort noise is send, which means silence is not suppressed.
On the high delta RTP packets, is there a gap in the rtp sequence number? Is so, then there is data lost in transport. If the RTP sequence number just increased by 1, then the RTP source decided to not send some audio samples for whatever reason (SIlence suppression being the most probable cause).
There could be VAD (Voice Activity Detection) or Silence Suppression in play. Are there RTP markers at the points of the high delta times? If so, this could very well be the reason for your high delta times.
i checked the sequence no. and dont see any gaps. so in a nutshell high delta not necessarily a issue as long as sequence no. increments properly. basically i am analyzing the traffic with 200 ms latency(on vpn) vs 50 ms latency(no vpn) on ms teams.. any other pointers? thanks
When you look at the RTP streams using the tool: TELEPHONY > RTP STREAMS, and then click on the ANALYZE button after selecting your FWD/REV stream, do you see markers (look in the Marker Column) in the packets just before or at the packets with high delta times? If so, then this is most likely silence suppression mechanism at play.
It would make it a lot easier to assist with analysis if we had a capture to look at. If you are able to share one, you can always provide a link so some sort of cloud sharing location such as Google Drive, MS OneDrive, or Dropbox, etc.
please see attached file.
SSRC 0x0000d93a is very pristine with 0ms jitter and 0ms skew. The high delta times seem to be legitimate breaks in the sending of RTP packets as indicated by the sequence numbers, however it's a bit strange that the RTP profile doesn't make use of the marker bit to indicate the break.
SSRC 0x0000f588 has some issues. In addition to RTP breaks without the marker bit set, there is a significant amount of packet loss. Out of the total expected packets (18855), 196 packets didn't make it.
So yes, I believe that silence suppression is being utilized in the streams, but you also have legitimate packet loss in one direction of the sample you provided.
Asked: 2020-03-20 22:44:03 +0000
Seen: 4,055 times
Last updated: Nov 04 '20
