Allowing Polycom 601's to Recieve Pages (EPM)

Do you think that if I altered that line in extensions_additional.conf that it might work?

If I find a version of Paging where the 430’s start intercomming again, would Sangoma accept this issue as a bug to be fixed, do you think?

Well, so far I’ve downgraded these modules to the versions below, but I never see the original code for ALERTINFO in extensions_additional.conf - I only see the updated code. How far back in which module do I need to go till I see the change?

  • Paging Pro
  • Paging and Intercom 14.0.7
  • Core
  • Framework 14.0.11

I found this thread:

which is the same problem I have.
I searched for issue #6502 in the tracker but can’t find it. That thread was from 2012, though, so I suspect that it was deleted for version 14. okay. same old problems…
Is there no solution for this, anybody?

Are you aware of the Advanced Setting “Enforce RFC7462”? That may be at play here for legacy devices.

Mr. Gaetz, ah, no - I’ve never heard of that one… If I apply that setting, will it mess up my non-legacy devices?

Ah, well. It’s already enabled, anyway. So I guess it doesn’t mess up non-legacy devices, because they have continued to function correctly.

I only have an IP330 available at the moment, but it seems to be auto answering for me without any custom changes to my config files. It’s been a while for me, but I think I remember the auto-answering setup to be similar with these models (330, 430, and likely 601). I may be way off here, since it sounds like you’re modifying some default polycom files, but can you check your [test phone’s mac].cfg file to see what it’s set to fetch? For example, based on the default settings, mine is set to get:
CONFIG_FILES=“0004f21e348c-features.cfg, 0004f21e348c-121.cfg, 0004f21e348c-sip-interop.cfg”

0004f21e348c-sip-interop.cfg has the settings I’d look towards.
For me, that file includes the following:
voIpProt.SIP.alertInfo.1.value=“Auto Answer”
It also includes:
se.rt.autoAnswer.micMute=“0”“Auto Answer”

I don’t know if there have been changes over the years with these settings, but if you’re setting your alertInfo class to be a number, you’ll want to make sure there’s a section in se.rt that matches up with it. This would be after verifying that the phones are actually fetching the files you’re looking at by checking [phone’s mac].cfg.
I’m currently on EPM v14.0.20, maybe from an edge release, but I don’t know if there’s any changes regarding this stuff between that and the versions you’ve been trying.

Here is my sr.rt entry in legacy_sip.cfg:

  <ringType se.rt.enabled="1" se.rt.modification.enabled="1">
     <DEFAULT"Default" se.rt.1.type="ring" se.rt.1.ringer="2" se.rt.1.callWait="6" se.rt.1.mod="1"/>
     <VISUAL_ONLY"Visual" se.rt.2.type="visual"/>
     <AUTO_ANSWER"Auto Answer" se.rt.3.type="answer"/>
     <RING_ANSWER"Ring Answer" se.rt.4.type="ring-answer" se.rt.4.timeout="2000" se.rt.4.ringer="2" se.rt.4.callWait="6" se.rt.4.mod="1"/>
     <INTERNAL"Internal" se.rt.5.type="ring" se.rt.5.ringer="2" se.rt.5.callWait="6" se.rt.5.mod="1"/>
     <EXTERNAL"External" se.rt.6.type="ring" se.rt.6.ringer="2" se.rt.6.callWait="6" se.rt.6.mod="1"/>
     <EMERGENCY"Emergency" se.rt.7.type="ring" se.rt.7.ringer="2" se.rt.7.callWait="6" se.rt.7.mod="1"/>
     <CUSTOM_1"Custom 1" se.rt.8.type="ring" se.rt.8.ringer="5" se.rt.8.callWait="7" se.rt.8.mod="1"/>
     <CUSTOM_2"Custom 2" se.rt.9.type="ring" se.rt.9.ringer="7" se.rt.9.callWait="7" se.rt.9.mod="1"/>
     <CUSTOM_3"Custom 3" se.rt.10.type="ring" se.rt.10.ringer="9" se.rt.10.callWait="7" se.rt.10.mod="1"/>
     <CUSTOM_4"Custom 4" se.rt.11.type="ring" se.rt.11.ringer="11" se.rt.11.callWait="7" se.rt.11.mod="1"/>

