Cache local media stream

[pedrokiefer]

For each call made or received the user has to allow the browser to access the camera or microphone.
I think the stream from webkitGetUserMedia can be cached. Someone else said something related to this on the list.

[ibc]

Let's plan it (for now) for 0.3 release (unless it becomes too complex to implement). I also expect that WebRTC browsers will provide some way to auto-accept local media rights in the future (maybe based on a previous local media usage in the same web session, not sure).

BTW: Would this feature introduce changes in the API? or would it be 100% transparent for the developer?

[saghul]

Hum, I have some concerns about this. IIRC there are 2 things to consider: whether the user allows you to use both camera and microphone, and whether you actually use them. Once you get the media description with getUserMedia constraints can be applied to just get a single track (audio or video).

So, if on start, the user only allows the mic and later he wants to use video? There would be no other way than reloading the page?

Caching that would be a good idea, indeed. Somewhat having a global local media object, which can be overwritten again later, if the user decides to do so. JsSIP would prompt the user only if there is no cached local media, for example. Since it can be overwritten, a new local media could be used in case the user decides to enable video later, for example.

@ibc I think it would definitely introduce a new API function (at least), since the user needs to be able to tell JsSIP about the local media stream it needs to cache.

[jmillan]

AFAIK, this is done at browser level. Google chrome does already implement it. It permits setting a 'allways allow' option in the drop down menu if the web is being retrieved via https. This setting can be later be flushed by the browser advanced settings: Privacy -> Media -> Manage exceptions.

I guess all browsers will implement it and they will only permit websites using https also.

I don't think this should be managed by the JavaScript, but I may be wrong.

[saghul]

@jmillan I see this feature request as a way to do that in "user space" lets say. Somehow in a per-session basis. Actually, this would also solve the problem when a user wants to specify the local media stream by himself because it was gathered by other means.

[jmillan]

@saghul It is not the same. The local media stream is a LocalMediaStream object retrived from a getUserMedia which can be stored in a JavaScript variable (UA.streams dictionary or so) without any problem, and be attached to a PeerConnection anytime. It is appart of the access rights stuff, which permits not asking the user for camera and micro acceptance for a given website.

[saghul]

But isn't the effect the same? If I cache the LocalMediaStream I don't need to ask the user for permission again, do I?

[jmillan]

Tomorrow you will access again the website and it will ask you for camera an micro access rights. This stuff is what is implemented in the browser. Once you have accepted, yes, you can store such local media stream for future use.

I agree with allowing making an outbound call specifiying the local media stream to be used, of course.

[saghul]

José Luis Millán wrote:

Tomorrow you will access again the website and it will ask you for
camera an micro access rights. This stuff is what is implemented in the
browser. Once you have accepted, yes, you can store such local media
stream for future use.

Sure, but if I would use a tab as a phone, having to allow the thing
every time could easily get annoying. Yes, if using HTTPS Chrome can do
it for you, but can we guarantee that all browsers will do that?

I agree with allowing making an outbound call specifiying the local
media stream to be used, of course.

Exactly. AFAIS just by implementing this second thing we get both :-)

Saúl Ibarra Corretgé
http://saghul.net/blog | http://about.me/saghul

[jmillan]

I don't think so. We will (and are) able to store the local media stream, but not (I don' t think so) the access rights for the camera and micro.

Once the access is granted (the first time in the web session), there is no need to ask again for camera and micro since we have the local media stream that those devices are generating, But only 'once' is has been granted.

Chrome does allow saving the grant policy for a specific website so getUserMedia won't ask the user for access rights.

[saghul]

Well, the reason for caching the local media is exactly that. Avoid being asked for auth over and over again. You would only be asked the first time, that's acceptable.

Looks like we are on the same page then :-)

[jmillan]

Yes, I have updated the issue subject from "Cache local media access rights" to "Cache local media stream".

;-)

[pedrokiefer]

Sorry, my mistake on creating a subject ;)

[jmillan]

Do not worry at all @pedrokiefer ;-)

[ibc]

Let me some (probably) stupid questions about this subject:

• Does "cache local media stream" mean that the webcam is always turned on after the first time?
• I assume the answer is not, but then, if it's possible to avoid the browser asking for media consent in every WebRTC session, is not that a WebRTC vulnerability? Imagine a web page that asks you for webcam consent, you accept it. Later the session is closed, and much later the web app starts using your webcam to send your video to some place without you knowing it.

Just wondering...

[ibc]

James Wyatt commented this in the maillist:

For the caching of media access, you can override the navigator.webkitGetUserMedia with your own function. Something similar to this:

// start
var getUserMediaFunction = navigator.webkitGetUserMedia;
var storedstream;

navigator.webkitGetUserMedia = function(mediaType, successCallback, failureCallback){
    function success(stream) {
        storedStream = stream;
        storedStream.stop = function(){}
        successCallback(storedStream);
    }

    function failure() {
        failureCallback();
    }

    if(storedStream) {
        successCallback(storedStream)
    } else {
        getUserMediaFunction.call(this, mediaType, success, failure);
    }
}

navigator.webkitGetUserMedia({audio:true, video:true}, function(){}, function(){});
// end

This would be done outside of JsSIP. After a bit of digging it seems that for persistent storage of selected permissions for chrome it will provide an option to remember settings if it is hosted under https.

[iwanbk]

Just tried jssip with https, there is 'always allow this site to use this microphone' in options dropdown menu.

[ibc]

This is useless and means that the webcam is active all the time. Not user friendly at all.

However JsSIP will allow, in the future, passing a local stream when generating a session so this issue is no longer valid (since it could be implemented at application level soon).