jitsi / jitsi-videobridge

Jitsi Videobridge is a WebRTC compatible video router or SFU that lets build highly scalable video conferencing infrastructure (i.e., up to hundreds of conferences per server).

Intro

Jitsi Videobridge is a WebRTC-compatible Selective Forwarding Unit (SFU), i.e. a multimedia router. It is one of the backend components in the Jitsi Meet stack.

You can find more documentation in the doc/ directory in the source tree and in the Jitsi Meet Handbook.

If you have questions about the project, please post on the Jitsi Community Forum. GitHub issues are only used to track actionable items.

Packages

Debian/Ubuntu

You can download binary packages for Debian/Ubuntu:

• stable (instructions)
• testing (instructions)
• nightly (instructions)

Building your own package

You can build a custom package with just mvn install in the root directory of the repo. Look for the package in jvb/target/jitsi-videobridge-2.1-SNAPSHOT-archive.zip.

Running locally

You can run jitsi-videobridge locally with maven (or in your IDE). First create a ~/.jvb/jvb.conf to configure the environment to connect to and other options (see reference.conf for the available options).

JVB_HOME="/path/to/the/cloned/repo"
JVB_CONFIG_DIR_LOCATION="~/"
JVB_CONFIG_DIR_NAME=".jvb"
JVB_CONFIG_FILE="$JVB_CONFIG_DIR_LOCATION/$JVB_JVB_CONFIG_DIR_NAME/jvb.conf"

mvn compile exec:exec -Dexec.executable=java -Dexec.args="-cp %classpath org.jitsi.videobridge.MainKt -Djava.library.path=$JVB_HOME/lib/native/linux-64 -Djava.util.logging.config.file=$JVB_HOME/lib/logging.properties -Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=$JVB_CONFIG_DIR_LOCATION -Dnet.java.sip.communicator.SC_HOME_DIR_NAME=$JVB_CONFIG_DIR_NAME -Dconfig.file=$JVB_CONFIG_FILE"

Configuration

Application level configuration comes from a config file, usually installed in /etc/jitsi/videobridge/jvb.conf. The values in that file override the defaults defined in reference.conf.

Debian

On debian systems the /etc/jitsi/videobridge/config file can be used to set configuration for the Java virtual machine. Notable examples:

# Increase the java heap to 8GB
VIDEOBRIDGE_MAX_MEMORY=8192m
# Change the garbage collector (defaults to G1GC)
VIDEOBRIDGE_GC_TYPE=G1GC

jitsi-videobridge's Issues

No webcam user issue

Hi!

I'm experiencing weird issue. If user didn't send his own video (hasn't webcam for example), he doesn't see anyone else.
This will continue until someone of participants toggles his own video. After that user without webcam starts to see other participants. But not for a long time. After less than minute all video freeze. Could you please help me with this issue?

Thanks for help in advance.

Support address mapping for single-port UDP

Jitsi-VideoBridge proxy

Any way to make jitsi-videobridge scalable (means LB)

Add expire attrribute to <conference>

We should consider adding expire attribute to element, so that the whole conference can be expired immediately instead of having to wait for it to happend after few minutes. Currently Jicofo expires all alocated channels, but the conference stays for a while as there is no way to expire it.

Exceptions logged when the remote side closes the TCP socket

With TCP in use, when the remote side closes the socket we log an exception.

<iq type=result/> is not handled

It appears that pubsub stats are broken because is not handled.
SENT:

     <iq type="set" id="0YApC-0" from="bridge.host" to="host">
       <pubsub xmlns="http://jabber.org/protocol/pubsub">
         <create node="videobridge"/>
       </pubsub>
     </iq>

RECV:

<iq id="0YApC-0" type="result" to="bridge.host" from="stage-host"/>

08:16:58.204 SEVERE: [13]
org.jitsi.videobridge.stats.PubSubStatsTransport.publishStatistics().207
Failed to publish to PubSub node: videobridge

i've debugged it down to https://github.com/jitsi/jitsi-videobridge/blob/master/src/org/jitsi/videobridge/xmpp/ComponentImpl.java#L235 returning null but that is where my java skills end.

missing "from" in ping requests

hi,

i've many logs lines that look like

2015-10-28 14:30:57.447 SEVERE: [20] org.jitsi.xmpp.component.ComponentBase.run().401 Ping timeout for ID: irRLf-1056

a rapid tcp dump show me that the ping request look like

<iq.id="irRLf-1056" to="intranet.test" type="get"><ping.xmlns="urn:xmpp:ping"></ping></iq>

and openfire explode with:

 org.jivesoftware.openfire.spi.RoutingTableImpl - Primary packet routing failed
org.jivesoftware.openfire.PacketException: Cannot route packet of type IQ or Presence to bare JID: <iq type="result" id="irRLf-11" from="intranet.test"/> 

a quick look at
http://xmpp.org/extensions/xep-0199.html#c2s
show that "from" seems to be required (it's not written but there is no mention that it's optionnal, and all exemples have "from")

totally new to xmpp & jvb
i'm using

jitsi-videobridge-linux-x64-547.zip
openfire_3_10_2.tar.gz
centos 6 lxc (fedora 22 host)
java-1.8.0-openjdk (also tried 1.7)

org/eclipse/jetty/server/Connector : Unsupported major.minor version 51.0

Using --apis=rest, getting this error:

Caused by: java.lang.UnsupportedClassVersionError: org/eclipse/jetty/server/Connector : Unsupported major.minor version 51.0

java version "1.6.0_34"
OpenJDK Runtime Environment (IcedTea6 1.13.6) (6b34-1.13.6-1ubuntu0.12.04.1)
OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)

high packet loss reported when audio is silenced

I just noticed that chrome reports a high packet loss when sending audio that is physically muted.

Steps to reproduce:

1. go to meet.jit.si twice, have chrome://webrtc-externals open
2. use a headset or mic that can be physically muted -- @emcho's big mic might work.
3. check the ssrc_12345_send statistics for packetsLost -- should be close to zero
4. mute the mic
5. watch the packetsLost counter increase at almost the same rate as the packetsSent

Not sure what happens exactly. It doesn't happen in chrome when doing p2p.
Maybe the cumulative number of packets lost or the highest sequence number received is not properly updated in the RTCP RR. Or it is and chrome expects something else?

output to an icecast server

I'm not even sure where or how this could be implemented, however, I suspect people would find the feature useful.

The specific use-case I have in mind is a conference panel that involves some people in person and some remote participants - all connecting via the jitsi video bridge. It would be nice if the panel could also be broadcast out to a large audience via icecast (which can be chained and distributed in a way to more easily handle bandwidth and seems more appropriate for passive listeners than having them join the video bridge directly).

