[asterisk-dev] Possible chan_sip problem with new scheduler

Sylvain Boily sboily at avencall.com
Tue Nov 10 17:03:41 CST 2015



Le 2015-11-10 14:56, Michael Keuter a écrit :
> Am 10.11.2015 um 19:42 schrieb Steve Davies <davies147 at gmail.com>:
>
>> Hi,
>>
>> I have a randomly occurring de-registration of SIP devices since 11.20.0, and I believe that the new scheduler is indirectly the cause. The following assumes that the new scheduler can (and will reasonably regularly) re-use the sched-id of 0, which never used to be possible.
>>
>> Scenario:
>>
>> - chan_sip is up and running, and several registrations are current.
>> - one of these registrations has a peer->expire sched_id value of 0
>> - SIP RELOAD is called, resulting in a call to set_peer_defaults(peer)
>>
>> set_peer_defaults(peer) contains the following code:
>>
>>          if (peer->expire == 0) {
>>                  /* Don't reset expire or port time during reload
>>                     if we have an active registration
>>                  */
>>                  peer->expire = -1;
>>                  peer->pokeexpire = -1;
>>                  peer->keepalivesend = -1;
>>                  set_socket_transport(&peer->socket, SIP_TRANSPORT_UDP);
>>          }
>>
>> At which point we leak a scheduled expire_register call. The knock on effect of this is an hourly line de-registration that is only resolved by stopping the phone for an hour to let the leaked event trickle out.
>>
>> Help? Should we:
>>
>> 1) Change the above test to 'peer->expire < 0'
>> 2) always initialise sched_id values to -1 as soon as the peer is created.
>>
>> Thanks,
>> Steve
> Hi Steve,
>
> I had exactly the same problem.
> There is already an issue in the bugtracker (including patches):
>
> https://issues.asterisk.org/jira/browse/ASTERISK-25476
>
> Maybe you can made your comments there as well.
> Thanks.
Hello,

I seems this problem is on asterisk 13.6 too. We have the same issue too 
on different servers.

Sylvain



More information about the asterisk-dev mailing list