Most likely the AudioCodec, Oracle and Ribbon are B2BUAs and there is no Route/Record-Route routing. Read about loose routing mechanism in SIP protocol to get a better understanding on how this headers are used in routing.
Regards, Ovidiu Sas On Tue, May 12, 2020 at 10:55 James Hogbin <[email protected]> wrote: > 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* > [image: IP Sentinel Logo] <http://ip-sentinel.com> > t. +44 (0)20 3011 4150 <+442030114150> > 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 > 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. > Q3dhRSrm_disclaimer > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- VoIP Embedded, Inc. http://www.voipembedded.com
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
