[jitsi-users] jitsi-meet no chat/voice/video


#1

I followed the manual install guide[1] (which was excellent, by the way)
to get everything set up. Everything seemed to go smoothly, but when I
connect to jitsi-meet using Chrome, I am unable to speak, hear, chat, or
see anyone else in the room. I do get the landing page, and I am able
to enter a chatroom and get the UI where all of the above should be working.

The only other clue that I have is that when I click "Invite others"
icon, it tells me: Your conference is currently being created...

I've tested the multi-user chat in Prosody using a standalone XMPP
client, and it is working just fine.

I set the log level to DEBUG on Prosody and can confirm that users are
getting sessions, and chat message are getting to the server (logs
below). At this point, I'm not sure where to go next. It looks like
Prodosy is working fine, but I'm not sure how to verify these other
components are working as expected. I also don't fully understand what
they do.

Is there a diagram of how jitsi-meet, the XMPP server, jitsi conference
focus, the videobridge, bosh, and the browser all interact? I don't
fully understand how all the components are connected, and what order I
should see them do their thing. Understand that would be very helpful
in me trying to troubleshoot this issue since I could trace through from
one step to the next, as opposed to doing what I'm doing now, which is
just checking things at random.

Finally, I'd be happy to create this documentation if it doesn't already
exist. I'm going to need it for my own sanity, so I might as well share
it with the world.

Thanks,
Adam

Prosody logs - two people connecting to jitsi-meet via Chrome
Aug 20 23:34:12 mod_bosh info New BOSH session, assigned it
sid '4bcfcbd3-82b2-4bd1-999d-7a73c4a185d1'
Aug 20 23:34:16 bosh4bcfcbd3-82b2-4bd1-999d-7a73c4a185d1 info
BOSH client disconnected
Aug 20 23:34:16 mod_bosh info New BOSH session, assigned it
sid '44d32608-eca8-4cd7-8d2a-f820b0ee6fad'

Prosody logs - me sending a message:
Aug 20 23:57:02 socket debug server.lua: accepted new client
connection from ::1:47288 to 5280
Aug 20 23:57:02 mod_bosh debug Handling new request table:
0x11fab80: <body rid='3092846535'
xmlns='http://jabber.org/protocol/httpbind' sid=
'702c311b-0735-48b7-8d71-9e1b852d4929'><message to='null'
type='groupchat'
xmlns='jabber:client'><body>AFKKKKKKKKKKKKKKKKKKKKK</body><nick xmlns='http
://jabber.org/protocol/nick'>adam</nick></message></body>

···

----------
Aug 20 23:57:02 mod_bosh debug BOSH body open (sid:
702c311b-0735-48b7-8d71-9e1b852d4929)
Aug 20 23:57:02 mod_bosh debug BOSH stanza received: <message
to='null' type='groupchat'>

Aug 20 23:57:02 bosh702c311b-0735-48b7-8d71-9e1b852d4929 debug
Received[c2s_unauthed]: <message to='null' type='groupchat'>
Aug 20 23:57:02 stanzarouter debug Unhandled c2s_unauthed stanza:
message; xmlns=jabber:client
Aug 20 23:57:02 mod_bosh debug We have an open request, so
sending on that
Aug 20 23:57:02 mod_bosh debug Request destroyed: table: 0x126dc00
Aug 20 23:57:02 socket debug server.lua: closed client handler and
removed socket from list
Aug 20 23:57:02 mod_bosh debug Session
702c311b-0735-48b7-8d71-9e1b852d4929 has 1 out of 1 requests open
Aug 20 23:57:02 mod_bosh debug and there are 0 things in the
send_buffer:
Aug 20 23:57:02 mod_bosh debug Have nothing to say, so leaving
request unanswered for now
Aug 20 23:57:02 socket debug server.lua: accepted new client
connection from 127.0.0.1:36176 to 5280
Aug 20 23:57:02 mod_bosh debug Handling new request table:
0x11ad460: <body rid='3092846536'
xmlns='http://jabber.org/protocol/httpbind'
sid='702c311b-0735-48b7-8d71-9e1b852d4929'/>
----------
Aug 20 23:57:02 mod_bosh debug BOSH body open (sid:
702c311b-0735-48b7-8d71-9e1b852d4929)
Aug 20 23:57:02 mod_bosh debug Session
702c311b-0735-48b7-8d71-9e1b852d4929 has 2 out of 1 requests open
Aug 20 23:57:02 mod_bosh debug and there are 0 things in the
send_buffer:
Aug 20 23:57:02 mod_bosh debug We are holding too many
requests, so...
Aug 20 23:57:02 mod_bosh debug ...sending an empty response
Aug 20 23:57:02 mod_bosh debug We have an open request, so
sending on that
Aug 20 23:57:02 mod_bosh debug Request destroyed: table: 0x11f9c90
Aug 20 23:57:02 socket debug server.lua: closed client handler and
removed socket from list
Aug 20 23:57:02 mod_bosh debug Have nothing to say, so leaving
request unanswered for now

