Conversations: Support audio/video calls + encryption

[specktator]

It will be an awesome feature for conversations to support audio/video calls via Jingle-ICE and with ZRTP encryption. The perspective, IMHO, should be in context to be able to communicate with desktop clients too and not only between conversations clients, we all hate that incompatibility in xmpp right?

From my experience STUN and (!) TURN servers autodiscovery should be implemented, even if TURN relays data through the server, cause UPnP in some cases is nasty.

If needed, I can provide testing VPS.

[tonghuix]

Awesome idea!

[SamWhited]

Duplicate of #1139, #1059, probably others.

This is not in the scope of this project.

[specktator]

@SamWhited I'm sorry, I did search the issues before posting, but didn't return anything related with my keywords. Anyway, what's, in short terms, the scope of the project so we can think/brainstorm and follow up?

@tonghuix Yes I would really love to see conversations with audio/video support too, but its a lot of work and I know it. Maybe we can start a fork with the others who wanted it and and pull when its stable? @SamWhited ?

[SamWhited]

I'm sorry, I did search the issues before posting, but didn't return anything related with my keywords.

Yah, GitHub changed search a while back to only search open issues (and ever since then a lot of projects I work on have gotten a lot more duplicates).

Anyway, what's, in short terms, the scope of the project so we can think/brainstorm and follow up?

The README's always a good place to start. Generally speaking, Conversations follows the Unix philosophy of "do one tihng and do it well" or "be a modern IM platform with sane defaults". @iNPUTmice or @andersruneson may have a more specific short pitch.

Maybe we can start a fork with the others who wanted it and and pull when its stable? @SamWhited ?

Not up to me, but it's open source so you can always start a fork if you want :)

[specktator]

The README's always a good place to start.

I read it. That's why I proposed the feature.

@SamWhited thanks for the answers

[iliarostovtsev]

Even though it's outside of the current's scope and it's hard to do - but just think what would that be like!?? People could call each other using their own services, instead of using corporate (spyware) stuff! It will be the only app that would do it - plain and simple! This is the only factor that keeps my family members to use Skype and Viber - voice support. Don't give up on this idea please!!

[specktator]

As an addon to @qooob 's opinion, Developing an app is not only coding, it's about providing a useful tool rest of the people could rely on and be safe with it.

[iliarostovtsev]

Adding voice - would be a giant leap for Conversations!

[tonghuix]

I suggest how about we adding voice as a plugin? I remember there is a voice chat plugin for ChatSecure. If someone want to use voice chat, they could install this plugin

[specktator]

In my opinion it should be a part of the core. Remember users are too lazy.

[iliarostovtsev]

Would be OK! But hey, who wouldn't want to use voice? Or you think it might break some current functionality?

[tonghuix]

I my opinion, adding voice is a additional function, cause I only use text chat for most time.

[iliarostovtsev]

Maybe we don't but normal people (not devs) yes, they are.. What do you think if we offer free registration on some recommended servers, right on readme page? So it would be clear of how to register an account? You need to be a geek to register JID.. Don't believe me? Well ask your friends to do it and you'll see.

[specktator]

All in! For that purpose I forked a very very old project for jabber web registrations and now supports DNS SRV records, added captcha and I've put some bootstrap css on it JRT. I'm also planning to make JRT to retrieve jabber servers list from xmpp.net. Maybe we can use it.

I'm already offering open registration for my server on my site using JRT

[iliarostovtsev]

+1

[tonghuix]

Hi all, please back to Conversations app....

I insist adding voice is very good and required for some people. but it is better keep it in plugin and let user to choice whether install it.

I respect Conversations following the Unix philosophy of "do one thing and do it well"

[strb]

Closing here, because this is not a productive discussion. We have voice messages in Conversations and those work pretty well with the new quick actions, but synchronous voice communications is not in the scope right now. But of course, as always, feel free to fork the project.

[Natureshadow]

I think providing audio and video calls is pretty much within the scope of Conversations. As I udnerstand it, its goal is to finally get Jabber aligned with what people like in proprietary messengers like WhatsApp, and most of those do have synchronous audio/video conversation.

[iliarostovtsev]

+1 Totally agree! This is what people need! Change your scope then, please!

[moshpirit]

:+1: maybe it should be implemented in a medium/long term.

[iliarostovtsev]

Like a 6 months, a year would be alright.

[moshpirit]

Tbh, I don't think so if we don't pay for it, that's a lot of work and Conversations needs a few more things, maybe 1,5 - 2 years imo, but I'd be really glad to use it before, even if we pay for it.

[iliarostovtsev]

I would pay, personally! Especially, when it works well.

[iNPUTmice]

I personally started to become interested in this from a technological stand point.
I'm still not sure that Conversations is the right place to implement this. But maybe with the beginning of 2016 I might be able to get some funding to start exploring this.

[iliarostovtsev]

Sounds fantastic - you'll be the only one who does it on XMPP in open source. People will appreciate this. In case there is desktop app for Linux and other OS - you will highly succeed!

[knoy]

For those interested... CSipSimple already provides what you guys are asking for: ZRTP-encrypted synchronous voice and video calls using ICE/TURN/STUN but does this over SIP instead of XMPP

[moshpirit]

Great news!! Thank you so much, @iNPUTmice!!

[specktator]

@iNPUTmice :dancers:

[iliarostovtsev]

@iNPUTmice Daniel, however, I don't think it's a good idea to separate apps and have two different apps for that. Most people prefer to chat/call all at the same time.

[moshpirit]

I'm sorry if I write too much here but I'd like to express that I agree with @qooob

[knoy]

Adding video and audio calling is not a simple project . Besides the basics involved you also need a way to support multiple codecs, a vast array of audio settings, configuration of NAT-bypassing tech, etc. I am not being pessimistic but don't underestimate the massive amount of work that will be required to get this done. This is on top of making sure that ZRTP is implemented properly and securely.

[moshpirit]

I'm not a developer, just a simple user but I've been following Conversations since its birth and I think that it's (if not the most) one of the most professional clients that I've ever seen. If it needs donations, we will give them, that's a huge work, but nothing that can't be implemented with hard work.

[iliarostovtsev]

:+1:

[iNPUTmice]

@knoy if this was directed towards me I'm fully aware of that and I totally agree.

Like I said I just got interested in the technology as a lot of the webrtc/do-voip-session-in-your-browser people (talky for example) use XMPP as signalling technology.

[andrey-utkin]

Ready to both pay and work on code. Please involve me.
This issue is complex and I'd suggest at last separate Github project just for Issues alone.
The code can be hosted in separate fork or a separate branch for a while. If we go with a fork, let it be at siacs organization.

[thundergreen]

@andrey-utkin does this mean that you wanna work on a video audio plugin ? Where can I send my money? ;);););) would be awesome !!!!

[andrey-utkin]

Where can I send my money?

This is problematic for ukranians :) No Paypal :)

Let's wait for a reply from maintainers first, then we'll see how to setup this workgroup.

[thundergreen]

Would be awesome ;)

Thorsten Fröhlich
Am 15.12.2015 15:18 schrieb "Andrey Utkin" [email protected]:

