If opus is the only codec selected all calls are busy; why is this?

Tags: #<Tag:0x00007f4f54310128> #<Tag:0x00007f4f543126d0> #<Tag:0x00007f4f5431fe98>

(Abc123) #1

If opus is the only codec selected all calls are busy; why is this?

I would like to use the “Opus” codec, and preferably only the opus codec if possible because I want the highest possible sound quality. Is this not possible? If I have ulaw/alaw, etc. selected, everything works perfectly fine but if I have only opus selected everything is busy. VM, calls between LAN phones, outgoing and incoming calls.

I guess that means the opus codec doesn’t work and therefore, since there is no functional audio codec, nothing will “create a call”, so to speak? So that means, I am guessing, that when I had opus at the top, and other codecs below it, they were bypassing opus altogether?

I want to use the absolute highest codec/audio quality possible. Is that opus? If so, can I use ONLY opus? If so, how come it isn’t working when only opus is selected?

Please explain it to me like I’m a golden retriever. Thanks very much.

(Abc123) #2

Also forgot to add, if it matters, I have a VVX500 phone “HDvoice” and a cisco 303. And latest stable versions of asterisk and freepbx.

(David55) #3

The Cisco 303 doesn’t seem to support Opus, assuming that https://www.cisco.com/c/en/us/products/collateral/collaboration-endpoints/small-business-spa300-series-ip-phones/data_sheet_c78-601648.html is the correct data sheet. I haven’t looked up the other devices.

If you restrict your choice of codec to Opus only and one of the parties doesn’t support it, you’ll either get a Not Acceptable Here response, and the call will never set up, or if the issue isn’t obvious until after OK is sent, you will get an immediate BYE from the device that doesn’t support Opus. Not Acceptable Here is likely to present as busy or congestion, although the log message about all devices actually reports all of busy, congestions, and unavailable.

General note: for any problem about the SIP protocol, it is useful to state that it is SIP, important to say whether you are using chan_sip or chan_pjsip, and likely t be important to provide the protocol traces produced by sip set debug on or pjsip set logger on. If my explanation doesn’t explain your problem, I think we will definitely need the traces.

(Abc123) #4

Yes, it appears you are correct. I searched the vvx500 and it says:

Codecs: G.711 (A-law and μ-law), G.729AB,
G.722, G.722.1, G.722.1C

so apparently neither phone supports opus. I also googled it and apparently carriers don’t support opus? Reading this reddit thread:
reddit com/r/VOIP/comments/852igt/will_carriers_ever_support_better_codecs/

It seems it’s relatively hopeless to expect better sound quality than the PSTN (crappy, imo) standards? I tried 722 and it seems a little better, but not that much, imo. Doesn’t that seem pretty pitiful, given G711 is almost 50 years old? A tiny bump, maybe? Or is it my hardware and I just need better?

P.S. It’s pjsip

(David55) #5

There is no point in carriers supporting codecs, other than G.711. unless lower bit rate, as they will, eventually use the PSTN for connectivity. In practice, no normal business supports direct routing of IP outside their extranet, because going through the PSTN is seen as more secure, but direct routing the domain in the SIP URI reflects the final destination, is the only way you will exceed G.711 outside a closed community.

(Abc123) #6

I see, so basically what you’re saying is that there’s no point in using a higher quality codec than 711, because it will be downgraded to 711 anyway on the pstn?

So, for someone like me where bandwidth isn’t an issue, and I want the highest quality calls, the only codec I should use is ulaw (g711)? Check that one single codec in asterisk sip settings and call it a day?

(R. Stindl) #7

Well…in german speaking Europe, g722 is widely used. The problem is that the cell phone carriers dont support it, they use other HD codecs. So if a call gets routed through the gateways of cell phone carriers, g722 gets downgraded to g711 and blown up again to a cell HD codec…which destroys any hd music on hold, of course :wink:
The Sangoma/Digium D6x phones support Opus, but you can only use it internally or on (IAX2-)trunks between two locations of a company.
Opus is not supported in the outside world…yet…but I might be wrong :wink:

(Simon Telephonics) #8

I would suggest you enable G722 and place it first, then G711. It may not be Opus, but it’s better, and if any transcoding happens the resource costs are negligible.

Opus is primarily a webrtc codec.

(R. Stindl) #9

…and g722 is terrible for music, by the way. Look at the file size and you will understand… :wink:

EDIT: I still dont understand, why we stream 4K-Netflix movies, but do not have the bandwidth for a decent audio codec, like sln16 or wav16!

(Abc123) #10

“EDIT: I still dont understand, why we stream 4K-Netflix movies, but do not have the bandwidth for a decent audio codec, like sln16 or wav16!”

Exactly! I don’t get people talking about “use this codec if your bandwidth isn’t great”… what? It’s 2021! An “uber HD” codec is, what, 10% of a single megabit? If that? If that is too much bandwidth then you’ve got MUCH bigger issues. Also, I get that in some outlier scenarios there could be some exceptions but generally speaking. Just about every device these days is connected to broadband. Most desk phones are by PCs that have gigabit LAN connections and 100 Mbps ISP connections (to start with). Most cell phones have 4G these days, and even the 2008 iphone had 3G, enough to make 30 “bandwidth intensive uber HD codec” phone calls simultaneously.

It just seems so ridiculous to me that we are still using 50 year old codecs. Nothing against you guys, of course. Thanks for your answers and I added 722 at the top. It does sound better, but barely. And I guess it won’t matter anyway, because any call not on my lan will be downgraded to 711 :frowning:. Thanks for the help everyone. Have a good day.

(R. Stindl) #11

It is not a problem of Asterisk/freePBX! Two Asterisk/freePBX machines can use any HD codec (IAX2 trunk). It is a problem of worldwide telephony standards! :wink:

EDIT: …although there is a problem with audio in the www, which is latency…audio-packets have to arrive in time :wink:

(Abc123) #12

Yep. Absolutely.

(Simon Telephonics) #13

The trunk type has nothing to do with it.

(David55) #14

I think this depends on where in the world you are. From questions I’ve seen on the Asterisk forum, there are parts of the world where bandwidth costs are still an important factor. I’ve seen people who really need to eliminate the protocol overheads of RTP.

(Also, although I doubt that telephony is a major contributor to global warming, using more bandwidth than you need does contribute to that.)

(R. Stindl) #15

Yes, you are correct…you can use any trunk. I just use IAX2 because I can connect two locations without any port forwarding and it’s 100% stable…and HD. I have no experience with other configurations, of course. Just an average user of freePBX :wink:

(R. Stindl) #16

again…we stream 4K-Netflix movies over mobile internet connections…how can the bandwidth be any limiting factor? :wink:

(R. Stindl) #17

…and in theory opus automatically adapts to the bandwidth. So there is no logic in not using a hd codec like opus in telephony…

EDIT: except if it doesn’t work…

(Jared Busch) #18

My codec order is always opus, 722, 711.
Life is good that way.

(Abc123) #19

It seems to me that having opus first (or at all) is pointless, though, isn’t it? Even the “latest and greatest” handsets with “HD voice” e.g. cisco’s 8861 $500 current gen phone:

Audio codec support ● G.711 a-law and mu-law, G.722, G.729a, Internet Low Bitrate Codec (iLBC), and Internet Speech Audio Codec (iSAC)

Don’t support anything better than 722. Again, there’s the one or two exceptions like mentioned above but basically ONLY if you’re calling your own local endpoints within your LAN with both handsets supporting opus (which 99% don’t, basically), right?

(Jared Busch) #20

is never latest nor greatest.