The MS documentation should be taken with a grain of salt. For SIP proxies there’s no need for an FQDN in the Contact header, instead an FQDN is required in the top Record-Route header. The FQDN is required in the Contact header of the OPTIONS ping because this is a direct message between the proxy and MS and there are no Record-Route headers in this particular SIP request. Everything is covered by the blog posted on the OpenSIPS website. Each item/step can be implemented as described there or slightly different, based on one’s needs.
Regards, Ovidiu Sas On Sun, May 10, 2020 at 12:27 James Hogbin <ja...@ip-sentinel.com> wrote: > OK. > > Thank you for the Record_Route_Preset fix. I had followed the example > without understanding what it was doing. It always seemed odd to put the > 5060 port after the TLS port. I understand why now. And more importantly > why not to do it. > > Adding a * to the listen port caused an error in the script. I’m running > 3.0.2 if that matters? > > However the routing is still not working correctly > > if (is_method("INVITE") && !has_totag() && > check_source_address(0)) { > xlog("[ROUTE]Incoming call to MS: RURI=$ruri, SI=$si, > M=$rm\n"); > strip(1); > prefix("+44"); > uac_replace_from( , "sip:$f...@sbc.ip-sentinel.com:5091"); > > $rd="sip.pstnhub.microsoft.com"; > $rp=5061; > > $var(ct) = $ct; > xlog("[INFO] Old Contact = $var(ct)\n”); > > remove_hf("Contact"); > append_hf("Contact: < > sip:$f...@sbc.ip-sentinel.com:5091;transport=tls>\r\n"); > > record_route_preset("sbc.ip-sentinel.com:5091 > ;transport=tls"); > > route(relay); > > > This routes the call from Zoiper -> Freeswich -> OpenSIPS -> Teams and I > get ringing. > > If I pick up the call In Teams the Zopier client knows it has been > accepted. > I can hang up the call from Zoiper and Teams hangs up > > I don’t get Audio from Zoiper -> Teams but I do get Audio from Teams back > to Teams with a slight delay > Teams then hangs up the call after 20 seconds but the call remains open on > Zoiper > > I’m pretty sure it has something to do with how/where I’m fixing the > contact. Any suggestions? > > Also how do I get one of those nice sip traffic flows given everything is > on TLS? I’m grabbing stuff out of the debug log and it’s not pretty. > > > For future reference this is a great resource on MSTeams expected SIP > traffic > https://docs.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip > > For all incoming calls to the Microsoft SIP proxy, the Contact header must > have the paired SBC FQDN in the URI hostname as follows: > Syntax: Contact: <sip:phone or sip address@FQDN of the SBC;transport=tls> > > If more than one value in the Contact header presented in a SIP message is > sent by the SBC, only the FQDN portion of the first value of the Contact > header is used. > > Use of an IP address is not supported in either Record-Route or Contact. > The only supported option is an FQDN, which must match either the Common > Name or Subject Alternative Name of the SBC certificate (wildcard values in > the certificate are supported). > • If an IP address is presented in Record-route or Contact, the > certificate check fails and the call fails. > • If the FQDN does not match the value of the Common or Subject > Alternative Name in the presented certificate, the call fails. > > But there is nothing in the instructions in the > https://blog.opensips.org/2019/09/16/opensips-as-ms-teams-sbc/ that > specifies fixing the contact in anything other than OPTIONS > > > > > > *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 > > On 8 May 2020, at 09:12, John Quick <john.qu...@smartvox.co.uk> wrote: > > James, > > Just to add to Alexey's last comment, if your SBC *is* changing the > transport from UDP to TLS, then you must ensure the correct socket is used > on the SBC when it is sending requests to the Teams Proxy: > force_send_socket(tls:137.117.136.143:5091); > > You may also find it helpful to add " AS sbc.ip-sentinel.com:5091" on the > end of your tls listen statement > > John Quick > Smartvox Limited > Web: www.smartvox.co.uk > > > 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 > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- VoIP Embedded, Inc. http://www.voipembedded.com
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users