Comments (17)
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?
from jssip.
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.
from jssip.
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.
from jssip.
@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.
from jssip.
@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.
from jssip.
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?
from jssip.
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.
from jssip.
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
from jssip.
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.
from jssip.
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 :-)
from jssip.
Yes, I have updated the issue subject from "Cache local media access rights" to "Cache local media stream".
;-)
from jssip.
Sorry, my mistake on creating a subject ;)
from jssip.
Do not worry at all @pedrokiefer ;-)
from jssip.
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...
from jssip.
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.
from jssip.
Just tried jssip with https, there is 'always allow this site to use this microphone' in options dropdown menu.
from jssip.
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).
from jssip.
Related Issues (20)
- Allow set JSSIP.UA extra_headers in runtime HOT 2
- resetLocalMedia is declared but not implemented HOT 1
- Make a call with error 488 Not Acceptable Here How to fix it HOT 1
- JsSIP Logger Override Functionality Not Working As Expected in v3.7.7 HOT 1
- UnMute Call HOT 2
- How not to get microphone permission HOT 1
- For SIP server Account Register Working? HOT 2
- Abnormal session cancellation method under race condition
- Type definition errors in 3.10.0 HOT 1
- Error when getting video track status on Firefox
- Play audio or tone to remote user. HOT 2
- The new JsSIP.UA(configuration).call method does not return the status after execution
- import JsSIP from "jssip"; 打印JsSIP undefined HOT 2
- Error 'setLocalDescription' on Chrome HOT 1
- BYE: Request-URI does not point to us HOT 33
- Incorrect SDP a=sendrecv in firefox HOT 7
- I want to send and Receive message using JSSIP
- Sending a silent stream on latest Chrome HOT 1
- Error when trying to change the microphone during a call HOT 1
- Add custom header JsSIP - Asterisk HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jssip.