Forum Discussion
Consult then transfer to call queue is not working
I have just been on with a support rep, and I think they found an answer....
you have to assign a DDI to the call queue, then you should be able to transfer a call to it.
there is allegedly documentation around this which I am waiting for, and also a site where I can request a feature from Microsoft - one can hope 🙂
this does seem odd where a purely sip based PBX in the cloud requires DDI to be assigned.
Hope this helps
I have had to do some creative work where I assigned the DDI but diverted the DDI on the sip trunk to the main number - I don't want to be woken in the night with a caller asking about their hospital appointment just because the put the wrong DDI on their paperwork....
Today I get the following answer from Microsoft on my reopened ticket: In my reopened ticket I pointed to this discussion ...
"
As I can see that the issue which you have reported and which is mentioned on the shared article, still remains a known issue for Microsoft. Our engineering team is actively working on it but unfortunately, we will do not a fix for the issue yet nor an ETA to share with you.
Consult then transfer is available for the user since the release of multiwindow calling and meetings to Global Availability. That being said, consult and transfer does not work in the context of transferring to CQs.
Ref: https://support.microsoft.com/en-us/office/transfer-a-call-in-teams-b7f40f14-e083-46b9-b739-68038c8f73a0
There were few issues related to Consult then Transfers which were resolved by disabling the New Meeting Experience in Teams Client Settings. I would suggest you can also try this workaround and check if it works for your environment. Please feel free to reach us back if need status detail in future.
We regret the inconvenience caused to you.
"
..... unbelievable.
Today I was a participant at the Teams Community Day ... I get in contact with another participant who had the same issue ... he said he could solve this with some changes on his SBC. I will get those detail informations in the next days ... but I can not really beleive that changes on the SBC can solve this issue because the call will not left microsoft environment when we select "consult then transfer" ...
I will let you know up to date
regards
Thorsten
Thorsten Stiebig Hi Thorsten, any news on that one? I have a similar problem here, regarding ALL consulted transfers, not only to call queues. We already identified that the chance of successful transfer is higher if one uses a fully qualified E.164 number as a target. Some Microsoft SBCs seem to normalize number correctly, some don't. And you never know, what users will dial ... thus we implemented a full-blown set of normalization rules so that the target ist always a full E.164 number. Nevertheless ... still get unsuccessful transfer in numerous calls. Any new hints to the root cause?
Thanks in advance!
Best
Dominik
- Under Teams Admin Centre, Org Wide Setting then Teams Settings there is an option:
Scope directory search using an Exchange address book policy - this was set to 'on' which messes with the search function. but this is not the issue now, something new. I have just filled in the detail for MS to ascertain the issue. - I have given up.
I said we will use the call merge feature, but this has still not been released. According to M365 message center, this feature will be released until end of may. Anybody got some update about this case?
If i see how long ago i created this topic i don't have hope the are going to fix this!
Reading the last reply here, I may certainly hope that they will fix it or leave it as it is, and not begin with
"hiding call queues from the search for consultative transfer while the scenario is not supported"
That is a bad idea as well. Why?
Because at this point you can still consult the call queue, someone in the queue picks up (person X), they say it's ok to transfer to them, then you have to leave call with person X , resume call with client , 3 dots more actions - transfer - type person X --> Go...It's annoying, but it does the job.
If they disable consulting the call queue, you have to consult one person at a time and constantly know who is in the queue, which is even worse.Merge call is perhaps a workaround if available, but it's equally annoying.
CDZoeller
Hi Dominik
I recently had a meeting with an actual engineer from Microsoft.
That was the answer:"This being said, the engineering team is currently working on two work items in that regard, namely one with hiding call queues from the search for consultative transfer while the scenario is not supported, second with adding support to consultative transfers to call queues.
At this point there is no ETA and PG is working on the available options to implement such, being in the engineering scope of decision, to implement the functionalities and update regarding the timelines for such."
For the time being, they said, we should use call merge.
https://support.microsoft.com/en-us/office/merge-calls-in-teams-15fd64cf-1500-4143-b199-1bbda98fd695
So you initiate the call with "consult, then transfer" and then merge the two active calls.
Regards,
Thomas
