[asterisk-bugs] [JIRA] (ASTERISK-27529) Endpoint with TLS lost inbound registration

[Dmitriy Serov (JIRA)]

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

Dmitriy Serov edited comment on ASTERISK-27529 at 2/9/19 5:05 AM:
------------------------------------------------------------------

The reason is found and the workaround works. I will tell you about the causes of the problem.
It is important that it was:
- allow_reload=true in the transport config
- reloading pjsip config

Sometimes the algorithm thinks that the transport has changed (although there were no real changes):
{code}
/res/res_pjsip/config_transport.c
                ast_sorcery_diff(sorcery, perm_state->transport, transport, &changes);
                if (!changes && !has_state_changed(perm_state->state, temp_state->state)) {
{code}
and then a new listener is created instead of the old one.

and then
{code}
third-party/pjproject/source/pjsip/src/pjsip/sip_transport.c
        /* If transport is found and listener is specified, verify listener */
        else if (sel && sel->type == PJSIP_TPSELECTOR_LISTENER &&
                 sel->u.listener && transport->factory != sel->u.listener)
        {

            transport = NULL;
            /* This will cause a new transport to be created which will be a
             * 'duplicate' of the existing transport (same type & remote addr,
             * but different factory). Any future hash lookup will return
             * the new one, and eventually the old one will still be freed
             * (by application or #1774).
             */
        }
{code}
When you try to send from the server to the OPTIONS or INVITE client, a new connection is created (from the server to the client, which by its nature will never be correct) and replaces the old connection (with the same Protocol, address and port) in the transport hash.
As a result, we have a lost socket that successfully responds to the client's REGISTER and creates the illusion of successful authorization from the client.

allow_reload=false is workaround i used now.


was (Author: demon):
The reason is found and the workaround works. I will tell you about the causes of the problem.
It is important that it was:
- allow_reload=true in the transport config
- reloading pjsip config

Sometimes the algorithm thinks that the transport has changed (although there were no real changes):
/res/res_pjsip/config_transport.c
                ast_sorcery_diff(sorcery, perm_state->transport, transport, &changes);
                if (!changes && !has_state_changed(perm_state->state, temp_state->state)) {
and then a new listener is created instead of the old one.

and then
third-party/pjproject/source/pjsip/src/pjsip/sip_transport.c
        /* If transport is found and listener is specified, verify listener */
        else if (sel && sel->type == PJSIP_TPSELECTOR_LISTENER &&
                 sel->u.listener && transport->factory != sel->u.listener)
        {

            transport = NULL;
            /* This will cause a new transport to be created which will be a
             * 'duplicate' of the existing transport (same type & remote addr,
             * but different factory). Any future hash lookup will return
             * the new one, and eventually the old one will still be freed
             * (by application or #1774).
             */
        }
When you try to send from the server to the OPTIONS or INVITE client, a new connection is created (from the server to the client, which by its nature will never be correct) and replaces the old connection (with the same Protocol, address and port) in the transport hash.
As a result, we have a lost socket that successfully responds to the client's REGISTER and creates the illusion of successful authorization from the client.

allow_reload=false is workaround i used now.

> Endpoint with TLS lost inbound registration
> -------------------------------------------
>
>                 Key: ASTERISK-27529
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27529
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip
>    Affects Versions: 15.2.0
>            Reporter: Dmitriy Serov
>            Severity: Minor
>              Labels: pjsip
>         Attachments: debug9-1.txt, demon.tcpdump.txt, endpoint.txt, pjsip-config-tls-lost.txt, registration_with_lost.txt, TLS-Qualify-ServerPort-Bug.zip
>
>
> Regression.15.1.4 -> 15.2.0-rc. 
> Endpoint with TLS lost inbound registration.
> After some time of first register (connect) in asterisk log "is now Unreachable.  RTT: 0.000 msec".
> Homer shows packets REGISTER and answers OK. But no line on Reachable in logs.
> Client thinks is online. And asterisk does not. As a result - lost calls.



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