[1] https://github.com/jitsi/jitsi-meet/blob/master/doc/manual-install.md


#2

I followed the manual install guide[1] (which was excellent, by the way)
to get everything set up. Everything seemed to go smoothly, but when I
connect to jitsi-meet using Chrome, I am unable to speak, hear, chat, or
see anyone else in the room. I do get the landing page, and I am able
to enter a chatroom and get the UI where all of the above should be working.

The only other clue that I have is that when I click "Invite others"
icon, it tells me: Your conference is currently being created...

I've tested the multi-user chat in Prosody using a standalone XMPP
client, and it is working just fine.

I set the log level to DEBUG on Prosody and can confirm that users are
getting sessions, and chat message are getting to the server (logs
below). At this point, I'm not sure where to go next. It looks like
Prodosy is working fine, but I'm not sure how to verify these other
components are working as expected. I also don't fully understand what
they do.

Is there a diagram of how jitsi-meet, the XMPP server, jitsi conference
focus, the videobridge, bosh, and the browser all interact? I don't
fully understand how all the components are connected, and what order I
should see them do their thing. Understand that would be very helpful
in me trying to troubleshoot this issue since I could trace through from
one step to the next, as opposed to doing what I'm doing now, which is
just checking things at random.

This would be quite useful indeed. I think the closest thing we have is Franck's paper and presentation here:
https://tnc15.terena.org/core/presentation/87

Finally, I'd be happy to create this documentation if it doesn't already
exist. I'm going to need it for my own sanity, so I might as well share
it with the world.

Thanks,
Adam

Prosody logs - two people connecting to jitsi-meet via Chrome
Aug 20 23:34:12 mod_bosh info New BOSH session, assigned it
sid '4bcfcbd3-82b2-4bd1-999d-7a73c4a185d1'
Aug 20 23:34:16 bosh4bcfcbd3-82b2-4bd1-999d-7a73c4a185d1 info
BOSH client disconnected
Aug 20 23:34:16 mod_bosh info New BOSH session, assigned it
sid '44d32608-eca8-4cd7-8d2a-f820b0ee6fad'

Prosody logs - me sending a message:
Aug 20 23:57:02 socket debug server.lua: accepted new client
connection from ::1:47288 to 5280
Aug 20 23:57:02 mod_bosh debug Handling new request table:
0x11fab80: <body rid='3092846535'
xmlns='http://jabber.org/protocol/httpbind' sid=
'702c311b-0735-48b7-8d71-9e1b852d4929'><message to='null'

This doesn't look right. You should check the browser's javascript console next.

We find that problems rarely occur on the XMPP/prosody level. Jicofo and videobridge logs will likely be more useful.

Boris

···

On 21/08/15 10:26, Adam wrote:


#3

Boris: Thanks for the link to the presentation. It confirmed my
understanding of what jitsi-videobridge does. I've read the overview of
jicofo[1] multiple times, but I still don't understand its purpose. If
we're going with a full star topology, why wouldn't the web clients just
send audio/video to videobridge via RTP and receive RTP streams back?
I'm sure there's a reason, I just haven't been able to find it yet.

