So I’ve now restarted my script from scratch. 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
The AudioCodec, Oracle and Ribbon SBC instructions all say you have to modify the Contact and don’t mention Record-Routes at all. e.g. https://www.audiocodes.com/media/13161/connecting-audiocodes-sbc-to-microsoft-teams-direct-routing-hosting-model-configuration-note.pdf The Microsoft Docs major on the Contact throughout 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: • Option 1. The full FQDN name presented in the Contact header must match the Common Name/Subject Alternative name of the presented certificate. • 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). Then it says Try to find a tenant using the full FQDN name presented in the Contact header. So the initial validation is done by the domain part of the contact 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 If I assume that contact header can be replaced with Record_Route throughout as the MS Docs say this 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. So the validation should work as the Record-Route is sbc.ip-sentinel.com as is the common name of my SSL cert And the teams user should work as the URI has +448435577721 with the striped domain of ip-sentinel.com I’ve set the RTP proxy to work only on the approved Microsoft Ports There are matching Codecs & Crypto in the INVITE Anyway It doesn’t work and I don’t get a 183 back from Teams so something Isn’t right. Is anybody able to help? James Hogbin Director IP Sentinel t. +44 (0)20 3011 4150 m. +44 7786910895 w. https://www.ip-sentinel.com INVITE sip:[email protected];transport=tls SIP/2.0 Record-Route: <sip:sbc.ip-sentinel.com:5091;transport=tls;ftag=16r7SU0B6KtpK;lr> Via: SIP/2.0/TLS sbc.ip-sentinel.com:5091;branch=z9hG4bK572.dcd29dc1.0;i=4c23cbf2 Via: SIP/2.0/TLS 13.80.245.144:5081;received=13.80.245.144;rport=52283;branch=z9hG4bK78XZF1S4c7mcK Max-Forwards: 68 From: "James Hogbin" <sip:[email protected]>;tag=16r7SU0B6KtpK To: <sip:[email protected]:5091> Call-ID: d8876893-0eff-1239-bdba-000d3aada04e CSeq: 20093096 INVITE Contact: <sip:[email protected]:5081;transport=tls;transport=tls;gw=c6ff36e8-d3de-4fe0-9f1b-9da2888c43a9> User-Agent: FreeSWITCH Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: timer, path, replaces Allow-Events: talk, hold, conference, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 1337 X-FS-Support: update_display,send_info Remote-Party-ID: "James Hogbin" <sip:[email protected]>;party=calling;screen=yes;privacy=off v=0 o=FreeSWITCH 1589277340 1589277341 IN IP4 13.80.245.144 s=FreeSWITCH c=IN IP4 137.117.136.143 t=0 0 m=audio 51904 RTP/SAVP 9 0 8 101 13 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 a=crypto:1 AEAD_AES_256_GCM_8 inline:DG1mX1BHpFLdw8k3JD9Cc/NNJXVXsIibm9DoLwFuy6Wh6rNrrrW7aRxREV8= a=crypto:2 AEAD_AES_128_GCM_8 inline:twu/t4tyHNqeXymfQZzwSz0wg9j5CQ3ggoFVOg== a=crypto:3 AES_256_CM_HMAC_SHA1_80 inline:2zxvdvVA926CvgMT8Izr5td0Sow0kIUx0y/yGSq7DB+lR3+BhNC+IDohjVwu4w== a=crypto:4 AES_192_CM_HMAC_SHA1_80 inline:7naCIyPWQBn4rNZ9Eat/GIK6p1EEEYsLVuvdQKH5qIPoKW7nIIw= a=crypto:5 AES_CM_128_HMAC_SHA1_80 inline:vm8K2XDqGiYTLg3dQdnEIas77/KPKj2WFwblhjmw a=crypto:6 AES_256_CM_HMAC_SHA1_32 inline:ErFJEbtVQ1eUlAYKy5I4SqluECiVvQt7TtASS3krfin10adczd+Y5SgnuzY1Nw== a=crypto:7 AES_192_CM_HMAC_SHA1_32 inline:jiuXK2Ggee9ZwAhR/EL6eqrWazSHnZoeyQP4RK1EwLdIjgNOPmc= a=crypto:8 AES_CM_128_HMAC_SHA1_32 inline:5WZHbfW6Oy8zKnGELuDMFpmeirx0YEUCTkH+d3O3 a=crypto:9 AES_CM_128_NULL_AUTH inline:MZF6zzwHeiJvX90BGmfjbSbKwBDGyLsP/rGEqMl7 a=ptime:20 m=audio 52500 RTP/AVP 9 0 8 101 13 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 a=ptime:20 a=nortpproxy:yes IP Sentinel Disclaimer This communication is for the information of the person to whom it has been delivered and neither it nor any of its contents should be passed on to or used by any other person. 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. Disclaimer: Q3dhRSrm_disclaimer
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
