[jitsi-dev] Time to first media too long


#1

Hi there!

I've been trying to create a custom UI for a WebRTC app using the Jitsi
Meet API but I've been having some issues with the time it takes for the
second user to receive the stream.

My setup is the following
- Dev machine: MacBook Pro
- VirtualBox running Ubuntu with jitsi-meet installed.
- Default jitsi-meet configuration plus change in the Prosody config file
to enable CORS. Jitsi Meet is accessible from the host machine at
https://local-meet.agilityfeat.com
- My custom app is running locally at https://local-dev.agilityfeat.com, it
is a nodejs app that uses React+Redux. The Redux actions are heavily based
on the https://github.com/jitsi/jitsi-meet-react project.
- Custom app uses lib-jitsi-meet npm module and strophe 1.2.4 from CDNjs.

*The problem:*
User A accesses it https://local-meet.agilityfeat.com/mycoolroom
User B joins the conference through the custom app (
https://local-dev.agilityfeat.com/mycoolroom)
User B receives the CONFERENCE_JOINED event
About 15 seconds have to pass after User B had CONFERENCE_JOINED for the
stream to be visible by User A.

Note: I already tried using the custom app on both the ends and the issue
remains. Jitsi Meet works just fine when used on both ends.

*The expected behavior:*
User A should be able to see User B stream way sooner (~3 seconds) like it
happens when using Jitsi Meet on both ends.

*Troubleshooting info:*
I've enabled the debug logs in Prosody and captured the logs for a session.
The user in the custom app joined first. You can find them attached.

I also saved the console logs in both the custom app and the jitsi meet
app. In the custom app the log that takes forever to appear is
*[/../forks/lib-jitsi-meet/modules/xmpp/strophe.jingle.js]
<Object.onJingle>: on jingle session-initiate...*

I'm also attaching the file that contains all the Redux actions.

Any clues on why this is happening? Would it had to do with the fact that
the request is coming from a different subdomain (remember I enabled CORS
for prosody)?. Please let me know if I can provide any additional info.

*Attachments:*
https://drive.google.com/open?id=0B2yPBke8DxjpWlQtdm1NZGlacVU

PS:
Sorry I'm causing some spam guys, I tried sending the email before with the
attachments included but didn't see the thread in
http://lists.jitsi.org/pipermail/dev/2016-June/date.html.

Thanks,
Nestor Bermudez


#2

Hi,

More inline.

Hi there!

I've been trying to create a custom UI for a WebRTC app using the Jitsi
Meet API but I've been having some issues with the time it takes for the
second user to receive the stream.

My setup is the following
- Dev machine: MacBook Pro
- VirtualBox running Ubuntu with jitsi-meet installed.
- Default jitsi-meet configuration plus change in the Prosody config
file to enable CORS. Jitsi Meet is accessible from the host machine at
https://local-meet.agilityfeat.com
- My custom app is running locally at https://local-dev.agilityfeat.com,
it is a nodejs app that uses React+Redux. The Redux actions are heavily
based on the https://github.com/jitsi/jitsi-meet-react project.
- Custom app uses lib-jitsi-meet npm module and strophe 1.2.4 from CDNjs.

*The problem:*
User A accesses it https://local-meet.agilityfeat.com/mycoolroom
User B joins the conference through the custom app
(https://local-dev.agilityfeat.com/mycoolroom)
User B receives the CONFERENCE_JOINED event
About 15 seconds have to pass after User B had CONFERENCE_JOINED for the
stream to be visible by User A.

Note: I already tried using the custom app on both the ends and the
issue remains. Jitsi Meet works just fine when used on both ends.

*The expected behavior:*
User A should be able to see User B stream way sooner (~3 seconds) like
it happens when using Jitsi Meet on both ends.

*Troubleshooting info:*
I've enabled the debug logs in Prosody and captured the logs for a
session. The user in the custom app joined first. You can find them
attached.

I also saved the console logs in both the custom app and the jitsi meet
app. In the custom app the log that takes forever to appear is
/[/../forks/lib-jitsi-meet/modules/xmpp/strophe.jingle.js]
<Object.onJingle>: on jingle session-initiate.../

The custom app and jitsi-meet logs are from the same session (where the app joins first), correct?

Looking at the logs, both apps connected and joined the MUC quickly, but then there was a 10+ second delay before they received an invite from jocofo. I don't know why that happened, but it isn't normal. Can you post your jicofo logs?

The custom app also takes a while before it starts connecting, but I assume this isn't a problem:
(TIME) Strophe CONNECTING: 17474.58

I'm also attaching the file that contains all the Redux actions.

Any clues on why this is happening? Would it had to do with the fact
that the request is coming from a different subdomain (remember I
enabled CORS for prosody)?. Please let me know if I can provide any
additional info.

I don't see how that could cause the delay.

Regards,
Boris

···

On 29/06/16 11:14, Néstor Bermúdez wrote:


#3

Thanks for the quick response Boris!

Answers inline.

Hi,

More inline.

> Hi there!
>
> I've been trying to create a custom UI for a WebRTC app using the Jitsi
> Meet API but I've been having some issues with the time it takes for the
> second user to receive the stream.
>
> My setup is the following
> - Dev machine: MacBook Pro
> - VirtualBox running Ubuntu with jitsi-meet installed.
> - Default jitsi-meet configuration plus change in the Prosody config
> file to enable CORS. Jitsi Meet is accessible from the host machine at
> https://local-meet.agilityfeat.com
> - My custom app is running locally at https://local-dev.agilityfeat.com,
> it is a nodejs app that uses React+Redux. The Redux actions are heavily
> based on the https://github.com/jitsi/jitsi-meet-react project.
> - Custom app uses lib-jitsi-meet npm module and strophe 1.2.4 from CDNjs.
>
> *The problem:*
> User A accesses it https://local-meet.agilityfeat.com/mycoolroom
> User B joins the conference through the custom app
> (https://local-dev.agilityfeat.com/mycoolroom)
> User B receives the CONFERENCE_JOINED event
> About 15 seconds have to pass after User B had CONFERENCE_JOINED for the
> stream to be visible by User A.
>
> Note: I already tried using the custom app on both the ends and the
> issue remains. Jitsi Meet works just fine when used on both ends.
>
> *The expected behavior:*
> User A should be able to see User B stream way sooner (~3 seconds) like
> it happens when using Jitsi Meet on both ends.
>
> *Troubleshooting info:*
> I've enabled the debug logs in Prosody and captured the logs for a
> session. The user in the custom app joined first. You can find them
> attached.
>
> I also saved the console logs in both the custom app and the jitsi meet
> app. In the custom app the log that takes forever to appear is
> /[/../forks/lib-jitsi-meet/modules/xmpp/strophe.jingle.js]
> <Object.onJingle>: on jingle session-initiate.../

The custom app and jitsi-meet logs are from the same session (where the
app joins first), correct?

The custom-app.log and jitsi-meet.log are for the same session. I captured
a new set of log files from Prosody, Jitsi Meet and the custom app
(prosody2.log, custom-app2.log and jitsi-meet2.log in the same drive folder)

Looking at the logs, both apps connected and joined the MUC quickly, but
then there was a 10+ second delay before they received an invite from
jocofo. I don't know why that happened, but it isn't normal. Can you
post your jicofo logs?

I just added the jicofo logs to the drive folder as well.

The custom app also takes a while before it starts connecting, but I
assume this isn't a problem:
(TIME) Strophe CONNECTING: 17474.58

I noticed that. But I'm not really sure if it is going to be a problem. Any
idea why it is taking a while?

···

On Wed, Jun 29, 2016 at 9:40 AM Boris Grozev <boris@jitsi.org> wrote:

On 29/06/16 11:14, Néstor Bermúdez wrote:

>
> I'm also attaching the file that contains all the Redux actions.
>
> Any clues on why this is happening? Would it had to do with the fact
> that the request is coming from a different subdomain (remember I
> enabled CORS for prosody)?. Please let me know if I can provide any
> additional info.

I don't see how that could cause the delay.

Regards,
Boris

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


#4

Hi Boris,

I was wondering if you had a chance to take a look at the jicofo logs.

I found two lines with difference in time similar to the time it takes to
connect:

Jicofo 2016-06-29 18:18:03.842 WARNING: [36]
org.jitsi.jicofo.JitsiMeetConference.propagateNewSSRCs().967 No jingle
session yet for roomid@conference.local-meet.agilityfeat.com/d03be39d
Jicofo 2016-06-29 18:18:18.039 SEVERE: [74]
org.jitsi.jicofo.discovery.DiscoveryUtil.discoverParticipantFeatures().139
Failed to discover features for
roomid@conference.local-meet.agilityfeat.com/d03be39d assuming default
feature set.

But I don't know what to make out of it.

Thanks,
Néstor Bermúdez

···

On Wed, Jun 29, 2016 at 10:32 AM Néstor Bermúdez < nestor.bermudez@agilityfeat.com> wrote:

Thanks for the quick response Boris!

Answers inline.

On Wed, Jun 29, 2016 at 9:40 AM Boris Grozev <boris@jitsi.org> wrote:

Hi,

More inline.

On 29/06/16 11:14, Néstor Bermúdez wrote:
> Hi there!
>
> I've been trying to create a custom UI for a WebRTC app using the Jitsi
> Meet API but I've been having some issues with the time it takes for the
> second user to receive the stream.
>
> My setup is the following
> - Dev machine: MacBook Pro
> - VirtualBox running Ubuntu with jitsi-meet installed.
> - Default jitsi-meet configuration plus change in the Prosody config
> file to enable CORS. Jitsi Meet is accessible from the host machine at
> https://local-meet.agilityfeat.com
> - My custom app is running locally at https://local-dev.agilityfeat.com
,
> it is a nodejs app that uses React+Redux. The Redux actions are heavily
> based on the https://github.com/jitsi/jitsi-meet-react project.
> - Custom app uses lib-jitsi-meet npm module and strophe 1.2.4 from
CDNjs.
>
> *The problem:*
> User A accesses it https://local-meet.agilityfeat.com/mycoolroom
> User B joins the conference through the custom app
> (https://local-dev.agilityfeat.com/mycoolroom)
> User B receives the CONFERENCE_JOINED event
> About 15 seconds have to pass after User B had CONFERENCE_JOINED for the
> stream to be visible by User A.
>
> Note: I already tried using the custom app on both the ends and the
> issue remains. Jitsi Meet works just fine when used on both ends.
>
> *The expected behavior:*
> User A should be able to see User B stream way sooner (~3 seconds) like
> it happens when using Jitsi Meet on both ends.
>
> *Troubleshooting info:*
> I've enabled the debug logs in Prosody and captured the logs for a
> session. The user in the custom app joined first. You can find them
> attached.
>
> I also saved the console logs in both the custom app and the jitsi meet
> app. In the custom app the log that takes forever to appear is
> /[/../forks/lib-jitsi-meet/modules/xmpp/strophe.jingle.js]
> <Object.onJingle>: on jingle session-initiate.../

The custom app and jitsi-meet logs are from the same session (where the
app joins first), correct?

The custom-app.log and jitsi-meet.log are for the same session. I captured
a new set of log files from Prosody, Jitsi Meet and the custom app
(prosody2.log, custom-app2.log and jitsi-meet2.log in the same drive folder)

Looking at the logs, both apps connected and joined the MUC quickly, but
then there was a 10+ second delay before they received an invite from
jocofo. I don't know why that happened, but it isn't normal. Can you
post your jicofo logs?

I just added the jicofo logs to the drive folder as well.

The custom app also takes a while before it starts connecting, but I
assume this isn't a problem:
(TIME) Strophe CONNECTING: 17474.58

I noticed that. But I'm not really sure if it is going to be a problem.
Any idea why it is taking a while?

>
> I'm also attaching the file that contains all the Redux actions.
>
> Any clues on why this is happening? Would it had to do with the fact
> that the request is coming from a different subdomain (remember I
> enabled CORS for prosody)?. Please let me know if I can provide any
> additional info.

I don't see how that could cause the delay.

Regards,
Boris

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


#5

Hi,

Hi Boris,

I was wondering if you had a chance to take a look at the jicofo logs.

I haven't looked deeply. I don't notice anything obviously wrong.

I found two lines with difference in time similar to the time it takes
to connect:

Jicofo 2016-06-29 18:18:03.842 WARNING: [36]
org.jitsi.jicofo.JitsiMeetConference.propagateNewSSRCs().967 No jingle
session yet for roomid@conference.local-meet.agilityfeat.com/d03be39d
<http://roomid@conference.local-meet.agilityfeat.com/d03be39d>
Jicofo 2016-06-29 18:18:18.039 SEVERE: [74]
org.jitsi.jicofo.discovery.DiscoveryUtil.discoverParticipantFeatures().139
Failed to discover features for
roomid@conference.local-meet.agilityfeat.com/d03be39d
<http://roomid@conference.local-meet.agilityfeat.com/d03be39d> assuming
default feature set.

But I don't know what to make out of it.

Yeah that could be related. AFAIK Jicofo should discover these using disco#info the first time, and then populate its cache and use the clientNode from presence. If your app uses a different clientNode this may fail (although I would expect it to still use disco#info).

I believe lib-jitsi-meet only uses the clientNode given to it via configuration and I don't know what the default it. Jitsi-meet defines this in config.js.

You can try setting clientNode to "http://jitsi.org/jitsimeet" as jitsi-meet does, and see if that helps.

Regards,
Boris

···

On 30/06/16 11:45, Néstor Bermúdez wrote:


#6

I already have clientNode set to "http://jitsi.org/jitsimeet". I'm using
the default settings except for the hosts URLs, the chrome extension and
callstats info.

Thanks,
Néstor

···

On Thu, Jun 30, 2016 at 1:23 PM Boris Grozev <boris@jitsi.org> wrote:

Hi,

On 30/06/16 11:45, Néstor Bermúdez wrote:
> Hi Boris,
>
> I was wondering if you had a chance to take a look at the jicofo logs.

I haven't looked deeply. I don't notice anything obviously wrong.

>
> I found two lines with difference in time similar to the time it takes
> to connect:
>
> ```
> Jicofo 2016-06-29 18:18:03.842 WARNING: [36]
> org.jitsi.jicofo.JitsiMeetConference.propagateNewSSRCs().967 No jingle
> session yet for roomid@conference.local-meet.agilityfeat.com/d03be39d
> <http://roomid@conference.local-meet.agilityfeat.com/d03be39d>
> Jicofo 2016-06-29 18:18:18.039 SEVERE: [74]
>
org.jitsi.jicofo.discovery.DiscoveryUtil.discoverParticipantFeatures().139
> Failed to discover features for
> roomid@conference.local-meet.agilityfeat.com/d03be39d
> <http://roomid@conference.local-meet.agilityfeat.com/d03be39d> assuming
> default feature set.
> ```
> But I don't know what to make out of it.

Yeah that could be related. AFAIK Jicofo should discover these using
disco#info the first time, and then populate its cache and use the
clientNode from presence. If your app uses a different clientNode this
may fail (although I would expect it to still use disco#info).

I believe lib-jitsi-meet only uses the clientNode given to it via
configuration and I don't know what the default it. Jitsi-meet defines
this in config.js.

You can try setting clientNode to "http://jitsi.org/jitsimeet" as
jitsi-meet does, and see if that helps.

Regards,
Boris


#7

Hi Boris!

After you mentioned that disco should be caching the data I took a look at
the versions of Strophe and its plugins that I was using.

I managed to get everything to work properly by changing those.
I was using Strophe 1.2.4 (latest available through npm) and the plugins
that are in https://github.com/jitsi/lib-jitsi-meet/tree/master/libs/strophe.
They don't seem to work well together.
When I downgraded Strophe to 1.2.2 (to match the version in
https://github.com/jitsi/lib-jitsi-meet/tree/master/libs/strophe) the issue
was gone.
Then I tried going back to Strophe 1.2.4 and use the latest plugins from
https://github.com/strophe/strophejs-plugins instead of the ones in
lib-jitsi-meet and this also worked just fine.

Thanks for the help provided!

Kind Regards,
Néstor Bermúdez

···

On Thu, Jun 30, 2016 at 1:23 PM Néstor Bermúdez < nestor.bermudez@agilityfeat.com> wrote:

I already have clientNode set to "http://jitsi.org/jitsimeet". I'm using
the default settings except for the hosts URLs, the chrome extension and
callstats info.

Thanks,
Néstor

On Thu, Jun 30, 2016 at 1:23 PM Boris Grozev <boris@jitsi.org> wrote:

Hi,

On 30/06/16 11:45, Néstor Bermúdez wrote:
> Hi Boris,
>
> I was wondering if you had a chance to take a look at the jicofo logs.

I haven't looked deeply. I don't notice anything obviously wrong.

>
> I found two lines with difference in time similar to the time it takes
> to connect:
>
> ```
> Jicofo 2016-06-29 18:18:03.842 WARNING: [36]
> org.jitsi.jicofo.JitsiMeetConference.propagateNewSSRCs().967 No jingle
> session yet for roomid@conference.local-meet.agilityfeat.com/d03be39d
> <http://roomid@conference.local-meet.agilityfeat.com/d03be39d>
> Jicofo 2016-06-29 18:18:18.039 SEVERE: [74]
>
org.jitsi.jicofo.discovery.DiscoveryUtil.discoverParticipantFeatures().139
> Failed to discover features for
> roomid@conference.local-meet.agilityfeat.com/d03be39d
> <http://roomid@conference.local-meet.agilityfeat.com/d03be39d> assuming
> default feature set.
> ```
> But I don't know what to make out of it.

Yeah that could be related. AFAIK Jicofo should discover these using
disco#info the first time, and then populate its cache and use the
clientNode from presence. If your app uses a different clientNode this
may fail (although I would expect it to still use disco#info).

I believe lib-jitsi-meet only uses the clientNode given to it via
configuration and I don't know what the default it. Jitsi-meet defines
this in config.js.

You can try setting clientNode to "http://jitsi.org/jitsimeet" as
jitsi-meet does, and see if that helps.

Regards,
Boris


#8

Hi,

···

On 01/07/16 19:36, Néstor Bermúdez wrote:

Hi Boris!

After you mentioned that disco should be caching the data I took a look
at the versions of Strophe and its plugins that I was using.

I managed to get everything to work properly by changing those.
I was using Strophe 1.2.4 (latest available through npm) and the plugins
that are
in https://github.com/jitsi/lib-jitsi-meet/tree/master/libs/strophe.
They don't seem to work well together.
When I downgraded Strophe to 1.2.2 (to match the version
in https://github.com/jitsi/lib-jitsi-meet/tree/master/libs/strophe) the
issue was gone.
Then I tried going back to Strophe 1.2.4 and use the latest plugins
from https://github.com/strophe/strophejs-plugins instead of the ones in
lib-jitsi-meet and this also worked just fine.

I'm glad to got to the bottom of it. And thanks for posting your findings!

Boris