RE: About non rtcp-mux and DTLS connections

Iñaki Baz Castillo said: 

"> though the sessions can share a single DTLS session and hence amortize the initial public key handshake!.

What does it mean??? is it talking about the common TLS/DTLS session re-usage? can it be used for two *concurrent* connections? or what?

In short, if my WebRTC implementation opens a socket for SRTP and another for SRTCP, should I expect two separate DTLS connections on them? or should I be ready to receive an unique DTLS handshake (in which port??) and share the key material in the other socket too? and in that case, how to signal that?"

[BA] RFC 5764 Section 3 creates some confusion about what is to be expected in the non-mux case:  one DTLS session or two? 

However, AFAIK RFC 5763 provides no way to signal the use of only a single DTLS session, and all  existing WebRTC implementations utilize distinct DTLS sessions for RTP and RTCP in the non-mux case.    

So I think that distinct DTLS sessions is the only way it can work in practice.

Received on Wednesday, 30 July 2014 20:40:44 UTC