Create a server-side JitMeet focus. This would imply adding a new role to JitMeet: that of a conference organiser.

The change would make chat rooms stabler and allow conference organisers to arrive later or reload their web pages without killing the entire conference.

Make WebRTC stats part of the JitMeet logs so that they would be available for analysis when bugs are being reported.

Add a check your hair screen before entering the conference.

On discuss-webrtc juberti said: "Note also that resetting a remote description to trigger a key frame is going away in M35. You should use RTCP FIR instead."

We do this in a number of places and should investigate where we can remove it.

Replace common smiley combinations with images. (Make sure copy pasting text still works that way)

Add the possibility to make presentations in a JitMeet conference.

This includes:

• upload a PDF or a number of images
• allow the presenter to pick which one they are showing
• allow participants to switch to slides as they do for regular video
• allow presenter to navigate through slides
• update slides for participants as the presenter moves through them

If there's a large number of remote videos, opening the chat will break the remote video layout by moving the last 2-3 videos on a new line.

under certain conditions it seems that there is a duplicate span created with a non-unique id.
I think this goes along with the "can not associate stream" warning.

Need to check if presence update is sent before jingle action.

When a new participant joins, their video replaces whatever is shown in the "big video" field. This is somewhat annoying if you're watching/presenting a presentation or looking at the etherpad.

Presentations and etherpad should not be replaced when a new participant joins.

Add visual and audio notifications when new chat messages are being received, while the chat panel is not open.

Send display names in presence. Show them to the user and save them in local storage.

Make it possible to record a JitMeet conference. This includes audio, video and potentially even text.

This is probably not going to be a very easy one. @fippo what do you think?

@fippo and discussed this yesterday. Currently having the focus leave during a call would not only break the call but also completely kill the channel.

We need some sort of a saving mechanism and a procedure for electing a new focus if (and only if) this happens.

Note that this is only a work-around as eventually we should be moving the focus on the server-side.

it seems we can safely remove the 2500ms timeout in colibri.js after https://code.google.com/p/webrtc/issues/detail?id=2688 is resolved. If that means supplying a patch...

issue #4 deals with full audio/video support for Firefox.
Audio-only should be easier, since the bridge only sends a single mixed stream.

It appears that displaynames like "&yet" are transformed into "&yet".
That might well be double-escaping, but it seems you could avoid the whole escaping when using .text() instead of .html() in some places inside showDisplayName.

In some cases participants would sometimes join a room and "nothing would happen". No audio/video connection is established. In such cases it is however possible to use the text chat of the application.

@lyubomir @fippo and I have been chatting about this today. Having the focus behave differently when joining conferences causes a few instabilities because it hits several Chrome bugs (e.g. one where Chrome gets confused between the local candidates that it should use).

The best way to resolve these short term would be to make the focus join conferences the same way as participants: putting it at the receiving end of the Offer/Answer and turning Chrome into the controlled rather than the controlling ICE agent.

If the first person to join a conference as a participant has constrained connectivity (e.g. only connects through an http proxy) the conference would then be broken for everyone else.

This would be resolved after moving to a server-side focus but until then we may also try a few things with the current arch. Inviting participants asynchronously sounds like one idea. Retrying and eventually abandoining a negotiation if it takes longer than N seconds would be another one.

@fippo any thoughts?

Focus should follow MUC settings and mute or kick people out of the conference as they are muted or kicked in the MUC

Add the possibility for the focus to force mute, kick and ban participants (i.e. without giving them the technical option of disobeying).

This would also mean placing their Jitsi Videobridge channel on hold, etc.

It would also mean that we would need to first finish #16

Add dates to chat messages, add themes, improve layout.

Add to JitMeet the possibility to use multiple bridges on the same server (for scalability reasons)

Add an indication that clearly allows users to determine if they are the focus in a particular conference and, if not, identify the person that is.

In the beginning of a conference unnecessary colibri channels are allocated. For example, in a conference of two the focus requests a total of three pairs of channels (3 audio, 3 video). I observed the following: Initially the focus requests 2 audio and 2 video channels. The bridge replies setting channel ids. Something like:

<content name="audio">
<channel direction="recvonly" expire="15" id="3d3a45dfa9b84087" initiator="true" rtp-level-relay-type="mixer">...</channel>
<channel direction="recvonly" expire="15" id="fa5e08e307baa8d9" initiator="true" rtp-level-relay-type="mixer">...</channel>
</content>
<content name="video">
<channel expire="15" id="49a8168ab3843f8" initiator="true" rtp-level-relay-type="translator">...</channel>
<channel expire="15" id="30f1869daed6e04e" initiator="true" rtp-level-relay-type="translator">...</channel>
</content>

