Alex,

Without seeing the INVITE I can’t be sure, but it seems like your problem is in 
your setting of the Contact header on the outbound INVITE to 3CX. The value of 
the Contact header is what dictates the RURI of sequential requests. The BYE 
from 3CX is being sent to your OpenSIPS public interface, not to the Softphone 
IP. Because the RURI address matches the top Route header, OpenSIPS assumes 
that loose routing is not supported, which is per the RFC I believe, and that 
is why you see this behavior. Replacing the URI with the contents of the route 
header is the old RFC 2543 routing mechanism.

If you are going to act as a proxy and use Record-Routing, you need to leave 
the Contact header URI pointing to the original UAC (the phone), not OpenSIPS. 
If you are going to change the Contact header to point to OpenSIPS, then 
Record-Routing is not necessary. You should instead be using either Topology 
Hiding or B2BUA to handle that.

Ben Newlin

From: Users <users-boun...@lists.opensips.org> on behalf of Alex Crow 
<alex.c...@geotogether.com>
Date: Friday, July 23, 2021 at 11:02 AM
To: users@lists.opensips.org <users@lists.opensips.org>
Subject: [OpenSIPS-Users] Double record-route trouble
Hi all,

I am setting up a proxy to route calls between a cloud 3CX instance and MS 
Teams Direct Routing. At the moment I'm just trying to get the OpenSIPS to 3CX 
connection working, testing with a softphone pointed at the proxy and 
attempting to make calls to extensions on the 3CX.

Opensips is behind NAT with two sockets configured, one TCP with an "as" 
setting for the public address of the NAT, one UDP which is where the softphone 
connects. Outbound calls from the softphone as UAC to 3CX extensions as UAS 
ring, show established when answered, and I get audio at least one way (I think 
the one way audio may be a firewall issue). There are no registrations being 
used by any endpoint.

Opensips adds a double record-route header as expected for both the receiving 
and sending interface.

The problem I am having is that a BYE from one of the extensions on the 3CX 
(being a callee/UAS) arrives at OpenSIPs on the public-facing socket, with a 
double route header, in the order of public, private, with lr and r2=on set, 
but loose_route() does not behave according to the RFCs. I believe it should 
remote both route headers and then send the BYE to the destination in the RURI, 
spiralling back into the proxy via the sip address in the last Route: header 
and then being routed to the softphone/UAC.

Instead, it seems to replace the RURI with the sip address of the last Route 
header, and sends the message via TCP to the internal socket (which I therefore 
had to add TCP to - if I dont have both UDP and TCP on the internal socket, we 
get a failed TCP connection here), thus causing a loop and an eventual Too Many 
Hops.

My openSIPS config is here:

https://pastebin.com/4t006vfn<https://pastebin.com/4t006vfn>

A packet capture of the BYE and subsequent problem, the public facing private 
ip is 10.20.12.124 (TCP socket), advertised as 195.196.197.198, and the 
internal private IP (facing the softphone) is 10.20.12.125 with a TCP and a UDP 
socket. 3CX is 62.63.64.65. Softphone (UAC) uses UDP, 3CX uses TCP. SIP Domain 
of the proxy and softphone is 195.196.197.198, the softphone's SIP username is 
1838, I'm calling extension 5760 on the 3CX.

BYE from 3XC (from UAS)

Session Initiation Protocol (BYE)
    Request-Line: BYE sip:1838@195.196.197.198:5060;transport=tcp SIP/2.0
    Message Header
        Via: SIP/2.0/TCP 
62.63.64.65:5060;branch=z9hG4bK-524287-1---77636e709985902e;rport
        Max-Forwards: 70
        Route: 
<sip:195.196.197.198:5060;transport=tcp;lr;r2=on;ftag=lihnv;nat=yes>
        Route: <sip:10.20.12.125;r2=on;lr;ftag=lihnv;nat=yes>
        Contact: <sip:5760@62.63.64.65:5060;transport=TCP>
        To: "Alex" <sip:1838@195.196.197.198>;tag=lihnv
        From: <sip:+5760@195.196.197.198>;tag=f6ce187d
        Call-ID: mpytwgabkcpnkef@ryzing
        [Generated Call-ID: mpytwgabkcpnkef@ryzing]
        CSeq: 2 BYE
        User-Agent: 3CXPhoneSystem 16.0.8.9 (9)
        Content-Length: 0

BYE after loose_route():

Session Initiation Protocol (BYE)
    Request-Line: BYE sip:10.20.12.125;r2=on;lr;ftag=lihnv;nat=yes SIP/2.0
    Message Header
        Via: SIP/2.0/TCP 
195.196.197.198:5060;branch=z9hG4bKcd21.3682afa6.0;i=a10f2936
        Via: SIP/2.0/TCP 
62.63.64.65:5060;received=62.63.64.65;branch=z9hG4bK-524287-1---77636e709985902e;rport=44953
        Max-Forwards: 69
        Contact: <sip:5760@62.63.64.65:5060;transport=TCP>
        To: "Alex" <sip:1838@195.196.197.198>;tag=lihnv
        From: <sip:+5760@195.196.197.198>;tag=f6ce187d
        Call-ID: mpytwgabkcpnkef@ryzing
        [Generated Call-ID: mpytwgabkcpnkef@ryzing]
        CSeq: 2 BYE
        User-Agent: 3CXPhoneSystem 16.0.8.9 (9)
        Content-Length: 0

Then this just loops around as expected due to the RURI in the above message:

Session Initiation Protocol (BYE)
    Request-Line: BYE sip:10.20.12.125;r2=on;lr;ftag=lihnv;nat=yes SIP/2.0
    Message Header
        Via: SIP/2.0/UDP 
10.20.12.125:5060;branch=z9hG4bKcd21.4682afa6.0;i=c10f2936
        Via: SIP/2.0/TCP 
195.196.197.198:5060;rport=47455;received=10.20.12.124;branch=z9hG4bKcd21.3682afa6.0;i=a10f2936
        Via: SIP/2.0/TCP 
62.63.64.65:5060;received=62.63.64.65;branch=z9hG4bK-524287-1---77636e709985902e;rport=44953
        Max-Forwards: 68
        Contact: <sip:5760@62.63.64.65:5060;transport=TCP>
        To: "Alex" <sip:1838@195.196.197.198>;tag=lihnv
        From: <sip:+5760@195.196.197.198>;tag=f6ce187d
        Call-ID: mpytwgabkcpnkef@ryzing
        [Generated Call-ID: mpytwgabkcpnkef@ryzing]
        CSeq: 2 BYE
        User-Agent: 3CXPhoneSystem 16.0.8.9 (9)
        Content-Length: 0

Any clues or ways of resolving this would be very much appreciated!

Best regards

Alex
DISCLAIMER: This email and any attachments are sent in confidence, subject to 
applicable legal privilege and upon the basis that the recipient will conduct 
appropriate checks. If you receive this email in error, please telephone us 
upon receipt: you are strictly prohibited from using, copying or disseminating 
it or any information contained in it save to the intended recipient. Internet 
communications are not secure and Green Energy Options Ltd is not responsible 
for their abuse by third parties, nor for any alteration or corruption in 
transmission, nor for any damage or loss caused by any virus or other defect. 
Green Energy Options Limited. Registered office: 3 St. Mary's Court, Main 
Street, Hardwick, Cambridge CB23 7QS Registered in England no. 5783558
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to