Where can I send my money?

This is problematic for ukranians :) No Paypal :)

Let's wait for a reply from maintainers first, then we'll see how to setup
this workgroup.

—
Reply to this email directly or view it on GitHub
https://github.com/siacs/Conversations/issues/1234#issuecomment-164777597
.

[Natureshadow]

Willing to sponsor and help testing in all kinds of environments as well!

[iNPUTmice]

Feel free to create a Bountysource pledge for this.

[SafwatHalaby]

https://www.bountysource.com/issues/18153806-support-audio-video-calls-encryption
I've added a 15$ bounty.
@Natureshadow, @thundergreen , @andrey-utkin , @qooob join in ;)

[SafwatHalaby]

@iNPUTmice You might want to set a Funding goal to encourage people to fund this.
(Get Started > Bounty too low > Your Goal)

[iliarostovtsev]

I've also added a 15$ bounty. Great idea! Fighting for freedom!

Thanks!

[Matthias84]

I guess it's a really hard one and would accept if this adds to much dependencies etc. Anyway, would agree, that this would be a superb feature, if you could use videoconference without google hangouts, skype, ...

[SafwatHalaby]

We're up to 80$ 95$ in less than 24 hours. This is fantastic. Come on people! we can easily reach a nontrivial amount. A thousand, perhaps.

[jkufner]

It would be nice if voice and video calls from Conversations work with Gajim, since it is one of few desktop clients supporting MAM and Stream Management.

[andrey-utkin]

Yep, compatibility is a must. And Gajim is one of usable clients, but not for calls. I have tested Gajim like a week ago, it's calls are broken (I guess gstreamer stuff could break the compatibility). Haven't got any reaction from Gajim devs - the bugtracker refused to register my bugreport saying I'm spambot, and on Gajim chat and -dev maillist I got no reply from devs.
https://lists.gajim.org/pipermail/gajim-devel/2015-December/000987.html
The only working calls implementation I could reach is on Jappix.com (browser-based). However I didn't manage yet to get it working on my setup.

[specktator]

I will help for this enhancement in any way I can (code, promoting and funding), since I opened it my self :P
@andrey-utkin Their bug tracker is closed due to spamming. I know the guys who run it. I'll say some words about your issue. Btw, Gajim's audio calls work for me.

FYI, the only modern client that meet the above requirements right now is Jitsi and it's close to what we're going to do. It's heavy, for desktops only, written in java (!) but cross platform. Mobile app is at alpha stage for ages but it works despite the bugs (we can read/use portions of their code maybe?). Jitsi has a very good implementation of video audio calls and video conferencing with OTR encryption. Empathy, Gajim and Jitsi compatibility (IMHO) is a must. We need things to run seamlessly. If we are going to go the hard way it should be done properly.

PS: It's 2015 and most xmpp clients still are not mature to replace skype and other proprietary IM software. Shame on us, devs, including myself.

[chathudan]

Hi this is really awesome project for voice, I implemented this, its working fine. https://github.com/lukeweber/webrtc-jingle-client

[andrey-utkin]

@chathudan could you please elaborate? Like, give a demo webapp URL? I'm personally very curious about webrtc implementations.

[chathudan]

@andrey-utkin could you please drop me an email ? mean time you may check https://github.com/EricssonResearch/openwebrtc-examples

[andrey-utkin]

I will update you all after the weekend, when I look deeper into the issue.
Now I am considering using webrtc API for Android, available in maven package by pristine.io.
The development will take place in https://github.com/Conversations-videocalls/Conversations .

[Natureshadow]

How does this BountySource thing work? I want to make a pledge, but not pay before anything has started.

[andrey-utkin]

@Natureshadow then just wait :)

[moshpirit]

Maybe the best way to contribute right now is by researching how to implement it in order to get a base to start from. After that, consulting Daniel his opinion and after having a starting point, then donating. I've been posting it on Diaspora, GNU social and Pump.io in order to let more people know about the intention. But yes, I feel it a bit risky donating for something that is not clear. So the best way to contribute right now is by giving information and code. But after seen the huge potential of this project, I don't discard the possibility of a new XEP for this.

About permissions and the weight of the app, it's not a problem for me.

[andrey-utkin]

@moshpirit why new XEP?

[strb]

You should probably move this discussion somewhere else.

We really appreciate someone taking the initiative and having a go at this, but realize that this is an enormous undertaking. We're talking hundreds of man-hours here. You certainly won't be able to coordinate the work in any meaningful way through this single GitHub issue. As such it's in everyone's interest that the group that wants to work on this feature create a fork of the project and do development and project management over there. You'll need your own issue tracker anyway, as issues that arise during your work don't really belong in here. Feel free to post a link here to wherever development will take place, that way interested parties can find you and collaborate with you. But please refrain from further discussion about this external project in this venue.

If this effort produces good results with decent code quality, we'll see about merging it at that point. But until that time, any work that is going to be done on this front doesn't really fall in the scope of Conversations.

We wish you the best of luck though. If you need help getting acquainted w/ the Conversations code base, feel free to ask in our MUC.

[improti]

I am trying to advertise a co-operation between Conversations and the Jitsi projekt (see https://github.com/siacs/Conversations/issues/1646). While my references so far point to what Jitsi could get from Conversations, this is a thing Conversations could get from Jitsi. Jitsi supports voice and video calls using ZRTP over XMPP (so actually without using the VoIP that Jitsi also has, at least without a SIP account). This sounds like an implementation might be easier than thought? I'm not enough "into" any of the projects to really judge this, but I cannot get rid of the feeling that some communication between you devs might open up much potential. While I enjoy OMEMO with conversations, I am missing a desktop-part. Jitsi could be it. And if I could take calls made with Jitsi in Conversations in addition (using that ZRTP over XMPP), it would just be greater.

Hope this input might be useful. I will make an offer in € to you devs just to get together and discuss this in the other thread now. Maybe that helps ...

[ghost]

It will be an awesome feature for conversations to support audio/video calls via Jingle-ICE and with ZRTP encryption.

It might happen this summer: http://wiki.xmpp.org/web/Summer_of_Code_2016#Implement_encrypted_calling_in_Conversations :-)

[SafwatHalaby]

Whoever has access to that WIKI page, you should tell people that a 400$ bounty awaits at Bountysource.

[thundergreen]

well.. i would more than highly appreciate this audio call feature. this
is just an agenta i guess... so nothing is sure that itwill be
implemented right?

would this be implemented, i know much more user should join xmpp :)

Am 23.04.2016 um 12:46 schrieb LogicParrot:

Whoever has access to that WIKI page, you should tell people that a
400$ bounty awaits at Bountysource
https://www.bountysource.com/issues/18153806-support-audio-video-calls-encryption.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/siacs/Conversations/issues/1234#issuecomment-213718329

[knoy]

What is the progress of this ? Last commit looks like Jan 25th on https://github.com/Conversations-videocalls/Conversations/commits/master . There are no GSoC students picking this up to my knowledge.

[thundergreen]

Would also like to know :)

[papermate]

