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 2.5.1.2 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-.