[asterisk-bugs] [JIRA] (ASTERISK-28048) res_pjsip fails to migrate endpoint devstate from Unavailable to Not in use after restart until pjsip reload (or rerigster)

[Jaco Kroon (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-28048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=244765#comment-244765 ] 

Jaco Kroon commented on ASTERISK-28048:
---------------------------------------

A quick perusal of the pjsip code reveals that during pjsip initialization these two functions are called in this specific order in load_module:

ast_res_pjsip_initialize_configuration
ast_res_pjsip_init_options_handling

The latter installs a sorcery hook for (as I understand it) sending OPTIONs for qualify support.

The former calls load_all_endpoints which loads all the initial endpoints (and presumably existing contacts), thus skipping the hooks.

I would suggest the last two calls (load_all_endpoints and ast_sip_location_prune_boot_contacts) from ast_res_pjsip_initialize_configuration be split into a separate function to be called after all other subsystems of PJSIP has been initialized and registered their hooks.  It does look like there is a quite a bit of work in ast_res_pjsip_initialize_configuration that needs to happen before other subsystems can initilize, but those two calls should probably be delayed a bit.

> res_pjsip fails to migrate endpoint devstate from Unavailable to Not in use after restart until pjsip reload (or rerigster)
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-28048
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28048
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip
>    Affects Versions: 13.23.0, 13.22.0
>            Reporter: Jaco Kroon
>              Labels: pjsip
>
> Directly after "core restart now" my PJSIP endpoints will report as such:
>  Endpoint:  100/100                                              Unavailable   0 of inf
>      InAuth:  100/100
>         Aor:  100                                               10
>       Contact:  100/sip:100 at 165.16.203.126:5060            85f65a7816 Created       0.000
> This will remain as-is, with no indication at the network level of attemped qualifications (core show hints will also show unavailable at this point).  Once the endpoint reREGISTERs then it starts to work for that specific endpoint, or if I execute pjsip reload.
> The fact that pjsip reload fixes things seems to imply an ordering issue, so for the sake of eliminating that, here is my module load order (pjsip related):
> load => chan_pjsip.so ; this one def doesn't matter, even loading it after all other modules ...
> load => res_odbc.so
> load => res_odbc_transaction.so
> load => res_config_odbc.so
> load => res_sorcery_config.so
> load => res_sorcery_memory.so
> load => res_sorcery_astdb.so
> load => res_sorcery_realtime.so
> load => res_pjproject.so
> load => res_pjsip.so
> load => res_pjsip_transport_management.so
> load => res_pjsip_session.so
> load => res_pjsip_authenticator_digest.so
> load => res_pjsip_endpoint_identifier_user.so
> load => res_pjsip_registrar.so
> load => res_pjsip_refer.so
> load => res_pjsip_nat.so
> load => res_pjsip_pubsub.so
> load => res_pjsip_mwi_body_generator.so
> load => res_pjsip_mwi.so
> load => res_pjsip_sdp_rtp.so
> load => res_pjsip_header_funcs.so
> load => res_pjsip_caller_id.so
> load => res_pjsip_transport_websocket.so
> load => res_http_websocket.so
> It's always from a clean start, pjsip reload resolves the issue.  One client reported this recurring, and even waiting for extensions to re-REGISTER didn't  fix it for that particular customer, had to execute pjsip reload for him.  Eventually added this to cli.conf:
> [startup_commands]
> core waitfullybooted = yes
> pjsip reload = yes
> The former is required to ensure that pjsip reload doesn't attempt to execute too early or it doesn't actually "solve" the issue.



--
This message was sent by Atlassian JIRA
(v6.2#6252)