[asterisk-bugs] [JIRA] (ASTERISK-26210) chan_sip: NOTIFYs for BLF start queuing up and fail to be sent out, Asterisk 13

[Steven Sedory (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-26210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231575#comment-231575 ] 

Steven Sedory commented on ASTERISK-26210:
------------------------------------------

Setup:

We have a few clients on a FreePBX server running Asterisk 13.9.1. We have a handful of Polycom VVX 300s and 400s setup with extensions on this server, and many of them have BLF keys, which are primarily used to show each user when their office companions are on a phone call or not.

On other servers we have, one of them being on Asterisk 13.7.0, we have the same setup, but without the issue.

The issue:

For an unknown amount of time after the endpoints are powered on (this seems to be somewhere around 1 day, but for the sake of not making a gigantic log file, I'm avoiding debugging for that long for now), BLF's work just fine. Then after a day or so, they stop working, meaning they do not light up when said BFL monitored extension is called or on a call. By rebooting the extensions, the problem goes away again for another day or so.

When this happens, a lot of messages like this show up in the logs:
   Extension Changed 521[ext-local] new state Ringing for Notify User 523 (queued)
   Extension Changed 521[ext-local] new state Ringing for Notify User 524 (queued)
   Extension Changed 521[ext-local] new state Ringing for Notify User 522 (queued)
*Notice the "(queued)" and that this happens when extension 521 is called, and the three phones with a BLF key for 521 do not light up as they should

Reproduction and logging:

The extensions used in the reproduction of the problem are 521,522,523,524,403, and 9877. 521-524 are part of a small office, with 524 being at a remote location. 403 and 9877 are located at our office, and have been setup as test extensions. 403, similar to 521-524, has BLF keys for 521-523.

Once I started logger per wiki [2], I called 521 from extension 9877. You will notice the following in the attached log file (debug_log_123456):
   1. Extensions 522-524 BLF keys do not work, and this is the result in the log:
      [2016-07-25 11:39:24] VERBOSE[2084] chan_sip.c: Extension Changed 521[ext-local] new state Ringing for Notify User 523 (queued)
      [2016-07-25 11:39:24] VERBOSE[2084] chan_sip.c: Extension Changed 521[ext-local] new state Ringing for Notify User 524 (queued)
      [2016-07-25 11:39:24] VERBOSE[2084] chan_sip.c: Extension Changed 521[ext-local] new state Ringing for Notify User 522 (queued)
   2. Extension 403 BFL key DOES work, and note that there is no "(queued)" in the log:
      [2016-07-25 11:39:24] VERBOSE[2084] chan_sip.c: Extension Changed 521[ext-local] new state Ringing for Notify User 403

We have other customers on the same server, so you will see other queued messages similar to the ones above, as they also have the same BLF issue going on.

Conclusion:

I would imagine that after some time, my test extension 403 will start getting queued messages too and therefore the BLF keys will stop working. I just set this up yesterday (Sunday), so I will report when/if that happens.

It sounds very much like the issue explained in the bug I already linked in the comment above is back, though I of course may be wrong. Thank you for your help on this matter.

> chan_sip: NOTIFYs for BLF start queuing up and fail to be sent out, Asterisk 13
> -------------------------------------------------------------------------------
>
>                 Key: ASTERISK-26210
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26210
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>    Affects Versions: 13.9.1
>         Environment: ESXi Host VM, CentOS 6.6 (FreePBX's Current Distro: 10.13.66-64bit), Quad Core Intel Xeon E5530 2.4GHz, 4GB RAM
>            Reporter: Steven Sedory
>            Assignee: Steven Sedory
>         Attachments: debug_log_123456
>
>
> The issue we are experiencing seems exactly the same as the one already "fixed" here: ASTERISK-21677
> The initial description there is exactly what we're experiencing. The main difference is that we're on CentOS 6.6, and Asterisk 13.



--
This message was sent by Atlassian JIRA
(v6.2#6252)