[OpenSIPS-Users] Opensips MS Teams lost BYE

[John Quick]

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