[OpenSIPS-Users] OpenSIPS as Teams SBC

[johan]

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 
> <users at lists.opensips.org <mailto:users at lists.opensips.org>> 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" <john.quick at smartvox.co.uk
>     <mailto:john.quick at smartvox.co.uk>>
>     *To: *"OpenSIPS users mailling list" <users at lists.opensips.org
>     <mailto:users at lists.opensips.org>>, james at ip-sentinel.com
>     <mailto:james at ip-sentinel.com>
>     *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
>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>     _______________________________________________
>     Users mailing list
>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> -- 
> VoIP Embedded, Inc.
> http://www.voipembedded.com
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200511/62196bfc/attachment.html>