[Home]

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-0600Date Closed:
Priority:MinorRegression?No
Status:Open/NewComponents:Channels/chan_sip/Registration
Versions:11.21.2 12.8.2 13.7.2 Frequency of
Occurrence
Frequent
Related
Issues:
Environment:anyAttachments:
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"