As for the external component logs, I found that jicofo complains every
30 seconds about feature list changing, however the comments in the
source code indicate that this is not actually a problem (despite being
logged as SEVERE)[2].

As a test, I restarted Prosody, then videobridge. jicofo reconnected
first and reported that the focus and videobridge components went
offline. 30 seconds later it re-discovered these components. So
everything seems normal there.

The web console does show an error, but it appears to be related to the
fact that my client doesn't have a camera (just microphone). Console
message is below.

I decided to dig into the "Your conference is currently being
created..." oddity that I mentioned earlier. The punchline is that if
the XMPPEvents.MUC_JOINED had fired, then it would have had populated
that text field with a URL instead of that message. I added in a bunch
of alert() statements in the JS code and was able to confirm that it
does not join the MUC. In fact, it doesn't even call
Authentication::xmppAuthenticate(). (For those following along at home:
xmppAuthenticate() calls APP.UI.checkForNicknameAndJoin(), which calls
APP.xmpp.joinRoom(), which is what actually joins the room)

I tested this using Google Chrome on both OSX and Linux, same results.

So at least now I know what is not happening, but I'm still not sure
why... Anyone have any ideas? Is it time to go to the jitsi dev
mailing list for help on this one?

jicofo logs showing the feature list is changing:
2015-07-21 13:40:03.486 SEVERE: [162]
org.jitsi.jicofo.ComponentsDiscovery.discoverServices().215 Feature list
changed for: auth.chat.diseasedmind.com

From the Chrome console:

Requested local resource before we're in the MUC
38.LocalVideo.getResourceJid @app.bundle.js?v=129:9374

The relevant JS source code causing this error in the console:
LocalVideo.prototype.getResourceJid = function () {
    var myResource = APP.xmpp.myResource();
    if (!myResource) {
        console.error("Requested local resource before we're in the MUC");
    }
    return myResource;
};

[1] https://github.com/jitsi/jicofo#overview
[2]
https://github.com/jitsi/jicofo/blob/master/src/main/java/org/jitsi/jicofo/ComponentsDiscovery.java

···

On 08/21/2015 12:31 PM, Boris Grozev wrote:

On 21/08/15 10:26, Adam wrote:

I followed the manual install guide[1] (which was excellent, by the way)
to get everything set up. Everything seemed to go smoothly, but when I
connect to jitsi-meet using Chrome, I am unable to speak, hear, chat, or
see anyone else in the room. I do get the landing page, and I am able
to enter a chatroom and get the UI where all of the above should be
working.

The only other clue that I have is that when I click "Invite others"
icon, it tells me: Your conference is currently being created...

I've tested the multi-user chat in Prosody using a standalone XMPP
client, and it is working just fine.

I set the log level to DEBUG on Prosody and can confirm that users are
getting sessions, and chat message are getting to the server (logs
below). At this point, I'm not sure where to go next. It looks like
Prodosy is working fine, but I'm not sure how to verify these other
components are working as expected. I also don't fully understand what
they do.

Is there a diagram of how jitsi-meet, the XMPP server, jitsi conference
focus, the videobridge, bosh, and the browser all interact? I don't
fully understand how all the components are connected, and what order I
should see them do their thing. Understand that would be very helpful
in me trying to troubleshoot this issue since I could trace through from
one step to the next, as opposed to doing what I'm doing now, which is
just checking things at random.

This would be quite useful indeed. I think the closest thing we have is
Franck's paper and presentation here:
https://tnc15.terena.org/core/presentation/87

Finally, I'd be happy to create this documentation if it doesn't already
exist. I'm going to need it for my own sanity, so I might as well share
it with the world.

Thanks,
Adam

