OS/browser Related Issues: Plugin - Load - Flash - Only False

Download as pdf or txt
Download as pdf or txt
You are on page 1of 3

o Multi-line hold is not well supported by browsers and the webphone is handling it with mute workaround from second

cond line (for WebRTC engine only; other


engines has true multi-line hold/reload). You might disable this behavior by setting the multilineoop parameter to 2.
o JRE audio handling is not so robust on Linux and you might encounter audio open issues in some Linux/JRE/audio system combinations when using the NS
or Java engine.
o Video is implemented only with the WebRTC engine (the webphone will auto-switch or auto-offer WebRTC whenever possible on video request). WebRTC-
SIP video calls works only if there are a compatible codec on SIP side (H.264 or VP8). WebRTC-WebRTC video calls are expected to work in all circumstances
between same browsers if the users have a camera device. Video re-INVITE will not work with the webphone (use with SIP devices which initiate or accept
the video from start)
o There is no video support on old Safari versions (video is supported from iPhone 7 / iOS 11 / Safari 11)
o While video should work via WebRTC on all supported platforms, we recommend testing it first in your environment before to purchase if this feature is
important for you. Some SIP servers and devices doesn’t handle the video features correctly and this is very difficult to debug (We can’t offer support for
extra video features. It either works or not works in your environment depending on your SIP server and SIP peers capabilities).
o Screen sharing might require extra plugin and might not work in all browsers (however it was tested and confirmed to work with both Chrome and Firefox)
o Mizutech doesn’t provide direct support for the video functionality with third-party devices, because of the many bogus implementations and codec
fragmentation. You will have the maximum chance for the success if both parties are connected by WebRTC
o Conference support with local RTP mixer is implemented only in the NS and Java engines. While the enduser is on WebRTC, then local conference mixer is
not available which means that conference can be done only via server side dtmf control or conference rooms between webphones or by auto switching to
NS when available. Read more here.
o Some features might not work correctly between WebRTC and SIP. This is not a webphone limitation, but it depends completely on server side (your
softswitch or gateway responsible for WebRTC-SIP protocol conversion) and for the loss of direct mapping between WebRTC and SIP protocol capabilities
o Some features require also proper server side support to work correctly. For example presence, chat, conference, video, call hold, call transfer and call
forward. See your VoIP server documentation about proper setup

OS/browser related issues


There are many browser and OS related bugs either in the browser itself or in the plugins used for VoIP (native/webrtc/java/flash). Most of the issues are
handled automatically by the webphone by implementing workarounds for a list of well-known problems. Rarely there is no any way to circumvent such issues
from the webphone itself and needs some adjustment on server or client side.

Some chrome versions only use the default input for audio. If you have multiple audio devices and not the default have to be used changing on chrome,
Advanced config, Privacy, Content and media section will fix the problem.

Some linux audio drivers allow only one audio stream to be opened which might cause audio issues in some circumstances. Workaround: change audio driver
from oss to alsa or inverse. Other workarounds: Change JVM (OpenJDK); Change browser.

Incoming calls might not have audio in some circumstances when the webphone is running in Firefox with the WebRTC engine using the mizu WebRTC to SIP
gateway (fixed in v.1.8).

Java related:

These details are important only if for some reason you might wish to force the Java engine. However please note that these java related issue are not real
problems since when possible the webphone uses WebRTC or NS engines, especially as Java is not available in latest Chrome and Firefox anymore.

If the java (JVM or the browser) is crashing under MAC at the start or end of the calls, please set the “cancloseaudioline” parameter to 3. You might also set the
"singleaudiostream” to 5. If the webphone doesn’t load at all on MAC, then you should check this link.

One way audio problem on OSX 10 Maverick / Safari 6/7 when using the Java engine: Safari allows users to place specific websites in an "Unsafe Mode" which
grants access to the audio recording. Navigate to "Safari ->Preferences -> Security (tab) and tick "Allow Plug-ins" checkbox. Then depending on safari version:
-from the Internet plug-ins (Manage Website Settings)" find the site in question and modify the dropdown to "Run In Unsafe Mode".
-or go to Plug-in Settings and for the option "When visiting other websites" select "Run in Unsafe Mode". A popup will ask again, click "Trust"
You will be asked to accept the site's certificates or a popup will ask again, click "Trust". Alternatively, simply use the latest version of the Firefox browser.

Java in modern browsers is not supported anymore (the webphone will select NS or WebRTC engine by default).

