SIP blind transfers, FreePBX ring groups and custom destinations

4 posts / 0 new
Last post
vieri
vieri's picture
SIP blind transfers, FreePBX ring groups and custom destinations

After upgrading to FreePBX 2.5.1.1 I noticed a small glitch (but important for my situation).

I have a SIP extension whose "follow-me" is set to redirect to a custom destination if unanswered.

I setup the custom context to do several things and one of them is to try to send the incoming call to a FreePBX group (4051).

This is what I call in this custom context:

exten => s,n,GotoIf($[]?from-internal,4051,1)

It works fine.

However, I'm having trouble with the following situation:

a SIP extension, member of the 4051 group answers the call then decides to do a blind transfer to another SIP extension which is not part of the group and has CF enabled and pointing to another SIP extension which isn't part of the group either.

The transfer fails and I see the following in the * CLI (7016 is the extension the call was supposed to be blind-transferred to):

dialparties.agi: Extension 7016 has call forward set to 4061
-- dialparties.agi: Filtered ARG3:
-- AGI Script dialparties.agi completed, returning 0
-- Executing Dial("Zap/13-1", "Local/FMPR-@from-internal&Local/FMGL-@from-internal|22|tTwWM(auto-blkvm)") in new stack
-- Called FMPR-@from-internal
-- Executing NoOp("Local/FMPR-@from-internal-d439,2", "In FMPR 7016 with ") in new stack
-- Called FMGL-@from-internal
(...)
dialparties.agi: Setting default NOANSWER DIALSTATUS since no extensions available
-- AGI Script dialparties.agi completed, returning 0
-- Executing NoOp("Local/FMPR-@from-internal-d439,2", "Returned from dialparties with no extensions to call and DIALSTATUS: NOANSWER") in new stack

I can't reproduce this situation with an earlier version of FreePBX (because I'm out of test systems for now) but I'm 99,9% sure it worked before.

Note that if the caller dials the group number 4051 and a group member blind-transfers the call to 7016 with a CF setting then it also fails.

So to reproduce the bug I'm reporting (but I'm not sure it's a bug yet) you could create a group, populate it, call that group extension and blind transfer it to another extension which has a CF setting.

Can anyone please confirm this bug and suggest how to fix it, if possible?

Thanks,

Vieri

vieri
vieri's picture
It looks like the CFIGNORE

It looks like the CFIGNORE variable is always true whenever I do a test call like the one I reported, even if I uncheck "Ignore CF Settings" in the group settings...

vieri
vieri's picture
There's a bug at line 141 of

There's a bug at line 141 of functions.inc.php in admin/modules/ringgroups:

the second instruction
if ($cwignore != '')
should clearly be
if ($cfignore != '')

fskrotzki
fskrotzki's picture
posting this here will get

posting this here will get lost and forgotten. Please post it in the bug tracker. it's at the bottom of the page under development.