I'm _very_ interested too (same address for email, chat and calling, just one app and few plugins? That is madly awesome).
If someone has news about the state of works please let know

[github-k8n]

Maybe it is possible to somehow use the wire libraries?
https://github.com/wireapp/wire

Some news page in german:
http://www.heise.de/newsticker/meldung/Wire-Messenger-ist-jetzt-vollstaendig-Open-Source-3277490.html

[GavelRust]

Dream Host (not surprisingly a web hosting company) allows the uri

[email protected]

to function both as email and xmpp texting. I am stunned this is not yet standard. Through DNS magic it can be extended via SIP sorcery

I expect vps hosting uri to be trifunctional

• email
• xmpp texting
• sip

(I abadoned arvixe for gross incompetence after many years in favor of dream host)

[ronnicek]

+$15 on bountysource ;-)

[contrapunctus-1]

As someone trying to get friends and family to switch to libre, privacy-respecting alternatives to WhatsApp, the importance of this cannot be understated. The definition of a "modern IM platform" has come to include this - people expect it of an IM client. And dealing with only one address and one client to manage chat, file sharing, and audio and video calling is undeniably convenient.

[rfc2822]

+1

[strugee]

@rfc2822 please refrain from +1-style comments. They don't help get this issue solved. If you don't have anything actionable to contribute, all you're doing is generating email for the 247 people watching this repository plus those of us who are subscribed specifically to this issue. It's just noise and it's a waste of everybody's time.

[moshpirit]

Riot has audio/video calls (which work very nice) and it's free software, maybe you could use its code.

[licaon-kter]

Yep, pretty pleasantly surprised by Riot, setup devices, call, done, you've got video.
While with Jitsi at most I got the devices to show their own images, although they said the connection was ok.

[alugarius]

isn't it possible to use jingle?

[samweisgamdschie]

I left a bounty too but i am only interested in encrypted audio calls. For me it's done with it.

[PeterEdens]

I have implemented encrypted video/audio calls in a library SpreedboxWebrtc that is used in a fork of the Conversations app. Signaling uses the Spreed webrtc server SpreedWebrtc but it could also be modified to use XMPP for signaling.

[Aluisyo]

link please......

On Mon, Jul 3, 2017 at 4:11 AM, PeterEdens [e-mail] wrote:

I have implemented encrypted video/audio calls in a library
SpreedboxWebrtc https://github.com/PeterEdens/SpreedboxAndroidWebrtc
that is used in a fork of the Conversations app. Signaling uses the Spreed
webrtc server SpreedWebrtc https://github.com/strukturag/spreed-webrtc
but it could also be modified to use XMPP for signaling.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/siacs/Conversations/issues/1234#issuecomment-312534045,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALAdNCLeDJpc6OIWbhPvMFmja5JVRmi-ks5sKE21gaJpZM4EsJhp
.

[PeterEdens]

The forked source
The app

[Aluisyo]

@PeterEdens thanks.

[knoy]

@PeterEdens this is an interesting app but reading through the source code it seems you aren't doing any P2P-encryption at all on the audio or video calls.

More concerningly you seem to be making many false statements about the security and encryption of these calls:
"All your communication is end-to-end encrypted so people cannot snoop on your conversations or files."
"Use your Android smartphone or tablet to have secure and private meetings with one or more of your contacts"
"Secure Video Conference"

I don't want to sidetrack the conversation here but this is really no more secure than google hangouts or skype in any meaningful way, besides the (very questionable) idea that it's self-hosted. I think what people in this thread are interested in is a ZRTP or P2P-encrypted calling similar to Signal's functionality.

[PeterEdens]

The app uses DTLS to secure the webrtc connections so that they are end-to-end encrypted.

[Natureshadow]

On 11 July 2017 01:23:25 GMT+02:00, PeterEdens [e-mail] wrote:

The app uses DTLS to secure the webrtc connections so that they are
end-to-end encrypted.

No, they are not. It may be some kind of when communicating directly, but then authentication is questionable. Encryption without authenticated keys is worthless. And if a media proxy is used, which will almost always be the case, then only the streams between clients and the proxy are encrypted, but not end-to-end.

[knoy]

@PeterEdens , I think you are conflating two terms or just misunderstand what end-to-end encryption is, which seems extremely dangerous for your users as you are the lead developer. Even if this was using P2P encryption (as stated you are using DTLS which is transport encryption, not content encryption) your client would need a robust ways of authenticating keys such as OMEMO's SMP, QR-code, etc. Without this, interception is trivial and the encryption is useless.

Seeing as your fork of Conversations requires some sort of custom commercial server to even login or view the rest of your app, testing your client is exceedingly difficult. Your commit log also seem to be grouping many changes together into monolithic commits. If you could provide some more detailed implementation details or abstract away your voice implementation into something more portable this would be a lot more helpful as the foundation for something from which a REAL secure implementation could be made.

[PeterEdens]

Please see 4.3.2. SRTP: Secure Real-time Transport Protocol in DTLS it specifically describes the end-to-end encryption for key exchange and verification prior to the establishment of a secure link. When using a TURN server for NAT traversal the packets are not decrypted for relay but are just passed to the recipient which decrypts the content so only the communicating users can read the content.

Using a video call it is much easier to verify the identity of the person you are connected to.

The video/voice call implementation is based upon apprtcdemo so you could test this app in order to evaluate the security of the connection. This app uses google's servers for signaling.

[github-k8n]

Maybe the verification part could be done by Conversations similar to the current situation with HTTP upload. Just transfer the key (or a hash of the key or something similar) via a normal encrypted xmpp message.
That way the identity of the communication partner can be verified using the already verified communication channel.

[PeterEdens]

For verification XMPP should be used for the signaling, so the offer, answer and ice candidates will be encrypted using OMEMO and this allows verifying that the information received is from the verified OMEMO user. Conversations already has code to handle the jingle connections for an audio/video call, it is just a matter of adding handlers for this type of jingle connection. If you add the following to FEATURES in AbstractGenerator.java:

"urn:xmpp:jingle:apps:rtp:1",
"urn:xmpp:jingle:apps:rtp:audio",
"urn:xmpp:jingle:apps:rtp:video",
"urn:xmpp:jingle:transports:ice-udp:1",
"urn:xmpp:jingle:apps:dtls:0"

Then you need a handler to convert the Jingle offer, answer to an SDP to pass it to the apprtc code to establish the peer to peer connection.

[WarrenBKN]

have y'all seen

https://ostel.co

[chathudan]

@PeterEdens
hope sdp-to-jingle-java will help for SDP to Jingle conversion

[cloudyfuel]

@iNPUTmice What do you think about using standard WebRTC SRTP with coturn server as TURN and OMEMO encrypted XMPP events as signaling (no need for ZRTP thanks to that - authentication is provided by OMEMO)? This sounds much simpler as tinkering with ZRTP or Jingle for that and shouldn't need any/much side work like optimization. A XEP could be created for this similarly as happened with OMEMO. UI work needed is pretty much inexistent.

Switching anyone to two apps (text + voice) from one is impossible for me

