SIP reINVITE issue with IMS

[shirosh]

I'm from a Telco company. We have successfully integrated with LiveKit SIP via our NGN SIP trunk. But recently we have migrated from NGN to IMS ATS, since NGN is deprecated leagcy system. But It doesn't work properly. We have noticed IMS standard call flow send 2 SIP INVITEs.

The most probable reason for the immediate re-INVITE is one of two IMS-mandated features:

1. Session Timers (RFC 4028): IMS requires session timers as a keep-alive mechanism to prevent "hung" sessions if a device disconnects without sending a BYE.

How it works: The initial INVITE from the IMS will contain headers like Session-Expires: 1800 and Min-SE: 90. Your LiveKit server is expected to acknowledge support for this in its 200 OK response. The IMS node acting as the "refresher" will then send a re-INVITE (or UPDATE) before the timer expires to keep the session alive. If your call setup is fast, this refresh might happen very quickly.

2. QoS Preconditions Framework (RFC 3312): IMS mandates this to guarantee Quality of Service. It ensures network resources are reserved before the call is answered.

How it works: The initial INVITE will contain headers like Require: precondition and an SDP body with a=curr:qos none and a=des:qos mandatory. This is the IMS saying, "I want to set up this call, but don't connect the media or alert the user until you can guarantee the network quality." Your system is expected to perform resource reservation and then confirm it. This confirmation is often done via a re-INVITE to update the SDP and signal that the media path is ready.

NGN likely operated in a "best-effort" manner without enforcing either of these, so the simple INVITE -> 200 OK -> ACK was sufficient. IMS operates under a "guaranteed service" model, which requires these additional steps.

Could you please support us to enable these features. Because our all Livekit Agents going to be wasted because of this SIP connection issue.

[alexbakker]

I think there are three separate things to consider here:

• Support for RFC 3261 section 14. re-INVITE's are primarily used to renegotiate the media session after the dialog has been established (but can also be used to refresh a session). Based on my limited testing, it seems that in response to a re-INVITE, Livekit first sends a 100, followed by a 180, and then silence. A brief look at

  sip/pkg/sip/inbound.go

  Line 203 in eab98b2

  func (s *Server) processInvite(req *sip.Request, tx sip.ServerTransaction) (retErr error) {

  suggests that Livekit treats every INVITE as a new call, even if the request is in-dialog. This is something we have a temporary workaround for on our end, but it'd be nice if Livekit supported this.
• Support for RFC 4028
• Support for RFC 3312

[shirosh]

Recently we have migrated NGN SIP trunk to IMS. Now Livekit can handle SIP re-INVITE issue. Did Livekit released a fix?

[briankwest]

Here is the probable fix #582