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 < [email protected]> 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 <[email protected]> 於 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 >> <[email protected]> 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 -- >> [email protected] >> > To unsubscribe send an email to [email protected] >> > Important: keep the mailing list in the recipients, do not reply only >> to the sender! >> > > > -- > Stay safe, > 秉寬 > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions -- > [email protected] > To unsubscribe send an email to [email protected] > Important: keep the mailing list in the recipients, do not reply only to > the sender! >
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- [email protected] To unsubscribe send an email to [email protected] Important: keep the mailing list in the recipients, do not reply only to the sender!
