Confusing RTP Issue With Endpoints Over VPN

[david55]

@ashcortech

When Asterisk logs “RTP forcing Marker bit, because SSRC has changed,” it’s indicating that it detected a change in the SSRC and, as a result, is setting the Marker bit in the RTP stream. This is likely done to signal to the receiving end (like a VoIP phone or gateway) that there has been a significant change in the stream, prompting it to handle the stream appropriately (like resetting any internal state linked to the previous SSRC).

This is the wrong semantics for the marker bit, and, at least in the past, caused some phone to garble the audio for some time. The marker bit indicates a safe place to dump the contents of a jitter buffer, and isn’t supposed to indicate a source change; that should be done by changing the SSRC on the outgoing side.

However, as I said, the problems we had with this were temporary garbling of the audio, not total loss of media.

[penguinpbx (C. Maj)]

@bholland

I did enable sip and rtp debug, but only for this specific extension.

Agreed on the RTP debug, but there is not much SIP debug. See the Message Details section 3.1 of RFC 3665 for an example:

   INVITE sip:[email protected] SIP/2.0
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
   Max-Forwards: 70
   From: Alice <sip:[email protected]>;tag=9fxced76sl
   To: Bob <sip:[email protected]>
   Call-ID: [email protected]
   CSeq: 1 INVITE
   Contact: <sip:[email protected];transport=tcp>
   Content-Type: application/sdp
   Content-Length: 151

   v=0
   o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
   s=-
   c=IN IP4 192.0.2.101
   t=0 0
   m=audio 49172 RTP/AVP 0
   a=rtpmap:0 PCMU/8000

Anything like that in your logs ?

@bholland

I can’t afford to globally enable debug and then wait for this to happen. That resulted in a 4GB text file.

There’s probably a lot more answers to the log rotation questions on something like Stack Overflow vs. the FreePBX forums, but here’s a couple of ideas:

• Set up a new limited SSH account on your logging server with a cronjob running on your PBX server to rsync the data over X times per day.

• Attach a $10 128GB USB thumb drive to your physical PBX server, mount it, and have the cronjob rsync stuff there.

@bholland

I’m not completely understanding what you are saying by calling the trunk via an IP address.

This line:

[2023-12-28 13:17:39] VERBOSE[371][C-00003575] app_dial.c: Called SIP/172.16.99.24/2072270

Should look more like this:

[2023-12-28 13:17:39] VERBOSE[371][C-00003575] app_dial.c: Called SIP/mytrunkname/2072270

You might be able to change the trunk name in the Connectivity → Trunks section of your FreePBX GUI.

@bholland

This call log was of the user making an outbound external call, however the same behavior has happened when a user makes an internal call to another user at the same location.

That is the confusing part. They could be unrelated issues. One thing at a time!

[bholland (Bryce Holland)]

OK, well you just helped reveal another configuration issue with this inherited setup. Believe it or not, that is the trunk name. I’m definitely going to have to change that.

According to what I have seen in the debug logs, it looks like Asterisk is not receiving RTP packets from the endpoint when this audio issue happens. As soon as the user calls back right away, then the audio is fine. Very odd.

[bholland (Bryce Holland)]

OK, I am going to ask this question on the forum of our router’s organization, but wanted to also ask an opinion here.

When we setup this new Wireguard VPN tunnel, the routers defaulted to a MTU of 1500. We were experiencing high latency issues at the time and learned from Wireguard documentation that the MTU should be 1420. We changed the MTU and things seemed to settle down.

However, do you think that wasn’t an issue, and changing the MTU could be causing this random RTP issue?

I have replaced another desk phone with a newer Polycom that can handle PJSIP. That user will let me know if the audio issues continue.

[penguinpbx (C. Maj)]

@bholland

However, do you think that wasn’t an issue, and changing the MTU could be causing this random RTP issue?

No, RTP media packets are small. However, fragmented SIP control packets over UDP eg. INVITE can get (much) bigger and cause problems if the router is breaking them up.

[garrett]

Wish I found this information sooner. Spent several days trying to figure out why calls would ring over a VPN but were not answerable (separate VLANs). Eventually I found the setting.

[bholland (Bryce Holland)]

My apologies to everyone for the delay in my reply / update. Anyone who works in the IT field knows how time can get away from you.

This situation improved after replacing the Wireguard VPN tunnel with an IPSEC tunnel. I’m not completely sure why, but maybe it can handle the older CHAN_SIP protocol better?

The greater influence has been the ISP infrastructure. Their internet connection stability has suffered due to new construction in the area and failed ISP equipment. So for now I am suspending my investigation until future decisions can be made with their Internet connection. It’s frustrating when a client suffers due to problems outside of your control. Time will tell.

Thank you again to everyone for virtually “putting your heads together” with me. You have helped me to troubleshoot a system that I inherited. I am being hopeful that future server and infrastructure upgrades will finally solve the phone audio issues.