Ovidiu
do you have any idea why refer-to user part can be empty in refer coming
from teams ?
On 11/05/2020 19:14, Ovidiu Sas 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] <mailto:[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]
<mailto:[email protected]>>
*To: *"OpenSIPS users mailling list" <[email protected]
<mailto:[email protected]>>, [email protected]
<mailto:[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] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected] <mailto:[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
