[jitsi-users] meet.jit.si configuration changed?


#1

Hi,

I used to connect to lambada.jit.si:5222 (XMPP server) with "meet.jit.si" set as MUC to join public web conferences at meet.jit.si from a third-party client, but this is not working anymore (the client does not longer get any session-initiate after the login).

Does anybody know if the configuration behind meet.jit.si has changed recently?


#2

Yes. Try using meet.jit.si:5222 for XMPP server and conference.meet.jit.si for the MUC service.

By the way, if you don't mind sharing, it would be interesting to hear about your use-case: which client do you use to connect, what are your reasons for using it, have you encountered any (other) problems?

Boris

···

On 04/09/15 01:10, info@linux-projects.org wrote:

Hi,

I used to connect to lambada.jit.si:5222 (XMPP server) with
"meet.jit.si" set as MUC to join public web conferences at meet.jit.si
from a third-party client, but this is not working anymore (the client
does not longer get any session-initiate after the login).

Does anybody know if the configuration behind meet.jit.si has changed
recently?


#3

Hi Boris,

thanks for answering.

I did try the new configuration meet.jit.si:5222/conference.meet.jit.si ( taken from http://meet.jit.si/config.js ), but it does not work for me. I get DNS errors and a quick nmap meet.jit.si shows filtered ports only. To work around this, until few days ago I had to use lambada.jitsi.net as XMPP server and "meet.jit.si" as MUC service. As a side note, I have no problems with the other "meet.jitsi.org" service (although the deployed version of Jitsi Meet seems to be old there, if I am not wrong), or with "beta.meet.jit.si".

I am using the UV4L client. Some days ago I sent an email announcing it:

http://www.linux-projects.org/modules/sections/index.php?op=viewarticle&artid=16#example16

It's a native client for the Raspberry Pi to broadcast audio&video to all the participants of a room (which does not require any browser), implementing all the XEP's required to communicate with the Jitsi Meet service.

I'll be glad to report any problems (there is one about the beta.meet.jit.si especially). For now I'd really like to understand what's happening with meet.jit.si.

If you have any question, please ask.

Thanks for your help.

···

On 04/09/2015 13:46, Boris Grozev wrote:

On 04/09/15 01:10, info@linux-projects.org wrote:

Hi,

I used to connect to lambada.jit.si:5222 (XMPP server) with
"meet.jit.si" set as MUC to join public web conferences at meet.jit.si
from a third-party client, but this is not working anymore (the client
does not longer get any session-initiate after the login).

Does anybody know if the configuration behind meet.jit.si has changed
recently?

Yes. Try using meet.jit.si:5222 for XMPP server and conference.meet.jit.si for the MUC service.

By the way, if you don't mind sharing, it would be interesting to hear about your use-case: which client do you use to connect, what are your reasons for using it, have you encountered any (other) problems?

Boris


#4

Hi Boris,

thanks for answering.

I did try the new configuration meet.jit.si:5222/conference.meet.jit.si
( taken from http://meet.jit.si/config.js ), but it does not work for
me. I get DNS errors and a quick nmap meet.jit.si shows filtered ports
only. To work around this, until few days ago I had to use
lambada.jitsi.net as XMPP server and "meet.jit.si" as MUC service. As a
side note, I have no problems with the other "meet.jitsi.org" service
(although the deployed version of Jitsi Meet seems to be old there, if I
am not wrong), or with "beta.meet.jit.si".

OK, it seems that port 5222 is now filtered, since we don't use it. Can you easily setup your client to use BOSH on https://meet.jit.si/http-bind?

I am using the UV4L client. Some days ago I sent an email announcing it:

http://www.linux-projects.org/modules/sections/index.php?op=viewarticle&artid=16#example16

It's a native client for the Raspberry Pi to broadcast audio&video to
all the participants of a room (which does not require any browser),
implementing all the XEP's required to communicate with the Jitsi Meet
service.

That's really awesome!

I'll be glad to report any problems (there is one about the
beta.meet.jit.si especially). For now I'd really like to understand
what's happening with meet.jit.si.

Beta.meet.jit.si is always running the latest code, so if there are problems there, they will probably eventually propagate to meet.jit.si as well.

Regards,
Boris

···

On 04/09/15 08:14, info wrote:


#5

Dear Jitsi Users, We would like to acknowledge that we have received your request and a ticket has been created. A support representative will be reviewing your request and will send you a personal response.(usually within 24 hours). To view the status of the ticket or add comments, please visit https://networklab.freshdesk.com/helpdesk/tickets/24 Thank you for your patience. Sincerely, NetworkLab Support Team


#6

Hi Boris,

unfortunately, it would require some extra effort to implement the new BOSH protocol used for signaling (XEP-0206 I suppose). At this point, I am not sure if or when this will happen.

Could you please tell me if you guys are not going to open the XMPP ports at meet.jit.si? In which case, I am afraid I'll have to remove meet.jit.si as default service from the web user interface for the time being.

I'll send a separate post for the issue I am observing with beta.meet.jit.si.

Thanks for you help.

Boris Grozev wrote:

···

On 04/09/15 08:14, info wrote:

Hi Boris,

thanks for answering.

I did try the new configuration meet.jit.si:5222/conference.meet.jit.si
( taken from http://meet.jit.si/config.js ), but it does not work for
me. I get DNS errors and a quick nmap meet.jit.si shows filtered ports
only. To work around this, until few days ago I had to use
lambada.jitsi.net as XMPP server and "meet.jit.si" as MUC service. As a
side note, I have no problems with the other "meet.jitsi.org" service
(although the deployed version of Jitsi Meet seems to be old there, if I
am not wrong), or with "beta.meet.jit.si".

OK, it seems that port 5222 is now filtered, since we don't use it. Can
you easily setup your client to use BOSH on https://meet.jit.si/http-bind?

I am using the UV4L client. Some days ago I sent an email announcing it:

http://www.linux-projects.org/modules/sections/index.php?op=viewarticle&artid=16#example16

It's a native client for the Raspberry Pi to broadcast audio&video to
all the participants of a room (which does not require any browser),
implementing all the XEP's required to communicate with the Jitsi Meet
service.

That's really awesome!

I'll be glad to report any problems (there is one about the
beta.meet.jit.si especially). For now I'd really like to understand
what's happening with meet.jit.si.

Beta.meet.jit.si is always running the latest code, so if there are
problems there, they will probably eventually propagate to meet.jit.si
as well.

Regards,
Boris


#7

Hey there,

Would you mind sharing the library you are currently using?

We haven't really used non-bosh xmpp, so it was only an accodent that it
was open before.

We'd have to think about whether or not this could be a concern. Let us
give it a thought.

Emil

···

On Friday, September 4, 2015, info@linux-projects.org < info@linux-projects.org> wrote:

Hi Boris,

unfortunately, it would require some extra effort to implement the new
BOSH protocol used for signaling (XEP-0206 I suppose). At this point, I am
not sure if or when this will happen.

Could you please tell me if you guys are not going to open the XMPP ports
at meet.jit.si? In which case, I am afraid I'll have to remove meet.jit.si
as default service from the web user interface for the time being.

I'll send a separate post for the issue I am observing with
beta.meet.jit.si.

Thanks for you help.

Boris Grozev wrote:

On 04/09/15 08:14, info wrote:

Hi Boris,

thanks for answering.

I did try the new configuration meet.jit.si:5222/conference.meet.jit.si
( taken from http://meet.jit.si/config.js ), but it does not work for
me. I get DNS errors and a quick nmap meet.jit.si shows filtered ports
only. To work around this, until few days ago I had to use
lambada.jitsi.net as XMPP server and "meet.jit.si" as MUC service. As a
side note, I have no problems with the other "meet.jitsi.org" service
(although the deployed version of Jitsi Meet seems to be old there, if I
am not wrong), or with "beta.meet.jit.si".

OK, it seems that port 5222 is now filtered, since we don't use it. Can
you easily setup your client to use BOSH on https://meet.jit.si/http-bind
?

I am using the UV4L client. Some days ago I sent an email announcing it:

http://www.linux-projects.org/modules/sections/index.php?op=viewarticle&artid=16#example16

It's a native client for the Raspberry Pi to broadcast audio&video to
all the participants of a room (which does not require any browser),
implementing all the XEP's required to communicate with the Jitsi Meet
service.

That's really awesome!

I'll be glad to report any problems (there is one about the
beta.meet.jit.si especially). For now I'd really like to understand
what's happening with meet.jit.si.

Beta.meet.jit.si is always running the latest code, so if there are
problems there, they will probably eventually propagate to meet.jit.si
as well.

Regards,
Boris

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

--
sent from my mobile


#8

Hi Emil,

the XMPP module/daemon used to communicate with the Jitsi Meet service is open source:

http://www.linux-projects.org/modules/mydownloads/visit.php?cid=10&lid=64

while UV4L itself is closed source (but free).

Let me know if you need more informations.

Emil Ivov wrote:

···

Hey there,

Would you mind sharing the library you are currently using?

We haven't really used non-bosh xmpp, so it was only an accodent that it
was open before.

We'd have to think about whether or not this could be a concern. Let us
give it a thought.

Emil

On Friday, September 4, 2015, info@linux-projects.org > <mailto:info@linux-projects.org> <info@linux-projects.org > <mailto:info@linux-projects.org>> wrote:

    Hi Boris,

    unfortunately, it would require some extra effort to implement the
    new BOSH protocol used for signaling (XEP-0206 I suppose). At this
    point, I am not sure if or when this will happen.

    Could you please tell me if you guys are not going to open the XMPP
    ports at meet.jit.si <http://meet.jit.si>? In which case, I am
    afraid I'll have to remove meet.jit.si <http://meet.jit.si> as
    default service from the web user interface for the time being.

    I'll send a separate post for the issue I am observing with
    beta.meet.jit.si <http://beta.meet.jit.si>.

    Thanks for you help.

    Boris Grozev wrote:

        On 04/09/15 08:14, info wrote:

            Hi Boris,

            thanks for answering.

            I did try the new configuration
            meet.jit.si:5222/conference.meet.jit.si
            <http://meet.jit.si:5222/conference.meet.jit.si>
            ( taken from http://meet.jit.si/config.js ), but it does not
            work for
            me. I get DNS errors and a quick nmap meet.jit.si
            <http://meet.jit.si> shows filtered ports
            only. To work around this, until few days ago I had to use
            lambada.jitsi.net <http://lambada.jitsi.net> as XMPP server
            and "meet.jit.si <http://meet.jit.si>" as MUC service. As a
            side note, I have no problems with the other "meet.jitsi.org
            <http://meet.jitsi.org>" service
            (although the deployed version of Jitsi Meet seems to be old
            there, if I
            am not wrong), or with "beta.meet.jit.si
            <http://beta.meet.jit.si>".

        OK, it seems that port 5222 is now filtered, since we don't use
        it. Can
        you easily setup your client to use BOSH on
        https://meet.jit.si/http-bind?

            I am using the UV4L client. Some days ago I sent an email
            announcing it:

            http://www.linux-projects.org/modules/sections/index.php?op=viewarticle&artid=16#example16

            It's a native client for the Raspberry Pi to broadcast
            audio&video to
            all the participants of a room (which does not require any
            browser),
            implementing all the XEP's required to communicate with the
            Jitsi Meet
            service.

        That's really awesome!

            I'll be glad to report any problems (there is one about the
            beta.meet.jit.si <http://beta.meet.jit.si> especially). For
            now I'd really like to understand
            what's happening with meet.jit.si <http://meet.jit.si>.

        Beta.meet.jit.si <http://Beta.meet.jit.si> is always running the
        latest code, so if there are
        problems there, they will probably eventually propagate to
        meet.jit.si <http://meet.jit.si>
        as well.

        Regards,
        Boris

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

--
sent from my mobile


#9

OK, so it's something you designed explicitly for this app? You are
not using an existing XMPP library?

I was hoping we could look around for bosh support for that lib but if
you did your own then ... yeah ... i guess we'd be out of luck.

Emil

···

On Fri, Sep 4, 2015 at 12:53 PM, info@linux-projects.org <info@linux-projects.org> wrote:

Hi Emil,

the XMPP module/daemon used to communicate with the Jitsi Meet service is
open source:

http://www.linux-projects.org/modules/mydownloads/visit.php?cid=10&lid=64

while UV4L itself is closed source (but free).

Let me know if you need more informations.

Emil Ivov wrote:

Hey there,

Would you mind sharing the library you are currently using?

We haven't really used non-bosh xmpp, so it was only an accodent that it
was open before.

We'd have to think about whether or not this could be a concern. Let us
give it a thought.

Emil

On Friday, September 4, 2015, info@linux-projects.org >> <mailto:info@linux-projects.org> <info@linux-projects.org >> <mailto:info@linux-projects.org>> wrote:

    Hi Boris,

    unfortunately, it would require some extra effort to implement the
    new BOSH protocol used for signaling (XEP-0206 I suppose). At this
    point, I am not sure if or when this will happen.

    Could you please tell me if you guys are not going to open the XMPP
    ports at meet.jit.si <http://meet.jit.si>? In which case, I am
    afraid I'll have to remove meet.jit.si <http://meet.jit.si> as
    default service from the web user interface for the time being.

    I'll send a separate post for the issue I am observing with
    beta.meet.jit.si <http://beta.meet.jit.si>.

    Thanks for you help.

    Boris Grozev wrote:

        On 04/09/15 08:14, info wrote:

            Hi Boris,

            thanks for answering.

            I did try the new configuration
            meet.jit.si:5222/conference.meet.jit.si
            <http://meet.jit.si:5222/conference.meet.jit.si>
            ( taken from http://meet.jit.si/config.js ), but it does not
            work for
            me. I get DNS errors and a quick nmap meet.jit.si
            <http://meet.jit.si> shows filtered ports
            only. To work around this, until few days ago I had to use
            lambada.jitsi.net <http://lambada.jitsi.net> as XMPP server
            and "meet.jit.si <http://meet.jit.si>" as MUC service. As a
            side note, I have no problems with the other "meet.jitsi.org
            <http://meet.jitsi.org>" service
            (although the deployed version of Jitsi Meet seems to be old
            there, if I
            am not wrong), or with "beta.meet.jit.si
            <http://beta.meet.jit.si>".

        OK, it seems that port 5222 is now filtered, since we don't use
        it. Can
        you easily setup your client to use BOSH on
        https://meet.jit.si/http-bind?

            I am using the UV4L client. Some days ago I sent an email
            announcing it:

http://www.linux-projects.org/modules/sections/index.php?op=viewarticle&artid=16#example16

            It's a native client for the Raspberry Pi to broadcast
            audio&video to
            all the participants of a room (which does not require any
            browser),
            implementing all the XEP's required to communicate with the
            Jitsi Meet
            service.

        That's really awesome!

            I'll be glad to report any problems (there is one about the
            beta.meet.jit.si <http://beta.meet.jit.si> especially). For
            now I'd really like to understand
            what's happening with meet.jit.si <http://meet.jit.si>.

        Beta.meet.jit.si <http://Beta.meet.jit.si> is always running the
        latest code, so if there are
        problems there, they will probably eventually propagate to
        meet.jit.si <http://meet.jit.si>
        as well.

        Regards,
        Boris

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

--
sent from my mobile

--
https://jitsi.org


#10

Hi Emil,

here is the XMPP library:

https://camaya.net/gloox/

not specific to any application. BOSH can be added there then?

The simple daemon I am using makes use of that XMPP library and is not really specific to any application either.

Let me know if you need other informations.

Thanks

Emil Ivov wrote:

···

OK, so it's something you designed explicitly for this app? You are
not using an existing XMPP library?

I was hoping we could look around for bosh support for that lib but if
you did your own then ... yeah ... i guess we'd be out of luck.

Emil

On Fri, Sep 4, 2015 at 12:53 PM, info@linux-projects.org > <info@linux-projects.org> wrote:

Hi Emil,

the XMPP module/daemon used to communicate with the Jitsi Meet service is
open source:

http://www.linux-projects.org/modules/mydownloads/visit.php?cid=10&lid=64

while UV4L itself is closed source (but free).

Let me know if you need more informations.

Emil Ivov wrote:

Hey there,

Would you mind sharing the library you are currently using?

We haven't really used non-bosh xmpp, so it was only an accodent that it
was open before.

We'd have to think about whether or not this could be a concern. Let us
give it a thought.

Emil

On Friday, September 4, 2015, info@linux-projects.org >>> <mailto:info@linux-projects.org> <info@linux-projects.org >>> <mailto:info@linux-projects.org>> wrote:

     Hi Boris,

     unfortunately, it would require some extra effort to implement the
     new BOSH protocol used for signaling (XEP-0206 I suppose). At this
     point, I am not sure if or when this will happen.

     Could you please tell me if you guys are not going to open the XMPP
     ports at meet.jit.si <http://meet.jit.si>? In which case, I am
     afraid I'll have to remove meet.jit.si <http://meet.jit.si> as
     default service from the web user interface for the time being.

     I'll send a separate post for the issue I am observing with
     beta.meet.jit.si <http://beta.meet.jit.si>.

     Thanks for you help.

     Boris Grozev wrote:

         On 04/09/15 08:14, info wrote:

             Hi Boris,

             thanks for answering.

             I did try the new configuration
             meet.jit.si:5222/conference.meet.jit.si
             <http://meet.jit.si:5222/conference.meet.jit.si>
             ( taken from http://meet.jit.si/config.js ), but it does not
             work for
             me. I get DNS errors and a quick nmap meet.jit.si
             <http://meet.jit.si> shows filtered ports
             only. To work around this, until few days ago I had to use
             lambada.jitsi.net <http://lambada.jitsi.net> as XMPP server
             and "meet.jit.si <http://meet.jit.si>" as MUC service. As a
             side note, I have no problems with the other "meet.jitsi.org
             <http://meet.jitsi.org>" service
             (although the deployed version of Jitsi Meet seems to be old
             there, if I
             am not wrong), or with "beta.meet.jit.si
             <http://beta.meet.jit.si>".

         OK, it seems that port 5222 is now filtered, since we don't use
         it. Can
         you easily setup your client to use BOSH on
         https://meet.jit.si/http-bind?

             I am using the UV4L client. Some days ago I sent an email
             announcing it:

http://www.linux-projects.org/modules/sections/index.php?op=viewarticle&artid=16#example16

             It's a native client for the Raspberry Pi to broadcast
             audio&video to
             all the participants of a room (which does not require any
             browser),
             implementing all the XEP's required to communicate with the
             Jitsi Meet
             service.

         That's really awesome!

             I'll be glad to report any problems (there is one about the
             beta.meet.jit.si <http://beta.meet.jit.si> especially). For
             now I'd really like to understand
             what's happening with meet.jit.si <http://meet.jit.si>.

         Beta.meet.jit.si <http://Beta.meet.jit.si> is always running the
         latest code, so if there are
         problems there, they will probably eventually propagate to
         meet.jit.si <http://meet.jit.si>
         as well.

         Regards,
         Boris

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

--
sent from my mobile


#11

Looks like it can do BOSH:
https://camaya.net/api/gloox-1.0.14/classgloox_1_1ConnectionBOSH.html

Boris

···

On 04/09/15 14:44, info@linux-projects.org wrote:

Hi Emil,

here is the XMPP library:

https://camaya.net/gloox/


#12

Hi guys,

there are two issues I am observing and trying to solve:

1. meet.jit.si does not seem to promptly react to muc/room leaving messages sent from my native client. In many cases this result in a pending session, where the client can be still seen in the room with other participants (e.g. chrome users), also after a complete disconnection. When this happens a new join with the same name is not possible for about 60s, until the participant is effectively disconnected/kicked out by the service. Are you aware of any such problems with the MUC protocol and/or the BOSH connection?

2. How can I make the videobridge stop sending the streams from other participants? I tried to set "a=recvonly" in my SDP answer, but does not seem to have any effect (stopping the streams from within the client is another matter). Should I use xep-0340 to set the direction of the streams?

thanks for your help

Boris Grozev wrote:

···

On 04/09/15 14:44, info@linux-projects.org wrote:

Hi Emil,

here is the XMPP library:

https://camaya.net/gloox/

Looks like it can do BOSH:
https://camaya.net/api/gloox-1.0.14/classgloox_1_1ConnectionBOSH.html

Boris


#13

info@linux-projects.org wrote:

2. How can I make the videobridge stop sending the streams from other
participants? I tried to set "a=recvonly" in my SDP answer

I meant to say "a=sendonly".


#14

Hi guys,

there are two issues I am observing and trying to solve:

1. meet.jit.si does not seem to promptly react to muc/room leaving
messages sent from my native client. In many cases this result in a
pending session, where the client can be still seen in the room with
other participants (e.g. chrome users), also after a complete
disconnection. When this happens a new join with the same name is not
possible for about 60s, until the participant is effectively
disconnected/kicked out by the service. Are you aware of any such
problems with the MUC protocol and/or the BOSH connection?

I don't know of any such problems.

2. How can I make the videobridge stop sending the streams from other
participants? I tried to set "a=recvonly" in my SDP answer, but does not
seem to have any effect (stopping the streams from within the client is
another matter). Should I use xep-0340 to set the direction of the streams?

Currently you won't be able to achieve this without modifications to some of the server components (so it won't work on meet.jit.si).

You can do this with xep-0340, but you will need to modify jicofo (which talks xep-0340 with the bridge). What you want is to set the "direction" attribute of the channel for your client to "recvonly" (the direction is from the bridge's perspective).

Regards,
Boris

···

On 05/09/15 17:43, info@linux-projects.org wrote:


#15

Boris Grozev wrote:

I don't know of any such problems.

Ok, I'll investigate further then...

2. How can I make the videobridge stop sending the streams from other
participants? I tried to set "a=recvonly" in my SDP answer, but does not
seem to have any effect (stopping the streams from within the client is
another matter). Should I use xep-0340 to set the direction of the
streams?

Currently you won't be able to achieve this without modifications to
some of the server components (so it won't work on meet.jit.si).

What a pity, it would save some bandwidth. Would it be possible for you guys to implement the required modifications for meet.jit.si?


#16

I think send-only endpoints is something we'd like to support in one way or another. But I don't know when someone will work on it.

Regards,
Boris

···

On 06/09/15 10:44, info@linux-projects.org wrote:

Boris Grozev wrote:

I don't know of any such problems.

Ok, I'll investigate further then...

2. How can I make the videobridge stop sending the streams from other
participants? I tried to set "a=recvonly" in my SDP answer, but does not
seem to have any effect (stopping the streams from within the client is
another matter). Should I use xep-0340 to set the direction of the
streams?

Currently you won't be able to achieve this without modifications to
some of the server components (so it won't work on meet.jit.si).

What a pity, it would save some bandwidth. Would it be possible for you
guys to implement the required modifications for meet.jit.si?