We Keep Coding

Implementation of JsSIP on actual phone

I just took a look JsSIP library, and it seems pretty promising except the fact that it has no actual demonstration or code which implements calling actual mobile phone. so is it actually possible to call phone which is in offline mode or in online? here is code on docs
var ua = new JsSIP.UA(configuration);
ua.start();
// Register callbacks to desired call events
var eventHandlers = {
'progress': function(e) {
console.log('call is in progress');
},
'failed': function(e) {
console.log('call failed with cause: '+ e.data.cause);
},
'ended': function(e) {
console.log('call ended with cause: '+ e.data.cause);
},
'confirmed': function(e) {
console.log('call confirmed');
}
};
var options = {
'eventHandlers' : eventHandlers,
'mediaConstraints' : { 'audio': true, 'video': true }
};
var session = ua.call('sip:bob#example.com', options);
even demo is implementing call within browsers, which is more easily done with WebRTC but i want to call phone. how is that possible, if it is possible in OFFLINE mode it would be better

You need first to look for a PSTN provider that provides you with a SIP account to make calls to phone numbers. That's not free typically. Then you probably want to configure such a SIP account in your SIP server and router calls from JsSIP to the PSTN provider. And deal with accounting and so on. Not something trivial.

OpenTok accessDenied issue in Chrome

I'm having some trouble with the OpenTok 2 API. When I start to publish a stream and I'm prompted to allow or deny the website to use my webcam and microphone, if I allow allowed() should run, but if I deny denied() should run.
publisher.addEventListener('accessAllowed', allowed);
publisher.addEventListener('accessDenied', denied);
function allowed() {
console.log('Allowed');
}
function denied() {
console.log('Denied');
}
It works as expected in Firefox. In Chrome accessAllowed works, however, accessDenied doesn't. Instead I get the following error:
OT.Publisher.onStreamAvailableError PermissionDeniedError:
TB.exception :: title: Internal Error (2000) msg: Publisher failed to access camera/mic:
Any ideas?

This is a bug in the current JS library at OpenTok. I do have a workaround that should get you going and I'll come back with an update when the bug is fixed.
var waiting = false;
publisher.addEventListener('accessAllowed', function() {
waiting = false;
allowed();
});
publisher.addEventListener('accessDenied', function() {
waiting = false;
denied();
});
publisher.addEventListener('accessDialogOpened', function() {
waiting = true;
});
publisher.addEventListener('accessDialogClosed', function() {
setTimeout(function() {
if (waiting) {
waiting = false;
denied();
}
}, 0);
});
This workaround is slightly limited because Chrome has some weirdness when it comes to denying access once and then visiting the page again. If the user hasn't changed his/her preferences regarding the media permissions, the video will continue to be denied and the 'accessDialogOpened' won't even fire. I'll inform the team and continue to look into this.

navigator.geolocation.getCurrentPosition doesn't work on android google chrome

This code:
navigator.geolocation.getCurrentPosition(
function(position) {
alert(position.coords.latitude, position.coords.longitude);
},
function(error){
alert(error.message);
}, {
enableHighAccuracy: true
,timeout : 5000
}
);
https://jsfiddle.net/FcRpM/ works in Google Chrome at my laptop, but on mobile HTC one S (android 4.1, GPS off, location via mobile networks and wifi enabled), connected to internet via WiFi.
Default browser works fine.
Google Chrome, Opera, Yandex.browser for android fails with "Timeout expired".
other android apps locates me correct.

