[OpenSIPS-Users] Double record-route trouble

Fri Jul 23 18:55:56 EST 2021

Hi again Ben,

Not rewriting the Contact lets BYE work from the UAS, so that's fixed, many thanks. Now the only problem is the media from UAS to the UAC. The INVITE outbound looks like this now:

Session Initiation Protocol (INVITE)
    Request-Line: INVITE sip:5760 at g---.spitfirevoiceapps.net:5060;transport=TCP SIP/2.0
        Method: INVITE
        Request-URI: sip:5760 at g---.spitfirevoiceapps.net:5060;transport=TCP
        [Resent Packet: False]
    Message Header
        Record-Route: <sip:195.196.197.198:5060;transport=tcp;r2=on;lr;ftag=pydzo;nat=yes>
        Record-Route: <sip:10.20.12.125;r2=on;lr;ftag=pydzo;nat=yes>
        Via: SIP/2.0/TCP 195.196.197.198:5060;branch=z9hG4bKee12.10e664c4.0
        Via: SIP/2.0/UDP 10.193.169.56;received=10.193.169.56;rport=5060;branch=z9hG4bKycrgiemh
        Max-Forwards: 69
        To: <sip:+5760 at 195.196.197.198>
        From: "Alex" <sip:1838 at 195.196.197.198>;tag=pydzo
        Call-ID: vfytldehdpikbnt at ryzing
        [Generated Call-ID: vfytldehdpikbnt at ryzing]
        CSeq: 224 INVITE
        Contact: <sip:1838 at 10.193.169.56;transport=udp>
        Content-Type: application/sdp
        Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
        Supported: replaces,norefersub,100rel
        User-Agent: Twinkle/1.10.2
        Content-Length: 339
    Message Body
        Session Description Protocol
            Session Description Protocol Version (v): 0
            Owner/Creator, Session Id (o): twinkle 1706657473 1887886456 IN IP4 10.193.169.56
            Session Name (s): -
            Connection Information (c): IN IP4 195.196.197.198
            Time Description, active time (t): 0 0
            Media Description, name and address (m): audio 35510 RTP/AVP 98 97 8 0 3 101
            Media Attribute (a): rtpmap:98 speex/16000
            Media Attribute (a): rtpmap:97 speex/8000
            Media Attribute (a): rtpmap:8 PCMA/8000
            Media Attribute (a): rtpmap:0 PCMU/8000
            Media Attribute (a): rtpmap:3 GSM/8000
            Media Attribute (a): rtpmap:101 telephone-event/8000
            Media Attribute (a): fmtp:101 0-15
            Media Attribute (a): sendrecv
            Media Attribute (a): rtcp:35511
            Media Attribute (a): ptime:20
            [Generated Call-ID: vfytldehdpikbnt at ryzing]

But the audio coming back towards the UAC seems to be hitting the external interface of the proxy and not getting forwarded to the UAC on 10.193.169.56:

Frame 21: 216 bytes on wire (1728 bits), 216 bytes captured (1728 bits)
Linux cooked capture v1
Internet Protocol Version 4, Src: 62.63.64.65, Dst: 10.20.12.124
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 200
    Identification: 0x848d (33933)
    Flags: 0x40, Don't fragment
    Fragment Offset: 0
    Time to Live: 54
    Protocol: UDP (17)
    Header Checksum: 0x67f9 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 62.63.64.65
    Destination Address: 10.20.12.124
User Datagram Protocol, Src Port: 10466, Dst Port: 35510
    Source Port: 10466
    Destination Port: 35510
    Length: 180
    Checksum: 0x9955 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 4]
    [Timestamps]
    UDP payload (172 bytes)
Real-Time Transport Protocol
    [Stream setup by SDP (frame 14)]
    10.. .... = Version: RFC 1889 Version (2)
    ..0. .... = Padding: False
    ...0 .... = Extension: False
    .... 0000 = Contributing source identifiers count: 0
    0... .... = Marker: False
    Payload type: ITU-T G.711 PCMA (8)
    Sequence number: 25470
    [Extended sequence number: 91006]
    Timestamp: 1183222988
    Synchronization Source identifier: 0x7485ecc6 (1954933958)
    Payload: d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d45554d55454…

I'm running RPTEngine and it doesn't seem to be complaining - I've tried leaving the (c) address in SDP to the internal address but then UAC->UAS RTP goes straight to the 3CX, and sill no UAS->UAC audio.

Wish we had IPv6 in this situation, would make everything work seamlessly!

Many thanks again for taking the time to help me.

Best regards

Alex
________________________________
From: Users <users-bounces at lists.opensips.org> on behalf of Ben Newlin <Ben.Newlin at genesys.com>
Sent: 23 July 2021 16:14
To: OpenSIPS users mailling list <users at lists.opensips.org>
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 <users-bounces at lists.opensips.org> on behalf of Alex Crow <alex.crow at geotogether.com>
Date: Friday, July 23, 2021 at 11:02 AM
To: users at lists.opensips.org <users at 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

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 at 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 at 62.63.64.65:5060;transport=TCP>

        To: "Alex" <sip:1838 at 195.196.197.198>;tag=lihnv

        From: <sip:+5760 at 195.196.197.198>;tag=f6ce187d

        Call-ID: mpytwgabkcpnkef at ryzing

        [Generated Call-ID: mpytwgabkcpnkef at 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 at 62.63.64.65:5060;transport=TCP>

        To: "Alex" <sip:1838 at 195.196.197.198>;tag=lihnv

        From: <sip:+5760 at 195.196.197.198>;tag=f6ce187d

        Call-ID: mpytwgabkcpnkef at ryzing

        [Generated Call-ID: mpytwgabkcpnkef at 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 at 62.63.64.65:5060;transport=TCP>

        To: "Alex" <sip:1838 at 195.196.197.198>;tag=lihnv

        From: <sip:+5760 at 195.196.197.198>;tag=f6ce187d

        Call-ID: mpytwgabkcpnkef at ryzing

        [Generated Call-ID: mpytwgabkcpnkef at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20210723/e82d8f54/attachment-0001.html>