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....
TeamsDR I recommend to also make a case at microsoft.
With more cases we hopefully get a fix soon!
My case status is:
Issue has been escalated to engineering team and it is with voice team.
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....
- I also created a ticket regarding this, so hopefully hat will give more pressure at their end 😉
- There is nothing we can do ... just wait ... we are waiting since April this year. Very sad!
hansvos I send you an pm with the Ticket number. Good luck!
Thorsten Stiebig, do you have an update or ticket number ?
We are facing the same issue and want to create a support ticket regarding this.
I want to mention your ticket.Thank you!
Kind regards,
Hans Vos
End of the year ?
Nothing we can do about that then....Are you transferring calls to the Queue by entering the Queue name in the transfer box, or are you transferring to the Resource Account associated with the Queue please?
We can get it to work when transferring to the resource account, but you need to be an owner or member of the queue for it to be in the list of people to transfer to.
TeamProMember
I have no issue transferring the call directly.
The issue only occurs when consulting first. We then have two separate calls and can't transfer the call after consulting.- I may have a similar issue.
So I can transfer a call to a queue when I enter the DDI of the queue, however, when I search for the Queue by name in the transfer box & hit transfer the original call stays with me, on hold, it doesn't get transferred to the queue.
Is this the same bug everybody else has?
Really frustrating having moved from a Cisco PBX where I could transfer to a 4 digit Hunt Group flawlessly. Thorsten Stiebig
Looking forward to the end of the calendar year.Thorsten Stiebig a bug really??? 😉
Good we finally have an answer!
Hope the fix will be there faster... Should be crazy indeed if we have to wait that long!
Thanks for the update...
IT IS A BUG AT MICROSOFT AND A KNOWN ISSUE!
Some minutes ago I received the final answer from Microsoft:
"
After discussing and checking with our team, this is a known issue and had registered as a bug. They are working on the issue, but for now their is no ETA and the fix should be rolled out at the end of this calendar year.
"This was a long way to get this information ... crazy, perhaps we have to wait to the end of this calendar year for a fix. That is very bad!
Thorsten Stiebig
Do you have any updates regarding this issue?Hi Thorsten Stiebig thats good to hear hope you can get somewhere with microsoft!
My cases is sort of closed and my sbc partner is waiting for microsoft patches so nobody is really looking for a solution for us at the moment! Hope to here good news from you soon...
Lars86
Hi,my microsoft ticket is still open and the support engineer is talking to the teams product group now. In the last weeks microsoft also informed us that we have to fix it on the SBC. But in our SBC Logfiles however we could not see any traffic for that ... when we start the process for "consult then transfer". This traffic did not arrive on our SBC at all ..... so for me this is actually a Microsoft problem.
I expect new informations this week ...
Anybody got some news? looks like Microsoft is not going to fix this???
My case with microsoft is at a dead end! And they keep saying our sbc partner needs to fix this.
Greetings,
Lars
Lars86 That is nearly the same what Microsoft Support told me too.
On 06-02-2020 11:04 AM I wrote in my post here the following Microsoft Support answer:
"
This is to inform you that this is a known issue. We analysed the logs and found 404 back from next hop outbound on gateway, e.g. SIP Trunk provider, this indicates that the IP Profile for Teams IP Group has not been configured to handle refer locally.
As mentioned earlier the Root Cause is the IP Profile for the Teams IP Group in the SBC has not been configured to handle refer locally. In this case the Refer received from Microsoft sip proxy for transferred calls is routed to next hop, and the next hop responds with 404 as it does not know the source of the transfer.
"With that Information we are not able to solve it with doing anything on the SBC ...
TeamsDR Microsoft send me an update of my case today...
I have investigated internally and found it is an issue with SBC vendor.
Your carrier provider needs to work with SBC vendor.
Reason : It looks like Invite of transfer incorrectly built, INVITE message should contain copy of REFER-TO header from referred call.
For me it looks like they are not going to fix this???
Do you have a case number at microsoft?
Thorsten Stiebig you are right! the support engineer came back very soon and said that MS are working on a fix that is to be deployed in July (they said Mid July).
TeamsDR : Thanks for your update. I can not believe that this will solve the problem. All my call queues are assigned with a phone number (from my direct routing sip phone number range).
I am still waiting for some news from my Microsoft ticket. The Support Engineer is waiting for some answers tand next steps to troubleshoot the issue. Now I have to create i short video of the issue and again deliver some log files ... never ending story.
TeamsDR my queues already have a Direct Routing DDI assigned to them and i see have the issue. can you share a screenshot of you queue setup to see if any settings are different. are you using a ddi from your direct routing sip provider or a cloud ddi from microsoft?
