DTLS role versus RFC 4145 SDP setup attribute #167
Comments
|
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. |
|
Question: does ORTC mandate actpass/auto for the "initiator"? I expect the Since actpass/active/passive are SDPisms, we decided to adopt the DTLS Note that holdconn has no meaning in the DTLS environment, and actpass can — |
|
On Fri, Dec 12, 2014 at 1:28 PM, Justin Uberti [email protected]
Second question, would RTCDtlsTransport accept DTLS packets before the Roman Shpount |
Never heard about that. Are you sure? Does it really work? |
|
On Fri, Dec 12, 2014 at 5:10 PM, Iñaki Baz Castillo <
|
|
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 |
|
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. |
|
That is worse when using media over TCP since the DTLS ClientHello would
|
|
On Fri, Dec 12, 2014 at 5:54 PM, steely-glint [email protected]
|
|
On Fri, Dec 12, 2014 at 5:52 PM, Iñaki Baz Castillo <
I do not thin we should change this. We will need auto for the interop. Roman Shpount |
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? :) |
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: |
|
Comment from Robin Raymond: Proposed text: Addition to Section 2.3.2: Revised text for RTCDtlsRole: RTCDtlsRole indicates the role of the DTLS transport. auto client server Question: Do we need an RTCDtlsRoleChangedEvent? |
#48 Update to the Statistics API, reflecting: #85 Update on 'automatic' use of scalable video coding, as noted in: #156 Update to the H.264 parameters, as noted in: #158 Update to the 'Big Picture', as noted in: #159 Added support for maxptime, as noted in: #160 Changed 'RTCIceTransportEvent' to 'RTCIceGathererEvent' as noted in: #161 Update to RTCRtpUnhandledEvent as noted in: #163 Added support for RTCIceGatherer.state as noted in: #164 Revised the text relating to RTCIceTransport.start() as noted in: #166 Added text relating to DTLS interoperability with WebRTC 1.0, as noted in: #167 Revised the text relating to RTCDtlsTransport.start() as noted in: #168 Clarified handling of incoming connectivity checks by the RTCIceGatherer as noted in: #170 Added a reference to the ICE consent specification, as noted in: #171
|
Would anyone care that the role changed? And if they did, would something 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 [email protected] wrote:
|
|
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
|
When creating answer, check ICE role while determining DTLS role. ORTC thread on how roles are set w3c/ortc#167 (comment) When remote is ice-lite and there is no answering role set, the answer uses the default which is DTLS client. So 'setup' is set as 'active' and answer sent. But, when DTLS transport is started, it checks the ICE role and sets itself as DTLS server (because remote is lite and hence local agent becomes controlling ICE agent). So, both sides end up being DTLS server adnd nobody sends client hello.
When creating answer, check ICE role while determining DTLS role. ORTC thread on how roles are set w3c/ortc#167 (comment) When remote is ice-lite and there is no answering role set, the answer uses the default which is DTLS client. So 'setup' is set as 'active' and answer sent. But, when DTLS transport is started, it checks the ICE role and sets itself as DTLS server (because remote is lite and hence local agent becomes controlling ICE agent). So, both sides end up being DTLS server and nobody sends client hello.
When creating answer, check ICE role while determining DTLS role. ORTC thread on how roles are set w3c/ortc#167 (comment) When remote is ice-lite and there is no answering role set, the answer uses the default which is DTLS client. So 'setup' is set as 'active' and answer sent. But, when DTLS transport is started, it checks the ICE role and sets itself as DTLS server (because remote is lite and hence local agent becomes controlling ICE agent). So, both sides end up being DTLS server and nobody sends client hello.
When creating answer, check ICE role while determining DTLS role. ORTC thread on how roles are set w3c/ortc#167 (comment) When remote is ice-lite and there is no answering role set, the answer uses the default which is DTLS client. So 'setup' is set as 'active' and answer sent. But, when DTLS transport is started, it checks the ICE role and sets itself as DTLS server (because remote is lite and hence local agent becomes controlling ICE agent). So, both sides end up being DTLS server and nobody sends client hello.
When creating answer, check ICE role while determining DTLS role. ORTC thread on how roles are set w3c/ortc#167 (comment) When remote is ice-lite and there is no answering role set, the answer uses the default which is DTLS client. So 'setup' is set as 'active' and answer sent. But, when DTLS transport is started, it checks the ICE role and sets itself as DTLS server (because remote is lite and hence local agent becomes controlling ICE agent). So, both sides end up being DTLS server and nobody sends client hello.
When creating answer, check ICE role while determining DTLS role. ORTC thread on how roles are set w3c/ortc#167 (comment) When remote is ice-lite and there is no answering role set, the answer uses the default which is DTLS client. So 'setup' is set as 'active' and answer sent. But, when DTLS transport is started, it checks the ICE role and sets itself as DTLS server (because remote is lite and hence local agent becomes controlling ICE agent). So, both sides end up being DTLS server and nobody sends client hello.
When creating answer, check ICE role while determining DTLS role. ORTC thread on how roles are set w3c/ortc#167 (comment) When remote is ice-lite and there is no answering role set, the answer uses the default which is DTLS client. So 'setup' is set as 'active' and answer sent. But, when DTLS transport is started, it checks the ICE role and sets itself as DTLS server (because remote is lite and hence local agent becomes controlling ICE agent). So, both sides end up being DTLS server and nobody sends client hello.
When creating answer, check ICE role while determining DTLS role. ORTC thread on how roles are set w3c/ortc#167 (comment) When remote is ice-lite and there is no answering role set, the answer uses the default which is DTLS client. So 'setup' is set as 'active' and answer sent. But, when DTLS transport is started, it checks the ICE role and sets itself as DTLS server (because remote is lite and hence local agent becomes controlling ICE agent). So, both sides end up being DTLS server and nobody sends client hello.
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.
The text was updated successfully, but these errors were encountered: