DTLS failure due to 'no shared cipher'

Asterisk Asterisk Support
1

Hi,

I have setup WebRTC with Asterisk-12+SIPml5 and it was working with Firefox version 38. After the latest update with version 39, calls are getting disconnected by Asterisk with the following error:
“res_rtp_asterisk.c: DTLS failure occurred on RTP instance ‘0x7fefe800e9e8’ due to reason ‘no shared cipher’, terminating”

This is happening when making a call from another SIPml5 client running from Chrome version 43.0.2357.132 m.

Please find the SIP requests/responses (client running in Firefox) below:

ÿINVITE sip:210214@172.16.1.98:63546 SIP/2.0^M
ÿVia: SIP/2.0/WS df7jal23ls0d.invalid;branch=z9hG4bK503cbd8a^M
ÿMax-Forwards: 70^M
ÿFrom: sip:210215@172.16.1.150;tag=as7f8d948a^M
ÿTo: sip:210214@172.16.1.98:63546^M
ÿContact: sip:210215@172.16.1.150:5060;transport=WS^M
ÿCall-ID: 4d2e3f261bfb521317b959870e3a8df4@172.16.1.150:5060^M
ÿCSeq: 102 INVITE^M
ÿUser-Agent: CAFE MAS^M
ÿDate: Wed, 08 Jul 2015 20:10:46 GMT^M
ÿAllow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE, PRACK, UPDATE^M
ÿSupported: replaces, timer^M
ÿX-CAFE-IDENTITY: 210214^M
ÿContent-Type: application/sdp^M
ÿContent-Length: 702^M
ÿ^M
ÿv=0^M
ÿo=root 1975475184 1975475184 IN IP4 172.16.1.150^M
ÿs=CAFE MAS^M
ÿc=IN IP4 172.16.1.150^M
ÿt=0 0^M
ÿm=audio 14744 UDP/TLS/RTP/SAVPF 0 3 8 101^M
ÿa=rtpmap:0 PCMU/8000^M
ÿa=rtcp:14745^M
ÿa=rtpmap:3 GSM/8000^M
ÿa=rtpmap:8 PCMA/8000^M
ÿa=rtpmap:101 telephone-event/8000^M
ÿa=fmtp:101 0-16^M
ÿa=silenceSupp:off - - - -^M
ÿa=ptime:20^M
ÿa=ice-ufrag:494478db471b68b56de1ce7b2c5df48a^M
ÿa=ice-pwd:3ee884cd4573f35736f3b24e4650c8cf^M
ÿa=candidate:Hac100196 1 UDP 2130706431 172.16.1.150 14744 typ host^M
ÿa=candidate:Hac100196 2 UDP 2130706430 172.16.1.150 14745 typ host^M
ÿa=connection:new^M
ÿa=setup:actpass^M
ÿa=fingerprint:SHA-256 34:0E:83:CC:66:97:0A:82:25:FF:72:4F:64:1D:0D:E0:38:43:29:76:26:9D:5C:DF:9C:F8:A3:1F:C7:D0:36:91^M
ÿa=sendrecv^M
ÿ
ÿ—
[2015-07-08 16:10:46.445] DEBUG[8564][C-00000001] chan_sip.c: Trying to put ‘INVITE sip:’ onto WS socket destined for 172.16.1.98:63546
[2015-07-08 16:10:46.445] VERBOSE[8564][C-00000001] app_dial.c: – Called SIP/210214::::ws@172.16.1.98:63546 [2015-07-08 16:10:46.540] DEBUG[13912] pjsip: utsx0x7fefdc00 STUN sending message (transmit count=6)
[2015-07-08 16:10:46.558] VERBOSE[7776] chan_sip.c:
ÿ<— SIP read from WS:172.16.1.98:63546 —>
ÿSIP/2.0 100 Trying (sent from the Transaction Layer)
ÿVia: SIP/2.0/WS df7jal23ls0d.invalid;branch=z9hG4bK503cbd8a
ÿFrom: sip:210215@172.16.1.150;tag=as7f8d948a
ÿTo: sip:210214@172.16.1.98:63546
ÿCall-ID: 4d2e3f261bfb521317b959870e3a8df4@172.16.1.150:5060
ÿCSeq: 102 INVITE
ÿContent-Length: 0
ÿ
ÿ<— SIP read from WS:172.16.1.98:63546 —>
ÿSIP/2.0 180 Ringing
ÿVia: SIP/2.0/WS df7jal23ls0d.invalid;branch=z9hG4bK503cbd8a
ÿFrom: sip:210215@172.16.1.150;tag=as7f8d948a
ÿTo: sip:210214@172.16.1.98:63546;tag=mxPaxzBlXJFu7FqDcPQJ
ÿContact: sip:210214@df7jal23ls0d.invalid;transport=ws
ÿCall-ID: 4d2e3f261bfb521317b959870e3a8df4@172.16.1.150:5060
ÿCSeq: 102 INVITE
ÿContent-Length: 0
ÿAllow: ACK, BYE, CANCEL, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REFER, UPDATE
ÿ
ÿ<------------->

