[asterisk-bugs] [JIRA] (ASTERISK-25575) res_pjsip: Dynamic outbound registrations created via ARI are not loaded into memory on Asterisk start/restart

[Kevin Harwell (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-25575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kevin Harwell updated ASTERISK-25575:
-------------------------------------

    Target Release Version/s: 13.7.0

> res_pjsip: Dynamic outbound registrations created via ARI are not loaded into memory on Asterisk start/restart
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-25575
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25575
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip_outbound_registration
>    Affects Versions: 13.6.0
>            Reporter: Matt Jordan
>            Assignee: Matt Jordan
>            Severity: Minor
>      Target Release: 13.7.0
>
>
> Consider a system where {{sorcery.conf}} is configured to store/retrieve outbound registrations through the AstDB - such as in the snippet below:
> {code}
> [res_pjsip_outbound_registration]
> registration=astdb,ps_registrations
> {code}
> When an outbound registration is created through ARI and persisted to the AstDB, this creates the necessary outbound registration objects in {{res_pjsip_outbound_registration}} and {{REGISTER}} requests being to fire. An example of a registration stored in the AstDB is shown below:
> {code}
> /ps_registrations/registration/foo                : {"auth_rejection_permanent":"true","transport":"","support_path":"false","expiration":"3600","forbidden_retry_interval":"0","endpoint":"","contact_user":"","server_uri":"sip:bar at 127.0.0.1:5061","line":"false","outbound_proxy":"","client_uri":"sip:foo at 127.0.0.1:5060","retry_interval":"60","fatal_retry_interval":"0","max_retries":"10"}
> {code}
> This works because the creation of the object causes the object's sorcery apply handler to be called, which in turn creates the registration state. However, when Asterisk is started or restarted, this does not occur.
> Interestingly, if one queries the objects at any time - such as using the CLI command {{pjsip show registrations}} - the state will be created (again, because the apply handler is called) and REGISTER requests will being to fire again.
> One way of solving this is to simply query for all objects in the existing sorcery observer's {{loaded}} callback. This has the effect during load/reload of asking the backend for all objects and applying the configuration to the runtime.



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