Hi Ben, That's very interesting. I'd read that the Contact address must be a public address - but perhaps that's not true with double record-route.
First I'll try not rewriting the Contact and then look into TH or B2BUA. Many thanks for your help! Alex ________________________________ From: Users <[email protected]> on behalf of Ben Newlin <[email protected]> Sent: 23 July 2021 16:14 To: OpenSIPS users mailling list <[email protected]> Subject: Re: [OpenSIPS-Users] Double record-route trouble 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 <[email protected]> on behalf of Alex Crow <[email protected]> Date: Friday, July 23, 2021 at 11:02 AM To: [email protected] <[email protected]> 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 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:[email protected]: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:[email protected]:5060;transport=TCP> To: "Alex" <sip:[email protected]>;tag=lihnv From: <sip:[email protected]>;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:[email protected]:5060;transport=TCP> To: "Alex" <sip:[email protected]>;tag=lihnv From: <sip:[email protected]>;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:[email protected]:5060;transport=TCP> To: "Alex" <sip:[email protected]>;tag=lihnv From: <sip:[email protected]>;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 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 [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
