Issues with DTLS-SRTP setup

[Lorenzo Miniero]

Hi all,

I've recently started working on getting the existing Asterisk 11 DTLS-SRTP implementation to work with Chrome and Firefox WebRTC implementations. The existing implementation was already quite complete and well done, so I only needed to study the interactions and check what could be missing.

I won't get in the details of what was needed to start to actually get this working (I had to hack a few things around, so feel free to ask me if you're interested), and I'll jump right to the point of what has been puzzling me these last days, in what I think may be the last obstacles left to actually make it work.

My scenario is simple: the browser (either Chrome or Firefox) is the caller, and Asterisk (an Echo test application preceded by a Playback) is the callee through a simple SIP gateway application I implemented, which means that, according from what I've read around, the browser will be the DTLS server while Asterisk will be the DTLS client. Right now, after a successul ICE completion, it apparently looks like the DTLS handshake is correctly completed, and the SRTP keys to use are extracted on the Asterisk side to complete the setup: nevertheless, Asterisk is the only one to start generating RTP, which is ignored by Chrome who, on the other end, does not generate any RTP packet either. I've captured a sample flow using Wireshark (attached as chrome-dtls.srtp, Asterisk on the left side and browser on the right) which I tried to debug and compare to a successful flow that was shared on this group some time ago (https://discuss-webrtc.googlegroups.com/attach/77ed6aa572e23bfa/dtls-ok.txt?pli=1&view=1&part=4, not sure which parties were involved).

I don't see many differences, except that:

1. in that flow each DTLS message is sent twice, which doesn't happen in my scenario (not a big deal, I guess);
   
   
2. in that flow the DTLS client sends his info (Certificate, Client Key Exchange, etc.) as separate messages, whereas in my scenario both the client and the server group them (again, probably not a big deal);
   
   
3. the same messages are exchanged in both flows, with the exception of "Server Key Exchange" that apparently is missing in my scenario (which means that both Chrome and Firefox are not sending it for some reason?).

Apart from that, I really don't know what's going wrong: looking at my scenario flow you can see that the RTP packets only start flowing from Asterisk towards the browser (displayed as UDP in the dump, but it's RTP), while the only messages Chrome keeps on sending are a few occasional connectivity checks.

Considering that this happens with both Chrome and Firefox, my guess is that there actually is something missing on my side: probably something that both browsers are expecting to complete the scenario before being able to communicate. Needless to say, no exception is triggered on the JavaScript concole, and I couldn't find any problem in the browser logs as well. I'm also attaching (as chrome-asterisk-sip-dtls.txt) the SDP that is exchanged between the two: the fake crypto line is there as well to that shouldn't be the cause.

What am I missing? Is there something that Chrome in particular expects in this scenario? Doing the same with SDES instead of DTLS works flawlessly, which means it's not an ICE/network/media issue. Is there any flag I can pass to Chrome at runtime to enable DTLS-specific logging?

Thanks,

Lorenzo

[kevinde...@googlemail.com]

In your answer you have RTCP on a separate port from RTP. This means that you need to perform a DTLS handshake for the RTCP as well. Without this the browser end will not send any RTP.

If you can use rtcp-mux, they you should only need the single handshake. 

[Lorenzo Miniero]

Thanks for your feedback, I'll look into it. rtcp-mux is not supported as of yet, so I'll have to try the RTCP DTLS handshake.

Lorenzo

[Lorenzo Miniero]

You were right, that did it! For Chrome at least, with Firefox it doesn't work yet, but that's another issue I'll start digging tomorrow...

Thanks again,

Lorenzo

[Dima]

Hi Lorenzo,

were you able to get Firefox to work with asterisk DTLS implementation?

[Lorenzo Miniero]

Yes, I documented my efforts here:

http://lists.digium.com/pipermail/asterisk-dev/2013-May/060355.html

Not everything works perfectly: for instance, the DTLS handshake for the RTCP channels fails, as you need two different handshakes for RTP and RTCP but Asterisk has a shared SRTP session for both of them. Nevertheless, it mostly works fine in our setup, and we also made it available to Firefox users in Meetecho for streaming via WebRTC the sessions at the latest IETF.

Lorenzo

[Yuriy Gorlichenko]

Lorenzo Hello. at asterisk 11.5  DTLS-SRTP supports at sip.conf file (dtlsenable and etc). does it Your patch? If yes can you help me with certificates for dtls. I generate self-sign certificate (for webrtc2sip this works well) but in Astrisk i can not make a call.
That errors I see:

Specified private key file '/path/to/CA//private/key/key.ca.cg.pem' for RTP instance '0x7f5ab801f138' could not be used
Attempted to set an invalid DTLS-SRTP configuration on RTP instance '0x7f5ab801f138'
Failed to authenticate device BLAB...@12.34.56.78

 I used this instruction for  generating self-sign certificates:

http://codeghar.wordpress.com/2013/04/16/create-private-certificate-authority-on-linux/
http://codeghar.wordpress.com/2013/04/16/generate-certificate-signing-request-on-linux/
http://codeghar.wordpress.com/2013/04/16/use-private-certificate-authority-to-sign-certificate-signing-request-on-linux/


Can not uderstatnd what is wrong.


Thanks.

[Lorenzo Miniero]

Hi Yuriy,

it looks like an error opening the private key to the certificate. Have you only specified a certificate and not the key in the configuration? I'm not sure whether you can use it this way in OpenSSL.

Anyway, something that I can add to the report I made at the time is that the certificate verification does not necessarily need to be disabled as I said, but if enabled (as is the default in Asterisk) there needs to be a callback specified too to handle the verification process for self signed certificates (which is NULL in Asterisk). This can even simply return 1 (verified) so that the certificate fingerprint can subsequently be computed and then compared to the one received via SDP.

Lorenzo

2013/9/17 Yuriy Gorlichenko <ovos...@gmail.com>

--
 
---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/1Fa1oJ0RN-I/unsubscribe.

To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Yuriy Gorlichenko]

Lorenzo Hello again. after many tryes with werrtc2sip and etc I returned to asterisk webrtc support without "sandwich" (I mean some server between Asterisk and client). What kind of sertificates you generated to work with DTLS-SRTP? If it is not OPENssl, then what is it?

Thanks. 

пятница, 10 мая 2013 г., 17:12:54 UTC+4 пользователь Lorenzo Miniero написал:

[Jay Jideliov]

Hi Lorenzo,

We are working together with Yuri here to figure out what the issue with the certs might be. Here is an example of the device from our conf file:

[s.i.device-636]

fullname = Test Name

secret = fdsfdsfds

qualify = 400

host = dynamic

autoprov = yes

allow=ulaw

allow=g729

allow=ilbc

allow=ulaw

hassip = yes

callwaiting = yes

context = s.i.1010

linenumber = 3

cid_number = 100

nat=yes,force_rport;nat=no

call-limit=3

encryption=yes

icesupport=yes

dtlsenable = yes

dtlsverify = no

dtlscafile = /cetparth/CA/certs/crt.ca.cg.pem

dtlsprivatekey = /certparth/CA/private/key.ca.cg.pem

dtlscertfile = /certhpath/CA/certs/crt.server1.pem

callerid = SI <1010>

We have tried both self-signed certificates and those that we have received for our domain (wildcard). None of them work. 

Please advise.

[Lorenzo Miniero]

I didn't use any particular certificate, just a simple one I generated myself using openssl quite some time ago.

If you're getting the same error Yuri reported at the time, in Asterisk it is failing because either SSL_CTX_use_PrivateKey_file or SSL_CTX_check_private_key is returning an error, so the issue is happening in OpenSSL and not Asterisk. I'm not sure what kind of certificates it is expecting, but it may need them in PEM format. Just for the sake of completeness, try some existing certificates from somewhere else: for instance, when playing with a few apps for debugging purposes I successfullu made use of some certificates that apps on my Fedora installed (e.g., /usr/share/doc/openvpn-2.3.2/sample/sample-keys/server.crt / .key).

Lorenzo 

[Jay Jideliov]

Have tried everything, and still stuck at this... Not sure what the issue might be.

Would really appreciate if you could join us on a 10-minute Skype call regarding that issue, maybe we are missing something. We will show you the exact steps we are taking and the output we are getting.

My skype username is jideliov


Thank you!

[M. M.]

Hello Lorenzo!

You have this errors:  Rejecting secure audio stream without encryption details: audio 63522 RTP/SAVPF 109 0 8 101?

Browser-side error: Incompatible SDP. SIP headers - 488 error.

JSSIP demo <> Asterisk /WS

пятница, 10 мая 2013 г., 17:12:54 UTC+4 пользователь Lorenzo Miniero написал:

Hi all,