Emil Ivov

The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE Agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel.

This document… Show more

The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE Agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel.

This document defines usage semantics for Trickle ICE with the Session Initiation Protocol (SIP). The document also defines a new SIP Info Package to support this usage together with the corresponding media type. Additionally, a new Session Description Protocol (SDP) "end-of-candidates" attribute and a new SIP option tag "trickle-ice" are defined. Show less

This document describes "Trickle ICE", an extension to the Interactive Connectivity Establishment (ICE) protocol that enables ICE agents to begin connectivity checks while they are still gathering candidates, by incrementally exchanging candidates over time instead of all at once. This method can considerably accelerate the process of establishing a communication session.

Multiparty conferencing has traditionally been a relatively expensive application that was only used in enterprise scenarios. Recently, however, the landscape has started to shift in ways that could change this. Ever-increasing bandwidth and processing capabilities make it possible for mobile endpoints and laptop computers to easily handle multiple incoming media streams (both audio and video). The development of Web Real-Time Communications (WebRTC) has also significantly simplified the… Show more

Multiparty conferencing has traditionally been a relatively expensive application that was only used in enterprise scenarios. Recently, however, the landscape has started to shift in ways that could change this. Ever-increasing bandwidth and processing capabilities make it possible for mobile endpoints and laptop computers to easily handle multiple incoming media streams (both audio and video). The development of Web Real-Time Communications (WebRTC) has also significantly simplified the development of video conferencing applications and made them mainstream. Both of these changes provide a way of replacing expensive video mixers (that produce composited videos) with light-weight video routers (that selectively forward streams). In this paper, we describe a Multipoint Control Unit (MCU) that identifies and selects the last N dominant speakers and forwards their streams to all the conference participants. We evaluate the performance of this Selective Forwarding Unit (SFU) against a simplistic everyone-to-everyone (full-star) MCU. Our results show that the SFU uses 45% less CPU and 63% less bandwidth when forwarding media for 10 of the endpoints in a 30-participant conference. Show less

In Jitsi Videobridge (https://jitsi.org/Projects/JitsiVideobridge), a WebRTC video conferencing router, encryption and packet signing were among the most expensive components in terms of CPU intensity. We therefore set out on a journey to optimize them as much as possible.

We would like to share this journey with the Java FLOSS community.

We are going to present a comparison we have made on the execution times of popular open source implementations of AES and SHA-1 in search of… Show more

In Jitsi Videobridge (https://jitsi.org/Projects/JitsiVideobridge), a WebRTC video conferencing router, encryption and packet signing were among the most expensive components in terms of CPU intensity. We therefore set out on a journey to optimize them as much as possible.

We would like to share this journey with the Java FLOSS community.

We are going to present a comparison we have made on the execution times of popular open source implementations of AES and SHA-1 in search of the best performer. Our reference implementations are provided by the pure-Java Bouncy Castle cryptography APIs. Our contenders are an assortment of widely-used Java and cross-platform C code: the SunJCE security provider optimized by Java Runtime Environment (JRE) 8, the Mozilla Network Security Services (NSS) libraries employed through the SunPKCS11 security provider and the OpenSSL Crypto library accessed with the help of the Java Native Interface (JNI).

We're going to pit software against hardware in our examination how we can leverage the Advanced Encryption Standard New Instructions (AES-NI).

We're going to look at the performance compromises of transferring bytes between Java and C. Can we beat Java's intrinsics? Will Java New/Non-blocking I/O (NIO) be better? Show less

This document suggests some strategies for the combined use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) both in user-oriented clients and in deployed servers.