Call Forwarding and Follow Me to External Number Not Working


Call Forwarding and Follow Me to External Numbers found not working for Users for whom the outgoing call is enabled through Source Caller ID Filter using Extension Groups.

If the extension is directly selected in the ‘Available Extensions/Extension Groups’ column, then they are able to do Call Forward or Follow Me to External Numbers.

So, it appears that the Extension Groups given in the ‘Available Extensions/Extension Groups’ are ignored for Call Forwarding and Follow Me calls to External Numbers.

Follow me is not working with external number

Further, it is also found that invitations from conference to external numbers also doesn’t go through if the inviting extension is in a Extension Group that is appearing in the outgoing filter! Basically, it appears that any system triggered activity for calling an external number seems to be ignoring the Extension Groups in the ‘Enable Filter on Source Caller ID’ list!


if I understand the question well, I think there is the trunk sip not set correctly, try to populate / popularize the fields “From User” and “From Domain” or those just below.


Its not the issue with trunk sip I guess. If it was the case, even the outgoing calls made by the user would have been failed. In this case, user is able to make outgoing calls by calling any external number without any issue. However, when external number is used in Follow Me, Call Forwarding or during a Conference Call invite, the outbound calls are failed. Also, instead of Extension Groups, if I put the user’s extension number directly in the filter, then all calls are happening! Its a simple case that he outgoing call initiator in certain cases simply ignores the extensions in the Extension Group provided in the Caller ID Filter. So, it is a bug. As usual, GS Help desk doesn’t respond neither to acknowledge nor to clarify!


I repeat that it could be a problem of setting up the Trunk SIP, I also happened to make and receive calls regularly on the Trunk SIP but the deviations or other particular situations did not work.
I fixed the SIP Trunk and also the detours etc… started to work.


To try this case, ours is a digital trunk. It does not have any option ‘From User’ or ‘From Domain’


mine are just examples, I told you about my experience hoping it would be useful to you, above I do not think you described that trunk uses, so I assumed that you used trunk Sip.


Thank you for sharing your experience. More or less we have tried all the options on the trunk and even tried through different trunks like analogue and with different settings. Unfortunately none of that worked. My intention of sharing here is that if anyone is using the same device and in a position of re-creating this scenario, more or less can confirm if this is a bug or something unique to our installation.


To summarize my understanding -

When source callerID is setup and the allowed extensions are set in the filter to be an extension group, the forward fails. However, when selecting the specific extensions rather than a group, the forwards succeed?

Do you have a ticket number?


Precisely @lpneblett . Here is the ticket number: #20190329160103. It’s not just Forward that fails - but Follow Me and In conference invites to External numbers too.

However, Ring Simultaneously works just fine with extension group as intended!


I can confirm the issue with forwards. I simply setup a catchall outbound route that has no source, but its for a very small client that does little of this, so the impact is minimal.

I am of two minds on the issue -

  1. I can understand that the call control is not handled by the extension, but rather the system and as the forward is being performed by the system as opposed to the forwarding being done in the physical phone, the source is apparently not being associated to the extension and therefor fails the source filter requirement. It seems to me that the system knows for what extension the call was destined and should be able to substitute its CID (source) for that of the system so the call can progress when forwarding. However, as you can specify the extensions instead of the group, you can still apparently get what you want, but not as conveniently.

  2. The invite from a conference, I think, is a different animal. I am not sure how the internal mechanism is determining who or what is making the call. You press 0 or 1 which then causes a voice prompt to query for the number and then it is dialed. As you were already in the call, there was no SIP signalling by “your” extension to send the INVITE to the outbound route, but rather the conference room seemingly handled via some form of a DISA like method. As a conference room is not a user extension, the opportunity to place in a group is non-existent.

I wonder if you could remove the source filter and repeat the steps and then examine the INVITE and see what is sent and then create a custom route for same? Of course, if this is possible, it effectively eliminates the source filter.

I am uncertain that either is a bug, but in #1, certainly a feature enhancement that simply expands the use of a group.

I am of the opinion that #2 is not a bug, but rather a system limitation in that as you stated, no system extension that has call control can use a route that has source enabled. I am not sure how one might programaticallly handle this as there is nothing that precludes the initiator of the action from being someone not attached to the system (an outside caller) and as none of the internal extensions have control of the call, the system has to handle. As an example, in the case of a conference, I assume I can be outside of the office and can dial in, be the administrator and then do an invite to another number. Now what?


