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, 秉寬
failure.pcapng
Description: Binary data
success.pcapng
Description: Binary data
__________________________________________________________ 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!