[whitetornado]

is JITSI a solution?

[genofire]

@iNPUTmice a reason, why u close this issue?
(i still would love to has a kind if jingle or webrtc on android+xmpp)

[iNPUTmice]

a reason, why u close this issue?

Yes. There is not going to be support for jingle. Keeping this issue open is misleading people

[github-k8n]

@iNPUTmice , is this a definite no to any audio/video stuff? Or just jingle?
I'd love to see webrtc+xmpp signalling and I think this would appeal to a lot of other folks as well.
I understand that this might not be that simple (new xep? etc), but maybe we could keep this open to track any progress if there are any (even long-term) plans to eventually support something like this?

[genofire]

@github-k8n +a high where i have spend money, too. :flushed:

@iNPUTmice sry i want not to harm u

[iNPUTmice]

@genofire the bounty source was part of the reason I closed this. So you can get your money back

From the bountysource FAQ

If the issue was closed as a "won't fix", or is deemed not in line with the project's goals, the bounty is refunded.

I'm not sure how that process works though.

@github-k8n There is no process to track. Unless someone comes along who wants to develop this I'm not sure how a very long thread of people begging for jingle support is any help.

[ronnicek]

@iNPUTmice so you think $565 bounty (so far) is not any help to implement audio/video.. oookey.. [then I should support Matrix?]

[SamWhited]

so you think $565 bounty (so far) is not any help to implement audio/video.. oookey.. [then I should support Matrix?]

Given the ammount of work this would take, that probably amounts to less than the U.S. minimum wage (on an hourly basis) most people probably would not be willing to spend weeks of their time for so little.

[licaon-kter]

should support Matrix

Matrix gets $3000 per month, EVERY month, geez, I wonder why they have constant developers/features/plans!?

Compare that with an one time pay of $565, really?

bounty (so far)

SO FAR after 2.5 years? I guess everybody that wanted this already put up the money or went elsewhere a long long time ago.

[ronnicek]

Ah.. that's the reason why XMPP is slowly dying, because there is no support of audio/video on major platforms (I am waiting for it for.. 10 years already?).. but I understand.. it's "so little". Sad..

And I am not talking, that bounty was growing slowly.. I know, really slowly, but "slowly" is better then "never".

@licaon-kter and is there problem to create that for XMPP / Conversation?

[Natureshadow]

Yes. There is not going to be support for jingle. Keeping this issue
open is misleading people

And that's why Conversations is just another XMPP client that will not do anything for wide acceptance of free standards :(.

[iNPUTmice]

A bounty can act as an additional motivation for someone who wants to
implement a certain feature anyway. It is in no way, shape or form a
payment thus it can not act as a sole motivation to implement it.
To hire someone to implement this we would be talking 10s of thousands of
dollars. Probably 100s.

[Natureshadow]

A bounty can act as an additional motivation for someone who wants to
implement a certain feature anyway. It is in no way, shape or form a
payment thus it can not act as a sole motivation to implement it.
To hire someone to implement this we would be talking 10s of thousands
of
dollars. Probably 100s.

There is a difference between not implementing this and not accepting a contribution.

As I read what you say, you wouldn't even accept the feature if someone implemented it completely.

[iNPUTmice]

@Natureshadow no one has ever step forward wanting to implement it. Arguing about whether I would merge a hypothetical pull request is completely pointless.

[Natureshadow]

@Natureshadow no one has ever step forward wanting to implement it.
Arguing about whether I would merge a hypothetical pull request is
completely pointless.

I don't think so.

As you already said yourself, the implementation will be very expensive.

Maybe whoever could do it should know whether their work will end up in a future-proof XMPP client or in the trash can.

[iNPUTmice]

@Natureshadow you are vastly underestimating the scope of this project. Someone who is dedicated enough to spend months working in full time on this project and is committed enough to maintain it in the future doesn't need me to merge their PR. They could simply fork Conversations if and only if (I never said I wouldn't merge) I don't accept the PR.

[Natureshadow]

@Natureshadow you are vastly underestimating the scope of this
project. Someone who is dedicated enough to spend months working in
full time on this project and is committed enough to maintain it in
the future doesn't need me to merge their PR. They could simply fork
Conversations if and only if (I never said I wouldn't merge) I don't
accept the PR.

Probably. Then again, many people argue that the XMPP world cannot cope with even more fragmentation.

But if you could state that if you refused to merge an implementation, it had to be for technical reasons, that would be a huge gain.

[licaon-kter]

@ronnicek: Why would you say that when Signal/Messenger/Whatsapp/Telegram, all of them, got video features in the last year only? Why is it that bilions of users still used them all these years without?

Also, if Facebook needs years to implement it with their money...$565 wow

[jkufner]

Can't we use some existing component and just invoke it from Conversations via an intent?

[ghost]

@ronnicek You're missing the part where Daniel single-handedly revived XMPP with Conversations and is constantly pushing it further.

[Natureshadow]

@ronnicek: Why would you say that when
Signal/Messenger/Whatsapp/Telegram, all of them, got video features
in the last year only? Why is it that bilions of users still used
them all these years without?

Simple: Because they used them in preference over SMS. And unlimited
text without paying per message was a huge benefit.

Now that everyone does that, having audio/video on top of that is a new
benefit over everything that doesn't.

[Natureshadow]

@ronnicek You're missing the part where Daniel single-handedly revived XMPP with Conversations and is constantly pushing it further.

Noone doubts that. Now, what counts is keeping up with others, in order
to prevent XMPP from dying a second (and final) time.

[ronnicek]

@licaon-kter because how I should convience all my friends to use XMPP when I cannot call thru it? And it was hard to convience them even year ago, since platform had some nice clients, just XMPP didnt

@d9h20f Man, I am so glad what Daniel did! I was hoping that Daniel can move with that old guys behind XMPP to move forward from 90' finally.. but it's not looks like that :-/

I start using XMPP in 2005 (it was really nice alternative to openminded people instead of MSN, ICQ, etc.). Around that time Jingle was bring to life and everyone around XMPP was happy that we will have audio in clients! But until now.. nothing happens.. and during that time lot of other communication software appers (like Whatsapp, Telegram, Matrix, RocketChat/Slack/, Signal, Wire) and almost all these software jump over XMPP dramatically (mainly, clients support on all platforms with all same features). Then Daniel appears and I was really happy, that someone is going to try recovery XMPP from clinical death. There was a big step forward (thanks to OMEMO and implementing lot of useful XEP's). But to keep track with all others, XMPP needs also voice/video and polish clients on all major platforms, if not, I have to look for other software for chatting then XMPP protocol. And trust me, I was trying hard to convience my friends to using that with me..

HOWGH :)

BTW: It's sad, because if XMPP would have good looking client and properly working audio/video (NAT) it could beat Skype (in 2005).

[licaon-kter]

@Natureshadow $565 and constantly moving the goal post don't mix

@ronnicek $565 versus the goverment funded OpenTechnologyFund money for Signal? Versus Facebook money in Whatsapp? Versus $3000 every month Matrix? Versus russian millionaire Telegram? Versus Google money in Duo/Allo?

Wow just wow, and what is this blackmailing bussiness of "implement this or else"? What other clients have these? If so, why didn't you switch already? Why aren't you using Signal or Wire or Matrix already? Does the whitepaper need to have the XSF / XMPP logo ?

[ronnicek]

@licaon-kter Matrix didnt have all $3000 from start ;-) btw.. just jealous?

