Summary:	ASTERISK-23065: On Asterisk start, device state is INVALID for previously registered PJSIP endpoints, despite re-registrations
Reporter:	Rusty Newton (rnewton)	Labels:
Date Opened:	2013-12-23 18:27:11.000-0600	Date Closed:	2014-01-16 10:46:01.000-0600
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Core/General Resources/res_pjsip
Versions:	12.0.0	Frequency of Occurrence
Related Issues:	is related to ASTERISK-23062 res_pjsip AOR config option qualify_frequency is inconsistently respected
Environment:	SVN-branch-12-r404531	Attachments:	( 0) cli_command_output.txt ( 1) full_after_restart_rereg.txt ( 2) full_initial_reg.txt ( 3) pjsip.conf.txt
Description:	*Reproduction and observation:* * Register an endpoint to Asterisk for the first time. (or wipe AstDB and then register). The Device state will be "NOT_INUSE". * Stop and start Asterisk. Device state shows "INVALID" for the endpoint. * After the endpoint re-registers, we continue to show "INVALID" for the endpoint. * Using the endpoint to dial an extension in dialplan, results in appropriate state changes (INUSE, RINGING, etc) and after hanging up, it ends up at "NOT_INUSE" * If you restart a phone and the phone unregisters, then Asterisk will make a state change to "UNAVAILABLE" and then "NOT_INUSE" after registration, which seems appropriate. *Notes:* In testing this, I notice that OPTIONS for the purpose of qualification do not get sent out unless the state is something other than INVALID. Though this is erratic and with a few tries I can reproduce endpoints in a "NOT_INUSE" state that don't have OPTIONS being generated for them. *Debug:* * cli_comment_output.txt contains "pjsip show endpoints" output after an initial registration of the phones, where the astdb had been wiped, plus output after a restart of Asterisk (stop and then start) where the AstDB info still exists for the previous registrations. * full_initial_reg.txt contains the full log from the initial run * full_after_restart_rereg.txt contains the full log from the restart where I wait for the endpoints to re-register
Comments:	By: Rusty Newton (rnewton) 2013-12-23 18:31:33.607-0600 ASTERISK-23062 may be a side effect of this behavior. It looks like the OPTIONS generally get sent out fine if the phone registers fresh with Asterisk and doesn't get into the INVALID state at any point. If however the phone was in an INVALID state, but then moves to other states, it looks like the OPTIONS never get generated. By: Rusty Newton (rnewton) 2013-12-23 19:10:04.317-0600 I guess what I would expect, or hope to see is an "UNAVAILABLE" or "NOT_INUSE" state after Asterisk starts if we still have the registration info from the endpoints, depending on what is possible. Then, relevant to ASTERISK-23062, I'd expect to see qualify start working after the endpoints get to any other state than "INVALID" or "UNAVAILABLE". By: Rusty Newton (rnewton) 2013-12-23 19:11:21.006-0600 I used the DEVICE_STATE function to verify the states that the CLI commands are showing appear accurate.