ÿ<— SIP read from WS:172.16.1.98:63546 —>
ÿSIP/2.0 200 OK
ÿVia: SIP/2.0/WS df7jal23ls0d.invalid;branch=z9hG4bK503cbd8a
ÿFrom: sip:210215@172.16.1.150;tag=as7f8d948a
ÿTo: sip:210214@172.16.1.98:63546;tag=mxPaxzBlXJFu7FqDcPQJ
ÿContact: sip:210214@df7jal23ls0d.invalid;transport=ws
ÿCall-ID: 4d2e3f261bfb521317b959870e3a8df4@172.16.1.150:5060
ÿCSeq: 102 INVITE
ÿContent-Type: application/sdp
ÿContent-Length: 934
ÿAllow: ACK, BYE, CANCEL, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REFER, UPDATE
ÿ
ÿv=0
ÿo=mozilla…THIS_IS_SDPARTA-39.0 4294967295 0 IN IP4 127.0.0.1
ÿs=Doubango Telecom - firefox
ÿt=0 0
ÿa=sendrecv
ÿa=fingerprint:sha-256 1F:00:94:17:D7:9D:F1:46:31:1F:8B:76:09:F8:96:0A:FD:73:59:23:B0:04:AB:7B:CD:9E:BA:1E:2E:F9:9A:EA
ÿa=ice-options:trickle
ÿa=msid-semantic:WMS *
ÿm=audio 62353 UDP/TLS/RTP/SAVPF 0
ÿc=IN IP4 61.12.92.74
ÿb=AS:64
ÿa=candidate:0 1 UDP 2128609535 172.16.1.98 62353 typ host
ÿa=candidate:0 2 UDP 2128609534 172.16.1.98 62354 typ host
ÿa=candidate:1 1 UDP 1692467199 61.12.92.74 62353 typ srflx raddr 172.16.1.98 rport 62353
ÿa=candidate:1 2 UDP 1692467198 61.12.92.74 62354 typ srflx raddr 172.16.1.98 rport 62354
ÿa=sendrecv
ÿa=end-of-candidates
ÿa=ice-pwd:5834e022d974e9d3b2f518c8a44a3b54
ÿa=ice-ufrag:53c2d504
ÿa=msid:{7f2253de-da0d-45fc-928d-12f63476dfbf} {3c665530-5b98-4acc-b1da-87e71f99bfde}
ÿa=rtpmap:0 PCMU/8000
ÿa=setup:active
ÿa=ssrc:1346958280 cname:{1129ef7a-4bd8-460a-b83d-fe2853871d48}
ÿ<------------->
[2015-07-08 16:10:50.523] VERBOSE[7776][C-00000001] chan_sip.c: Transmitting (no NAT) to 172.16.1.98:63546:
ÿACK sip:210214@df7jal23ls0d.invalid;transport=ws SIP/2.0^M
ÿVia: SIP/2.0/WS df7jal23ls0d.invalid;branch=z9hG4bK6e49f690^M
ÿMax-Forwards: 70^M
ÿFrom: sip:210215@172.16.1.150;tag=as7f8d948a^M
ÿTo: sip:210214@172.16.1.98:63546;tag=mxPaxzBlXJFu7FqDcPQJ^M
ÿContact: sip:210215@172.16.1.150:5060;transport=WS^M
ÿCall-ID: 4d2e3f261bfb521317b959870e3a8df4@172.16.1.150:5060^M
ÿCSeq: 102 ACK^M
ÿUser-Agent: CAFE MAS^M
ÿContent-Length: 0^M
ÿ^M
ÿ

After completion, Asterisk throws:

— begin STUN message —
STUN Binding success response
Hdr: length=60, magic=2112a442, tsx_id=357269355351696d554b597a
Attributes:
XOR-MAPPED-ADDRESS: length=8, IPv4 addr=172.16.1.98:61221
SOFTWARE: length=12, value="pjnath-2.1.0"
MESSAGE-INTEGRITY: length=20, data=1e412d9a7002aa1987b3208bed60f95f13b9bd84
FINGERPRINT: length=4, value=3998190357 (0xee4f8b15)
— end of STUN message —