If for some reason you still wish to force Java, then in Chrome versions prior September 1, 2015 it can still be re-enabled:
Go to this URL in Chrome: chrome://flags/#enable-npapi (then mark activate)
Or via registry: reg add HKLM\software\policies\google\chrome\EnabledPlugins /v 1 /t REG_SZ /d java

Java can be also re-enabled in Firefox 52 by configuring the Firefox setting plugin.load_flash_only to false.

(By default the webphone will handle these automatically by choosing some other engine such as WebRTC unless you forced java by the engine priority settings)
The webphone is not loading
Symptoms:
 If your html can’t find the webphone library files you might see the following errors in your browser console:
o Failed to load resource: …/js/lib/api_helper.js
o ReferenceError: webphone_api is not defined
 If not supported by browser or your webserver doesn’t allow the required mime types, then the page hosting the webphone might load, but you will not be
able to make calls (VoIP engine will not start)
Fixes:
 Missing library: Make sure that you have copied all files from the webphone folder (including the js and other sub-folders)
 Browser support: Make sure that your browser has support for any of the implemented VoIP engines: either Java or WebRTC is available in your browser or
you can use the NS engine (on Windows, MAC and Linux) or the app engine (on Android and iOS)
 Web server mime settings: Make sure that the .jar and .exe mime types are allowed on your webserver so the browsers are able to download platform
specific native binaries
 HTTPS: Set a SSL certificate for your website for secure http, otherwise WebRTC will not work in chrome
 Lib not found: If your webphone files are near your html (in the same folder) then you might have to set the webphonebasedir parameter to point to the
javascript directory
webphonebasedir
This setting is deprecated after 1.9 as the webphone should automatically detect its library path automatically.
If the html page, where you are including the webphone, is not in the same directory as the webphone, then you must set the "webphonebasedir" as the relative path to the webphone base directory in relation to your html
page.
The base directory is the "webphone" directory as you download it from Mizutech (which contains the css,js,native,... directories).
For example if your page is located at http://yoursite.com/content/page.html and the webphone files are located at http://yoursite.com/modules/webphone then the webphonebasedir have to be set to
'../modules/webphone/'
The webphonebasedir parameter must be set in the webphone_config.js file directly (not at runtime by webphone_api.webphonebasedir).
Default is empty (assumes that your html is in the webphone folder).

 NS engine download not found: you might have to set the nativepluginurl parameter to point to the ns installer file.
nativepluginurl
(string)
This setting is deprecated after 1.9 as the webphone should automatically detect its library path automatically.
The absolute location of the Native Service/Plugin installer. In most of the cases this is automatically guessed by the webphone, but if for some reason (for example: you era using URL rewrite) the guessed location is incorrect,
then it can be specified with this parameter.
The Service/Plugin installer is located in webphone package "native" directory.
Example:
“https://mydomain.com/webphopne/native/WebPhoneService_Install.exe”
Default value is empty.

The webphone is not starting


Symptom: The webphone user interface is loaded but nothing is happening (webphone doesn’t start / connect).
Solution: If the webphone doesn’t start or doesn’t connect, that means that most probably you haven’t set the necessary parameters (such as
serveraddress/username/password) and/or you haven’t called any of the API functions.

The webphone will start when one of the followings happens:


 Autostart: If the important parameters such as the serveraddress/username/password (and sometimes others such as the proxyaddress) are preconfigured
(set in the webphone_config.js, via the setparameter API call or passed by URL). In this case the webphone can auto connect if you haven’t set the autostart
parameter to 0.
 API triggered: even if the autostart parameter is set to 0 and/or the important parameters are not set yet, you can force the webphone start using the
start() API. The start API can also auto connect/register (if the above parameters are preset), otherwise you can connect later after you have set these
parameters with the register() API.
Other API’s (such as the call() API) might also trigger the start action on demand.

See this FAQ point for more details regarding auto start / auto register.

Note: There are multiple ways to initialize the webphone:


 Example 1:
o Set all the important parameters in the webphone_config.js and just launch the webphone html (any of the included skins or samples or your own including the
webpone_api.js). The webphone should auto start and auto connect.
 Example 2:
o Set only the serveraddress parameter in the webphone_config.js and just launch a html which also has a login page (such as the included softphone.html). In this
case the webphone should just stop at the login page (if there is no any cached credentials yet) waiting for the enduser to enter it’s username/password and the
start will be triggered from the OK/Login button
 Example 3:
o Set the autostart parameter to 0.
o Preconfigure the serveraddress (or other required parameters such as the proxyaddress if needed) set in the webphone_config.js, via the setparameter API call or
passed by URL
o Call the start() function
o Supply the username/password (or other required parameters such as the sipusername if needed) using the setparameter API.
o Call the register() function
 Example 4:
