This repository was archived by the owner on Feb 25, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Feb 25, 2026. It is now read-only.
DTLS role versus RFC 4145 SDP setup attribute #167
Description
From Roman Shpount (see http://lists.w3.org/Archives/Public/public-ortc/2014Dec/0021.html):
P.P.S. Is there a reason why DTLS role does not match the values for RFC 4145 SDP setup attribute? SDP setup attribute can be "actpass", which corresponds to auto, "active", which corresponds to client, "passive" which corresponds to server, and "holdconn" which does not match anything in the ORTC.
Activity
juberti commentedon Dec 12, 2014
Since actpass/active/passive are SDPisms, we decided to adopt the DTLS terminology of client/server.
Note that holdconn has no meaning in the DTLS environment, and actpass can be simulated by initially acting as a server, but then changing to a client if the other side says it wants to be the server.
ibc commentedon Dec 12, 2014
Question: does ORTC mandate actpass/auto for the "initiator"? I expect the
answer is "no" as here there is no such an initiator, but want to confirm
it since the SDP DTLS rules mandate that and I see no reason at all.
Since actpass/active/passive are SDPisms, we decided to adopt the DTLS
terminology of client/server.
Note that holdconn has no meaning in the DTLS environment, and actpass can
be simulated by initially acting as a server, but then changing to a client
if the other side says it wants to be the server.
—
Reply to this email directly or view it on GitHub
#167 (comment).
rshpount commentedon Dec 12, 2014
On Fri, Dec 12, 2014 at 1:28 PM, Justin Uberti notifications@github.com
wrote:
Second question, would RTCDtlsTransport accept DTLS packets before the
start call? Currently, with SDP, an offer is sent with actpass, the client
waits for answer, but will accept DTLS handshake packets, which will switch
it into server mode. If answer is received which forces a client setup
role, DTLS transport is reset and handshake is restarted as a client. Is
this something supported by the current setup?
Roman Shpount
ibc commentedon Dec 12, 2014
Never heard about that. Are you sure? Does it really work?
rshpount commentedon Dec 12, 2014
On Fri, Dec 12, 2014 at 5:10 PM, Iñaki Baz Castillo <
notifications@github.com> wrote:
ibc commentedon Dec 12, 2014
Never seen that working. Interesting, but wont implement it :)
That's why I ask not to mandate actpass/auto for the initiator. It is mucho
better to set client/server. I do not see value in auto.
steely-glint commentedon Dec 12, 2014
How can you check the fingerprint in the answer before you have got the answer? I agree that in principle the DTLS handshake could start before the answer, but it can't safely complete and start actual media flow until the fingerprint is validated.
(The same is true for DataChannel - SCTP shouldn't flow until the answer is in)
ibc commentedon Dec 12, 2014
That is worse when using media over TCP since the DTLS ClientHello would
not be retransmitted. So what I do if the fingerprint arrives after the
ClientHello is to keep state and wait for both of them.
On 12 Dec 2014 23:54, "steely-glint" notifications@github.com wrote:
rshpount commentedon Dec 12, 2014
On Fri, Dec 12, 2014 at 5:54 PM, steely-glint notifications@github.com
wrote:
rshpount commentedon Dec 12, 2014
On Fri, Dec 12, 2014 at 5:52 PM, Iñaki Baz Castillo <
notifications@github.com> wrote:
I do not thin we should change this. We will need auto for the interop.
There are media proxy solutions which would always want to be server. On
the other hand, normal clients would prefer to be client for the faster
call setup. You just never know what you are going to talk to before the
call setup.
Roman Shpount
ibc commentedon Dec 13, 2014
No, we just need the JS shim to behave as that. But that is just an artificial need for legacy interop.
So? that's the problem. Clients want to be DTLS clients as well, but in the SDP world the are SDP offeres which means announcing "actpass" (so the server decides).
In the other side, servers usually receive SDP offers, except when the don't. For example when they start a re-negotiatio (let's say a multiconference joined by a new participant in which the server may wish to send all the other participants a new SDP offer with the new "m=" lines as "Unified Plan" mandate). So, the server is the offerer and, according to SDP DTLS rules, it should announce "actpass" (so the client decides what to be regardless what the server likes to be).
And I wonder, why? Why can't the "call" initiator decide what to be? why is the "called" who decides which role each party is?
BTW: shouldn't we being discussing this in the mailing list? :)
ibc commentedon Dec 13, 2014
Yes and not. If peerA is the ICE Controlling and peerB is ICE Controlled, then peerB MUST be ready to receive a DTLS ClientHello in any interface/tuple in which a STUN Binding request has been received.
Not just delayed, but in case of media over TCP failed (since there won't be DTLS ClientHello retransmissions). So catching them is the only way (until the signaling response arrives so the fingerprint can be checked). Hard stuff anyhow.
Set a flag:
dtls_done = trueand ignore incoming media until remote fingerprint is validated. This is the only way in TCP. In UDP you can just drop DTLS packets if response is not received (because DTLS packets will be retransmitted by the peer).aboba commentedon Jan 9, 2015
Comment from Robin Raymond:
http://lists.w3.org/Archives/Public/public-ortc/2015Jan/0013.html
Proposed text:
Addition to Section 2.3.2:
While a newly constructed RTCDtlsTransport must listen for incoming DTLS packets before start() is called, to complete the negotiation it is necessary to verify the remote fingerprint, which is dependent on remoteParameters, passed to start().
Revised text for RTCDtlsRole:
RTCDtlsRole indicates the role of the DTLS transport.
auto
The DTLS role is determined based on the resolved ICE role: the 'controlled' role acts as the DTLS client, the 'controlling' role acts as the DTLS server. Since RTCDtlsRole is initialized to "auto" on construction of an RTCDtlsTransport, transport.getLocalParameters().RTCDtlsRole will have an initial value of "auto".
client
The DTLS client role. A transition from "auto" to "client" will occur if start(remoteParameters) is called with remoteParameters.RTCDtlsRole having a value of "server".
server
The DTLS server role. If RTCDtlsRole has a value of "auto" and a DTLS client initiates a connection, RTCDtlsRole will transition to "server", even before start() is called. A transition from "auto" to "server" will also occur if start(remoteParameters) is called with remoteParameters.RTCDtlsRole having a value of "client".
Question: Do we need an RTCDtlsRoleChangedEvent?
Updated Section 8.3 to reflect proposed matching rules, reflecting:
pthatcherg commentedon Jan 26, 2015
Would anyone care that the role changed? And if they did, would something
in stats be good enough?
I'm gonna go with "don't put it in until someone really needs it".
On Fri, Jan 9, 2015 at 2:25 PM, aboba notifications@github.com wrote:
steely-glint commentedon Jan 26, 2015
The only reason I can think of that you might care is the server determines the encryption algorithm etc on the Dtls. So you might conceivably care, but in that case you should be specifying the Dtls role not leaving it to auto.
T.
Sent from my iPod
Use ICE role to set DTLS role in answer
Use ICE role to set DTLS role in answer
Use ICE role to set DTLS role in answer
Use ICE role to set DTLS role in answer
Use ICE role to set DTLS role in answer
Use ICE role to set DTLS role in answer
Use ICE role to set DTLS role in answer
Use ICE role to set DTLS role in answer