XMPP Council - 2014-01-14

OK, http://xmpp.org/extensions/inbox/jingle-dtls.html (surely this should be called jingle-srtp?) is confusing me.

It's not at all clear to me if that sctpmap element is proposing an additional candidate using SCTP at the IP layer, or if it's saying that when the two proposed UDP candidates are tried, SCTP should be tried over UDP.

jingle-dtls-sctp probably

(Because SCTP will either work at the transport layer or tunnelled over UDP, right?)

in the context of webrtc it's sctp/udp authenticated via dtls fingerprints

So the sctpmap element in this case is saying "Try the existing candidates, but tunnel SCTP over them".

yeah, that's the plan

Which wasn't at all clear to me from the times I read it (I assumed as much, given it should have been its own candidate otherwise, but ...).

In which case, how does this play with having multiple candidates?

the tricky issue is that this will often be BUNDLE'd with srtp

Is there any reason I shouldn't be able to offer both SCTP/DTLS/UDP candidates, and TCP candidates?

Well, that's not remotely possible given the structure of the transport mechanism, is it?

you think this shoudldn't be part of <transport/>

I'm saying no such thing.

I'm asking questions.

you make me wonder...

if it makes more sense to put the sctpmap to the 0234 part

The first thing I'm wondering is whether it's possible to implement from just this protoXEP, without already knowing what the author means :)

Although we've published un-implementable Experimentals before, as a statement of direction, so that's not a blocker.

I'm going to OK this, but I'm not quite sure yet that it's the right way to do it (nor am I sure otherwise), I lack prerequisite knowledge.

we'll see

i'm pretty eager to see a pull request for strophe.jingle :-)