OK. I get it’s all easy when you know how the trick is done. Please could you help by suggesting which opensips default script you advise I start with if I have a FreeSWITCH pbx I want to connect to MSTeams for one domain only.
James James Hogbin Director IP Sentinel t. +44 (0)20 3011 4150 m. +44 7786910895 w. https://www.ip-sentinel.com >> On 11 May 2020, at 19:35, Ovidiu Sas <[email protected]> wrote: > What is to disagree here? :) > All I said is that MS's SIP implementation is rfc compliant and > there's no 'voodoo' SIP routing here. I did not say that is easy or > straight forward! > It is true that the blog assumes very good knowledge of OpenSIPS and > SIP protocol. And this is a requirement for any OpenSIPS deployment. > There's no config example in the blog because each deployment is > different. But *all* the required steps to integrate with MS are > outlined there with proper code snippets. > There's really no need to mess up with To,From,Contact headers. > > The fact that all communication between OpenSIPS and MS is encrypted > makes the troubleshooting more difficult. > And on top of that, there is this particular method of authentication > based on FQDNs and certificates. > Beside that, it's all standard SIP. > > Regards, > Ovidiu Sas > > >> On Mon, May 11, 2020 at 1:43 PM James Hogbin <[email protected]> wrote: >> >> I disagree. The blog pre assumes a MASSIVE amount of knowledge and >> configuration >> >> with a pre-existing opensips.conf routing set up >> >> Goodness knows what that is. It isn’t the Proxy set up or the Residential >> set up. I’ve tried both and neither work. >> >> It would be really helpful if the Blog started with which config file it is >> based on and went from there. >> >> With a lot of blind hacking around on the script I’ve got to the stage where >> >> Teams outbound works fine with a >> $rd="pbx.ip-sentinel.com"; >> $rp=5081; >> >> However to have the Inbound accepted by MS Teams I have to modify the TO, >> FROM add a ROUTE AND force the CONTACT >> strip(1); >> prefix("+44"); >> uac_replace_from( , "sip:[email protected]:5091"); >> uac_replace_to( , "sip:[email protected]"); >> $rd="sip.pstnhub.microsoft.com"; >> $rp=5061; >> record_route_preset("sbc.ip-sentinel.com:5091;transport=tls”); >> And in the route >> if(check_source_address(0)){ >> xlog("[INFO] FIX ACK CONTACT"); >> remove_hf("Contact"); >> append_hf("Contact: >> <sip:[email protected]:5091;transport=tls>\r\n”); >> And onroute_reply >> if(check_source_address(0)){ >> xlog("[INFO] FIX ACK CONTACT"); >> remove_hf("Contact"); >> append_hf("Contact: >> <sip:[email protected]:5091;transport=tls>\r\n”); >> >> However even with that I eventually miss an ACK and the whole thing falls >> over. Most frustrating! >> >> >> James Hogbin >> Director >> >> >> t. +44 (0)20 3011 4150 >> m. +44 7786910895 >> w. https://www.ip-sentinel.com >> >> On 11 May 2020, at 18:14, Ovidiu Sas <[email protected]> wrote: >> >> Microsoft’s SIP routing is RFC compliment. >> There’s no special routing for approved SBCs. The routing Is based on the >> type of SBC: B2BUA vs proxy, which again, is rfc complient. >> For OpenSiPS, which is a proxy, all the configuration steps are very well >> outlined in the blog. No need to mess with Via or Contact headers! Follow >> the loose routing rules as outlined in the rfc and all is good. >> >> Regards, >> Ovidiu Sas >> >>>> On Mon, May 11, 2020 at 05:51 Slava Bendersky via Users >>>> <[email protected]> wrote: >>> Hello All, >>> Microsoft is rely on approved sbc vendors, where most sbc are use VIA and >>> headers to route traffic. That why Contact header is important, also they >>> use from and to. >>> Opensips is rely on route headers and use different way to route it. >>> volga629 >>> ________________________________ >>> From: "John Quick" <[email protected]> >>> To: "OpenSIPS users mailling list" <[email protected]>, >>> [email protected] >>> Sent: Monday, May 11, 2020 6:19:50 AM >>> Subject: Re: [OpenSIPS-Users] OpenSIPS as Teams SBC >>> I agree completely with Ovidiu. >>> The Microsoft documentation says to use a FQDN in the Contact header, but >>> this is wrong when the SBC is acting as a SIP Proxy. >>> The blog post on the OpenSIPS website explains that actually the >>> Record-Route header needs the FQDN. >>> The one exception to this is the handling of OPTIONS pings - for these, >>> OpenSIPS is the end point so it must use a FQDN in Contact. >>> If you change the Contact header in call setup then you risk breaking the >>> path for sequential requests, such as ACK. >>> If ACK does not reach its destination, the call drops at one end after about >>> 20 seconds - exactly what you are seeing. >>> I have not yet found a good way to capture TLS encoded SIP. In theory, you >>> can use sngrep with the -k option to identify the path to the private key >>> file. >>> It would be necessary to start sngrep first, then start (or restart) >>> OpenSIPS. However, this never works for me. >>> I had more success using the siptrace module to capture the packets to a DB >>> table. Presenting it as a sequence diagram may be possible using the >>> OpenSIPS Control Panel. >>> Wireshark also has the ability to capture, decode and present TLS encrypted >>> SIP. >>> Another option might be to mirror the traffic to Homer in HEP format and >>> then use Homer to create the sequence diagram. >>> John Quick >>> Smartvox Limited >>> _______________________________________________ >>> Users mailing list >>> [email protected] >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> _______________________________________________ >>> 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 >> >> >> 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
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
