RTP analysis jump in forward delta time

asked 2021-05-30 16:43:16 +0000

int-red
1 ●1 ●2

Hi, I am trying to find the cause for strange audio problems that we see sporadically at our Alcactel PBX. It sometimes happens that suddenly the external phone partner can not hear the audio from our PBX anymore. I captured some of the offending RTP streams and analyzed them with Wireshark. There I realized that the audio problem correlates with a jump in forward delta time - the forward delta time suddenly changes from 30ms to 40ms.

During the period where the forward delta time is 40ms the external partner can not hear the audio, although when I play the audio track in Wireshark the audio is played just fine. When the forward delta time returns to 30ms the external partner can hear the internal partner again.

Here a screenshot of the Wireshark graph: https://my.hidrive.com/lnk/3kmAFpiu

I read in other forum posts that a change in delta time can happen when silence filtering happens but in the RTP stream I see no markers for that.

Does anybody have an idea what is going on here? Any help or hint is appreciated!

edit retag flag offensive close merge delete

add a comment

4 Answers

Sort by » oldest newest most voted

answered 2021-06-10 09:53:04 +0000

int-red
1 ●1 ●2

updated 2021-06-10 09:53:22 +0000

Here my feed back to the cause and solution of the problem.

One thing I noticed in the pcap is that the provider does not send a ptime parameter in it's SDP packet. Only a maxptime parameter.

This was a good find! Also our support for the Alcatel PBX found this behaviour. This was the root cause of the problem!

None of the end points, neither or Alcatel PBX nor the other phone partner, did set a ptime parameter when establishing the SIP connection. Both sides did only specify a maxptime. Sometimes the other end of the call did not even specify a maxptime. This made the Alcatel PBX "think" it was free to choose and change the ptime as it saw fit.

The solution was to configure the Alcatel PBX for a fix ptime of 20ms

The answer of our VOIP provider about this was, that SIP/SPD is transparent. The part of the provider is only call transfer. The ptime is negotiated between the end points of the call and is not set by the provider.

edit flag offensive delete link

Comments

Thank you for the status update with the good news. Glad you were able to fix it and that my observations helped out.

BTW I tried to convert my comment to an answer and have this answer as a comment under it, so that the flow is right. But unfortunately that is not possible with our current system (the old one had that possibility)

SYN-bit ( 2021-06-10 15:37:03 +0000 )edit

add a comment

answered 2021-05-31 14:49:26 +0000

BigFatCat
31 ●2 ●88 ●4

Interesting capture. 192.168.22.247 sampling is 30ms and 195.185.37.60 is 20ms. The RTCP is reporting packet loss that is not in your capture. The drops are bursty. The IP ID are not sequential when the delay increases is >40ms and the marker bit wasn't set. This may not be the issue. The receiver can tolerate RTP packets a little early or late, but it may not like the jitter and may need to re-converge.

edit flag offensive delete link

Comments

I forgot to add the silence suppression is comfort noise with Voice Activity Detection (VAD). What happens when it doesn't detect any audio energy, it will tell the other end to insert comfort noise. When audio energy is detected, it starts sending voice packets. This slight delay causes the beginning of the audio to get clipped. If you think that is an issue, you can ask to have VAD disabled.

BigFatCat ( 2021-05-31 17:27:35 +0000 )edit

add a comment

answered 2021-05-31 08:55:45 +0000

SYN-bit

18344 ●9 ●301 ●255 https://SYN-b.it

Without the signalling and RTP seq+timestamps it's hard to say for sure. But it looks like a different packetization time (ptime) is used during the interval where the deltas are 40ms. Otherwise, the forward difference would have to be high during that interval too.

If you look at the difference between the RTP timestamps, is it 240 during the first part of the call and 320 during the interval of 40ms deltas? Was there any signalling involved at the start and end of the 40ms-delta interval?

I'm not sure whether changing the ptime during a call is allowed. Also, it could be that the other side just does not support 40ms ptime.

edit flag offensive delete link

Comments

Thank you for your quick feedback!

I don't see any RTP markers at the start or end of the 40ms-delta interval. see start for example: https://my.hidrive.com/lnk/wamAFJXQ

I also don't see any RTP packets around the the start or end of the 40ms-delta interval. But at the start there is a RTCP sender report when the ptime changes: https://my.hidrive.com/lnk/dYmgF6pS

and also at the end of the 40ms-delta interval: https://my.hidrive.com/lnk/oRGAFO1W

int-red ( 2021-05-31 09:37:26 +0000 )edit

It seems the RTCP packet at the start of the 40ms ptime interval is indicating ~11% packet loss experienced by the external phone partner. At the end of the interval 0% packet loss is reported. I assume your PBX is using these statistics to change the ptime to reduce overhead, but that the other party does not support ptime shifting or a ptime of 40.

Interesting capture, was it a test conversation that you are able to share as a pcap?

SYN-bit ( 2021-05-31 10:06:48 +0000 )edit

Yes, it was a test conversation - you can download it here: https://my.hidrive.com/lnk/TPGAFq68

I am also in contact with our provider and our Alcatel support if this 'I'm not sure whether changing the ptime during a call is allowed. Also, it could be that the other side just does not support 40ms ptime.' might be the cause of the issues. Thank you for that hint!

"is indicating ~11% packet loss experienced by the external phone partner" This also interesting - the paket capture at our WAN interface shows 0% packet loss in Wireshark analysis. So the packet loss must have happened somewhere externally.

int-red ( 2021-05-31 10:25:41 +0000 )edit

Thanks for sharing the pcap, it's interesting to see the behavior. Also it seems to take 1 RTCP packet with quite a bit of reported packet loss to change the ptime to 40ms and it takes 3 RTCP with 0% packet loss to change back to a ptime of 30ms.

I'm curious to what the provider will say!

SYN-bit ( 2021-05-31 12:18:56 +0000 )edit

add a comment

answered 2021-05-31 14:34:11 +0000

SYN-bit

18344 ●9 ●301 ●255 https://SYN-b.it

One thing I noticed in the pcap is that the provider does not send a ptime parameter in it's SDP packet. Only a maxptime parameter. Is that the case for all calls to this provider?

And regarding the packet-loss, have you enabled a QoS policy on the WAN interface to make sure EF marked packets will have priority when being sent to the WAN?

edit flag offensive delete link

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

RTP analysis jump in forward delta time

4 Answers

Comments

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

RTP analysis jump in forward delta time edit

4 Answers

Comments

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

RTP analysis jump in forward delta time