Forum Discussion
MS Teams Direct Routing - Internal call transfer failure
Hi all, My organisation is planning a move to direct routing. We have an AudioCodes VE SBC. I've been working on this for awhile and got everything to a pretty decent state. I've come across ...
the thing is that SBC should only respect Refer-to header by means of SIP. REFER comes without user part but it's still fair enough and legal. So what my SBC does as last resort to send INVITE out is DNS query for hostname in Refer-To and fills RURI and To in same fashion:
INVITE sip:sip.pstnhub.microsoft.com:5061;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689;transport=tls SIP/2.0
Via: SIP/2.0/TLS 192.168.65.100:5061;branch=z9hG4bKvahihb0040adpr8tb320.1
CSeq: 1 INVITE
Contact: <sip:sbc.customers.matejandfriends.com:5061;transport=tls>;sip.ice
From: <sip:+18572996345@sip.pstnhub.microsoft.com:5060;user=phone>;tag=11241SIPpTag011
To: <sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689>
Content-Type: application/sdp
Content-Length: 425
Referred-By: <sip:sip.pstnhub.microsoft.com:5061;x-m=8:orgid:bdc0511a-4a8d-48aa-bf1d-5ea6ef316e2a;x-t=2d88cb42-f810-417a-a0fc-80244a7fdd61;x-ti=9cfa2ad6-c73e-402d-b621-90d9af6ffea2;x-tt=ahr0chm6ly9hcgktzhutys1ldxdllnbzdg5odwiubwljcm9zb2z0lmnvbs92ms9uz2mvy2fsbg5vdglmawnhdglvbj9ky2k9yje2odmxntuwyjuwndg3mzk4nja4ndhlmgflyznimwq%3d>
Call-ID: 8f09e11d9183f754c525a0d4ce2aea46
Supported: replaces
Max-Forwards: 70</sip:sip.pstnhub.microsoft.com:5061;x-m=8:orgid:bdc0511a-4a8d-48aa-bf1d-5ea6ef316e2a;x-t=2d88cb42-f810-417a-a0fc-80244a7fdd61;x-ti=9cfa2ad6-c73e-402d-b621-90d9af6ffea2;x-tt=ahr0chm6ly9hcgktzhutys1ldxdllnbzdg5odwiubwljcm9zb2z0lmnvbs92ms9uz2mvy2fsbg5vdglmawnhdglvbj9ky2k9yje2odmxntuwyjuwndg3mzk4nja4ndhlmgflyznimwq%3d></sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689></sip:+18572996345@sip.pstnhub.microsoft.com:5060;user=phone></sip:sbc.customers.matejandfriends.com:5061;transport=tls>
and that's just enough...
obviously we dont use same vendor SBC but standard wise logic should remain the same
yep, tend to be with you on conclusions. being forced to implement both in real life felt like sharing things people find useful 🙂 Most important is we understand now how to implement both methods and logic MS uses to trigger each.
cheers!
All right, just to clarify, I've got this sorta working, I was removing REFERRED-BY header when placing a new INVITE and that's why it couldn't connect the call, after leaving that header intact the call can be transferred. But this far for us it's much easier just to remove REFER method from the list of allowed methods, otherwise it's quite a complex setup with our SBC. Thanks everyone for replies, now we have two working methods that allow call to be transferred to internal MS Teams users!
Here's my INVITE packet, I had to remove triangle brackets to make post clear:
INVITE sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:7709b36f-1f10-4b1c-8a0f-9c0e5390c86c SIP/2.0
Via: SIP/2.0/TLS X.X.X.X:5061;branch=z9hG4bKf26f.503bdc4.0;i=54849946
From: "XXXXXXX";tag=a1d8a1ca-d330-4251-811d-35fa1a797c64&;
To: sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:7709b36f-1f10-4b1c-8a0f-9c0e5390c86c
Call-ID: 1fa2f0d0-ba41-4e4d-83be-fbef9d0739c6
CSeq: 10432 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 69
Content-Type: application/sdp
Content-Length: 346
Contact: sip:gateway@sbc.xxx.xxx.com:5061;transport=TLS
Hi,
Unfortunately, that doesn't work for me, I'm sending same INVITE packet as you do but I'm getting back a '400 Bad Request' with a REASON:
REASON: Q.850;cause=111;text="a5d458f9-14c0-4cc4-8c10-202277af11e9;Unable to parse RURI."Thanks for detailed description, I will try to reproduce this behaviour on my SBC, but it looks really strange to me that MS sends a SIP REFER packet back to SBC that connects calls to PSTN and uses LineURI telephone numbers for that. According to RFC it should provide a proper username or DID in such case. From what I can see now it's much simpler to just disallow REFER method and let Microsoft Teams handle internal call transfers on their side, which is more logical, rather than implementing such call forking. Anyway, your help is much appreciated and SIP INVITE packet is a perfect example on what I should try to achieve. Thanks!
