Hi,
I am working on getting our new ATAs (Grandstream HT802) to work with our system with the Opus codec. I am relatively new to Asterisk so I will do my best to describe what I see happening. If you need any more information, please let me know.
It works fine if each endpoint is configured with ‘allow=ulaw’. Calls work between endpoints with direct media enabled as well. I have issues when using ‘allow=opus,ulaw’ or ‘allow=opus’. We have a SIP trunk that only allows ulaw so I would like calls between endpoints to preferably use Opus and fallback to ulaw for outgoing calls to the trunk.
We are using Asterisk 13.13.1 but I currently have installed the latest 13 branch from the Asterisk git repo. I read this issue: https://issues.asterisk.org/jira/browse/ASTERISK-26666 and thought it may have something to do with our problem. Unfortunately, the issue persists with this version.
I have tried several softphones to compare. X-Lite, Jitsi work with Opus. A softphone called Blind does the same thing as the Grandstream HT802. Others like the Grandstream Wave app for Android, do not send the /2 in rtpmap in the SDP so Asterisk ignores the request to use Opus. This is a different issue altogether though - I just want to get the ATAs to work.
I have an ATA bridged through my computer to capture packets through Wireshark.
I am calling a test number through our SIP trunk, ATA set to use opus,ulaw, trunk set to use ulaw, directmedia is disabled. In this scenario, I get one way audio; I do not receive audio back from the trunk to my ATA. Asterisk creates a native_rtp bridge for this call.
voip*CLI> pjsip show channelstats
...........Receive......... .........Transmit..........
BridgeId ChannelId ........ UpTime.. Codec. Count Lost Pct Jitter Count Lost Pct Jitter RTT....
===========================================================================================================
dbbf0e61 000b8296aec2-00000 00:00:19 ulaw 1774 12970 731 0.000 895 0 0 0.000 0.000
dbbf0e61 voipms-00000080 00:00:19 ulaw 905 0 0 0.000 887 0 0 0.000 0.000
voip*CLI> core show channel PJSIP/000b8296aec2-0000007f
-- General --
Name: PJSIP/000b8296aec2-0000007f
Type: PJSIP
UniqueID: 1484848484.130
LinkedID: 1484848484.130
...
NativeFormats: (opus|ulaw)
WriteFormat: opus
ReadFormat: opus
WriteTranscode: No
ReadTranscode: No
Time to Hangup: 0
Elapsed Time: 0h2m17s
Bridge ID: dbbf0e61-fbd5-4543-b090-c92504f5ce1f
voip*CLI> core show channel PJSIP/voipms-00000080
-- General --
Name: PJSIP/voipms-00000080
Type: PJSIP
UniqueID: 1484848484.131
LinkedID: 1484848484.130
...
NativeFormats: (ulaw)
WriteFormat: opus
ReadFormat: ulaw
WriteTranscode: Yes (opus@48000)->(slin@48000)->(slin@8000)->(ulaw@8000)
ReadTranscode: No
Time to Hangup: 0
Elapsed Time: 0h3m55s
Bridge ID: dbbf0e61-fbd5-4543-b090-c92504f5ce1f
Here is the SDP that is sent to Asterisk from the HT802 (with some sanitation):
v=0
o=000b8296aec2 8000 8000 IN IP4 {IP ADDRESS}
s=SIP Call
c=IN IP4 {IP ADDRESS}
t=0 0
m=audio 25838 RTP/AVP 123 0 101
a=sendrecv
a=rtpmap:123 opus/48000/2
a=fmtp:123 maxplaybackrate=16000
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16,32-36,54
And the debug log is getting spammed by:
[2017-01-19 13:16:14] DEBUG[24196][C-00000044] res_rtp_asterisk.c: Unsupported payload type received
[2017-01-19 13:16:14] DEBUG[24199] translate.c: Sample size different 960 vs 160
The weird thing though, is if I check the RTP stream on Wireshark, I can listen to the incoming audio. So the incoming stream is getting to my computer (and possibly the ATA) but it is not playing it. Wireshark shows my ATA send Opus and receiving back ulaw. I have tested other codec configurations and am able to receive a different codec than I am sending (such as g723 and ulaw). Edit: further testing shows that this last part might not be true.
If I disable native_rtp bridging (using “bridge technology suspend native_rtp”) I do get audio in both directions. So the problem appears to have something to do with that. Asterisk uses a simple_bridge in this case.
If I call using two HT802’s, both using Opus, directmedia=no, it works. If I do the same with directmedia=yes, I get no audio in either direction and the debug log shows:
[2017-01-19 13:22:51] DEBUG[24379] chan_pjsip.c: Oooh, got a frame with format of opus on channel 'PJSIP/000b8296aebb-00000082' when it has not been negotiated
Another weird thing is when I make a call from one endpoint (opus,ulaw) to another (g722,ulaw), the call appears to get converted to slin8000 to ulaw then to g722.
Endpoint 1:
NativeFormats: (opus|ulaw)
WriteFormat: g722
ReadFormat: opus
WriteTranscode: Yes (g722@16000)->(slin@8000)->(ulaw@8000)
ReadTranscode: No
Endpoint 2:
NativeFormats: (g722|ulaw)
WriteFormat: g722
ReadFormat: g722
WriteTranscode: No
ReadTranscode: No
Is there a way to keep the audio from converting to 8000 khz and keep it at a higher quality?
Thank you. Please let me know if you need any additional information.
Edit: After some more investigating, the issue might be because I am receiving a different codec than I and sending? Using native_rtp, my ATA sends Opus and receives ulaw back and refuses to play the audio. Other devices/softphones may support this though.
Does that make sense? Has anyone else experienced this?