[Home]

Summary:ASTERISK-14268: [patch] SIP peers remain present in the channel's memory after rename (and probably removal)
Reporter:Romik_g (romik)Labels:
Date Opened:2009-06-04 12:00:28Date Closed:2010-01-07 10:55:59.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_sip.patch
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@sipnet.ru' timed out, trying again (Attempt #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.

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

Sorry, can't check in 1.6. Asterisk's ver. is 1.4.24.1.
Comments:By: Dmitry Dudkin (ddv2005) 2009-06-05 09:37:19

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.
By: Romik_g (romik) 2009-06-22 04:04:52

Sorry, any updates?
By: Igor Goncharovsky (igorg) 2009-06-22 04:56:09

Similar issue fixed in https://reviewboard.asterisk.org/r/282/
By: Romik_g (romik) 2009-06-22 05:07:46

Thanks. I'll check that as soon it will be in the next stable 1.4.x release.
By: Dmitry Dudkin (ddv2005) 2009-07-15 11:53:13

https://reviewboard.asterisk.org/r/282/ [^] is not similar issue because 1.4.x have different (old) ref counting code and it can't be same issue.
I think that in this case the problem in the "sip_registry_destroy" that don't destroy "pokeexpire" scheduler. Try this patch to resolve the problem:
==========================================
--- /old/chan_sip.c 2009-05-12 14:18:44.000000000 -0400
+++ ./chan_sip.c 2009-07-15 12:47:48.000000000 -0400
@@ -3127,6 +3127,7 @@
ast_log(LOG_DEBUG, "Destroying active SIP dialog for registry %s@%s\n", reg->username, reg->hostname);
sip_destroy(reg->call);
}
+ AST_SCHED_DEL(sched, reg->pokeexpire);
AST_SCHED_DEL(sched, reg->expire);
AST_SCHED_DEL(sched, reg->timeout);
ast_string_field_free_memory(reg);

==========================================
By: Olle Johansson (oej) 2009-09-10 14:40:13

ddv2005: Can you please upload the patch as a file in the bug tracker? Thanks.
By: Olle Johansson (oej) 2009-09-11 01:26:03

Thanks for quick feedback!
By: Dmitry Dudkin (ddv2005) 2009-10-28 10:06:23

to russell
Did you test the patch?
By: David Vossel (dvossel) 2009-11-25 15:09:02.000-0600

The patch does not compile. There is no pokeexpire variable in the sip_registry struct, it is in the sip_peer struct.

I've spent some time trying to reproduce this and have not been able to.  Can anyone having this problem verify it still exists in the latest 1.4 release?
By: Leif Madsen (lmadsen) 2010-01-07 10:55:56.000-0600

Closing this as unable to reproduce.