[asterisk-bugs] [JIRA] (ASTERISK-21663) [patch] Realtime TCP endpoints lose registration after "sip reload" & "core reload"

[under (JIRA)]

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

under commented on ASTERISK-21663:
----------------------------------

Hi, Michael.

I reproduced the same issue with WSS transport.

The patch you proposed won't fix the issue, because the issue is as follows.
When TCP-based client (TCP/TLS/WS/WSS) connects to Asterisk, Asterisk stores FD of connecting socket inside sip_peer->socket->fd (for WSS it stores sip_peer->socket->ws_session).
Later this info is used for communicating with client (socket->fd for TCP, socket->ws_session for WSS).
On 'sip_reload', realtime sip_peer struct is cleared, together with socket info.
And on restoring realtime sip_peer from realtime DB, this socket->fd and socket->ws_session is not restored (basically there is nowhere to get this socket info anymore).
And client is unreachable until he registers again and socket info gets written to sip_peer.

Following patch fixes the issue (don't reload realtime peers on 'sip reload'):

--- chan_sip.c.orig     2018-02-19 11:40:15.919503000 +0200
+++ chan_sip.c  2018-02-19 11:39:35.118345000 +0200
@@ -32229,7 +32229,7 @@ static struct sip_peer *build_peer(const
 static int peer_markall_func(void *device, void *arg, int flags)
 {
        struct sip_peer *peer = device;
-       if (!peer->selfdestruct) {
+       if (!peer->selfdestruct && !peer->is_realtime) {
                peer->the_mark = 1;
        }
        return 0;

Sip realtime peers could be unloaded with 'sip prune realtime peer' command, so I don't see reasons why they should be reloaded by 'sip reload'.


> [patch] Realtime TCP endpoints lose registration after "sip reload" &  "core reload"
> ------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-21663
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21663
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/DatabaseSupport
>    Affects Versions: 1.8.21.0, 11.3.0
>            Reporter: Dinesh Ramjuttun
>            Assignee: Michael L. Young
>            Severity: Minor
>         Attachments: asterisk-21663-outbound-default-transport-fix_11.diff, asterisk-21663-outbound-default-transport-fix_1.8.diff
>
>
> The scenario is as follows:
> - TCP endpoints are being used.
> - transport is set to "udp,tcp" in sip.conf (transport=udp,tcp)
> I have tested with both realtime configuration and flat peer configuration in sip.conf
> After a "sip reload", a realtime TCP peer loses its registration. With qualify=yes set, the TCP peer becomes "unreachable" to asterisk. When that TCP peer is called, sip invites are retransmitted unsuccessfully before giving up. Extension to extension calls cannot go through. Only way to fix this is either by restarting Asterisk or waiting for the peers to re-register again.
> If peer setting is static in sip.conf, the TCP endpoint does not lose its registration.
> I have compared the "sip show peer [peer]" in both cases after a "sip reload" or "core reload". With realtime peers, "sip show peer [peer]" shows primary transport as UDP while "sip show peer [peer]" with static peer in sip.conf ,primary transport is showed as TCP.



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