IP traffic routes

I have a webrtc setup running on AWS. The communication that what I see does not runs over the external networks but ICE returns the internal IP’s.

Now my traffic works as long as I’m on the VPN network. When I’m remote there is no traffic running.
For testing I use the cyber_mega_phone_2k projects and followed the guide from https://blogs.asterisk.org/2017/09/20/asterisk-15-multi-stream-media-sfu/

Additionally I set this:

; pjsip.conf
[transport_wss]
type=transport
bind=0.0.0.0
protocol=wss
external_media_address=34.xxx.xxx.xxx

[guest]
type=aor
max_contacts=5

[guest]
type=endpoint
context=default
direct_media=no
allow=!all,ulaw,vp8,h264
aors=guest
max_audio_streams=10
max_video_streams=10
webrtc=yes
from_user = guest
rewrite_contact=yes

[guest]
type=auth
auth_type=userpass
password=12345678
username=guest
; rtp.conf
icesupport=true
stunaddr=stun.nextcloud.com:3478

What am I missing in this setup to get the media running over the outside?

You can configure in rtp.conf replacements so that the public IP address are placed in as host candidates instead of the private:

[ice_host_candidates]
;
; When Asterisk is behind a static one-to-one NAT and ICE is in use, ICE will
; expose the server's internal IP address as one of the host candidates.
; Although using STUN (see the 'stunaddr' configuration option) will provide a
; publicly accessible IP, the internal IP will still be sent to the remote
; peer. To help hide the topology of your internal network, you can override
; the host candidates that Asterisk will send to the remote peer.
;
; IMPORTANT: Only use this functionality when your Asterisk server is behind a
; one-to-one NAT and you know what you're doing. If you do define anything
; here, you almost certainly will NOT want to specify 'stunaddr' or 'turnaddr'
; above.
;
; The format for these overrides is:
;
;    <local address> => <advertised address>
; 
; The following will replace 192.168.1.10 with 1.2.3.4 during ICE
; negotiation:
;
;192.168.1.10 => 1.2.3.4
;
; You can define an override for more than 1 interface if you have a multihomed
; server. Any local interface that is not matched will be passed through
; unaltered. Both IPv4 and IPv6 addresses are supported.

This traffic does not go over the websocket connection?

Will check the firewall tomorrow and give you feedback on this.

Media does not go over the websocket. ICE/STUN/TURN is used to establish a flow, and then SRTP is used for the transport of the media over UDP.

Just tried to open up the firewall and add the change for rtp as suggested.

When I look at my tcpdump I see the correct Ip address as the target of the UDP traffic but from my webclient (behind nat) I see unreachable in the dump:

20:02:48.886494 IP 10.253.125.201.50027 > 34.xxx.xxx.xxx.18002: UDP, length 128
20:02:48.958345 IP 34.254.92.243 > 10.253.125.201: ICMP 34.xxx.xxx.xxx udp port 18002 unreachable, length 164

The firewall allows all traffic at the moment (so no firewall enabled).

You’d need to further isolate and track it down. Where is that trace taken? If not on the VM running Asterisk, then do one there and see if the traffic is seen. Then double check the SDP (sip set debug on or pjsip set logger on depending on which SIP driver is in use) and see what is actually placed in it. The “rtp set debug on” CLI command will also show you media going in/out.

The trace was from the client (my laptop).
There is the pjsip trace: https://gist.github.com/johan-smits/c95791ce06cb3711d1b14c9d917880e3

The host candidate is still not correct, it has “172.17.0.2” as the IP address. The server reflexive was correct though, but otherwise you still need to isolate further.

Added the correct IP now and updated the gist with the new trace.

172.17.0.2 => 34.245.125.210

Yes, the host candidate is now correct but you still need to collect more information as I previously stated and isolate further.

Solved the problem. I had a typo in the firewall port that prevented the stream to the correct endpoint.
This typo and with your suggestions solved my issue. Thanks for the quick replies :+1: