[jitsi-dev] Start video bridge in debug mode?


#1

Hi,

Is it possible to start the Jitsi video bridge in debug mode to make it
more verbose? I'm trying to send colibri messages and get back a
bad-request error from the bridge, but can't figure out the exact problem.

Thanks,
Andreas


#2

Hello,

···

On 08/04/14 13:21, Andreas Granig wrote:

Hi,

Is it possible to start the Jitsi video bridge in debug mode to make it
more verbose? I'm trying to send colibri messages and get back a
bad-request error from the bridge, but can't figure out the exact problem.

Currently there is no way to make the videobridge logs more verbose, but
received and sent XMPP messages are logged by default (look for 'RECV'
or 'SENT'). A bad-request error likely comes from the XMPP server and
not from the videobridge.

Regards,
Boris


#3

Hi Boris,

···

On 04/08/2014 01:46 PM, Boris Grozev wrote:

Is it possible to start the Jitsi video bridge in debug mode to make it
more verbose? I'm trying to send colibri messages and get back a
bad-request error from the bridge, but can't figure out the exact problem.

Currently there is no way to make the videobridge logs more verbose, but
received and sent XMPP messages are logged by default (look for 'RECV'
or 'SENT'). A bad-request error likely comes from the XMPP server and
not from the videobridge.

Hm. My videobridge seems to register successfully with my prosody, and
when sending a colibri request, prosody logs this:

c2s1e4eee0: Received[c2s]: <iq id='ad3988d327d9cf7e3f90409ce20272fb.0'
type='set' to='jitsi-videobridge.example.org' from='testuser2@example.org'>
jcp1250d00: Received[component]: <iq id='ad3988d327d9cf7e3f90409ce20272fb.0' type='error' to='testuser2@example.org/videobridge' from='jitsi-videobridge.example.org'>

The XMPP request I try to send is this (taken more or less from the
XEP-340 examples, and I tried to modify it to use raw-udp as there was
no example in the XEP for that case), maybe/likely there is something
wrong with it which I can't spot on my own:

<iq from='testuser2@example.org' id='ad3988d327d9cf7e3f90409ce20272fb.0'
to='jitsi-videobridge.example.org' type='set'>
<conference>
  <content name='audio'>
    <channel rtp-level-relay-type='mixer' initiator='true'>
      <payload-type id='96' name='opus' clockrate='48000' channels='2'/>
      <transport xmlns='urn:xmpp:jingle:transports:raw-udp:1'>
        <candidate component='1' generation='0'
id='ad3988d327d9cf7e3f90409ce20272fb.0' ip='92.42.136.48' port='30672'/>
      </transport>
    </channel>
  </content>
  <content name='video'>
    <channel initiator='true'>
      <payload-type id='105' name='VP8' clockrate='90000'/>
      <transport xmlns='urn:xmpp:jingle:transports:raw-udp:1'>
        <candidate component='1' generation='0'
id='ad3988d327d9cf7e3f90409ce20272fb.1' ip='92.42.136.48' port='30676'/>
      </transport>
    </channel>
  </content>
</conference>
</iq>

My video bridge doesn't log anything at all, so it really doesn't
receive anything, but the prosody log says it gets something from the
component?

My prosody in question question is straight forward, just this:

Component "jitsi-videobridge.example.org"
        component_secret = "mysecretpass"

Andreas


#4

Hello,

Hi Boris,

Is it possible to start the Jitsi video bridge in debug mode to make it
more verbose? I'm trying to send colibri messages and get back a
bad-request error from the bridge, but can't figure out the exact problem.

Currently there is no way to make the videobridge logs more verbose, but
received and sent XMPP messages are logged by default (look for 'RECV'
or 'SENT'). A bad-request error likely comes from the XMPP server and
not from the videobridge.

Hm. My videobridge seems to register successfully with my prosody, and
when sending a colibri request, prosody logs this:

c2s1e4eee0: Received[c2s]: <iq id='ad3988d327d9cf7e3f90409ce20272fb.0'
type='set' to='jitsi-videobridge.example.org' from='testuser2@example.org'>
jcp1250d00: Received[component]: <iq
id='ad3988d327d9cf7e3f90409ce20272fb.0' type='error'
to='testuser2@example.org/videobridge' from='jitsi-videobridge.example.org'>

The XMPP request I try to send is this (taken more or less from the
XEP-340 examples, and I tried to modify it to use raw-udp as there was
no example in the XEP for that case), maybe/likely there is something
wrong with it which I can't spot on my own:

<iq from='testuser2@example.org' id='ad3988d327d9cf7e3f90409ce20272fb.0'
to='jitsi-videobridge.example.org' type='set'>
<conference>

Looks like the NS is missing here.

  <content name='audio'>
    <channel rtp-level-relay-type='mixer' initiator='true'>
      <payload-type id='96' name='opus' clockrate='48000' channels='2'/>
      <transport xmlns='urn:xmpp:jingle:transports:raw-udp:1'>
        <candidate component='1' generation='0'
id='ad3988d327d9cf7e3f90409ce20272fb.0' ip='92.42.136.48' port='30672'/>
      </transport>
    </channel>
  </content>
  <content name='video'>
    <channel initiator='true'>
      <payload-type id='105' name='VP8' clockrate='90000'/>
      <transport xmlns='urn:xmpp:jingle:transports:raw-udp:1'>
        <candidate component='1' generation='0'
id='ad3988d327d9cf7e3f90409ce20272fb.1' ip='92.42.136.48' port='30676'/>
      </transport>
    </channel>
  </content>
</conference>
</iq>

My video bridge doesn't log anything at all, so it really doesn't
receive anything, but the prosody log says it gets something from the
component?

That's weird. Looking at the code, it should log every time it receives
something -- either a "RECV" or an exception.

Regards,
Boris

···

On 08/04/14 15:23, Andreas Granig wrote:

On 04/08/2014 01:46 PM, Boris Grozev wrote:


#5

I'd also love to have a debug option for videobridge to see what's
happening behind the scenes.
Is there an option to have all that console info logged to file besides
piping?

Also, off topic but no one has answered so far so maybe you guys can help
me out. I'm seeing a lot of failed video/media streams in jitmeet when
cilent browsers connect from behind corporate firewalls.
This is likely their fw policy blocking udp and/or only opening up specific
ports. Anyone have any good tips on how to workaround that problem? I guess
we could have restund only relay on standard ports like 80 or 443, but that
obviously isn't really feasible considering the number of ports needed, so
I'm hoping someone has some tips or workarounds.

Thanks

···

On Tue, Apr 8, 2014 at 2:50 PM, Boris Grozev <boris@jitsi.org> wrote:

Hello,

On 08/04/14 15:23, Andreas Granig wrote:
> Hi Boris,
>
> On 04/08/2014 01:46 PM, Boris Grozev wrote:
>>> Is it possible to start the Jitsi video bridge in debug mode to make it
>>> more verbose? I'm trying to send colibri messages and get back a
>>> bad-request error from the bridge, but can't figure out the exact
problem.
>>
>> Currently there is no way to make the videobridge logs more verbose, but
>> received and sent XMPP messages are logged by default (look for 'RECV'
>> or 'SENT'). A bad-request error likely comes from the XMPP server and
>> not from the videobridge.
>
> Hm. My videobridge seems to register successfully with my prosody, and
> when sending a colibri request, prosody logs this:
>
> c2s1e4eee0: Received[c2s]: <iq id='ad3988d327d9cf7e3f90409ce20272fb.0'
> type='set' to='jitsi-videobridge.example.org' from='
testuser2@example.org'>
> jcp1250d00: Received[component]: <iq
> id='ad3988d327d9cf7e3f90409ce20272fb.0' type='error'
> to='testuser2@example.org/videobridge' from='
jitsi-videobridge.example.org'>
>
> The XMPP request I try to send is this (taken more or less from the
> XEP-340 examples, and I tried to modify it to use raw-udp as there was
> no example in the XEP for that case), maybe/likely there is something
> wrong with it which I can't spot on my own:
>
>
> <iq from='testuser2@example.org' id='ad3988d327d9cf7e3f90409ce20272fb.0'
> to='jitsi-videobridge.example.org' type='set'>
> <conference>

Looks like the NS is missing here.

> <content name='audio'>
> <channel rtp-level-relay-type='mixer' initiator='true'>
> <payload-type id='96' name='opus' clockrate='48000' channels='2'/>
> <transport xmlns='urn:xmpp:jingle:transports:raw-udp:1'>
> <candidate component='1' generation='0'
> id='ad3988d327d9cf7e3f90409ce20272fb.0' ip='92.42.136.48' port='30672'/>
> </transport>
> </channel>
> </content>
> <content name='video'>
> <channel initiator='true'>
> <payload-type id='105' name='VP8' clockrate='90000'/>
> <transport xmlns='urn:xmpp:jingle:transports:raw-udp:1'>
> <candidate component='1' generation='0'
> id='ad3988d327d9cf7e3f90409ce20272fb.1' ip='92.42.136.48' port='30676'/>
> </transport>
> </channel>
> </content>
> </conference>
> </iq>
>
> My video bridge doesn't log anything at all, so it really doesn't
> receive anything, but the prosody log says it gets something from the
> component?

That's weird. Looking at the code, it should log every time it receives
something -- either a "RECV" or an exception.

Regards,
Boris

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


#6

Hi Boris,

<iq from='testuser2@example.org' id='ad3988d327d9cf7e3f90409ce20272fb.0'
to='jitsi-videobridge.example.org' type='set'>
<conference>

Looks like the NS is missing here.

That actually did the trick!

My video bridge doesn't log anything at all, so it really doesn't
receive anything, but the prosody log says it gets something from the
component?

That's weird. Looking at the code, it should log every time it receives
something -- either a "RECV" or an exception.

Now since I've added the NS to the conference element, the videobridge
indeed logs the RECV. Leaving the NS out keeps the videobridge silent.
System was a Debian Wheezy with the stock openjdk-1.7:

# java -version
java version "1.7.0_25"
OpenJDK Runtime Environment (IcedTea 2.3.10) (7u25-2.3.10-1~deb7u1)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)

And the bridge got started with the shell script provided by you guys:

# ./jvb.sh --secret=mysecret --domain=example.org --host=localhost

Hope that helps! Anyways, your hint helped me at least! :slight_smile:

Thanks again,
Andreas

···

On 04/08/2014 03:50 PM, Boris Grozev wrote: