[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
Fri Jun 5 09:37:20 CDT 2009
A NOTE has been added to this issue.
======================================================================
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-05 09:37 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.
======================================================================
----------------------------------------------------------------------
(0106048) ddv2005 (reporter) - 2009-06-05 09:37
https://issues.asterisk.org/view.php?id=15274#c106048
----------------------------------------------------------------------
I have same problems with OPTIONS messages on 1.6.1.0 with Realtime SIP
peers. When qualify=yes and client go down without unregistration then
Asterisk will send OPTIONS message forever. And only one way to stop it -
sip qualify peer xxx. But if i did "sip reload" then this peer will removed
from SIP peers and i can't do "sip qualify peer". And after that no way to
stop OPTIONS messages. Even if this peer will available, Asterisk will send
OPTIONS message again after normal unregistration.
And of course if I delete peer then OPTIONS messages never stop. Even
after sip reload.
I found that sip_poke_peer function in chan_sip is initiating the
OPTIONS message and save peer reference for scheduler. If peer is
unavailable then scheduler will call sip_poke_noanswer function. And this
function will schedule sip_poke_peer again in any case. Even if peer not
exist in SIP peers, because old peer reference saved in scheduler.
Issue History
Date Modified Username Field Change
======================================================================
2009-06-05 09:37 ddv2005 Note Added: 0106048
======================================================================
More information about the asterisk-bugs
mailing list