Sample rate from provider is 8060, not 8000

I am attempting to register a trunk in FreePBX to an extension in Zoom Phone.

It’s working like a champ, except for one little (but big) detail - the sample rate Zoom is sending is 8060, not 8000.

Some of my phones pass it just fine, others are passing it, but with slightly sped-up audio and a brief dropout exactly every 11 seconds.

I know the 8000 Hz sample rate is an industry standard, but is there any way to adjust this or resample the audio in FreePBX or under it in Asterisk? Zoom is very consistent with the 8060 Hz sample rate.

Asterisk won’t even negotiate if it’s not 8000, so are they negotiating it as 8000 and sending it as 8060? How are you determining 8060?

Strictly speaking, the process is not negotiation. They are required to either send at the rate that Asterisk specified in its SDP, or reject the codec, or the whole media stream. Even if they sent 8060 in their SDP (for which Asterisk would have to reject the codec), that is what they are prepared to receive not what they are offering to send (although it would be unusual to offer to receive only at a rate that you weren’t prepared to send.

There’s no mention of non-standard sample rates on although there is a choice of codecs, so it might be useful to know which.

That sounds to me like the sampling rate is too low, rather than too high.

The specific device I’m connecting is a broadcast phone system, manufactured by a company called Telos.

When a call is connected, the Telos equipment reports the sample rate of the call. If I’m making a call to or from a SIPStation trunk, the sample rate it shows is 8000. If I’m making a call to or from Zoom Phone, it shows something between 8060 and 8062. I have seen it fluctuate slightly between 8060, 8061 and 8062, but never anything outside that range when connected to Zoom. It is typically fairly stable at 8060.

This is a screen shot from a manual for a newer version of the product. It’s showing 4000 as the sample rate, but mine always shows 8000 on a SIPStation trunk and 8060 when connected to Zoom Phone.

Zoom Phone can do g722, g711 and Opus. The Telos phone system is compatible with g722 and g711. It doesn’t support Opus.

If I go to SETTINGS → ASTERISK SIP SETTINGS in FreePBX and select g722 as the only codec, everything works fine with the exception of the audio dropout every 11 seconds, and the call sounding like it’s slowing down at the start of the call.

If I select ulaw or alaw, the call will go through and I get some audio, but the call quality is awful. Completely unusable.

Of course, if Opus is selected, it doesn’t work at all. The phone system itself shows an error if you try to dial out.

Does Asterisk perhaps have any way to force audio to be decoded and re-encoded? That’s something I’d like to try if possible.

I’m not sure if it’s relevant to this issue or not, but Zoom Phone only supports SIP via TLS 1.2. The Telos system only supports SIP via UDP or TCP, so that conversion is taking place in FreePBX.

The codecs I’ve tried are Opus, g722 and g711 (ulaw and alaw) as those are the ones Zoom Phone supports.

The broadcast phone system only supports g722 and g711.

g722 calls sound good, except for the audio slowing down at the start of the call, and the dropout every 11 seconds thereafter.

Both ulaw and alaw sound terrible - horrible dropouts.

When I have Opus selected as the only codec in FreePBX, the phone system rejects the call.

BTW - this isn’t the conference room connector. I’m actually utilizing Zoom Phone, which is a cloud PBX service they offer which is very similar to RingCentral.

Interesting issue. Could you get a SIP trace that includes the invite request from Zoom Phone and also out to your Telos unit? It’ll be interesting to see whether the SIP includes these unusual rates.

As I read it, encryption is optional for the Connector product.

I can’t find any solid technical information on Zoom Phone, amongst all the marketing stuff, so can’t tell whether TLS is also optional for that.

If the A leg and B leg have different codecs, this will be inevitable. However Asterisk will not correct for media received at a rate that was not in its SDP offer. (If you “originate” a call, by default, both legs will be set up with slin codecs, which will result in both needing transcoding.)

A sample rate of 4,000 would not be understandable!!! With brick wall filters, you need at least 2.1kHz for technical communication use, but in reality you will need filter guard bands, and the sampling rate will need to be at least twice the bandwidth. I assume they have got them confused with passband, and forgotten that brick wall filters aren’t realistic.

That’s a great idea! I’m physically not with the system today, but will be back there tomorrow to investigate more and will report back.

The encryption isn’t optional for this product. I’d post a link to the page, but being a new user of the forum, it won’t let me post links. If you Google “zoom phone certified hardware” and select the first page from Zoom that comes up, you’ll find it.

This is being configured as a “Generic SIP Device” the same way the Spectralink DECT device, AudioCodes conference room and Konftel conference phone.

On thing I could use some pointers on is how I could set up FreePBX to connect to Zoom using Opus, then the extension device to connect using g722. It sounds like that would force transcoding and hopefully, eliminate the sample rate issue, possibly at the expense of some latency.

Transcoding will be done on the basis that the sample rate is the one that Asterisk offered to receive. Asterisk isn’t going to measure the average actual arrival rate and construct a rate adapter for that.

I don’t think you explained where your 8060 came from (especially as your symptoms suggest their rate is low, rather than high. I think it would be instructive to see the detailed contents of the RTP packets and the Wireshark, packet by packet, media stream analysis for them.

Edit: I did the screenshots backwards from what you want, but you get the idea.

You specify only the one codec in the extension, and only the other codec in the trunk.

Advanced tab of your pjsip extension:

Codec sub tab of your pjsip trunk.

1 Like

Thanks so much!

I actually started playing with this a bit earlier at the suggestion of the support team for our broadcast phone provider.

Interestingly, I’m finding not all codec combos are transcoding.

For example, if I put Opus on the trunk side and g722 on the extension side, it will transcode the audio. If I put Opus on the trunk side and ulaw on the extension side, it will not. The Yealink T33G phone I’m using to test with a sandbox FreePBX server at home says “not allowed here” when I try Opus to ulaw, but it goes through just fine if I put ulaw on both sides.

I can tell it’s transcoding from Opus to g722 though. If I plug in g722 on both the trunk and extension side, the audio has fewer coding artifacts with my test audio.

I’ve been working from home today, but I’ll be back in the studios with the broadcast phone system and I’m eager to see if transcoding from Opus to g722 resolves the issue.

It likely won’t matter, but I am a bit curious why I can’t transcode from Opus to ulaw and alaw.

Not every device will support every codec.

However I find it weird that anything would work with G.722 but not G.711 µ-Law. The CLI command “core show translation” will tell you the translation costs and therefore which codecs an be translated which other ones.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.