And I am not blackmailing at all, I am just saying things how they are. Why I didn't switch? Because I used to like XMPP and I was fan of XMPP.. but when I see toxic community around XMPP (mainly when you say that they stuck in 90') then I am going to change my mind.

And now really HOWGH from my side.

[whitetornado]

I am bust with a party what is busy to implementing voice in conversations.
The beta is ready in about 2 weeks. I will keep you informed

Op 29 sep. 2017 19:24 schreef "Jindřiška" [e-mail]:

@licaon-kter https://github.com/licaon-kter because how I should
convience all my friends to use XMPP when I cannot call thru it? And it was
hard to convience them even year ago, since platform had some nice clients,
just XMPP didnt

@d9h20f https://github.com/d9h20f Man, I am so glad what Daniel did! I
was hoping that Daniel can move with that old guys behind XMPP to move
forward from 90' finally.. but it's not looks like that :-/

I start using XMPP in 2005 (it was really nice alternative to openminded
people instead of MSN, ICQ, etc.). Around that time Jingle was bring to
life and everyone around XMPP was happy that we will have audio in clients!
But until now.. nothing happens.. and during that time lot of other
communication software appers (like Whatsapp, Telegram, Matrix,
RocketChat/Slack/, Signal, Wire) and almost all these software jump over
XMPP dramatically (mainly, clients support on all platforms with all same
features). Then Daniel appears and I was really happy, that someone is
going to try recovery XMPP from clinical death. There was a big step
forward (thanks to OMEMO and implementing lot of useful XEP's). But to keep
track with all others, XMPP needs also voice/video and polish clients on
all major platforms, if not, I have to look for other software for chatting
then XMPP protocol. And trust me, I was trying hard to convience my friends
to using that with me..

HOWGH :)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/siacs/Conversations/issues/1234#issuecomment-333186824,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AI4In30-XY9LxLCxZ4jgXoXUTNFqylO5ks5snSeygaJpZM4EsJhp
.

[Natureshadow]

I am bust with a party what is busy to implementing voice in conversations.
The beta is ready in about 2 weeks. I will keep you informed

Where can it be found/followed?

[whitetornado]

I will update here.

Op 29 sep. 2017 20:15 schreef "Dominik George" [e-mail]:

I am bust with a party what is busy to implementing voice in
conversations.
The beta is ready in about 2 weeks. I will keep you informed

Where can it be found/followed?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/siacs/Conversations/issues/1234#issuecomment-333199721,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AI4InxhoqYsAGgOnJuM_YvNmzHJcvf5oks5snTOygaJpZM4EsJhp
.

[mimi89999]

People complaining don't even have an idea about the huge amount of work that needs to be put in to implement proper Jingle A/V calls.

[github-k8n]

I think one of the main issues here is that the target (audio/video) stayed the same while the ideas on how to achieve that changed.
I can imagine that having full jingle support can be really difficult?
Recent ideas have been floating around to basicaly just use webrtc and do signalling via xmpp.
That might still prove very difficult, but if it is possible to just reuse existing apps/libs then it might be easier to achieve.
How about just generating some link that opens in a browser/webview with webrtc support and might even work with clients that don't support it because it would just open in a browser.. (depending on some server side magic/component of course, turn server etc, i'm not that deep into that.. )

Summary: users don't care how it works, just that it works. I understand that we wouldn't want to throw out some half assed implementation (wouldn't fit to the rest of the refined and excellent conversations app), however it might be time to decide where to focus further effort. (Is there ANYONE currently using jingle?)

[Natureshadow]

People complaining don't even have an idea about the huge amount of
work that needs to be put in to implement proper Jingle A/V calls.

This is as much a lie as saying that @inputmice doesn't care about
bringing XMPP forward.

AFAIAC, the question is: Independent of how much work anything is, would
it be worth the effort without having to cause more fragmentation of
clients in the end?

[SamWhited]

I can imagine that having full jingle support can be really difficult?

Conversations has Jingle support, it just uses it for file transfer, not A/V. I'm not sure what you mean by "full" support though.

Recent ideas have been floating around to basicaly just use webrtc and do signalling via xmpp.

Jingle is how you do signaling via XMPP. WebRTC is a transport that lets you send data back and forth; it's not really any more difficult or easy than creating a stream any other way. You could use Jingle to negotiate WebRTC connections, this is how Jitsi Meet works, for instance (but it doesn't make developing this feature any easier).

How about just generating some link that opens in a browser/webview with webrtc support and might even work with clients that don't support it because it would just open in a browser

This is not how WebRTC works and is still drastically underestimating the problem. You can't just "[generate] some link that opens in a browser". Instead of implementing a video solution in Android, you're just advocating that you implement it for the browser. This doesn't make anything easier.

(Is there ANYONE currently using jingle?)

Yes, it's a fairly common signaling protocol.

[github-k8n]

As I said, i don't really have the background on this, thanks for the explanation.

Instead of implementing a video solution in Android, you're just advocating that you implement it for the browser. This doesn't make anything easier.

Well, IF the browser does already support it (thinking of e.g. nextcloud video conf which works on android in the browser)
it might be a "ghetto" way to support audio/video calls, i mentioned that it would require some server side stuff....

But yeah, if jingle is not more difficult to implement then i'm all for it... (looking forward to call asterisk via conversations 😁)

[mdosch]

This is what I said in conversations MUC today regarding this issue:

‎[19:13:56] ‎* Martin is also sad about no voice call
‎[19:14:41] ‎Martin‎: video call is not important to me but I won't beg there as I am not able to contribute... (but still watching this particular issue)

I would recommend to all of you to calm down and don't start a flame war
here as it wouldn't make us move forward.

I am willing to donate to anyone bringing voice call to
conversations/XMPP but I can not afford paying someone to do the job. So
if someone really wants to have this and has the skills to implement it
(I am not able to do this as I am not a programmer) I will donate (via
bank transfer, as this bountysomething site uses PayPal and a lot of
external scripts). But as long as no one is interested to do this it
won't bring us any further to molest a single developer. (I think it
might even be contrary to our interest of getting voice call as he gets
frustrated about all this flaming here).

[Natureshadow]

But as long as no one is interested to do this it
won't bring us any further to molest a single developer. (I think it
might even be contrary to our interest of getting voice call as he gets
frustrated about all this flaming here).

Again: All I (and I think others) want is a statement clarifying that
someone is welcome to maintain audio/video in Conversations without
having to maintain a fork that fragments XMPP clients even more.

[Xohoo]

