Transferring a queue-originated call to another extension bypasses voicemail

Did you notice you've set your call timeout to be 5 minutes? That's why it's not going to voicemail. Shorten it down a bit. -- Executing Macro("Local/20@from-internal-783c,2", "dial||trwW|300")

--Rob

Actually, that'd be the extension. From extensions.conf:

; Use a Macro call such as the following:
;  Macro(dial,$DIAL_TIMER,$DIAL_OPTIONS,$EXT1,$EXT2,$EXT3,...)

So, whatever's calling macro-dial is leaving the dial-timer blank.

Re-opening ticket, as it was erroneously closed... -rt

Indeed. I do apologise for leaping erroneously to that conclusion, especially as I was the one who changed the dial macro's parameters! However, this is the problem:

{{{ -- Executing Dial("Local/20@from-internal-783c,2", "SIP/300trwW") in new stack

-- Called 300 -- SIP/300-094e36a8 is ringing -- User hung up

}}}

There's _no_ timeout on the Dial string - this is correct. You don't want an Agent going to Voicemai. However, I'm confused as to how you got there whilst trying to do a transfer. Can you tell me exactly what the user is doing? (Eg, phone rings, they pick it up, push hold, dial the number, talk, push transfer)

--Rob

Here's the order of reproduction:

- Agent logs into queue dynamically

- External caller gets into the queue via either Inbound Route or IVR

- Call goes to the agent, who is using a SIP device (customer is using Cisco 7940s, we're using Polycom IP501s)

- Agent uses the phone's user interface to perform a transfer

I'm not 100% sure if it's a blind transfer or attended transfer, but I believe it happens either way. I'll double-check on it though, if necessary.

Simular problem is reported in ticket 1196

Have been looking at this and have found this so far

Stored in queues_additional.conf

would be somthing like the following

[14] announce-frequency=15 queue-callswaiting= queue-thankyou=custom/tamuch queue-thereare= queue-youarenext= retry=5 rtone=0 strategy=ringall timeout=15 music=default monitor-join=yes monitor-format= announce-holdtime=no context=ivr-6 eventmemberstatusoff=Yes eventwhencalled=no joinempty=Yes leavewhenempty=no maxlen=0 member=Local/202@from-internal/n,0 wrapuptime=0

If i change the member=Local/202@from-internal/n,0 to member=SIP/202,0

so the whole config for queue 14 looks like

[14] announce-frequency=15 queue-callswaiting= queue-thankyou=custom/tamuch queue-thereare= queue-youarenext= retry=5 rtone=0 strategy=ringall timeout=15 music=default monitor-join=yes monitor-format= announce-holdtime=no context=ivr-6 eventmemberstatusoff=Yes eventwhencalled=no joinempty=Yes leavewhenempty=no maxlen=0 member=SIP/202,0 wrapuptime=0

it works as expected and also the call pickup also works I dont know if it will break anything else.

Sigh. This is getting quite complex. Need to build a lab of enough phones to debug this properly. Probably after 2.2's out.

Just a followup

Tested this in a live environment for 6 Hours with the following phones

aastra 480i Grandstream GXP200 Ploycom IP500

Plus link sys pap 2 box

All worked ok if I changed the config back to Local/202@from-internal/n,0

Then calls trasfered from a queue will just ring and ring and ring then hangup

#1196 marked as duplicate. There was discussion on that report as well that is relevant

I just tested this and it appears to be working fine, agent answered phone and transfered the call to another extension where it rang as appropriate and then went to voicemail.

I'll close this bug but if there really is something going on still then please re-open with more information. I don't want to be too trigger happy.

Which version was this fixed in? Just curious.

Thanks! -rt

I was still having the same problem until this morning

I change my zapata.conf file and my zaptel.conf file

restarted the machine tested the calls from a queue and it works

Tim