I have an AI agent running on my local machine, and I use ngrok for establishing a connection. When I installed Asterisk on my AWS server and tried connecting Asterisk to my WebSocket, I faced an issue.
Here’s the configuration I’m using in Asterisk:
[ws-internal]
exten => _X.,1,NoOp(Starting the call with WebSocket URL)
same => n,NoOp(WebSocket URL: ${WS_URL})
same => n,AudioSocket(${UUID},${WS_URL})
same => n,Dial(SIP/digium/${EXTEN},30,T)
same => n,Hangup()
When I moved my WebSocket to the AWS server and used localhost:8000, everything worked perfectly (Not good because low GPU). However, when I switched to using ngrok (e.g., 7894-109-107-236-124.ngrok-free.app:80), it didn’t connect to the URL.
I suspect the issue might be related to SSL. What are your thoughts?
On Monday 30 December 2024 at 11:07:24, HazemMeqdad via Asterisk Community
wrote:
[Dec 30 09:53:45] WARNING[53476]: channel.c:5791 set_format: Unable to find
a codec translation path: (ulaw) → (g723)
Do you have support for the G.723 codec installed and working?
You said “When I moved my WebSocket to the AWS server and used localhost:8000, everything worked perfectly”, so this tells us that your
Asterisk setup on that machine is working as you want it to.
It would be good to know which codec gets used in this setup.
“However, when I switched to using ngrok (e.g., 7894-109-107-236-124.ngrok- free.app:80), it didn’t connect to the URL”
I am not familiar with ngrok, but I would start by checking to see whether the
working setup uses the G.723 codec, and if not, find out why the non-working
setup is trying to use it.
Antony.
–
What do you call a dinosaur with only one eye? A Doyouthinkesaurus.
On Monday 30 December 2024 at 12:04:23, Antony Stone wrote:
I didn’t ask about G.726 - I asked about G.723, and I do not see that in
the output you posted.
Hm, someone more knowledgeable than me regarding Asterisk’s codecs may be able
to confirm whether the G.726 codec can in fact handle G.723 input / output.
I just looked up some details and realise that G.726 is a replacement standard
for G.723 (and G.721).
Apologies for the ignorance / confusion.
Antony.
–
It is also possible that putting the birds in a laboratory setting
inadvertently renders them relatively incompetent.
Don’t worry. I’m not sure if the codec warning is related to the WebSocket connection, as my AI agent worked perfectly when hosted locally on AWS. What do you think?
On Monday 30 December 2024 at 12:30:04, HazemMeqdad via Asterisk Community
wrote:
Don’t worry. I’m not sure if the codec warning is related to the WebSocket
connection, as my AI agent worked perfectly when hosted locally on AWS.
What do you think?
Firstly, do you get the same codec warning in the logfile output in the working
configuration? If you do, then it’s reasonably safe to ignore it.
Secondly, you speculated that this might be an SSL problem, but I don’t see
where SSL comes into things, and I see no SSL messages (and certainly no
errors) in the output you’ve provided.
Thirdly, the URL you posted and said does not work was
“7894-109-107-236-124.ngrok-free.app:80” and the ending :80 makes me dubious
that this would be using SSL.
Maybe you’re saying that it should be using SSL, and the fact that it’s now
pointing at something on port 80 means that it isn’t? I have no idea what
protocol “localhost:8000” might use.
To dig deeper, I suggest pointing at localhost:8000 (which you say works, but
uses a lot of CPU) and capturing the network traffic to/from that service, and
then changing the setup to use the ngrok-free.app URL, capture the traffic
to/from that service on port 80, and see if anything stands out regarding the
difference.
Antony.
–
“Hi, I’ve found a fault with the English language and I need an entomologist.”
“I think you mean an etymologist.”
“No. It’s a bug, not a feature.”
Thanks, Pooh, for this information. I noticed a mistake on my port: I used port 80 instead of 443 (the SSL port). After correcting it, the call started successfully. However, something strange is still happening. Even though the logs indicate a successful connection, my local machine (ngrok logs) isn’t showing any connection attempts. What do you think could be the issue?
Here is the logs:
[Dec 30 14:45:46] WARNING[73631]: channel.c:5791 set_format: Unable to find a codec translation path: (ulaw) -> (g723)
[Dec 30 14:45:46] WARNING[73631]: channel.c:5791 set_format: Unable to find a codec translation path: (g723) -> (ulaw)
-- SIP/digium-0000000a is making progress
-- SIP/digium-0000000a answered
-- Executing [7865652168@ws-internal:1] NoOp("SIP/digium-0000000a", "Starting the call with WebSocket URL") in new stack
-- Executing [7865652168@ws-internal:2] NoOp("SIP/digium-0000000a", "WebSocket URL: b517-109-107-236-124.ngrok-free.app:443") in new stack
-- Executing [7865652168@ws-internal:3] AudioSocket("SIP/digium-0000000a", "37c701dc-66e6-4543-b440-8c0689e1e98a,b517-109-107-236-124.ngrok-free.app:443") in new stack
== Manager 'mark' logged off from 109.x.x.x
On Monday 30 December 2024 at 16:04:51, HazemMeqdad via Asterisk Community
wrote:
Thanks, Pooh, for this information. I noticed a mistake on my port: I used
port 80 instead of 443 (the SSL port).
Aha, so that was part of the problem after all
Even though the logs indicate a successful connection, my local machine
(ngrok logs) isn’t showing any connection attempts.
I’m now puzzled about what you mean by “local machine”. If this does not mean
the machine that Asterisk is running on, what is it?
Here is the logs:
I see nothing in there saying there’s a problem.
Maybe it related with protocol ws or wss?
Possibly, and for which someone else would need to assist, since I don’t use
these.
I still think a packet capture and analysing using something like wireshark,
might show what difference there is between the “localhost:8000” and the
“URL:443” connection attempts.
Antony.
–
Tinned food was developed for the British Navy in 1813.