Currently, we can accomplish this by having one participant stream their desktop to icecast. However, that requires an experienced techie to manage.

Perhaps the video send to icecast could be the video of the currently talking person?

Is the video bridge the right place to implement this? Or should it be implemented in the jitsi client or jit-meet?

Thanks for all your work on jitsi video bridge.

Problem with setting "mixer" rtpLevelRelayType for RTPChannels

I think recent changes to Jitsi-videobridge introduced a small bug.

Constructor of RTPChannel performs this call even before the XML attributes of the channel are parsed:

https://github.com/jitsi/jitsi-videobridge/blob/master/src/org/jitsi/videobridge/RtpChannel.java#L205

 if (RTPLevelRelayType.MIXER.equals(getRTPLevelRelayType()))

As a result, getRTPLevelRelayType sets the type to a default, which is a "translator". When attributes of the channel's XML description are parsed later and the attribute rtp-level-relay-type="mixer" is discovered later in Videobridge.handleColibriConferenceIQ, the code tries to set the type to "mixer". But it does not work, because the logic in RtpChannel.setRTPLevelRelayType allows to set a type only if it is not set set or it is the same. Since each RTPChannel has now "translator" as an initially set type, it is impossible to set "mixer" at all, as far as I understand.

This seems to be a regression from previous versions of the video bridge. I guess it should be still possible to set a "mixer" mode during conference establishment.

Is it possible for users to have different channelLastN value when using Adaptive Last N?

I have tried giving each client a different channelLastN value in the config but it doesn't seem like it is working correctly. All users have adaptiveLastN set to true.

View is not sharp while screen-sharing

Hi,
We have a very nice view quality during video calls however while screen-sharing the view doesn't have the same quality and it is not sharp for some reason.

Is that expected? If not, how can we improve the image quality during scree-sharing?

Thanks.

sun.nio.ch.SelChImpl exception in build 445

Using the -445 build I get the following exception:

2015-04-07 19:07:24.245 INFO: [25] org.jitsi.videobridge.Videobridge.info() Created conference 7d18e3c5e73fae3e. The total number of conferences is now 1, channels 0, video streams 0.
2015-04-07 19:07:24.248 INFO: [25] org.jitsi.videobridge.Conference.info() Created content audio of conference 7d18e3c5e73fae3e. The total number of conferences is now 1, channels 0, video streams 0.
2015-04-07 19:07:24.681 INFO: [25] org.ice4j.ice.harvest.MultiplexingTcpHostHarvester.addLocalAddresses() Not using link-local address /fe80:0:0:0:be76:4eff:fe10:9e5e%4 for TCP candidates.
2015-04-07 19:07:24.681 INFO: [25] org.ice4j.ice.harvest.MultiplexingTcpHostHarvester.addLocalAddresses() Not using link-local address /fe80:0:0:0:be76:4eff:fe10:9a1c%3 for TCP candidates.
2015-04-07 19:07:24.681 INFO: [25] org.ice4j.ice.harvest.MultiplexingTcpHostHarvester.addLocalAddresses() Not using link-local address /fe80:0:0:0:be76:4eff:fe10:757b%2 for TCP candidates.
2015-04-07 19:07:24.683 SEVERE: [25] util.UtilActivator.uncaughtException().108 An uncaught exception occurred in thread=Thread[pool-2-thread-3,5,main] and message was: class org.ice4j.socket.DelegatingServerSocketChannel cannot access its superinterface sun.nio.ch.SelChImpl
java.lang.IllegalAccessError: class org.ice4j.socket.DelegatingServerSocketChannel cannot access its superinterface sun.nio.ch.SelChImpl
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
        at org.ice4j.ice.harvest.MultiplexingTcpHostHarvester.init(MultiplexingTcpHostHarvester.java:609)
        at org.ice4j.ice.harvest.MultiplexingTcpHostHarvester.<init>(MultiplexingTcpHostHarvester.java:247)
        at org.ice4j.ice.harvest.MultiplexingTcpHostHarvester.<init>(MultiplexingTcpHostHarvester.java:217)
        at org.ice4j.ice.harvest.MultiplexingTcpHostHarvester.<init>(MultiplexingTcpHostHarvester.java:198)
        at org.jitsi.videobridge.IceUdpTransportManager.initializeStaticHarvesters(IceUdpTransportManager.java:1732)
        at org.jitsi.videobridge.IceUdpTransportManager.appendVideobridgeHarvesters(IceUdpTransportManager.java:455)
        at org.jitsi.videobridge.IceUdpTransportManager.createIceAgent(IceUdpTransportManager.java:763)
        at org.jitsi.videobridge.IceUdpTransportManager.<init>(IceUdpTransportManager.java:335)
        at org.jitsi.videobridge.IceUdpTransportManager.<init>(IceUdpTransportManager.java:303)
        at org.jitsi.videobridge.Conference.getTransportManager(Conference.java:1139)
        at org.jitsi.videobridge.Channel.initialize(Channel.java:528)
        at org.jitsi.videobridge.RtpChannel.initialize(RtpChannel.java:876)
        at org.jitsi.videobridge.Content.createRtpChannel(Content.java:275)
        at org.jitsi.videobridge.Videobridge.handleColibriConferenceIQ(Videobridge.java:733)
        at org.jitsi.videobridge.Videobridge.handleColibriConferenceIQ(Videobridge.java:545)
        at org.jitsi.videobridge.xmpp.ComponentImpl.handleColibriConferenceIQ(ComponentImpl.java:209)
        at org.jitsi.videobridge.xmpp.ComponentImpl.handleIQRequest(ComponentImpl.java:380)
        at org.jitsi.videobridge.xmpp.ComponentImpl.handleIQ(ComponentImpl.java:311)
        at org.jitsi.videobridge.xmpp.ComponentImpl.handleIQ(ComponentImpl.java:263)
        at org.jitsi.videobridge.xmpp.ComponentImpl.handleIQSet(ComponentImpl.java:437)
        at org.xmpp.component.AbstractComponent.processIQRequest(AbstractComponent.java:515)
        at org.xmpp.component.AbstractComponent.processIQ(AbstractComponent.java:289)
        at org.xmpp.component.AbstractComponent.processQueuedPacket(AbstractComponent.java:239)
        at org.xmpp.component.AbstractComponent.access$100(AbstractComponent.java:81)
        at org.xmpp.component.AbstractComponent$PacketProcessor.run(AbstractComponent.java:1051)

-433 still works, happy bisecting

Turn server

Its not a Issue, its just a question..
Can i use my own turnserver?
If Yes, where can i conf this?

Temporary freeze

We observed a situation in which packets were being dropped for a couple of minutes, causing streams to timeout. Afterwards the bridge continued to work without apparent issues. We suspect that the problem somehow involves the TCP implementation. I have log files available if needed.