o Set all the required parameters using the setparameter API
o Use the call() function (this will auto trigger the start action and also the register action if the register parameter is not set to false)
 Example 5:
o Any other combinations
o The important thing is to just set the webphone parameters with any method and then call any action API such as start/register/call/etc.

Can’t connect to SIP server


If the webphone cannot connect or cannot register to your SIP server, you should verify the followings:
 You have set your SIP server address:port correctly (from the user interface or “serveraddress” parameter in the webphone_config.js file)
 In case if you have set by the webrtcserversaddress parameter, make sure that it actually works. You can test it with this tool (set the “Location” to the
same string as you have set for the webphone webrtcserveraddress parameter and check if it can connect).
 Make sure that you are using a SIP username/password valid on your SIP server
 Make sure that the autostart parameter is 1 or 2 and the register parameter is 1 or 2. Otherwise use the start() and register() API explicitly. Details here.
 If you are using the WebRTC engine with the Mizu WebRTC SIP gateway service, make sure that your firewall or fail2ban doesn’t block the gateways. You
should white-list rtc.mizu-voip.com and usrtc.webvoipphone.com
 Make a test from a regular SIP client such as mizu softphone or x-lite from the same device (if these also doesn’t work, then there is some fundamental
problem on your server not related to our webphone or your device firewall or network connection is too restrictive)
 Use an account-extensions with digest authentication (don’t use IP authentication if you are using the webphone WebRTC engine via gateway; in Asterisk
the extension should be configured as “users” and not as “peer”)
 Check if some firewall, NAT or router blocks the webphone process or the SIP signaling
 Check the browser console output for possible errors (search for “ERROR”, but note that some error messages are normal to occure)
 If there are no any answer for the REGISTER requests, turn on your server logs and look for the followings:
o The REGISTER reaches your server?
o Is there any response triggered (or some error)?
o If answer is triggered, is it sent to the correct address? (it should be sent to the exact same address from where the server received the REGISTER
request)
o The answer packet reach the client PC? You can use Wireshark to see the packets at network level.
 Send us a detailed client side log if still doesn’t work with loglevel set to 5 (from the browser console or from softphone skin help menu)

Webphone doesn’t work with the NS engine


The NS engine is a native executable which is running in background on your OS as a system service, offering SIP/media capabilities for the webphone. The
webphone communicates with the NS engine via a websocket connection (or with HTTP poll if websocket is not available in your browser).

The followings might be responsible for the NS engine failure (in case when the webphone has to use the NS engine but can’t connect):
1. The NS engine is not running: make sure that the webphone service is started successfully and you can see it in your running process list from Task
Manager.
The “Webphone” or “YourBrandName” service state can be seen by opening the services management console (run services.msc from the command line)
2. You are running a very old outdated NS engine.
For Windows you can install the latest version from http://yourdomain.com/path_to_webphone/native/WebPhoneService_Install.exe
(or from the webphone package native folder sent to you by Mizutech)
3. The webphone can’t resolve the ns4.webvoipphone.com domain name to 127.0.0.1: Verify by running ping ns4.webvoipphone.com from your command
line and it should respond from 127.0.0.1. This might fail for the following reasons:
a. No any internet connection
b. DNS requests are blocked
c. You have a proxy which cannot resolve this domain or blocks it
Possible workaround: add the following line the hosts file of the client PC: 127.0.0.1 ns4.webvoipphone.com
4. Check your HTTP proxy if any
5. Your browser doesn’t accept the SSL certificate of the domain for ns4.webvoipphone.com some reason. As a workaround, you might add it to your browser
white list
6. The webphone was unable to listen on the required ports. Make sure that no other applications are using ports: TCP 10443, TCP 18520, UDP 18521, UDP
18522 on your client PC. You can verify this from the Resource Monitor -> Network tab or with the nestat –a command
7. The communication between the browser and the NS service is blocked. This might happen if you have a very restrictive firewall which blocks the
communication also on localhost. As a workaround, add the NS engine and the java.exe to the firewall exception list
To test the connection, open the following URL: https://ns4.webvoipphone.com:10443/extcmd_test (it should respond with some text)
8. The NS engine is unable to start on Windows for some reason. Have a look at the logs (MizuCall_Servicelog.dat and other logs files in the NS engine app
directory which is located by default at C:\Program Files (x86)\YourBrandNameWebphone_Service\. Also check the engine log at C:\Program Files (x86)\
ourBrandNameWebphone_Service\content\native\)

You might also like