Prosody logs - two people connecting to jitsi-meet via Chrome
Aug 20 23:34:12 mod_bosh info New BOSH session, assigned it
sid '4bcfcbd3-82b2-4bd1-999d-7a73c4a185d1'
Aug 20 23:34:16 bosh4bcfcbd3-82b2-4bd1-999d-7a73c4a185d1 info
BOSH client disconnected
Aug 20 23:34:16 mod_bosh info New BOSH session, assigned it
sid '44d32608-eca8-4cd7-8d2a-f820b0ee6fad'

Prosody logs - me sending a message:
Aug 20 23:57:02 socket debug server.lua: accepted new client
connection from ::1:47288 to 5280
Aug 20 23:57:02 mod_bosh debug Handling new request table:
0x11fab80: <body rid='3092846535'
xmlns='http://jabber.org/protocol/httpbind' sid=
'702c311b-0735-48b7-8d71-9e1b852d4929'><message to='null'

This doesn't look right. You should check the browser's javascript
console next.

We find that problems rarely occur on the XMPP/prosody level. Jicofo and
videobridge logs will likely be more useful.

Boris

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


#4

Boris: Thanks for the link to the presentation. It confirmed my
understanding of what jitsi-videobridge does. I've read the overview of
jicofo[1] multiple times, but I still don't understand its purpose. If
we're going with a full star topology, why wouldn't the web clients just
send audio/video to videobridge via RTP and receive RTP streams back?
I'm sure there's a reason, I just haven't been able to find it yet.

This is exactly what happens. Jicofo server as a signalling server in order to setup these RTP sessions.

As for the external component logs, I found that jicofo complains every
30 seconds about feature list changing, however the comments in the
source code indicate that this is not actually a problem (despite being
logged as SEVERE)[2].

As a test, I restarted Prosody, then videobridge. jicofo reconnected
first and reported that the focus and videobridge components went
offline. 30 seconds later it re-discovered these components. So
everything seems normal there.

The web console does show an error, but it appears to be related to the
fact that my client doesn't have a camera (just microphone). Console
message is below.

I decided to dig into the "Your conference is currently being
created..." oddity that I mentioned earlier. The punchline is that if
the XMPPEvents.MUC_JOINED had fired, then it would have had populated
that text field with a URL instead of that message. I added in a bunch
of alert() statements in the JS code and was able to confirm that it
does not join the MUC. In fact, it doesn't even call
Authentication::xmppAuthenticate(). (For those following along at home:
xmppAuthenticate() calls APP.UI.checkForNicknameAndJoin(), which calls
APP.xmpp.joinRoom(), which is what actually joins the room)

This is normal. This code doesn't execute for anonymous XMPP login which is what you are using (right?). Look for a message like this to confirm successful XMPP login: "My Jabber ID:". Given your prosody logs, I think this works fine.

The next thing the client does is join a MUC, and this seems to fail in your case. Check the prosody configuration for the MUC component, and check that you have the correct domain in config.js (hosts.muc).

I tested this using Google Chrome on both OSX and Linux, same results.

So at least now I know what is not happening, but I'm still not sure
why... Anyone have any ideas? Is it time to go to the jitsi dev
mailing list for help on this one?

Well, you won't find a different audience there. I'd keep it all in one thread :slight_smile:

Regards,
Boris

···

On 22/08/15 21:58, Adam wrote:


#5

I double checked my config.js and prosody configuration and they have
matching hostnames.

I don't see this "My Jabber ID:" message anywhere in the developer
console in Chrome. Here are the full console logs:

