FreePBX | Register | Issues | Wiki | Portal | Support

Strange SIP NOTIFY behavior


#2

Here is a module list comparison, of a PBX image that has pretty much the same simple setup. Same phones, same firmware, similar amount of extensions and similar BLFs. The one on the left doesnt experience the issue, while the one on the right does.

Is there an easy way to downgrade modules to test to see if the issues goes away in an older version?


#3

Latest SNG7.6 GA install does the same thing.

Although if I remove all BLFs and only have a SIP account register, the phone never subscribes to hints, and therefore asterisk doesnt send SIP NOTIFY packets which in turn doesnt start bombarding the phones, maxing out the CPU on them.

I installed an old SNG7-FPBX-64bit-1805-1.iso. Left it completely stock, all i did was update Endpoint Manager… the issue doesnt happen there. Everything is fine.

+----------------------+------------+---------+------------+
| Module               | Version    | Status  | License    |
+----------------------+------------+---------+------------+
| accountcodepreserve  | 13.0.2.2   | Enabled | GPLv2      |
| announcement         | 13.0.7.1   | Enabled | GPLv3+     |
| arimanager           | 13.0.4     | Enabled | GPLv3+     |
| asterisk-cli         | 14.0.1     | Enabled | GPLv3+     |
| asteriskinfo         | 13.0.7.1   | Enabled | GPLv3+     |
| backup               | 14.0.6     | Enabled | GPLv3+     |
| blacklist            | 13.0.14.8  | Enabled | GPLv3+     |
| builtin              |            | Enabled |            |
| bulkhandler          | 13.0.14.4  | Enabled | GPLv3+     |
| calendar             | 14.0.2.2   | Enabled | GPLv3+     |
| callback             | 13.0.5.2   | Enabled | GPLv3+     |
| callforward          | 14.0.1.3   | Enabled | AGPLv3+    |
| callrecording        | 13.0.11.4  | Enabled | AGPLv3+    |
| callwaiting          | 14.0.1.1   | Enabled | GPLv3+     |
| cdr                  | 14.0.5.14  | Enabled | GPLv3+     |
| cel                  | 14.0.2.4   | Enabled | GPLv3+     |
| certman              | 14.0.1     | Enabled | AGPLv3+    |
| cidlookup            | 14.0.1.6   | Enabled | GPLv3+     |
| conferences          | 13.0.23.11 | Enabled | GPLv3+     |
| configedit           | 13.0.7.1   | Enabled | AGPLv3+    |
| contactmanager       | 14.0.3.5   | Enabled | GPLv3+     |
| core                 | 14.0.12    | Enabled | GPLv3+     |
| customappsreg        | 13.0.5.4   | Enabled | GPLv3+     |
| dahdiconfig          | 14.0.1.1   | Enabled | GPLv3+     |
| dashboard            | 14.0.3.3   | Enabled | AGPLv3+    |
| daynight             | 14.0.1     | Enabled | GPLv3+     |
| dictate              | 13.0.5     | Enabled | GPLv3+     |
| digiumaddoninstaller | 2.11.0.14  | Enabled | GPLv2      |
| directory            | 13.0.19.5  | Enabled | GPLv3+     |
| disa                 | 13.0.6.1   | Enabled | AGPLv3+    |
| donotdisturb         | 14.0.1.1   | Enabled | GPLv3+     |
| dundicheck           | 2.11.0.3   | Enabled | GPLv3+     |
| endpoint             | 14.0.2.188 | Enabled | Commercial |
| extensionroutes      | 13.0.10.5  | Enabled | Commercial |
| extensionsettings    | 13.0.4     | Enabled | GPLv3+     |
| fax                  | 14.0.2.3   | Enabled | GPLv3+     |
| featurecodeadmin     | 13.0.6.4   | Enabled | GPLv3+     |
| findmefollow         | 14.0.1.18  | Enabled | GPLv3+     |
| firewall             | 13.0.53.4  | Enabled | AGPLv3+    |
| framework            | 14.0.11    | Enabled | GPLv2+     |
| fw_langpacks         | 14.0.1     | Enabled | GPLv3+     |
| hotelwakeup          | 14.0.1.4   | Enabled | GPLv2      |
| iaxsettings          | 14.0.1.4   | Enabled | AGPLv3     |
| infoservices         | 13.0.1.2   | Enabled | GPLv2+     |
| ivr                  | 13.0.27.7  | Enabled | GPLv3+     |
| languages            | 13.0.6     | Enabled | GPLv3+     |
| logfiles             | 13.0.10.4  | Enabled | GPLv3+     |
| manager              | 13.0.2.5   | Enabled | GPLv2+     |
| miscapps             | 13.0.3.1   | Enabled | GPLv3+     |
| miscdests            | 13.0.5     | Enabled | GPLv3+     |
| music                | 13.0.22.3  | Enabled | GPLv3+     |
| outroutemsg          | 13.0.2.1   | Enabled | GPLv3+     |
| paging               | 14.0.3     | Enabled | GPLv3+     |
| parking              | 13.0.19.8  | Enabled | GPLv3+     |
| pbdirectory          | 2.11.0.6   | Enabled | GPLv3+     |
| phonebook            | 13.0.6.1   | Enabled | GPLv3+     |
| phpinfo              | 13.0.2     | Enabled | GPLv2+     |
| pinsets              | 13.0.8     | Enabled | GPLv3+     |
| pm2                  | 13.0.5     | Enabled | AGPLv3+    |
| presencestate        | 14.0.1.5   | Enabled | GPLv3+     |
| printextensions      | 13.0.3.1   | Enabled | GPLv3+     |
| queuemetrics         | 2.11.0.3   | Enabled | GPLv3+     |
| queueprio            | 13.0.2     | Enabled | GPLv3+     |
| queues               | 14.0.2.15  | Enabled | GPLv2+     |
| recordings           | 13.0.30.12 | Enabled | GPLv3+     |
| restapi              | 13.0.21.1  | Enabled | AGPLv3     |
| ringgroups           | 14.0.1.4   | Enabled | GPLv3+     |
| setcid               | 13.0.6.2   | Enabled | GPLv3+     |
| sipsettings          | 14.0.27.1  | Enabled | AGPLv3+    |
| soundlang            | 14.0.4.3   | Enabled | GPLv3+     |
| speeddial            | 2.11.0.4   | Enabled | GPLv3+     |
| superfecta           | 14.0.6     | Enabled | GPLv2+     |
| sysadmin             | 14.0.13    | Enabled | Commercial |
| timeconditions       | 14.0.2.13  | Enabled | GPLv3+     |
| ucp                  | 14.0.2.3   | Enabled | AGPLv3+    |
| userman              | 14.0.3.40  | Enabled | AGPLv3+    |
| vmblast              | 13.0.8     | Enabled | GPLv3+     |
| voicemail            | 14.0.1.25  | Enabled | GPLv3+     |
| weakpasswords        | 13.0.2     | Enabled | GPLv3+     |
+----------------------+------------+---------+------------+