Update sigar

Update the sigar libraries

Simulcast support within Chrome/Firefox

Is simulcast currently supported within Chrome/Firefox? Is the implementation in the videobridge based on draft specifications?

Thanks

signaling ice failure

In jitsi-meet we have chrome is acting as the controlled agent in ice so it will never go into iceConnectionState = failed.

Can we signal this from the bridge to the focus somehow so the jingle session can be terminated with a connectivity-error?

Protocol-wise I would tend to add a iceconnectionstate attribute to the channel and then set that to failed. For meet this means we have to listen for all iq type=set... mh!

Need a README file

Could you include a readme file that explains how it all works? Port numbers, the software involved and how it relates to SIP or XMPP?

REST/XMPP interface parity

In reference to http://lists.jitsi.org/pipermail/dev/2015-May/024203.html, like Mihail, I was wondering when we might see REST patches to bring it up to speed with the XMPP interface.

Thanks so much!

Feature: REMB support

http://tools.ietf.org/html/draft-alvestrand-rmcat-remb-03

Question: WebRTC

Hi

I read something on jitsi that this videobridge can be used for webrtc.
And I wondered, how would my browser connect to the server.
Or how is it possible to use it with webrtc.

REST-API Timeout for PATCH in build 445

PATCH Method for HTTP gives a Timeout

conference creation fails under load due to port contention

Hello,

IceUdpTransportManager attempts to bind ports from a "tracked" starting value, in code that starts here:

https://github.com/jitsi/jitsi-videobridge/blob/master/src/main/java/org/jitsi/videobridge/IceUdpTransportManager.java#L724

The problem is that if multiple threads enter this code in parallel, all can start the search from the same value. Under sustained conference creation load, this ultimately leads to a bind failure, because there is an inner retry loop that fails after 50 attempts (it can be bumped to 100, but that 100 limit is hardcoded in NetworkAddressManagerServiceImpl.createIceStream). If the retry loop is unsuccessful, conference creation fails.

I can get a failure with a conference creation rate of 9/sec over 10 seconds on an EC2 m4.large instance.

Are there any plans to improve this port assignment code? We are experimenting with a synchronized block around the portTracker code mentioned above. That eliminates the errors, but results in a port assignment time that is a order of magnitude slower under load. We may consider using multiple port trackers or some kind of port free list, but we wanted to see if anyone else had run into this.

NPE when client tries to create a video bridge

I've just set up OpenFire and Jitsi Videobridge on a headless Arch installation. It's working perfectly for one to one VoIP and video, but trying to create a video bridge on one of my test clients causes a NPE. It looks like it's caused by a NoClassDefFoundError for java.awt.Toolkit, which is being loaded by java.awt.Dimension. This seems to imply that a desktop environment is required for the Videobridge, is that the case?

Here's the relevant section from the logs:

