SIP Under WSS with WebRTC Register but keep UNREACHABLE

Im using JSSIP version 3.10 and Asterisk 20 to authenticate an SIP over WebRTC. The problem is: When i make the register to my asterisk server using “ws” it works perfectly fine but when i use “wss” the JSSIP says it’s registered but in asterisk itself it keeps “UNREACHABLE” and this message keep shown:
chan_sip.c:4356 __sip_reliable_xmit: Serious Network Trouble; __sip_xmit returns error for pkt data

The SSL certs has been generated by LetsEncrypt and its fully working and i copied them to /etc/asterisk/keys and gave them 750 perm and chown to “asterisk” role. The proof that the certs are working is that if i type in my browser: “https://MY_DOMAIN:8089/ws” it returns: “426 - Upgrade Required” and the browser recognize the cert.

My http.conf is this:

[general]
servername=Asterisk
enabled=yes
bindaddr=0.0.0.0
bindport=8088
tlsenable=yes
tlsbindaddr=0.0.0.0:8089
tlscertfile=/etc/asterisk/keys/fullchain.pem
tlsprivatekey=/etc/asterisk/keys/privkey.pem

My general sip.conf:
[general]
bindaddr=0.0.0.0
bindport=5060
transport=udp,tcp,ws,wss
nat=force_rport,comedia
tlsenable=yes
tlsbindaddr=0.0.0.0:5060
tlscertfile=/etc/asterisk/keys/fullchain.pem
tlsprivatekey=/etc/asterisk/keys/privkey.pem
allowexternaldomains=yes
#include sip_trunks.conf
#include sip_endpoints.conf

My peer:

[204]
type=friend
context=MY_CONTEXT
username=204
secret=MY_PASSWORD
host=dynamic
nat=force_port,comedia
canreinvite=no
disallow=all
allow=ulaw,alaw,opus
qualify=yes
qualifyfreq=60
rewritecontact=yes
encryption=no
avpf=yes
icesupport=yes
dtlsenable=yes
dtlsverify=fingerprint
dtlssetup=actpass
dtlscertfile=/etc/asterisk/keys/fullchain.pem
dtlsprivatekey=/etc/asterisk/keys/privkey.pem
directmedia=no
rtcp_mux=yes

And this is how im configuring my JSSIP:

let dados_aut_split = usuario.value.split('@')
let num_ramal = dados_aut_split[0]
let realm = dados_aut_split[1]
const socket_ramal = new JsSIP.WebSocketInterface(`wss://${realm}:8089/ws`);
const configuration = {
    sockets: [socket_ramal],
    uri: `sip:${usuario.value}`,
    password: senha.value,
    mediaConstraints: { audio: true, video: false }
};

ua = new JsSIP.UA(configuration);

Is there anything i could be doing wrong? i also could share some sip logs and other stuffs
PS: Im running a server inside AWS Infrasctructure and im already allowed the following ports over TCP/UDP: 10000-2000, 8088, 8089, 5060-5070

Execute permission isn’t sensible. Unless your certificate update mechanism requires more generous access, I’d suggest user nobody, group asterisk, mode 640, although only private keys need world restrictions. Actually, mode 240 might be even better.

chan_sip is obsolete. I’m pretty sure that mixing wss and other protocols is inadvisable. You have a typical cut and paste sip.conf peer definition.

You told me about CHAN_SIP be obsolete and yea i know it is but in my specific case i still need to use it. i changed the permissions to 640 like you said and restarted asterisk but the problem still. I could send you some sip logs if you want

What is Asrterisk re-writing the contact as?

You have qualify=yes, this is fine, but what it will do is send an OPTIONS message to the contact as soon as its registered. If it doesn’t reach this endpoint it will mark it as UNREACHABLE. This attempt at sending this options packet is also the source of the __sip_reliable_xmit:... error. Now your ws client will think you are still registered (it will have no reason to believe otherwise), but asterisk is marking it as unreachable.

Okay so what you told me is that the “OPTIONS” package not reaching my JSSIP application for some reason and this is why asterisk set it to Unreachable. I understand it but what i can’t understand is that if i change my JSSIP appointing it to a “ws” Instead of “wss” it works and the peer becomes reachable without any problem. At beginning i thought it could be a cert issue (im using a Lets Encrypt valid cert) but i have other applications running in my server and they are working with my cert. Do you want me to send you some sip logs about my registration request (i don’t know if that helps in this specific case btw)
About the Certs, LetsEncrypt generated me this files: cert.pem, chain.pem, fullchain.pem, privkey.pem
Im using “fullchain.pem” as tlscert and “privkey.pem” as tlskey

If you think it’s the SSL, just generate a self-signed on, and give it a try.

Otherwise, you need to see where and how the OPTIONS packet are being sent. Can you capture these messages from the CLI?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.