I disagree.  The blog pre assumes a MASSIVE amount of knowledge and 
configuration

with a pre-existing opensips.conf routing set up

Goodness knows what that is.  It isn’t the Proxy set up or the Residential set 
up.  I’ve tried both and neither work.

It would be really helpful if the Blog started with which config file it is 
based on and went from there.

With a lot of blind hacking around on the script I’ve got to the stage where

Teams outbound works fine with a
             $rd="pbx.ip-sentinel.com<http://pbx.ip-sentinel.com>";
             $rp=5081;

 However to have the Inbound accepted by MS Teams I have to modify the TO, FROM 
add a ROUTE AND force the CONTACT
  strip(1);
                prefix("+44");
                uac_replace_from( , "sip:[email protected]:5091");
                uac_replace_to( , "sip:[email protected]");
                
$rd="sip.pstnhub.microsoft.com<http://sip.pstnhub.microsoft.com>";
                $rp=5061;
                
record_route_preset("sbc.ip-sentinel.com:5091<http://sbc.ip-sentinel.com:5091>;transport=tls”);
And in the route
      if(check_source_address(0)){
                xlog("[INFO] FIX ACK CONTACT");
                remove_hf("Contact");
                append_hf("Contact: 
<sip:[email protected]:5091;transport=tls>\r\n”);
And onroute_reply
      if(check_source_address(0)){
                xlog("[INFO] FIX ACK CONTACT");
                remove_hf("Contact");
                append_hf("Contact: 
<sip:[email protected]:5091;transport=tls>\r\n”);

However even with that I eventually miss an ACK and the whole thing falls over. 
 Most frustrating!

James Hogbin
Director 
 
IP Sentinel 
t. +44 (0)20 3011 4150
m. +44 7786910895
w. https://www.ip-sentinel.com

On 11 May 2020, at 18:14, Ovidiu Sas 
<[email protected]<mailto:[email protected]>> 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<http://www.voipembedded.com/>
_______________________________________________
Users mailing list
[email protected]<mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

IP Sentinel Disclaimer 
This communication is for the information of the person to whom it has been 
delivered and neither it nor any of its contents should be passed on to or used 
by any other person. IP Sentinel Ltd is a limited company registered in England 
and Wales under Registered Number 08648097. Registered Office: Newnhams Wood, 
Horsted Keynes, West Sussex, RH17 7BT. 
Disclaimer: Q3dhRSrm_disclaimer
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to