Server's local IP address leaked to client.

Asterisk Asterisk WebRTC
1

Using asterisk 22.1.0, I’m trying to connect a pjsip device (103) using webrtc (JsSIP) through server’s public IP address 177.130.58.201.
After client is connected, server sends an OPTIONS message that includes the server’s local IP address in the “Via” clause after which my client only communicates through server’s local IP address 192.168.109.69 which it doesn’t have access to. how can I prevent this from happening? I want my client to always connect through the public address 177.130.58.201 and the local IP address not be leaked to the client. I’ve been struggling with this issue for weeks and I have already tried almost everything suggested on the internet.

this is my pjsip.endpoint.conf:
[103]
type=endpoint
aors=103
auth=103-auth
tos_audio=ef
tos_video=af41
cos_audio=5
cos_video=4
allow=ulaw,alaw,gsm,g726,g722
context=from-internal
callerid=103 <103>
dtmf_mode=rfc4733
direct_media=no
aggregate_mwi=yes
use_avpf=yes
rtcp_mux=yes
max_audio_streams=1
max_video_streams=1
bundle=yes
ice_support=yes
media_use_received_transport=yes
trust_id_inbound=yes
user_eq_phone=no
send_connected_line=yes
media_encryption=dtls
timers=yes
timers_min_se=90
media_encryption_optimistic=yes
refer_blind_progress=yes
rtp_timeout=30
rtp_timeout_hold=300
rtp_keepalive=0
send_pai=yes
rtp_symmetric=yes
rewrite_contact=yes
force_rport=yes
media_address=177.130.58.201
bind_rtp_to_media_address=yes
language=en
one_touch_recording=on
record_on_feature=apprecord
record_off_feature=apprecord
dtls_verify=fingerprint
dtls_setup=actpass
dtls_rekey=0
dtls_cert_file=/etc/asterisk/keys/default.crt
dtls_private_key=/etc/asterisk/keys/default.key
transport=wss

this is my pjsip.conf
[global]
type=global
user_agent=FPBX-17.0.19.23(22.1.0)
use_callerid_contact=no
debug=no
keep_alive_interval=90
endpoint_identifier_order=ip,username,anonymous,header,auth_username
external_media_address=177.130.58.201
external_signaling_address=177.130.58.201
external_signaling_port=8089
local_net=192.168.110.0/24

this is my pjsip.transport.conf
[wss]
type=transport
protocol=wss
bind=0.0.0.0:8089
external_media_address=177.130.58.201
external_signaling_address=177.130.58.201
external_signaling_port=8089
allow_reload=no
tos=cs3
cos=3
local_net=192.168.110.0/24
symmetric_transport=yes
,
this is how client’s communication with server look like:

sending message:
REGISTER sip:177.130.58.201 SIP/2.0
Via: SIP/2.0/WSS 177.130.58.201;branch=z9hG4bK1038080
Max-Forwards: 69
To: sip:103@177.130.58.201
From: “103” sip:103@177.130.58.201;tag=qp9050ejag
Call-ID: vck53h072qln78kbcqhpf8
CSeq: 17 REGISTER
Contact: sip:103@177.130.58.201;+sip.ice;reg-id=1;+sip.instance=“urn:uuid:f3a1ce42-7758-409c-a025-7f729928be07”;expires=600
Expires: 600
Allow: INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY
Supported: path,gruu,outbound
User-Agent: JsSIP 3.10.0
Content-Length: 0

received message:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/WSS 177.130.58.201;rport=1648;received=193.36.224.184;branch=z9hG4bK1038080
Call-ID: vck53h072qln78kbcqhpf8
From: “103” sip:103@177.130.58.201;tag=qp9050ejag
To: sip:103@177.130.58.201;tag=z9hG4bK1038080
CSeq: 17 REGISTER
WWW-Authenticate: Digest realm=“asterisk”,nonce=“1744727335/a5827a1cbd25ca085d597fc98821300a”,opaque=“5e59aac748a7c747”,algorithm=MD5,qop=“auth”
Server: Asterisk PBX 22.1.0
Content-Length: 0

sending message:
REGISTER sip:177.130.58.201 SIP/2.0
Via: SIP/2.0/WSS 177.130.58.201;branch=z9hG4bK6880735
Max-Forwards: 69
To: sip:103@177.130.58.201
From: “103” sip:103@177.130.58.201;tag=svaesq303t
Call-ID: oiq02v151qr9fu99goroki
CSeq: 2 REGISTER
Authorization: Digest algorithm=MD5, username=“103”, realm=“asterisk”, nonce=“1744717843/944fba63abe06624fd8ffcb15dcfba1c”, uri=“sip:177.130.58.201”, response=“50809088ab059688af9727298ac903d3”, opaque=“53e021d067ce436f”, qop=auth, cnonce=“4hgmvs244j30”, nc=00000001
Contact: sip:103@177.130.58.201;+sip.ice;reg-id=1;+sip.instance=“urn:uuid:137208e3-63e8-4e05-bcb8-84c50595e0ce”;expires=600
Expires: 600
Allow: INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY
Supported: path,gruu,outbound
User-Agent: JsSIP 3.10.0
Content-Length: 0

