Error "missing tmp ecdh key" when receiving call over WebRTC (TLS)

Edit: Stop reading now unless you have this problem. It’s fixed.

First of all, this seems to be my issue:

I have configured Asterisk to work with WebRTC and am using Sip.JS to make and receive calls from a web browser. I am able to register a phone and make calls like this. I can receive a call, but as soon as I “answer” in the browser, the call disconnects and I get error “missing tmp ecdh key” in the Asterisk logs.

I’m running Asterisk 13.7.2 which has the fix described in the Asterisk JIRA. I looked at the patch code myself and made sure it was there, even tried to install the patch myself but it skipped it all because the patch was already present.

Here’s the log:

[Apr  6 15:02:15] VERBOSE[13092][C-0000000e] netsock2.c: Using SIP RTP CoS mark 5
[Apr  6 15:02:15] VERBOSE[13403][C-0000000e] pbx.c: Executing [203@200:1] NoOp("SIP/200-0000001c", "") in new stack
[Apr  6 15:02:15] VERBOSE[13403][C-0000000e] pbx.c: Executing [203@200:2] Dial("SIP/200-0000001c", "SIP/203") in new stack
[Apr  6 15:02:15] VERBOSE[13403][C-0000000e] netsock2.c: Using SIP RTP CoS mark 5
[Apr  6 15:02:15] VERBOSE[13403][C-0000000e] app_dial.c: Called SIP/203
[Apr  6 15:02:15] VERBOSE[13403][C-0000000e] app_dial.c: SIP/203-0000001d is ringing

[Apr  6 15:02:19] ERROR[13403][C-0000000e] res_rtp_asterisk.c: DTLS failure occurred on RTP instance '0x7f8d70001958' due to reason 'missing tmp ecdh key', terminating
[Apr  6 15:02:19] WARNING[13403][C-0000000e] res_rtp_asterisk.c: RTCP Read error: Unspecified.  Hanging up.
[Apr  6 15:02:19] VERBOSE[13403][C-0000000e] app_dial.c: No one is available to answer at this time (1:0/0/0)
[Apr  6 15:02:19] VERBOSE[13403][C-0000000e] pbx.c: Auto fallthrough, channel 'SIP/200-0000001c' status is 'NOANSWER'
[Apr  6 15:02:19] VERBOSE[13268][C-0000000e] netsock2.c: Using UDPTL CoS mark 5

I’m at a loss. The only place I can find a possible resolution is the JIRA and that’s already been done. I’ve tried rebooting, regenerating the certificates, recompiling, etc. Am I missing a setting somewhere?


[203] ; This will be WebRTC client
callerid = "WebRTC" <203>
defaultuser = 203
username=203 ; The Auth user for SIP.js
host=dynamic ; Allows any host to register
secret=password ; The SIP Password for SIP.js
encryption=yes ; Tell Asterisk to use encryption for this peer
avpf=yes ; Tell Asterisk to use AVPF for this peer
icesupport=yes ; Tell Asterisk to use ICE for this peer
context=203 ; Tell Asterisk which context to use when this peer is dialing
directmedia=no ; Asterisk will relay media for this peer
transport=udp,wss ; Asterisk will allow this peer to register on UDP or WebSockets
force_avp=yes ; Force Asterisk to use avp. Introduced in Asterisk 11.11
dtlsenable=yes ; Tell Asterisk to enable DTLS for this peer
dtlsverify=no ; Tell Asterisk to not verify your DTLS certs
dtlscertfile=/etc/asterisk/keys/foo.pem ; Tell Asterisk where your DTLS cert file is
dtlsprivatekey=/etc/asterisk/keys/foo.pem ; Tell Asterisk where your DTLS private key is
dtlssetup=actpass ; Tell Asterisk to use actpass SDP parameter when

http.conf (foo.pem is the second certificate I generated directly from OpenSSL.

tlsenable=yes          ; enable tls - default no.
tlsbindaddr=    ; address and port to bind to - default is bindaddr and port 8089.
tlscertfile=/etc/asterisk/keys/foo.pem  ; path to the certificate file (*.pem) only.
tlsprivatekey=/etc/asterisk/keys/foo.pem    ; path to private key file (*.pem) only.

Keys generated with both of the following commands; neither worked.
openssl req -new -x509 -days 365 -nodes -out /etc/asterisk/keys/foo.pem -keyout /etc/asterisk/keys/foo.pem
./ast_tls_cert -C <server ip> -O <company name> -d /etc/asterisk/keys

Any ideas? I’m running my application in Chrome (tried Firefox too) on a server with a properly configured SSL certificate. Everything related to WebRTC is working. Outbound calls work fine and have audio. It’s just the inbound calls that fail as soon as I answer.

Thanks for your help!

For the record, if you read way to the bottom of the JIRA thread you can see that someone said it’s still an issue in 13.7.2. I manually ran the patch at the very top of the page and it’s now fixed.