Our requirement demands a source caller filter. So cannot do away the source filter:

a. Not all extensions are permitted to make external calls.
b. Multiple trunks are used for making external calls. While few extension use Trunk 1, few other extensions should use Trunk 2 and so on…

So, a catchall route will probably make a loophole in the above requirement.

Referring to your 2 points,

  1. That is how the logic should work - if not, how is then it is making the call when the extension is directly entered in the filter instead of group? Practically it is a very complicated work-around if we have to accommodate all the extensions directly in the filter instead of group. With Extension names included it is going to be a massive amount of poorly organised text that we would need to traverse when required.

  2. I am not sure if my description of the problem communicated something else. When the extension is entered directly in the filter instead of group, even conference invite also works perfectly. We are not expecting an external participant of a conference to make an invite to another external party - that would probably lead to illegal call routing. Here the invites are made by internal extensions. When an internal extension is making the invite, the invite goes from that extension. If that extension is permitted to make outbound calls, that extension can do invites to external numbers. This is tested and working perfectly - only when the extension is in the filter directly instead of group.

Except when the filter used through an Extension Group, everything works perfect as intended. When Extension Group is used as filter, making outbound calls physically from extension and Ring Simultaneously to external numbers works. Forward, Follow Me and Conference invite fails.

I guess this is definitely something that the development team can fix in terms of programmability. The logic and all other essential components required to make it work is already there. In my understanding, it is fairly a simple fix - it’s all about populating the list of source id filter with filter list + extension groups in the list exploded OR whatsoever is the logic currently used for making an outbound call or Ring Simultaneously.

If Extension Group A contains the extensions 4500, 4510, 4520 and the Source ID filter list contains 4550, 4560, ExtensionGroupA, then:

Instead of validating the filter list as {4550,4560,ExtensionGroupA } the list must be reconstructed by exploding the Extension Group in filter as {4550,4560,4500,4510,4520} and then validated.


As stated about the catchall - in my case the issue was of little impact, I did not mean that it would not be of greater or lesser impact to you as I have no idea of the size of the install. Only what I did.

As far as not being able to make external call, a filter is not needed as you can set the permission level to prohibit calls from given extensions.

I did not suggest that it should not work by using extension groups. I am just not sure that it is a “bug” as I have no way to know that it was ever intended to be able to use groups for forwards. A bug is defined when something that was designed to work in a certain fashion fails to function as such. I am in agreement that it should work regardless of what the intent was or was not as it could have been simply overlooked; hence why I suggested a feature request/enhancement.

While you may not expect external folks to make a invite call, that is not necessarily the case for everyone else. There are options that can be employed to safeguard against some of the concerns. How the dev team does what you wish is not something I can speculate about, but can again only suggest that you submit a ticket as it is up to GS to resolve.

So, don’t take e wrong, I am supporting the needs you have expressed, but have no control as a user like yourself to influence GS in their decision to act upon the issue.


Permission level would have been the ideal option for enabling external calls if only our requirement ‘b’ was not there! Requirement ‘b’ was to route few people through Trunk A and few others through Trunk B. People in group A should not use any trunks other than Trunk A and similarly for Group B. This forced us to use Extension Groups.

Your comments are taken in the right sense. Sharing my thoughts to see if they stand the test of logical stability and what view points are it gathering.

I am equally not very sure to call it a bug or feature. But, given the observations it appeared more like a bug than a feature. Hence tagged here. Now waiting for GS Help desk to respond.


Well, got me there with regard to permissions as I forgot that source disables the permissions.

Guess we will see how it goes. It would make it easier to have groups.


This is general build problem as UCM have missing any correct control for outband calls that is not Extension.
It generate problem with 2 options:
correct routing

I’m fighting with GS but they are hard to press on that matter. It look like they never have trunk with multi numbers.

As for your situation:
You can make limitation on pattern. USER X can call his mobile via this route but no one else.

  1. Restrict source (user)
  2. Restrict pattern (his external number) - this will prioritize call go to this permission.

Big problem as UCM will forward call with incoming call caller ID !
This will swap FROM to caller ID (in some cases provider deny call).


We are referring to a case where when extension is added on the source filter directly, it is working whereas when done through an Extension Group, it is not working. So, more or less the problem is how Extension Groups are enumerated to the source filter.