[asterisk-bugs] [Asterisk 0015274]: SIP peers remain present in the channel's memory after rename (and probably removal)

Asterisk Bug Tracker noreply at bugs.digium.com
Thu Jun 4 12:00:28 CDT 2009


The following issue has been SUBMITTED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15274 
====================================================================== 
Reported By:                Romik
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   15274
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.24 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-06-04 12:00 CDT
Last Modified:              2009-06-04 12:00 CDT
====================================================================== 
Summary:                    SIP peers remain present in the channel's memory
after rename (and probably removal)
Description: 
Right after I've added qualify=yes to alterfon & sipnet peers into sip.conf
and issued `sip reload` command followed by the `sip show peers` I got in
the console:
=======================================================================
102/102                    192.168.1.248    D   N      27864   
UNREACHABLE
101/101                    192.168.1.174    D   N      26024    OK (101
ms)
125/125                    (Unspecified)    D   N      0        UNKNOWN
199/199                    xxx.xxx.xxx.xxx     D   N      5063     OK (37
ms)
alterfon/xxxxxxxx             83.219.240.148       N      5060    
UNREACHABLE
sipnet/xxxxxxx             212.53.40.40         N      5060    
UNREACHABLE
76 sip peers [Monitored: 5 online, 71 offline Unmonitored: 0 online, 0
offline]
iris*CLI>
iris*CLI>
iris*CLI>
    -- Got SIP response 405 "Method Not Allowed" back from 83.219.240.148
[Jun  4 18:12:44] NOTICE[23967]: chan_sip.c:13019
handle_response_peerpoke: Peer 'trunk_1' is now Reachable. (15ms / 2000ms)
[Jun  4 18:12:44] NOTICE[23967]: chan_sip.c:13019
handle_response_peerpoke: Peer 'trunk_2' is now Reachable. (15ms / 2000ms)
[Jun  4 18:12:48] NOTICE[23967]: chan_sip.c:13019
handle_response_peerpoke: Peer 'sipnet' is now Reachable. (15ms / 2000ms)
[Jun  4 18:12:48] NOTICE[23967]: chan_sip.c:13019
handle_response_peerpoke: Peer 'alterfon' is now Reachable. (15ms /
2000ms)
iris*CLI>
=======================================================================
Note trunk_1 and trunk_1 peers. I've renamed them to sipnet and alterfon
1,5 days ago and did `sip reload` and according to peerpoke/qualify they
still remain somewhere in the memory.
All peers are type=friend and host=hostname.domain (not IP) if that makes
sense.

Later I saw something like this in the console:
=======================================================================
    -- Got SIP response 405 "Method Not Allowed" back from 83.219.240.148
[Jun  4 18:12:44] NOTICE[23967]: chan_sip.c:13019
handle_response_peerpoke: Peer 'trunk_1' is now Reachable. (15ms / 2000ms)
[Jun  4 18:12:44] NOTICE[23967]: chan_sip.c:13019
handle_response_peerpoke: Peer 'trunk_2' is now Reachable. (15ms / 2000ms)
[Jun  4 18:12:48] NOTICE[23967]: chan_sip.c:13019
handle_response_peerpoke: Peer 'sipnet' is now Reachable. (15ms / 2000ms)
[Jun  4 18:12:48] NOTICE[23967]: chan_sip.c:13019
handle_response_peerpoke: Peer 'alterfon' is now Reachable. (15ms /
2000ms)
[Jun  4 18:13:48] NOTICE[23967]: chan_sip.c:16652 sip_poke_noanswer: Peer
'trunk_1' is now UNREACHABLE!  Last qualify: 15
[Jun  4 18:13:48] NOTICE[23967]: chan_sip.c:16652 sip_poke_noanswer: Peer
'trunk_2' is now UNREACHABLE!  Last qualify: 15
[Jun  4 18:13:52] NOTICE[23967]: chan_sip.c:16652 sip_poke_noanswer: Peer
'sipnet' is now UNREACHABLE!  Last qualify: 15
[Jun  4 18:13:52] NOTICE[23967]: chan_sip.c:16652 sip_poke_noanswer: Peer
'alterfon' is now UNREACHABLE!  Last qualify: 15
[Jun  4 18:14:47] NOTICE[23967]: chan_sip.c:7715 sip_reg_timeout:    --
Registration for 'xxxxxxxxxxx at sipnet.ru' timed out, trying again (Attempt
https://issues.asterisk.org/view.php?id=1)
    -- ast_get_srv: SRV lookup for '_sip._udp.sipnet.ru' mapped to host
sipnet.ru, port 5060
[Jun  4 18:15:07] NOTICE[23967]: chan_sip.c:13019
handle_response_peerpoke: Peer 'sipnet' is now Reachable. (15ms / 2000ms)
[Jun  4 18:15:07] NOTICE[23967]: chan_sip.c:13019
handle_response_peerpoke: Peer 'alterfon' is now Reachable. (15ms /
2000ms)
[Jun  4 18:15:11] NOTICE[23967]: chan_sip.c:13019
handle_response_peerpoke: Peer 'trunk_1' is now Reachable. (14ms / 2000ms)
[Jun  4 18:15:11] NOTICE[23967]: chan_sip.c:13019
handle_response_peerpoke: Peer 'trunk_2' is now Reachable. (15ms / 2000ms)
=======================================================================

Reporter IgorG confirms that it's true for his 1.4.24 and 1.4-svn.
Quote:
Had a look at the source. Seems that `sip reload` does not cancel sending
OPTIONS SIP messages which are scheduled somewhere and data for old peers
remains in the memory.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-06-04 12:00 Romik          New Issue                                    
2009-06-04 12:00 Romik          Asterisk Version          => 1.4.24          
2009-06-04 12:00 Romik          Regression                => No              
2009-06-04 12:00 Romik          SVN Branch (only for SVN checkouts, not tarball
releases) =>  1.4            
======================================================================




More information about the asterisk-bugs mailing list