[asterisk-bugs] [Asterisk 0011930]: sip reload should not unregister tcp/tls peers

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11930 
====================================================================== 
Reported By:                pj
Assigned To:                jamesgolovich
====================================================================== 
Project:                    Asterisk
Issue ID:                   11930
Category:                   Channels/chan_sip/Registration
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 102037 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             02-05-2008 14:35 CST
Last Modified:              02-11-2008 02:03 CST
====================================================================== 
Summary:                    sip reload should not unregister tcp/tls peers
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)


====================================================================== 

---------------------------------------------------------------------- 
 jamesgolovich - 02-11-08 02:03  
---------------------------------------------------------------------- 
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. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
02-11-08 02:03  jamesgolovich  Note Added: 0081995                          
======================================================================