Chris, it is not about removing lines from the script. It is about not executing those lines when they are inappropriate. i.e. "for any SIP requests or SIP responses coming from MS Teams"
Mark, there are several gotchas that I know of with Teams, but I cannot guess which might apply in your case unless you are able to supply more details. Is your problem with calls from Teams? Which end is hanging up first and generating the BYE? Has a loose routed SIP request already got through okay in that direction - e.g. ACK? Did you leave the call connected for at least 30 seconds to make sure the call setup worked? Here are some of the gotchas I know about that are not fully covered in the blog: *The double RR headers using FQDN mentioned in the blog must be added to initial INVITE requests to and from the Teams Proxy - calls in *both* directions *Version 2.4.7 of OpenSIPS (and some v3 releases) have a bug that means RR parameters are not always added - e.g. "r2=on" *Do not send RR headers to Teams with ";lr=on" as can happen if you have a Kamailio Proxy in the path. It must just be ";lr" *Don't call fix_nated_contact for any SIP request or response coming from MS Teams *Don't let any downstream Proxy call fix_nated_contact for those requests either *If you want an easy life, remove REFER from the Allow header in INVITE's to Teams and in 200 OK responses being returned to it I used the siptrace module to capture the SIP packets passing between my SBC and the Teams Proxy because I had no luck with sngrep decrypting the TLS even when I pointed it to the certificate key. You need to be able to inspect those packets to make sure the headers look correct, the ports and protocols are as expected, etc. In the case of BYE not getting a response, you could check exactly what is in the Via headers within the BYE. John Quick Smartvox Limited Web: www.smartvox.co.uk _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
