Summary: | ASTERISK-25832: chan_sip: "Unknown peer" registration error does not retry | ||
Reporter: | Matthias Urlichs (smurfix) | Labels: | |
Date Opened: | 2016-03-03 05:02:19.000-0600 | Date Closed: | |
Priority: | Minor | Regression? | No |
Status: | Open/New | Components: | Channels/chan_sip/Registration |
Versions: | 11.21.2 12.8.2 13.7.2 | Frequency of Occurrence | Frequent |
Related Issues: | |||
Environment: | any | Attachments: | |
Description: | SIP Registration does not retry after a 404 error.
This is the wrong thing to do in cases where the remote system uses a dynamically-generated SIP peer list and takes some time setting that up after a restart. I have noticed the problem with a Starface peer, which uses a Java/Tomcat front-end to Asterisk -- Asterisk starts up a lot faster than the Tomcat system, thus Asterisk has an empty SIP peer list until Starface is fully operational. Asterisk should wait a couple of minutes and then retry. | ||
Comments: | By: Asterisk Team (asteriskteam) 2016-03-03 05:02:20.607-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Rusty Newton (rnewton) 2016-03-03 16:34:54.138-0600 Thanks for the report and debug. However we also need protocol specific debug captured at the time of the issue. Please include the following: * Asterisk log files generated using the instructions on the Asterisk wiki [1], with the appropriate protocol debug options enabled, e.g. 'pjsip set logger on' if the issue involves the chan_pjsip channel driver. * Configuration information for the relevant channel driver, e.g. pjsip.conf. * A wireshark compatible packet capture, captured at the same time as the Asterisk log output. [1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Rusty Newton (rnewton) 2016-03-03 16:35:47.300-0600 In addition to the debug requested please attach an example of the registration and peer configuration. By: Asterisk Team (asteriskteam) 2016-03-18 12:00:01.636-0500 Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1]. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines By: Matthias Urlichs (smurfix) 2016-03-18 20:27:16.474-0500 Umm, pardon my ignorance, but why would you need a debug trace and configuration? It's pretty obvious from looking at chan_sip.c:handle_response_register() that receiving a 404 error immediately drops any further attempts ("Got 404 Not found on SIP register to service %s@%s, giving up") and de-registers the retry timeout. The test configuration for this consists of a single "register" entry in sip.conf, directed at a peer which doesn't know about us (obviously it needs "alwaysauthreject = no"). Observe exactly one attempt at registration and a resulting 404 error. That's trivial. Note that there is no peer configuration I could attach to this request. By: Asterisk Team (asteriskteam) 2016-03-18 20:27:16.686-0500 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable. By: Matthias Urlichs (smurfix) 2016-03-18 20:29:23.904-0500 I have updated the issue's title and initial description to clarify the problem. By: Rusty Newton (rnewton) 2016-04-08 12:19:47.993-0500 I had a developer look into it based on your comment and we've opened it up in our internal queue as well. Thanks! By: Eugene M. Zheganin (drookie) 2016-10-15 03:21:12.309-0500 I'm sitting on this issue with one of my voice providers (11.22.0 from my side). Once a week it rebuilds something in it's peer database, and whan this rebuild clashes with the SIP reregistration, I'm getting a 404 which * then never retries, and my trunk goes in the state "Rejected", and it's unuseable after this. Any chance this issue would be resolved ? Right now I'm using a nasty cron hack to check if there's a "Rejected" trunk to issue "sip reload" |