This appears to be Chrome, ver: 44
jquery-2.1.1.min.js:4 Synchronous XMLHttpRequest on the main thread is
deprecated because of its detrimental effects to the end user's
experience. For more help, check http://xhr.spec.whatwg.org/.
app.bundle.js?v=129:11873 Using Chrome WebRTC for desktop sharing
app.bundle.js?v=129:1809 Get media constraints Object {audio: Object,
video: Object}
app.bundle.js?v=129:1814 getUserMedia() is deprecated on insecure
origins, and support will be removed in the future. You should
consider switching your application to a secure origin, such as HTTPS.
See https://goo.gl/rStTGz for more details.
app.bundle.js?v=129:18884 Strophe status changed to CONNECTING null
app.bundle.js?v=129:1822 Failed to get access to local media. Error
NavigatorUserMediaError {} Object {audio: Object, video: Object}
app.bundle.js?v=129:1953 failed to obtain audio/video stream - trying
audio only NavigatorUserMediaError {}11.RTCUtils.errorCallback @
app.bundle.js?v=129:1953(anonymous function) @
app.bundle.js?v=129:1936(anonymous function) @ app.bundle.js?v=129:1825
app.bundle.js?v=129:1809 Get media constraints Object {audio: Object,
video: false}
app.bundle.js?v=129:1816 onUserMediaSuccess
app.bundle.js?v=129:1946 got MediaStream {} 1 0
app.bundle.js?v=129:11016 Peer video type changed: null camera

I do plan on switching the web server to use TLS, so that will take
care of that warning. I don't have a webcam on this computer, so that
explains the lack of video stream. I found the "Strophe status
changed to" javascript code. In that same area, I saw the "My Jabber
ID" string that you mentioned. Looks like you are on the right track.

"bosh" is set in config.js, and the bosh module is enabled server-wide
in Prosody. Furthermore, I am seeing things like this in the Prosody
logs:

Aug 28 21:25:54 mod_bosh debug BOSH body open (sid:
a4f03c99-b59a-4712-aba9-210d62a3021d)

I tried re-enabling Google Analytics, just to see if that would make
any difference. It didn't. So I commented out all the code in
analytics.js again.

As I was going through the code, I also noticed there's a lot of
references to a "ConnectionIndicator" object, but I didn't see any
visual indication of whether I was connecting or not. Is there
supposed to be something on the screen showing the connection status?
It sounds like it'd be really helpful for situations like this where
the connection isn't doing so well.

At any rate, where should I look next?

···

On 08/24/2015 10:51 AM, Boris Grozev wrote:

On 22/08/15 21:58, Adam wrote:

I decided to dig into the "Your conference is currently being
created..." oddity that I mentioned earlier. The punchline is
that if the XMPPEvents.MUC_JOINED had fired, then it would have
had populated that text field with a URL instead of that message.
I added in a bunch of alert() statements in the JS code and was
able to confirm that it does not join the MUC. In fact, it
doesn't even call Authentication::xmppAuthenticate(). (For those
following along at home: xmppAuthenticate() calls
APP.UI.checkForNicknameAndJoin(), which calls
APP.xmpp.joinRoom(), which is what actually joins the room)

This is normal. This code doesn't execute for anonymous XMPP login
which is what you are using (right?). Look for a message like this
to confirm successful XMPP login: "My Jabber ID:". Given your
prosody logs, I think this works fine.

The next thing the client does is join a MUC, and this seems to
fail in your case. Check the prosody configuration for the MUC
component, and check that you have the correct domain in config.js
(hosts.muc).


#6

Just wanted to follow up and see if anyone knows where I should look
next. I presume it's time for me to dig into the Strophe library code...

···

On 08/28/2015 10:19 PM, Adam wrote:

On 08/24/2015 10:51 AM, Boris Grozev wrote:

On 22/08/15 21:58, Adam wrote:

I decided to dig into the "Your conference is currently being
created..." oddity that I mentioned earlier. The punchline is
that if the XMPPEvents.MUC_JOINED had fired, then it would have
had populated that text field with a URL instead of that message.
I added in a bunch of alert() statements in the JS code and was
able to confirm that it does not join the MUC. In fact, it
doesn't even call Authentication::xmppAuthenticate(). (For those
following along at home: xmppAuthenticate() calls
APP.UI.checkForNicknameAndJoin(), which calls
APP.xmpp.joinRoom(), which is what actually joins the room)

This is normal. This code doesn't execute for anonymous XMPP login
which is what you are using (right?). Look for a message like this
to confirm successful XMPP login: "My Jabber ID:". Given your
prosody logs, I think this works fine.