The focus then appears to use only one of the channels for each content, and requests new ones:

<content name="audio">
<channel id="3d3a45dfa9b84087" expire="15" initiator="true">...</channel>
<channel expire="15" initiator="true"/>
</audio>
<content name="video">
<channel id="49a8168ab3843f8" expire="15" initiator="true">...</channel>
<channel expire="15" initiator="true"/>
</content>

having a 1-1 session relayed via the bridge would be another step towards firefox compability.

That is not impacted by multi-stream support either, but may break due to lack of a=ssrc lines in firefox SDP

Conferences with more than 8 or 10 participants wouldn't be showing all of them. For such cases it would be important to have an alternative means of seeing a list of the conference participants.

@yanas will add a GUI option that allows organisers to specify whether participants in a conference are supposed to start with their microphone muted and/or webcam turned off.

Once this is ready, we would need the focus to indicate it in its invitations.

Allow participants to share etherpads for collaborative editing.

Make it possible for participants to share a list of URLs as meeting materials. This could also be used as a basis for shared presentations

we should have a separate page for firefox which explains why firefox is not supported. Currently, this is redirects to chromeonly.

The webrtc-required page should also recommend other browsers this works with such as Chromium or Opera.

OK, this is very important. We need to be able to tell users about their join progress. The idea is that when a user is joining a conference now, they are only seeing an avatar for an indefinitely long time and there's no way for them to know if that's because a join is in progress or because it has failed. We need to be able to tell this to users.

@fippo Could you please add an API that sends notifications for join states? Maybe something that would allow progress tracking would be nice. I mean, in addition to the status message, the API can also say that we are at (very roughly) X% of getting there. Like for example: joining the room is 30%, getting an offer is 60%, sending our first candidate is 80%, getting audio is 90% and getting video is 100%. All this is about showing to a user their own state.

Showing to a user (focus?) the states of other participants would be a little bit trickier (but not much). Telling one participant about the state of another one would be trickiest because we'd basically have only joining the room (30%) getting their remote SSRC (70%?) and getting a video stream for a 100%

How does this sound? Keep in mind that this is just a sketch suggestion so please let me know if you have other ideas.

@yanas once @fippo is ready, could you please glue that into the GUI? I think this would help a lot for all the cases where people are still unable to join.

What do you guys think?

Many users seem to be asking about this and they don't seem to mind needing to set a flag in chrome. We might as well oblige them :)

@bgrozev , @yanas , @fippo , any takers? :)

partially implemented, need to test.

In particular, a focus without video might cause strange things to happen because its offer has a=recvonly.

Since @lyubomir added support for keeping video channels alive in #20, we can make the video button turn video off (a=recvonly) rather than just sending black video. This should pave our way toward a resolution for #6

Muting video should better work by stopping video transmission because that would have a significant impact on bandwidth requirements, especially for large scale conferences.

To achieve this however we'd first need to make sure that the videobridge wouldn't expire connections without data and that it would keep them alive with ICE connectivity checks.

So for the time being this ticket lies with @lyubomir . @fippo would probably take over once we need to do the muting in JitMeet.

People would often enter a conference and then continue doing other things while waiting for everyone else to join. So, when people start arriving there wouldn't necessarily notice until greeted. It would be cool to have audio notifications generated by the app for newcomers.

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

Allow the user to choose between other video layouts, e.g. show more than one participants in large resolution or allow the user to show/ hide the remote participants.

The updates to
https://code.google.com/p/webrtc/issues/detail?id=1406
and specifically
https://code.google.com/p/webrtc/issues/detail?id=2828
suggest that ipv6 clientside support has just landed in chrome canary. I'll see about adding that.

I don't expect many problems, I think I saw it in action at IETF Berlin.

This is an entirely videobridge task but since most of the work on the bridge currently happens within the context of JitMeet.

The goal of this ticket is to create, clear and easily greppable logging on the videobridge.

In some cases the layout in the chat panel appears broken and the topmost messages are hidden.

Jitsi Videobridge now has a LastN feature that allows it to only forward the video for the last N active speakers. This is a mandatory feature for large scale conferences.

This is just a support request.

Chromium works very well.
Please support also other browsers such as Firefox in the future.

Thank you for your great work!