Have to delete/recreate extensions with SRTP/DTLS enabled

Hi, been at this for hours and hours.
For a long time, there was no issue like this. This seems to have started about a week ago.

The problem in a nutshell is inbound calls hangup soon as they are answered by end point.

First noticed this issue on cell phone with Bria. Subsequently found same issue in our Grandstream phones.

For some reason, when end point is configured with:
Transport = UDP
SRTP = yes
DTLS = yes

We could not answer a call as the call would immediately hangup. Seems the reason is:

[2017-03-20 11:57:39] WARNING[4386][C-0000003b]: chan_sip.c:10760 process_sdp: Failed to receive SDP offer/answer with required SRTP crypto attributes for audio

Below is part of a call:

<— SIP read from UDP:xxx.xx.72.210:57225 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP xx.xx.85.115:5060;branch=z9hG4bK37cfe498;rport=5060
From: “JOHN TRUCKING” sip:[email protected];tag=as0c9703b7
To: sip:[email protected]:57225;tag=1040663773
Call-ID: [email protected]:5060
CSeq: 102 INVITE
Contact: sip:[email protected]:57225
Supported: replaces, path, timer
User-Agent: Grandstream GXP2130 1.0.7.97
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Type: application/sdp
Content-Length: 212

v=0
o=320 8002 8000 IN IP4 xxx.xx.72.210
s=SIP Call
c=IN IP4 xxx.xx.72.210
t=0 0
m=audio 5008 RTP/AVP 0 101
a=sendrecv
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
<------------->
— (12 headers 11 lines) —
Found RTP audio format 0
Found RTP audio format 101
Found audio description format PCMU for ID 0
Found audio description format telephone-event for ID 101
[2017-03-20 11:57:39] WARNING[4386][C-0000003b]: chan_sip.c:10760 process_sdp: Failed to receive SDP offer/answer with required SRTP crypto attributes for audio
sip_route_dump: route/path hop: sip:[email protected]:57225
Transmitting (NAT) to xxx.xx.72.210:57225:
ACK sip:[email protected]:57225 SIP/2.0
Via: SIP/2.0/UDP xx.xx.85.115:5060;branch=z9hG4bK1867acbe;rport
Max-Forwards: 70
From: “JOHN TRUCKING” sip:[email protected];tag=as0c9703b7
To: sip:[email protected]:57225;tag=1040663773
Contact: sip:[email protected]:5060
Call-ID: [email protected]:5060
CSeq: 102 ACK
User-Agent: FPBX-13.0.190.19(13.14.0)

The above partial call is AFTER changing SRTP to NO, Transport to UDP Only and DTLS to NO.

Decided to change configuration for a few extensions in FreePBX and End points and go plain vanilla. NO SRTP, NO DTLS. UDP Only

The only fix was to delete the extensions in FreePBX and recreate them. After recreating the extensions with no SRTP, No DTLS and transport set to UDP only, inbound calls worked as they should.

We use wild card CA Signed certificates. Not real sure if the certificate is the cause but why the error above regarding SRTP when SRTP is set to OFF is beyond me.

Thanks.

Seems our PBX is haunted!

Although ext 320 was deleted and recreated, the bug is still there.

Called the grandstream ext 290 phone from Bria ext 308

<— SIP read from UDP:xx.xx.72.210:40975 —>
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP xx.xx.72.210:40975;branch=z9hG4bK-524287-1—eaaacd579b3d9d4e;rport
Max-Forwards: 70
Contact: sip:[email protected]:40975;rinstance=4740e0dd279c7324
To: sip:[email protected]
From: "John"sip:[email protected];tag=22991b31
Call-ID: 140992_rel51N2Q5YTc5ZmI3ZTdhMjc3ZTcwNDJjYWU1MzFkMGE2NzE
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, BYE, REFER, INFO, NOTIFY, OPTIONS, SUBSCRIBE, MESSAGE
Content-Type: application/sdp
Supported: replaces
User-Agent: Bria Android 3.9.1 build 95572
Content-Length: 184

