Blind transfer Follow Me and Callforward patch required

Would like to hear any opinion about my issue and if I can make a BUG report on it. I am not sure if I ran into a BUG or a system limit or need to write an API etc or need to find another approach etc.

On freePBX with asterisk version 1.14.2 I run a multi user environment where groups of extensions have their own context that refer to outbound and inbound routes and trunks dedicated to a group of extensions. All is working well and normal pstn outbound calling is selecting properly the trunk that is assigned to an extension by its context. Also for inbound calling all is functioning very well.

In most cases the firmware in the phones causes the attendent transfers to select the proper trunk because the endpoint is genereating a regular INVITE that will follow the configured dial plan thus selecting the correct resources.

With a Blind transfer the problems start that after a call transfer selected on the phone by pressing the xfer key. Eventually the call will be forwarded but it will take the extension as configured in the extensions.additional.conf under the TRANSFER_CONTEXT.

In some phones that I tested the blind transfer configuration will not cause a problem because the firmware still will use a regular INVITE as coming from the endpoint with the proper FROM field causing the Dial macro not end up in a to spawn exception .

The hard coded call forward and follow will jump into the “from-internal” context and use the resources connected to this context. I would like to see that the call will be properly forwarded using the context assigned to the extension where it is forwarded from.

Sofar I analysed a multitude of ata’s and voipphones all giving different results for the attendent or blind forwarding. Dump tracing learned me that the reason for this is that some firmware in some phones start with a INVITE and a media attribute sendonly challenging the freepbx and putting the phone in hold and activating the MOH. Normal procedure is pressing the pstn number followed by another xfer to transfer the call and some firmware in the phones create their own INVITES using the correct FROM field while other phone types do nothing. The second xfer in a dependent xfer will cause a REFER that freePBX will challenge and connect using the correct extension context. The second xfer on the phones that do nothing will cause a REFER that will be challenged by the freepbx and eventually by the macro logic result in an INVITE using the stored TO number in the REFER to connect to. Last will give a successfull connect but use the context as given in the TRANSFER_CONTEXT in stead of using the from field that came with the REFER.

In short some phones do INVITE using their FROM fields and some do nothing letting freePBX create the INVITE. In both cases technically the call transfer will result in a success for the end user unknown of the fact that not his trunk will be charged but the default one.

With call forward and follow me the hardcoded “from-internal” context will be used thus invoking the trunk related to this context.

How can I achieve proper call transfer in a multi tenant environment where each group of extensions has its own trunk - that when a call transfer is issued on any given extension - the proper or owed contexts are being used - followed by its assigned trunk. This in case an ata’s or voip phones firmware does not generate their own INVITE afer the transfer xfer button has been pressed.

In most cases described as blind transfer but it is not always true? It fully depends on the endpoints firmware (In a blind transfer you dont care if the person you connect the call to is answering the line or not. You just forward)

Is the above scenario a BUG or “function as described”.

How can I achieve that call forward and follow me will do forwarding with the same behavior as above using the proper extension that originated the call forward or follow me?

Note: It is not clear that a blind transfer causes this more than a dependent transfer. It is firmware dependent. In all tested phones the procedure xfer - press number to forward to - xfer has been used. All phones used RFC 3264 offer/answer sendonly in the SDP for the first INVITE after pressing xfer.

regards, Tjaracas-.

I finally found some useful information in the development forum. What I like to achieve is referred to as multi tenant solutions and according to what I read is asterisk - freePBX not the best platform to achieve this functionality. So I am afraid that what I discovered with the call transfer function is known as “functions as designed”.

If anybody can advice me a good open source multi tenant platform than not be afraid to inform me about it.

have you tried google today?

In under 2 seconds using the words “asterisk multi-tenant” I received at least two different packages that say they can do it in the first ten listings.

And read the discussions on the development forum for freePBX and found out that asterisk and multi tenant does not go hand in hand. I already left freepbx and asterisk and went for a solution to another platform. I will still be using asterisk and freepbx for standalone solutions. thanks for your answer anyway.

Global Advantage PBX
Thirdlane Multi Tenant PBX

are just a few that were found quickly.

Thanks but I like to work with opensource solutions like linux , freepbx etc. Not because I do not like to pay for my software but because I am a big fan of solutions like freepbx that work together to provide solutions coming from a community. With buy software I totally depend on the company I buy the software from. People should not do this. Asking money for support is another deal but selling some modified opensource software is like something I can not appreciate. I think my initial transfer question cannot be answered.

I used the information from here to fix it. Search for GO_ON_BLINDXFR Call forward and follow me still a pain in the a$$ but for now I am happy. Looks like freePBX is adding some code that will put the context always in from-internal-xfer. Blind transfers take the correct context that belongs to the extension that transfers from now. Since I consider my fix as a ugly hack I will not put it available to the public to avoid further problems. Bottom line is that asterisk does it OK with proper configuration settings .