I've been quiet on the list and perhaps this has already been discussed. My primary concern has to do with the way users interact with their browsers and tying the lifetime of the streaming sessions to the javascript on a webpage. Given the proposals, javascript will likely be used to setup streaming sessions and thus there will need to be automatic clean-up of these sessions when the related javascript objects are closed when a website page is "closed". This in my opinion can cause major issues with users. In my own situation, I have a list of common viewed websites at the top of my browser and a simple accidental click will go to those new pages. I frequently click on those pages accidentally. If I'm simply viewing email, no big deal, I hit the back and while I'm annoyed I can easily recover. With a call in progress this will no longer be the case. The entire session state will be destroyed, the calls will tear down immediately as a result of the lifetime of streams being tied to the lifetime of the javascript objects on the page. I think practically speaking this will happen often. Users will be in a call with each other and say "have you seen that new cool video", and most non tech savvy users will simply type the search into their browser window and their search bar and the browser javascript will be torn down and bring down all the RTP streams thus ending any active communication as a result. How annoying it would be to have established calls torn up/down based on typical browser usage by a user! Expecting users not to navigate while calling is impractical and expecting users will open new browser tabs will be unworkable, especially to anyone like me has had to support family members confusion over browser tabs and accidentally closing what they are working on... I think the depth of this issue is unique to RTC-WEB proposal. Of course, I've seen this issue with videos and other places - where you are in the middle of watching a video, click to a new page and then come back to have the video start over and if it doesn't index itself properly will have to download and play from the beginning. Youtube has done a lot to solve those usability issues by doing many intelligent work arounds and keeping currently locations pretty accurate when going "back". But I fear no such work arounds will be easy or possible with RTC-WEB and solutions could open up new cans of security worms. For example, reopening a closed page with the "back button" could cause re-open a previously accidentally closed media sessions but could also open an intentionally closed sessions. Re-opening the connection automatically based on going "back" to a previous page could be embarrassing if you did actually intend to end the call and then the microphone was re-opened automatically broadcasting to the previous person you were connected. To keep media sessions alive even as users click around implies the lifetime of the call exists outside the active browser page. But this opens up other issues. For example, when does the call get automatically torn down if they leave the site? Or where are the controls for the call going to exist outside the site if the page with the controls is closed? (and the browser would have no understanding of what controls should be presented when navigating off the page since every website will have their own call control definitions). So maybe I'm missing something important like other browser future technologies introduced in conjunction with RTC-WEB (e.g. application based web sites) but I don't understand how RTC-WEB is going to get around these javascript-tied-to-a-webpage lifetime issues... Regards, Robin Raymond hookflash