Feature Request: When an INVITE includes a private IP address in the SDP, send the response to the source IP

[mike-r-mclaughlin]

Problem Statement

Some SIP providers include a private IP address rather than a public IP address for the audio endpoint.
For example:

v=0
o=root 123456789 123456789 IN IP4 10.1.33.103
s=REDACTED PBX
c=IN IP4 10.1.33.103
t=0 0
m=audio 14264 RTP/AVP 9 8 0 3 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:140
a=sendrecv

When this is sent to LiveKit, the call will ultimately fail since that address is not routable.

Feature Request

Instead of failing, it would be great if LiveKit could instead detect this and send the RTP traffic back to the IP address from which the incoming packets originate.

[MatthiasGruba]

We have at least 1-2 customers a week with this problem on Starface and other PBXs - it'd be huge to get this solved! 🙏

[GianlucaP106]

This seems related, I’m planning to implement support for symmetric RTP (RTP latching) for us internally, where LiveKit would fall back to using the source IP/port of incoming RTP when the SDP address is not reachable.

Before moving forward, I just want to confirm this aligns with the scope of this issue. If so, I’d be happy to open a PR once it’s ready.

[mike-r-mclaughlin]

This seems related, I’m planning to implement support for symmetric RTP (RTP latching) for us internally, where LiveKit would fall back to using the source IP/port of incoming RTP when the SDP address is not reachable.

Before moving forward, I just want to confirm this aligns with the scope of this issue. If so, I’d be happy to open a PR once it’s ready.

that sounds related. cc: @nishadmusthafa

[IshanSingla]

@GianlucaP106
PR #624 looks like the right approach. One thing worth considering in the implementation: should symmetric RTP latching be enabled only as a fallback when the SDP contains an RFC1918 address, or always? Always-on latching is simpler but could cause issues with providers that send RTP from a different IP than the one they receive on (some load-balanced setups). A config flag or auto-detect based on RFC1918 check might be safer.

[GianlucaP106]

@IshanSingla Would making the option symmetric_rtp: "off" | "auto" | "on" be a suitable solution? In my case I need it always on. But like u said I can image the same scenario.