Opus not working GS Wave to UCM 6202 1.0.18.12


#1

We upgraded our UCM6202 to 1.0.18.12 today. Then we downloaded the latest GS Wave (now with Video) app. Factory reset the UCM, created a SIP trunk to our proxy, created an extension, disabled all codecs and then added Opus. Did the same on the Wave app so that only Opus was allowed on both ends.

After we make a call, almost immediately the call hangs up and we’re looking back at the dialpad on GS Wave.
Syslog says (no surpises here): channel.c:5749: Unable to find a codec translation path: (gsm) -> (opus)

Which tells me that Opus isn’t really supported on the UCM. Or maybe it’s the Wave. Or both.

Any clues?


#2

Do you think it possible that the Wave is unable to transcode? I am guessing that the call was made over cellular given the GSM reference and the W would rely on the horsepower of the cell CPU to transcode from GSM to Opus and that it doesn’t do that. What about Wi-Fi?


#3

Call was made on WiFi and it would be the responsibility of the UCM to do any transcoding. All I did was call into a queue with music on hold.


#4

True as you have stated, but where does the GSM come from when no GSM codec is enabled in the UCM, your proxy or the Wave? Hence, why i thought cellular.

If you enable a known working codec is there a reference to GSM?


#5

That’s kind of my point. Only Opus was selected as the codec on Wave and on the UCM so that’s the confusing part. I’m not even leaving the local network, not making a call to the outside world. Just Wave to UCM to a queue so I can test audio with music on hold in an empty queue.


#6

What does a wireshark show? What about direct extension to extension by-passing your proxy?


#7

I’m not being clear. We’re testing audio quality from Grandstream Wave app. So we took our UCM6202, upgraded it to 1.0.18.12 and factory reset it. We added one extension, for the Wave app. We added one queue and allowed it to be used while empty so it would play music on hold. We set the Wave app to use one codec and we set the extension to use one codec.

When PCMU is selected for both sides and we call the queue, everything is fine.
When G722 is selected for both sides and we call the queue, everything is fine.
When Opus is selected for both sides and we call the queue, the call drops and won’t connect.

The wifi access point and UCM are plugged into the same switch on the same internal network. No cellular service is involved as the phone running Wave is only connected via wifi. No SIP proxy is involved (though there is one configured on the UCM, it does not come into play here). This is strictly Cel phone -> Grandstream Wave -> UCM testing with no outside resources involved.

Our testing indicates that either the Wave app or the UCM are not properly implementing the Opus codec.

We do not currently have another device that we can test Opus->UCM with, but we may do so in a couple of weeks.


#8

We do not currently have another device that we can test Opus->UCM with, but we may do so in a couple of weeks.

Please download and run Linphone. Report your experience. Let’s see if changing the client helps.


#9

I now understand. The initial post did not indicate that the call did not involve the proxy.

I am dense as I did see that you indicated that the path never left the local.


#10

We may choose to test that way, but in the end it must work from GS Wave. Will test more on Monday.


#11

We’ve done some testing with a GXP2160. Connected to this same UCM. Same basic drill:

  • Activate all codecs on the extension on the UCM
  • Make a queue that allows callers when empty and plays music on hold (confirmed working)
  • Set all codecs on the phone to be Opus
  • Change the first codec to G722 - works (queue plays music)
  • Change the first codec to Opus - doesn’t work (call connects but plays nothing)
  • syslog shows the following two lines, repeated many times:
    • Unable to find a codec translation path: (slin) -> (opus)"
    • codec.c:364: Unable to calculate samples for codec opus

The last two lines is what we would expect if the UCM didn’t have an Opus coder/decoder installed. In other words, it seems to fail pretty miserably.

Is anyone successfully using Opus with a UCM6202 running 1.0.18.12?


#12

Remember all transcoding paths require a change to slinear (slin) between front-facing codecs. GSM is also sometimes used in place of slin.

That transcode path error is an asterisk-generated error that gets shown when a particular vocoder (codec parser) isn’t initialized/installed.

If you can run SSH commands on a UCM, run “core show translations recalc 10” to get it to print your translation matrix.


#13

Do you know some magic way to run Asterisk commands on a UCM? “core show translation recalc 10” is Asterisk. That doesn’t work on our UCM. Wish that it would…

And yes, we’re aware of the transcoding paths, which is why the real question is: " Is anyone successfully using Opus with a UCM6202 running 1.0.18.12?"


#14

I thought UCMs were asterisk based, so they don’t actually give you access to the asterisk CLI?


#15

A-hahahahahahaha!!! You funny!!! No. There is no direct access to Asterisk or its dial plan or any customizations or AGI. If it were, half the stupid answers I give people wouldn’t be required in the first place. They may be open source Asterisk based, but they are closed systems.


#16

No, OPUS does not appear to work.

Set up extension 1000 in UCM using a GXV3275 and both sides (UCM and phone) were set only with OPUS.

Called from extension to VM on UCM, phone connected, no audio and then a bye from UCM. correct.
image. Note that the BYE comes within 2 second of the ACK from the UCM. VM is enabled on the extension and the default greeting is longer than 6 seconds. I suspect that while I could not hear the audio, it was the result of the GSM recording method not being able to be transcoded into OPUS and hence the BYE from the UCM.

I then dialed in from a SIP Trunk, which is using G711u and G729. The phone and extension were left untouched with regard to OPUS being the only codec. Extension 1000 was the destination for the inbound route. The call was received by the UCM, but there was no attempt by the UCM to send the call to the phone. The UCM responded with a 488 which then caused the 2nd failover trunk to try which resulted in the same thing.

I then added a g711u codec to the extension and the 3275 and placed them as the 1st codec in the priority listing.

I repeated the same tests to call VM and using an inbound call from a SIP Trunk and both calls were made without issue.

I then took the same GXV3275 and configured it as an extension on a different make of PBX that also purports to support OPUS. Again, OPUS was set as the only available codec. I had no issues in using OPUS as it worked fine with the other make. You will note the BYE is from the phone when I hung-up, not from the PBX as was the case with the UCM.

image


#17

Thanks for that. We’ll open a ticket with @grandstream.


#18

My tests gave me Wave can work with Elastix using OPUS codec and can’t work with UCM. Wave starts RTP session and UCM keeps silence

%D0%B8%D0%B7%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5


#19

Thanks. We’ve opened a ticket with Grandstream.


#20

If it could help for solve I opened ticket #20170908090422 related also with this issue about an year ago. It’s still on hold.