[2015-07-08 16:10:50.525] DEBUG[9280][C-00000001] pjsip: stun_session.c .tdata 0x7fefdc001758 destroy request, force=0, tsx=0x7fefdc001940
[2015-07-08 16:10:50.525] DEBUG[9280][C-00000001] pjsip: utsx0x7fefdc00 .STUN transaction 0x7fefdc001940 schedule destroy
[2015-07-08 16:10:50.525] DEBUG[9280][C-00000001] pjsip: icess0x7fefe80 .Check 3: [2] 172.16.1.150:14745–>61.12.92.74:62354: state changed from In Progress to Failed
[2015-07-08 16:10:50.525] DEBUG[8564][C-00000001] pjsip: icess0x7fef3c0 .Valid check 1: [2] 172.16.1.150:12691–>172.16.1.98:61221 is nominated
[2015-07-08 16:10:50.525] DEBUG[9280][C-00000001] pjsip: stun_session.c .tdata 0x7fef38000d88 destroy request, force=0, tsx=0x7fef38000f70
[2015-07-08 16:10:50.525] DEBUG[8564][C-00000001] pjsip: icess0x7fef3c0 .Triggered check for check 1 not performed because it’s completed
[2015-07-08 16:10:50.525] DEBUG[9280][C-00000001] pjsip: utsx0x7fef3800 .STUN transaction 0x7fef38000f70 schedule destroy
[2015-07-08 16:10:50.525] DEBUG[8564][C-00000001] pjsip: icess0x7fef3c0 …Check 1 is successful and nominated
[2015-07-08 16:10:50.525] DEBUG[8564][C-00000001] pjsip: icess0x7fef3c0 …Cancelling check 3: [2] 172.16.1.150:12691–>61.12.92.74:61221 (In Progress)
[2015-07-08 16:10:50.525] DEBUG[8564][C-00000001] pjsip: stun_session.c …tdata 0x7fefdc002738 destroy request, force=0, tsx=0x7fefdc002910
[2015-07-08 16:10:50.525] DEBUG[8564][C-00000001] pjsip: utsx0x7fefdc00 …STUN transaction 0x7fefdc002910 schedule destroy
[2015-07-08 16:10:50.525] DEBUG[8564][C-00000001] pjsip: icess0x7fef3c0 …Check 3: [2] 172.16.1.150:12691–>61.12.92.74:61221: state changed from In Progress to Failed
[2015-07-08 16:10:50.525] ERROR[9280][C-00000001] res_rtp_asterisk.c: DTLS failure occurred on RTP instance ‘0x7fefe800e9e8’ due to reason ‘no shared cipher’, terminating

Please help me to figure out the issue.

Regards,
Karthik

2

Anybody get a chance to check this one?

3

You need to debug the RTP, not the SIP.

4

hello
I got exactly this problem. I’m using sipjs (sipjs.com) with Asterisk 13.3.2 to build a webphone for our CRM in CentOS 6.6 64bit, OpenSSL 1.0.1e. Everything was working perfectly before.

However, when Firefox 39 released and updated automatically, i have been facing problem of receiving call by Firefox. When using Firefox-39 to make call other client, it’s still work normally but when using Firefox-39 to receive call, it says (from asterisk console):

“[2015-07-16 23:03:32] ERROR[7476][C-00000001]: res_rtp_asterisk.c:2042 __rtp_recvfrom: DTLS failure occurred on RTP instance ‘0x7f0ee40067d8’ due to reason ‘no shared cipher’, terminating”

Asterisk seems always offer cipher suites TLS_RSA_WITH_AES_256_CBC_SHA. But from what i see from wireshark, firefox-39 has been disable TLS_RSA_WITH_AES_256_CBC_SHA cipher suites for DTLS/SRTP. Below is list of cipher suites in message Client Hello offered from firefox-39:

After Hello Client in DTLSv1.2 from firefox-39, asterisk reply with DTLSv1.0, not sure if it’s cause of the problem.

I have been research for several days but no luck, hope anyone can help. I think a lot people will face this problem since Firefox 39 released.

Thanks so much!

5

A user has created an issue[1] for this and any progress towards a resolution will be recorded there.

[1] issues.asterisk.org/jira/browse/ASTERISK-25265