No media when sip.js browser is receiver, using VPN

[smititelu]

Describe the bug I'm using basic SIP.js 0.19.0 Web.SimpleUser() typescript app, from chrome browser. When I start call from browser, all works. When I receive calls in browser, sip signalling works fine but I can't hear audio. I have a VPN setup where "private_ip" is VPN interface address and "public_ip" is STUN resolved address.

After debugging and comparing the signalling, I noticed this ICE candidate is missing from the browser's 200 OK, when browser is receiver. Note that the candidate is present in the browser's INVITE, when browser is sender and all works:

a=candidate:1234934969 1 udp 1686052607 "public_ip"59220 typ srflx raddr "private_ip" rport 59220 generation 0 network-id 1

My question is if you have any idea why in 200OK that candidate is not sent and what can I do about it?

To Reproduce (if possible) Web.SimpleUser() receiver using VPN interface.

Expected behavior RTP media to be sent over VPN interface.

Observed behavior RTP media is sent over local interface connected to wifi, not over VPN interface.

Environment Information

• Backend Server and version: kamailio 4.4, rtpengine 9.4.0.0
• Browser and version: Chrome Version 89.0.4389.90 (Official Build) (64-bit)

[james-criscuolo]

Full logs with sip trace please.

[smititelu]

Hi, I've attached console logs when browser is both sender and receiver.

sender.log receiver.log

[slachtar]

Hello, have you solved this problem? I'm facing similair issue and don't know how to fix it. I'm using v0.20.0

[smititelu]

Hi,

No, I didn't solve this problem.

Thanks, Stefan

[john-e-riordan]

Hi,

If this is still an issue, can you please send the receiver.log again with the UserAgent logLevel option set to "debug". There are a bunch of debug level messages which will indicate what is going on with ICE. It's apparently not spending any time waiting for candidates, so would just like to confirm it's just getting the 2 host candidates which are getting put in the SDP of the 200 Ok. If that's the case, then SIP.js is doing what it is supposed to be doing and this is a network/webrtc support issue and not a bug.

Thanks,

John