You can try this. It seems to work on my device (Samsung Galaxy Nexus running Chrome 27.0.1453.90 on Wi-Fi (no data connection, no GPS on))
navigator.geolocation.getCurrentPosition(
function(position) {
alert("Lat: " + position.coords.latitude + "\nLon: " + position.coords.longitude);
},
function(error){
alert(error.message);
}, {
enableHighAccuracy: true
,timeout : 5000
}
);
The problem is that alert only takes strings (in it's original form) however you are passing 2 doubles. Modify the alert box for example to alert('Hey', 'Hello'); and the output will be only Hey. Change the , to + and you'll get the concatenated strings HeyHello. You can't use a + sign inside the alert as the equation will be first executed and then displayed.
Hope this makes it clear.

THERE IS A WORKAROUND: to watchPosition call, and wrapping this in a 5 second wait before clearing the watchID. Code below;
var options = { enableHighAccuracy: true, maximumAge: 100, timeout: 60000 };
if( navigator.geolocation) {
var watchID = navigator.geolocation.watchPosition( gotPos, gotErr, options );
var timeout = setTimeout( function() { navigator.geolocation.clearWatch( watchID ); }, 5000 );
} else {
gotErr();
}
I haven't played around with the "options" values or the timeout delay at the moment, but the above code brings back accurate positioning info on every platform I've tried.

Just finished testing a bunch of mobile devices and the Javascript Geolocation. I used the example code from Google in order to make sure that the problem is not in my own code.
Chrome for Android 4.4 does not seem to work with GPS-only location services and neither does the 2.3 stock browser. They both need "High accuracy" - the use of wireless and 3G/4G networks.
The funny thing is that Firefox for Android works without any problems GPS-only. Only the stock Android browsers (Chrome + Mobile Safari) fail with GPS-only location settings.
And the rest of the gang - Lumia WP8 with GPS, Windows and Linux (both with ADSL) worked perfectly with any location settings.

Well, I ran into this problem yesterday and the issue was that the Geolocation API can only be used over HTTPS. It will work on http://localhost but for other devices, you need to be on a secure connection.
Hope it helps!

After many hours of seeking solution for error3, i only can reboot my phone, and geolocation starts work as usually. So bad...

It was working for me for every simulator but not for android devices
what worked for me was
navigator.geolocation.getCurrentPosition(
(position) => {
console.log(position);
},
(error) => console.log(new Date(), error),
{ enableHighAccuracy: false, timeout: 5000},
);
means instead of three argument I used only two means
{ enableHighAccuracy: false, timeout: 5000}

just add
"geolocation",
"location"
under permissions. Worked for me. :-)

Poor network performance with Websockets running on apple device

I am working on an HTML/Javascript running on mobile devices that is communicating with a Qt/C++ application running on a PC. Both the mobile device and the PC are on a local network. The communication between the HTML page (client) and the C++ app (server) is done using Websockets.
The HTML page is a remote control for the C++ application, so it is needed to have a low latency connection between the mobile device and the PC.
When using any non-Apple device as a client, data is sent to a rate between 60 to 120 frames/sec, which is totally acceptable. When using an Apple device, this rate falls to 3-4 frames/sec.
I also checked ping times (Websocket implementation, not a ping command from command line). They are acceptable (1-5 ms) for Apple devices as long as the device is not transmitting data. Whenever it transmits data, this ping time raises to 200ms.
Looking from the Javascript side, the Apple devices always send data at a consistent rate of 60 frames/sec, as any other devices do. However, on the server side, only 3 to 4 of these 60 frames are received when the client is an Apple device.
Does anyone have any idea on what can be happening?
Here is my Javascript code :
<script language="javascript" type="text/javascript">
var wsUri = document.URL.replace("http", "ws");
var output;
var websocket;
function init()
{
output = document.getElementById("output");
wsConnect();
}
function wsConnect()
{
console.log("Trying connection to " + wsUri);
try
{
output = document.getElementById("output");
websocket = new WebSocket(wsUri);
websocket.onopen = function(evt)
{
onOpen(evt)
};
websocket.onclose = function(evt)
{
onClose(evt)
};
websocket.onmessage = function(evt)
{
onMessage(evt)
};
websocket.onerror = function(evt)
{
onError(evt)
};
}
catch (e)
{
console.log("Exception " + e.toString());
}
}
function onOpen(evt)
{
alert("Connected to " + wsUri);
}
function onClose(evt)
{
alert("Disconnected");
}
function onMessage(evt)
{
alert('Received message : ' + evt.data);
}
function onError(evt)
{
alert("Error : " + evt.toString());
}
function doSend(message)
{
websocket.send(message);
}
window.addEventListener("load", init, false);
</script>
Data is sent from Javascript side using dosend() function.