The next thing the client does is join a MUC, and this seems to
fail in your case. Check the prosody configuration for the MUC
component, and check that you have the correct domain in config.js
(hosts.muc).

I double checked my config.js and prosody configuration and they have
matching hostnames.

I don't see this "My Jabber ID:" message anywhere in the developer
console in Chrome. Here are the full console logs:

This appears to be Chrome, ver: 44
jquery-2.1.1.min.js:4 Synchronous XMLHttpRequest on the main thread is
deprecated because of its detrimental effects to the end user's
experience. For more help, check http://xhr.spec.whatwg.org/.
app.bundle.js?v=129:11873 Using Chrome WebRTC for desktop sharing
app.bundle.js?v=129:1809 Get media constraints Object {audio: Object,
video: Object}
app.bundle.js?v=129:1814 getUserMedia() is deprecated on insecure
origins, and support will be removed in the future. You should
consider switching your application to a secure origin, such as HTTPS.
See https://goo.gl/rStTGz for more details.
app.bundle.js?v=129:18884 Strophe status changed to CONNECTING null
app.bundle.js?v=129:1822 Failed to get access to local media. Error
NavigatorUserMediaError {} Object {audio: Object, video: Object}
app.bundle.js?v=129:1953 failed to obtain audio/video stream - trying
audio only NavigatorUserMediaError {}11.RTCUtils.errorCallback @
app.bundle.js?v=129:1953(anonymous function) @
app.bundle.js?v=129:1936(anonymous function) @ app.bundle.js?v=129:1825
app.bundle.js?v=129:1809 Get media constraints Object {audio: Object,
video: false}
app.bundle.js?v=129:1816 onUserMediaSuccess
app.bundle.js?v=129:1946 got MediaStream {} 1 0
app.bundle.js?v=129:11016 Peer video type changed: null camera

I do plan on switching the web server to use TLS, so that will take
care of that warning. I don't have a webcam on this computer, so that
explains the lack of video stream. I found the "Strophe status
changed to" javascript code. In that same area, I saw the "My Jabber
ID" string that you mentioned. Looks like you are on the right track.

"bosh" is set in config.js, and the bosh module is enabled server-wide
in Prosody. Furthermore, I am seeing things like this in the Prosody
logs:

Aug 28 21:25:54 mod_bosh debug BOSH body open (sid:
a4f03c99-b59a-4712-aba9-210d62a3021d)

I tried re-enabling Google Analytics, just to see if that would make
any difference. It didn't. So I commented out all the code in
analytics.js again.

As I was going through the code, I also noticed there's a lot of
references to a "ConnectionIndicator" object, but I didn't see any
visual indication of whether I was connecting or not. Is there
supposed to be something on the screen showing the connection status?
It sounds like it'd be really helpful for situations like this where
the connection isn't doing so well.

At any rate, where should I look next?


#7

In case anyone runs into this in the future, the problem was that I had
c2s_require_encryption = true, and authentication = "internal_hashed" in
my prosody.cfg.lua.

By opening this up to allow unauthenticated, anonymous users to use the
XMPP server, everything with jitsi started working. Obviously this
isn't the level of security I'm looking for, but it's a start.

I'll get a TLS certificate which might allow me to turn on
c3s_require_encryption in Prosody.

Is there a way to get the web server authenticate to the XMPP server (so
all web-based users would be sharing the same account)?

Thanks,
Adam

···

On 09/08/2015 01:01 PM, Adam wrote:

Just wanted to follow up and see if anyone knows where I should look
next. I presume it's time for me to dig into the Strophe library code...

On 08/28/2015 10:19 PM, Adam wrote:

On 08/24/2015 10:51 AM, Boris Grozev wrote:

On 22/08/15 21:58, Adam wrote:

