-
larma
Also related to Jingle: XEP-0320 is based on XEP-0176 and thus clients implementing XEP-0320 tend to announce support for XEP-0176 via disco. However, WebRTC clients can't create a transport using XEP-0176 without XEP-0320. A client only implementing XEP-0176 will consider WebRTC clients compatible because that's what they announce, but they won't be able to create a connection.
-
larma
Should we change things such that XEP-0320 support does not imply full support of XEP-0176 and thus clients only implementing WebRTC should only announce `urn:xmpp:jingle:apps:dtls:0` but not `urn:xmpp:jingle:transports:ice-udp:1`? Or any better idea?
-
Link Mauve
larma, a better idea might be to make WebRTC-only clients advertise only XEP-0371 and keep 0176 for legacy unencrypted clients, but every WebRTC client currently uses 0176 and migrating them all in an incompatible manner would take years too probably.
-
Link Mauve
You had the same issue with ZRTP encryption too.
-
larma
Link Mauve, I bet there was no client only supporting ZRTP encrypted Jingle
-
Link Mauve
Can WebRTC even use TCP ICE btw?
-
Link Mauve
larma, Jitsi IIRC does.
-
larma
Yes, but Jitsi can perfectly handle when the other client does not
-
larma
also even xep-0371 has the same issue as XEP-0176 in that it only is the ICE layer, not the DTLS on top
-
Link Mauve
That’s possible, I haven’t tested it.
-
larma
So when the client announce 371, how do I know it means "I use WebRTC"
-
larma
technicaly speaking WebRTC-only clients only implement a subset of 176/371 when requiring dtls to be used
-
Link Mauve
You don’t, you have to check for DTLS-SRTP support too, and RTP, and the various (mandatory?) extensions.
-
Link Mauve
The solution might be to fix all still-maintained clients with no support for DTLS-SRTP to stop advertising calls there.
-
Link Mauve
But at this point, it might even be easier to add support for DTLS-SRTP.
-
larma
DTLS-SRTP is not always an option
-
larma
Jingle can be used with SIP gateways, which might end at hardware SIP devices which tend to not support DTLS-SRTP (some do ZRTP though)
-
Link Mauve
Right.
-
larma
Point is: it is a totally valid decision for a client to support unencrypted ICE but not ICE+DTLS-SRTP. There is however no way to discover if the other end *requires* DTLS-SRTP. ICE+DTLS-SRTP clients announce what was unencrypted ICE before without actually supporting it.✎ -
larma
Point is: it is a totally valid decision for a client to support unencrypted ICE but not ICE+DTLS-SRTP. There is however no way to discover if the other end *requires* DTLS-SRTP. WebRTC-only clients announce what was unencrypted ICE before without actually supporting it. ✏
-
Link Mauve
Maybe adding a “negative” feature, to say “I don’t support DTLS-SRTP”?
-
Link Mauve
Err, “I require it”?
-
Link Mauve
(It’s still morning.)
-
larma
And how should a client that only implements ICE know to check that this feature does not exist? That's weird
-
larma
Maybe ICE+DTLS-SRTP should just be a different transport than ICE
-
larma
it's already weird enough that DTLS-SRTP is something inside the ICE-UDP transport when it could have been a security precondition.
-
Link Mauve
+1
-
Link Mauve
I think I once reported that to Philipp, but I don’t remember his answer.
-
larma
IIRC he argued that DTLS is more like part of the transport layer, which isn't that wrong considering that we now have the problem that some clients implement only the transport layer that includes DTLS. However if it is part of the transport layer, it shouldn't reuse the ICE-UDP and instead make a ice-dtls transport layer - or just make one that is called webrtc-datagram which is way easier to understand for the average dude than "use ICE-UDP with DTLS-SRTP"
-
larma
Also we now have XEP-0343 which is broken because it provides a streaming transport but uses the ICE-UDP transport element which according to its registrar entry is a datagram transport.
-
Zash
Deferred and inactive since a bit after the time of its initial publication.
-
Link Mauve
Speaking of WebRTC, I didn’t quite understand what msid is, and whether it’s useful outside of the web platform. I noticed Conversations gets it completely wrong, but I’m not sure how to do it properly.
-
Zash
larma, wanna reach out to the author and see if they are still interested?
-
larma
Zash: which author?
-
Zash
larma: of 343
-
larma
Does it help to contact them pointing out a problem without there being a solution in place?
-
Zash
I'm not sure I follow what the problem is. Sounds to me like the XEP might need some attention from an author, as it seems to have been inactive with only minor editorial work for years.
-
larma
The problem of 343 is similar to the one of 320 though: both were like "OK, webrtc is something in dtls in ice-udp, so let's reuse XEP 176 which provides us with ice-udp and then add dtls", 343 just continues the story " and then add sctp". IMO these two should get their own transports in jingle layer: "webrtc-srtp" (datagram), "webrtc-datachannel" (streaming) - and not reuse "ice-udp" (datagram). It's just more visible that something is wrong with 343 because it's a different transport type
-
larma
However, 320 was moved to draft recently, so it's probably impossible to fix that.
-
Alex
Memberbot is online for the Q4-2020 membership applications
-
Zash
👍️
-
mathieui
whoops I forgot to look at pending PRs before submitting my MIX patches, but it looks like there’s no overlap at least