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?
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?
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
voIpProt.SIP.alertInfo.1.class=“autoAnswer”
voIpProt.SIP.alertInfo.1.value=“Auto Answer”
voIpProt.SIP.alertInfo.2.class=“default”
voIpProt.SIP.alertInfo.2.value=""
>
</voIpProt.SIP.alertInfo>
It also includes:
<se.rt.autoAnswer
se.rt.autoAnswer.callWait=“callWaiting”
se.rt.autoAnswer.micMute=“0”
se.rt.autoAnswer.name=“Auto Answer”
se.rt.autoAnswer.ringer=“ringer2”
se.rt.autoAnswer.timeout=“2000”
se.rt.autoAnswer.type=“answer”
>
</se.rt.autoAnswer>
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.
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.
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: CONFIG_FILES="0004f205ff7f-2545.cfg,legacy_sip.cfg"
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.
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.
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.
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…
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.
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.