Summary: | ASTERISK-26281: chan_pjsip would send INVITE to 'Unreachable' endpoints | ||
Reporter: | Jacek Konieczny (jkonieczny) | Labels: | |
Date Opened: | 2016-08-10 05:36:46 | Date Closed: | 2017-06-07 08:12:59 |
Priority: | Major | Regression? | |
Status: | Closed/Complete | Components: | Channels/chan_pjsip |
Versions: | 13.10.0 13.11.0 | Frequency of Occurrence | Constant |
Related Issues: | |||
Environment: | Attachments: | ||
Description: | chan_sip would not send INVITE requests to peers known to be unreachable (via the qualify 'pings'). I would expect the same from chan_pjsip, but it doesn't work this way.
Even if an endpoint is considered 'Unreachable' (as shown in 'pjsip list endpoints'), but a contact is available (preconfigured or REGISTERed), Asterisk would send INVITE and report 'channel unavailable' error only after the request times out (32s by default). This is way too long for a good user experience. | ||
Comments: | By: Asterisk Team (asteriskteam) 2016-08-10 05:36:47.237-0500 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-08-10 17:38:47.256-0500 Yeah I see the same behavior. I can think of some reason why we might want it this way, but I'm not sure if it was intended or not. I'm going to chalk it up as a bug for now. By: dimitripietro (dimitripietro) 2017-04-23 08:58:24.959-0500 Hi Rusty, Is there a workaround to have the same behavior as chan_sip ? By: Rusty Newton (rnewton) 2017-04-25 15:19:52.077-0500 Dialplan. I'd say check the status of an endpoint before you dial it. Don't dial it if the status is unreachable or unavailable. There are a variety of functions and applications you could use in concert. Lots of people on https://community.asterisk.org/ or the asterisk-users mailing lists can help you out with that sort of scenario. In fact if you search you'll probably find examples or conversations about this sort of configuration. By: Joshua C. Colp (jcolp) 2017-06-01 16:59:43.264-0500 [~rnewton] Sup bro. By: Friendly Automation (friendly-automation) 2017-06-07 08:13:00.268-0500 Change 5752 merged by Jenkins2: res_pjsip: Add support for returning only reachable contacts and use it. [https://gerrit.asterisk.org/5752|https://gerrit.asterisk.org/5752] By: Friendly Automation (friendly-automation) 2017-06-07 08:31:15.421-0500 Change 5753 merged by Jenkins2: res_pjsip: Add support for returning only reachable contacts and use it. [https://gerrit.asterisk.org/5753|https://gerrit.asterisk.org/5753] By: Friendly Automation (friendly-automation) 2017-06-07 08:35:28.746-0500 Change 5754 merged by Joshua Colp: res_pjsip: Add support for returning only reachable contacts and use it. [https://gerrit.asterisk.org/5754|https://gerrit.asterisk.org/5754] By: Friendly Automation (friendly-automation) 2017-06-07 10:31:34.766-0500 Change 5755 merged by Jenkins2: pjsip/qualify/call_unreachable: Add test for calling unreachable endpoint. [https://gerrit.asterisk.org/5755|https://gerrit.asterisk.org/5755] By: Friendly Automation (friendly-automation) 2017-06-08 09:46:42.476-0500 Change 5780 merged by Jenkins2: pjsip/qualify/call_unreachable: Fix user event. [https://gerrit.asterisk.org/5780|https://gerrit.asterisk.org/5780] |