It should work with this, which is what I had there for ages.
<alertInfo voIpProt.SIP.alertInfo.1.value="Auto Answer" voIpProt.SIP.alertInfo.1.class="3"/>

I have a lot of these 430’s and they all stopped intercomming at the same time, and I’m positive it began just after I made some system or module updates and rebuilt the configs in EPM.

I think I figured something out!

So, I was making sure the settings were correct in sip_legacy.cfg, so that ALL the legacy phones would use the correct alertinfo.

Now, sip_legacy.cfg is loaded in the [mac].cfg file like this:

However, even though legacy_sip.cfg is loaded after [mac].[ext].cfg, the alertinfo settings in that file are not being preferred to to [mac].[ext].cfg.

I thought the last file loaded was supposed to take precedence.

This is the default in [mac].[ext].cfg - that is, this is what gets built by default for EPM.

    voIpProt.SIP.alertInfo.1.value="Auto Answer"

But if I manually change it in [mac].[ext].cfg, then it works with this code:

    voIpProt.SIP.alertInfo.1.value="Auto Answer"

So, I have two problems:

  1. EPM builds the [mac].[ext].cfg file with the wrong alertinfo.
  2. legacy_sip.cfg is not being preferred to [mac].[ext].cfg, even though it is loaded last in the list.

I’d submit a ticket on 1.

I can see, on the other one, why that would make sense. Regardless of the load order, I’d expect the phone to treat “default” files (like your legacy_sip.cfg) differently than the “phone specific” files like your mac.ext.cfg file.

If we assume the phone processes them in the order they are received, then you’d expect them to work like you are expecting, but I don’t think the phone works that way. I think it loads the NVRAM stuff first, then processes any “generic” files, then the MAC specific files last. If that’s the case, the only way to get your phones to work is to make sure the alertinfo stanza is loaded in the MAC specific file, which arguably it should be.

Good work on finding a solution, by the way.

1 Like

I just updated (in my last post) the code the EPM builds - I deleted [mac].[cfg].cfg for a particular 430 and then rebuilt the config in EPM and this is exactly what it created.

Apparently, EPM builds the cfg with the wrong class.
If I manually correct the cfg, intercom works like it’s supposed to.

Sounds like a trip to Ticket Town.

I would have to create a commercial ticket, right? They are soooo slow to respond. I still have a ticket there from last Friday that nobody has apparently even looked at. I wish they would use the issue tracker instead of making people use the “commercial support” page.

But EPM is a commercial program so that would be the right. Also, remember that they don’t do commercial ticket triage on the weekends.

Now, if this was a problem with a basefile or something that isn’t “code related”, then the Issue Tracker might be the place to put it. Having a solution usually gets them cleared out pretty quickly though, especially if there are other ticket open for the same code segment…

One couldn’t be faulted for putting the ticket into the Issue Tracker and have it escalated by the “professional” staff. Having the code fix available (or at least a good explanation of how to fix the problem) might make adding it as an “Issue” instead of a commercial ticket palatable…

Thanks, Mr. Burgess.

I ended up fixing this in the basefile for the ext.cfg by changing “ringAutoAnswer” to “3”.

That’s cool, and I’m glad that also works for you, but this really does deserve a ticket. If you’ve got it working, a Commercial Trouble Ticket wouldn’t hurt you and could solve the problem for other people.

I placed a commercial ticket already just after my last post.

1 Like

To be fair, your ticket from last Friday is a commercial module Feature Request not a Support Ticket. Feature request tickets don’t get immediate action as they are used to gauge development direction for future module versions. Lack of response is not indicative of lack of interest.

Mr. Gaetz, there were two - one was a feature request, true. The other reported an issue which made Extension Routing not useable.

Okay, I will not take lack of response as lack of interest.

Commercial support responded to me and said they don’t support legacy devices and that editing the basefile is the only solution.

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