No audio using SIP proxy and TLS

Hi all!
I’m trying to setup a SIP proxy using flexisip (because I’d like to have push notifications and I don’t want to use the notify - wait some seconds - dial approach)
everything works using SIP UDP transport, but I’ve no audio if I switch to SIPS (TLS) both using RTP and SRTP.
RTP packets do arrive to Asterisk, but Asterisk drop them and give me this message:
DEBUG[21813][C-0000162a]: res_rtp_asterisk.c:4277 ast_rtp_write: No remote address on RTP instance '0x7fa2c41f8ef8' so dropping frame

Everyhing looks right into INVITE and addresses are the same with or without proxy, the only difference that I’ve spotted is that:


look at the extra “s” after “INVITE” and in “To” field

The extra “s” also appears in my contact uri:
Contact: 92201/sips:92201@157.230.97.157:39297;transpor 2c2ea3ef7d Avail 32.784
That’s a working one for comparison:
Contact: 91450/sip:91450@80.17.99.73:11948;transport=TL d0468abde5 Avail 28.180

In this example, I’m using a flexisip proxy on the same machine, but I’ve same issue also with a proxy on another machine.

Does anyone have an idea of what I’m doing wrong and how to fix it?

1 Like

The problem will be in the SDP in a response packet, but you have provided the requests, and omitted the SDP from those.

1 Like

<--- Transmitting SIP request (1412 bytes) to TLS:157.230.97.157:39297 --->
INVITE sips:92201@157.230.97.157:39297;transport=TLS;fs-conn-id=f5603645b34c58f1;CtRt2ca863acf1b49e77=tls:80.17.99.73:1677 SIP/2.0
Via: SIP/2.0/TLS 157.230.97.157:5061;rport;branch=z9hG4bKPj8d035541-42b9-4844-b377-0f62577e0e5f;alias
From: "3xxxxxxxxxx" <sip:3xxxxxxxxxx@157.230.97.157>;tag=703768ab-c8d5-44c3-abdd-ac96f64bfaf8
To: <sips:92201@157.230.97.157;fs-conn-id=f5603645b34c58f1;CtRt2ca863acf1b49e77=tls:80.17.99.73:1677>
Contact: <sips:asterisk@157.230.97.157:5061;transport=TLS>
Call-ID: 803b404e-937e-413b-9826-3900f99ffa9e
CSeq: 3396 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
P-Asserted-Identity: "3xxxxxxxxxx" <sip:3xxxxxxxxxx@157.230.97.157>
Alert-Info: <http://www.notused >\;info=ring2
Max-Forwards: 70
User-Agent: FPBX-14.0.13.12(13.34.0)
Content-Type: application/sdp
Content-Length:   435

v=0
o=- 562606718 562606718 IN IP4 157.230.97.157
s=Asterisk
c=IN IP4 157.230.97.157
t=0 0
m=audio 16900 RTP/AVP 0 8 3 111 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:111 G726-32/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
m=video 17426 RTP/AVP 99 104
a=rtpmap:99 H264/90000
a=rtpmap:104 MP4V-ES/90000
a=sendrecv


<--- Received SIP response (675 bytes) from TLS:157.230.97.157:39297 --->
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS 157.230.97.157:5061;rport=5061;branch=z9hG4bKPj8d035541-42b9-4844-b377-0f62577e0e5f;alias
Record-Route: <sips:157.230.97.157:6061;lr>
From: "3xxxxxxxxxx" <sip:3xxxxxxxxxx@157.230.97.157>;tag=703768ab-c8d5-44c3-abdd-ac96f64bfaf8
To: <sips:92201@157.230.97.157;fs-conn-id=f5603645b34c58f1;CtRt2ca863acf1b49e77=tls:80.17.99.73:1677>;tag=2621131302
Call-ID: 803b404e-937e-413b-9826-3900f99ffa9e
CSeq: 3396 INVITE
Contact: <sip:92201@80.17.99.73:1677;transport=tls>
User-Agent: Fanvil X4U 1.0.0 0c383e4249ef
Allow-Events: talk
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REFER, NOTIFY, INFO, PRACK, UPDATE, MESSAGE
Content-Length: 0


<--- Received SIP response (1088 bytes) from TLS:157.230.97.157:39297 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 157.230.97.157:5061;rport=5061;branch=z9hG4bKPj8d035541-42b9-4844-b377-0f62577e0e5f;alias
Record-Route: <sips:157.230.97.157:6061;lr>
From: "3xxxxxxxxxx" <sip:3xxxxxxxxxx@157.230.97.157>;tag=703768ab-c8d5-44c3-abdd-ac96f64bfaf8
To: <sips:92201@157.230.97.157;fs-conn-id=f5603645b34c58f1;CtRt2ca863acf1b49e77=tls:80.17.99.73:1677>;tag=2621131302
Call-ID: 803b404e-937e-413b-9826-3900f99ffa9e
CSeq: 3396 INVITE
Contact: <sip:92201@80.17.99.73:1677;transport=tls;verified>
Supported: 100rel, replaces, timer
User-Agent: Fanvil X4U 1.0.0 0c383e4249ef
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REFER, NOTIFY, INFO, PRACK, UPDATE, MESSAGE
Content-Type: application/sdp
Content-Length: 360

v=0
o=92201 293661303 6030219836 IN IP4 80.17.99.73
s=A conversation
c=IN IP4 157.230.97.157
t=0 0
m=audio 25356 RTP/AVP 0 8 111 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:111 G726-32/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
m=video 0 RTP/AVP 99
a=rtpmap:99 H264/90000

<--- Transmitting SIP request (596 bytes) to TLS:157.230.97.157:39297 --->
BYE sip:92201@80.17.99.73:1677;transport=tls SIP/2.0
Via: SIP/2.0/TLS 157.230.97.157:5061;rport;branch=z9hG4bKPjafe72b39-cef2-48e4-936c-a0789e0c5f46;alias
From: "3xxxxxxxxxx" <sip:3xxxxxxxxxx@157.230.97.157>;tag=703768ab-c8d5-44c3-abdd-ac96f64bfaf8
To: <sips:92201@157.230.97.157;fs-conn-id=f5603645b34c58f1;CtRt2ca863acf1b49e77=tls:80.17.99.73:1677>;tag=2621131302
Call-ID: 803b404e-937e-413b-9826-3900f99ffa9e
CSeq: 3397 BYE
Route: <sips:157.230.97.157:39297;transport=TLS;lr>
Warning: 381 SIP "SIPS Required"
Max-Forwards: 70
User-Agent: FPBX-14.0.13.12(13.34.0)
Content-Length:  0

Turns out that no media was sent because the call failed. It looks like Asterisk doesn’t like an insecure contact URI when you are trying to force a secure connection.

Warning: 381 SIP "SIPS Required"

[ deleted as it assumed that a new connection was being used for the BYE, which is not the case. ]

I note that you are FreePBX. We can’t in general provide information on how to use the FreePBX web forms or comment on the way it generates configuration files.

Actually, that is probably secondary.

There is no SDP on the Ringing, so early media would get the response you mention, but there is a media address on the OK.

As you seem to have screen scraped, there is no timing information, so I can’t tell if the BYE is fast, but is is possible that Asterisk hasn’t actioned the SDP because it is going to close the call down, anyway, because of the unacceptable contact address.

The BYE is on the original port number, so it isn’t the result of the TLS connection having been closed.

Basically, the peer is trying to downgrade a secure connection to an insecure one.