RECV: <iq id="woiC1-79" to="videobridge.jitsi.fritz.box" type="get" from="[email protected]/jitsi-3vkn7nm"><conference xmlns="http://jitsi.org/protocol/colibri"><content name="audio"><channel initiator="false"><payload-type id="96" name="opus" channels="2" clockrate="48000"><parameter name="usedtx" value="1"/></payload-type><payload-type id="97" name="SILK" channels="1" clockrate="24000"/><payload-type id="98" name="SILK" channels="1" clockrate="16000"/><payload-type id="9" name="G722" channels="1" clockrate="8000"/><payload-type id="100" name="speex" channels="1" clockrate="32000"/><payload-type id="102" name="speex" channels="1" clockrate="16000"/><payload-type id="0" name="PCMU" channels="1" clockrate="8000"/><payload-type id="8" name="PCMA" channels="1" clockrate="8000"/><payload-type id="103" name="iLBC" channels="1" clockrate="8000"/><payload-type id="3" name="GSM" channels="1" clockrate="8000"/><payload-type id="104" name="speex" channels="1" clockrate="8000"/><payload-type id="101" name="telephone-event" channels="1" clockrate="8000"/><transport xmlns="urn:xmpp:jingle:transports:ice-udp:1" ufrag="7c7jn" pwd="1dbedvusfsjkdeo6kjm15g6v9q"><candidate foundation="1" component="1" protocol="udp" priority="2130706431" generation="0" id="61" ip="192.168.1.125" port="5010" type="host" network="0"/><candidate foundation="2" component="1" protocol="udp" priority="2130706431" generation="0" id="62" ip="192.168.56.1" port="5010" type="host" network="0"/><candidate foundation="3" component="1" protocol="udp" priority="2113937151" generation="0" id="63" ip="fe80:0:0:0:c130:72aa:793b:bfa6" port="5010" type="host" network="0"/><candidate foundation="1" component="1" protocol="udp" priority="2113932031" generation="0" id="64" ip="192.168.1.125" port="63293" type="host" network="0"/><candidate foundation="4" component="1" protocol="udp" priority="1677724415" generation="0" id="65" ip="81.83.192.223" port="5010" type="srflx" rel-addr="192.168.1.125" rel-port="5010" network="0"/><candidate foundation="5" component="1" protocol="udp" priority="1677724415" generation="0" id="66" ip="192.168.0.212" port="63293" type="srflx" rel-addr="192.168.1.125" rel-port="63293" network="0"/><candidate foundation="1" component="2" protocol="udp" priority="2130706430" generation="0" id="67" ip="192.168.1.125" port="5011" type="host" network="0"/><candidate foundation="2" component="2" protocol="udp" priority="2130706430" generation="0" id="68" ip="192.168.56.1" port="5011" type="host" network="0"/><candidate foundation="3" component="2" protocol="udp" priority="2113937150" generation="0" id="69" ip="fe80:0:0:0:c130:72aa:793b:bfa6" port="5011" type="host" network="0"/><candidate foundation="1" component="2" protocol="udp" priority="2113932030" generation="0" id="70" ip="192.168.1.125" port="63294" type="host" network="0"/><candidate foundation="5" component="2" protocol="udp" priority="1677724414" generation="0" id="71" ip="192.168.0.212" port="63294" type="srflx" rel-addr="192.168.1.125" rel-port="63294" network="0"/><candidate foundation="4" component="2" protocol="udp" priority="1677724414" generation="0" id="72" ip="81.83.192.223" port="5011" type="srflx" rel-addr="192.168.1.125" rel-port="5011" network="0"/></transport></channel><channel initiator="true"><payload-type id="96" name="opus" channels="2" clockrate="48000"><parameter name="usedtx" value="1"/></payload-type><payload-type id="97" name="SILK" channels="1" clockrate="24000"/><payload-type id="98" name="SILK" channels="1" clockrate="16000"/><payload-type id="9" name="G722" channels="1" clockrate="8000"/><payload-type id="100" name="speex" channels="1" clockrate="32000"/><payload-type id="102" name="speex" channels="1" clockrate="16000"/><payload-type id="0" name="PCMU" channels="1" clockrate="8000"/><payload-type id="8" name="PCMA" channels="1" clockrate="8000"/><payload-type id="103" name="iLBC" channels="1" clockrate="8000"/><payload-type id="3" name="GSM" channels="1" clockrate="8000"/><payload-type id="104" name="speex" channels="1" clockrate="8000"/><payload-type id="101" name="telephone-event" channels="1" clockrate="8000"/><transport xmlns="urn:xmpp:jingle:transports:ice-udp:1"/></channel></content></conference></iq>
23:27:55.689 INFO: [21] org.jitsi.videobridge.Videobridge.info() Created conference 990e466165302d08. The total number of conferences is now 1, channels 0.
23:27:55.708 INFO: [21] org.jitsi.videobridge.Conference.info() Created content audio of conference 990e466165302d08. The total number of conferences is now 1, channels 0.
23:27:56.323 INFO: [21] org.jitsi.impl.libjitsi.LibJitsiImpl.info() Failed to initialize service implementation org.jitsi.impl.neomedia.MediaServiceImpl. Will continue without it.
java.lang.NoClassDefFoundError: Could not initialize class java.awt.Toolkit
        at java.awt.Dimension.<clinit>(Dimension.java:88)
        at org.jitsi.impl.neomedia.device.DeviceConfiguration.<clinit>(DeviceConfiguration.java:186)
        at org.jitsi.impl.neomedia.MediaServiceImpl.<init>(MediaServiceImpl.java:150)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
        at java.lang.Class.newInstance(Class.java:374)
        at org.jitsi.impl.libjitsi.LibJitsiImpl.getService(LibJitsiImpl.java:142)
        at org.jitsi.impl.libjitsi.LibJitsiOSGiImpl.getService(LibJitsiOSGiImpl.java:86)
        at org.jitsi.service.libjitsi.LibJitsi.invokeGetServiceOnImpl(LibJitsi.java:163)
        at org.jitsi.service.libjitsi.LibJitsi.getMediaService(LibJitsi.java:115)
        at org.jitsi.videobridge.Conference.getMediaService(Conference.java:710)
        at org.jitsi.videobridge.Content.getMediaService(Content.java:584)
        at org.jitsi.videobridge.RtpChannel.getMediaService(RtpChannel.java:749)
        at org.jitsi.videobridge.RtpChannel.<init>(RtpChannel.java:216)
        at org.jitsi.videobridge.AudioChannel.<init>(AudioChannel.java:35)
        at org.jitsi.videobridge.Content.createRtpChannel(Content.java:207)
        at org.jitsi.videobridge.Videobridge.handleColibriConferenceIQ(Videobridge.java:617)
        at org.jitsi.videobridge.Videobridge.handleColibriConferenceIQ(Videobridge.java:449)
        at org.jitsi.videobridge.xmpp.ComponentImpl.handleColibriConferenceIQ(ComponentImpl.java:204)
        at org.jitsi.videobridge.xmpp.ComponentImpl.handleIQRequest(ComponentImpl.java:350)
        at org.jitsi.videobridge.xmpp.ComponentImpl.handleIQ(ComponentImpl.java:281)
        at org.jitsi.videobridge.xmpp.ComponentImpl.handleIQ(ComponentImpl.java:233)
        at org.jitsi.videobridge.xmpp.ComponentImpl.handleIQGet(ComponentImpl.java:332)
        at org.xmpp.component.AbstractComponent.processIQRequest(AbstractComponent.java:511)
        at org.xmpp.component.AbstractComponent.processIQ(AbstractComponent.java:289)
        at org.xmpp.component.AbstractComponent.processQueuedPacket(AbstractComponent.java:239)
        at org.xmpp.component.AbstractComponent.access$100(AbstractComponent.java:81)
        at org.xmpp.component.AbstractComponent$PacketProcessor.run(AbstractComponent.java:1051)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)
23:27:57.853 INFO: [21] org.ice4j.ice.Agent.gatherCandidates() Gather candidates for component audio.RTP
23:27:57.905 INFO: [21] org.ice4j.ice.Agent.createComponent()   [fe80:0:0:0:a00:27ff:fe36:694a]:10000/udp (host)
23:27:57.910 INFO: [21] org.ice4j.ice.Agent.createComponent()   [fe80:0:0:0:268f:ea33:dba6:2f39]:10000/udp (host)
23:27:57.911 INFO: [21] org.ice4j.ice.Agent.createComponent()   192.168.1.145:10000/udp (host)
23:27:57.911 INFO: [21] org.ice4j.ice.Agent.gatherCandidates() Gather candidates for component audio.RTCP
23:27:57.923 INFO: [21] org.ice4j.ice.Agent.createComponent()   [fe80:0:0:0:a00:27ff:fe36:694a]:10001/udp (host)
23:27:57.926 INFO: [21] org.ice4j.ice.Agent.createComponent()   [fe80:0:0:0:268f:ea33:dba6:2f39]:10001/udp (host)
23:27:57.927 INFO: [21] org.ice4j.ice.Agent.createComponent()   192.168.1.145:10001/udp (host)
java.lang.NullPointerException
        at org.jitsi.videobridge.RtpChannel.<init>(RtpChannel.java:219)
        at org.jitsi.videobridge.AudioChannel.<init>(AudioChannel.java:35)
        at org.jitsi.videobridge.Content.createRtpChannel(Content.java:207)
        at org.jitsi.videobridge.Videobridge.handleColibriConferenceIQ(Videobridge.java:617)
        at org.jitsi.videobridge.Videobridge.handleColibriConferenceIQ(Videobridge.java:449)
        at org.jitsi.videobridge.xmpp.ComponentImpl.handleColibriConferenceIQ(ComponentImpl.java:204)
        at org.jitsi.videobridge.xmpp.ComponentImpl.handleIQRequest(ComponentImpl.java:350)
        at org.jitsi.videobridge.xmpp.ComponentImpl.handleIQ(ComponentImpl.java:281)
        at org.jitsi.videobridge.xmpp.ComponentImpl.handleIQ(ComponentImpl.java:233)
        at org.jitsi.videobridge.xmpp.ComponentImpl.handleIQGet(ComponentImpl.java:332)
        at org.xmpp.component.AbstractComponent.processIQRequest(AbstractComponent.java:511)
        at org.xmpp.component.AbstractComponent.processIQ(AbstractComponent.java:289)
        at org.xmpp.component.AbstractComponent.processQueuedPacket(AbstractComponent.java:239)
        at org.xmpp.component.AbstractComponent.access$100(AbstractComponent.java:81)
        at org.xmpp.component.AbstractComponent$PacketProcessor.run(AbstractComponent.java:1051)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)