received message:
SIP/2.0 200 OK
Via: SIP/2.0/WSS 177.130.58.201;rport=64079;received=90.91.180.26;branch=z9hG4bK6880735
Call-ID: oiq02v151qr9fu99goroki
From: “103” sip:103@177.130.58.201;tag=svaesq303t
To: sip:103@177.130.58.201;tag=z9hG4bK6880735
CSeq: 2 REGISTER
Date: Tue, 15 Apr 2025 11:50:43 GMT
Contact: sip:103@177.130.58.201;transport=ws;expires=599
Expires: 600
Server: FPBX-17.0.19.23(22.1.0)
Content-Length: 0

received message:
OPTIONS sip:103@90.91.180.26:64079;transport=ws SIP/2.0
Via: SIP/2.0/WSS 192.168.109.69:8089;rport;branch=z9hG4bKPj92745890-4f59-479c-a218-1cc464386af0;alias
From: sip:103@PBX-Company;tag=9541f935-4f18-4570-81cf-39b14f2e6b0e
To: sip:103@90.91.180.26
Contact: sip:103@PBX-Company:5060;transport=ws
Call-ID: c12242c9-1641-4a78-a7e8-3d28e467b565
CSeq: 16845 OPTIONS
Max-Forwards: 70
User-Agent: FPBX-17.0.19.23(22.1.0)
Content-Length: 0

2

pjsip.*.conf are not referenced anywhere, so will be ignored, if this really is your configuration.

These, and probably some of the other settings are not valid in the type=global section.

In your logs, the device logging is a registrant for the REGISTER, and a server for the OPTIONS.

The Via has rport, so the UAS should use the actual source address, not the one in the Via (however, I’m not sure that Via is actually meaningful for WebRTC). I’m not sure if the local address in the Via is a bug, or is simply because it doesn’t apply to WebRTC.

Your log shows no response, rather than a failure to send one. Maybe the device doesn’t support OPTIONS and is broken, in that it doesn’t respond with an unspported method status. I’d try disabling qualify.

You have a raher large number of explicitly set options; that makes it more difficult to work out which ones may be causing problems,

3

JsSIP is an extremely common and widely used framework, I haven’t heard of a problem like this before. From the transport perspective it should just use the Websocket always.

4

Yes, sip messaging will leak you network path, that’s just how it works. Most of the time it’s only a problem because you know about the browser developer tools, and network websocket debugging… this, by the way, puts you in a 5% category of users. But yes, technically under instruction, any user could access the the raw sip messaging as you can.

There are really only two solutions here:

  1. Use Topography Hiding: This is when a proxy like OpenSIPS sit in between the ISP and the web users, and messages are manipulated to hide Via and Record-Route headers, and put into a contact parameter dialog-id (did).
    More information: openSIPS | Documentation / Tutorials-Topology-Hiding
  2. Asterisk as a Back-to-back User Agent. Asterisk can act as this “wall” between the user and the ISP. Asterisk would terminate the web users, and forward the calls onto the ISP (as a completely unrelated sip dialogue). You would have a bit of work to map the users-to-users, but it could be done.

Note: with the proxy route, the media would be allowed to flow end-to-end, with Asterisk it would have to relay (or transcode and relay), that would add another step in the media path.

More bedtime reading here: https://www.siperb.com/kb/article/does-webrtc-leak-my-ip-address/

5

In the Asterisk world, DID means PSTN number. The etymology is “direct in dialling”, but I consider that meaning has got corrupted, by the VoIP community.

6

Agreed, that’s why I used the lower case “did”, and used the full word “dialog-id” just before it, so that there would be no confusion. OpensIPS updates the Contact header to include an additional parameter e.g.;did=abc123 indicating that topography hiding has been used, and this id is referring to a hash table entry with the real headers, so onward sent messages get re-built.

Also, just to be clear on the original question here, where you mention: “server’s public IP address 177.130.58.201”, and then go on to describe very typical nat network “local_net=192.168.110.0/24”. This indicates that the server is not actually bound to the live IP, its bould to the local network and you are using NAT to have traffic forwarded to the server on its local network address.

This is fine, but you have a 3rd option to solve the question “how can I prevent this from happening?”

  1. You can bind the actual live IP 177.130.58.201 to the network card, and not have any local_net description. Just be sure to configure the system firewall first.