2017-06-30 08:42:02.920Z | WARN in [createLocalTracks #1]: Call to getUserMedia failed: MediaStreamError { name: "InternalError", message: "Starting video failed", constraint: "", stack: "" } twilio-video.min.js:92:26979
Unable to access local media MediaStreamError { name: "InternalError", message: "Starting video failed", constraint: "", stack: "" }
Twilio developer evangelist here.
You have an issue with system resources here. One app can only get access to the camera at a time, so if it's being used by Chrome, then Firefox can't access it.
I recommend just testing in one browser, possibly using private mode so you can log in as a different user.
Make sure you handle the error case when you can't get access to the camera too.
Related
Intro:
was created a Google Smart Home project
was configured a proxy server via ngrok to redirect the Google request to my local machine
I develop an IoT project that has the ability to open/close a lock. I need to implement Google integration to use the Google Assistant to control the user locks. I have implemented OAuth Server for Google. Also I have implemented some controllers to handle Google Action Intents: SYNC, QUERY and EXECUTE. Google send a request with the SYNC intent and App response a payload that contain devices list with specific settings. Instance:
{
requestId: 'requestIdOfGoogle', // contains in the request body
payload: {
agentUserId: 'userId123', // matches user id inside app system
devices: [
{
id: 1,
type: 'action.devices.types.LOCK', // device type
traits: ['action.devices.traits.LockUnlock'], // feature that has a device
name: {
name: 'Kos Lock'
},
willReportState: true,
roomHint: 'Main Door',
deviceInfo: { // Test data
manufacturer: 'smart-home-inc',
model: 'hs1234',
hwVersion: '3.2',
swVersion: '11.4'
}
}
]
}
}
Then Google send requests to my server with QUERY intent to get info about state of a devices, instance
{
requestId: 'requestIdOfGoogle', // contains in the request body
payload: {
devices: {
1: {
status: 'SUCCESS',
online: true,
isLocked: true,
// isJammed - Boolean. Whether the device is currently jammed and therefore its
// locked state cannot be determined.
isJammed: false
}
}
}
}
But after sending a response a test lock isn't configured and a user can't control one with Google Assistant.
enter image description here
I have tried to add other traits for a lock but it didn't help me. Also I have the same problem when I try to configure a Door device. But when I send to Google a Light device it works successfully. When you use the LockUnlock trait then Google Doc recommends to setup secondary user verification but it's optional.
I don't understand that do incorrect. If someone faced such a problem and solved it then could you help me, please
Prerequisites:
use node ^14.0.0
programming language - js
Touch controls are not supported for every device, and locks are not a device type that can be controlled directly. But they will still respond to voice commands.
I'm trying to get the price for stock option for the Japan "6503" stock, and I get the error:
Error code 10197 No market data during competing live session
I don't have subscription for Japan Market, but I still can see the "last price" for the option in TWS User Interface (not for all but for some option contracts, for some it's unavailable and displayed as "n/a").
Question - it seems like this error code - is not actually an error and could be ignored, is that true? The error doesn't make sense at all as I don't have any competing session or paper session.
I'm using the TWS Java API with the following code to get the price:
val contract = Contract()
contract.exchange("OSE.JPN")
contract.currency("JPY")
contract.conid(455178173)
contract.secType(Types.SecType.OPT)
client.reqMarketDataType(MarketDataType.DELAYED_FROZEN)
client.reqMktData(request_id, contract, "", false, false, null)
I'm using the conid 455178173 to get the price, if you need the full info about the option, here it is:
symbol: "6503",
right: "call",
expiration: "2021-01-07",
strike: 1200.0,
option_exchange: "OSE.JPN",
currency: "JPY",
This error happens when you have a "live" session thats competing for data. Which means you have a live TWS terminal thats showing the live data and you are requesting data from your Paper account via the API.
The API won't return the requested data (showing this error) because the same data is being sent to the live account.
I am trying to implement the project from https://www.twilio.com/blog/serverless-phone-verification to verify phone number using SMS TOTP.
When I created new function the url given by Twilio Functions is https://isabelline-badger-5492.twil.io/sendTOTP
I have given the VERIFY_SERVICE_SID env variable to point to correct value ‘VAxxxxxxx’.
But I am getting error as below. Please advise what is wrong.
The Verify functions works fine by itself, but when triggered from Functions, it throws below error.
{
"success": false,
"message": {
"status": 404,
"message": "The requested resource /Services/VAxxxxxxx/Verifications was not found",
"code": 20404,
"moreInfo": "https://www.twilio.com/docs/errors/20404"
}
}
Make sure the Twilio helper library your Twilio Functions are using is up to date (3.29.2 is to old to use this newer feature). If using the Console based functions, you can find and set the version here, for twilio. Make sure to click save. The latest helper library version as of this response is 3.37.1. This will fix the issue.
When I try to start the process in BPM on rest I get an error:
Result:
{
status: "error",
Data:
{
status: "error",
exceptionType: "com.ibm.bpm.wle.api.CannotStartBPDWrongStateException",
errorNumber: "CWTBG0586E",
errorMessage: "CWTBG0586E: Cannot start BPD because the snapshot or BPD is in the wrong state.",
errorMessageParameters: null,
responses: null,
errorData: null
}
}
Then I do everything as described in the video:
https://www.youtube.com/watch?v=sD1_BHFHP4Y&list=PL7D328AAEB82FE141&index=9
But in my rest it does not work and the error is the same.
The status snapshot remains active.
version BPM - 8.6.
I was able to solve my problem by iterating through the input parameters. To be able to start a task, I had to exclude from the request "snapshotId" and add "processAppId".
After that, I received an answer of 200 and the task started.
Version IBM Bussiness Process Manager Server 8.6.0.0 CF2018.03
My web application is failing to gather WebRTC relay ICE candidates via a CoTURN server when using Safari 11 on iOS 11 (iPhone 5s & iPhone 7) or desktop. The web application (which establishes a one-way audio only WebRTC peer connection) works fine between the real browsers (Chrome and Firefox) either direct or via CoTURN relay, and I normally get 6-15 ICE candidates on these browsers.
I have a (frankly, unnecessary) call to getUserMedia on the receiving side, which allows host ICE candidates to be produced by Safari. (Note... the user must approve audio and/or video access before Safari will provide host Ice Candidates, even if on a receiving-only end. I'm past that hurdle, but just so you won't hit it too... This is out of "privacy" concerns.). Before I added the allow getUserMedia, I received no ICE. Now I receive two candidates. One with a private IPv4 and another with an IPv6. This is enough to get the app working properly when on the same machine or local network. So I'm pretty confident with other parts of the application code. I am not sure if my problem is with the application code or the CoTURN server.
Example of the ICE candidates received:
{"candidate":{"candidate":"candidate:622522263 1 udp 2113937151 172.27.0.65 56182 typ host generation 0 ufrag r23H network-cost 50","sdpMid":"audio","sdpMLineIndex":0,"usernameFragment":"r23H"}}
I pretty sure the RTCIceServer Dictionary for my RTCPeerConnection is inline with the following standards:
https://w3c.github.io/webrtc-pc/webrtc.html
https://www.rfc-editor.org/rfc/rfc7064
https://www.rfc-editor.org/rfc/rfc7065
And I've tried multiple variations of parameters:
// For Example:
var RPCconfig = {
iceServers: [{
urls: "turn:Example.live",
username: "un",
credential: "pw"
}]
};
// Or:
var RPCconfig = {
iceServers: [{
urls: "turns:Example.live",
username: "un",
credential: "pw",
credentialType: "password"
}, {
urls: "stun:Example.live"
}]
};
// And even more desperate attempts...
var RPCconfig = {
iceServers: [{
urls: "turn:Example.live?transport=tcp",
username: "un",
credential: "pw",
credentialType: "password"
}]
};
Here's an example of the signaling process log for an idea of what is going on. This is from the receiving side, which is Safari 11. The other browser was Chrome (compare 6 vs 2 ICE candidates). The state change refers to oniceconnectionstatechange.
SDP Offer received.
Sending signal SDP
Sending signal IceCandidate
Sending signal IceCandidate
ICE Candidate Received
4:08:25 AM State Change -> checking
ICE Candidate Received
ICE Candidate Received
ICE Candidate Received
ICE Candidate Received
ICE Candidate Received
4:08:40 AM State Change -> failed
CoTURN is configured quite liberally in terms of accepting every possible transport method as far as I am aware. It works well for providing ICE Candidates and as a relay for the other browsers.
Any direction would be greatly appreciated. Even if it is just a sample RTCIceServer Dictionary code that works or a proven TURN server to try.