jdev - 2020-06-14


  1. lovetox

    can somebody clear up my confusion with 0260

  2. lovetox

    https://xmpp.org/extensions/xep-0260.html

  3. lovetox

    the dstaddr has to be calculated (sid, initiator, responder)

  4. lovetox

    ok let me rephrase

  5. lovetox

    in 0260, dstaddr is only mentioned regarding proxys

  6. lovetox

    its clear how dst addr is calculated there

  7. lovetox

    but we have to calc dstaddr also for our direct candidates

  8. lovetox

    is it there always (sid, initiator, responder)

  9. lovetox

    even for my offered candidates if im responder?

  10. lovetox

    rion, ^

  11. rion

    Session initiator and responder. Everything else doesn't matter

  12. rion

    For a proxy rules are different yes. There it matters who offers the proxy

  13. lovetox

    yeah k thanks i thought so, but its weirdly not mentioned explicitly, its implied with XEP-0065 only having this one way to calculate it

  14. rion

    That was also my concern in some xep comments on wiki iiirc

  15. rion

    I even remember doing some PRs to the xep. But not sure if any related to this topic. In any case none was merged

  16. lovetox

    rion, do you support multiple file transfer contents per session?

  17. lovetox

    and what does psi when a user sends multiple files

  18. lovetox

    do you create one session per file, or one session and multiple contents

  19. lovetox

    and can you give me a link to the wiki page

  20. lovetox

    https://wiki.xmpp.org/web/Tech_pages/Jingle

  21. lovetox

    i only found this, and there are no comments

  22. rion

    > rion, do you support multiple file transfer contents per session? One session for in and out

  23. rion

    Unfortunately I haven't written any docs yet. I remind myself everytime to do this but still can find some spare time for this

  24. rion

    In short Psi has 1) manager for every application type and every transport type (global instances. e.g. S5Bmanager) 2) specific classes to make instances for every application type and every transport type (e.g. S5BTransport) 3) sessioned managers - a single instances of managers per session. From one side this thing has session and global manager from another side multiple instances of applications of transports. I call these things pads (kind of a place we where application can access global manager. e.g. S5BSessionManagerPad) s5b stuff is not quite standard but I hope it's compatible. It has optimizations wrt trickle candidates. And Psi heavily uses them. Basically it never waits to send session or session answer. If something can be discovered and sent later it will be discovered and sent later. Besides it has priority optimizations. Like if it's possible some higher priority candidate can be discovered later, it will wait before sending candidate-error/use.

  25. rion

    Most clients have simpler implementation. And the XEP doesn't explicitly say what's the preferred way to implement it.

  26. rion

    anyway I look forward to implement webrtc datachannels. I believe it's the future which will eventually deprecate s5b

  27. lovetox

    hm how would you trickle candidates? and why? in what circumstance would a higher priority candidate discovered later?

  28. lovetox

    higest priority candidates is your own ip

  29. lovetox

    i guess you always know your own ip way before any jingle session

  30. lovetox

    my opinion about jingle is, its very generic, that does not mean one has to implement every possible option that one could imagine

  31. lovetox

    i say almost all circumstances, you give your own ip, and a proxy, if for what ever reason own ip does not work

  32. lovetox

    and thats about it, also 10 years of jingle FT told us there is no probably no client out there who implements more than, send one content with candidates, and thats about it

  33. lovetox

    and really FT should not need more than that

  34. lovetox

    also because probably nobody implements all what the spec could do theoretically, i think there are many wholes in the spec that just resulted from no implementation feedback

  35. lovetox

    probably because jingle allows many theoretically things, where no real use case is there for right now

  36. rion

    > i guess you always know your own ip way before any jingle session Think about upnp. If for some reason it's discovered later.

  37. rion

    > that does not mean one has to implement every possible option That's the real problem. Because everyone has in mind their own way. and it's usually it's incompatible with ways of others

  38. rion

    Just because of this I don't like jingle.

  39. rion

    I would better implemented sip

  40. rion

    I recently implemented new ICE (RFC 8445) and I have to say it's way more clear than for example XEP-0166. Even so XEP-0166 has way more circumstances described. In other words less freedom - simpler/more reliable/more compatible implementation

  41. rion

    I recently implemented new ICE (RFC 8445) and I have to say it's way more clear than for example XEP-0166. Even so RFC 8445 has way more circumstances described. In other words less freedom - simpler/more reliable/more compatible implementation

  42. rion

    waqas: how alive Adium nowadays? I was gooing to remove it from Psi's clients detector.

  43. waqas

    rion: Not very, AFAIK. There were some commits 7 months ago, but before that was 2017. I haven't found another client I felt like switching to yet.

  44. rion

    waqas: pidgin?