WebRTC2SIP server and DTLS handshake failure (double SSL client_hello)

[Rosario Santoro]

Hi everyone,

first of all I apologize for bothering you with my doubts but I really can't find a clue about my issue. I hope some of you may help me clarify what I'm getting wrong with my setup.

In few word what I get is an occasional DTLS handshake failure between the called peer (Chrome browser 45.0.2454.93 m) and the WebRTC2SIP server; anyway, as I outlined, this doesn't happen everytime I place a call but occasionally. This means that sometimes I am able to setup the call (and talk) and sometimes I am not.

So here are more details about the scenario (please, find attached my WebRTC2SIP configuration, logs and called Chrome browser logs).

10.4.1.49 - Asterisk 11.13.1

10.4.1.49 - WebRTC2SIP server

10.4.1.47 - Chrome client named BARBATO (uses SIPml5) (first call peer)

10.4.1.47 - Chrome client named SANTORO (uses SIPml5) (second call peer, that's me :) )

10.4.1.47 is a physical machine hosting the 10.4.1.49 virtual machine (VMware, connected through bridge and having access to Internet).

Here are the actions I took (wholly logged in attached files)

1. Both peer login (successful)
2. First call from BARBATO to SANTORO (successful, DTLS handshake ok)
3. 30s call long. Then end (ok)
4. Second call from BARBATO to SANTORO (failure, DTLS handshake wrong)
5. Third call from SANTORO to BARBATO (failure, DTLS handshake wrong)

Other attempts I made in the past randomly show first call failing while next calls succeeding and viceversa: this irregularity keeps me from understanding what is happening.

One interesting fact is that, observing come Wireshark captures I made on 10.4.1.47, the DTLS handshake fails because both the called peer and the webrtc2sip server send a TLS "Client Hello" each other (the former is good but the latter should be a "Server Hello"): this causes the handshake failure.

My certificates are self signed. I read this could lead to problems in modern browsers but with those certificates I am able anyway to place a call, so I think that's fine.

May I ask what is your opinion?

Thank you in advance for your time and your help.

--Rosario

[Marcelo Gornstein]

Hello,

This seems to be happening to us too. We ocasionally have a failed SSL handshake and are still debugging the issue. Any help, tips, or updates will be greatly appreciated guys

[Rosario Santoro]

Hi,

I am able to provide one more detail.

In my first post I forgot to mention that the two browser clients are loaded over an HTTPS connection towards my web server (to avoid the continuous microphone permission request).

Few moments ago I made some tests loading the browser clients over HTTP: the DTLS handshake is perfectly accomplished and the called peer is able to pick up the call and talk.

Switching to HTTPS makes that handshake fail again.

I think I will keep under control both TLS (towards the web server) and DTLS connection.

--Rosario

[Marcelo Gornstein]

That is exactly our issue.

Our scenario uses an Asterisk (11.18.0) and webrtc2sip (r141, doubango r1326), using a browser to receive calls "from the outside world". We are using a "real ssl certificate" (i.e: not self signed)

We tried the sipml5 official example, served with our web server (nginx, if that matters, no special ssl configurations). 

If we access the example through HTTP (and use wss:// against webrtc2sip) we can answer the calls just fine, but if we access the web server through HTTPS the calls fail (but not always, though..) with a dtls handshake error when answering the call from the browser. This was tested with chrome 45.0.2454.101.

Using FireFox (41.0) the calls fail (when answering them) with MSG: DTLS handshake failed [error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher]

--
You received this message because you are subscribed to a topic in the Google Groups "discuss-doubango" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/doubango/oPpXlSRcz2E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to doubango+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

--
http://marcelog.github.com/
https://github.com/marcelog/
skype: marcelo.gornstein
twitter: @mgornstein
--
// I don't sleep. I coffee.
"Make everything as simple as possible, but not simpler." -- Albert Einstein
"There’s a lot of work happening behind the scenes, courtesy of the Spring AOP framework"
"Why do I have this nagging hunch that you have no idea what you're doing?"
"Any society that would give up a little liberty to gain a little security will deserve neither and lose both" - Benjamin Franklin
"Delivering stupid software faster just get's you more stupid software" - Jeff Patton
"Utilitas, Venustas, Firmitas"
"Stop breaking tests. Stop it. Just, stop."
"Sending messages that nobody will read is as useful as writing emo poetry" - learnyousomeerlang.com
"The class object inherits from Chuck Norris."
"Chuck Norris can divide by zero and can unit test an entire application with a single assert."
"Make it work, then make it beautiful, then if you really, really have to, make it fast." - Joe Armstrong
"The world doesn't crash when someone dies".

[Rosario Santoro]

Hi Marcelo,

unfortunately in the meanwhile I didn't manage to find any solution.

Anyway, I am now trying to install a WebRTC2SIP server on CentOS instead of Debian (which I used till now).

WebRTC2SIP on CentOS can be installed via "yum" from repositories, while as we know in Debian it must be compiled from sources.

I'll let you know later.

[Marcelo Gornstein]

Thanks for the update Rosario. We are also trying with other alternatives (i.e: not using webrtc2sip) and will let you know too if we make any progress. 

Best!

[Rosario Santoro]

Hi Marcelo,

I wished to inform you that today I gave a try to OverSIP which is very easy to install on Debian OSes, but it hasn't a media gateway which WebRTC2SIP instead has and which I need. So I didn't go on in testing OverSIP.

After that, I found another "clue" about WebRTC2SIP: comparing the logs of a successful call and a failed one, I realized there is a parameter which changes according to the call outcome.

It is an attribute in the caller SDP (the offer): in successful calls there is "a=setup:active", while in failed calls there is "a=setup:actpass". Searching online I found what that attribute means (here) and, if I got it right, "actpass" is a looser concept than "active".

After this parameter appears, both logs begin to diverge, the former to heaven, the latter to hell.

I don't know how much this may be helpful, but I wished anyway to keep you up to date, as my reasearch goes toward this direction.

Regards

[Marcelo Gornstein]

Hi Rosario,

Thanks for the update, that's a nice catch indeed! And I can confirm we have the *exact* same scenario. We observe a a=setup:actpass on failed calls, and a=setup:active on the ones that succeed.

There's one asterisk option that might be useful (haven't tried it yet, taken from http://doxygen.asterisk.org/trunk/sip.conf.html): 

; dtlssetup = actpass                ; Whether we are willing to accept connections, connect to the other party, or both.
;                                    ; Valid options are active (we want to connect to the other party), passive (we want to
;                                    ; accept connections only), and actpass (we will do both). This value will be used in
;                                    ; the outgoing SDP when offering and for incoming SDP offers when the remote party sends
;                                    ; actpass

We're going to try it, but it would be great if you could that too.

Best :)

[Marcelo Gornstein]

Ah sorry for the lapsus, the dtls handshake is entirely done by webrtc2sip in our scenario. My bad, we'll keep looking! 

[Rosario Santoro]

Don't worry Marcelo :)

Here are few more updates.

First of all, I chose a way around to DTLS handshake problem: falling back to HTTP only, as we both said in our first messages. This is good for me, because I don't require secrecy: I needed HTTPS only to avoid asking microphone permission to the user, but I can obtain this behavior in other ways (i.e. using Chrome flag --use-fake-ui-for-media-stream).

That said, today I found this page which talks about how DTLS peers choose their own role (client or server): in that conversation (and its follow-ups) you will read a confirm of what we observed in our last messages (a=setup:.. influences that decision). The new information I believe to have deduced from there is that the a=setup value is something linked with who is the ICE-controlling peer.

Unfortunately, I think I didn't get what is the solution they propose (if there's one) and from my Wireshark captures I don't see anything strange.