Few ideas and suggestions.
Check if the client's WebSocket protocol is supported by the server. This question and answer discuss a case where different protocol versions were an issue.
The WebSocket standard permits implementations to arbitrarily delay transmissions and perform fragmentation. Additionally, control frames, such as Ping, do not support fragmentation, but are permitted to be interjected. These permitted behavioral difference may be contributing to the difference in times.
Check if the bufferedAmount attribute on the WebSocket to determine if the WebSocket is buffering the data. If the bufferedAmount attribute is often zero, then data has been passed to the OS, which may be buffering it based on OS or socket configurations, such as Nagle.
This question and answer mentions resolving delays by having the server send acknowledgements for each message.
To get a deeper view into the interactions, it may be useful to perform a packet trace. This technical Q&A in the Mac Developer Library may provide some resources as to how to accomplish this.

The best way to get some more insight is to use the AutobahnTestsuite. You can test both clients and servers with that suite and find out where problems are situated.
I have created QWebSockets, a Qt based websockets implementation, and used that on several occasions to create servers. Performance from Apple devices is excellent.
However, there seems to be a severe problem with Safari when it comes to large messages (see https://github.com/KurtPattyn/QWebSockets/wiki/Performance-Tests). Maybe that is the problem.

Does a Firefox Workers limit exist?

Im trying to create web Workers and post messages to them in cycle:
array.forEach(function (data) {
this.createWorker();
this.workers[this.workersPointer].postMessage({task: 'someTask', data: string});
}, this);
createWorker function:
createWorker: function () {
this.workersPointer++;
var worker = this.workers[this.workersPointer] = new Worker('Worker.js'),
storage = this;
worker.onmessage = function (event) {
if (event.data.error) {
storage[event.data.task + 'Errback'](event.data.error);
}
else {
storage[event.data.task + 'Callback'](event.data.data);
}
};
worker.onerror = function (error) {
storage.workerErrback(error);
};
}
Worker code:
self.addEventListener('message', function (event) {
self.postMessage({
data: data,
error: err,
task: event.data.task
});
}, false);
It works perfectly in Google Chrome. When I'm trying to run it in Firefox, it works only 20 times. Do Firefox web workers have a limit? I can't find information about it on mozilla.org. If there is no limit, what's the problem? Any ideas?

Just did some test of my own. For this, i changed the code a little bit:
Cycle:
for(var i=0;i<200;i++){
this.createWorker();
this.workers[this.workersPointer].postMessage({task: 'someTask', number:i});
};
createWorker function:
this.workers =[];
this.workersPointer = 0;
storage=[];
var createWorker= function () {
workersPointer++;
var myPointer = workersPointer;
var worker = this.workers[this.workersPointer] = new Worker('Worker.js');
worker.onmessage = function (event) {
if (event.data.error) {
alert(event.data.error);
}
else {
document.cookie=event.data.task+"["+myPointer+"]="+event.data.number;
}
};
worker.onerror = function (event) {
alert("Error: " + event.error);
};
}
Worker:
onmessage = function(event) {
postMessage({number:event.data.number*2, task: event.data.task});
};
After i run this, in chrome i got 66 cookies (including a nice blue crash window), in firefox i got 20. So both browsers seem to have worker limitations.
EDIT:
In Opera i get a console message:
Maximum number of Web Worker instances(16) exceeded for this window.

There is a setting in Firefox, called "dom.workers.maxPerDomain" which is by default 20.
However, there might not be any real performance gain in using more workers than you have cores in the computer. With a modern computer today that has hyper threading, I think using around 8 workers would be sufficient. Otherwise you might cause to much context switching that would instead introduce a bottleneck.
It all depends though, what you want to achieve.

For futher reference check out in Firefox
about:config
There's a parameter called :
dom.workers.maxPerDomain
Wich (at least in FF 33) is set to a default value of 20.
gl.
And as noted on this other stackoverflow question:
Each browser has web workers limitations (Firefox has 20, Chrome 60+, Opera 16); however, you can change it in Firefox -> dom.workers.maxPerDomain; as for your actual question, if you can or cannot avoid this limitation, I'm not sure. "Workers (as these background scripts are called herein) are relatively heavy-weight, and are not intended to be used in large numbers." Can you give an exact situation where you would want to use more than 20 workers? – Marius Balaban Nov 26 '12 at 22:34

I also played around with workers and tried to find an optimum for my case (encryption of strings). It was 8 too.
Similar question and discussion: Number of Web Workers Limit