jdev - 2021-10-10

I'm trying to test an ICE-UDP + DTLS-SRTP implementation with Conversations, but the latter keeps closing the Jingle session with the "failed-application" reason, whether I'm initiating or accepting it on the other side, and with one proposed payload matching that proposed by Conversations itself. I don't have it at hand myself (though perhaps should set an Android emulator, just expecting it to be messy), so the testing/debugging is tricky, but does something look wrong in <https://paste.uberspace.net/jingle-ice-udp-dtls-srtp.xml> (the session-initiate I'm sending)?

I would always hope that error responses contain a detailed reason why the application (or the used library) felt like returning an error response

defanor, do you have the error response? is there anything in the adb log from conversations

usually the next thing I'd do is to identify the code site in conversations where the error response is created

flow, nothing but the "failed-application" element in the reason given in the session-terminate response, and unfortunately no adb log available (the Conversations instance I tried to test it with is just on someone else's phone, not nearby). Perhaps will indeed try to dive into those sources now.

imagine how nice it would be if conversations would put some detailed information in the error response

and if it's just the coordinations of the source file where the error is created

stacktrace would even be better

add some related state on top of it and $$$

Apparently it happens if anything fails in the WebRTC setup function (setupWebRTC in JingleRtpConnection.java), and looks like there's quite a few things that can fail.

looks like even the exception isn't logged here :(

Someone summon Daniel

or join the conversations MUC and suggest that improve the logging and the error response stanza

Indeed, will try that. And maybe will find out there how it's run on desktops.

defanor, usually via an Android Virtual Device (AVD) which an be created using the Android SDK

tl;dr: simply install Android Studio :)

I see a few packages in Debian 11 repositories, like "android-sdk-platform-23", but I think I saw a remark somewhere in Conversations documentation that it needs Android API level (I think that's how it's called, not familiar with phone software development at all) 21 or 22 at most. Though maybe it was out of date.

I fear I have to recommend to not use your distribution packages in this case…

the Android development ecosystem is usually to fast moving for most distributions

I mean you could of course try it, but i you want to have a good experience you want to install Android Studio and Co locally

Well, will ask about it in the Conversations MUC first -- likely somebody there knows whether it'd work. I just prefer to keep the system relatively clean, with software coming from the system repositories and being managed/updated all at once. Though there always are VMs or containers, too.

to the library developers, do you provide a method like getTag() which returns the first tag found within a stanza?

or does this method always return a list? because tags can be more than once in a stanza

In Prosody we provide one to get the first matching tag, and one to iterate

You can supply a name to get a named tag in the same namespace, or supply a namespace as well

I'm just exposing libxml2's structures, for use with its functions, but also a convenience search function to find the first matching element. But that's in C and while trying to avoid additional memory allocations, so forming a new list would be more awkward than in GC'd languages; in those functions for both cases may be appropriate.

lovetox, in xmpp-rs we aim at providing high-level APIs instead of XML ones, in order to encourage developers to implement extensions in the library instead of directly in their software.

We’re not there yet.

Link Mauve: offtopic, should that listed on the xmpp library/tools page?

Link Mauve, yeah i go also that way

Gajim has only 90 matches for getTag anymore in a codebase with 100k loc

:)

emus, I’d say, not yet.

It’s definitely not ready for prime time.

Some parts are already pretty robust, like tokio-xmpp or xmpp-parsers, but the rest of the xmpp-rs APIs are not there yet.

ok, just let folks one once you think it is 🙂

Sure!

😃

<https://datatracker.ietf.org/doc/html/rfc5763#section-6.7.1> says that "Implementations MUST treat all ICE candidate pairs associated with a single component as part of the same DTLS association.", but what about different components? It appears that Dino performs a handshake just on the first component, and then uses the obtained key material for all the components, skipping handshakes on those.

But I can't find whether any specification says that it's okay.

From <https://datatracker.ietf.org/doc/html/rfc5764#section-3>, it sound slike at least two sessions are used, with a DTLS association/connection per session.

Well, unless there's multiplexing. But there's no multiplexing in this case.

Oh, but DTLS-SRTP sessions can share DTLS sessions/handshakes. Looks like it's correct behaviour, then.