TCP/TLS support for SIP signaling

[justin0mcateer]

It appears that the SIP adapter/service is currently hard coded to use UDP for SIP signaling. However, it appears the upstream library has support for TCP and TLS.

https://github.com/livekit/sip/blob/1ce2ec84ebf08f23d97febddb507f63d4cc21c6d/pkg/sip/server.go#L172

Would there be any aversion to adding optional configuration options to support other SIP signaling transports such as TCP and/or TLS?

[dennwc]

There's definitely a plan to support more protocols eventually (especially TLS!). But for now I want to focus on supporting one protocol and getting all core features in (DTMF in LK, better audio codecs, to name a few).

In the meantime, you could help out by making the PoC with these changes to check how invasive (or not) it will be. I will gladly review it!

It seems like we need a config option for choosing which protocols to listen on (for inbound), plus Trunks will need to accept addresses with a protocol in them (for outbound). Both should default to UDP if not specified.

[justin0mcateer]

I've looked at it a couple of times and it looks fairly simple. Sipgo is already loading support for all possible transports, it looks like the config and doing some branching on which listener configuration to use is the key thing to be handled.

However, we don't have anyone on our team who has any meaningful Go experience and we are pretty swamped with other work right now. We would be willing to sponsor this work if anyone is interested.

[dennwc]

Started working on TCP support.

[maik-parloa]

With UDP we are also experiencing issues with UDP fragmentation for SIP REFERs as sipgo limits to 1300 Bytes – which leads to issues with bigger SIP headers. TCP support would resolve this limitation / challenge as well.

[dennwc]

@maik-parloa We had the same issue recently, but unrelated to sipgo. SIP INVITE became larger than MTU and got dropped somewhere along the path. This is exactly why we want to prioritize TCP support now.

If it helps, as a workaround we made hostnames shorter and removed one code from SDP to fit packets inside MTU (while TCP is in progress).

[dennwc]

Initial support for TCP: #99.

[denyspozniak]

@dennwc If you look at the outgoing traffic from LiveKit SIP GW, you can see that the fragmentation prohibition flag is set (1.. .... = Don't fragment: Set). Probably this is configured somewhere in the libraries used.

Internet Protocol Version 4, Src: 10.10.10.10, Dst: 10.10.10.11
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 939
    Identification: 0xafb4 (44980)
    010. .... = Flags: 0x2, Don't fragment
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 63
    Protocol: UDP (17)
 

[maik-parloa]

@dennwc Is there a timeline to support TLS, and can we support it somehow?

[davidzhao]

this is on the roadmap for this month. :)

[alexHerrmio]

Thanks for merging! When can I expect to have TLS functionality in the livekit cloud environment ?

[dennwc]

Yes, we are working on it!

[alexHerrmio]

Thank you for the quick response, @dennwc! Could you provide us with a rough timeline for this? We’d like to conduct some latency tests using the LiveKit Cloud environment (with TLS) and have opted not to host an additional instance ourselves.