Summary:	ASTERISK-27668: PjSIP missing feature: Endpoint registration status
Reporter:	Samuel For (samfun)	Labels:	pjsip
Date Opened:	2018-02-12 05:19:14.000-0600	Date Closed:	2018-03-12 07:54:02
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Channels/chan_pjsip
Versions:	15.2.0	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:
Description:	We tried to migrate chan_sip to chan_pjsip but got stuck on a missing feature. In chan_sip: ${SIPPEER(endpointname,status) Yields the qualify status of the endpoint. This can then in turn be used to determine if we should call on the endpoint or not. There is no corresponding feature in chan_pjsip, at least we can't find it.
Comments:	By: Asterisk Team (asteriskteam) 2018-02-12 05:19:15.414-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: Joshua C. Colp (jcolp) 2018-02-12 05:23:06.466-0600 The general DEVICE_STATE dialplan function[1] can be used for this. Is there a reason you weren't using this even previously? [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Function_DEVICE_STATE By: Samuel For (samfun) 2018-02-12 05:30:57.669-0600 Hi, thanks for you reply. We might have misunderstood DEVICE_STATE but it feels like it is used to determine more or less if a device is on a call etc and not if the qualify=yes/qualify_timeout is yielding a positive or negative response? We use the SIPPEER to failover if an ITSP has a downtime (OPTIONS failing) of one of their several available IPs we could call on. By: Joshua C. Colp (jcolp) 2018-02-12 05:42:12.101-0600 The DEVICE_STATE dialplan function can be used to tell you that, but it also tells you if it is available or not. It is what is used internally by many things, such as ChanIsAvail (which is used for this as well). By: Samuel For (samfun) 2018-02-12 06:38:49.103-0600 So, if I understand you correctly, you are saying is that we should emulate the old behavior by categorizing: qualify = success UNKNOWN NOT_INUSE INUSE BUSY RINGING RINGINUSE ONHOLD qualify = failed INVALID UNAVAILABLE DEVICE_STATE reports our endpoint as UNAVAILABLE when Asterisk restarts until the qualify is successful which is not what we'd like as it would drop all the calls after a restart until qualifications have completed. It would have been better if it reported as UNKNOWN. We have run a number of tests now and ChanIsAvail() seems to yield the functionality we want. We didn't use this initially because of two reasons: (1) AVAILSTATUS always yields 0. We still don't understand why that is but we now check if the AVAILCHAN is an empty string or not and that works well. (2) If an endpoint is unreachable it will throw an error where we think it shouldn't, should only warn or perhaps inform that the endpoint isn't available. It seems that it tries to create a dialog rather than just checking the availability. -- Executing [s@CALL:13] ChanIsAvail("PJSIP/testserver-00000006", "PJSIP/testserver") in new stack [Feb 12 12:31:13] ERROR[5072]: res_pjsip.c:3163 ast_sip_create_dialog_uac: Endpoint 'testserver': Could not create dialog to invalid URI 'testserver'.  Is endpoint registered and reachable? [Feb 12 12:31:13] ERROR[5072]: chan_pjsip.c:2475 request: Failed to create outgoing session to endpoint 'testserver' At this time we most likely will move forward with (ChanIsAvail) so I thank you for that. Not sure if you'd like to act on anything of the above. We are running tests here now on this so if we can help in any way please let me know. By: Joshua C. Colp (jcolp) 2018-02-12 06:48:52.983-0600 I'll let this be triaged and the person doing so can decide what they want. By: Joshua C. Colp (jcolp) 2018-03-12 07:54:02.345-0500 As the behavior change would be a new feature (that would have to be configurable - behavior change is bad) I'm closing this out as a request. If you'd like to provide a patch it can be reopened.