SIP refer in Direct routing sends internal Teams transfer to CUBE ?

[mrvoipstuff]

have recently setup direct routing on CUBE with Teams following the integration guide below

https://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise/interoperability-portal/direct-routing-with-cube.pdf

I noticed if a Teams client attempts to perform an internal transfer to another teams client it instead sends the REFER back out to CUBE as it were transferring externally out to PSTN. It ideally should stay within the Teams phone system as transfer was internal to another Teams user. If I disable the SIP refer and use standard INVITE then internal transfer works as normal without the request (INVITE) ever getting to CUBE. Only where it's an external transfer out to PSTN it sends the INVITE back to CUBE

Is there anything in the configuration (that +AAA@ I suspect) which sort of binds any refer messages to always be sent out CUBE's way ? I would like to use refer ideally as it's efficient compared to separate channel consumed by the INVITE. But doing so obviously causes the above issue. 

Appreciate any feedback. let me know if require to post SIP ladder/CCSIP trace. thanks. 

[Steven L]

so...what you are asking is not simple to answer.

if you are in MS teams and trying to transfer a call, the issue would be in your MS Phone System configuration.

In general, if it is sending it back to CUBE, it doesn't know how to get where you are trying to transfer to.

[mrvoipstuff]

Then how come it NOT send the request back for transfer when I change the method of transfer from REFER to INVITE. I think there's a catch-all phrase in that configuration guide that is possibly binding any transfer request to be sent back to SBC. I have seen another couple of posts where Teams ends up sending REFER back to SBC for internal transfers. Solution was to either disable refer (not recommended as Direct routing transfer is recommended via SIP refer) ... or 2nd edit the catch-all phrase somewhere in REFER config causing it be sent to SBC. I will share link of those posts soon. 

[Roger Kallberg]

Can you please outline the call flow and path of the call for where you see this happening? If it’s a call where the SBC is not in the path I agree with @Steven L that it doesn’t sound like it would be related to the configuration in the SBC for how to handle transfers. On the other hand if it is in the call path I would expect it to act just as you described in your original post even if the transfer recipient is a Teams client as the SBC would be involved in the call flow and with that be in the signaling path.

[mrvoipstuff]

Thanks for your reply.

call comes in from external mobile => ITSP => CUBE => Teams .. Teams client then transfers internally to another Teams user. principally the CUBE should not receive a REFER request back for it as it's internal but it does. Only way around is to disable REFER in SIP-profile 200 as below. When I do that then it does not send REFER back and internal transfer works. 

rule 130 request ANY sip-header Allow-Header modify " REFER," ""
rule 140 response ANY sip-header Allow-Header modify " REFER," ""

saw a similar post with Audiocodes SBC where REFER was disabled to allow for internal transfer to go thru. 

https://techcommunity.microsoft.com/t5/microsoft-teams/ms-teams-direct-routing-internal-call-transfer-failure/m-p/754902

[Roger Kallberg · Accepted solution]

Thank you for outlining the call flow. With what you describe I would say that the flow of SIP events is the expected one as the call is traversing the SBC, however the transfer should not fail when the REFER gets sent to the Cube. I did have a look briefly in the attached debug and from what I can tell the call fails with this reason.

818189: May 17 15:57:42.382 auest: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
NOTIFY sip:api-du-c-auea.pstnhub.microsoft.com:443;x-i=d7ebe1e2-3d56-4fe2-99d3-399dab129c81;x-c=e6dbdacafe0e5a978ed30099f703a96b/s/1/b4f6963a11734160b1721c62d39ff243 SIP/2.0
Via: SIP/2.0/TLS 10.82.184.20:5061;branch=z9hG4bK4526A4920
From: <sip:+61475704546@SBC.com>;tag=DFE24305-981
To: <sip:+61297655570@sip.pstnhub.microsoft.com>;tag=e47fc2eabdee47a39fdbc611e0458e2b
Call-ID: 266D433D-134911EF-A594A69F-3BB85EF@SBC.com
CSeq: 103 NOTIFY
Max-Forwards: 70
Date: Fri, 17 May 2024 05:57:42 GMT
User-Agent: Cisco-SIPGateway/IOS-17.6.5
X-MS-SBC: Cisco UBE/ISR4431/IOS-17.6.5
Event: refer
Subscription-State: terminated;reason=noresource
Route: <sip:sip-du-a-au.pstnhub.microsoft.com:5061;transport=tls;lr>
Contact: <sip:+61475704546@SBC.com:5061;transport=tls>
Content-Type: message/sipfrag
Content-Length: 34