I decided to dig into the "Your conference is currently being
created..." oddity that I mentioned earlier. The punchline is
that if the XMPPEvents.MUC_JOINED had fired, then it would have
had populated that text field with a URL instead of that message.
I added in a bunch of alert() statements in the JS code and was
able to confirm that it does not join the MUC. In fact, it
doesn't even call Authentication::xmppAuthenticate(). (For those
following along at home: xmppAuthenticate() calls
APP.UI.checkForNicknameAndJoin(), which calls
APP.xmpp.joinRoom(), which is what actually joins the room)

This is normal. This code doesn't execute for anonymous XMPP login
which is what you are using (right?). Look for a message like this
to confirm successful XMPP login: "My Jabber ID:". Given your
prosody logs, I think this works fine.

The next thing the client does is join a MUC, and this seems to
fail in your case. Check the prosody configuration for the MUC
component, and check that you have the correct domain in config.js
(hosts.muc).

I double checked my config.js and prosody configuration and they have
matching hostnames.

I don't see this "My Jabber ID:" message anywhere in the developer
console in Chrome. Here are the full console logs:

This appears to be Chrome, ver: 44
jquery-2.1.1.min.js:4 Synchronous XMLHttpRequest on the main thread is
deprecated because of its detrimental effects to the end user's
experience. For more help, check http://xhr.spec.whatwg.org/.
app.bundle.js?v=129:11873 Using Chrome WebRTC for desktop sharing
app.bundle.js?v=129:1809 Get media constraints Object {audio: Object,
video: Object}
app.bundle.js?v=129:1814 getUserMedia() is deprecated on insecure
origins, and support will be removed in the future. You should
consider switching your application to a secure origin, such as HTTPS.
See https://goo.gl/rStTGz for more details.
app.bundle.js?v=129:18884 Strophe status changed to CONNECTING null
app.bundle.js?v=129:1822 Failed to get access to local media. Error
NavigatorUserMediaError {} Object {audio: Object, video: Object}
app.bundle.js?v=129:1953 failed to obtain audio/video stream - trying
audio only NavigatorUserMediaError {}11.RTCUtils.errorCallback @
app.bundle.js?v=129:1953(anonymous function) @
app.bundle.js?v=129:1936(anonymous function) @ app.bundle.js?v=129:1825
app.bundle.js?v=129:1809 Get media constraints Object {audio: Object,
video: false}
app.bundle.js?v=129:1816 onUserMediaSuccess
app.bundle.js?v=129:1946 got MediaStream {} 1 0
app.bundle.js?v=129:11016 Peer video type changed: null camera

I do plan on switching the web server to use TLS, so that will take
care of that warning. I don't have a webcam on this computer, so that
explains the lack of video stream. I found the "Strophe status
changed to" javascript code. In that same area, I saw the "My Jabber
ID" string that you mentioned. Looks like you are on the right track.

"bosh" is set in config.js, and the bosh module is enabled server-wide
in Prosody. Furthermore, I am seeing things like this in the Prosody
logs:

Aug 28 21:25:54 mod_bosh debug BOSH body open (sid:
a4f03c99-b59a-4712-aba9-210d62a3021d)

I tried re-enabling Google Analytics, just to see if that would make
any difference. It didn't. So I commented out all the code in
analytics.js again.

As I was going through the code, I also noticed there's a lot of
references to a "ConnectionIndicator" object, but I didn't see any
visual indication of whether I was connecting or not. Is there
supposed to be something on the screen showing the connection status?
It sounds like it'd be really helpful for situations like this where
the connection isn't doing so well.

At any rate, where should I look next?


#8

Note that this only leaves the connection from your web-server to your XMPP server unencrypted (which is a local connection). The traffic from clients goes over HTTPS to the web-server.

Boris

···

On 09/09/15 23:07, Adam wrote:

In case anyone runs into this in the future, the problem was that I had
c2s_require_encryption = true, and authentication = "internal_hashed" in
my prosody.cfg.lua.

By opening this up to allow unauthenticated, anonymous users to use the
XMPP server, everything with jitsi started working. Obviously this
isn't the level of security I'm looking for, but it's a start.