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
Hi The header fields should not be the reason that the reply is not processed. By default, kamailio should process the response even its content is something that the endpoints won't like.
If you can provide that SIP request and response (a packet capture may also be good), then it might be obvious to someone if something is wrong with it. Does your config file have anything in a reply route (sanity-checking, etc) that might be dropping the replies?
James
On Sun, 23 Feb 2025 at 07:15, 高秉寬 via sr-users sr-users@lists.kamailio.org wrote:
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
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Dear James,
Thank you for your response.
I have attached two packet capture (.pcap) files for reference:
- *success.pcapng* – A case where the call succeeds. - *failure.pcapng* – A case where the call fails with a 408 timeout.
For context, the relevant IP addresses in the captures are:
- *172.16.6.204* – Kamailio - *10.70.0.16* and *10.70.0.17* – The UEs
Regarding your question about the configuration file: To my knowledge, there is nothing in the reply route (such as sanity-checking) that would be dropping the replies. However, if you suspect something specific, I’d be happy to double-check.
Please let me know if you need any additional details.
Best regards,
Ping Kuan Kao
James Browne james@frideo.com 於 2025年2月24日 週一 下午9:21寫道：
Hi The header fields should not be the reason that the reply is not processed. By default, kamailio should process the response even its content is something that the endpoints won't like.
If you can provide that SIP request and response (a packet capture may also be good), then it might be obvious to someone if something is wrong with it. Does your config file have anything in a reply route (sanity-checking, etc) that might be dropping the replies?
James
On Sun, 23 Feb 2025 at 07:15, 高秉寬 via sr-users sr-users@lists.kamailio.org wrote:
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
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org
To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to
the sender!
It looks like PCAP does not contain all messages. No INVITE messages [image: image.png] Please record everything packets on the client's or Kamailio's side.
On Wed, Feb 26, 2025 at 8:33 AM 高秉寬 via sr-users < sr-users@lists.kamailio.org> wrote:
Dear James,
Thank you for your response.
I have attached two packet capture (.pcap) files for reference:
- *success.pcapng* – A case where the call succeeds.
- *failure.pcapng* – A case where the call fails with a 408 timeout.
For context, the relevant IP addresses in the captures are:
- *172.16.6.204* – Kamailio
- *10.70.0.16* and *10.70.0.17* – The UEs
Regarding your question about the configuration file: To my knowledge, there is nothing in the reply route (such as sanity-checking) that would be dropping the replies. However, if you suspect something specific, I’d be happy to double-check.
Please let me know if you need any additional details.
Best regards,
Ping Kuan Kao
James Browne james@frideo.com 於 2025年2月24日 週一 下午9:21寫道：
Hi The header fields should not be the reason that the reply is not processed. By default, kamailio should process the response even its content is something that the endpoints won't like.
If you can provide that SIP request and response (a packet capture may also be good), then it might be obvious to someone if something is wrong with it. Does your config file have anything in a reply route (sanity-checking, etc) that might be dropping the replies?
James
On Sun, 23 Feb 2025 at 07:15, 高秉寬 via sr-users sr-users@lists.kamailio.org wrote:
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
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org
To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only
to the sender!
-- Stay safe, 秉寬 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Hi
The SIP is in there, alright, but encapsulated in multiple layers. It's confusing to read that pcap, alright.
I used filter "gtp and ip.addr==10.70.0.16" in Wireshark. I see that the INVITE, the SIP-100 response, the SIP-183 response and the later CANCEL (and its response) all were encapsulated with IP, UDP, GTP, IP and ESP, but that the SIP-200 responses (frames 29, 31,35) to the PRACK were not (they have IP, UDP, GPT, IP, UDP and then SIP, but not the ESP). I don't see anything in the SIP that looks wrong to me, so it looks like a routing problem with whatever networking you have set up, and not actually any problem with SIP. That's my best guess.
Anyway, to troubleshoot further, you might add some logging to kamailio. Simply add an xlog to the very top of the onreply_route. If you see a log for the SIP-183 INVITE response but not for the SIP-200 PRACK response, then it shows that the SIP message does not even get to kamailio, which is my suspicion. If the message does actually get to kamailio (and my suspicion is wrong), then you might try setting the debug level high enough to see exactly what kamailio does with the response (and why it drops it).
James James
On Wed, 26 Feb 2025 at 06:49, Sergey Safarov s.safarov@gmail.com wrote:
It looks like PCAP does not contain all messages. No INVITE messages [image: image.png] Please record everything packets on the client's or Kamailio's side.
On Wed, Feb 26, 2025 at 8:33 AM 高秉寬 via sr-users < sr-users@lists.kamailio.org> wrote:
Dear James,
Thank you for your response.
I have attached two packet capture (.pcap) files for reference:
- *success.pcapng* – A case where the call succeeds.
- *failure.pcapng* – A case where the call fails with a 408 timeout.
For context, the relevant IP addresses in the captures are:
- *172.16.6.204* – Kamailio
- *10.70.0.16* and *10.70.0.17* – The UEs
Regarding your question about the configuration file: To my knowledge, there is nothing in the reply route (such as sanity-checking) that would be dropping the replies. However, if you suspect something specific, I’d be happy to double-check.
Please let me know if you need any additional details.
Best regards,
Ping Kuan Kao
James Browne james@frideo.com 於 2025年2月24日 週一 下午9:21寫道：
Hi The header fields should not be the reason that the reply is not processed. By default, kamailio should process the response even its content is something that the endpoints won't like.
If you can provide that SIP request and response (a packet capture may also be good), then it might be obvious to someone if something is wrong with it. Does your config file have anything in a reply route (sanity-checking, etc) that might be dropping the replies?
James
On Sun, 23 Feb 2025 at 07:15, 高秉寬 via sr-users sr-users@lists.kamailio.org wrote:
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
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org
To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only
to the sender!
-- Stay safe, 秉寬 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
-
James Browne -
Sergey Safarov -
高秉寬