Merge pull request jitsi#3 from pstros/CCC

Upgrading integration to release 797

.gitattributes

@@ -0,0 +1 @@
+*.java text eol=lf diff=java

build.xml

@@ -201,8 +201,10 @@
     <!-- Jitsi Videobridge Version -->
     <target name="version">
         <!-- set the build id according to the cruisecontrol property -->
-        <replaceregexp file="${src}/org/jitsi/videobridge/version/VersionImpl.java"
-                 match="NIGHTLY_BUILD_ID=(.+)" replace="NIGHTLY_BUILD_ID=&quot;${label}&quot;;" byline="true"/>
+        <replaceregexp file="${src}/org/jitsi/videobridge/version/CurrentVersionImpl.java"
+                 match="NIGHTLY_BUILD_ID = (.+)"
+                 replace="NIGHTLY_BUILD_ID = &quot;${label}&quot;;"
+                 byline="true"/>
     </target>
 
     <!-- JAVADOC -->

config/logrotate

@@ -0,0 +1,11 @@
+/var/log/jitsi/jvb.log {
+  daily
+  missingok
+  rotate 7
+  compress
+  delaycompress
+  notifempty
+  copytruncate
+  su jvb jitsi
+}
+

doc/adaptive-last-n.md

@@ -101,10 +101,10 @@ bandwidth.
 The parameters from the above section can be configured with the following
 properties (with their default values given):
 
-org.jitsi.videobridge.ratecontrol.BitrateController.INCREASE\_LAG\_MS=20000
-org.jitsi.videobridge.ratecontrol.BitrateController.DECREASE\_LAG\_MS=10000
-org.jitsi.videobridge.ratecontrol.BitrateController.INITIAL\_INTERVAL\_MS=70000
-org.jitsi.videobridge.ratecontrol.BitrateController.REMB\_MULT\_CONSTANT=1.0
-org.jitsi.videobridge.ratecontrol.BitrateController.MIN\_ASSUMED\_ENDPOINT\_BITRATE\_BPS=400000
-org.jitsi.videobridge.ratecontrol.BitrateController.REMB\_AVERAGE\_INTERVAL\_MS=5000
+org.jitsi.videobridge.ratecontrol.LastNBitrateController.INCREASE\_LAG\_MS=20000
+org.jitsi.videobridge.ratecontrol.LastNBitrateController.DECREASE\_LAG\_MS=10000
+org.jitsi.videobridge.ratecontrol.LastNBitrateController.INITIAL\_INTERVAL\_MS=70000
+org.jitsi.videobridge.ratecontrol.LastNBitrateController.REMB\_MULT\_CONSTANT=1.0
+org.jitsi.videobridge.ratecontrol.LastNBitrateController.MIN\_ASSUMED\_ENDPOINT\_BITRATE\_BPS=400000
+org.jitsi.videobridge.ratecontrol.LastNBitrateController.REMB\_AVERAGE\_INTERVAL\_MS=5000
 org.jitsi.videobridge.ratecontrol.VideoChannelLastNAdaptor.MAX\_STAY\_AT\_ZERO\_MS=60000

doc/callstats.md

@@ -3,12 +3,24 @@ in /etc/jitsi/videobridge/sip-communicator.properties
 
     # the callstats credentials
     io.callstats.sdk.CallStats.appId=
-    io.callstats.sdk.CallStats.appSecret=
+    io.callstats.sdk.CallStats.keyId=
+    io.callstats.sdk.CallStats.keyPath=
 
     # the id of the videobridge
     io.callstats.sdk.CallStats.bridgeId=
 
     # enable statistics and callstats statistics and the report interval
     org.jitsi.videobridge.ENABLE_STATISTICS=true
     org.jitsi.videobridge.STATISTICS_INTERVAL.callstats.io=30000
