[OpenSIPS-Users] OpenSIPS as Teams SBC
Ovidiu Sas
osas at voipembedded.com
Tue May 12 16:48:38 EST 2020
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 <james at 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 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:+448435577721 at 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
> ;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 at 13.80.245.144>;tag=16r7SU0B6KtpK
> To: <sip:08435577721 at sbc.ip-sentinel.com:5091>
> Call-ID: d8876893-0eff-1239-bdba-000d3aada04e
> CSeq: 20093096 INVITE
> Contact: <sip:gw+c6ff36e8-d3de-4fe0-9f1b-9da2888c43a9 at 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 at 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 at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
--
VoIP Embedded, Inc.
http://www.voipembedded.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200512/4ce20504/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 120051215543902783.png
Type: image/png
Size: 3317 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20200512/4ce20504/attachment-0001.png>
More information about the Users
mailing list