-
Ge0rG
mhm. looks like it all started here: http://mozilla.6506.n7.nabble.com/SCTP-and-WebRTC-FYI-td228999.html
-
fippo
ge0rg: i think it was earlier... i'll check the notes from the kickoff
-
Ge0rG
fippo: I'd be glad to get to the root of it. I'm looking for material supporting the not-quite-obvious decision of SCTP-over-DTLS
-
fippo
http://rtc-web.alvestrand.com/ might have some hints... but I can't find anything obvious right now
-
ralphm
Ge0rG: I might have missed earlier discussion on this, but what is the issue?
- Ge0rG is on a flaky 2G connection right now. can't do extensive surfing :(
-
ralphm
Ge0rG: I mean, why is SCTP-over-DTLS a thing that needs to be gotten to the root of? Why is it an unexpected choice?
-
Ge0rG
ralphm: what I am looking for is extensive documentation of the possible alternatives, and why stacking a transport-layer protocol implemented at the app layer on top of another transport layer protocol has been chosen.
-
Ge0rG
also, my 2G connection lags. icmp_req=454 ttl=40 time=34930 ms
-
Ge0rG
ralphm: I can understand the choice was made because of NAT, but I fail to believe it was the only possible choice.
-
Ge0rG
you know, if all you ave is a srtp/dtls hammer, file transfer might look like a nail as well.
-
fippo
ge0rg: RTMFP was/is way more cool imo :-)
-
Ge0rG
sometimes people make brave decisions and stack protocols like it is Babel all over again. And sometimes it even works out reasonably well.
-
Ge0rG
so far, the guardianproject managed twice already to impress and to disgust me at the same time with their protocol stacking: one was serverless XMPP over avahii over OLSR on mobile, and the other was HTTP over OTR text messages over XMPP
-
Ge0rG
and I'd like to form a strong opinion on that SCTP-over-DTLS thing before opening my mouth and ranting it to the moon ;)
-
fippo
ge0rg: shout at rtcweb for using DTLS-SRTP instead of ZRTP :-)
-
Ge0rG
fippo: I have no strong opinion on RTP encryption mechanisms, and do not intend to form one soon
-
fippo
the bad thing about all RTP encryption mechs is that they don't encrypt the header. which really makes me wonder about the https://www.schneier.com/blog/archives/2011/03/detecting_words.html kind of stuff :-/
-
ralphm
fippo: what about http://tools.ietf.org/html/rfc6904?
-
ralphm
(which of course doesn't cover all headers)
-
fippo
ralphm: the basic problem is that there is alot of infrastructure that wants to have access to the rtp headers for QoS.
-
ralphm
yeah, of course
-
ralphm
I suppose the same holds for http v.s. https
-
fippo
well, voip is timecritical. http isn't
-
ralphm
with Internet "service" providers mucking around with your javascript, styling and images if you use http
-
ralphm
Ge0rG: but just so you know, server-less XMPP over SCTP/DTLS/SRTP will be a thing.
-
Zash
But you still need servers to find them.
-
Zash
ralphm, like what XTLS was supposed to be?
-
fippo
ralphm: i think the guys from the RWTH aachen have a prototype for exactly that ,-)
-
ralphm
Zash: Yeah, there have been proposals to negotiate peer-to-peer XML Streams over Jingle to do end-to-end encryption.
-
ralphm
that was using XTLS
-
ralphm
They never left the XEP inbox
-
ralphm
and then were IETF drafts
-
fippo
but we bumped the jingle namespace for XTLS at least!
-
Kev
That was why they never left the inbox, wasn't it?
-
Kev
I forget, this was a while ago.
-
ralphm
Kev: indeed
-
ralphm
tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption-02
-
ralphm
http://tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption-02
-
ralphm
in fact, that spec mentions dtls
-
fippo
i tried implementing XTLS, but found the openssl BIO api to be ... hard to use.
-
ralphm
I think it might be picked up again to match the new webrtc reality
-
ralphm
OpenSSL is the bane of everyones existance
-
ralphm
existence even
-
ralphm
unfortunately, there aren't many alternatives
-
Zash
fippo: Why would you use that directly?
-
fippo
i do think the approach in xep-0320 (mapping rfc 5763 without much more thought) is better than the one shown in draft-meyer
-
fippo
zash: for doing xtls over ibb
-
ralphm
fippo: can we forget about that use case?
-
Zash
fippo: Oh. Yeah. :/
-
ralphm
I think we should maybe move beyond thinking that we want to fall back on ibb
-
Kev
ralphm: Why's that?
-
Kev
And are you saying that as a general policy, or just for some use cases?
-
fippo
https://code.google.com/p/webrtc/issues/detail?id=2796 -- ah, they're going to fix the wrong m-line then!
-
ralphm
Kev: for streaming, file transfer, IBB is an unholy approach. Most servers will not handle it well and large stanzas block streams, I believe.
-
Kev
I'm not sure why server shouldn't handle it well, it's just message switching, same as everything else.
-
Zash
You /could/ run multiple client connections ...
-
fippo
ralphm/zash: +1000!
-
Kev
And in reasonably small chunks.
-
fippo
kev: bad traffic properties. bad karma
-
Kev
There is clearly an upper limit on what is sensible.
-
ralphm
Kev: and I think the upper limit is probably around GSM encoded audio.
-
Kev
fippo: That's choosing not to handle it, rather than being unable to handle it.
-
Kev
I have no idea if fallback for media streams is viable. It feels like it's probably not.
-
ralphm
I'd rather have a single model here, having byte streams out of band.
-
ralphm
If you need alternative transports there, Jingle should be able to handle that.
-
ralphm
If only with co-located proxies
-
Kev
I see your point. But equally, I'm not sure we should dismiss IBB out of hand.
-
ralphm
I'd love to see a counter argument besides "it might still be useful".
-
ralphm
We've been dragging on this forever and it always felt icky
-
Kev
Well, it's guaranteed interop.
-
Kev
Which seems slightly more than 'it might be useful'.
-
ralphm
I mean, base64 encoded RTP wrapped in XML on stanza-switched (neologism?) connection. Meh.
-
fippo
i like it as last-resort for file transfer. but I'd actually prefer to see how well webrtc with all its nat traversal requires it. no decisions without data :-)
-
ralphm
I /could/ kind of see how we might do inband if there's going to be a HTTP/2.0 binding for XMPP eventually.
-
ralphm
fippo: agreed
-
ralphm
fippo: but I do like the idea of separation of concerns, while being sympathetic to Kev's argument.
-
ralphm
Kev: don't break jabber.org, please!
-
ralphm
:-P
-
Kev
The DoS did that already :(
-
Kev
Although it's back now.
-
intosi
That's not Kev breaking things.
-
ralphm
intosi: don't break things
-
intosi
I'm trying to unbreak it.
-
ralphm
hehe
-
ralphm
Meanwhile, I updated the topic for jdev to point here, as many discussions seem to happen here instead of over there
-
Kev
I don't have strong opinions on this.
-
Kev
Well, actually, I do.
-
ralphm
set the topic to
XSF discussion room | Logs: http://logs.xmpp.org/xsf/
-
Kev
Which is that this room gets used for official purposes from time to time, so we shouldn't encourage entry from the types of people who will be a nuisance.
-
Tobias
you welcome anything that takes load of jabber.org?
-
Tobias
:)
-
Kev
But it's not clear to me that this fails that test.
-
Kev
Tobias: The jdev load really isn't a problem.
-
Tobias
i know..was just joking
-
Kev
Although if it encourages the DoSsers to start attacking muc.xmpp.org instead, we will possibly have issues. Athena is...not as powerful.
-
ralphm
Kev: I'm trying to reflect reality, still forming my opinion. Arguably, since standards@xmpp.org is hosted by the XSF, maybe the discussions on MUC should too.
-
MattJ
I can handle it ;)
-
Tobias
yeah...it's Lua, not some C/C++ stuff
-
ralphm
Kev: are the DoSsers targetting jdev specifically?
-
Kev
No.
-
Tobias
all DoS packets are JIT compiled to a single NOP
-
Kev
Which is why I'm not jumping up and down and calling you a lunatic for pointing them here :)
-
ralphm
Do you think pointing to it in the topic gives them ideas?
-
Kev
Probably not. I think this is probably not going to lead to problems.
-
ralphm
awesome
-
Zash
Create a new room for general discussions?
-
ralphm
Zash: I don't see the point, to be honest
-
ralphm
But, one could argue we should reflect the mailinglists in rooms. I've seen a trend to reduce the number of lists, though.
-
Kev
I don't see much value in moving jdev here. I don't see much harm in it.
-
ralphm
oh, heh, there is a board room. Single occupant is a non-board member.
-
Kev
And some old spam in the history.
-
ralphm
techreview@ points here
-
Tobias
also been wondering why board meeting happen here and not at board@
-
Zash
Destroy all rooms!
-
ralphm
Tobias: they are public
-
Kev
Tobias: There's no reason for them not to happen here :)
-
ralphm
Tobias: like we discuss mostly everything on the members list
-
Tobias
Kev, let's move council meetings here?
-
Kev
Council and Board sometimes overlap slightly, so that seems like a not great idea.
-
ralphm
Tobias: that crossed my mind, but what Kev says
-
Tobias
i just seem to remember they've been hold in the board@muc...but if that's wrong nvm
-
ralphm
Tobias: we won't any time soon, I think
-
ralphm
board@ should probably be a restricted room
-
ralphm
like the mailing list
-
intosi
A board-only back channel doesn't sound like a bad idea to me.
-
ralphm
except we would almost never use it
-
intosi
You wouldn't for board meetings, at least.
-
Kev
intosi: A /second/ Board-only back channel.
-
intosi
Kev: right
-
ralphm
Kev: I'd merge them, of course
-
Kev
I think Board can decide if they want such a thing. I don't see the value, but I'm not Board.
-
ralphm
Kev: indeed
- Ge0rG 's got one good reason for IBB. With 0198, you can have stream resumption for file transfers.
-
ralphm
While that might be an argument, I am not sure if it is a particularly strong one.
-
fippo
if your server doesn't like IBB and kills you for bad karma, you might trick the karma mechanism :-)
-
Ge0rG
how does SCTP-DTLS handle live network changes?
-
ralphm
I.e. for file transfers, if the transfer is broken at some point, you know which pieces you have, and can simply start a new transfer for the missing pieces
-
fippo
(i don't want to look further down the road... karma was always simplified too much)
-
fippo
ge0rg: using ice / mice
-
fippo
ge0rg: http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility-02
- Ge0rG puts mice on his read-list
-
Ge0rG
ralphm: resuming a file transfer somewhere in the middle is a security problem, as well
-
ralphm
Ge0rG: I don't see how the transport method affects that statement
-
Ge0rG
ralphm: maybe I'm just hanging at the slight semantic difference between "resume" and "continue"
-
ralphm
Ge0rG: hang in there!
- Ge0rG whistles Jeopardy tune...
-
dwd
We (the Board) do actually have a seperate MUC for private discussion, but we've rarely used it.
-
dwd
I think we used it to discuss an incoming sponsor once, and that's it.
-
Kev
dwd: Other than board@?
-
dwd
Yes; seemed easier to setup a new one than repurpose an existing one at the time.
-
Kev
OK.
-
Kev
Also on xmpp.org?
-
dwd
Yes
-
Kev
OK.
-
ralphm
simon: I want to add pictures from the Lounge to the Summit event in Plus. Can you extend the dates?
-
ralphm
or any other suggestion for collecting pictures from both in one album
-
ralphm
emcho: you guys have a bunch of pictures of the lounge, yes?
-
emcho
ralphm: I'll ask around and I'll come back to you
-
emcho
https://docs.google.com/a/sip-communicator.org/file/d/0BwiF7kZbHitaT3ZxUlNYbWdSWE0/edit https://docs.google.com/a/sip-communicator.org/file/d/0BwiF7kZbHitaYWxCWXdLbW9LeUE/edit https://docs.google.com/a/sip-communicator.org/file/d/0BwiF7kZbHitaU1d0TTBjZUVXNFU/edit https://docs.google.com/a/sip-communicator.org/file/d/0BwiF7kZbHitadUF4bUFNc3lrZE0/edit https://docs.google.com/a/sip-communicator.org/file/d/0BwiF7kZbHitaVXdvY2VlSzNrRkk/edit
-
emcho
are those readable to you?
-
Tobias
emcho, seems so
-
emcho
cool
-
ralphm
emcho: cool. Since they are in the Googleplex already, can you add them to the photos on the XMPP Summit event on G+ by Simon?
-
emcho
ralphm: where's that. can't find anything on simon's page other than the BC photos from the mountains
-
Tobias
https://plus.google.com/events/cducp61naq050ce9cufjlfh37d8?authkey=CIjS4KHjiq2zpAE this is it i think
-
ralphm
emcho: what Tobias says. It is in the XMPP community page
-
ralphm
hi Lance
-
emcho
ralphm: ok done. will add more as people check them in
-
simon
ralphm: dates extended. Photos should be addable.
-
bear
dwd - can you send that link to my andyet email address?
-
dwd
BTW, I personally have no issues with the spreadsheet currently being played with by Board being made public; but I wasn't happy doing that unilaterally or when the figures were still rough.
-
bear
once we get all the final data, no reason to not publish a read-only version IMO
-
ralphm
emcho: thanks!
-
ralphm
simon: thanks! It seems Plus doesn't actually mind
-
dwd
[17:27:17] Dave Cridland: http://ubber.com seems to give me German error messages. Might want to check that out. [17:35:20] Florian Jensen: hmm [17:35:21] Florian Jensen: our geo db is off then
-
dwd
I'm *so* cruel.
-
fippo
rotfl
-
Tobias
hehe
-
bear
LOL
-
ralphm
dwd: good thing you have a thinking cap now
-
bear
ralphm - remember to send me an email for the cost of the realtime logo'd bean bags
-
ralphm
bear: ack
-
ralphm
bear: sent
-
bear
ta
-
dwd
bear, You messed up my spreadsheet. :-)
-
Zash
BEAR, WHYYYYY
-
Tobias
yeah...didn't you get that memo?
-
waqas
Tobias: Which one?
-
Tobias
waqas, about the spreadsheets....right next to the one about the TPS reports
- dwd unmesses the sheet.
-
dwd
bear had made the loss look bigger, whereas now it's much better. Benefits of some ad-hoc training in accountancy.
-
waqas
They train you to make losses look smaller?
-
dwd
No, they train you to get the signs correct.
-
Neustradamus
one guy will post an article about FOSDEM on the website?
-
dwd
Yes, we'll get to that. The Summit, too.
-
ralphm
dwd: what if is isn't one. Or not even a guy?
-
dwd
ralphm, I'm somewhat hoping it won't be a guy. :-)
-
Zash
Maybe it'll be a person.
-
Zash
Or two
-
Zash
or more
-
ralphm
Zash: what!
-
Zash
Just maybe