<html><body>So I’ve now restarted my script from scratch.<BR>
<BR>
I’ve distilled what I’ve understood from everybody’s suggestions. BUT There is a total disconnect between the advice and what I can find elsewhere<BR>
<BR>
The AudioCodec, Oracle and Ribbon SBC instructions all say you have to modify the Contact and don’t mention Record-Routes at all. <BR>
e.g. <a href="https://www.audiocodes.com/media/13161/connecting-audiocodes-sbc-to-microsoft-teams-direct-routing-hosting-model-configuration-note.pdf" target="_blank">https://www.audiocodes.com/media/13161/connecting-audiocodes-sbc-to-microsoft-teams-direct-routing-hosting-model-configuration-note.pdf</a><BR>
<BR>
The Microsoft Docs major on the Contact throughout<BR>
<BR>
The Microsoft Docs say the Teams takes the FQDN name presented in the Contact header and matches it to the Common Name or Subject Alternative name of the presented certificate. The SBC name must match one of the following options:<BR>
• Option 1. The full FQDN name presented in the Contact header must match the Common Name/Subject Alternative name of the presented certificate.<BR>
• Option 2. The domain portion of the FQDN name presented in the Contact header (for example adatum.biz of the FQDN name sbc1.adatum.biz) must match the wildcard value in Common Name/Subject Alternative Name (for example *.adatum.biz).<BR>
<BR>
Then it says<BR>
Try to find a tenant using the full FQDN name presented in the Contact header.<BR>
<BR>
So the initial validation is done by the domain part of the contact <BR>
And to find the teams user it uses the phone number presented in the Request-URI and the the domain extracted from the Contact Header<BR>
<BR>
If I assume that contact header can be replaced with Record_Route throughout as the MS Docs say this<BR>
Per RFC 3261, Record-Route is used if a proxy wants to stay on the path of future requests in a dialog, which is not essential as all traffic goes between the Microsoft SIP proxy and the paired SBC.<BR>
<BR>
So the validation should work as the Record-Route is sbc.ip-sentinel.com as is the common name of my SSL cert<BR>
And the teams user should work as the URI has +448435577721 with the striped domain of ip-sentinel.com<BR>
<BR>
I’ve set the RTP proxy to work only on the approved Microsoft Ports<BR>
There are matching Codecs & Crypto in the INVITE<BR>
<BR>
Anyway It doesn’t work and I don’t get a 183 back from Teams so something Isn’t right. <BR>
<BR>
Is anybody able to help?<BR>
<br>
<p style="font-family: Open Sans,sans-serif;">
<b><span style="font-family: Open Sans,sans-serif; font-size:10.0pt;color:#888888">James Hogbin</span></b>
<b><span style="font-family: Open Sans,sans-serif;font-size:8.0pt;color:#888888;"><br>Director</span></b>
</p>
<table border="0" cellspacing="0" cellpadding="0"><tr><td><a href="http://ip-sentinel.com"><IMG border="0" alt="IP Sentinel Logo" src="cid:120051215543902583@uk-mta-8.uk.mimecast.lan" ></A></td></tr></table>
<span style="font-family: Open Sans,sans-serif;font-size:8.0pt;color:#222222;"><br>t. <a href="tel:+442030114150" target="_blank">+44 (0)20 3011 4150</a><br></span><span style="font-family: Open Sans,sans-serif;font-size:8.0pt;color:#222222;">m. +44 7786910895<br></span><span style="font-family: Open Sans,sans-serif;font-size:8.0pt;color:#222222">w. <a href="https://www.ip-sentinel.com/" target="_blank">https://www.ip-sentinel.com</a><br></span><table>
<tbody><tr>
</tr>
<tr>
</tr>
<tr>
</tr>
<tr>
</tr>
</tbody></table>
<br>
<BR>
INVITE sip:+448435577721@sip.pstnhub.microsoft.com;transport=tls SIP/2.0<BR>
Record-Route: <sip:sbc.ip-sentinel.com:5091;transport=tls;ftag=16r7SU0B6KtpK;lr><BR>
Via: SIP/2.0/TLS sbc.ip-sentinel.com:5091;branch=z9hG4bK572.dcd29dc1.0;i=4c23cbf2<BR>
Via: SIP/2.0/TLS 13.80.245.144:5081;received=13.80.245.144;rport=52283;branch=z9hG4bK78XZF1S4c7mcK<BR>
Max-Forwards: 68<BR>
From: "James Hogbin" <sip:+442030114146@13.80.245.144>;tag=16r7SU0B6KtpK<BR>
To: <sip:08435577721@sbc.ip-sentinel.com:5091><BR>
Call-ID: d8876893-0eff-1239-bdba-000d3aada04e<BR>
CSeq: 20093096 INVITE<BR>
Contact: <sip:gw+c6ff36e8-d3de-4fe0-9f1b-9da2888c43a9@13.80.245.144:5081;transport=tls;transport=tls;gw=c6ff36e8-d3de-4fe0-9f1b-9da2888c43a9><BR>
User-Agent: FreeSWITCH<BR>
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY<BR>
Supported: timer, path, replaces<BR>
Allow-Events: talk, hold, conference, refer<BR>
Content-Type: application/sdp<BR>
Content-Disposition: session<BR>
Content-Length: 1337<BR>
X-FS-Support: update_display,send_info<BR>
Remote-Party-ID: "James Hogbin" <sip:+442030114146@13.80.245.144>;party=calling;screen=yes;privacy=off<BR>
<BR>
v=0<BR>
o=FreeSWITCH 1589277340 1589277341 IN IP4 13.80.245.144<BR>
s=FreeSWITCH<BR>
c=IN IP4 137.117.136.143<BR>
t=0 0<BR>
m=audio 51904 RTP/SAVP 9 0 8 101 13<BR>
a=rtpmap:9 G722/8000<BR>
a=rtpmap:0 PCMU/8000<BR>
a=rtpmap:8 PCMA/8000<BR>
a=rtpmap:101 telephone-event/8000<BR>
a=fmtp:101 0-16<BR>
a=rtpmap:13 CN/8000<BR>
a=crypto:1 AEAD_AES_256_GCM_8 inline:DG1mX1BHpFLdw8k3JD9Cc/NNJXVXsIibm9DoLwFuy6Wh6rNrrrW7aRxREV8=<BR>
a=crypto:2 AEAD_AES_128_GCM_8 inline:twu/t4tyHNqeXymfQZzwSz0wg9j5CQ3ggoFVOg==<BR>
a=crypto:3 AES_256_CM_HMAC_SHA1_80 inline:2zxvdvVA926CvgMT8Izr5td0Sow0kIUx0y/yGSq7DB+lR3+BhNC+IDohjVwu4w==<BR>
a=crypto:4 AES_192_CM_HMAC_SHA1_80 inline:7naCIyPWQBn4rNZ9Eat/GIK6p1EEEYsLVuvdQKH5qIPoKW7nIIw=<BR>
a=crypto:5 AES_CM_128_HMAC_SHA1_80 inline:vm8K2XDqGiYTLg3dQdnEIas77/KPKj2WFwblhjmw<BR>
a=crypto:6 AES_256_CM_HMAC_SHA1_32 inline:ErFJEbtVQ1eUlAYKy5I4SqluECiVvQt7TtASS3krfin10adczd+Y5SgnuzY1Nw==<BR>
a=crypto:7 AES_192_CM_HMAC_SHA1_32 inline:jiuXK2Ggee9ZwAhR/EL6eqrWazSHnZoeyQP4RK1EwLdIjgNOPmc=<BR>
a=crypto:8 AES_CM_128_HMAC_SHA1_32 inline:5WZHbfW6Oy8zKnGELuDMFpmeirx0YEUCTkH+d3O3<BR>
a=crypto:9 AES_CM_128_NULL_AUTH inline:MZF6zzwHeiJvX90BGmfjbSbKwBDGyLsP/rGEqMl7<BR>
a=ptime:20<BR>
m=audio 52500 RTP/AVP 9 0 8 101 13<BR>
a=rtpmap:9 G722/8000<BR>
a=rtpmap:0 PCMU/8000<BR>
a=rtpmap:8 PCMA/8000<BR>
a=rtpmap:101 telephone-event/8000<BR>
a=fmtp:101 0-16<BR>
a=rtpmap:13 CN/8000<BR>
a=ptime:20<BR>
a=nortpproxy:yes<BR>
<p style="font-family: Open Sans, Arial, sans-serif;padding: 5px;background:#D5EAFF">
<span style="font-family: Open Sans,sans-serif;font-size:8.0pt;color:red">IP Sentinel Disclaimer <br></span>
<span style="font-family: Open Sans,sans-serif;font-size:6.0pt;color:black">The information contained in this e-mail, and any attachment, is confidential and is intended solely for the use of the intended recipient. Access, copying or re-use of the e-mail or any attachment, or any information contained therein, by any other person is not authorized. Unintended recipients are prohibited from taking action on the basis of information in this e-mail. If you are not the intended recipient or have received this email in error, please notify the sender immediately by return email and delete the email from your computer.
E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. We do not guarantee that either are virus-free and accept no liability for any damage sustained as a result of computer viruses or other defects.
. IP Sentinel Ltd is a limited company registered in England and Wales under Registered Number 08648097. Registered Office: Newnhams Wood, Horsted Keynes, West Sussex, RH17 7BT. </span>
</p><span style="font-size:1.0pt;color:white">Q3dhRSrm_disclaimer</span>
</body></html>