[Home]

Summary:ASTERISK-11381: sip reload should not unregister tcp/tls peers
Reporter:pj (pj)Labels:
Date Opened:2008-02-05 14:35:46.000-0600Date Closed:2008-02-12 02:10:35.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Registration
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) sip-debug.txt
Description:after reloading sip configuration, peers that using tcp or tls transport are unregistered (even in case, when sip.conf isn't changed).
peers are registered back when registry timeout expires. I think:
1) should not be unregistered when reloading sip.conf
2) when tcp session is closed (eg. stop/start asterisk server), tcp clients should attempt to reregister immediatelly (not wait until registration expires)



****** ADDITIONAL INFORMATION ******

324 is wm6 pda device (tcp transport)
bill-gw is asterisk client (tls transport)
both are behind nat/fw device

CLI> sip show tcp
Host                           Port Transport   Type
xx.xx.xx.xx                 52964  TLS       Server
xx.xx.xx.xx                 10006  TCP       Server


CLI> sip reload
[Feb  5 21:22:45]  Reloading SIP
[Feb  5 21:22:46]   == Parsing '/etc/asterisk/sip.conf': [Feb  5 21:22:46]   == Found
[Feb  5 21:22:46]   == Parsing '/etc/asterisk/sip_notify.conf': [Feb  5 21:22:46]   == Found
[Feb  5 21:22:46] SSL certificate ok
[Feb  5 21:22:52] NOTICE[2935]: chan_sip.c:18570 sip_poke_noanswer: Peer 'bill-gw' is now UNREACHABLE!  Last qualify: 2
[Feb  5 21:22:55] NOTICE[2935]: chan_sip.c:18570 sip_poke_noanswer: Peer '324' is now UNREACHABLE!  Last qualify: 273
CLI>
[Feb  5 21:24:12] NOTICE[2935]: chan_sip.c:14833 handle_response_peerpoke: Peer 'bill-gw' is now Reachable. (2ms / 2000ms)
[Feb  5 21:26:41] NOTICE[2935]: chan_sip.c:14833 handle_response_peerpoke: Peer '324' is now Reachable. (270ms / 4000ms)
CLI>
Comments:By: pj (pj) 2008-02-05 14:47:06.000-0600

debug attached...
maybe source of the issue is, that after sip reload, asterisk server is trying to send sip qualify message via udp, instead of tcp/tls?

after sip reload:
OPTIONS sip:s@192.168.40.4:5061;transport=TLS SIP/2.0
Via: SIP/2.0/UDP 192.168.38.20:5060;branch=z9hG4bK51c7964e;rport

after peer reregisters back:
OPTIONS sip:s@192.168.40.4:5061;transport=TLS SIP/2.0
Via: SIP/2.0/TLS 192.168.38.20:5060;branch=z9hG4bK3671708c;rport
By: pj (pj) 2008-02-05 15:04:14.000-0600

using tcpdump, I investigated, that after sip reload, asterisk is trying to send sip qualify (to tls peer) from port 5060, instead of port tcp:5061

so, I wrote subject of this issue inaccuratelly, sip reload do not unregister peers, but causes sending qualify messages using wrong transport and thus causes peers to be qualified as unreachable until peers are reregistered.


By: James Golovich (jamesgolovich) 2008-02-11 00:19:21.000-0600

The first part is taken care of and fixed in trunk.  Let me think about the 2nd part a bit and I'll see what I can come up with.
By: James Golovich (jamesgolovich) 2008-02-11 01:25:48.000-0600

I reviewed the SIP RFC to see if it said anything about it, looked at what we do with UDP, and looked how other clients handled it and I've come to the conclusion that we shouldn't really change anything.  In order to not overwhelm a server we should wait for the registration to timeout

I'm going to close out this issue, if someone feels the re-registration needs to be addressed a new bug should be opened on it since it would also apply to UDP and not just TCP and TLS.
By: pj (pj) 2008-02-11 01:51:02.000-0600

James, thanks to fixing the first issue, I will test today..
ad second) udp registrations are stored in asterisk databaze
'database show SIP/Registry'
so, after restarting asterisk server, udp peers are immeadiatelly qualified as OK, but seems, that tcp/tls peers are not stored here, so this peers are qualified as unreachable after restart, until all peers reregisers itself after their registry timeout expires.
I think it should be changed, because now, I must lower maxexpiry timeout globally in asterisk, because with default registry expiry timeout (3600s) will stay tcp/tls peers even one hour unregistered!
By: James Golovich (jamesgolovich) 2008-02-11 02:03:51.000-0600

Pavel,

I was under the impression that you were talking about from the client side that was making the registration and not the server that was receiving them.  In that case it is more cut and dry since with a TCP connection there is no way to connect back to a session that has already been closed.  We explicitly do not save the TCP/TLS connections in the database because of this.

Unless I'm missing something, the client should notice the connection go away and attempt to reconnect at some reasonable time.
By: pj (pj) 2008-02-11 02:31:51.000-0600

sorry for mistake, I mix two things together, so forget...
it seems, that only way to improve behaviour is from asterisk as client side, it can try to start reregistering (eg. reset registry timer) after asterisk client detect, that tcp session was closed.
By: Digium Subversion (svnbot) 2008-02-11 06:39:22.000-0600

Repository: asterisk
Revision: 103306

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r103306 | jamesgolovich | 2008-02-11 00:05:59 -0600 (Mon, 11 Feb 2008) | 3 lines

Don't wipe out transport and fd in chan_sip on reload (issue ASTERISK-11381)


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=103306