Debian init script problem if /bin/sh is /bin/bash

Hi,
I installed Jitsi Meet with quick install method on Debian Jessie and init script for jitsi-videobridge does not work when /bin/sh is a symbolic link of /bin/bash:

~# ls -l /bin/sh
lrwxrwxrwx 1 root root 4 oct. 28 14:20 /bin/sh -> bash

~# /etc/init.d/jitsi-videobridge stop
Stopping jitsi-videobridge: /etc/init.d/jitsi-videobridge: ligne 37: PPID : readonly variable
zsh: exit 1 /etc/init.d/jitsi-videobridge stop

Maybe because PPID is an environnement variable ? Now with Dash :

~# ls -l /bin/sh
lrwxrwxrwx 1 root root 4 oct. 28 14:26 /bin/sh -> dash

~# /etc/init.d/jitsi-videobridge stop
Stopping jitsi-videobridge: jvb stopped.

To fix script for Bash i've replaced PPID with ppid : sed -i 's/PPID/ppid/g' /etc/init.d/jitsi-videobridge

The 'initiator' attribute is not supported for channel-bundles

Debian package

this software is really exiting. Any plans to do debian packaging ?

Feature: rtcp-mux

Having http://tools.ietf.org/html/rfc5761 implemented would reduce the number of ports and therefore ice sessions the bridge has to keep open.

After some discussion with Emil we think that it's part of in XMPP/Jingle, so we'd put it there in CoLiBri.

Install failed on ubuntu/debian

dpkg: error processing package jitsi-videobridge (--configure):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for libc-bin (2.19-0ubuntu6.3) ...
Processing triggers for ca-certificates (20130906ubuntu2) ...
Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d....
done.
done.
Errors were encountered while processing:
 jitsi-videobridge
E: Sub-process /usr/bin/dpkg returned an error code (1)

Having bother installing jitsi-videobridge on digitalocean ubuntu/debian while running the jitsi-meet package install. Is the latest package currently broken or am I doing something wrong?

Video disappearing immediately after starting

I am a new person to Jitsi, just gave it a try, and have an issue. I followed the standard install (on centos, however, but it went smoothly), and it works fine except the other person video is seen for a split second and then disappears.

Server is hosted in Azure and is behind the NAT but I configured it as instructed using the properties file. Audio works. jvb log says issues about caches being overflown and some connection errors although as I said, initially connection is OK and video works.

Firewall is off - both Linux and Azure.
Ports open: 80, 443, 4443, 5000-5002, 10000-10070 (TCP + UDP). Verified by making nginx listen on 10000 - works, also made iptables log incoming packets on all these ports - UDP and TCP works.

Tried both OpenJDK 1.7, 1.8 and SunJDK 1.8.

I saw similar reports but no clues yet.. Spent hours on this. Would really appreciate any pointers.

Client is Chrome, works fine with meet.jit.si.

BTW can you share the exact versions and config of meet.jit.si?

videobridge seems to ignore "a=sendonly" in sdp

Is there any way to make the videobridge honor the standard sdp 'a=sendonly' direction? I am interested in sending video /audio only and don't want to receive any media stream from the videobridge.

listen only mode

In a typical broadcast scenario where there are 2-3 publisher and hundreds of listener, how could videobridge be used. There is no documentation about connecting to jitmeet in listen/view only mode without publishing self stream

no audio/video in videobridge

I am having weird issue. Only chat is working among client in videobridge, there is no audio/video in conference. Only error I see is

Aug 24, 2014 6:06:26 PM net.java.sip.communicator.util.Logger info
INFO: Ignoring invalid port range [null to null]

in openfire logs

I am running openfire on window 2008
firewall is turned off. Also there is no udp traffic whatsoever

Why does the video bridge listen to port 443. I want to run nginx with SSL on that port

Hi,
I am currently recognizing that the video bridget listens to port 443. I don't want that. I want to run nginx there.

# start video bridge
./jvb.sh --host=localhost --domain=v.apaxo.de --port=5347 --secret=*****

# show ports
netstat -pantu
... (around 30 other servers shown prosody, jicofo, ssh etc.)
tcp        0      0 10.240.87.13:443        0.0.0.0:*               LISTEN      2525/java     
...

I will investigate why this is the case.

/Manuel

Preserving stream quality statistics

This is long. Sorry. Bear with me. Feel free to tell my, "you're wrong" about any part of this.

Background

We're rolling out a deployment of jitsi (awesome stuff!). We want to be able to troubleshoot audio/video quality problems post-mortem. In other words, we want users to be able to report problems after the conference is over, and we as engineers can look at detailed statistics to determine what the problem is, and hopefully, craft a solution.

Possible sources of statistics

• Statistics reported to InfluxDB after each channel is closed (i.e. the channel_expired series). -- This is good to spot big / general problems, but it's difficult to reconstruct what actually happened. For instance, we want to be able to see things like packet loss over time. We hope this can distinguish between things like a continually crappy network, and a network that was fine and then at some point got measurably worse.
• RTCP data broadcast to participants in the conference. -- This isn't currently preserved anywhere, but if we were to save off a pcap file (or similar) of the RTCP data stream, we should be able to reconstruct most, if not all, of the information we need from that.

We're currently investigating adding support to Jitsi-videobridge for saving off the complete set of RTCP packets for a conference.

Possible solutions

