Dear Kamailio Developers,

I am using Kamailio as a SIP server to facilitate a phone call, but I am encountering an issue where the call cannot be established due to Kamailio sending a 408 Request Timeout to the caller.

Issue Details:
A (Caller) sends an initial INVITE to Kamailio, which then forwards it to B (Callee). The INVITE contains the following `Supported` header:

Supported: timer,100rel,replaces,precondition,from-change,histinfo,tdialog

I suspect the precondition option may be relevant to the issue.

B responds with a 183 Session Progress message, which includes:

Require: 100rel,precondition

Kamailio correctly forwards this response to A.

A then sends a PRACK request to Kamailio. However, this request contains:

Require: sec-agree
Supported: timer

Notably, precondition is absent from both the Require and Supported headers.

Kamailio forwards this PRACK to B, and B responds with 200 OK, including:

Supported: 100rel,from-change,tdialog

However, Kamailio does not seem to acknowledge B's 200 OK and instead keeps retransmitting the PRACK to B. B responds with 200 OK again, but the cycle repeats.

After three retransmissions of PRACK, Kamailio eventually sends 408 Request Timeout to A, leading A to send a CANCEL request.

Device Used:

Caller (A): Asus ROG Phone 5
Callee (B): Asus ROG Phone 6

Both are commercially available mobile phones.

Possible Cause:

According to 3GPP TS 24.229, Subclause 5.1.3.1,

If the received response with an SDP body includes a Require header with the "precondition" option-tag, the originating UE shall include a Require header with the "precondition" option-tag in responses with an SDP body to subsequent requests that include an SDP body and include the "precondition" option-tag in either the Supported or Require header field received in-dialog.

In this case:

The 183 Session Progress from B contains Require: precondition.
The subsequent PRACK from A does not include precondition in either Require or Supported.

Could this mismatch be the reason Kamailio keeps retransmitting PRACK and ignoring B's 200 OK? Or could there be another factor causing Kamailio to behave this way?

If additional details are needed, please let me know.

Best regards,
Ping Kuan Kao

Issue Details:A (Caller) sends an initial INVITE to Kamailio, which then forwards it to B (Callee). The INVITE contains the following Supported header:

Supported: timer,100rel,replaces,precondition,from-change,histinfo,tdialog

Device Used:

Possible Cause:

Issue Details:
A (Caller) sends an initial INVITE to Kamailio, which then forwards it to B (Callee). The INVITE contains the following `Supported` header: