Opus issues when in a bridge on DP750

bug
ip-communications

#1

Hi all,

Rather than necro an old post which seems to have similar issues (http://forums.grandstream.com/forums/index.php?topic=29580.msg87807#msg87807), we have issues with new DP750/720 devices when using Opus, but only when used in a bridge scenario.

We are using Asterisk 14.0.2 with the recently announced official Opus support. Our test environment is DP750 1.0.2.16 (upgraded from shipping firmware, same issue), Digium D40 2.2.0, Jitsi 2.8 and Android 6.0.1 native SIP stack, so a decent mix of hardware and software clients both with and without Opus support.

Opus to Opus without transcoding works perfectly - from Jitsi to GP750 and the other way.

If I force various codecs, Asterisk creates a basic bridge to transcode. I’ve forced this on various devices to see what happens. In the list below, first device is calling device and issue reports are from the perspective of the GP750.

Opus on Jitsi to g722 on D40 - works perfectly
g722 on Jitsi to g722 on DP750 - works perfectly
g722 on D40 to to Opus on Jitsi - works perfectly
g711 on Jitsi to g722 on DP750 - works perfectly
g722 on D40 to Opus on DP750 - buzzing on received audio, sent audio is audible but "distant"
g722 on Jitsi to Opus on DP750 - buzzing on received audio, sent audio is audible but "distant"
g711 on Jitsi to Opus on DP750 - buzzing on received audio, sent audio is audible but "distant"
Opus on DP750 to g722 on Jitsi - buzzing on received audio, sent audio is audible but “distant”

ERIC TAMME had a similar sounding issue in the post I referenced above but using FreeSWITCH in a bridging application, so this isn’t specific to Asterisk.

The issue is only apparent when transcoding Opus on the DP750. Transcoding any other format from the 750 (g711, g722 etc.) or doing Opus to Opus is fine and as I can transcode from Opus to anything on other devices, I can only conclude it’s an issue with the 750.

Is there any update on the bug raised by Eric? We’ve purchased these phones for their Opus ability but if we can’t transcode to another format, we can’t make calls to anything that doesn’t support Opus…

Please let me know if there’s any further information I can provide.

Best Regards,

Kev


#2

Hi Kev,
Could you please kindly enable syslog to debug level (syslog server can be whatever IP address) and use the packet capture tools in DP750 Web to capture all the traces and XML config file when you experience DP750 Opus issue?
Thanks you very much!


#3

Hi Shawn,

I’ve a PCAP, XML and user.log from syslog ready.

There might be some things in the logs I’d rather not attach to a public board - can I email them to you? I was going to attached them to a PM but it doesn’t seem to support that.

Cheers,

Kev


#4

Any news on this? Although I am not the author, I am the current maintainer of the original Opus transcoding module for Asterisk 13 and newer. And I still face similar symptoms with my DP750. The Opus audio send to the DP750 is not hearable in the handset at all. Direct G.722 works fine.

Even without transcoding, the audio send to the DP750 is not hearable, at least with CounterPath Bria for Google Android. Interestingly like Kev mentioned, Jitsi for Desktop and its Opus does work for me as well. Although not in all calls. In some calls, the audio is buzzing but understandable. I tested with 1.0.2.16 and the current beta (1.0.3.22).

Until this is resolved, I had to disable Opus-Codec in DP750 » Web interface » Profile » Audio settings » Vocoder Settings, be changing the Preferred Vocoder 8 to some existing value like G.722. That disables audio codecs. Thanks for that hint to the technical support.

@Kev, may I ask why you want to go for Opus Codec. The DP750 has to translate that anyway back to G.722 or G.726-32, because those are the audio codecs for DECT. I see no benefit to go for Opus Codec expect for bandwidth savings on the wire. Is there any additional benefit?


#5

1.0.3.22 have better support for OPUS than 1.0.2.16, you can try if the issue resolved on 1.0.3.22.


#6

I tested with 1.0.2.16 and the current beta (1.0.3.22).


#7

Did you test the DP750 and its Opus-Codec with Asterisk 13 or FreeSWITCH in the meantime? I would love to debug this, but I do not know where to start in the DP750. I do not see anything suspicious on the RTP layer. Looks like to be an issue on the Opec-Codec layer, the speech samples themselves. Is there a log, I could stare at?


#8

Hi Alexander and everyone,

Apologies for not noticing the activity on this ticket - I’ve not been on the forums lately as I opened a ticket for the issue with support. I’ve just popped on here as I’ve updated a site to the latest 1.03.23 firmwares with no improvement in Opus interoperability. I thought I would see if anybody else was trying to push Grandstream to fix it - I have a ticket number 20161018105949 open since October last year and all I get from it is “we’ll get an update from our engineering team”. So far, I’ve had nothing from this engineering team.

Grandstream Support - I’m calling you out on this one. There is a long list of bugfixes and feature enhancements, some of which seem quite pointless - UPNP discovery so there’s an icon to click on in a Windows Network that directs you to a webpage? Really? That is more important than fixing a 9 month old bug preventing an advertised codec fro working correctly? I’ve asked for this to be escalated a number of times and I’m getting nothing back. I’d appreciate a statement on this.

Anyway, enough ranting!

@Alexander: I disabled Opus on the SIP codec settings for the extension in Asterisk to make sure there was no way the DP750 could negotiate it. You are right in that I chose Opus to save bandwidth on the wire, we are using a cellular system to move the voice traffic. G726-32 is reported as being too muffled by our end users, same with G729 (as well as needing codec licensing). We ended up using G722 and the call quality is fine but there are some speech dropouts that are not evident when using Opus as well as needing more bandwidth. Incidentally, I have sporadic issues with iLBC on the DP750 too but I’ve not investigated this one too much yet.

The DP750 remains the only device we have issues with on Opus - we use Digium D60 and Jitsi everywhere else and so far, no issues at all.

We’re using Asterisk 14.2.1 with native Opus on this particular deployment. I’ve not tried native Opus on Asterisk 13 but I did try the add-in unsupported Opus in 13 with similar issues in a lab test.

If you manage to get any further with this, or if there’s anything I can do to help, please let me know :smiley:

Cheers,

Kev


#9

[quote=“kevlatimer, post:8, topic:16620”]we are using a cellular system to move the voice traffic[/quote]So, you are using the DP750 behind a cellular connection. Did I understand that correctly? In that case, you might be better off with a single-cell DECT solution which offers AMR-WB out of the box, like the current Panasonic KX-TGP6-series. Works so lala here.

Alternatively, did you ask Grandstream to get an AMR-WB enabled DP750? I really wonder how to get that as I would like to do interoperability tests with Grandstreams interpretation of AMR-WB as well.

In the extreme case and to avoid the license fee with AMR(-WB), you put a media-gateway (like an Asterisk on a Rasberry Pi) were your DP750 are located. In that gateway, you transcode between Opus and G.722.[quote=“kevlatimer, post:8, topic:16620”]if there’s anything I can do to help, please let me know[/quote]You could try to investigate the system-logging possibilities on a DP750. The issue happens while decoding on the DP750. Perhaps you, Grandstream, or somebody else is able to point me to to a log which might help. The next step would be using a Opus-Codec shared library on your sending device, which has debugging symbols enabled. That way, you are able to see in which state the Opus-Codec library itself is. That way, you could determine, what is so different between Jitsi – because Jitsi works at least sometimes.


#10

Hi Kev,
This issue has been fixed in our 1.0.4.x branch, 1.0.4.x have some major changes need a lot of testing to verify the stability, therefore, we didn’t release it yet and don’t have the plan to release it in coming future.
After read this post today, we will pull the fix to 1.0.3.x and hopefully release the firmware soon. I’m really sorry, Kev, I should respond you earlier in time, I forgot to follow up with you after we released 1.0.3.23. BTW, in case I missed a post again, you are welcome to send me messages via Forum which will send me notification email so I cannot miss that.


#11

Shawn, if you need an Alpha tester, please, do not hesitate to say so. As I am in full control of the Asterisk transcoding module, I am able to debug a lot – normally. Furthermore, I really would like to test your AMR-WB implementation as well. Is that a special license, I can add to my existing DP750? Or do I have to buy a different kind of DP750? If it is a different DP750, do you have a product/order number – so I can place a order via my reseller?


#12

Thank you so much Alexander,
DECT don’t have plan to support AMR-WB yet, I’m not sure the reason but it could be the license fee and very little benefit for customers. We will consider this if pulled by marketing department.


#13

Ahh. Then, I am sorry because misunderstood the data sheet which states ‘Voice Codecs […] AMR-WB (special order)’.


#14

You are right, we can do AMR-WB on special order but not on general firmware. Maybe there are some orders with AMR-WB supported just i don’t know. Will definetely contact you if we need help to test with it. Thank you very much!


#15

Hi,

Sorry to bring up an old ticket but I think this is still an issue for me.

I am using kamailio, rtpengine (git-master-c61d7f1), and ffmpeg 4.0.2 (tried git/master).

I get the ‘garbled voice’ effect on my DP750’s and I also have an WP820 which I don’t receive any audio on at all but audio is sent from the WP820 and heard on the remote phone.

If I go to options, call details, under receive I get packet loss rate: 100%, bit rate: 0Kbps, Codec: unknow

I think this might be a similar issue to this:

My WP820 is running System version: 1.0.1.15

If I use CSipSimple authenticated against the same kamailio instance and limited to opus I get two way audio without any problems.

I’m sure the packets are getting back to the phone and this happens even when they are on the same network.

Any clues?

Thanks,

Matt.


#16

Hi Matt,
What’s your device software version? Did you upgrade your DP750/DP720 to 1.0.4.10?


#17

I setup a DP750/720 today with my freeswitch server and set the dp720 to use opus for phone calls. When placing a call to any number (extension or external), the phone call audio is garbled and I can’t hear any audio.

That was with Version 1.0.3.37 and then I upgraded to 1.0.4.10, which results in the same inaudible call.

I don’t think freeswitch or my setup is the issue, because using a variety of softphones (bria, wave, groundwire), opus is set as the primary codec and bidirectional audio is heard clearly.

Is this pretty much what everyone else is also experiencing? Is there some kind of tuning that needs to happen within the web setup for the profile?


#18

Everyone whe has a do 720 never experienced issues setting up the opus codec before? No one has any guidance or suggestions?


#19

Even with 1.0.9.9, I still face the issue. It never changed for me. Would be cool if Grandstream would partner up because I am in full control of the Digium Asterisk and its Opus Codec module; I can patch and fix whatever they want.