Running Asterisk 20.16.0
We are using the chan_websocket feature to stream audio to/from a websocket server. Things have been working great when we have a PJSIP endpoint using ulaw codec and the websocket server is using ulaw. We make this connection via the Dial command specifying everything with a codec of ulaw.
Running into a problem when we have an endpoint using G.722. Performing the same exact work.
I can see through the Asterisk debugging the
The codec_resample.so is present.
We’re able to play ulaw prompts, even perform ConfBridges of these G.722 channels with other calls using opus and even other ulaw calls.
Only thing we have found that we’re having problems with is the audio to the websocket server (using wss for security) is garbled.
Any thoughts on how to diagnose the issue or what the issue might be?
Dan
jcolp
February 10, 2026, 10:43pm
2
You’re going to need to state more clearly what the problem actually is and provide more detail.
What does garbled mean. Are you receiving ulaw at the same rate? If you connect through ConfBridge does it work or fail?
jcolp
February 10, 2026, 11:00pm
3
I would also suggest testing the latest version to double check as there were some changes to chan_websocket, the diff between 20.16.0 and latest is 1383 lines in fact.
Thanks Joshua. I will work on trying the latest.
One thing to mention.
The start of the audio flow is our WebSocket Server sending ulaw audio to Asterisk. We know that’s correct because it’s the same audio we send to Asterisk when the other side of the bridge (original caller was ulaw).
WebSocket developer is going to try to get me details on the audio Asterisk sends it (comparing when the original caller was ulaw vs g.722).
Caller (ulaw vs g722) comes in.
Dial internally uses the simple_bridge.
Audio from this simple_bridge to/from WebSocket (both directions) is not even close to understandable (quiet and really more like a quiet pop or some other noise) is what I hear.
Again, if it’s ulaw for the original PJSIP call, it’s perfect.
Best description I can give is it’s like the chan_websocket support is missing a check to see if it needs to resample from the simple_bridge to/from the websocket if the simple_bridge was slin16 but needs to downsample for ulaw to websocket.
Upgraded to 20.18.2 and still encountering the issue.
Decided to also try using an opus codec for the original caller (still Dialing chan_websocket where the codec is ulaw). It is also encountering the issue.
Not sure what data is needed for this.
[02/11 12:55:33.922] DEBUG[1769][C-0000000a] channel.c: Channel WebSocket/ISPAUL__1/0x7ff548041b20 setting read format path: ulaw → slin48
When it’s answered by the WebSocket server…
gjoseph
February 11, 2026, 7:31pm
7
How is transcode_via_sln set in asterisk.conf? The default is “yes”. I’m guessing “yes” because without it, the path would be direct between the two. Can you try with transcode_via_sln turned off? If it works, it might give me a clue.
No difference that I can tell.
[02/11 13:49:45.584] DEBUG[1577][C-00000002] chan_websocket.c: PJSIP/4370-00000001: WebSocket channel requested_’ _’
If you need more of the log, let me know.
gjoseph
February 11, 2026, 8:05pm
9
I think using opus is just going to confuse things so here are a few things to try…
Turn global debugging off but do a core set debug 3 chan_websocket.so
Have your websocket server just echo back the binary media websocket packets (not the text packets) and try ulaw phone to ulaw websocket to verify that everything is working. If you can, revert back from wss to ws and use wireshark to look at the packets and verify that the packets are the same in both directions. If that’s OK, switch to g722 for both the phone and websocket and try again. Then g722 phone and ulaw websocket.
Just FYI I been testing with g722 phones and ulaw websocket and it’s worked fine and I just re-tested it with the same result.
Thanks George.
That’s good news that you have been testing with g722 phones and ulaw websocket. May indicate a problem with our websocket server
gjoseph
February 11, 2026, 8:22pm
11
No prob. I’m done for the day but will be around tomorrow after about 6am GMT-7.
Additional information, the person who wrote our websocket server (that uses the secure websocket) indicated the g722 audio from the caller sent to the websocket ulaw codec is good. The ulaw codec audio sent back is the same regardless of original caller being g722 or ulaw, so it appears it’s something on the Asterisk side.
Here is what I setup on my own.
I have a simple websocket that I believe echoes only the binary packets.
ulaw phone to ulaw websocket audio works (both directions). What I say is what I hear back.
I’m not sure how to compare the packets sent/received in the tcpdump capture.
I am going to try to attach the asterisk debugging, an asterisk messages, and the tcpdump files for all tests.
gjoseph
February 12, 2026, 4:19pm
13
If you wouldn’t mind, attach your test websocket app, a small dialplan fragment and any relevant config file fragments including the pjsip config for the phone so I can try and reproduce. What phone are you using BTW?
If you have something confidential you can PM me with it.
Sent a PM with additional files.
I forgot to include the tcpdump captures.
ulaw_to_ulaw_pcap.txt (427.8 KB)
g722_to_ulaw_pcap.txt (532.2 KB)
g722_to_g722_pcap.txt (277.7 KB)
Also, for a phone I am using PhonerLite.
system
March 14, 2026, 5:05pm
17
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.