I think it woud be great if conversations manage to get audio/video chat via Jitsi Videobridge [https://jitsi.org/jitsi-videobridge/] the jitsi team also managed to get p2p in 1:1 chats [https://jitsi.org/news/p2p4121/] --> more in the scope of this discussion

[PeterEdens]

JSXC implements video and voice using signaling over XMPP and webrtc for the actual video and audio, Jitsi does the same. I had a go at implementing the signaling over XMPP but when I convert the description back to SDP the webrtc parser complains about the lines not matching so I have not progressed further.

[Cervator]

Hey all - for reference I just refunded all the bounties on this issue from the Bountysource side of things. Somewhat rare (and cool!) to see a bounty total get so high with primarily small amounts, from 23 backers the second highest was $35 :-)

Good luck with the project! Even if this particular request isn't being implemented here. Hooray open source!

[diegobill]

@PeterEdens , Do you have this https://github.com/jsxc/jsxc/issues/630 problem?

[PeterEdens]

No, I get a different issue where the SDP is reported as invalid because of lines not matching. I do my own conversion of the jingle XML to SDP so it may be the case that the jitsi conversion is failing on one of the lines and failing to set the RTP Description. I would put some breakpoints in the parsing to see where it is failing.

[diegobill]

@PeterEdens , Did you put breakpoints at jitsi code or jsxc code? I do not know How to Put breakpoints at protocol-jabber.jar (where the code errors happens during a call from jsxc to jitsi), because this .jar is Put into a dex file.

To know: @tiocadu

[PeterEdens]

I didn't use jitsi, I used the AppRTCDemo code and made my own https://github.com/spreedbox/SpreedboxAndroidWebrtc. I modified the jingle code in Conversations to add a class to convert the jingle offer and answer to SDP https://github.com/spreedbox/Spreedbox-Android. In Jitsi you can put breakpoints in the JingleToSDP.java file or SDPToJingle.java where the packet containing the offer/answer is initially received then step through to find where it fails. Looking in logcat might also show why it fails.

[thundergreen]

@PeterEdens did u integrate audio video call already?

2017-11-02 23:47 GMT+01:00 PeterEdens [e-mail]:

I didn't use jitsi, I used the AppRTCDemo code and made my own
https://github.com/spreedbox/SpreedboxAndroidWebrtc. I modified the
jingle code in Conversations to add a class to convert the jingle offer and
answer to SDP https://github.com/spreedbox/Spreedbox-Android. In Jitsi
you can put breakpoints in the JingleToSDP.java file or SDPToJingle.java
where the packet containing the offer/answer is initially received then
step through to find where it fails. Looking in logcat might also show why
it fails.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/siacs/Conversations/issues/1234#issuecomment-341580454,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMtAf3EoFVZ61ngaqKSZNWlaB6OhWCe-ks5sykZ6gaJpZM4EsJhp
.

[whitetornado]

we tried Jitsi but has to much bugs we are busy with astrix and sip see if
that works

2017-11-03 19:06 GMT+01:00 ThUnD3r|Gr33n [e-mail]:

@PeterEdens did u integrate audio video call already?

2017-11-02 23:47 GMT+01:00 PeterEdens [e-mail]:

I didn't use jitsi, I used the AppRTCDemo code and made my own
https://github.com/spreedbox/SpreedboxAndroidWebrtc. I modified the
jingle code in Conversations to add a class to convert the jingle offer
and
answer to SDP https://github.com/spreedbox/Spreedbox-Android. In Jitsi
you can put breakpoints in the JingleToSDP.java file or SDPToJingle.java
where the packet containing the offer/answer is initially received then
step through to find where it fails. Looking in logcat might also show
why
it fails.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
issuecomment-341580454>,
or mute the thread
AMtAf3EoFVZ61ngaqKSZNWlaB6OhWCe-ks5sykZ6gaJpZM4EsJhp>

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/siacs/Conversations/issues/1234#issuecomment-341783171,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AI4In01ugO8okqs_MBc3y6tAFyY0Vpfvks5sy1YQgaJpZM4EsJhp
.

[thundergreen]

u would be the first and only making an approach to integrate audio video
:)

2017-11-03 20:14 GMT+01:00 Henk Nienhuis [e-mail]:

we tried Jitsi but has to much bugs we are busy with astrix and sip see if
that works

2017-11-03 19:06 GMT+01:00 ThUnD3r|Gr33n [e-mail]:

@PeterEdens did u integrate audio video call already?

2017-11-02 23:47 GMT+01:00 PeterEdens [e-mail]:

I didn't use jitsi, I used the AppRTCDemo code and made my own
https://github.com/spreedbox/SpreedboxAndroidWebrtc. I modified the
jingle code in Conversations to add a class to convert the jingle offer
and
answer to SDP https://github.com/spreedbox/Spreedbox-Android. In Jitsi
you can put breakpoints in the JingleToSDP.java file or
SDPToJingle.java
where the packet containing the offer/answer is initially received then
step through to find where it fails. Looking in logcat might also show
why
it fails.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
issuecomment-341580454>,
or mute the thread
AMtAf3EoFVZ61ngaqKSZNWlaB6OhWCe-ks5sykZ6gaJpZM4EsJhp>

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
issuecomment-341783171>,
or mute the thread
MBc3y6tAFyY0Vpfvks5sy1YQgaJpZM4EsJhp>

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/siacs/Conversations/issues/1234#issuecomment-341800369,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMtAf3RuAjatfYxejt7e8Mbdc0boDnWxks5sy2X9gaJpZM4EsJhp
.

[whitetornado]

:-) we got video worked, but by default there where missing some things
like a popup that someone calls and xmpp over tor gives to much latency so
we decide to go only for voice. The first test are good :-)

2017-11-03 21:07 GMT+01:00 ThUnD3r|Gr33n [e-mail]:

u would be the first and only making an approach to integrate audio video
:)

2017-11-03 20:14 GMT+01:00 Henk Nienhuis [e-mail]:

we tried Jitsi but has to much bugs we are busy with astrix and sip see
if
that works

2017-11-03 19:06 GMT+01:00 ThUnD3r|Gr33n [e-mail]:

@PeterEdens did u integrate audio video call already?

2017-11-02 23:47 GMT+01:00 PeterEdens [e-mail]:

I didn't use jitsi, I used the AppRTCDemo code and made my own
https://github.com/spreedbox/SpreedboxAndroidWebrtc. I modified the
jingle code in Conversations to add a class to convert the jingle
offer
and
answer to SDP https://github.com/spreedbox/Spreedbox-Android. In
Jitsi
you can put breakpoints in the JingleToSDP.java file or
SDPToJingle.java
where the packet containing the offer/answer is initially received
then
step through to find where it fails. Looking in logcat might also
show
why
it fails.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
issuecomment-341580454>,
or mute the thread
AMtAf3EoFVZ61ngaqKSZNWlaB6OhWCe-ks5sykZ6gaJpZM4EsJhp>

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
issuecomment-341783171>,
or mute the thread
MBc3y6tAFyY0Vpfvks5sy1YQgaJpZM4EsJhp>

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
issuecomment-341800369>,
or mute the thread
AMtAf3RuAjatfYxejt7e8Mbdc0boDnWxks5sy2X9gaJpZM4EsJhp>

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/siacs/Conversations/issues/1234#issuecomment-341812806,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AI4InziscKI68VPdYBsAzbQvDb7oL0erks5sy3KYgaJpZM4EsJhp
.

