We have a client who want to use late offer, so no sdp sent with INVITE.
Connection is TLS
When Asterisk reply with 200 OK it sends insecure RTP / AVP profile in sdp and client reject it sending BYE with “488 Not Acceptable Here”.
How to configure Asterisk to send SRTP offer in 200 OK sdp for TLS connections?
Which channel driver is in use, and what is the configuration?
chan_sip
sip.conf
type=friend
disallow=all
allow=ulaw
Our asterisk is behind SIP proxy
And SIP Proxy → Asterisk is UDP
You haven’t enabled any security features, or you haven’t provided the complete configuration.
Ok sorry, so
since our Asterisk is behind SIP Proxy which is handling TLS stuff, tls is off on asterisk:
tlsenable=no
other relevant configs we have:
allowguest=no
match_auth_username=yes
allowoverlap=no
directmedia=no
transport=udp
tcpenable=yes
tcpbindaddr=
udpbindaddr=
TLS and SRTP are two separate things. TLS secures the signaling while SRTP secures the media. SRTP has to be explicitly enabled in chan_sip using the “encryption” option.
Yes I tried that (to set encryption=yes) but still, when Asterisk answer with 200 OK it sends
v=0
o=root 1614082163 1614082163 IN IP4 1.2.3.4
s=RServer
c=IN IP4 1.2.3.4
t=0 0
m=audio 39980 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=maxptime:150
a=sendrecv
And once again connection between Our SIP Proxy and Asterisk is not TLS, it’s UDP, not sure if it makes Asterisk to act differently
Plus description for “encryption” says
“Whether to offer SRTP encrypted media (and only SRTP encrypted media) on outgoing calls to a peer. Calls will fail with HANGUPCAUSE=58 if the peer does not support SRTP. Defaults to no.”
Isn’t it for outgoing calls?
Here we are talking about late offer negotiation (No sdp in INVITE from client and RTP instead of SRTP in 200 OK from Asterisk)
As I recall it, media encryption requires signalling encryption, because the plain text media session keys are sent in the signalling channel.
Even after enabling TLS between SIP Proxy and Asterisk, Asterisk still replies with insecure RTP in late offer 200 OK SDP
‘encryption=yes’ is configured for this peer and globally
<— Reliably Transmitting (NAT) to 5.5.5.5:57278 —>
SIP/2.0 200 OK
Via: SIP/2.0/TLS 1.2.3.4:5061;branch=z9hG4bK598b.ded48454.0;i=d3da56b1;received=1.2.3.4;rport=57278
From: “User” sip:988@1.2.3.4:5063;tag=79468b0f-a245-495d-a24e-6e452ff0e4e1
To: sip:345@4.3.2.1:5061;transport=tls;tag=as3eed955f
Call-ID:TViQVRcMWRkZi1CSFdrf2d+LENUWGJ6YzF9SAdZ
CSeq: 18978103 INVITE
Server: Server
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: sip:345@4.3.2.1:5061;transport=tls
Content-Type: application/sdp
Require: timer
Content-Length: 236
v=0
o=root 560167402 560167402 IN IP4 4.3.2.1
s=Server
c=IN IP4 4.3.2.1
t=0 0
m=audio 41952 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=maxptime:150
a=sendrecv
What is your reason for not using PJSIP? Even if this is due to a limitation in chan_sip, it is extremely unlikely that anyone in the community will remove it.
You could try turning up debugging, to see if it logs a reason for not using SRTP. I’d expect that late offer SDP would be treated pretty much the same as an outgoing call, but it would take far too long the check what the code actually does.
It’s pretty old system and so far we had no issues we chan_sip.
Can you please give me an idea how to enable more debugging?
I found this bug opened and closed a while ago which describes situation we are in right now: [ASTERISK-17103] Unable to establish SRTP if receive INVITE with no SDP - Digium/Asterisk JIRA
Can you please give me an idea if that was ever fixed?
We are on asterisk 16.2.1
And as bug descriptions says SRTP works well for us with an early offer but doesn’t with late offer
Also I enabled debug logs and don’t see anything about why asterisk doesn’t want to use SRTP
The bug report says:
Resolution: Not a bug
so the official position was that there was nothing to fix.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.