JVB 2.0 DTLS 1.2 handshake fails with Freeswitch


I am trying to integrating JVB 2.0 with Freeswitch 1.8.5 on PSTN call, and found out that DTLS handshake is broken between JVB 2.0 and Freeswitch 1.8.5 with DTLS 1.2 version. It is good with DTLS 1.0 version.

  1. SDP from JVB is offer
  2. SDP from Freeswitch is answer
  3. Freeswitch works as DTLS client
  4. JVB works as DTLS server

After Certificate/Client Key Exchange/Certificate Verify/Change Cipher Spec, JVB sends Fatal Alert to Freeswitch with error Illegal Parameter 47.

  1. When I change Freeswitch to use DTLS 1.0, the error is gone and call works well.

  2. There is no issue between JVB and Chrome with DTLS 1.2

  3. There is no issue between Freeswitch and Chrome with DTLS 1.2.

I attached the wireshark.

Any idea?

Best regards,

/Kaiduanfreeswitch-jvb-dtls-1.2.pcap (35.9 KB)

Not sure, I can try and take a look. The first thing I’d check is probably to compare it against a successful JVB <-> Chrome DTLS 1.2 negotiation and see what’s different. Do you have a pcap of that handy as well?

The pcap file has the DTLS handshake between JVB and Chrome, please use filter dtls && udp.port == 64531 to see DTLS 1.2 between Chrome and JVB, and dtls && udp.port == 35994 to see DTLS 1.2 between Freeswitch and JVB.

I do notice freeswitch responds with a certificate using a different encryption algorithm compared to chrome, but I think it’s one that should still be supported according to what I see coming from the JVB. Some other differences in there as well, but I’m far from a DTLS expert. The error codes are also, unfortunately, rarely helpful. Do you have JVB logs? We might get something more useful there.

Please check attached jvb log around line 1658.
jvb-dtls-1.2.fail.log (719.4 KB)

Hm, the stack trace there is very confusing. It shows org.bouncycastle.tls.DTLSRecordLayer.receive calls org.bouncycastle.tls.DTLSRecordLayer.closeTransport, but the code only seems to do that if the received message was an alert, so that doesn’t seem to make much sense.

To further debug I’d run the bridge in Debug mode and step through what was going on there. The question is which of the chunks of that message before the alert JVB is having a problem with. I’d think it’ll be something around a selected cipher suite, as those are what are dynamic, but that’s just a hunch.

How to debug JVB? It is run on cloud.

Usually to debug things like this I shut down the JVB running in the cloud and configure a local JVB to connect to that Jicofo, etc. so it looks just like the remote JVB, just running locally so I can run it in IntelliJ and debug.

Were you able to get a debug bridge working? Find anything?

Not yet, our environment is a little bit different than Jitsi team.

I build bouncycastle library from source, added some logs to the DTLS part, and found out the root cause of the issue.

In CertificateRequest from JVB (JVB works as DTLS server), the certificate type is ECDSA, and when bouncycastle library handles CertificateVerify message from Freeswitch, the signature algorithm is rsa_pkcs1_sha1, then bouncycastle library throws FatalAlertError with Illegal Parameter/47.

The solution is to add CertificateType ClientCertificateType.rsa_sign in TlsServerImpl.kt in jitsi-media-transform.



1 Like