v=0
o=- 10359429136 1 IN IP4 xx.xx.72.210
s=Cpc session
c=IN IP4 xx.xx.72.210
t=0 0
m=audio 12916 RTP/AVP 0 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
<------------->
— (13 headers 9 lines) —
Sending to xx.xx.72.210:40975 (no NAT)
Sending to xx.xx.72.210:40975 (no NAT)
Using INVITE request as basis request - 140992_rel51N2Q5YTc5ZmI3ZTdhMjc3ZTcwNDJjYWU1MzFkMGE2NzE
Found peer ‘308’ for ‘308’ from xx.xx.72.210:40975

<— Reliably Transmitting (NAT) to xx.xx.72.210:40975 —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP xx.xx.72.210:40975;branch=z9hG4bK-524287-1—eaaacd579b3d9d4e;received=xx.xx.72.210;rport=40975
From: "John"sip:[email protected];tag=22991b31
To: sip:[email protected];tag=as4ff3f6b4
Call-ID: 140992_rel51N2Q5YTc5ZmI3ZTdhMjc3ZTcwNDJjYWU1MzFkMGE2NzE
CSeq: 1 INVITE
Server: FPBX-13.0.190.19(13.14.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce="3eccee00"
Content-Length: 0

<------------>
Scheduling destruction of SIP dialog ‘140992_rel51N2Q5YTc5ZmI3ZTdhMjc3ZTcwNDJjYWU1MzFkMGE2NzE’ in 10112 ms (Method: INVITE)
Retransmitting #1 (NAT) to xx.xx.72.210:40975:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP xx.xx.72.210:40975;branch=z9hG4bK-524287-1—eaaacd579b3d9d4e;received=xx.xx.72.210;rport=40975
From: "John"sip:[email protected];tag=22991b31
To: sip:[email protected];tag=as4ff3f6b4
Call-ID: 140992_rel51N2Q5YTc5ZmI3ZTdhMjc3ZTcwNDJjYWU1MzFkMGE2NzE
CSeq: 1 INVITE
Server: FPBX-13.0.190.19(13.14.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce="3eccee00"
Content-Length: 0


<— SIP read from UDP:xx.xx.72.210:40975 —>
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP xx.xx.72.210:40975;branch=z9hG4bK-524287-1—eaaacd579b3d9d4e;rport
Max-Forwards: 70
To: sip:[email protected];tag=as4ff3f6b4
From: "John"sip:[email protected];tag=22991b31
Call-ID: 140992_rel51N2Q5YTc5ZmI3ZTdhMjc3ZTcwNDJjYWU1MzFkMGE2NzE
CSeq: 1 ACK
Content-Length: 0

<------------->
— (8 headers 0 lines) —

<— SIP read from UDP:xx.xx.72.210:40975 —>
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP xx.xx.72.210:40975;branch=z9hG4bK-524287-1—eaaacd579b3d9d4e;rport
Max-Forwards: 70
To: sip:[email protected];tag=as4ff3f6b4
From: "John"sip:[email protected];tag=22991b31
Call-ID: 140992_rel51N2Q5YTc5ZmI3ZTdhMjc3ZTcwNDJjYWU1MzFkMGE2NzE
CSeq: 1 ACK
Content-Length: 0

<------------->
— (8 headers 0 lines) —

<— SIP read from UDP:xx.xx.72.210:40975 —>
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP xx.xx.72.210:40975;branch=z9hG4bK-524287-1—a356ff66e9d2983d;rport
Max-Forwards: 70
Contact: sip:[email protected]:40975;rinstance=4740e0dd279c7324
To: sip:[email protected]
From: “John"sip:[email protected];tag=22991b31
Call-ID: 140992_rel51N2Q5YTc5ZmI3ZTdhMjc3ZTcwNDJjYWU1MzFkMGE2NzE
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, BYE, REFER, INFO, NOTIFY, OPTIONS, SUBSCRIBE, MESSAGE
Content-Type: application/sdp
Supported: replaces
User-Agent: Bria Android 3.9.1 build 95572
Authorization: Digest username=“308”,realm=“asterisk”,nonce=“3eccee00”,uri="sip:[email protected]”,response=“62af628e4d0aee91ec3fd02d10f78ebf”,algorithm=MD5
Content-Length: 184

v=0
o=- 10359429136 1 IN IP4 xx.xx.72.210
s=Cpc session
c=IN IP4 xx.xx.72.210
t=0 0
m=audio 12916 RTP/AVP 0 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
<------------->
— (14 headers 9 lines) —
Sending to xx.xx.72.210:40975 (NAT)
Using INVITE request as basis request - 140992_rel51N2Q5YTc5ZmI3ZTdhMjc3ZTcwNDJjYWU1MzFkMGE2NzE
Found peer ‘308’ for ‘308’ from xx.xx.72.210:40975
== DTLS ECDH initialized (secp256r1), faster PFS enabled
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
Found RTP audio format 0
Found RTP audio format 101
Found audio description format telephone-event for ID 101
[2017-03-20 13:18:20] WARNING[4386][C-00000057]: chan_sip.c:10760 process_sdp: Failed to receive SDP offer/answer with required SRTP crypto attributes for audio

<— Reliably Transmitting (NAT) to xx.xx.72.210:40975 —>
SIP/2.0 488 Not acceptable here
Via: SIP/2.0/UDP xx.xx.72.210:40975;branch=z9hG4bK-524287-1—a356ff66e9d2983d;received=xx.xx.72.210;rport=40975
From: "John"sip:[email protected];tag=22991b31
To: sip:[email protected];tag=as4ff3f6b4
Call-ID: 140992_rel51N2Q5YTc5ZmI3ZTdhMjc3ZTcwNDJjYWU1MzFkMGE2NzE
CSeq: 2 INVITE
Server: FPBX-13.0.190.19(13.14.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0

<------------>
Scheduling destruction of SIP dialog ‘140992_rel51N2Q5YTc5ZmI3ZTdhMjc3ZTcwNDJjYWU1MzFkMGE2NzE’ in 10112 ms (Method: INVITE)
Retransmitting #1 (NAT) to xx.xx.72.210:40975:
SIP/2.0 488 Not acceptable here
Via: SIP/2.0/UDP xx.xx.72.210:40975;branch=z9hG4bK-524287-1—a356ff66e9d2983d;received=xx.xx.72.210;rport=40975
From: "John"sip:[email protected];tag=22991b31
To: sip:[email protected];tag=as4ff3f6b4
Call-ID: 140992_rel51N2Q5YTc5ZmI3ZTdhMjc3ZTcwNDJjYWU1MzFkMGE2NzE
CSeq: 2 INVITE
Server: FPBX-13.0.190.19(13.14.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0


ext 308 from sip_additional.conf

[308]
deny=0.0.0.0/0.0.0.0
secret=REDACTED
dtmfmode=rfc2833
canreinvite=no
context=from-internal
host=dynamic
defaultuser=
trustrpid=yes
sendrpid=yes
type=friend
session-timers=accept
nat=force_rport,comedia
port=5060
qualify=yes
qualifyfreq=60
transport=udp
avpf=no
force_avp=no
icesupport=no
encryption=no
namedcallgroup=
namedpickupgroup=
dial=SIP/308
mailbox=308@default
permit=0.0.0.0/0.0.0.0
callerid=BRIA Cell <308>
callcounter=yes
faxdetect=no
cc_monitor_policy=generic

I didn’t think SRTP and DTLS could be used together.

I think the supported configuration is SIP over TLS(TCP) with or without SRTP.