KevOK, http://xmpp.org/extensions/inbox/jingle-dtls.html (surely this should be called jingle-srtp?) is confusing me.
KevIt'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.
fippojingle-dtls-sctp probably
Kev(Because SCTP will either work at the transport layer or tunnelled over UDP, right?)
fippoin the context of webrtc it's sctp/udp authenticated via dtls fingerprints
KevSo the sctpmap element in this case is saying "Try the existing candidates, but tunnel SCTP over them".
fippoyeah, that's the plan
KevWhich 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 ...).
KevIn which case, how does this play with having multiple candidates?
fippothe tricky issue is that this will often be BUNDLE'd with srtp
KevIs there any reason I shouldn't be able to offer both SCTP/DTLS/UDP candidates, and TCP candidates?
KevWell, that's not remotely possible given the structure of the transport mechanism, is it?
fippoyou think this shoudldn't be part of <transport/>
KevI'm saying no such thing.
KevI'm asking questions.
fippoyou make me wonder...
fippoif it makes more sense to put the sctpmap to the 0234 part
KevThe first thing I'm wondering is whether it's possible to implement from just this protoXEP, without already knowing what the author means :)
KevAlthough we've published un-implementable Experimentals before, as a statement of direction, so that's not a blocker.
KevI'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.
fippowe'll see
fippoi'm pretty eager to see a pull request for strophe.jingle :-)
XMPP Council - 2014-01-14