[jitsi-dev] jitsi-meet for iOS


#1

Oh awesome! Thank you! I'm going to try this out soon.

Were you able to get anything working yet, and if not what are the issues
you are facing?


#2

We have audio and video streamed and played back in both directions
between iOS and Chrome.

···

On Wed, May 18, 2016 at 8:49 AM, Jake Quattrocchi <jake.quattrocchi@gmail.com> wrote:

Were you able to get anything working yet


#3

I tried running the latest code on your
https://github.com/lyubomir/RCTWebRTCDemo in the lib-jitsi-meet branch and
got it to compile and run on iOS, but when i view the corresponding room in
meet.jit.si both iOS and chrome see that there is another participant in
the room without displaying the remote stream. (just a black video and no
audio)

when debugging on the phone i saw that the remote stream looked to be stuck
on ice checking.

I was wondering if this issue has happened to you or if you have an idea
why its not working

···

On Tue, May 17, 2016 at 7:50 PM Lyubomir Marinov <lyubomir.marinov@jitsi.org> wrote:

On Wed, May 18, 2016 at 8:49 AM, Jake Quattrocchi > <jake.quattrocchi@gmail.com> wrote:
> Were you able to get anything working yet

We have audio and video streamed and played back in both directions
between iOS and Chrome.

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#4

I tried running the latest code on your
https://github.com/lyubomir/RCTWebRTCDemo in the lib-jitsi-meet branch and
got it to compile and run on iOS, but when i view the corresponding room in
meet.jit.si both iOS and chrome see that there is another participant in the
room

They learn about the other participants and their media (i.e. videos
and audios) through the signaling path. It seems to work pretty
reliably.

without displaying the remote stream. (just a black video and no audio)

when debugging on the phone i saw that the remote stream looked to be stuck
on ice checking.

I was wondering if this issue has happened to you or if you have an idea why
its not working

The very media though should eventually flow through the media path
which is different than the signaling path and is opened using ICE.
Unfortunately, we seem to be getting ICE failures (i.e. ICE never
completes) pretty often on devices (not the iOS simulator).

I'll look into that more today.

···

On Thu, May 19, 2016 at 2:18 AM, Jake Quattrocchi <jake.quattrocchi@gmail.com> wrote:


#5

Unfortunately, we seem to be getting ICE failures (i.e. ICE never
completes) pretty often on devices (not the iOS simulator).

I was researching a little bit about ice never completing, and it looks
like the dtls handshake never resolves on iOS.

I read (in https://bugs.chromium.org/p/webrtc/issues/detail?id=4223) that
it could have to do with possibly Boring SSL vs OpenSSL, but im not sure.

Do you think the issue could be in the webrtc/libjingle_peerconnection build
currently in react-native-webrtc?

···

On Wed, May 18, 2016 at 3:46 PM Lyubomir Marinov <lyubomir.marinov@jitsi.org> wrote:

On Thu, May 19, 2016 at 2:18 AM, Jake Quattrocchi > <jake.quattrocchi@gmail.com> wrote:
> I tried running the latest code on your
> https://github.com/lyubomir/RCTWebRTCDemo in the lib-jitsi-meet branch
and
> got it to compile and run on iOS, but when i view the corresponding room
in
> meet.jit.si both iOS and chrome see that there is another participant
in the
> room

They learn about the other participants and their media (i.e. videos
and audios) through the signaling path. It seems to work pretty
reliably.

> without displaying the remote stream. (just a black video and no audio)
>
> when debugging on the phone i saw that the remote stream looked to be
stuck
> on ice checking.
>
> I was wondering if this issue has happened to you or if you have an idea
why
> its not working

The very media though should eventually flow through the media path
which is different than the signaling path and is opened using ICE.
Unfortunately, we seem to be getting ICE failures (i.e. ICE never
completes) pretty often on devices (not the iOS simulator).

I'll look into that more today.

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#6

Yesterday ICE completed successfully on my iPhone 5c throughout the day.

···

On Fri, May 20, 2016 at 2:57 AM, Jake Quattrocchi <jake.quattrocchi@gmail.com> wrote:

I was researching a little bit about ice never completing, and it looks like
the dtls handshake never resolves on iOS.

I read (in https://bugs.chromium.org/p/webrtc/issues/detail?id=4223) that it
could have to do with possibly Boring SSL vs OpenSSL, but im not sure.

Do you think the issue could be in the webrtc/libjingle_peerconnection build
currently in react-native-webrtc?


#7

Okay i think i may know the issue.

I tried running the demo (https://github.com/lyubomir/RCTWebRTCDemo) on my
iPhone 6s,5s and 5.

In testing the the 6s and 5s, the dtls handshake is never completing.
BUT
In testing the the 5 it works!!

so i was researching why and came across this image (
http://i.stack.imgur.com/F5s5W.png) that shows the ARM architecture differences
across iOS devices

It turns out the iPhone 5 and 5c(the phone you tested) have an ARMv7s
architecture and those worked successfully with jitsi.

But the iPhone 5s and 6s have an ARM64 architecture and those failed to
work with jitsi

so i came across this article (
https://bugs.chromium.org/p/webrtc/issues/detail?id=4929) about issues with
ARM64 failing with dtls handshake.

so I think we have to figure out the correct build of webrtc and that will
solve this issue.

···

On Thu, May 19, 2016 at 6:19 PM Lyubomir Marinov <lyubomir.marinov@jitsi.org> wrote:

Yesterday ICE completed successfully on my iPhone 5c throughout the day.

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#8

In case any of you who're interested in react-native + lib-jitsi-meet
find it useful:

https://github.com/lyubomir/react-native-webrtc/commit/108b3a5da7b53e058c4927624afc5f73ea9d63b6
supports remotely-opened RTCDataChannel. It allows
jitsi/lib-jitsi-meet#react-native in
lyubomir/RCTWebRTCDemo#lib-jitsi-meet to successfully receive
Videobridge's RTCDataChannel messages. I plan to get back to the
commit in question because I'm not very comfortable with removing the
reactTag property from react-native-webrtc's RTCDataChannel.