• Add another hidden participant to the conference, ala JiCoFo, that records these statistics. As I understand, all participants should generally still get all the RTCP data, so this should work. (Correct me if that's not the case)
• Record the statistics client-side (via browser APIs) and report them separately to another server. This has the downside of duplicating data that, as I understand it, is already reported to the videobridge via RTCP.
• Inject code into jitsi-vidoebridge itself to save off the RTCP data to a file.

We've tentatively gone down that third path. Two questions:

• Is this of general interest, and thus likely to be accepted as a PR; OR
• Is there a good way of doing this without modifying jitsi-videobridge itself?

Implementation

What follows is very hacky, largely untested, and not at all final.

So far, I've enabled BasicBridgeRTCPTerminationStrategy via configuration, and added a new DetailedStatsSerializer implements Transformer<RTCPCompoundPacket>, which I add to the list of rtcp transformers (via setTransformerChain.

The DetailedStatsSerializer saves all of the rtcp packets it sees to a file, one file per conference. We have a separate system monitoring the directory in question and uploading files to Amazon S3 for storage.

We'll build a separate analysis tool to summarize and visualize the information when needed.

---

I'm looking for general feedback, of any sort.

• Am I way off track?
• Is there interest from other people in this sort of functionality?
• Are there better ways to get this information?

Sorry for the novel. Thanks for reading.

So. Thoughts?

Hardware crypto

Does the videobridge use hardware crypto libraries and if not is it possible to plug-in? Thanks.

TCP candidates are generated with rtcp-mux disabled

The first component of a stream gets TCP candidates, because the harvest happens before there's a second component.

ComponentException : Not authorized

I'm trying to run jitsi videobridge 361 in Ubuntu 12.04, configured ejabberd 14.07 in port 5275, the next error is shown :

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
09:45:28.646 GRAVE: [1] util.UtilActivator.uncaughtException().108 An uncaught exception occurred in thread=Thread[main,5,main] and message was: not-authorized
org.xmpp.component.ComponentException: not-authorized
    at org.jivesoftware.whack.ExternalComponent.connect(ExternalComponent.java:219)
    at org.jivesoftware.whack.ExternalComponentManager.addComponent(ExternalComponentManager.java:221)
    at org.jivesoftware.whack.ExternalComponentManager.addComponent(ExternalComponentManager.java:201)
    at org.jitsi.videobridge.Main.main(Main.java:273)

Thank you in advance and good work

Fix config file permissions

Fix the permissions for /etc/jitsi/videobridge/* (they should not be world-readable)

Sctp send error: : Transport endpoint is not connected

org.jitsi.videobridge.Endpoint.error() SCTP error, endpoint: aa53d346
java.io.IOException: Failed to open new chanel on sid: 0
at org.jitsi.videobridge.SctpConnection.openChannel(SctpConnection.java:917)
at org.jitsi.videobridge.SctpConnection.getDefaultDataStream(SctpConnection.java:366)
at org.jitsi.videobridge.Endpoint.sendMessageOnDataChannel(Endpoint.java:283)
at org.jitsi.videobridge.Conference.sctpConnectionReady(Conference.java:1072)
at org.jitsi.videobridge.Conference.access$000(Conference.java:33)
at org.jitsi.videobridge.Conference$1.onSctpConnectionReady(Conference.java:152)
at org.jitsi.videobridge.SctpConnection.notifySctpConnectionReadyInEventDispatcher(SctpConnection.java:551)
at org.jitsi.videobridge.SctpConnection.access$300(SctpConnection.java:43)
at org.jitsi.videobridge.SctpConnection$3.run(SctpConnection.java:531)
at net.java.sip.communicator.impl.osgi.framework.AsyncExecutor.runInThread(AsyncExecutor.java:110)
at net.java.sip.communicator.impl.osgi.framework.AsyncExecutor.access$000(AsyncExecutor.java:16)
at net.java.sip.communicator.impl.osgi.framework.AsyncExecutor$1.run(AsyncExecutor.java:219)

A known workaround is to wait long enough between Conference.sctpConnectionReady and SctpConnection.openChannel.

Version 1.3.1 doesn't work with Openfire-3.9.3

Server is debian 7. I can confirm that our openfire server 3.9.3 used to be working with earlier version 1.3.0 but it stopped working since the upgrade to version 1.3.1.

Jitsi videobridge doesn't show up in the installed plugins list after installing from 'available plugins' window.

ofmeet

Openfire-ofmeet.

Events:
Both members are able to see only themselves. One member sees black screen instead of other member. Both members are able to see each other after they re-enter room.

Why is this happening?
Where can I get detailed information about the work Jitsi VideoBridge?

Not receiving a TCP (srflx) candidate in EC2 while using Docker

We do not receive all TCP (srflx) candidates when a user joins a meeting. This results in that user with UDP blocked being able to join the meeting without any media (audio/video).

This occurs only when we run the Videobridge in a Docker container within an EC2 instance. This bug does not occur when ran locally in also Docker Container. When ran locally, we observe that we receive all TCP (srflx) and (host) candidates verified from the videobridge logs and also in chrome://webrtc-internals.

Locally Ran VIdeobridge logs

videobridge_1 | 21:54:19.605 FINEST: [22] sun.net.www.protocol.http.HttpURLConnection.plainConnect() Proxy used: DIRECT
videobridge_1 | 21:54:19.615 FINE: [79] org.jitsi.impl.neomedia.transform.srtp.SRTPCryptoContext.debug() Reverse transform for SSRC 1851702603 SeqNo=23513 s_l=23512 seqNumSet=true guessedROC=0 roc=0
videobridge_1 | 21:54:19.618 FINE: [68] org.jitsi.impl.neomedia.transform.srtp.SRTPCryptoContext.debug() Reverse transform for SSRC 1186699033 SeqNo=20696 s_l=20695 seqNumSet=true guessedROC=0 roc=0
videobridge_1 | 21:54:19.639 FINE: [68] org.jitsi.impl.neomedia.transform.srtp.SRTPCryptoContext.debug() Reverse transform for SSRC 1186699033 SeqNo=20697 s_l=20696 seqNumSet=true guessedROC=0 roc=0
videobridge_1 | 21:54:19.654 INFO: [89] org.jitsi.videobridge.IceUdpTransportManager.info() Initializing static harvesters....
videobridge_1 | 21:54:19.654 INFO: [89] org.jitsi.videobridge.IceUdpTransportManager.info() Adding TCP Candidate Harvester: org.ice4j.ice.harvest.MultiplexingTcpHostHarvester@49d44a2
videobridge_1 | 21:54:19.654 INFO: [89] org.jitsi.videobridge.IceUdpTransportManager.info() Will append a NAT harvester for XXX.XX.X.XXX:9/udp=>YYY.YYY.YY.YYY:9/udp
videobridge_1 | 21:54:19.655 FINE: [89] org.ice4j.ice.Agent.createMediaStream() Create media stream for data
videobridge_1 | 21:54:19.655 INFO: [89] org.ice4j.ice.Agent.gatherCandidates() Gather candidates for component data.RTP
videobridge_1 | 21:54:19.655 FINEST: [89] org.ice4j.ice.harvest.HostCandidateHarvester.createDatagramSocket() just bound to: /XXX.XX.X.XXX:10005
videobridge_1 | 21:54:19.656 INFO: [30] org.ice4j.ice.harvest.CandidateHarvesterSetElement.harvest() Harvest is called in CandidateHarvesterSetElement
videobridge_1 | 21:54:19.657 FINE: [89] org.ice4j.ice.Agent.gatherCandidates() Candidate count in first harvest: 4
videobridge_1 | 21:54:19.657 INFO: [89] org.ice4j.ice.Agent.createComponent()   XXX.XX.X.XXX:10005/udp (host)
videobridge_1 | 21:54:19.657 INFO: [89] org.ice4j.ice.Agent.createComponent()   XXX.XX.X.XXX:4444/tcp (host)
videobridge_1 | 21:54:19.658 INFO: [89] org.ice4j.ice.Agent.createComponent()   YYY.YYY.YY.YYY:4444/tcp (srflx)
videobridge_1 | 21:54:19.658 INFO: [89] org.ice4j.ice.Agent.createComponent()   YYY.YYY.YY.YYY:10005/udp (srflx)
videobridge_1 | 21:54:19.660 FINE: [68] org.jitsi.impl.neomedia.transform.srtp.SRTPCryptoContext.debug() Reverse transform for SSRC 1186699033 SeqNo=20698 s_l=20697 seqNumSet=true guessedROC=0 roc=0
videobridge_1 | 21:54:19.663 FINEST: [22] sun.net.www.protocol.http.HttpURLConnection.plainConnect() Proxy used: DIRECT

EC2 Ran Videobridge logs

videobridge_1 | 19:58:17.277 FINEST: [19] sun.net.www.protocol.http.HttpURLConnection.plainConnect() Proxy used: DIRECT
videobridge_1 | 19:58:17.278 FINE: [19] sun.net.www.protocol.http.HttpURLConnection.writeRequests() sun.net.www.MessageHeader@1543938e5 pairs: {GET /latest/meta-data/public-ipv4 HTTP/1.1: null}{User-Agent: Java/1.7.0_75}{Host: 169.254.169.254}{Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2}{Connection: keep-alive}
videobridge_1 | 19:58:17.279 FINEST: [19] sun.net.www.protocol.http.HttpURLConnection.logFinest() KeepAlive stream used: http://169.254.169.254/latest/meta-data/public-ipv4
videobridge_1 | 19:58:17.283 FINE: [19] sun.net.www.protocol.http.HttpURLConnection.getInputStream() sun.net.www.MessageHeader@78c5a8a9 pairs: {null: HTTP/1.0 200 OK}{Content-Type: text/plain}{Accept-Ranges: bytes}{ETag: "1794169453"}{Last-Modified: Thu, 26 Mar 2015 16:29:42 GMT}{Content-Length: 12}{Connection: keep-alive}{Date: Fri, 10 Apr 2015 19:58:37 GMT}{Server: EC2ws}
videobridge_1 | 19:58:17.283 INFO: [19] org.ice4j.ice.harvest.AwsCandidateHarvester.obtainEC2Addresses() Detected AWS local IP: XX.X.X.XX:9/udp
videobridge_1 | 19:58:17.284 INFO: [19] org.ice4j.ice.harvest.AwsCandidateHarvester.obtainEC2Addresses() Detected AWS public IP: YY.YY.YY.YYY:9/udp
videobridge_1 | 19:58:17.284 INFO: [19] org.jitsi.videobridge.IceUdpTransportManager.info() EC2 local address: 10.0.0.80 and public address: ZZ.ZZ.ZZ.ZZZ
videobridge_1 | 19:58:17.284 INFO: [19] org.jitsi.videobridge.IceUdpTransportManager.info() Adding TCP Candidate Harvester: org.ice4j.ice.harvest.MultiplexingTcpHostHarvester@37fead5c
videobridge_1 | 19:58:17.285 INFO: [19] org.jitsi.videobridge.IceUdpTransportManager.info() Appending an AWS harvester to the ICE agent. org.ice4j.ice.harvest.AwsCandidateHarvester@31278fbc
videobridge_1 | 19:58:17.286 INFO: [19] org.jitsi.videobridge.IceUdpTransportManager.info() Will append a NAT harvester for AAA.AA.A.AAA:9/udp=>YY.YY.YY.YYY:9/udp
videobridge_1 | 19:58:17.288 FINE: [19] org.ice4j.ice.Agent.createMediaStream() Create media stream for stream
videobridge_1 | 19:58:17.305 INFO: [19] org.ice4j.ice.Agent.gatherCandidates() Gather candidates for component stream.RTP
videobridge_1 | 19:58:17.308 FINEST: [19] org.ice4j.ice.harvest.HostCandidateHarvester.createDatagramSocket() just bound to: /AAA.AA.A.AAA:10000
videobridge_1 | 19:58:17.322 INFO: [29] org.ice4j.ice.harvest.CandidateHarvesterSetElement.harvest() Harvest is called in CandidateHarvesterSetElement
videobridge_1 | 19:58:17.325 INFO: [30] org.ice4j.ice.harvest.CandidateHarvesterSetElement.harvest() Harvest is called in CandidateHarvesterSetElement
videobridge_1 | 19:58:17.326 FINE: [19] org.ice4j.ice.Agent.gatherCandidates() Candidate count in first harvest: 3
videobridge_1 | 19:58:17.326 INFO: [19] org.ice4j.ice.Agent.createComponent()   AAA.AA.A.AAA:10000/udp (host)
videobridge_1 | 19:58:17.327 INFO: [19] org.ice4j.ice.Agent.createComponent()   AAA.AA.A.AAA:4444/tcp (host)
videobridge_1 | 19:58:17.327 INFO: [19] org.ice4j.ice.Agent.createComponent()   YY.YY.YY.YYY:10000/udp (srflx)
videobridge_1 | 19:58:17.329 FINEST: [20] sun.net.www.protocol.http.HttpURLConnection.plainConnect() Proxy used: DIRECT

Tear down DTLS-protected media session if the fingerprint does not match the hashed certificate

Gavin Llewellyn wrote:

I noticed something in a JVB log file that has me concerned:

2015-06-28 16:43:34.267 WARNING: [12159] org.jitsi.impl.neomedia.transform.dtls.DtlsControlImpl.warn() Failed to verify and/or validate a certificate offered over the media path against fingerprints declared over the signaling path! No fingerprints declared over the signaling path!

The root cause of the lack of fingerprints may be that we’re not driving the REST interface correctly; I haven’t looked into that yet. What worries me is that the media is working despite this warning message. JVB has apparently been unable to verify the fingerprint, but continues regardless. Surely this is not a good idea.

Looking at the code in DtlsControlImpl, it appears a similar result would arise if the fingerprint was signalled but did not match: verifyAndValidateCertificate() prints a warning and returns false, but the return value is never used. According to a comment in that file, not tearing down the connection appears to be deliberate. Am I missing something?

REST PATCH to update payload information hangs

Hi,

I am trying to use the videobride and when I set the fingerprint it seems to hang and the rest connection times out. There is no error/log output on the videobridge.

When I do a get on the same URI that mostly works.

Thank you,
Florian

PATCH /colibri/conferences/18fdda51d63305d8 HTTP/1.1
Host: localhost:8080
Content-Type: application/json
Cache-Control: no-cache
Postman-Token: e154d52c-dee5-9f0b-960c-ece9ab658493

{
  "contents":[
    {
      "name":"audio",
      "channels":[
        {
          "id":"4501729186d829a0",
          "transport":{
            "fingerprints":[
              {
                "fingerprint":"A7:A3:E6:8F:17:E5:50:E6:F5:58:5A:B7:30:FE:9B:E6:37:4D:A0:63",
                "hash":"sha-1"
              }
            ]
          }
        }
      ]
    }
  ]
}

GET /colibri/conferences/18fdda51d63305d8 HTTP/1.1
Host: localhost:8080
Content-Type: application/json


{
    "contents": [
        {
            "channels": [
                {
                    "sources": [
                        1841335812
                    ],
                    "rtp-level-relay-type": "translator",
                    "expire": 240,
                    "initiator": true,
                    "id": "4501729186d829a0",
                    "transport": {
                        "candidates": [
                            {
                                "generation": 0,
                                "component": 1,
                                "protocol": "udp",
                                "port": 10012,
                                "ip": "10.33.38.154",
                                "foundation": "1",
                                "id": "18fdda51d63305d81d14f01c684099a4063f6c40f",
                                "priority": 2130706431,
                                "type": "host",
                                "network": 0
                            },
                            {
                                "generation": 0,
                                "component": 2,
                                "protocol": "udp",
                                "port": 10013,
                                "ip": "10.33.38.154",
                                "foundation": "1",
                                "id": "18fdda51d63305d81d14f01c684099a4010b214e6",
                                "priority": 2130706430,
                                "type": "host",
                                "network": 0
                            }
                        ],
                        "xmlns": "urn:xmpp:jingle:transports:ice-udp:1",
                        "ufrag": "1idlp19v220c2e",
                        "pwd": "3cnibjc6q6o9l7obni2p50fq6t",
                        "fingerprints": [
                            {
                                "fingerprint": "FE:75:6C:32:84:BC:3E:B6:9C:B9:A6:92:B6:BC:15:F8:33:1C:BE:A2",
                                "hash": "sha-1"
                            }
                        ]
                    },
                    "direction": "sendrecv"
                }
            ],
            "name": "audio"
        },
        {
            "channels": [
                {
                    "sources": [
                        2240213590
                    ],
                    "rtp-level-relay-type": "translator",
                    "expire": 240,
                    "initiator": true,
                    "id": "69eb244c3727a57a",
                    "transport": {
                        "candidates": [
                            {
                                "generation": 0,
                                "component": 1,
                                "protocol": "udp",
                                "port": 10014,
                                "ip": "10.33.38.154",
                                "foundation": "1",
                                "id": "18fdda51d63305d832c1e8ba6e2075d6078c9ec61",
                                "priority": 2130706431,
                                "type": "host",
                                "network": 0
                            },
                            {
                                "generation": 0,
                                "component": 2,
                                "protocol": "udp",
                                "port": 10015,
                                "ip": "10.33.38.154",
                                "foundation": "1",
                                "id": "18fdda51d63305d832c1e8ba6e2075d604799e72d",
                                "priority": 2130706430,
                                "type": "host",
                                "network": 0
                            }
                        ],
                        "xmlns": "urn:xmpp:jingle:transports:ice-udp:1",
                        "ufrag": "dg9qd19v220c3q",
                        "pwd": "o89pv65l7j69k3834rnjjb64v",
                        "fingerprints": [
                            {
                                "fingerprint": "76:7B:E0:F5:F7:F0:9F:EE:28:3D:A2:0D:27:D7:DA:52:A3:74:E1:BE",
                                "hash": "sha-1"
                            }
                        ]
                    },
                    "direction": "sendrecv"
                }
            ],
            "name": "video"
        }
    ],
    "id": "18fdda51d63305d8"
}

build script for lib/native/* ?

How does one go about building the bits in lib/native/* ? The source looks to be in the https://github.com/jitsi/libsrc repo, but I don't see any kind of build script there.

I'm looking to get this working on a new arch (armhf, specificially the Beaglebone Black).

two parse errors when expiring channels

I ran into some errors recently when expiring channels with build 231.

1. http://hancke.name/tmp/jvb-parseerror
   I fixed that by adding endpoints which seem to be required here. I don't think that makes sense since the bridge already knows the endpoint.

2. http://hancke.name/tmp/jvb-exception2
   Not sure what causes the exception here.

pseudo-tls over tcp support

Would be nice to have pseudo-tls over tcp support in the bridge as well as described on http://msdn.microsoft.com/en-us/library/dd947700(v=office.12).aspx

chrome and hangouts use a similar thing. I wiresharked a little and the handshake is as follows:

char peer0_0[] = {
0x80, 0x46, 0x01, 0x03, 0x01, 0x00, 0x2d, 0x00, 
0x00, 0x00, 0x10, 0x01, 0x00, 0x80, 0x03, 0x00, 
0x80, 0x07, 0x00, 0xc0, 0x06, 0x00, 0x40, 0x02, 
0x00, 0x80, 0x04, 0x00, 0x80, 0x00, 0x00, 0x04, 
0x00, 0xfe, 0xff, 0x00, 0x00, 0x0a, 0x00, 0xfe, 
0xfe, 0x00, 0x00, 0x09, 0x00, 0x00, 0x64, 0x00, 
0x00, 0x62, 0x00, 0x00, 0x03, 0x00, 0x00, 0x06, 
0x1f, 0x17, 0x0c, 0xa6, 0x2f, 0x00, 0x78, 0xfc, 
0x46, 0x55, 0x2e, 0xb1, 0x83, 0x39, 0xf1, 0xea };
char peer1_0[] = {
0x16, 0x03, 0x01, 0x00, 0x4a, 0x02, 0x00, 0x00, 
0x46, 0x03, 0x01, 0x42, 0x85, 0x45, 0xa7, 0x27, 
0xa9, 0x5d, 0xa0, 0xb3, 0xc5, 0xe7, 0x53, 0xda, 
0x48, 0x2b, 0x3f, 0xc6, 0x5a, 0xca, 0x89, 0xc1, 
0x58, 0x52, 0xa1, 0x78, 0x3c, 0x5b, 0x17, 0x46, 
0x00, 0x85, 0x3f, 0x20, 0x0e, 0xd3, 0x06, 0x72, 
0x5b, 0x5b, 0x1b, 0x5f, 0x15, 0xac, 0x13, 0xf9, 
0x88, 0x53, 0x9d, 0x9b, 0xe8, 0x3d, 0x7b, 0x0c, 
0x30, 0x32, 0x6e, 0x38, 0x4d, 0xa2, 0x75, 0x57, 
0x41, 0x6c, 0x34, 0x5c, 0x00, 0x04, 0x00 };

Googling for the first bytes of that leads to a file GoogleTurnSSLCandidateHarvester.java in ice4j which already contains those strings :-)

The candidate type for those is "ssltcp". http://hancke.name/tmp/ssltcp shows an example of using it.