I dont know what else to think other than a freepbx module update is pissing off the polycom somehow.

I suppose I will buy support coins and open a ticket, but I am worried because polycoms are involved I am wasting my time? Can anyone at Sangoma confirm that if i buy support that I wont be ignored?


#4

Upgraded a brand new install of SNG7.6 GA to FreePBX 15 and the issue still exists.

After several days of research, the gist of the issue is this: Server sends a ton of SIP NOTIFY’s to each endpoint, and the phone has trouble keeping up returning the 200 OK. Eventually the server overwhelms the phones and they lock up.

The issue is reproducible across different installs and environments. I cannot be the only one having this issue? I am honestly surprised that there are zero replies to this thread… is it because i have Polycom phones? Even a reply from someone telling me to go pound sand is better than silence.


(Dave Burgess) #5

I wouldn’t ever tell you to pound sand, but there’s little else anyone can add.

It does appear (from the silence you’ve been met with) that you are the only one having this specific problem. The fact that you are generating that many SIP NOTIFY messages that quickly would imply to me that one of your time-out/reregistration settings is set a little too tight. I can’t really tell (no time timestamps) but it looks like you are trying to register the phone about once a second, and the latency on your network might be a little high. If either of those is the case, it could explain the problem you are seeing.

Check your extension settings and make sure you aren’t trying to send keep-alives every second (or less?, if that’s possible).

As far as downgrading goes, yes, you can use the module admin page to go back at least one version. Downgrading should be available to you from that window.


#6

Thanks for the reply.

Everything is stock as far as timeouts and whatnot. The SIP NOTIFYs are not responses to registrations, they appear to be related to BLFs. As soon as I remove BLFs from the phone’s config, they no longer subscribe to hints, so the server no longer needs to keep the phone updated on the statuses of other extensions based on the hints the phones subscribe to. Latency is less than 30ms over the VPN with very little jitter so I dont believe that is an issue.

I am currently installing the latest distro on bare metal to see if it has the same issue.


#7

Same issue with a new install on a bare metal server on a completely new network. Server is on a private subnet. I also now have a S705 that I’ll be adding to the server to see if it does the same thing.


#8

I have found that a fwconsole reload will stop the server from sending it’s bombardment of packets… just temporarily though.

Quite strange that just reloading freepbx would stop this


(Tom Ray) #9

Are the PBX and the phones on the same local network?


#10

I typically do it over a VPN, but I just setup a bare metal server on a new network. Everything is one local subnet. I dont even have a SIP trunk connected to it.