[PeterEdens]

I have video and audio working but I use the spreed signaling server https://github.com/strukturag/spreed-webrtc/ instead of XMPP

[thundergreen]

@peter did u install the server and the "client" in conversations? could u
pease explain a bit more? :) I would also setup spreed server for this :)

2017-11-07 22:50 GMT+01:00 PeterEdens [e-mail]:

I have video and audio working but I use the spreed signaling server
https://github.com/strukturag/spreed-webrtc/ instead of XMPP

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/siacs/Conversations/issues/1234#issuecomment-342634089,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMtAf2NJc2mNi-aVhmUV-ZwUVbG-Pilkks5s0NCagaJpZM4EsJhp
.

[PeterEdens]

I installed spreed server on a linux box, the client is https://github.com/spreedbox/Spreedbox-Android which has all the signaling implemented to communicate with the spreed server on the linux box. You can pass the server ip address or host name to the ConnectActivity.class via Intent RoomActivity.EXTRA_SERVER_NAME to connect to the server and display the activity so you can include the project as a library in your conversations app.

[thundergreen]

sounds kind of complicated id u r not a programmer / coder like me :) would
u like working with someone who has more knowledge? If you know chris from
Pixart-Messenger?

https://jabber.pix-art.de/

2017-11-08 23:13 GMT+01:00 PeterEdens [e-mail]:

I installed spreed server on a linux box, the client is
https://github.com/spreedbox/Spreedbox-Android which has all the
signaling implemented to communicate with the spreed server on the linux
box. You can pass the server ip address or host name to the
ConnectActivity.class via Intent RoomActivity.EXTRA_SERVER_NAME to connect
to the server and display the activity so you can include the project as a
library in your conversations app.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/siacs/Conversations/issues/1234#issuecomment-342978491,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMtAf2hXKxYVX2qRlzfALAoW3toL9rwuks5s0ieHgaJpZM4EsJhp
.

[diegobill]

@PeterEdens , Is it possible to configure this XMPP/WebRTC Client https://github.com/jsxc/jsxc to connect to your https://github.com/strukturag/spreed-webrtc/ server to make video calls?

[PeterEdens]

spreed-webrtc uses a different signaling method to jsxc so it is not possible to use the spreed-webrtc server to make calls with it.

[thundergreen]

Could someone provide a running demo if conversations with video? Wanna
setup similar stuff

Am 06.12.2017 11:10 nachm. schrieb "PeterEdens" [e-mail]:

spreed-webrtc uses a different signaling method to jsxc so it is not
possible to use the spreed-webrtc server to make calls with it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/siacs/Conversations/issues/1234#issuecomment-349791351,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMtAf866hMljlYKFbZqapP5Wz8XFwGk1ks5s9xC6gaJpZM4EsJhp
.

[andypl]

Hi Guys,
A few years ago Jits devs started a project that will brings video/audio to Android. Now project is dead, but I think, that U could take the code and other libs from it and create video/audio support for Conversation.

Jitsi-Android: https://github.com/jitsi/jitsi-android
Jitsi for Android is an Android port of the Jitsi project: The most feature-rich communicator with support for encrypted audio/video, chat and presence over SIP and XMPP.

libjitsi: https://github.com/jitsi/libjitsi
libjitsi is an advanced Java media library for secure real-time audio/video communication. It allows applications to capture, playback, stream, encode/decode and encrypt audio and video flows. It also allows for advanced features such as audio mixing, handling multiple streams, participation in audio and video conferences. Originally libjitsi was part of the Jitsi client source code but we decided to spin it off so that other projects can also use it. libjitsi is distributed under the terms of the Apache license.

ice4j: https://github.com/jitsi/ice4j
The Interactive Connectivity Establishment (ICE) protocol combines various NAT traversal utilities such as the STUN and TURN protocols in order to offer a powerful mechanism that allows Offer/Answer based protocols such as SIP and XMPP to traverse NATs.

This project provides a Java implementation of the ICE protocol that would be usable by both SIP and XMPP applications. The project also provides features such as socket sharing and support for Pseudo TCP.

[licaon-kter]

@andypl Jitsi Meet is alive and well

[andypl]

@licaon-kter but Jitsi Meet is for a different purpose.. It is a Conferencing client build on top of Jitsi video bridge. U can create a free conferences without using a XMPP account and a client.
Jitsi Android was supposed to be a full featured Jitsi client for Android platform allows U to communicating with your friends using text, voice or video.

Main problem with XMPP is that we do not have full featured clients for top platforms (Android, Linux, Windows and iOS).

I know that implementig voice and wideo in conversation is not a trivial thing and it take time, but if XMPP clients will not catch up services like FB M, Telegram, Signal or WhatsUP they will die. If users will not use XMPP there will by no dev writing code for it. and if there will by no devs...

Modern communications is not only text. U say use a different client for Android, but there is no another full featured and open XMPP client for Android and there are only few for desktop...

[cloudyfuel]

Nextcloud implemented E2E XMPP voice/video calls and chat. They are coming to mobile and desktop and call federation is planned. The problem is it's aimed at enterprise (something like slack), AFAIK the UI won't be simple IM like Conversations, but perhaps in the future someone integrates this in some simple mobile app etc.

http://karlitschek.de/2018/01/nextcloud-talk-is-here/

[jkrenzer]

Just a thougth:

As i remember android uses the chromium-basis for its browser-component. I used the chromium-embeded-framwork (CEF) in another project to establish a webrtc-connection to jitsi-meet. I think that it would be complicated to implementing serverless conferences as long as the WebRTC-Standard does not contain a ripe definition for this which is implemented on the browser side. We could detect jitsi-meet based services in the meantime, though.

And could we not use the browser-component of android to initiate a serverless p2p WebRTC-Session?

Cheers

Jörn

[NinjaTune]

Hi

I realize this request has been made several times before: 2015, 2016, 2017 and was closed.

But it's the current year and maybe the focus now is open to this feature (one of the killer features of whatsapp)

btw I'm willing to pledge money to make that happen.

[Peterede]

The webrtc part of the calls is the easy part, there is android code for this. The complicated part is the signaling where Session Description OFFER and ANSWER and ICE Candidates are sent. These need to be encoded using jingle for compatibility with other XMPP servers that implement video/audio calling. Also the TURN server is another complication where this needs to hosted on the server and the app needs to get the address and port of the TURN server.

[ccaapton]

@Peterede Would you consider using Cordova for the UI part of calling? This utilize the android connectionservice thus could handle the complex interaction with the phone state, native call holding, native ui, ui on lockscreen, etc.

For the signaling part, I think we can start without Jingle compatibility. It is already a huge step forward even voip only happens between conversations users, and when it is good enough, jingle compatibility could be added later.

[Peterede]

Conversations is a native android app so using Cordova in it would not make sense. The UI parts of calling are the easy parts, it is the signaling that is complicated. The Sdp and ice candidates could be sent as a custom xmpp message to avoid using jingle.

