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:[email protected]:5060;transport=TCP
SIP/2.0
Method: INVITE
Request-URI: sip:[email protected]: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:[email protected]>
From: "Alex" <sip:[email protected]>;tag=pydzo
Call-ID: vfytldehdpikbnt@ryzing
[Generated Call-ID: vfytldehdpikbnt@ryzing]
CSeq: 224 INVITE
Contact: <sip:[email protected];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@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 <[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
