Hello Joahn, No, I don't! Sorry :( Bring this up with their support team.
I ran a few quick tests and REFER is properly populated for both blind and attended transfer. Regards, Ovidiu Sas On Mon, May 11, 2020 at 1:33 PM johan <jo...@democon.be> wrote: > > 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@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.qu...@smartvox.co.uk> >> To: "OpenSIPS users mailling list" <users@lists.opensips.org>, >> ja...@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@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> _______________________________________________ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- > VoIP Embedded, Inc. > http://www.voipembedded.com > > _______________________________________________ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- VoIP Embedded, Inc. http://www.voipembedded.com _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
