BLF not working for extensions not in from-internal context

We have multiple FreePBX distro servers that we use for multiple customers. On one box, we throw a bunch of customers that only have a handful of extensions. Customer phones go into a custom context called [from-customer] that prevents them from calling each other.

One customer decided they wanted sidecars on their Cisco SPA504 phones so they could monitor via BLF, as well as have instant transfer to voicemail capabilities. So we hooked them up like all our other sidecar SPA504s.

Except the BLF buttons went orange and would not get state information for the other extensions. After some testing, we discovered that if the extensions are not in [from-internal] the BLFs won’t subscribe properly.

We have a working work-around for this, but wanted to know if anyone else had such a problem?

[from-customer]
exten => _XXX,hint,SIP/${EXTEN}

exten => 200,hint,SIP/201&SIP/202&SIP/203
http://www.voip-info.org/wiki/view/Asterisk+standard+extensions

You should look at virtualization for each customer, it is the supported method for FreePBX in multi-tennant.

I looked on your web site. You are rebranding FreePBX. Have you respected all trade dress and copyrights?

Schmooze has many resources for resellers. We have been very succesful using the Schmooze hosting platform for our managed VoIP offering.

@DungeonMaster3000, no we have not tried that. We will investigate. Though I’m guessing that our provisioning team will not want to add to extensions_custom.conf (or our version of it) every time add an extension. We’ll see.

@SkykingOH, while we do provide dedicated servers for each of our customers except for those with a handful of extensions. They get dumped onto a set of general purpose machines. As for the rest of this note, I hope it does not sound confrontational - it’s so hard to get “genuine concern” tone in an email.

Please let me know what makes you think we are. We are not knowingly rebranding FreePBX. We do not allow customers access to web interface and all customer support requests go through our support staff. To my knowledge, we are in compliance with the FreePBX Distro ToS located at http://www.freepbx.org/freepbx-distro-tos, but if there is something else that we missed, please let me know and I’ll pass it along to our compliance people. We do not market or sell our product as having anything to do with FreePBX.

By the way, there’s a typo on the ToS page: “strickly prohibited” should be “strictly prohibited.”

Thanks!

It wasn’t confrontational, just a friendly note.

WRT virtuals, With the ease of virtualization (we use KVM on CentOS) I use a virt for even two extensions.

Hello,

I am working with a similar situation where I have 2 groups of users and want to prevent group A from dialing group b. I’ve setup 2 context names and made added code to extensions_custom.conf to accomplish this.
The code below prevents extensions in the 500 range from calling extensions in the 100 and 200 range. Works fine, and BLF on the extensions works.
However, BLF for the parking extensions and mailbox extension 500 do not work. I’m hoping an extra set of eyes might see why I’m not getting BLF hints for virtual ext 500 and park extensions 79 and 80.

[from-500]
;disallow calls from extensions 50x to 10x, 20x and intercom
exten => _20x,1,Goto(app-blackhole,congestion,1)
exten => _10x,1,Goto(app-blackhole,congestion,1)
exten => _99x,1,Goto(app-blackhole,congestion,1)
exten => _[*]5XX.,1,Goto(from-internal,${EXTEN},1)
exten => _[*0-9]!,1,Goto(from-internal,${EXTEN},1)
exten => h,1,Hangup()
exten => _5XX,hint,SIP/${EXTEN}
exten => _500,hint,SIP/${EXTEN}
exten => _7X,hint,SIP/${EXTEN}
exten => _8X,hint,SIP/${EXTEN}
exten => 50x,hint,SIP/79&SIP/50&SIP/500

There is a module called “custom contexts” that will enable that, a caveate is that it takes a bit of RTFM’ing

Didn’t see the custom contexts module, but it looks like the fix was adding
include => from-internal

I believe you will find it in ‘unsupported’ modules