So I have created 2 Custom Contexts so that we can control which users can use a specific outbound route. My Custom Contexts are called [international-dial] and [national-dial]. And on each context, I have enabled a dial rule so they can call each other internally: Dial Rule: 7XXXX. Everything works fine, and the extensions are using the correct Custom Context as expected. The problem is that all of a sudden, I see that the BLF on the phones does not work at all.
When configuring the Custom Context settings, and I setup “ext-local” as “Allow” then BLF works again.
When I change the “ext-local” to “Allow Rules”, so it uses my dialplan rule, then BLF stops working, and I get the following log error on my Asterisk CLI
Endpoint '70182' state subscription failed: Extension '70121' does not exist in context 'International-Dial' or has no associated hint
The problem is that the answer was from 2011, and I am not able to find where to add this subscribecontext=ext-local on my FreePBX GUI, which “Srthomas” used to solve his issue.
Can anyone help me here, please? Is this a real bug or why does my BLF break when using Custom Contexts?
So, after playing a lot with Custom Contexts, I ended up removing the “Allow Rules” from the ext-local and swap it to only “Allow” and I left the subscribecontext=ext-local as it is on the SIP Settings.
I tested whether between extensions were able to call internally.
Here is the breakdown:
So on the first ext [70181], which belongs to [national-dial] context, I dialed to the ext [70121], which belongs to international-dial] context.
Lo-and-behold they started working without the need the “Dialplan rule” which I had set up way before within the custom context. In the end, I was able to call internally between extensions. I am not sure how it worked without the “dialplan rules” but sometimes IT works in weird ways.
BLF works also, the only issue that I encountered was that some of our custom Feature codes weren’t working, for example our Voicemail feature code, or our Call Flow Control feature code. The solution was by setting (app-daynight-toggle) to “Allow”, as well as (app-dialvm) to “Allow” on the custom context’s settings, and the BLF’s work now.
Strange scenario but hope this post can be useful in the future for someone who is having the same issue as I had.
Is this a new system, or did you add international calling restrictions to a system that was long in production?
If the former, it is strongly recommended to use pjsip rather than the deprecated and soon to be removed chan_sip.
Also, for a simple restriction such as allowing international calls from only certain extensions, instead of Custom Contexts I would just set up the international Outbound Route with CallerID fields that match the allowed extensions. If you have many such extensions and they aren’t in groups that can be pattern matched, you can use the Upload from CSV feature to load them from a spreadsheet.
We recently moved to cloud-based and I was given the task of setup international dialing for specific extensions. I do not have a commercial distro. It could be another approach by creating a matching rule to allow specific extensions to use a specific route.
At the moment I am using pjsip for all of my extensions and I knew that chan is being deprecated soon. My only issue was only with BLF not working at all when using custom contexts where ext-local had “Allow Rule” instead of “Allow”. I am still not sure why this happens tho.
Thank you for the advise! I’ll keep it in mind. At the moment I am still working out the phone call flow and trying to improve the user’s experience.
I’m haven’t touched the Custom Contexts module in a decade or so, but I do know that it works by internally placing extensions in alternate contexts that have different access to dialplan. It may well be that losing local BLF hints is a consequence of using the CC module, tho I don’t know that to be the case.
Wow, so it seems that CC is not being used much anymore. Yeah, it’s strange as when I deployed the CC to all my extensions, some of them started having BLF issues where even if the BLF was showing “green” when an extension would get a call the BLF would not even update. I actually thought that the problem came from my route. I even tried to check the call flow and I was getting a 404 subscribe error on my logs. The thing is that I accidentally changed my CC naming and all of the extensions belonging to that CC were reset back to the from-internal context, and lo and behold, the BLF started to come up. That’s how I realized that CC was the main cause of my issue.
Even though I fixed my issue, I am still trying to understand the logic behind it so, thanks for the brief explanation on how CC works but this still raises my question on why BLF hints get lost when working with dialplan rules. And this is something that I started seeing more often in forums and the solution they gave was to add a SIP Setting subscribecontext=ext-local. I believe that when alternating the CC the hints are lost because they are still using the from-internal context; however, this setting is added onto the chan_sip setting, and not the pjsip_setting, (note that I am only using pjsip for my extensions) so I don’t think that adding the subscribecontext=ext-local did nothing at all.
