Hi Alex, Thank you again for looking at this.
I am including a snippet of the last part of the Wireshark dump that occurs right before the dropped call. There are many of the very same INFO Request going from Asterisk to Kamailio; there is also another INFO request in the middle that was different (but only occurs a few times). The INFO Requests do have ;tag in the To header. I noticed that Asterisk replies '200 OK' to INFO request from Kamailio but Kamailio does not send '200 OK' for INFO requests from Asterisk. I did try forcing Kamailio to send a '200 OK' when it gets an INFO request, but that did not work. You will see that there are a bunch of INFO request to Kamailio from Asterisk, then Kamailio sends a 408 Request Timeout , then Asterisk send a BYE and call drops shortly after. Thank you!!, -Steve -----Original Message----- From: sr-users [mailto:[email protected]] On Behalf Of Alex Balashov Sent: Tuesday, February 6, 2018 8:34 PM To: Kamailio (SER) - Users Mailing List <[email protected]> Subject: Re: [SR-Users] Request Timeouts On Wed, Feb 07, 2018 at 01:31:43AM +0000, Wilkins, Steve wrote: > Hi Alex Thank you!, there is so much to learn. > > As you suggested, I looked at the CSeq and the Timeout is from an INFO > message going from Kamailio to Asterisk. Asterisk immediately sends > "BYE" back to Kamailio and then the call drops. This is why I was > wondering if I needed to do anything for INFO messages. "I think" > this is why some calls are dropping. Does this make any since? It does. Is the INFO message in-dialog[1] or out-of-dialog? [1] Does it have a ;tag attribute in the To header? -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ _______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Wireshark output- 112.1.32.97 => Asterisk 112.1.32.108 => Kamailio 100.9.312.174 => IP Address of Provider Client PC 12135431348 => Number the provider called (Note: this number connects to a webRTC Client in our Asterisk dial-plan) 20832 50.736901 112.1.32.97 34062 112.1.32.108 5060 SIP/XML 1008 Request: INFO sip:[email protected]:5060;alias=209.169.233.52~63368~2 | 20937 50.897839 112.1.32.97 5060 112.1.32.108 5060 SIP/XML 937 Request: INFO sip:[email protected];transport=ws;alias=100.9.312.174~60800~6;alias=100.15.188.174~60800~6 | 20832 50.736901 112.1.32.97 34062 112.1.32.108 5060 SIP/XML 1008 Request: INFO sip:[email protected]:5060;alias=209.169.233.52~63368~2 | 20832 50.736901 112.1.32.97 34062 112.1.32.108 5060 SIP/XML 1008 Request: INFO sip:[email protected]:5060;alias=209.169.233.52~63368~2 | ... ... ... Repeating many of this same "Request: INFO" but no other types of request messages ... ... ... 21975 52.123047 112.1.32.108 5060 112.1.32.97 34062 SIP 506 Status: 408 Request Timeout | 21977 52.123310 112.1.32.97 34062 112.1.32.108 5060 SIP 782 Request: BYE sip:[email protected]:5060;alias=209.169.233.52~63368~2 | Then call Drops Note: ;tag does exist in both the INFO request to headers (sip:[email protected]:5060, and sip:[email protected])
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