(Lorne Gaetz) #11

A support colleague ran into this late yesterday. Have a look at the advanced tab for the extension where the solicited and unsolicited options are for MWI. There were differences depending on which option is set.


(Tom Ray) #12

Yes, you want to have Solicited so that it requires an actual subscription to the MWI instead of just randomly sending updates whenever (unsolicited).


#13

Interesting, I wasnt aware of this setting. I will give that a shot and watch my packet capture. Did this setting change in a recently? All of my installs up until a few weeks ago didnt experience this behavior.

edit:
I am now curious what the functionality behind Auto is, how does the PBX determine which one to use? I suppose it’s possible polycom changed something on their end that is causing the PBX to change which mode it uses… but then again, I have tried older Polycom firmwares that are known to work fine, and have this issue with the later “versions” of freepbx.

Thanks for the suggestions, I will report back with what I find.


(Tom Ray) #14

If this was a polycom issue I would hear about it. I’m 90% Polycom with my deployments. So yeah…the numbers game would have made me hear about it.


#15

Same here. Have you seen this issue as well? Or do you explicitly set the MWI mode in each extension to Solicited? I have obviously never adjusted this setting until you guys brought it to my attention


#16

Ok so far setting this to Solicited has fixed my problem. I will let it run over the weekend just to be sure, but normally the CPUs on my phones would already be near 100% after a couple hours.

I could be wrong here on the setting here, but a brand new extension created on the latest and greatest freepbx modules:

MWI Subscription Type: Auto

[root@freepbx ~]# asterisk -x "pjsip show endpoint 205" | grep mwi
 aggregate_mwi                      : false
 incoming_mwi_mailbox               :
 mwi_from_user                      :
 mwi_subscribe_replaces_unsolicited : true

MWI Subscription Type: Unsolicited

[root@freepbx ~]# asterisk -x "pjsip show endpoint 205" | grep mwi
 aggregate_mwi                      : false
 incoming_mwi_mailbox               :
 mwi_from_user                      :
 mwi_subscribe_replaces_unsolicited : false

MWI Subscription Type: Solicited

[root@freepbx ~]# asterisk -x "pjsip show endpoint 205" | grep mwi
 aggregate_mwi                      : false
 incoming_mwi_mailbox               :
 mwi_from_user                      :
 mwi_subscribe_replaces_unsolicited : false

In my experience, when set to Auto, it sets mwi_subscribe_replaces_unsolicited = true, which blows up my phones with SIP NOTIFY

I manually set it to Solicited as suggested and it sets mwi_subscribe_replaces_unsolicited = false, but setting it to Unsolicited also has mwi_subscribe_replaces_unsolicited = false… so something isnt quite adding up here. I would think that setting it to Solicited would set that field to true ?

The last thing I noticed is that on our current production PBX, most of our extensions were created well before this issue started and all of them seem to have aggregate_mwi = true and mwi_subscribe_replaces_unsolicited = true (set to auto in the GUI)

[root@pbx ~]# asterisk -x "pjsip show endpoint 308" | grep mwi
 aggregate_mwi                      : true
 incoming_mwi_mailbox               :
 mwi_from_user                      :
 mwi_subscribe_replaces_unsolicited : true

If I create a brand new extension on our production pbx with everything up to date, these are the settings:

[root@pbx ~]# asterisk -x "pjsip show endpoint 1337" | grep mwi
 aggregate_mwi                      : false
 incoming_mwi_mailbox               :
 mwi_from_user                      :
 mwi_subscribe_replaces_unsolicited : true

It looks like the default setting of aggregate_mwi was changed from true to false sometime recently. Maybe that has something to do with it? :man_shrugging:


(Dotcom) #17

We see the same behavior… very high network load which appears some time after a APPLY in the GUI.

Is there any way to bulk update all extensions to set MWI Subscription Type to “Solicited”?

Can we set it by default to Solicited when creating a new PJSIP extension?

Final question: Does this setting have any impact on BLF? Or is it just used for voicemail notifies?

BR


#18

I don’t know the answer to the bulk changing or the default setting, it would definitely be nice to have.

As far as the BLFs, I haven’t noticed any adverse effects with functionality


(Dotcom) #19

Thanks for your reply!

Last question: Is there a way to set the default value to Solicited?


(Tom Ray) #20

No, as of right now there is no global template for PJSIP extensions. See both Chan_SIP and IAX (I believe, not 100% on IAX) have [general] sections that apply settings to all peers so if you don’t modify or add that setting to an individual peer, the setting in the [general] section applies to them.

Chan_PJSIP doesn’t have this. There are no general settings that apply to all endpoint/aors that are created. Each endpoint has its own settings.

You might want to check the issue tracker and see if there is a feature request for this functionality. If not, you could submit one.


(system) closed #21

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.