[ccaapton]

The Sdp and ice candidates could be sent as a custom xmpp message to avoid using jingle

That is exactly what I intended to imply.

The UI parts of calling are the easy parts.

Could you at least try to use connectionservice directly? It is available since android 7.0

[Peterede]

connectionservice is only for sim based telecommunications, it is not for webrtc or other calls.

[ccaapton]

connectionservice is only for sim based telecommunications, it is not for webrtc or other calls

It is for both sim-based and voip, as google had unified all calls since android N. Please see the link above for the brief introduction.

[Peterede]

The app still needs to implement the ConnectionService API so it is just an overlay for the implementation of the signaling, the call would still need to use webrtc and jingle or a custom xmpp message for the signaling.

[ccaapton]

Conversations is a native android app so using Cordova in it would not make sense.

We could just borrow a single activity from Cordova for the voice/video call, it does not require the other part of Conversations UI rewritten in Cordova.

would still need to use webrtc and jingle or a custom xmpp message for the signaling

That is why I suggested Cordova at the first place. It already includes webrtc and easy to use compare to native code.

[Peterede]

There is UI already for calls available in the Spreedbox app so this could be used in conversations, using Cordova would not be practical.

[whitetornado]

what about the security of the voip? is it possible to use eg zrtp with sas?

Op do 28 jun. 2018 om 08:25 schreef Peter Edens [e-mail]:

There is UI already for calls available in the Spreedbox app so this could
be used in conversations, using Cordova would not be practical.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/siacs/Conversations/issues/1234#issuecomment-400925902,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AI4In1K7domYPDwyOj2XUw8xXwc86CSNks5uBHbRgaJpZM4EsJhp
.

[Peterede]

webrtc uses dtls-srtp

[streaps]

The XMPP world really don't need another non-standard way to do audio/voice calls. My impression is that these workarounds and discussions are a waste of time, because there is zero chance that it would be included in Conversations.

[PeterEdens]

The standard way of doing audio/video calls in XMPP world is using jingle for which there is an XMPP extension. JSXC uses this, jitsi does too. An implementation of jingle to SDP and SDP to jingle is the only real hurdle here. Jitsi uses smack so reusing their SDP to jingle code in conversations is not possible without rewriting the code.

[streaps]

I still don't get it. Why do you want to use SDP at all, if there is Jingle?

[Peterede]

webrtc cannot parse jingle so it needs to be converted to sdp.

[streaps]

xmpp clients can use jingle, no need to use sdp. conversations is not a web app. xmpp is federated, to be able to do video calls between different xmpp clients you have to use jingle.

[Peterede]

Yes that is correct xmpp uses jingle and conversations is not a web app. Webrtc is not strictly for web apps and is used in many android apps for realtime communications, it is secure and robust and ideal for use in Conversations. Jingle can be mapped to SDP to allow webrtc sessions to be established https://xmpp.org/extensions/xep-0167.html

[unicorntaco]

I personally started to become interested in this from a technological stand point.

Is aTalk headed in the right direction?
https://github.com/cmeng-git/atalk-android

[streaps]

Is aTalk headed in the right direction?
https://github.com/cmeng-git/atalk-android

it's actively developed, reported bugs are fixed by the developer and jingle audio does work. I'm not sure what the right direction is, but atalk is getting better with every new release. The biggest feature that is missing is push notification support.

[iNPUTmice]

Updating this so everyone subscribed to this issues get a notification.
Conversations now has support for A/V calls using Jingle!
This is available in 2.8.0

[iliarostovtsev]

That's fantastic! Audio and video calls using your own server works just fine now! Thank you!

[bodtx]

Hi I'm trying this on android 7+ and conversations2.8.3+fcr .
Phones are connected on 4G without wifi box or sthg like that.
no matter wich phone is calling, once answering, I have this error,

[alirasol]

Hi I'm trying this on android 7+ and conversations2.8.3+fcr .
Phones are connected on 4G without wifi box or sthg like that.
no matter wich phone is calling, once answering, I have this error,

Did you setup your stun/turn server??

[bodtx]

No,thought it was mandatory only for connection behind internet box.
To me jigle stream with two people is done with direct connection.
I have done a test behind a router and the phone could not discover the target (lock on message discovering other phone), so behaviour is different.

BTW I have no log in my prosody server for all of that.

[alirasol]

No,thought it was mandatory only for connection behind internet box.
To me jigle stream with two people is done with direct connection.
I have done a test behind a router and the phone could not discover the target (lock on message discovering other phone), so behaviour is different.

BTW I have no log in my prosody server for all of that.

I am no expert when it comes to jigle.
Without stun/turn server it only worked when on the same network. But when testing between 4G and wifi, I had to use stun and turn server, which only worked with udp connection for me. So my guess is you need a stun/turn server. Very easy to setup. You can run it on the same machine.

[licaon-kter]

You need at least a STUN one, https://gist.github.com/a28c438d9bbf3f4a3d4c663ffaa224d9

[bodtx]

indeed with coturn it works. I have only problem when 4G <-> wifi , the same wifi lan where coturn is running, maybe this is messing up things.
will try behind another wifi.
so 4G <-> 4G ✅
wifi <-> wifi (same one) ✅

thx

[alirasol]

indeed with coturn it works. I have only problem when 4G <-> wifi , the same wifi lan where coturn is running, maybe this is messing up things.
will try behind another wifi.
so 4G <-> 4G ✅
wifi <-> wifi (same one) ✅

thx

If it doesn't work, then there is a problem with the settings of the coturn

[licaon-kter]

@maisiliymBridj there are mentions in the Readme and in the stores descriptions.

Yes, DTLS-SRTP, not OMEMO.

[maisiliym]

Deleted the original question for some reason (does is do e2e encryption), maybe too much coffee; sorry for that
Anyhow, I guess I wasnt very clear anyway. My new question is:
What private key is it using to setup the TLS part of the handshake, since client TLS certs are a thing only in a parallel universe. Is it using the omemo key?

[licaon-kter]

@maisiliymBridj Like I said, not based on OMEMO (or not yet). See DTLS-SRTP docs.

[lessness0]

@maisiliymBridj Like I said, not based on OMEMO (or not yet). See DTLS-SRTP docs.

@licaon-kter Do I understand correctly that now audio / video calls are not protected from listening by the server (active MITM)?

[licaon-kter]

@gardener84 you don't. Please read about DTLS-SRTP.

[lessness0]

@licaon-kter
I understand the general idea of DTLS-SRTP, if the certificates are not authenticated (that is, they are generated and transmitted regardless of OMEMO keys), then we must rely on trust in the signal server. For example, the Signal uses the e2e channel to transmit keys for SRTP to avoid this.
Sorry if I don’t fully understand something.

[licaon-kter]

@gardener84 yes, at the moment they are not checked. So MITM might be possible, from the xmpp server side.

[lessness0]

@licaon-kter
Yes, I’m talking about that. Thanks for the answer!
Are there any future plans for revision in this part?

[licaon-kter]

In omemo:1 un the future, afaik,