RTP Audio Packet Error: "Destination address required" on Janus SIP Plugin

General
1

I’m running the Janus server on macOS, and it’s configured to operate behind a firewall. When I initiate a SIP call, the phone on the other end rings successfully, but I cannot hear anything once I accept. I also encounter the following repeated error in the logs:

[SIP-bob23791] Error sending RTP audio packet... Destination address required (len=172, ts=16777216, seq=32)...[repeated]

I suspect this issue might be related to ICE negotiation or a misconfiguration in my RTP setup. I believe the audio is arriving on the Janus gateway but it is not able to forward the audio data to the WebRTC peer. I would appreciate any help confirming this theory. Here’s what I’ve done so far:

  1. Firewall Configuration:

    • I’ve configured my firewall to allow RTP traffic on the ports 20000-40000 (as specified in my Janus configuration). However, I plan to double-check this to ensure accuracy.

  2. Error Analysis:

    • Looking at the source code, the error seems to stem from a failed call to send(session->media.audio_rtp_fd, buf, len, 0).
    • This suggests that the RTP socket (audio_rtp_fd) might not be properly configured with a destination address.

  3. STUN/TURN Setup:

    • I’m using stun.l.google.com:19302 for STUN and turn.telnyx.com:3478 for TURN with the appropriate credentials.

  4. General Configuration:

    • The media section specifies rtp_port_range = "20000-40000".
    • The nat section includes behind_nat = true and local_ip = "192.168.1.44".

I’ve attached my configuration below for reference.

Questions:

  1. Is this error indicating that Janus is unable to reach the destination or that the destination is rejecting the packets?
  2. Could this issue arise due to misconfigured ICE negotiation or STUN/TURN settings?
  3. Are there specific logs or debugging steps I should check to confirm whether the RTP destination is correctly configured during the session setup?

Any guidance on resolving this issue would be greatly appreciated.

Attached Configuration:

configuration: https://pastebin.com/raw/4FtJsQVP
javascript code: Simple SIP Call

SDP:

Full SDP: answer v=0
o=FreeSWITCH 1734612520 1734612521 IN IP4 99.96.25.242
s=FreeSWITCH
t=0 0
a=group:BUNDLE 0
a=ice-options:trickle
a=fingerprint:sha-256 FD:9F:37:41:AC:43:4D:C7:2A:12:A4:C7:E5:34:65:19:E8:D6:F2:33:E9:74:58:BA:3D:9A:99:58:59:20:C7:F5
a=extmap-allow-mixed
a=msid-semantic: WMS *
m=audio 9 UDP/TLS/RTP/SAVPF 0 126 13
c=IN IP4 99.96.25.242
a=sendrecv
a=mid:0
a=rtcp-mux
a=ice-ufrag:eOXw
a=ice-pwd:NRu5ILGPP/IzeIN8KIfhNV
a=ice-options:trickle
a=setup:active
a=rtpmap:0 PCMU/8000
a=rtpmap:126 telephone-event/8000
a=fmtp:126 0-15
a=rtpmap:13 CN/8000
a=ptime:20
a=mid:0
a=msid:janus janus0
a=ssrc:3748659655 cname:janus
a=candidate:1 1 udp 2015363583 192.168.1.44 37542 typ host
a=candidate:2 1 udp 1679819263 99.96.30.125
37542 typ srflx raddr 192.168.1.44 rport 37542
a=candidate:3 1 udp 505414143 64.16.248.195 57471 typ relay raddr 192.168.1.44 rport 37542
a=end-of-candidates
m=video 0 UDP/TLS/RTP/SAVPF 0
c=IN IP4 99.96.25.242
a=inactive
a=mid:1

2

image
image2896×764 206 KB

image
image1618×1044 78 KB

Do you see anything wrong with the above picture?
I am running janus and the browser on my mac (So both the WebRTC peers are on the same network). Just to clarify - I’m actually able to make the phone call and my phone on the other end rings when I initiate a call from the browser.

3

ICE for sure has nothing to do with it: the error you’re getting is on a socket created by the SIP plugin, which does “raw” RTP oner UDP and doesn’t use ICE/STUN/TURN (those are only used on the WebRTC side). You should check the SIP INVITE and 200 OK, and the SDP they contain, to check what addresses and port were negotiated: if there’s no destination set, it may be the remote SDP doesn’t contain a valid address, or the SIP plugin couldn’t find it.

4

Thank you @lorenzo - Your comment was very helpful to guide me out of wrong rabbit holes.

The problem turned out to be a lot deeper, but it was related to me running it on my local computer and loading the file using file://siptest.html or http://127.0.0.1/siptest.html. I ran into a number of problems related to TLS certficates, Chrome not being happy with ws (rather than wss), and my local browser getting peers with mdns names and ports.

That was driving me crazy and so that next best option was to move all of this to a server with a domain name and it worked as expected. I learned a lot through this process but I have spent a total of three days with intense work trying to get into the weeds of exactly what’s happening.

Thanks again for your message Lorenzo - very much appreciate it.