I have a webRTC video which is working as expected between Chrome on PC and Chrome on mobile but if the internet connection is disrupted on the mobile it will not resume the webRTC video when it is back online, however it will resume correctly if it is the Chrome on PC that has the internet disrupted.
It is the same implementation used regardless of device or browser and chrome mobile seems to support webRTC the same as desktop (https://caniuse.com/?search=webrtc), why might it be failing on mobile chrome?
I have the below 'oniceconnectionstatechange' function:
pc.oniceconnectionstatechange = event => {
if (pc.iceConnectionState === 'failed') {
pc.restartIce()
}
}
I think you are seeing the different behaviors because of your NAT Mappings. It could be something else, but with the details we have that is my first guess.
When the connection is disrupted on desktop (and then returns) you are keeping your NAT Mapping. When the connection is disrupted on mobile maybe you are getting a new one. You could confirm the behavior yourself by sending UDP packets from your phone and printing out the src details on a world routable server.
The proper way to reconnect a peer is to do an ICE Restart. That ensures that even if your network path changes you will reconnect.
Related
I've been investigating the implementation of CTAP2 protocol with Google Chrome (protocol between Fido Authenticator and Fido Client (e.g. Chrome)), which should be supported in Chrome since version 69.
So I dumped the chrome request to the authenticator in two cases:
1. U2F (CTAP1) with yubico demo website.
Here everything goes as expected and chrome follows the CTAP1 protocol.
2. FIDO2/Webauthn (CTAP2) with webauthn.org
And the browser has a strange behaviour:
It starts by following the CTAP2 protocol by sending a AuthenticatorGetInfoRequest
The Authenticator replies with AuthenticatorGetInfoResponse
But then Chrome switches to the CTAP1 protocol by sending a Registration Request Message (U2F_REGISTER)
Is it a problem with Chrome implementation: CTAP2 is not enabled entirely yet (it seems to be implemented in Chromium sources)?
Or is the problem coming from the authenticator: sending a response that makes Chrome switch to CTAP1?
Or something else entirely?
In AuthenticatorGetInfoRequest, the authenticator must respond with a string list of the supported versions among "U2F_V2" and "FIDO_2_0". Note also in case of NFC or CCID, a "FIDO_2_0" (CTAP2) only authenticator shall anwser directly "FIDO_2_0" on the SELECT command. I don't know about HID and BLE.
So maybe your authenticator is listing "U2F_V2" in the protocol versions list in AuthenticatorGetInfoRequest.
I also imagine the Chrome code base about this was moving fast and can be partial or not strict. To my tests in early 2020, the Chrome CTAP capabilities seem now stable and compliant.
I am using webcam.js for getting a photo clicked of a customer for profile creation on my cloud based retail store software.
It used to work fine in earlier versions of chrome and is still working fine on firefox. But now latest version of chrome and even other browsers like Opera have started throwing errors on invoking webcam - only https versions are allowed to use webcam.
Its a personal use software and i don't want to spend extra on a SSL certificate. Is there some option where in we can add exception for a http site to use webcam
Current Code:
function loadCamera(){
Webcam.attach( '#my_camera' );
Webcam.set({
width: 200,
height: 200,
dest_width: 200,
dest_height: 200,
force_flash : true
});
}
You could check out letsencrypt or certbot (basically the same). They issue SSL certificates for free and the setup is very straightforward and easy.
Link:
https://letsencrypt.org/
I'm using a standard video tag like so <video src="test.mp4" controls></video>. I'm in a SharePoint 2013 environment with NTLM authentication with basic authentication as fall back. The video tag works without issue on all desktop browsers that support HTML5 video.
On mobile browsers, the video tag fails once I authenticate to the site. The video is just static public content that is being served by IIS 8 and is not a part of SharePoint. The only exception so far is Firefox on android, which works without issue. I've removed NTLM auth and switched to basic auth only with the same results.
I've tested so far:
iPad iOS 8 - Safari, Chrome
Android K & L - Chrome, Firefox
Windows Phone 8.1 - IE
The video works as long as I am not authenticated to the host where the video is located. So, if I am at host1 with markup pointing at a video on host2, the video will work until I authenticate to host2.
The video will also work fine if I'm going through a forms based authentication. In my case, I'm using Microsoft TMG.
I've gotten this far with Android Chrome: It will first send a range request with 0-1 byte as expected with Chrome as the user agent. When unauthenticated, it will ask for the rest of the video with stagefright as the user agent. When authenticated, it doesn't send anything and simply fails to play the video. ADB logcat returns this when that happens:
E/StagefrightMetadataRetriever( 183): Unable to instantiate an extractor for 'snipped-video-url'.
E/MediaResourceGetter(11682): Error configuring data source
E/MediaResourceGetter(11682): java.lang.RuntimeException: setDataSource failed: status = 0x80000000
E/MediaResourceGetter(11682): at android.media.MediaMetadataRetriever._setDataSource(Native Method)
E/MediaResourceGetter(11682): at android.media.MediaMetadataRetriever.setDataSource(MediaMetadataRetriever.java:105)
E/MediaResourceGetter(11682): at org.chromium.content.browser.MediaResourceGetter.configure(MediaResourceGetter.java:417)
E/MediaResourceGetter(11682): at org.chromium.content.browser.MediaResourceGetter.configure(MediaResourceGetter.java:259)
E/MediaResourceGetter(11682): at org.chromium.content.browser.MediaResourceGetter.extract(MediaResourceGetter.java:153)
E/MediaResourceGetter(11682): at org.chromium.content.browser.MediaResourceGetter.extractMediaMetadata(MediaResourceGetter.java:125)
E/MediaResourceGetter(11682): Unable to configure metadata extractor
I/MediaFocusControl( 744): AudioFocus requestAudioFocus() from android.media.AudioManager#2ff8d914org.chromium.media.MediaPlayerListener#23b9af5d
D/MediaPlayer(11682): Couldn't open file on client side, trying server side
I/AwesomePlayer( 183): setDataSource_l()
My first thought was it was a Chrome/Safari issue, but IE behaving the same way makes it less likely. Is this by design? Any direction to figuring out what is going on would be appreciated.
Try this
i have a issue which is same as your issue(E/StagefrightMetadataRetriever( 183): Unable to instantiate an extractor for 'snipped-video-url'.).after doing lot of work finally find the way to correct that.
add this line in the manifest of your project
<uses-permission android:name="android.permission.INTERNET" />
Error
After Error
We are using Pusher on mobile devices (using html webview + javascript).
I am connecting to Pusher using the following script (loaded async to the page)
http://js.pusher.com/2.1/pusher.min.js.
and then initialise Pusher object:
var externalTrackingProvider = new Pusher(config.key, { encrypted: true });
var connection = externalTrackingProvider.connection;
connection.bind('connected', function() {
console.log("connected");
});
The process works well but the time between "new Pusher" and "connected" event can take up to 15!!! seconds on mobile devices. The average time between init and connected is 5-10 seconds. (the js file itself is pre-loaded so this is the actual connection time).
Our testing is done using high speed wifi network so this is not the issue here.
Is this a knows Pusher issue? Anything to be done in order to fix this?
EDIT
Following Mike's advise, I tested "http://test.pusher.com" using our webview on Samsung Galaxy S4, high speed wifi connection. The results are avarage of 3-4 seconds between "connecting" and "connected". Attached screenshot.
Edit2:
After sending the logs to Pusher it appears that Android webview does not support Websockets, which causes a js fallback which results in poor performance.
The solution should be some kind of webview websocket library
I'll try and update if it is working
It should all be done in well under a second. You can use test.pusher.com with the same browser and network connection to see the messages passed back and forth and at what stage the latency is being introduced. Some fallbacks where websocket connections fail require the loading of further code, may involve a timeout to consider the initial attempt failed and require more round-trips than a websocket in order to create a connection.
I try to play some mp3 files via the html5 audio-tag. For the desktop this works great (with Chrome), but when it comes to the mobile browsers (also Chrome (for Android)), there seem to be some difficulties:
I protected the stream with some password an therefore the streaming server needs to find a special authentification cookie (spring security remember-me). But somehow the mobile browser doesn't send this cookie when it accesses the mp3-stream via the audio tag. When I enter the stream URL directly to the address bar everything works just fine.
While I searched for the lost cookie I found out, that the mobile browser still sends some cookies (e.g. the JSESSIONID) but not all. Further investigations (quick PoC with PHP) revealed that the mobile browsern seems to refuse to send cookies via the audio-tag which have the HttpOnly Flag set. So my question is:
Is this a specified behaviour, why are there differences between the mobile and the desktop versions (of Chrome) and is there a way control the behaviour from the client side?
By looking more deeply into the HTTP packages I found out, that the Android browser doesn't request the mp3-stream itself, but delegates this to stagefright (some android multimedia client). A quick search revealed, that for the old Android versions (before 4.0) stagefright cannot handle cookies:
https://code.google.com/p/android/issues/detail?id=17553 <-- (Status: spam) WTF...
https://code.google.com/p/android/issues/detail?id=17281
https://code.google.com/p/android/issues/detail?id=10567
https://code.google.com/p/android/issues/detail?id=19958
My own tests confirmed this. The old stagefright (Android 2.3.x) doesn't send any cookies at all, the stagefright from a european S3 (android 4.1.2, stagefright 1.2) sends only the the cookies which do NOT have the httpOnly flag.
So I think that everybody has to decide himself which solution he wants to use:
enable httpOnly: android has no access at all but its secure
disable httpOnly: less secure against XSS, but works for Android >4.0
disable cookie authentication at all: insecure but works for all
Note: The problem with simply disabling httpOnly is that you make your whole application vulnerable to cookie hijackers. Another possible solution would be to have a special rememberme cookie for the stream (without httpOnly) and another rememberme cookie with httpOnly enabled.
I had the same problem and disabling HttpOnly or Secure flags on cookies didn't solve the problem on Android 4.2 and 4.4 chrome browser.
Finally I figured the cause. I had a cookie with its value containing special characters colon ( : ) and pipe ( | ), etc. After disabling that cookie with special characters the videos play fine in Android 4.2 and 4.4.
Hope this helps someone.