SIP/2.0 484 Address Incomplete

Why that is I'm not clear about as it's not that easy to find anything related to this in your output. I ran it trough TranslatorX as well, but it didn't do a very good job at filtering out the events for just this single call, so it didn't give that much. You might be looking at a session with TAC on this as it's a quite specific issue that might not be all that common so others in the community might not have run into it.

[mrvoipstuff]

thanks for the insight - much appreciated  

yes that trace was during busy hours. I just did another test and took a cleaner capture during after hours .. Issue as you pointed out is in NOTIFY msg.

Was it normal for CUBE though to receive REFER at the first place ? Shouldn't Teams Phone system just look up the user and transfer. Asking as TAC might ask same question why is REFER hitting CUBE at the first place and ask to redirect issue to Microsoft ? If I disable REFER then no REFER ever hits the CUBE and Teams does the internal transfer fine. 

[Roger Kallberg]

Please do not post debug output, or any other big chunk of text directly into a post as that makes it so much harder to read and work on.

[mrvoipstuff]

My apologies. had an error with attachment  ...

I did a voip ccapi and dial peer trace .. preceding the address incomplete message it shows dial-peer is not matching which may be my issue ?  

[Roger Kallberg]

If dial-peer 280 isn't matched for the outbound part that would in my mind mean that you're not matching dial-peer 290 in the inbound direction as that is meant to add the route prefix for the referral. Do a debug voip ccapi inout togheter with debug voip dialpeer, debug voip translation and debug ccsip messages to see what's really happening here. If you want help looking at it post the output from all debugs in one text file and tell the called, calling, transfer numbers and time of the call so we can find it in the output.

[mrvoipstuff]

thanks again for your reply. 

I have attached the debug. Timestamp is 13:00:29 with CUBE's ITSP call leg "BW1300293551805241762350149" and Teams call leg is "9E360610-13F911EF-AA0086FA-86E44DFC". Refer call-leg is "9E360610-13F911EF-AA0086FA-86E44DFC" at 13:00:54.666. You'll see some other calls in trace to CUCM so just ignore those

[Roger Kallberg]

I haven’t checked the debug output yet, but I did quickly check your shared running config and I see this in it that you’re not following the configuration in the documentation.

dial-peer voice 290 voip
 incoming called-number .T

Remove the match for .T and try to see if there is any difference. Why have you added this to the inbound dial peer? It is supposed to use information in the To header to match the calls inbound, not called numbers.

Also you likely know this already, but you don’t need to use the bind statements on the dial peers when you have the same bind configuration on the tenant.

[mrvoipstuff]

sorry yes i shouldn't have required incoming called-number .T as I already had incoming URI. It would have matched using URI though over incoming called-number .T due to higher preference .. i have removed incoming called-number .T from DP 290 but same result. SIP notify following Refer accepted shows 484 Address Incomplete. 

yes correct about DP's not requiring bind statement if already on tenant. May have left it there from initial configuration before configuring multi tenant.. 

[mrvoipstuff]

not sure if this matters but I notice when there's a normal outgoing call from Teams => CUBE => ITSP ... then CUBE's name is exactly how is defined in voice class uri i.e. all small letters

voice class uri 290 sip 

host sbc.com => all small letters 

But when the REFER msg. comes in from Teams to CUBE the TO field (not referring to "REFER-TO:" field but TO:) then host portion of SBC is in capital but domain portion in small as below 

If the AAA prefix will be done after it matches DP 290 "To" Field .. But SBC name is not matching case-sensitivity as above would it still match DP 290 ? Probably NO ? 

[Roger Kallberg]

That is easy enough to test/verify, just add another line to the voice class 290 that is in upper case SBC.

voice class uri 290 sip
 host sbc.example.com
 host SBC.example.com

I did check the debug now when I'm on a computer and from what I can tell it is not matching dail peer 290 inbound and it is not therefore doing the add of the route string by SIP profile 290 that dial peer 280 needs to match outbound, so that isn't matched either. Before you get dial peer 290 to match you should not expect that the REFER transfer will work as it should. I only see dial peer 60 being matched inbound for this specific call.