[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)

[Richard Mudgett (JIRA)]

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

Richard Mudgett commented on ASTERISK-28048:
--------------------------------------------

Use of the allow_unqualified_fetch sorcery realtime option can block fetching the endpoints and AOR records with the new OPTIONS qualify code.  See ASTERISK-28003

> 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)