-    org.jitsi.videobridge.STATISTICS_TRANSPORT=callstats.io
+    org.jitsi.videobridge.STATISTICS_TRANSPORT=callstats.io
+
+You can use [pem-to-jwk](https://www.npmjs.com/package/pem-to-jwk) to convert PEM encoded EC private key to JWK.  
+To generate a jwk file that needs to be supplied as
+io.callstats.sdk.CallStats.keyPath parameter, follow these steps:
+
+    # Generate EC key
+    openssl ecparam -name prime256v1 -genkey > ecpriv.key
+    cat ecpriv.key | pem-to-jwk > ecpriv.jwk
+
+    # Generate a public key from private key
+    openssl ec -in ecpriv.key -pubout -out ecpubkey.pem

doc/datachannel-communication.md

@@ -0,0 +1,36 @@
+#Messages by COLIBRI class:
+
+##EndpointMessage:
+
+
+This type of messages could be used by the clients for sending JSON objects to the other clients in the conference. A client can send a message to specific endpoint or a broadcast message.
+
+
+
+* The messages processed by Jitsi Videobridge has the following format:
+
+```
+{
+    colibriClass: "EndpointMessage",  
+    to: `<ENDPOINT-ID>`,   
+    msgPayload: `<PAYLOAD>`  
+}
+```
+
+`<PAYLOAD>` is valid JSON string.  
+`<ENDPOINT-ID>` is endpoint id of existing participant or `""` for broadcast message.
+
+* The messages sent by Jitsi Videobridge has the following format:
+
+
+```
+{
+    colibriClass: "EndpointMessage",
+    to: `<ENDPOINT-ID>`,
+    from: `<ENDPOINT-ID>`,
+    msgPayload: <PAYLOAD>
+}
+```
+
+
+The only modification made by Jitsi Videobridge before the message is forwarded is adding `from` property to it. The value of this property is the endpoint id of the sender of the message.

doc/debugging.md

@@ -0,0 +1,36 @@
+# Introduction
+
+This document describes some methods and techniques that can be used to debug
+the JVB.
+
+# Capturing packets
+
+The JVB can be configured to log all (or just some) of the incoming/outgoing
+packets that it receives/sends. In order to capture all RTP/RTCP traffic, you
+can setup logging like this:
+
+    net.java.sip.communicator.packetlogging.PACKET_LOGGING_ENABLED=true
+    net.java.sip.communicator.packetlogging.PACKET_LOGGING_ARBITRARY_ENABLED=true
+    net.java.sip.communicator.packetlogging.PACKET_LOGGING_SIP_ENABLED=false
+    net.java.sip.communicator.packetlogging.PACKET_LOGGING_JABBER_ENABLED=false
+    net.java.sip.communicator.packetlogging.PACKET_LOGGING_RTP_ENABLED=false
+    net.java.sip.communicator.packetlogging.PACKET_LOGGING_ICE4j_ENABLED=false
+    net.java.sip.communicator.packetlogging.PACKET_LOGGING_FILE_COUNT=1
+    net.java.sip.communicator.packetlogging.PACKET_LOGGING_FILE_SIZE=-1
+
+Optionally, you can log the packets to a named pipe like this:
+
+    mkfifo ~/.sip-communicator/log/jitsi0.pcap
+
+If you log to a named pipe, you can launch Wireshark like this (assuming that
+you're using Bash):
+
+    wireshark -k -i < (cat ~/.sip-communicator/log/jitsi0.pcap)
+
+# Scripting the bridge
+
+You can script the bridge using Groovy. This functionality is not baked in the
+vanilla bridge for security reasons, so you have to download and compile and
+configure the shell yourself. Here
+https://github.com/jitsi/jitsi-videobridge-groovysh you can find more
+information on how to do that.

doc/http.md

@@ -14,6 +14,7 @@ org.jitsi.videobridge.rest.jetty.ResourceHandler.resourceBase=/usr/share/jitsi-m
 org.jitsi.videobridge.rest.jetty.ResourceHandler.alias./config.js=/etc/jitsi/meet/example.meet.jit.si-config.js
 org.jitsi.videobridge.rest.jetty.RewriteHandler.regex=^/([a-zA-Z0-9]+)$
 org.jitsi.videobridge.rest.jetty.RewriteHandler.replacement=/
+org.jitsi.videobridge.rest.api.jetty.SSIResourceHandler.paths=/
 org.jitsi.videobridge.rest.jetty.tls.port=443
 org.jitsi.videobridge.TCP_HARVESTER_PORT=443
 org.jitsi.videobridge.rest.jetty.sslContextFactory.keyStorePath=/etc/jitsi/videobridge/example.meet.jit.si.jks

doc/last-n.md

@@ -23,11 +23,49 @@ the dominant speaker or lastN endpoints.
     ],
     "lastNEndpoints": [
       "myuserJid@somewhere.com/chat-1234"
+    ],
+    "conferenceEndpoints": [
+      "myuserJid@somewhere.com/chat-1234", "another-endpoint"
+    ]
+}
+```
+The "lastNEndpoints" array contains the IDs of the endpoints for which video is
+currently being forwarded from the bridge to the client, and only these
+endpoints. The list is ordered according to the history of the speech activity in
+the conference. That is, the first entry in the list is the one which has been dominant
+speaker most recently. This list is not necessarily an initial segment of the 
+"conferenceEndpoints" list, because of endpoint pinning.
+
+The "endpointsEnteringLastN" array contains the IDs of the endpoints which are
+in the "lastNEndpoints" array, but were not in the array the last time the
+event was sent. I.e. their video was not being forwarded, but now it is.
+
+The "conferenceEndpoints" array contains the IDs of the endpoints in the
+conference, ordered by speech activity. That is, the first element is the
+current dominant speaker, the second element is the previous dominant speaker
+and so on. The list is limited to the "lastN" value for the endpoint (which may
+or may not be the same as the size of "lastNEndpoints").
+
+For example, if we have a conference with endpoints "a", "b", "c", "d", "e",
+ordered by speech activity in this way, we have lastN=4, we have "e" as a pinned endpoint,
+and previously no video was being forwarded (e.g. adaptive last-n had dropped the
+number of forwarded streams to 0), we could receive the following:
+
+```json
+{
+    "colibriClass": "LastNEndpointsChangeEvent",
+    "endpointsEnteringLastN": [
+      "a", "b", "e"
+    ],
+    "lastNEndpoints": [
+     "a", "b", "e"
+    ],
+    "conferenceEndpoints": [
+      "a", "b", "c", "d"
     ]
 }
 ```
-This event could be used by the client to show avatars or placeholders for users who are not
-currently in the `lastNEndpoints` array.
+
 
 **DominantSpeakerEndpointChangeEvent**
 ```json

doc/newrelic.md

@@ -16,7 +16,7 @@ newrelic.config.file=/my/new/location/newrelic.jar
 Uncomment the property JVB_EXTRA_JVM_PARAMS in /etc/jitsi/videobridge/config.
 And put the following property in /etc/jitsi/videobridge/sip-communicator.properties:
 ```json
-org.jitsi.videobridge.metricservice.NewRelic=org.jitsi.videobridge.metrics.NewRelicMetricPublisher
+org.jitsi.videobridge.metricservice.NewRelic=org.jitsi.videobridge.eventadmin.metrics.NewRelicMetricPublisher
 ```
 
 ## Metrics Produced