the dstaddr has to be calculated (sid, initiator, responder)
Neustradamushas joined
lovetox
ok let me rephrase
lovetox
in 0260, dstaddr is only mentioned regarding proxys
lovetox
its clear how dst addr is calculated there
lovetox
but we have to calc dstaddr also for our direct candidates
lovetox
is it there always (sid, initiator, responder)
lovetox
even for my offered candidates if im responder?
kikuchiyohas joined
kikuchiyohas left
lovetox
rion, ^
rion
Session initiator and responder. Everything else doesn't matter
kikuchiyohas joined
kikuchiyohas left
rion
For a proxy rules are different yes. There it matters who offers the proxy
Martinhas left
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
Martinhas joined
rion
That was also my concern in some xep comments on wiki iiirc
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
kikuchiyohas joined
lovetox
rion, do you support multiple file transfer contents per session?
kikuchiyohas left
lovetox
and what does psi when a user sends multiple files
lovetox
do you create one session per file, or one session and multiple contents
kikuchiyohas joined
lovetox
and can you give me a link to the wiki page
lovetox
https://wiki.xmpp.org/web/Tech_pages/Jingle
lovetox
i only found this, and there are no comments
kikuchiyohas left
rion
> rion, do you support multiple file transfer contents per session?
One session for in and out
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
kikuchiyohas joined
asterixhas left
asterixhas joined
Yagizаhas left
asterixhas left
asterixhas joined
kikuchiyohas left
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.
rion
Most clients have simpler implementation. And the XEP doesn't explicitly say what's the preferred way to implement it.
rion
anyway I look forward to implement webrtc datachannels. I believe it's the future which will eventually deprecate s5b
debaclehas joined
debaclehas left
debaclehas joined
lovetox
hm how would you trickle candidates? and why? in what circumstance would a higher priority candidate discovered later?
lovetox
higest priority candidates is your own ip
lovetox
i guess you always know your own ip way before any jingle session
lovetox
my opinion about jingle is, its very generic, that does not mean one has to implement every possible option that one could imagine
kikuchiyohas joined
lovetox
i say almost all circumstances, you give your own ip, and a proxy, if for what ever reason own ip does not work
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
lovetox
and really FT should not need more than that
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
lovetox
probably because jingle allows many theoretically things, where no real use case is there for right now
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.
moparisthebesthas left
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
rion
Just because of this I don't like jingle.
flowhas left
rion
I would better implemented sip
moparisthebesthas joined
goffihas left
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✎
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 ✏
rion
waqas: how alive Adium nowadays? I was gooing to remove it from Psi's clients detector.
adiaholic_has left
adiaholic_has joined
dropshas left
dropshas joined
asterixhas left
asterixhas joined
kikuchiyohas left
lovetoxhas left
asterixhas left
kikuchiyohas joined
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.