There are a lot of points when $scope.$apply is called. We must avoid them because it leads to some failures (trying to do an $apply during a running digest-cycle).

It should be possible to create a bookmark for the current username and room selections, so entering the same room everyday (or several times per day) is more straightforward.

If the user logs out of the room and then joins again (also to a different room, I assume), speaking detection stops working.

When I'm muted (esp. if others muted me) and I start speaking Jangouts should detect that and inform me (e.g. with a bell).

Google Hangout does that.

would ne nice if channels had persistent links so one could invite other people

The thumbnails are currently fixed at 100px wide. The plan has always being to have them automatically adjusted between 126 and 80 pixels, based on the available space. With the current flex box, that should be very easy to implement using only css with the min-width and max-width properties. The problem is that those properties, that work as expected with figures containing images, doesn't seem to work with videos.

Two options:

• CSS based solution. Not sure if it's possible but maybe we can force the videos to act as images and allow the resizing.
• JS solution, use this method https://github.com/jangouts/jangouts/blob/master/src/app/components/videochat/jh-video-chat.directive.js#L146 to resize the thumbnails to one of these predefined widths: 80, 96, 112, 126.

For self (un)muting and similar actions. See https://support.google.com/hangouts/answer/2752487?hl=en

Looks like the recent changes broke screen sharing for chrom(e/ium)

Once you're muted but jangout supposed you are speaking then it will notice you by text and audio, we should have an option can disable it.

Allow the users to change their name during the session

In the past, the buttons for muting or disabling local video really disabled the corresponding channels of the stream locally. Now the channels remain activated but are not sent to the other peers. That is great for audio because it allowed us to implement #27. But for video is not that great. The user can still manage to see their own video and may think that it's being transmitted. So disabling the local video channel in addition to stop sending it would give us the best of both worlds and should be easy to implement with some git archeology.

With new versions of the Janus package some extra steps are required.

The thumbnails of the participants are automatically resized to make sure they all fit in the roster area. But there is a bug somewhere and in some situations the resized thumbnails don't fit and a scroll bar appears (instead of using smaller thumbnails).

Jangouts is getting bigger and bigger so, IMHO, we must build a test suite.

janus.js added volume detection recently (meetecho/janus-gateway@66b4afa), it would make sense to rely on it instead of using hark. Less dependencies, more integrated solution.

We had a call yesterday, and somebody muted somebody else. That person was not able to speak anymore as there was no way to unmute him...

Geeko makes no sense anymore. There is no other (open)SUSE branding in the tool.

If you close a window that you're sharing, Firefox just crashes. Confirmed with Firefox 37.0.2.

Thanks @bmwiedemann for reporting this issue.

Would be useful to be able to configure a keyboard shortcut for push-to-talk like with mumble.

Like it happens in Google Hangouts when you join a crowded session.

The current UI is not much friendly for devices with a small screen. Moreover, the CPU of mobile devices do not cope very well with many videos being rendered at the same time. Thus, the mobile interface should reduce the number of live videos, maybe rendering only the active one.

When somebody mutes the user, we display a toastr notification. We do the same you the user tries to speak but is muted. It would be cool to include a unmute button in those notifications.

Information linked from here could be useful: Foxandxss/angular-toastr#3

It would be easy to base the implementation on this e228bee

After implementing #39 I'd like to explore the posibility of making that interface more flexible with the possibility of arranging the elements (list of participants, chat, etc.) in a flexible way. Inspiration:
http://www.dockspawn.com/
http://docker.webcabin.org/

We use Jangouts for long meetings with a lot of people. Sometimes, the audio stream from user A to user B stops working. Video still works and other participants can still hear A. When that happens, there are A LOT of errors like this being thrown to the Janus log

[ERR] [ice.c:janus_ice_send_thread:3124] [3945424720] ... SRTP protect error... err_status_replay_old

As a workaround, we use the ignore functionality to restart the connection between A and B, so everything works fine again. But that's just an ugly workaround, we need to prevent the error from happening at all.

If I try to highlight text from the chat pane in order to copy and paste, it just drags the pane around.

Introduced by me in 0a22c85

Currently the only way to disable the webcam in Chrome is to refuse Jangouts permission to access it, but this also refuses permission to the microphone, which is obviously useless. I would like to be able to use Jangouts in voice-only mode, even if others are using their webcams. This is supported by Google Hangouts.

If I rearrange the position/size of the panes on the meeting page, the new layout gets lost when I reload the page. This should be persisted either locally via cookies, or server-side per user account.

The following error is logged to the console every time a remote feed disconnects.

this.connection.getConfig(...) is undefined

Since some users are way to loud and others very quiet it should be possible to control the volume per user.

Right now, the limiting factor for big meetings is the CPU usage needed to render all the videos in the clients. Bandwidth and CPU power on the server seems to not be a big issue. We should create alternative user interfaces less CPU hungry.

A first approach could be to only render the main video, keeping the thumbnails as audio-only.

We could need to investigate which situations produce the highest CPU consumption.

More elaborated solutions can be tried, like rendering video only for participants that are speaking and/or moving (with motion detection in the publisher side).

Better embedded views for those tools. Some of then can require API keys, though, making it more difficult.

The main feed (the big video) does not always fit the whole space, sometimes it's smaller and almost never is centered.

When you have just joined a room, the setup (sending the configure and so on) can take some seconds. If the user speaks during that period the "you are muted" notification is displayed. Once the setup finishes, the user is not muted anymore. Unexpected and confusing.

Self-explanatory

At this time, user is always connected to the room '1234'. This feature is intended to let the user to choose a room to join.

I see that to Ignore someone means turning off their

• video
• audio
• chat messages

That may be OK for an annoying person in a public chat, but our use case is cancelling echos when sitting in the same room. For that, you should definitely see the chat messages (with links to issue trackers) and possibly also the video (if the other party is sitting back to back with you).

We have discussed two approaches here.

1. Use the integrated recording feature in Janus, which produces one .mjr per each audio and video stream. We could use then the streaming plugin to recreate the meeting in a similar way to what is done in this demo (code available) https://janus.conf.meetecho.com/recordplaytest.html We would probably need to store some additional data (like the list of participants) in order to be able to recreate the session effectively. Data channels would be most likely lost, since I don't think they are currently recorded by Janus. The good part is that the recording could be "interactive", i.e. allowing selection of the participant to highlight in each moment, browser resizing, layout rearranging and so on.

2. Connect to the room with a "ghost" participant that will run a browser and simply record what is rendered in the browser. It needs almost no special support server-side and everything will be recorded (including chat messages). But the result would not be so flexible.

The chat window should also show events (like participants joining/leaving). Probably, some events should be, in addition, displayed using Toastr or a similar mechanism.

Architecturally, the feature is planned (using ActionService), but some more events (like muting) should be moved to ActionService as a first step.

Despite not being in the room anymore.

a sqwiggle mode would be cool :)

This is a full-screen window on my Laptop.
![jangouts](https://cloud.githubusercontent.com/assets/336868/8157413
/eb5775b2-1354-11e5-8d58-5fd12ba8ddf5.png)

For turn-based meetings it would be useful to have a button which automatically mutes the only current speaker and un-mutes the next one in the list of feeds.

When a user press the browser's back button while being on a room, he goes back to the login screen without actually quiting the room, so he can join twice.

Jangouts should support a list of people who are supposed to join a call/room, e.g. the YaST room, so that it's easy to see who is missing.