Cannot complete DTLS handshake

[Filippo Guerzoni]

Hi
The use case is the same of streaming example, the difference is that I'm trying to connect an openwebrtc android client to Janus Gateway.
Signalling and ice handshake play well until I reach the final step where DTLS handshake should fully complete.

After I get (both browser and android client)

The DTLS handshake for the component 1 in stream 1 has been completed

Janus writes on log (android client only):

DTLS already set up, disabling retransmission timer!

instead of

The DTLS handshake has been completed

as in the browser case.
Then (Android client only), after 1 minute, the session goes to timeout.
Instead in the browser case I get:

WebRTC media is now available.

The outcome is that in the browser case streaming reaches started status, while in android client case the session is disconnected.

I really can't understand why.

Following are available pastebin with log for both browser and android client use case.
Janus log browser case: http://pastebin.com/ubaG5cUn
Janus log android client case: http://pastebin.com/NRWLGj7P


Please note: android client code is still very experimental and there are few things to know:
1) for sake of simplicity during trickle I send back to Janus only first UDP ice candidate for video (both Janus and client are on the same LAN). Issue doesn't disappear sending back to Janus every ice candidate available on the client.
2) for some openwebrtc internal issues (to fix) the trickle candidate is sent back to Janus before the jsep answer. Seems to me not a problem because Janus is smart enough to set the candidate as pending and use it later on.

Thanks and regards

[Lorenzo Miniero]

Sounds like an issue on the Android end: as far as Janus is concerned, DTLS was correctly established, as it seems to be confirmed looking at the log. Have you looked at the DTLS exchange with Wireshark to see if you can spot anything weird? You dhould probably also check if the openwebrtc stack allows you to see what was sent and received with respect to DTLS, and if there were any errors in the handshake on that end.

Try the echotest as well: unlike the streaming demo, the echotest has the client originate an offer (in the streaming event, Janus offers and your client answers), which also changes the way the DTLS handshake takes place (DTLS client/server roles are inverted).

 

L.

[Filippo Guerzoni]

Thank you for quick reply,

very first thing I notice inspecting with wireshark is that:
- in the browser case the protocol used is TLSv1.2
- in the android case the protocol used is DTLSv1.0

I'm not a TLS expert, so please advice me if it could be the root cause in order to point the effort towards updating TLS on OWR stack.

[Lorenzo Miniero]

I'm no expert either, but that shouldn't be an issue. AFAIK DTLS 1.2 is offered but not required. Besides, Janus thinks the handshake went fine: if 1.2 was a requirement, it would be Janus itself (or actually it's OpenSSL stack) shutting the thing down, while apparently it's the Android part that's still waiting for something.

L.

[Filippo Guerzoni]

Found.
The problem was already written in the log.
In the remote sdp I found:

m=application 1 DTLS/SCTP 0

c=IN IP4 0.0.0.0

a=inactive

Actually the datastream was not implemented on the android side and so Janus could not complete DTLS for that.
I implemented SimpleStreamSet available in openwebrtc-android-sdk which lacks datastream.
The fix on the android side is straightforward.

On the Janus side, while debugging ice.c the program flow entered:

    if(handle->data_stream && !handle->data_stream->disabled) {
        if(handle->data_stream->rtp_component && (!handle->data_stream->rtp_component->dtls ||
                !handle->data_stream->rtp_component->dtls->srtp_valid)) {
            /* Still waiting for this component to become ready */
            janus_mutex_unlock(&handle->mutex);
            return;
        }
    }

which led to session timeout.

[Lorenzo Miniero]

That shouldn't be an issue when bundle is supported, as in that case the same DTLS handshake is used for all media. I take it that the android app doesn't support it?

L.

--
You received this message because you are subscribed to the Google Groups "meetecho-janus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janu...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Filippo Guerzoni]

Sorry, I really don't know.
What I've found is that implementing and managing data stream on android side solved the issue.
Next days I'll continue to grasp OWR sources, and in case I'll update the thread.

[Chetan Naik]

Hi,

I am trying to setup the echo test android client as per https://github.com/Computician/janus-gateway-android

I am using google's stun server for the ICE.

First I tried doing the echo from http://janus.conf.meetecho.com/echotest.html, but the connection was not established. I thought it could be due non-availability of TURN server, as my android endpoint is behind a symmetric NAT.

Then, I hosted janus-gateway on a local computer and tried the echo test from the android device. Both the device are now on the same network. The ICE candidates are exchanged, but at the end of everything, janus is stuck at "Still waiting for the DTLS stack for component 1 in stream 1..." and I dont see the echoed video on the android device. The bundle and rtcp-mux are supported for this session..

Is it some ICE setup issue? or Could it be due to ports being blocked on the android device? 

I am attaching a detailed log with this. 

[Lorenzo Miniero]

http://www.meetecho.com/blog/understanding-the-janus-admin-api/

L.

[Chetan Naik]

hi,

here is the admin summary of the webrtc session I am not able to establish.

http://pastebin.com/gUXks5g6

please help, what could be wrong?

[Lorenzo Miniero]

Possibly a firewall error of some sorts, it's stuck on "connecting" with both local and remote candidates available. You should have a look at what travels on the wire, e.g. via wireshark or tcpcump, to see if STUN connectivity checks are being sent/received on both ends.

L.

[Chetan Naik]

The issue is sorted, though not solved.

The trouble is with the REST API implementation on android side. 

The call was established when I used websockets as the transport mechanism.

I will try to fix the REST API issue and keep posted.

[zj z]

hi， i met the same prolem，how do you deal with it?  i am not good at Android。hoping for your reply