Consult then transfer to call queue is not working

[Lars86]

Hi,

We are using teams with direct routing option.

Everything is working fine but we cannot use the option consult then transfer to a call queue.

You can call the call queue and get a user on the phone but the option to transfer the call disappears.

Consult and transfer to a direct users is working fine!

And a direct transfer without consult to a call queue is also working fine...

Anybody has the same issue and is there a solution for this problem?

Hope you can help!

Greetings,

Lars

[#2]

@Lars86 Today I received the following answer from Microsoft after they had analyzed the Log-Files from my Teams Client and SBC (AudioCodes):

"

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

I will now call my Colleagues who manage our SBC. When I understand everything correct the problem can be solved with a reconfigured IP Profile.

regards
Thorsten

[#3]

Hi thorsten,

Thanks for the update! I am going to ask our external partner For the sbc to look info this... is Microsoft Closing Your ticket? Hope we can fix it!

Greetings,

Lars

[#4]

We just ran a test purely in Teams (no Direct Routing) and get the same behaviour:
User 1 calls User 2
User 2 does consult with a Teams Queue
User 3 answers.
User 2 is talking with User 3, and sees User 1 as on hold with no option to complete the transfer

Can anyone else reproduce this without Direct Routing? I think the Direct Routing aspect is a distraction and it is a core Microsoft issue.

[#5]

@Thorsten Stiebig Any news on your microsoft case?

[#6]

@Lars86 No news actual. The Microsoft Support Team had technical issues because of a Cyclone in India.

I also have no feedback from my colleagues because of the SBC. 

[#7]

@Thorsten Stiebig just to add some notes which I could not see here, but it seems that I am experiencing the same issue, except that as I am a member of one of the Queues, I can find the name of the queue I am a member of but not any others, I also cannot transferor consult then transfer to them now, and it was working when we were preparing my company for migration to Teams.

to conclude;

1. Unable to transfer or consult then transfer to any Queue I am not a member of!

2. It was working 3-4 weeks ago, when I was testing prior to migration.

3. This is nothing to do with the SBC (I have an Audiocodes SBC), as I cannot transfer with internal or external calls. I have also had mine checked by Audiocodes Support.

Did Microsoft come back with anything yet?

Here's hoping this will provide further insight  

[#8]

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

[#9]

@TeamsDR It seems that you have the same (similar) issue.

We have also a AudioCodes SBC for Direct Routing.

Transfer a PSTN Call to a Call queue works fine for us. Even when I am a member of that Call queue. I am able to see and find all my call queues for the simple call transfer.

The issue we have is that we can not "consult then transfer" a pstn call to a call queue.

Microsoft Support actual believes that the issue is on the audiocodes SBC which we are thinking ist not.

[#10]

@Thorsten Stiebig I believe this is an issue with Teams, as all the SBC does is handle the inbound and outbound calls routes and does not have any visibility of what goes on within the Teams Environment.

Microsoft should be able to provide details of any fields that are missing within the SIP message, then the SBC can add that field, but  it does not delete unless yo specify it to delete this field within the SIP message.

You can do message manipulation, but you will need to know what to add to the message, so AudioCodes can provide more help, this information must be supplied by Microsoft. 

it is like reporting from the SBC pointless if you need to know who the call finally went to and where they forwarded it on to, the SBC cannot provide this information as it all resides within the Teams Environment.

[#11 · Accepted solution]

@Lars86 

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

[#12]

@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?

[#13]

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

[#14]

@TeamsDR Here also we are still waiting on research from microsoft! our provider did a capture yesterday so hope they can find something in the logs and can send it to microsoft!

Still waiting for a good solution for this and in the mean time keep providing log files...

[#15]

@Lars86  - it seems that the support rep I had looked into this further, and found that putting a DDI there would not work, and that Microsoft is working on this, and for me they are going to deploy a fix in July, as a lot of other tenants have had the same issue.

[#16]

@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).

[#17]

@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?

[#18]

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

[#19]

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

[#20]

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

[#21]

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