What is your opinion Marcelo?

Thank you for your help! :)

[Marcelo Gornstein]

Hello Rosario,

So we tried Asterisk 13.6.0 without webrtc2sip. It seems to be working ok (more tests will be done tomorrow). The setup is an AWS EC2 instance with:

• Asterisk 13.6.0
• OpenSSL 1.0.2d
• libsrtp 1.5.2
• pjproject 2.4 (although still using chan_sip in asterisk, pjsip was compiled in, not sure yet if this makes a difference or not)
• Chrome 46.0.2490.71
• SIPML5 rev 230

A few tests have been run so far:

• Inbound calls to the browser (from an outside peer setup with UDP) work every time.
• Outbound calls work too (again, to a peer setup with UDP).
• Inbound/Outbound calls and audio from/to a browser work fine too.
  

Considerations

• The SIPML5 code is accessed through https. The audio is being transported through wss.
• The asterisk setup has nothing special, aside from using the versions detailed above.
• Asterisk now handles the websocket connection and the audio

I'll run some more tests, and if everything works ok will write a detailed step-by-step set of instructions. I will send them to you first so you can try to reproduce this first :)

Cheers,

Best!

[Marcelo Gornstein]

Just in case others stumble upon this issue, I've put together a list with the detailed steps needed to make this work (webrtc2sip is no longer required): http://marcelog.github.io/articles/webrtc_with_asterisk_without_webrtc2sip.html

[Rosario Santoro]

Hi everyone,

as Marcelo just wrote, he created a detailed tutorial explaining how to solve the WebRTC2SIP DTLS handshake failure: summarizing, the solution is removing the WebRTC2SIP server and use the Asterisk built-in WebSocket server to establish connections with browser endpoints.

I publicly say "thank you" to Marcelo for the precious help he gave me and I hope his work will be helpful to others who stumble upon the same issue.

Best,

[Zala Pierre GOUPIL]

Thanks, men! I'll try that ASAP and let you know how it goes.

Regards,

Zala

--
You received this message because you are subscribed to the Google Groups "discuss-doubango" group.
To unsubscribe from this group and stop receiving emails from it, send an email to doubango+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Je n'aime pas seulement ma vie, mais aussi celle des autres.

(Blade Runner)

[navaismo]

Great work guys...

Just keep in mind that Asterisk can't handle Video-Calls and there are several issues with the calls and ICE support, Take a look in the Asterisk Jira Page to know how sometimes the answered time affects in the audio and others issues too. Both Asterisk and Doubango  make their best to bring and make it work this new protocol  but there is a huge roadmap to bring WebRTC into a standard.