XSF Discussion - 2020-11-30

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.

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?

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.

You had the same issue with ZRTP encryption too.

Link Mauve, I bet there was no client only supporting ZRTP encrypted Jingle

Can WebRTC even use TCP ICE btw?

larma, Jitsi IIRC does.

Yes, but Jitsi can perfectly handle when the other client does not

also even xep-0371 has the same issue as XEP-0176 in that it only is the ICE layer, not the DTLS on top

That’s possible, I haven’t tested it.

So when the client announce 371, how do I know it means "I use WebRTC"

technicaly speaking WebRTC-only clients only implement a subset of 176/371 when requiring dtls to be used

You don’t, you have to check for DTLS-SRTP support too, and RTP, and the various (mandatory?) extensions.

The solution might be to fix all still-maintained clients with no support for DTLS-SRTP to stop advertising calls there.

But at this point, it might even be easier to add support for DTLS-SRTP.

DTLS-SRTP is not always an option

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)

Right.

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. ✏

Maybe adding a “negative” feature, to say “I don’t support DTLS-SRTP”?

Err, “I require it”?

(It’s still morning.)

And how should a client that only implements ICE know to check that this feature does not exist? That's weird

Maybe ICE+DTLS-SRTP should just be a different transport than ICE

it's already weird enough that DTLS-SRTP is something inside the ICE-UDP transport when it could have been a security precondition.

+1

I think I once reported that to Philipp, but I don’t remember his answer.

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"

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.

Deferred and inactive since a bit after the time of its initial publication.

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.

larma, wanna reach out to the author and see if they are still interested?

Zash: which author?

larma: of 343

Does it help to contact them pointing out a problem without there being a solution in place?

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.

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

However, 320 was moved to draft recently, so it's probably impossible to fix that.

Memberbot is online for the Q4-2020 membership applications

👍️

whoops I forgot to look at pending PRs before submitting my MIX patches, but it looks like there’s no overlap at least