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

[Michael L. Young (JIRA)]

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

Michael L. Young commented on ASTERISK-21663:
---------------------------------------------

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.
                
> 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
>    Affects Versions: 1.8.21.0, 11.3.0
>            Reporter: Dinesh Ramjuttun
>            Assignee: Dinesh Ramjuttun
>            Severity: Minor
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira