Summary:	ASTERISK-21663: [patch] Realtime TCP endpoints lose registration after "sip reload" & "core reload"
Reporter:	Dinesh Ramjuttun (din3sh)	Labels:	patch
Date Opened:	2013-04-20 22:56:52	Date Closed:	2013-07-02 13:05:40
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Channels/chan_sip/DatabaseSupport
Versions:	1.8.21.0 11.3.0	Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 21663.diff ( 1) asterisk-21663-outbound-default-transport-fix_1.8.diff ( 2) asterisk-21663-outbound-default-transport-fix_11.diff
Description:	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.
Comments:	By: Michael L. Young (elguero) 2013-04-21 08:45:07.739-0500 We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information What is the "transport" setting for the peer in your realtime table?  The default will be UDP if the transport is not specified for that peer and is only specified in the global settings. Also, is "rtcachefriends" turned on? By: Dinesh Ramjuttun (din3sh) 2013-04-21 12:23:19.567-0500 rtcachefriends is set to yes. I did not explicitly set transport= in realtime table. Setting it explicitly seems to resolve the issue. Also, I thought setting transport=tcp,udp in general section of sip.conf sets the value globally for the peers without having to explicitly set it for each peer. I mean, for the static peers in sip.conf, I did not have to explicitly set transport=tcp,udp, yet it defaults to TCP. In realtime, not setting it defaults to UDP? By: Michael L. Young (elguero) 2013-04-21 23:53:51.549-0500 First, realtime peers are handled differently from static peers.  When you issue a sip reload or core reload, realtime peers will not be in the peers table that is displayed when you issue "sip show peers".  It remains that way until a realtime peer re-registers or we initiate a call to the peer which loads in it's configuration. The order of the transports plays an important part.  Which order do you have it set in the general section?  Your description says "udp,tcp" but in your last comment you say "tcp,udp".  Having "transports=udp,tcp" sets the permitted transports and also sets the default outbound transport.  The first transport listed becomes the default outbound transport.  Therefore, UDP would be used based on what you have in the description.  If you were to set it to "transports=tcp,udp", then TCP would become the default outbound transport. But, I think I may see a bug.  When a sip reload has been issued and the realtime peer has not re-registered yet, when a call is sent to the peer, we are setting the transport to UDP instead of using the configured default transports or the configured default outbound transport.  In this situation where you are not specifying the transport for a realtime peer, UDP and TCP are in the list of allowed transports for the realtime peer since it was in the global settings.  But, we have set the transport for this call to UDP and when we check it against the peer, we send the call using UDP (since it is set as a valid transport) which fails. I will work on a patch to see if that solves this for you.  We will then want to make sure to set the default outbound transport accordingly as well once I get a patch for this put together. By: Michael L. Young (elguero) 2013-04-24 08:53:25.481-0500 Dinesh, please try the attached patch.  One is for 1.8 and the other is for 11.  Please try your settings exactly how you had them when you reported this issue in order to confirm that it fixes the problem of not using the default primary outbound transport when transport is not specified on a per peer basis. Also, please remember that the order of the transports is important.  If you have "transports=udp,tcp", then UDP will be used as the default.  If you have "transports=tcp,udp" then TCP will be used as the default. Thanks By: Michael L. Young (elguero) 2013-05-13 16:26:58.544-0500 Dinesh, Have you been able to test this patch?  If you could please report back on whether this fixed the issue for you or not, would be greatly appreciated. Thanks By: Jason Parker (jparker) 2013-07-02 13:05:40.233-0500 I'm going to close this issue out, due to no response from the reporter. If the reporter would like to reopen the issue after having tested the patch, it can be requested. By: under (under) 2018-02-19 03:43:20.010-0600 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 Asterisk learns his socket info again. Attached patch 21663.diff, which fixes the issue. Patch disables reloading realtime peers on 'sip reload'. 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'. By: Michael L. Young (elguero) 2018-02-19 10:17:53.942-0600 This issue was closed almost 5 years ago with no response from the original reporter.  If this issue is still present in the latest supported version of Asterisk, I would recommend that you open up a new report.  You can always reference this issue. https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions