jdev - 2020-06-14

can somebody clear up my confusion with 0260

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

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

ok let me rephrase

in 0260, dstaddr is only mentioned regarding proxys

its clear how dst addr is calculated there

but we have to calc dstaddr also for our direct candidates

is it there always (sid, initiator, responder)

even for my offered candidates if im responder?

rion, ^

Session initiator and responder. Everything else doesn't matter

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

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

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

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

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

and what does psi when a user sends multiple files

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

and can you give me a link to the wiki page

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

i only found this, and there are no comments

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

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

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.

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

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

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

higest priority candidates is your own ip

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

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

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

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

and really FT should not need more than that

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

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

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

> 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

Just because of this I don't like jingle.

I would better implemented sip

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 ✏

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

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.

waqas: pidgin?