What is freaky is if I just remove the Contact header from the invite entirely I get a response from Teams.
So now I have Ringing working from Freeswitch to MSTeams. However the CLI is screwed up and showing a random number that isn’t formatted at all - 266696687 I can answer in Teams but that doesn’t get back to Freeswitch. I get one way audio From Teams and the teams client still says ringing If I hang up in Teams it doesn’t get back to Freeswitch and the freeswitcht end of the call stays open If I hang up in Freeswitch it does get back to Teams and the entire call is torn down After 30 secs the Teams client hangs itself up I honestly don’t know if I’m any closer or not What is uber frustrating is that Teams -> Freeswitch just works James James Hogbin Director IP Sentinel t. +44 (0)20 3011 4150 m. +44 7786910895 w. https://www.ip-sentinel.com On 12 May 2020, at 17:48, Ovidiu Sas <o...@voipembedded.com<mailto:o...@voipembedded.com>> wrote: 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 <ja...@ip-sentinel.com<mailto:ja...@ip-sentinel.com>> 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<http://adatum.biz/> of the FQDN name sbc1.adatum.biz<http://sbc1.adatum.biz/>) must match the wildcard value in Common Name/Subject Alternative Name (for example *.adatum.biz<http://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<http://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<http://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 <120051215543902783.png><http://ip-sentinel.com/> t. +44 (0)20 3011 4150<tel:+442030114150> m. +44 7786910895 w. https://www.ip-sentinel.com<https://www.ip-sentinel.com/> INVITE sip:+448435577...@sip.pstnhub.microsoft.com<mailto:sip%3a%2b448435577...@sip.pstnhub.microsoft.com>;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<http://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:+442030114146@13.80.245.144<mailto:sip%3A%2B442030114146@13.80.245.144>>;tag=16r7SU0B6KtpK To: <sip:08435577...@sbc.ip-sentinel.com:5091<http://sip:08435577...@sbc.ip-sentinel.com:5091/>> Call-ID: d8876893-0eff-1239-bdba-000d3aada04e CSeq: 20093096 INVITE Contact: <sip:gw+c6ff36e8-d3de-4fe0-9f1b-9da2888c43a9@13.80.245.144: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:+442030114146@13.80.245.144<mailto:sip%3A%2B442030114146@13.80.245.144>>;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 Users@lists.opensips.org<mailto:Users@lists.opensips.org> http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- VoIP Embedded, Inc. http://www.voipembedded.com<http://www.voipembedded.com/> _______________________________________________ Users mailing list Users@lists.opensips.org<mailto:Users@lists.opensips.org> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
