Mizu WebPhone
v.4.0. June
25, 2024
About 2
Usage. 2
Steps. 2
Web Softphone. 4
Click-to-call 4
Developers. 4
Designers. 4
Features, technology and licensing. 5
Feature list 5
Requirements. 6
Technical details. 6
Licensing. 8
Integration and customization. 9
Concepts. 10
User interface Skin/Design. 10
Web Dialer/Softphone. 12
Click to call 17
Custom solutions. 21
Integration with Web server side applications or scripts. 21
Integration with SIP server side applications or scripts. 23
Development 23
Parameters. 26
SIP account settings. 28
Engine related settings. 31
Call divert and other settings. 51
User interface related settings. 60
Parameter security. 69
JavaScript API 70
About 70
Basic example. 70
Functions. 71
Events. 84
FAQ.. 93
Resources. 162
The Mizu WebPhone is a universal
JavaScript SIP client library to provide VoIP capability for all browsers
using a variety of technologies compatible with most OS/browsers. Since it is
based on the open standard SIP and RTP
protocols, it can inter-operate with any other SIP-based network, allowing
people to make true VoIP calls directly from their browsers. Compatible with
all SIP softphones (X-Lite, Bria, Jitsi others), devices (gateways, ATA’s, IP
Phones, others), proxies (SER, OpenSIPS, others), PBX (Asterisk, FreeSWITCH, FreePBX, Elastix, Avaya, FusionPBX,
3CX, Broadsoft, Alcatel, NEC, others), VoIP servers (Mizu, Voipswitch, Cisco,
Huawei, Kamailio, others), service providers (Twilio, Vonage and others) and
any SIP capable endpoint (UAC, UAS, proxy, others).
The Mizu WebPhone is truly cross-platform,
running from both desktop and mobile browsers, offering the best browser to SIP
phone functionality in all circumstances, using a variety of built-in
technologies referred as “engines”:
·
NS (Native Service/Plugin)
·
WebRTC
·
Java applet
·
Flash
·
App
·
P2P/Callback
·
Native Dial
The engine to use is automatically
selected by default based on OS, browser and server availability (It can be
also set manually from the configuration or priorities can be changed). This multi-engine capability has considerable benefits over other naive implementations.
The webphone can be used with the
provided user interface (as a ready to use softphone or click to call
button) or as a JavaScript SIP library via its API.
The provided user interfaces are
implemented as simple HTML/CSS and can be fully customized, modified, extended or removed/replaced.
The webphone is an all-in-one VoIP
client module which can be used as-is (as a ready to use softphone or click to
call) or as a JavaScript SIP library (to implement any custom VoIP client or
add VoIP call capabilities to existing applications). You can create custom
VoIP solutions from scratch with some JavaScript knowledge or use it as a
turn-key solution if you don’t have any programming skills as the webphone is
highly customizable by just changing its numerous settings.
Download the webphone.zip and extract it to your web server (or test it from
your local file system by just launching it from your desktop for example).
Open the webphone_config.js file and configure at least the serveraddress
parameter.
Launch any of the example html included with the webphone, for example the
index.html as from there you can access most examples.
Enter your SIP username/password (if
you haven’t preconfigured it in the webphone_config.js) and call any
account/extension/phone number.
A quick tutorial can be found here
and/or you might follow the below step by step detailed instructions:
The package can be downloaded from
here: webphone download.
It includes everything you need for a
browser to SIP solution: the engines, the JavaScript API, the skins and also a
few usage examples.
This public downloadable version has
some demo
limitations, but you can use it for
any tests or integration work before to purchase your license.
If you already have a webphone license, then use the webphone package sent to you by
Mizutech instead of the above link.
You can find the requirements here, which needs to be fulfilled to be able to use the
webphone.
There is no any web server related
requirements. You can host the webphone on any web server the exact same way as you host a static page or a
png images.
Unzip and copy the webphone folder into your webserver and refer it from your html (for
example from your main page) or open one of the included html in your browsers
by specifying its exact URL.
For example:
http://192.168.1.44/webphone/samples/techdemo_example.html or https://yourdomain.com/webphone/softphone.html
.
Notes:
·
You might have to enable the .jar,
.exe, .zip, .swf, .dll, .so, .pkg, .dmg and .dylib mime types in your webserver if not enabled by default (these
files might be used in some circumstances depending on the client OS/browser).
·
If you wish to use (also) the
WebRTC engine then your site should be secured (HTTPS with a valid SSL
certificate). Modern browsers requires secure connection for both your website
(HTTPS) and websocket (WSS). If your website doesn’t have an SSL certificate
then we can host
the webphone for you for free or you can install a cheap or free certificate.
·
More details can be found here
·
Alternatives:
o
You can also test it without a
webserver by launching the html files from your desktop (launch from
local file system)
o
You can also test it by using the online demo
hosted by Mizutech website, but in this case you will not be able to change the
configuration (you can still set any parameters from the user interface or from
URL)
The webphone has a long list of parameters which you can set to
customize it after your needs.
You can set
these parameters multiple ways (in
the webphone_config.js file, pass by URL
parameter or via the setparameter() API).
If you are using the webphone with a
SIP server (not peer to peer) then you must set at least the “serveraddress” parameter. For more details read here.
The easiest way to start is to just
enter the required parameters (serveraddress, username, password and any other
you might wish) in the webphone_config.js file.
The webphone can be used as a turn-key
ready to use solution (just refer to it from your HTML) or as a Java-Script
library to develop custom software.
There are multiple ways to use it:
o
Use one of the supplied templates
(the “softphone” or the “click to call”) and customize it after your needs. You
can place one of them as an iframe or
div to your website
o
Integrate the webphone with
your webpage, website or web application
o
Integrate the webphone with your server side application (if
you are a server side developer)
o
Create your custom solution by using the webphone as a JavaScript SIP
library (if you are a JavaScript developer)
If you are a designer then you might
create your own design or
modify the existing HTML/CSS. For simple design changes you don’t need to be a
designer. Colors, branding, logo and others can be specified by the settings
for the supplied “softphone” and “click to call” skins.
Mizutech can also supply a ready to use
pre-customized build of the softphone skin with your settings and branding for
no extra cost (ask for it).
Please note that the webphone also
works without any GUI.
Launch one of the examples (the html
files in the webphone folder) or your own html (from desktop by double clicking
on it or from browser by entering the URL). You might launch the “index.html”
to see the included templates.
At first start the webphone might offer
to enable or download a native plugin if no other suitable engine are supported
and enabled by default in your browser.
It will also ask for a SIP
username/password if you use the default GUI and these are not preset.
On init, the webphone will register
(connect) to your VoIP server (this can be disabled if not needed by setting
the register parameter to 0).
Then you should be able to make calls
to other UA (any webphone or SIP endpoint such as X-Lite or other softphone) or
to pstn numbers (mobile/landline) if outbound call service is enabled by your
server or VoIP provider.
Examples and ready to use solutions
(found in the webphone folder):
·
index.html: just an index page with direct links to the
below examples for your convenience
·
minimal_example.html: shortest example capable to make a call
·
basic_example.html: a basic usage example
·
techdemo_example.html: a simple tech demo. You might make any tests
by using this html or change/extend it to fit your needs
·
softphone.html: a full featured, ready to use browser softphone. You can use it as is on your website as a web
dialer. For example you can include it in an iframe or div on your website.
Change the parameters in the webphone_config.js). You can further customize it
by changing the parameters or changing its design.
·
softphone_launch.html: a simple launcher for the above to look better
when launched directly (since the softphone.html is used usually in a DIV or
iFrame)
·
click2call.html: a ready to use browser to SIP click to call
solution. You might further customize
after your needs
·
custom: you can easily create any custom browser VoIP solution by using the webphone java
script SIP library
More details:
·
Webphone
file list
·
Customization
·
How it works?
·
Quick webphone tutorial
The webphone package contains a ready
to use web
softphone.
Just copy the webphone folder to your
webserver and change the “serveraddress” setting in the in webphone_config.js
file to your SIP server IP or domain to have a fully featured softphone
presented on your website. You can just simply include (refer to) the
softphone.html via an iframe
(this way you can even preset the webphone parameters in the iframe URL) div or
on demand.
Note: you might have to enable the
following mime types in your web server if not enabled by default: .jar, .swf,
.dll, .dylib, .so, .pkg, .dmg, .exe
The web softphone can be configured via
URL parameters or in the " webphone_config.js" file, which can be found in
the root directory of the package. The most important configuration is the
“serveraddress” parameter which should be set to your SIP server IP address or
domain name. More details about the parameters can be found below in this
documentation in the “Parameters”
section.
We can also send you a build with all
your branding and settings pre-set: contact us.
Check here for more options.
The webphone package contains a ready
to use click to call solution.
Just copy the whole webphone folder to
your website, set the parameters in the webphone_config.js file and use it from
the click2call.html.
Rewrite or modify after your needs with
your custom button image or you can just use it via a simple URI or link such
as:
http://www.yourwebsite.com/webphonedir/click2call.html?wp_serveraddress=YOURSIPDOMAIN&wp_username=USERNAME&wp_password=PASSWORD&wp_callto=CALLEDNUMBER&wp_autoaction=1
You can find more details and
customization options in the click to call
section.
Developers can use the webphone as a JavaScript SIP library
to create any custom VoIP solution integrated in any webpage or web
application.
Just include the " webphone_config.js" to your project or html and
start using the webphone
API.
See the development
section for the details.
Note: You can adjust the webphone
behavior also without any development knowledge by just modifying its settings
described in “parameters” section.
If you are a designer, you
can modify all the included HTML/CSS/images or create your own design from
scratch using any technology that can bind to JS such as HML5/CSS, Flash or
others.
For simple design changes you don’t
need to be a designer. Colors, branding, logo and others can be set by the
settings.
See the “User
Interface Skin/Design” section for
more details.
Note: If you are using the built-in
softphone or click2call skins, then you can adjust them also without any
designer knowledge by just setting/modifying the user interface
related settings in the
webphone_config.js file.
Features, technology and licensing
The WebPhone is a cross-platform
JavaScript SIP client library running entirely in clients browsers compatible
with all browsers and all SIP servers, IP-PBX or softswitch. The webphone is
completely self-hosted without any cloud dependencies, completely owned and
controlled by you (just copy the files to your Web server).
·
Standard SIP voice calls
(in/out), video, chat, conference and others (Session Initiation Protocol)
·
Maximum browsers compatibility.
Runs in all browsers with Java, WebRTC or native plugin support (WebView,
Chrome, Firefox, IE, Edge, Safari, Opera)
·
Includes several different
technologies to make phone calls (engines): WebRTC, NS (Native Service or
Plugin), Java applet, Flash, App, Native and server assisted conference rooms,
calls through IVR, P2P and callback
·
SIP and RTP stack compatible with
all standard VoIP servers and devices like Cisco, Voipswitch, Asterisk,
softphones, ATA, IP phones and others
·
Transport protocols: IPv4/IPv6,
UDP, TCP, HTTP, RTMP, websocket (uses UDP for media whenever possible)
·
Encryption: SIPS, TLS, DTLS, SRTP
and end to end encryption for webphone to webphone calls even if TLS/DTLS/SRTP
is not supported
·
NAT/Firewall support: auto detect
transport method (UDP/TCP/HTTP), stable SIP and RTP ports, keep-alive, rport
support, proxy traversal, auto tunneling when necessary, ICE/STUN/TURN
protocols and auto configuration, firewall traversal for corporate networks,
VoIP over HTTP/TCP when firewalls blocks the UDP ports with full support for
ICE TCP candidates
·
Works over the internet and also
on local LAN’s (perfectly fine to be used with your own internal company PBX)
·
RFC’s: 2543, 3261, 7118, 2976,
3892, 2778, 2779, 3428, 3265, 3515, 3311, 3911, 3581, 3842, 1889, 2327, 3550,
3960, 4028, 3824, 3966, 2663, 6544, 5245 and others
·
Supported methods: REGISTER,
INVITE, re-INVITE, ACK, PRACK, BYE, CANCEL, UPDATE, MESSAGE, INFO, OPTIONS,
SUBSCRIBE, NOTIFY, REFER
·
Audio Codec: G.711 (PCMU, PCMA),
G.729, GSM, iLBC, iSAC, SPEEX, OPUS (including wide-band HD audio)
·
Video codec: H.263, H.264, H.265,
VP8 and VP9 for WebRTC only
·
SIP compatible codec auto
negotiation and adjustment (for example OPUS – G.711, G.729 - wideband or RTC
G.711 to G.729 transcoding if needed)
·
Video calls and Screen-sharing
(for WebRTC enabled browsers)
·
Call divert: rewrite, redial,
mute, hold, transfer, forward, conference and other PBX features
·
Call park and pickup,
auto-answer, barge-in
·
Voice call recording
·
IM/Chat (RFC 3428), SMS, file
transfer, DTMF, voicemail (MWI)
·
Multi-line support
·
Multi account support
·
Contacts: management,
synchronization, flags, favorites, block, auto prioritization
·
Presence
(DND/online/offline/others) via standard SIP PUBLISH/SUBSCIBE/NOTIFY
·
BLF (Busy Lamp Field)
·
Balance display, call timer,
inbound/outbound calls, caller-id display
·
High level JavaScript API: web
developers can easily build any custom VoIP functionality using the webphone as
a JS SIP library
·
Stable API: new releases are
always backward compatible so you can always upgrade to new versions with no
changes in your code
·
Full control: perpetual life-time
license self-hosted as you wish
·
Integration with any website or
application including simple static pages, apps with client side code only
(like a simple static page) or any server side stack such as PHP, .NET, java
servlet, J2EE, Node.js and others (sign-up, CRM, callcenter, payments and
others)
·
Phone API accessible from any
JavaScript framework (such as AngularJS, React, jQuery and others) or from
plain/vanilla JS or not use the JS API at all
·
Branding and customization:
customizable user interface with your own brand, skins and languages (with
ready to use, modifiable themes)
·
Flexibility: all
parameters/behavior can be changed/controlled by URL parameters, preconfigured
parameters, from javascript or from server side
The webphone is in continuous development with multiple new releases
every year.
Only the major releases are published on the software homepage
as a demo
(usually once per year), but new customers always receive the latest stable
release.
All versions are fully backward/forward compatible, thus upgrades
doesn’t require any change in existing configurations and code.
For the major new versions you can find the change list here.
Server side:
·
Any web hosting for the
webphone files (any webserver is fine: IIS, nginx, Apache, NodeJS, Java,
others; any OS: Windows, Linux, others).
Chrome and Opera
requires secure connection for WebRTC engine to work (otherwise this engine
will be automatically skipped). We can also host the webphone for free if you
wish on secure http. Note that the web phone itself doesn’t require any
framework, just host it as static files (no PHP, .NET, JEE, NodeJS or similar
server side scripting is required to be supported by your webserver, however
you are free to integrate the webphone with any such server side stacks if you
need so)
·
At least one SIP account
at any VoIP
service provider or your own SIP server or IP-PBX (such as Asterisk, Voipswitch, 3CX,
FreePBX, Trixbox, Elastix, SER, Cisco and others)
·
Optional: WebRTC capable SIP
server or SIP to WebRTC gateway (Mizutech free WebRTC to SIP service is enabled
by default. The webphone can be used and works fine also without WebRTC, however if you prefer this technology then free software is available and Mizutech also offers WebRTC to SIP gateway (free with the Advanced license) and free service
tier. Common VoIP servers also has built-in WebRTC support nowadays)
Client side:
·
Any browser supporting
WebRTC OR Java OR native plugins with JavaScript enabled (most browsers are
supported)
·
Audio device: headset or microphone/speakers
Compatibility:
·
OS: Windows (XP,Vista,7,8,10,11)
, Linux (most distros), MAC OSX, Android, iOS, BlackBerry, Chromium OS and
others
·
Browsers: Firefox, Chrome, IE
(6+), Edge, Safari, Opera and others
·
Different OS/browser might have
different compatibility level depending on the usable engines. For example the
rarely used Flash engine doesn’t implement all the functionalities of the
WebRTC/Java/NS engines (these differences are handled automatically by the
webphone API)
If you don't have an IP-PBX or VoIP
account yet, you can use or test with our SIP VoIP service.
·
Server address:
voip.mizu-voip.com
·
Account: create
free VoIP account from here or use
the following username/passwords: webphonetest1/webphonetest1,
webphonetest2/webphonetest2 (other people might also use these public accounts
so calls might be misrouted)
Some more details can be found here.
The goal of this project is to
implement a VoIP client compatible with all SIP servers, running in all
browsers under all OS with the same user interface and API. At this moment no
technology exists to implement a VoIP engine to fulfill these requirements due
to browser/OS fragmentation. Also different technologies have some benefits
over others. We have achieved this goal by implementing different “VoIP
engines” targeting each OS/browser segment. This also has the advantage of just
barely run a VoIP call, but to offer the best possible quality for all
environments (client OS/browser). All these engines are covered by a single,
easy to use unified API accessible from JavaScript. To ease the usage, we also
created a few different user interfaces in HTML/JS/CSS addressing the most common
needs such as a VoIP dialer and a click to call user interface.
More details about how it works can be
found here.
Each engine has its advantages and
disadvantages. The sip webphone will automatically choose the “best” engine
based on your preferences, OS/Browser/server side support and the enduser
preferences (this can be overridden by settings if you have some special
requirements): VoIP availability in browsers.
Native VoIP engine
implemented as a service or browser plugin. The engine works like a usual SIP client, connecting
directly from client PC to your SIP server, but it is fully controlled from web
(the client browser will communicate in the background with the native engine
installed on the client pc/mobile device, thus using this natively installed
sip/media stack for VoIP).
Available for: all
browsers on Windows, Linux
Pros:
·
All features all supported, native
performance
Cons
·
Requires install
(one click installer)
A new technology for media
streaming in modern browsers supporting common VoIP features. WebRTC is a built-in module in modern browsers which can be used to implement
VoIP. Signaling goes via websocket (unencrypted or TLS) and media via encrypted
UDP (DTLS-SRTP). These are then converted to normal SIP/RTP by the VoIP server
or by a gateway.
Available for: all
modern browsers.
Pros:
·
Comfortable usage
in browsers with WebRTC support because it is has no dependencies on plugins
Cons:
·
It is a black-box
in the browser with a restrictive API
·
Lack of popular
VoIP codec such as G.729 (this can be solved by CPU intensive server side
transcoding)
·
A WebRTC to SIP
gateway may be required if your VoIP server don’t have built-in support for WebRTC (there are
free software for this and we also provide a free service tier, included by
default)
A browser plugin
technology developed by Adobe with its proprietary streaming protocol called RTMP.
Available for: old
browsers.
Pros:
·
In some
old/special browsers only Flash is available as a single option to implement
VoIP
Cons:
·
Requires server
side Flash to SIP gateway to convert between flash RTMP and SIP/RTP (we provide
free service tier)
·
Basic feature set
Based on our powerful
JVoIP SDK, compatible with all JRE enabled browsers. Using the Java Applet technology you can make SIP calls
from browsers the very same way as a native dialer, connecting directly from
client browser to SIP server without any intermediary service (SIP over UDP/TCP
and RTP over UDP).
Available for: java
enabled browsers such as IE, Pale Moon and old Firefox/Chrome.
Pros:
·
All SIP/media
features are supported, all codecs including G.729, wideband and custom extra
modules such as call recording
·
Works exactly as
a native softphone or ip phone connecting directly from the user browser to
your SIP capable VoIP server or PBX (but with your user interface)
Cons:
·
Java is getting
deprecated by modern browsers (handled automatically by the webphone by just
choosing another available engine)
·
Some browsers may
ask for user permission to activate the Java plugin
Some platforms don’t
have any suitable technology to enable VoIP in browsers (a minor percentage,
most notably old iOS/Safari). In these cases the webphone can offer to the user
to install a native softphone application. The apps are capable to
fully auto-provision itself based on the settings you provide in your web
application so once the user installs the app from the app store, then on first
launch it will magically auto-provision itself with most of your
settings/branding/customization/user interface as you defined for the webphone
itself.
Available for: old
browsers with no any built-in or plugin based VoIP support.
Pros:
·
Covering
platforms with lack of VoIP support in browsers (most notable old iOS Safari)
Cons:
·
No API support.
Not the exactly same HTML user interface (although highly customized based on
the settings you provided for the webphone)
These are just
“virtual” engines with no real client VoIP stack.
·
P2P means server initiated phone to phone call
initiated by an API call into your VoIP server. Then the server will first call
you (on your regular mobile/landline phone) and once you pick it up it will
dial the other number and you can start talking (Just set the “p2p” setting to
point to your VoIP server API for this to work)
·
Callback is a method to make cheap
international calls triggering a callback from the VoIP server by dialing its
callback access number. It might be used only as a secondary engine if you set
a callback access number (Just set the “callback” setting to point to your VoIP
server API for this to work)
These are treated as a
secondary (failback) engines and used only if no other engines are available
just to be able to cover all uncommon/ancient devices with lack of support for
all the above engines which is very rare. However it might be possible that
these fits into your business offer and in that case you might increase their
priority to be used more frequently. Alternatively it might be used also to
initiate native call under low quality network conditions.
This means native calls
from mobile using your mobile carrier network. This is a secondary “engine” to
failback to if no any VoIP capabilities were found on the target platform or
there is no network connection. In these circumstances the webphone is capable
to simply trigger a phone call from the user smartphone if this option is
enabled in the settings. Rarely used if any.
The most important
engines are: NS, WebRTC and Java. The other engines are to provide support for
exotic or ancient browsers maximizing the coverage for all OS/browser
combinations ensuring that endusers always has call capabilities regardless of
the circumstances.
All the above engines
are covered with an easy to use unified Java Script API, hiding all the
differences between the engines as described below in the “JavaScript
API” section.
The webphone can be
used with or without a user interface.
The user interface can
be built using any technology with JS binding. The most convenient is HTML/CSS,
but you can also use any others such as Flash.
The webphone package
comes with a few prebuilt feature rich responsive user interfaces covering the
most common usage such as a full featured softphone user interface and a click
to call implementation. You are free to use these as is, modify them after your
needs or create your own from scratch. For more details check the “User interface Skin/Design” section.
The webphone is sold with life-time unlimited client
license (Advanced and Gold) or restricted number of licenses (Basic and
Standard). You can use it with any VoIP server(s) on your own and you can
deploy it on any webpage(s) which belongs to you or your company. Your VoIP
server(s) address (IP or domain name) and optionally your website(s) address
will be hardcoded into the software to protect the licensing. You can find the
licensing possibilities on the pricing page.
After successful tests please ask for your final version at webphone@mizu-voip.com. Mizutech will deliver your webphone build within
one workday after your purchase.
Release versions does not have any limitations (mentioned below in the “Demo
version” section) and are customized for your domains/brand. All “mizu” and
“mizutech” words and links are removed so you can brand it after your needs
(with your company name, brand-name or domain name), customize and skin (we
also provide a few skin which can be freely used or modified).
Your final build must be used only for you company
needs (including your direct sip endusers, service customers or integrated in
your software).
Title, ownership rights, and intellectual property
rights in the Software shall remain with MizuTech.
The webphone is licensed per server (except the Gold
version). Already licensed servers cannot be removed or changed, however, you
can use domain names, thus allowing changing your server or its IP address any
time later without any implications regarding the webphone license. The
exception for the server limitations is the Gold version, which has a more
flexible licensing, allowing also unlimited servers.
The agreement and the license granted hereunder will terminate automatically if
you fail to comply with the limitations described herein. Upon termination, you
must destroy all copies of the Software. The software is provided "as
is" without any warranty of any kind. You must accept the software SLA before
to use the webphone.
You may:
·
Use the webphone on any number of
computers, depending on your license
·
Give the access to the webphone
for your customers or use within your company
·
Offer your VoIP services via the
webphone
·
Integrate the webphone to your
website or web application (or native applications usually via a webview)
·
Use the webphone on multiple
webpage’s and with multiple VoIP servers (after the agreement with Mizutech).
All the VoIP servers must be owned by you or your company. Otherwise please
contact our support to check the possibilities
You may not:
·
Resell the webphone as is
·
Sell “webphone” services for
third party VoIP providers and other companies usable with any third-party VoIP
servers (except if coupled with your own VoIP servers)
·
Resell the webphone or any
derivative work which might compete with the Mizutech “webphone” software offer
·
Create competition for Mizutech
by reselling the webphone in similar way (not tied to your servers or apps, but
as a general browser VoIP client)
·
Reverse engineer, decompile or
disassemble or modify the software in any way except modifying the settings and
the HTML/CSS skins or the included JavaScript examples
Note: It is perfectly fine to sell or
promote it as a “webphone service” if that is tied to your own SIP servers. But
if you sell it as webphone software which can be used with any server than you
are actually selling the same as Mizutech and this is not allowed by the
license.
There are the following legal ways to
use the webphone:
·
you have your own
SIP server(s) and the webphone will be used with these server(s) (your customers
can integrate the webphone into any application or website but they will use
the webphone via your VoIP server)
·
you are building
some application or website (such as a CRM, portal or game), so the webphone
will be tightly integrated with your solution
·
both of the above
(webphone used via your own SIP server from within your own website or
application)
·
click to call for
your webpage (or click to call service for others via your SIP server)
·
your call center
or contact center
·
call center
software offered to other companies if the webphone is deeply integrated in
your callcenter software or uses your own SIP server for call
termination/reception
·
you are a VoIP
service provider and wish to allow your customers to make calls from your
website (without the need to install a native client)
Contact us
if you wish to use the webphone in some other way which is not covered by this
license or you are in doubt with the usage: webphone@mizu-voip.com
The downloadable
demo version can be used to try and test before any purchase. The demo version
has all features enabled but with some restrictions to prevent commercial
usage. The limitations are the followings:
·
commercial usage not allowed
·
maximum ~10 simultaneous webphone
instances at the same time (depending on the engine used)
·
might be restricted to up to ~5
or ~10 simultaneous calls (depending on the engine used)
·
will expire after several months
of usage (around 2 - 5 months, depending on the release date)
·
maximum ~100 sec call duration
restriction
·
maximum ~10 calls / session
limitation (after ~10 calls you will have to restart your browser)
·
will work maximum ~20 minutes
after that you have to restart it or restart the browser
·
can be blocked from Mizutech
license service
The demo version can be used for all
kind of tests or development, but it can’t be used for production. It can be
used by up to 5 developers to make short calls (below 100 seconds) and the
browser have to be restarted after 10 calls or 20 minutes, otherwise a “Trial”
or “License” error will be displayed or printed to the browser console.
Note: for the first few calls and in
some circumstances the limitations might be weaker than described above, with
fewer restrictions.
All these demo limitations are removed from the licensed versions.
See the pricing and order your licensed copy from here.
On request we
can also provide an one month trial without the above demo limitations.
Integration and customization
The webphone is a
flexible VoIP web client which can be used for various purposes such as a dialer on your website, a click to call button for contacts
or integrated with your web application (contact center, CRM, social media or
any other application which requires VoIP calls).
The webphone can be
customized by its numerous settings, webphone API’s and by changing
its HTML/CSS.
Deploy:
The webphone can be deployed as a static page (just copy the webphone file to
your website), as a dynamic page (with dynamically generated settings) or used
as a JavaScript VoIP library by web developers.
You can embed the webphone to your website in
a div, in an iFrame or on demand, as a module or as a separate page. The webphone
settings can be set also by URL parameters so you can just launch it from a link with all the required settings
specified.
VoIP platform:
All you need to use the
webphone is a SIP account at any VoIP service provider or your own
softswitch/IP-PBX.
Free SIP accounts can be
obtained from numerous VoIP service providers or you can use our service.
(Note that free accounts are free only for VoIP to VoIP calls. For outbound
pstn/mobile you will need to top-up your account).
If you wish to host it
yourself then you can use any SIP server software. For example FreePBX
for linux or the advanced /
free VoIP server for windows by Mizutech. We can also provide our WebRTC to SIP gateway (for free with the Advanced or Gold license) if your
softswitch don’t have support for WebRTC and you need a self-hosted solution.
Settings:
The webphone settings can
be passed multiple ways as described at the beginning of the parameters chapter.
The most important
parameter that you will need to set is the “serveraddress”
which have to be set to the domain or IP:port of your SIP server.
Other important
parameters are listed here.
More details regarding
the configuration with your SIP server can be found here.
Integration:
You can integrate the webphone with your web-site or web-application:
-using your own web server API
-and/or using the
webphone client side JavaScript API to insert any
business logic or AJAX call to your server API
The webphone library
doesn’t depend on any framework (as it is a pure client side library) but you
can integrate it with any server side framework if you wish (PHP, .NET, NodeJS,
J2EE or any server side scripting language) or work with it only from client
side (from your JavaScript).
On the client side you
can use the webphone API from any JavaScript framework (such as AngularJS,
React, Vue, Electron, WordPress and others) or from plain/vanilla JS or not use
the JS API at all.
You can tightly integrate
the web phone with your SIP server using the methods described here.
Design
You can completely change any of the included skins (click to call button,
softphone), or change the softphone colors or create
your user interface from scratch with your favorite tool and call the webphone
API from there.
Custom application:
For deep changes or to
create your unique VoIP client or custom application you will need to use the JavaScript API.
See the development section for more details.
Branding:
Since the webphone is
usually used within your website context, your website is already your brand
and no additional branding is required inside the webphone application itself.
However the softphone skin (if you are using this turn-key GUI) has its own branding
options which can be set after your
requirements.
Additionally you can
change the webphone HTML/CSS design
after your needs if more modifications are required.
On request, we can send
your webphone build already preconfigured with your preferences.
For this just answer the points
from the voip client customization page (as many as possible) and send to us by email.
Then we will generate and send your webphone build within one work-day. All the
preconfigured parameters can be further changed by you via the webphone
settings.
Of course, this is
relevant only if you are using a skin shipped with the webphone, such as the
softphone.html. Otherwise you can create your custom solution using the
webphone library with your unique user interface or integrate into your
existing website.
User
interface Skin/Design
You can use
the webphone with or without a user interface.
The webphone is shipped with
a few ready to use open source user interfaces such as a softphone and click to
call skins. Both of these can be fully customized or you can modify their
source to match your needs. You can also create any custom user interface using
any technique such as HTML/CSS and bind it to the web phone javascript API.
The default user interface for the
softphone and other included apps can be easily changed by modifying parameters
or changing the html/css. For simple design changes you don’t need to be a
designer. Colors, branding, logo and others can be set by the settings
parameters.
Also you can easily create your own app
user interface from scratch with any tool (HTML/CSS or others) and call the
webphone Java Script API from your code.
In short, there are two ways to achieve
your own (any kind of) custom user interface:
A.
Use one of the skins provided by
the webphone
Here you also have two possibilities:
o Quick customization changing the webphone built-in user-interface
related settings (you can change the colors, behaviors and others)
o If you are a web developer, then have a look at the
html and JavaScript source code and modify it
after your needs (we provide all the source code for these; it can be found
also in the downloadable demo)
B.
Create
your own user web VoIP user interface
and use the webphone as a JavaScript library for the SIP protocol from there.
The webphone has an easy to use API which can be easily integrated with any user
interface. For example from your “Call” button, just call the webphone
webphone_api.js.call(number) function. Have a look at the samples folder:
“minimal_example.html”, “basic_example.html” or “techdemo_example.html” (You
can also use the provided samples as a template to start with and modify/extend
it after your needs)
Just use the “colortheme” parameter to make quick and wide changes.
Then have a look at the “User interface
related” parameters (described in
the “Parameters” section) and change them after your needs (set
logo, branding, translate and others).
We can also send you a web softphone with
your preferred skin. For this just set your customization on the online designer form and send us the parameters.
We can also send you fully customized
and branded web softphone with your preferences. For this just send us
the customization details.
Read below if you need more
customizations.
Web developers/designers can easily
modify the existing skins or create their own.
For the softphone application all the
HTML source code can be found in "softphone.html" file as a
single-page application model.
There are a few possibilities to change
the skins:
·
Change the user interface
related parameters as already
discussed above (for example the “colortheme”
and other parameters)
·
You can manually edit the html
and css file with your favorite editor to change it after your needs
·
Or just create your design with
your favorite tools and call the web sip phone API from there
·
If you wish to customize the
softphone skin (softphone.html), it is discussed in details here
Note: If you are using the webphone as
a javascript SIP library then you can customize the “choose engine” popup in
"css\pmodal.css".
The webphone can be positioned on your
webpage after your needs. You can put it in a DIV or iFrame control and define
any position from HTML of CSS. For example you can make it floating as
described here.
If you have different needs or don’t
like the default skins, just create your own from scratch and call the webphone
JavaScript API from your code. Using the API you can easily add VoIP call
capabilities also to existing website or project with a few function calls as
described in the “Java Script API” section
below.
For specific needs, look at the
following sections:
·
Dialer
skin
·
Click
to call skin
·
Custom
solution
·
Floating skin
·
Multi-line
With the Mizu webphone you can create a
web based softphone which looks like and works like a native desktop softphone
application (such as X-Lite). A web based solution has a big advantage since it
is always available for endusers without the need to download and install an
application and also it is much more flexible than a traditional softphone
(tons of parameters, easy to build user interface with HTML/CSS and easy
integration with your backend).
The webphone includes a turn-key ready softphone
skin (softphone.html) which you can start using in production as-is or change
it after your needs.
You can create any HTML/CSS
web design (with call controls, contact lists, etc) and call out to the
WebPhone API to add the VoIP functionality.
You can start with any
custom design from scratch or you might extend the “api_example.html” to reach
your goals.
More details can be found here.
There are two possibilities to create
your web dialer:
·
Create your web softphone or
dialer from scratch
You can create any HTML/CSS web design (with call
controls, contact lists, etc) and call out to the WebPhone API to add the VoIP
functionality.
Start with any custom design from scratch or you
might extend the “api_example.html” (or any other from the samples folder) to
reach your goals.
Basically the purpose of the webphone library is to
create any web based SIP client solution and most of this documentation is
about describing this process.
Jump here to
begin the development.
·
Modify the existing softphone
skin
In this chapter below we will explore the
possibilities of customizing and extending the softphone skin (softphone.html)
Softphone
skin basic customization
An easier solution is to
use the turn-key softphone skin shipped with the webphone (softphone.html and
related css and js files). This can be used as-is (it is a ready to use
turn-key solution) or further modifying after your needs.
No any development
knowledge is required to deploy the
web softphone on your website
and you can also customize it easily via webphone parameters.
Note: You can quickly test
this also from the online demo if you haven’t downloaded
the webphone demo package yet: https://www.webvoipphone.com/webphone_online_demo/softphone_launch.html (this will launch the very same “softphone.html”
included in the download package).
If you are a JavaScript developer then you might implement even more
modifications by changing the HTML, CSS or JS files (softphone.html,
js\softphone files).
We can also ship the
webphone with ready to use customized softphone skin (with your branding and
settings). For this, just answer the points on this page
on your order and send the answers by email.
Here is the whole process
step by step:
1)
Order your webphone from Mizutech
with branding (send as many customization details as you can by answering these points).
At this point you
already have a turn-key ready to use solution which can be deployed and used as-is on your website/page/application,
without the need of any technical or developer knowledge.
2)
Customize your softphone by
adjusting the technical parameters
after your needs
This can be easily
done by just modifying or adding more parameters in the webphone_config.js. At
least the “serveraddress” parameter must be set.
3)
Modify the user interface
related parameters after your needs
For example you can
set the “colortheme” parameter to make quick and wide change about the
skin appearance.
4)
Optionally further customize your
softphone by making more user interface changes as described here and here.
This optional step
requires some basic HTML/CSS knowledge.
5)
Optionally further customize your
softphone by integrating it with your client side application, integrating it
with your server, integrate with server-side address
book or change/add functionalities
by using the phone
API .
This optional step requires
some development knowledge.
The softphone skin can be positioned on
your webpage after your needs. You can put it in a DIV or iFrame control and
define any position from HTML of CSS. For example you can make it floating as
described here.
Softphone
skin advanced customization
If the above described customization
options are not enough to achieve your goals, you can modify or extend the softphone
HTML, CSS or JavaScript code.
The softphone skin can be further
customized, with new functionality, new user interface elements including new
pages.
Adding a new functionality for the
softphone skin usually involves the followings:
·
Add some user interface element
to the softphone skin. This is described in this chapter below.
·
Add functionality for your user
interface element. This is usually interaction with the SIP client or
interaction with your app server (web service):
o To interact with the SIP client, just use the
webphone SIP
API. Learn more here.
o For the interaction with your backend you can use
AJAX requests. Learn more here.
Files
All the webphone SDK library related
files are located in the \js\lib\ directory.
The softphone skin related files are:
·
html file: this is a Single Page
Application and the HTML code is all in "softphone.html"
·
css files are located in \css\
directory
·
javascript files are located in:
\js\softphone\ directory.
JQuery Mobile
The softphone skin is a single page
application built using jQuery Mobile framework.
Note: jQuery Mobile is not maintained
anymore by its original developers, however we forked a copy, which we keep up
to date and optimized also for latest browser changes.
Every jQuery mobile "page"
defined in softphone.html has a corresponding Javascript file in /softphone/
directory.
Regarding css files, styling, most of
these css files in "css" directory are related to jQuery Mobile
framework which is used to aid in the build of the Single Page application and
these should not be edited/changed.
All the styling of the webphone skin is
defined in "mainlayout.css" and can be customized from here. This css
file should be used to change any styling.
A simple way to change the softphone
design can be achieved by changing the jQuery theme: The jQuery mobile Theme
Roller generated style sheet can be found in this file:
"css\themes\wphone_1.0.css".
Current jQuery mobile version is 1.4.2.
Using the Theme roller, you can create new styles:
http://themeroller.jquerymobile.com/
The style sheet which overrides the
"generated" one (in which all the customizations are defined) is
"css/mainlayout.css".
For basic color scheme changes you can
use the online designer form. Send us your preferred color parameters and we can send you a
softphone build preconfigured with your favorite colors.
Important note: jQuery namespace within
the webphone is changed from "$" to “webphone_api.$”.
Pages
Pages in softphone.html are <DIV>
elements with the following attribute: data-role="page".
Every jQuery mobile "page"
defined in softphone.html has a corresponding Javascript file in js/softphone/
directory.
For example settings page's HTML is
defined in softphone.html file in a <DIV> element with the id:
page_settings. The corresponding Javascript file for the settings page is:
\js\softphone\_settings.js. All these "page view" Javascript files
contain a few lifecycle functions which are used to initiate/load/destroy a page.
Helper containers
For your convenience, the softphone
skin already contains a few <DIV> elements where you can drop any custom
content.
These are place below the header on
each main page (settins, dialpad, contactslist, callhistorylist).
The ID of these elements is the
followings:
·
extra_header_settings
·
extra_header_dialpad
·
extra_header_contactslist
·
extra_header_callhistorylist
Of course, you can add, modify or
remove any user interface element as you wish. Edit the html and CSS files
after your needs.
These DIV’s were added only to help
beginners.
Extra customizable pages
There are 5 predefined extra pages
which can be customized as required. These pages are: page_extra1, page_extra2,
page_extra3, page_extra4, page_extra5.
The corresponding javascript files are:
_extra1.js, _extra2.js, _extra3.js, _extra4.js, _extra5.js.
In each javascript file related to a
page, there are three "lifecycle" functions predefined:
·
onCreate(): This lifecycle function is called only once per
session, when the user navigates to the page for the first time. This is where
most initialization should go: attaching event listeners, initializing static
page content, etc.
·
onStart():This lifecycle function is called every time the
user navigates to this page (every time the page is displayed). This is where
dynamic content can be added/refreshed. For example on Contacts page we load
and display the contacts list.
·
onStop():This lifecycle function is called every time the
user navigates away from this page. This is where you can save data that the
user modified, clear dynamically added page content, etc.
Page navigation:
Page navigation can be done by calling
jQuery mobile "changePage()" method:
Format:
webphone_api.$.mobile.changePage("#PAGE_ID", { transition:
"none", role: "page" });
Example:
webphone_api.$.mobile.changePage("#page_extra1", { transition:
"none", role: "page" });
To "close" a page, you can
either navigate to another page, or return to the previous page by calling
jQuery mobile method: webphone_api.$.mobile.back();
Page content:
The content of a page will be put in a
<DIV> element with the following attribute: role="main".
Content can be added:
·
statically, by defining the
content in softphone.html file. For example for page_extra1 the content will be
in <DIV> element with id: page_extra1_content.
·
dynamically, in function
"PopulateData()" defined in all javascript files corresponding to a
page.
Autocomplete:
You can turn autocomplete off for your
HTML input elements like this:
<input type="text"
autocomplete="off" name="destination" id=”destination”
/>
Auto login:
By default the softphone skin will stop
at the login screen only if there was no previous login (missing
username/password).
Otherwise it should auto-login.
If you wish to preset the
username/password then you can do it multiple ways:
·
Set it in the webphone_config.js
·
Pass as URL query parameters
https://www.youraddress.com/webphone_path/softphone.html?wp_username=xxx&wp_password=yyy
·
Pass it from JavaScript using the
setparameter() API
·
Pass it from your server side
script session variable
Add functionality to web softphone
skin
The webphone is shipped with a ready to
use softphone skin with full functionality, but this doesn't mean that other
desired functionalities cannot be added.
This can be achieved using the
webphone's API.
For example, capturing call state
events (or using any other API function) can be done like this:
- create a new javascript file, for
example new.js
- import this script right after
"webphone_api.js" in softphone.html file
- add the following javascript code in
new.js:
//start
interacting with the webphone only once the onAppStateChange callback has been
fired with the “loaded” event.
webphone_api.onAppStateChange
(function (state)
{
if
(state === 'loaded') //webphone loaded
{
webphone_api.onCallStateChange(function (event, direction, peername,
peerdisplayname, line, callid)
{
//handle
any events here. For example to catch the call connect events:
if
(event === 'connected')
{
//add your
code here
}
});
}
});
You can find a similar example of
webphone API usage in /samples/basic_example.html.
Empty callback functions can be found
in the _dialpad.js file for your convenience (onAppStateChange,
onRegStateChange, onCallStateChange, onCdr). You can just enter any code for
these functions body.
The full webphone API is available so
you can easily interact with the softphone skin from external modules or
injected code as described in the development
and API chapters. Please note that the onCallStateChange and
some other callbacks are not used internally by the softphone (because it uses
the low level notifications), but you can use them in your code to catch
webphone state changes. Just set your callback function(s) and it will work.
The skin HTML is located in
softphone.html.
This is a single page
application that uses jQuery Mobile
framework for the single page structure and also for UI elements cross browser
compatibility. Every “page” in “softphone.html” has a corresponding Javasript
file in “\js\softphone\” directory, for example: "page_dialpad" is managed by “_dialpad.js” file.
Each Javascript file
managing a page has three “life cycle” callback functions:
·
onCreate() - called only once –
it is a good practice to handle binding to all kind of events here
·
onStart() – called every time the
page is displayed
·
onStop() – called every time the
page is “closed”
Note: jQuery namespace within the webphone is
changed from "$" to "j$" or to “webphone_api.$”.
Page
list
Below is a list of all Javascript
files managing pages. These are located in \js\softphone\ directory:
“_accounts.js”: manage multiple SIP
accounts
“_addeditcontact.js”: user interface
for creating or editing contacts
“_call.js”: user interface of the in
call page
“_callhistorydetails.js”: call
history details page
“_callhistorylist.js”: call history
list page
“_message.js”: messaging page
“_messagelist.js”: messaging inbox
list page
“_contactdetails.js”: contact
details page
“_contactslist.js”: contacts list
page
“_filetransfer.js”: file transfer
page
“_filters.js”: simple prefix rewrite
page
“_internalbrowser.js”: web view used
as a browser
“_logview.js”: page for viewing
internal app log/trace
“_newuser.js”: new user
registration page
“_dialpad.js”: main dial pad page
“_settings.js”: settings/login page
“_startpage.js”: it’s a page
displayed once or on every start; can by a URL or text; usually used for
privacy policy
“themes.js”: contains all the
definitions of the different color themes that can be applied to the skin
Menu
Every page has a menu
which can be accessed when the menu button in top-right corner is clicked. This
click event triggers the CreateOptionsMenu() function in the corresponding page
javascript file. In CreateOptionsMenu() function the menu is assembled every
time it is displayed to the user.
Then in
MenuItemSelected() function the selected menu item will be handled.
Navigation
Navigation between pages can be
accomplished with the jquery mobile changePage() method. For example, to navigate
to settings page the following command will be used:
webphone_api.$.mobile.changePage("#page_settings", {
transition: "pop", role: "page"
});
Styling
All the skin related CSS files are
located in “\css\softphone\” directory. Here all the CSS files are jQuery
mobile generated style sheets, except “mainlayout.css”. All the styling is done
here.
All element dimensions are set
proportionally with percentages if possible, or using “em” unit of measure, to
assure that the skin user interface resizes well on any screen size and any
resolution.
Skin
start up
The main page launched is every time
the settings page. If the user has already entered login credentials before,
the skin will automatically login and display the dial pad page.
The softphone skin is open sourced
(plain html/css/js source code is included in the webphone package) and it can
be freely changed by any web developer.
A few common tasks are described below
for your convenience:
How
to add a new page
The ready to use skin which is
delivered with the webphone package is built as a single page application using
jQuery mobile framework (actually only a few things are used from jQuery
mobile, the rest is plain html/javascript).
Follow the steps below to create a
new page:
1) Create new <div> html element
with attribute data-role="page" in softphone.html file. You
can use “page_extra1” as template.
2) Create the equivalent JavaScript
file, which manages the behavior of the new page. You can use the “_extra1.js” file as template.
3) Add the three “life cycle” callback
Javascript functions in init.js
a.
webphone_api.$(document).on('pageinit
b.
webphone_api.$(document).on('pageshow'
c.
webphone_api.$(document).on('pagebeforehide'
The new page is ready.
How
to change the login page
The login page is managed in
“_settings.js” file. Basically, it displays only the main login settings:
serveraddress, username, password. There is also a traditional style login page
which can be enabled with the “useloginpage” parameter: -1=auto (default),
0=no, 1=only at first login, 2=always.
How
to change the main page (dial pad tab)
The main dial pad tab consists of
the “page_dialpad” id <div> defined in softphone.html and the associated
javascript file: _dialpad.js.
How to add a new setting
First establish the setting
parameter name, which should be in lowercase, for example “newsetting”.
Open stringres.js file and define
the new setting title, description and short description (short description is
optional) with the following format:
sett_display_name_mysetting: 'My settings',
sett_comment_mysetting: 'My new settings does the following',
sett_comment_short_mysetting: '',
If you want this setting to appear
on the user interface, then add the “newsetting” to the comma separated list
stored in String variable “settOrderWebphone” and
“settOrderWebphoneWebRTCFlash” located in _setings.js file. Also, the order in
this list will define the order in which the settings will be displayed. For a
setting to appear in “Basic settings”, the parameter name should be added to
the slit in variable “basicSettings”.
To actually define a new setting, go
to “InitializeSettings()” function in common.js file add the new settings using
SettingItem() function.
The following line of code will add
the new settings:
SettingItem ("newsetting", "", "1", GROUP_LOGIN, "", "", "1", "");
SettingItem function has the
following parameters:
·
(String)
parameterName: the name of the parameter.
·
(String) value:
the current value of the parameter. I can be empty string.
·
(String) type:
the type of the settings:
o “0” = (boolean) enabled/disabled
o “1” = text input
o “2” = dropdown list
·
(String) group:
it belongs to this group/submenu:
o “20” = displayed on login page
o “0” = basic settings list
o “1” = SIP settings
o “2” = Media settings
o “3” = Call divert settings
o “4” = General Settings
o “8” = Video settings
·
(String)
allNames: a comma separated list of the display names of possible values. Used
only for dropdown list type settings, otherwise empty string.
·
(String)
allValues: a comma separated list of the actual parameter values. Used only for
dropdown list type settings, otherwise empty string.
·
(String)
isdefault: the value here should always be “1”
·
(String)
defaultValue: the default value of the parameter
How
to remove a setting
Go to “InitializeSettings()”
function in common.js file and comment out/delete the “SettingItem()” function call for that parameter
that is to be removed.
Also search for setting parameter
name in “settOrderWebphone” and “settOrderWebphoneWebRTCFlash” and
“basicSettings” variable and remove it from there if found.
How
to add a new menu item
In every javascript file that
manages a page (located in \js\softphone\), the Menu is created in
“CreateOptionsMenu ()” method. Add a menu with the following line of code:
webphone_api.$(menuId).append('<li
id="ITEM_ID"><a
data-rel="back">TITLE</a></li>').listview('refresh');
In
MenuItemSelected() function handle the action for the added menu based on
itemId.
How
to remove a menu item
In every javascript file that
manages a page (located in \js\softphone\), the Menu is created in
“CreateOptionsMenu ()” method. Just comment out or delete the “webphone_api.$(menuId).append()” line for the item to be removed.
How
to add a header/footer
For every page there is already
added a header and a footer where custom content can easily be displayed.
The content to be displayed here can
be text or HTML and can be specified with the following parameters in
webphone_api.js: “header” and “footer”.
Click-to-call (also known as click-to-talk, webcall or click-to-dial)
is a simplified form to make a call when the enduser just needs to click on a
button or a hyperlink to request an immediate connection to another webphone,
softphone or PSTN (landline/mobile), without the need of configuration to be
set by the enduser.
You can use the webphone SIP library to implement your custom
click-to-call solution or use one of the skin templates for click to call.
Click to call buttons or links can be embedded into any webpage (sales page,
blogs, social media, others) and also in email (click to call from email
signature).
You can also set auto-dial feature when the call is initiated
automatically without enduser interaction, using the callto
and autoaction parameters.
There are multiple ways to achieve
click to call or clicktodial functionality with the sip webphone:
1) Click to call from HTML link via URL parameters
(single line copy-paste code into your html)
2) Use the webphone library directly (via it’s API) to
implement any custom click to call solution (for JavaScript developers)
3) Use the click2call template as-is. A click to call
skin is shipped with the webphone (click2call.html and related css/js files) as
a turn-key click to call solution which can be used without any development
knowledge
4) Modify the click2call template by changing its
settings and skin after your needs)
Details:
1) Click to call from HTML link
You can pass any setting as URL parameter
and the webphone (and the included templates) can be easily parametrized to act
as a click to call solution:
http://www.yourwebsite.com/webphonedir/click2call.html?wp_serveraddress=YOURSIPDOMAIN&wp_username=USERNAME&wp_password=PASSWORD&wp_callto=CALLEDNUMBER&wp_autoaction=1
A working example with the click to
call skin:
https://www.webvoipphone.com/webphone_online_demo/click2call.html?wp_serveraddress=voip.mizu-voip.com&wp_username=webphonetest1&wp_password=webphonetest1&wp_callto=testivr3&wp_autoaction=1
This will launch the click to call page
and will initiate the call automatically. You can find more examples for URL
parameters here.
You can also use any other skins for
click to call. For example here is with the softphone skin:
https://www.webvoipphone.com/webphone_online_demo/softphone.html?wp_serveraddress=voip.mizu-voip.com&wp_username=webphonetest1&wp_password=webphonetest1&wp_callto=testivr3&wp_autoaction=1
2) Use the webphone library directly
You can easily create your custom click
to call solution from scratch by using the webphone as a library/SDK.
Just create a HTML button after your
needs and call the webphone_api.call(number)
function from there.
This is recommended for JavaScript
developers and in this way you can create any custom web click to call solution
after your needs.
Have a look at the click2call_example.html in the samples folder for
a very basic click to call implementation (you can use this as a starting point
for your custom development).
See the Development
and the API sections about how to work with the web phone SDK.
3)
Use the Click2Call template as-is
The webphone package contains a ready
to use click to call solution (click2call.html and related JS/CSS files).
Just copy the whole webphone folder to
your website, set the parameters in the webphone_config.js file and use the
click2call.html as-is on your webpage or directly.
Configure it after your needs by
adjusting (changing and/or adding) the settings in the “Configuration
parameters” section in the “click2call.html” file. See the parameters settings for the full list of adjustable settings.
Note: You can quickly test this also
from the online demo if you haven’t downloaded
the webphone demo package yet: https://www.webvoipphone.com/webphone_online_demo/click2call.html
4) Modify the Click2Call template
You can completely customize the
click2call example for your needs (change any settings,
change the html/css/javascript, use your custom button image).
This click2call template/skin consists
of a few different files:
·
\click2call.html
·
\css\click2call\click2call.css
·
\js\click2call\click2call.js
In the HTML file there is short html
code which defines a click to call button: <div
id="c2k_container_0" title="" style="text-align:
center;"></div>
This is the single line of HTML code
which you will include in your webpage where you want the click to call button
to be displayed. For the call button to work, you will also have to include
(preferably in the <head> section of your web page) the related css (in
this case click2call.css), Javascript (click2call.js) and the webphone API
file: webphone_api.js.
The Configuration parameters in
click2call.html are put there just for convenience. These same parameters can
be just as easily set in webphone_config.js file where the other webphone
parameters are set.
In order for the click to call skin to
work, a valid SIP account and a destination number need to be configured with
the following API parameters :
·
serveraddress: yoursipdomain.com your VoIP server IP address or
domain name
·
username: SIP account username
·
password: SIP account password
·
callto: destination number to call (the click2call can be
also modified to load this at run-time if there are multiple target numbers)
(You can also fine-tune your solution
by setting/changing any of the webphone parameters)
The click-to-call buttons color, width,
height, radius or the displayed text can be customized after your needs from
the click2call.js file using the variables from the "Customizations"
section.
You can even add a background image, by
setting your image (jpg or png format) path for the call_button_color variable
in the following way:
var call_button_color =
'url(IMAGE_PATH/YOUR_PHOTO.png)';
Integrate
into web page
Below is an example code and steps to integrate the
click to call button into your web page:
Put the below code in your web
page's <head> section:
<link
rel="stylesheet" href="css/click2call/click2call.css" />
<script
src="webphone_api.js"></script>
<script
src="js/click2call/click2call.js"></script>
<script>
/**Configuration parameters*/
webphone_api.parameters['serveraddress'] = '';
webphone_api.parameters['username'] = '';
webphone_api.parameters['password'] = '';
webphone_api.parameters['md5'] = '';
webphone_api.parameters['realm'] = '';
webphone_api.parameters['callto'] = '';
webphone_api.parameters['autoaction'] = 1;
//Add any other parameter here
</script>
Copy this html element in you page,
where you want the click to call button to show up:
<div
id="c2k_container_0" title=""><a
href="tel://CALLTO"
id="c2k_alternative_url">CALLTO</a></div>
Customize the button
The provided click to call example
button can further be customized with customization parameters located at the
beginning of click2call.js file in js\click2call\ directory:
/** Customizations */
var call_button_text =
'Call'; // text
displayed on call button
var hangup_button_text =
'Hangup'; // text
displayed on hangup button
var call_button_color =
'#43b61b'; // call
button color
var hangup_button_color =
'#e83232'; // hangup
button color
var status_text_color =
'#ffffff'; // color of displayed
status messages
var button_width =
135; //
button width in pixels
var button_height =
42; // button
height in pixels
var button_radius =
5; // button
corner radius in pixels, higher values will result in a round button
var chatwindow_title =
'Chat'; // chat
window header-title; can be text or html
var
chatwindow_default_state = 0; //
default state of the chat window: 0=open, 1=collapsed
The styling can be further customized
from click2call.css located in css/click2call/ directory.
/**For floating button*/
var float_button =
false; // if
set to true the button will float over the content of the webpage
var float_distance_from_top
= -1; // distance in
pixels from the top of the page. -1 means disabled
var
float_distance_from_left = -1; // distance in pixels from the left of the page. -1 means disabled
var
float_distance_from_bottom = -1; // distance in pixels from the bottom of the page. -1 means disabled
var
float_distance_from_right = -1; // distance in pixels from the right of the page. -1 means disabled
Customize the behavior
The click to call example can further
be customized by editing the js\click2call\click2call.js Javascript file.
All the API functions found in
webphone_api.js can be used to achieve the desired functionality.
For example if you choose to add your
own custom incoming call popup, you can do this in click2call.js file using the
webphone_api.onCallStateChange() function
where you receive call events. For chat message events use the webphone_api.onChat() function. Find more details
about the API functions in the documentation and in webphone_api.js.
Use as a chat window
The click to call button can also be
used as a chat window. This is controlled by the autoaction
parameter (1 means call, 2 means chat).
The chat window can also be opened by
accessing the menu and selecting the Chat item.
The menu can be accessed by right
clicking or by long clicking on the button.
Floating button
This click to call button can also be
used as a floating button on a web page. The floating related configurations
can be found in click2call.js file located in js/click2call/ folder.
To enable floating, set the
"float_button" config to true and specify two direction coordinates
for the floating. For example to have a floating button on the top right corner
of your page, located from 100 pixels from the top and 10 pixels from the
right:
var float_button = true;
var
float_distance_from_top = 100; //
floating 100 pixels from the top of the page
var
float_distance_from_left = -1;
var
float_distance_from_bottom = -1;
var
float_distance_from_right = 10; //
floating 10 pixels from the right of the page
The floating parameters also apply to
the chat window in the same way as for the click to call button.
Note: If somehow your changes will not have effect in the web browser,
you just need to clear the cache.
Multiple instances
To add more than one click to call
button to a page, include the script part in the <head> section once, and
copy the container <div> increasing the id index number for every
instance.
ex:
<div
id="c2k_container_0" title="55555"></div>
<div id="c2k_container_1"
title="66666"></div>
<div
id="c2k_container_2" title="77777"></div>
<div
id="c2k_container_3" title="88888"></div>
These id indexes must be unique and
increasing.
The callto parameter can be set as the
title attribute of the <div> element.
Load on demand
You can also load the sip web phone on
demand as explained here.
Auto-call
If you wish to make a
call automatically, then just initialize the webphone as described above and
-either set also the “autoaction” parameter to 1
-or make the call with
the webphone_api.call(number) API from the onAppStateChange() callback “loaded” event or from the onRegStateChange
() callback “registered” event.
The autoaction API parameter controls the behavior of the click to
call button and can have the following values:
0: Nothing (default) - it
will display the click to call button and will place a call whet the user
clicks it.
1: Call - it will
immediately place a call, once page is loaded in which the click to call button
is integrated.
2: Chat - a chat window
will be displayed for the user
3: Video Call - it will
immediately place a video call, once page is loaded in which the click to call
button is integrated.
Note:
o Even if you initiate a call form the onAppStateChange
“loaded” event and the webphone is not yet registered -and it needs to
register-, then it will handle registration first then it will initialize the
call automatically.
o If your IP-PBX doesn’t require registrations, then just
set the “register” setting to 0.
More
details about the click to call functionality can be found here and in this wiki article.
The most common use case
for the webphone is a dialer (softphone user interface) or as a click to call
solution (simple click to call button user interface).
For these we got you
covered with ready to use solutions shipped with the webphone (see the
softphone.html and the click2call.html files).
However this doesn’t mean
that the webphone usage is restricted only for these. You can create any kind
of solution using the webphone. A few examples are listed here.
All you need is a little
HTML knowledge to create your desired user interface and some JavaScript
knowledge to use the webphone API from your HTML/JS.
You might implement your
solution by extending
the softphone skin or by creating a
new solution from scratch.
See the webphone development section for more details.
Integration with Web server side applications or
scripts
This section is mostly for
server side developers. If you have more JavaScript skills then we recommend to
just use the JavaScript
API directly as described in the development section.
First of all it is
important to mention that the webphone doesn’t have any server side framework
dependencies. You can host it on any webserver without any framework (.PHP,
.NET, Node.Js ot others installed).
The webphone is running
entirely on the client side (in the user browser as a browser sip plugin) and
can be easily manipulated via its JavaScript SIP API, however you can easily integrate the webphone with any
server side application (web applications or web service) or script, be it
.NET, PHP, Node.Js, J2EE or any other language or framework even if you don’t
have JavaScript experience. Just create
a HTTP API to catch events such as login/call start/disconnect and drive your
app logic accordingly.
The most basic things you
can do is to dynamically generate the webphone parameters per
session depending on your needs. For example if the user is already logged-in,
then you can pass its SIP username/password for the webphone (possibly encoded).
For this, just generate
the webphone_config.js dynamically or pass the parameters in the URI.
For a tighter integration
you will just have to call into your server from the webphone.
This can be done with simple
XMLHTTP /AJAX or
websocket requests against your server HTTP API, then process the events in
your server code according to your needs. The requests can be generated using
the built-in HTTP API events or you can just post them yourself from your
custom JavaScript code using websocket or ajax requests. Usually these requests
will be made from callback
events which are triggered on web
phone state machine changes, but you are free to place ajax request anywhere in
your code such as click on a button.
Example:
For example if you need
to save each call details (date, caller, called, duration, others) into a
server side database, then just define a “oncalldetails” or similarly named API
in your server side application which can be called via simple HTTP request in
one of the following ways:
1.
Using the built-in HTTP API integration capabilities:
Just
set the scurl_onincalldisconnected to your HTTP API. For example: https://mydomain.com/myapi/oncalldetails/ (or wherever your API can be called). This method
is very convenient if you are a server side developer with no JavaScript knowledge
as you don’t need to touch any JavaScript to implement this. See the details here.
2.
Using custom AJAX requests:
Use
the onCdr() API to setup a callback which will be
triggered after each call.
Send
an AJAX request (XMLHttpRequest or jQuery get or post) to your application
server with the CDR details.
(You
can pass the details in HTTP GET URL parameters or in HTTP POST body in your
preferred format such as clear text, json, xml or other).
You will need an API on
your web server to handle the websocket or AJAX HTTP GET/POST requests from the
webphone.
This can be done by
implementing a web service or a simple script in any server side framework on
language (such as .ASP .NET, PHP, Node.js or others).
You can push/request
anything from the webphone and do anything with the data (store in a database
such as MS SQL, MySQL or PostgreSQL) or answer with some content to be
displayed on the webphone user interface.
For example on incoming calls
(cached with the onCallStateChange callback or preset with the scurl_onincallsetup parameter) you might look-up the caller id (caller number) in your
database and return details about the caller (such as full name, interests,
etc).
You can do similar things
for all other important events such as on phone start, on chat, on call setup,
etc and perform various actions on your server side such as
processing/transforming/storing the data received by the webphone and/or
returning answers to be processed or displayed by the webphone.
Note: For
auto-provisioning from a server side application, you can create an API to
return all the webphone parameters (settings) and set the “scurl_setparameters”
setting to this API URL.
Custom HTTP
API integration
You can integrate the webphone with
your server code using your custom HTTP requests (AJAX/fetch) API URI’s. These
are called “Action URL’s”, so you can implement various server-side actions
when something happens on the SIP client (such as on incoming call, on call
finished, and others). You can implement these API’s in your existing
server-side framework, using any language or tools (ASP.NET, PHP or any
others).
Just set one or more of the
following settings to point to your server application HTTP API entries which
will be called automatically as the webphone state machine changes:
·
scurl_onstart: will be called when the webphone
is starting
·
scurl_onoutcallsetup: will be called on outgoing call
init
·
scurl_onoutcallringing: will be called on outgoing call
ring
·
scurl_onoutcallconnected: will be called on outgoing call
connect
·
scurl_onoutcalldisconnected: will be called on outgoing call
disconnect with call details (CDR)
·
scurl_onincallsetup: will be called on incoming call
·
scurl_onincallringing: will be called on incoming call
ring
·
scurl_onincallconnected: will be called on incoming call
connect
·
scurl_onincalldisconnected: will be called on incoming call
disconnect with call details (CDR)
·
scurl_oninchat: will be called on incoming instant
message
·
scurl_onoutchat: will be called on outgoing instant
message
·
scurl_setparameters: will be called after onAppStateChange
started event and can be used to provision the webphone from server API. The
answer should contain parameters as key/value pairs, ex:
username=xxx,password=yyy
·
scurl_displaypeerdetails: will be called at the beginning of
incoming and outgoing calls to return details about the peer from your server
API (like full name, address or other details from your CRM). It will be
displayed at the location specified by the “displaypeerdetails” parameter. You
can return any string as clear text or html which can be displayed as-is.
Special keywords will be replaced by
the webphone at runtime. The keywords are listed here.
For example: scurl_onoutcallsetup: https://mydomain.com/myapi/?user=USERNAME&called=CALLEDUMBER
(Your API will be called each time
the webphone user makes an outgoing call and the parameters in uppercase will
be replaced at runtime in the same way as described for the links setting)
For API request, the webphone will
try to use following techniques (first available): AJAX/XHTTP, CORS, JSONP and
websocket (if available).
Make sure that there is no any
cross-domain request restriction: you might need to set the Access-Control-Allow-Origin
HTTP header on your WEB server/service to * or to the target domain if you are
not hosting the webphone on the same domain.
You can achieve similar functionality by
just sending AJAX request from the onCallStateChange callback.
Using these scurl variables is just a
different approach to help users with little JavaScript knowledge.
Integration with third party systems and
CRM’s
Many custom callcenters are using the webphone as
their VoIP client module to implement voice/video call capabilities.
You can use the webphone SIP library to
implement your custom click-to-call solution, use one of the skin templates for
click to call or use the softphone.html as-is integrated into your CRM.
The VoIP web sip phone browser plugin
doesn’t depend on any framework and can be integrated with any system or CRM
with JavaScript binding support. Usually you just need to include the
webphone_api.js, set the basic parameters in the webphone_config.js (such as
serveraddress/username/password to be used, but these can be passed also by the
API) and just use the call() function to make an outgoing calls. Incoming calls
are handled automatically and with a few more API calls you can easily
implement features such as call transfer, conference, chat, dtmf or video call.
For example here is tutorial for Salesforce webphone integration in case if you are interested in this platform or
some details about VoIP callcenter integration.
Consult your CRM documentation to find
the details about integration third-party general modules (or even better if it
has an interface specific for third party phone integrations). Contact us
if you need help with any integration.
Using the webphone with various server side
frameworks
The webphone doesn’t require any server
side web framework however you are free to use your own favorite framework,
language and libraries to interact with the web phone such as PHP, ASP.NET,
J2EE, NodeJS, Perl, C++, Python, Ruby on Rails, Express.js, Django or any other
framework.
This is useful if you have a server
application and you need certain details from the webphone (such as call detail
records to be inserted into your database) or you wish to push some data to the
webphone (settings depending on the enduser, incoming caller details, etc).
By default the webphone has nothing to
do with server side framework (it is a pure client-side library) so you can
deploy it like any other javascript library.
Then you can add server side binding in
various ways:
·
if you don’t have any JavaScript
experience, just use the action URL’s mentioned above
·
otherwise you can interact with
your server side service with AJAX calls (for example you can notify your
server about phone state change by triggering an xhttp request
from the from the onCallStateChange callback) or send call the details after hangup from the onCdr callback.
·
you can use also any other technique
for the communication between the webphone and your server such as WebSocket,
HTTP polling or use a library such as Socket.IO
technique (These might be necessary only if you wish to exchange a lot’s of
data between the webphone and your server application. Otherwise simple HTTP
API requests are just fine)
In short: All you need to do is to
create some API’s in your server application to be called from the webphone,
usually via AJAX XHTTP requests.
Examples:
We don’t have too much framework
specific examples to show as the webphone is a client-side library and the
server side integration is just optional and the usage is really
straightforward as described above:
·
ASP.NET: a very basic example
from one of our customer can be downloaded from here
·
A basic demonstration/example
about using the webphone with PHP can be found here.
·
Integration with various
frameworks can be also done via WebView as described here.
Integration
with SIP server side applications or scripts
This is a more
straightforward topic then the previous Web application integration because
here we are restricted to the SIP protocol capabilities.
Actually the main purpose
of the whole webphone library is to interact with a SIP server.
For a tighter integration
you can take full advantage of the SIP
protocol using the following tools:
·
Your SIP server capabilities
(configure the webphone extensions like any other SIP endpoint, taking full
advantage of your softswitch (or proxy/gateway/other SIP device) capabilities
such as voicemail, server side call forward, call queue, etc
·
Webphone parameters: you can
fully customize the webphone behavior by changing the parameters
·
Webphone API: fully control the
interaction between the webphone and your SIP server using the webphone API. Beyond
basic functionality, you can find useful functions such as BLF, dtmf, presence
which can be used for specific interaction with your SIP server in a standard
way. For example, during a call you can exchange additional details with your
SIP server using SIP INFO, DTMF or even chat/presence/BLF notifications.
·
You can also consider
using a side-channel to exchange information with your server using alternative
methods such as HTTP API or websocket. For this you will need a server side
application and the details described in the previous chapter can be applied.
In case if you have some built-in
application or script then a preferred method to exchange information between
the server and the webphone is the usage of extra SIP headers (which can
be easily sent/extract on your SIP server and also by the webphone). For more
details see the customsipheader parameter
and the setsipheader/getsipheader
API’s.
Integration with the SIP server API is
also possible by using the links parameters. This is
useful for things like balance display, server side contact list, SMS, recharge and others.
This section
is for JavaScript developers. You can use this webphone also without any
JavaScript skills:
·
If you don’t have any programming
skills: customize and
use the included turn-key templates (for example the softphone.html or click2call.html)
on your website.
·
If you are a server-side developer
not comfortable with JS: take advantage of the server
integration capabilities
Developers can use the webphone as an
SDK (JavaScript SIP library) to create any custom VoIP solution,
standalone or integrated in any webpage or web application.
First of all you should download
and deploy the webphone on your webserver (copy the webphone folder to your web server).
You can also launch it from local file
system on your dev environment (works with some limitations), but the best is
if you use it from a secure (HTTPS) webserver.
Notes:
Requirements:
Basic HTML and JavaScript
knowledge is required to work with the webphone to create custom solutions.
You will also need a web server and a SIP account.
See more details here.
Settings:
Once you deployed the webphone, you
will have to adjust the settings. At least the “serveraddress”
parameter must be set.
The library parameters can be preconfigured in webphone_config.js, changed
runtime from JavaScript, passed by URL parameters or set dynamically by any
server side script such as PHP, .NET, java servlet, J2EE or Node.js.
Frameworks:
The webphone doesn’t require any extra
client or server side framework (it is a client side VoIP implementation which
can be used from simple JavaScript) however you are free to use your own
favorite framework or libraries to interact
with the web phone (for example use with jQuery on the client side or integrate
into your PHP/.ASP/.NET/J2EE/NodeJS or other server side framework or use it
straight without any frameworks involved).
Demo:
The downloadable demo version has some limitations to disable
commercial usage, however if your development/test process is affected by these
then you can request a
trial from mizutech with all demo limitation removed.
The public JavaScript API can be found
in "webphone_api.js" file, under global javascript namespace
"webphone_api".
Just include the "webphone_api.js" to your project or html
and start using the webphone API.
The API reference can be found here.
Make sure to call any API function only
after the webphone completely initializes itself (the onAppStateChange callback was fired with the “loaded” event).
Many functionalities can be controlled by both the parameters and by the API.
When you need some persistent global behavior then you might use the
parameters, otherwise use the API if you need more control (for example toggle
a function at runtime or apply it only in some circumstances such as for a
single call only or manage multiple simultaneous
calls differently). For example you can use the voicerecupload
parameter if you need all calls to be recorded or use the voicerecord() API to record only some
calls (or part of the calls). Another example is the customsipheader
parameter vs the setsipheader() API.
Follow these steps to get started:
1
Download and
deploy the webphone
3.
Include the webphone to your
project by adding/importing the webphone_api.js
to your project
For HTML add the following line: <script
src="webphone_api.js"></script>
4.
Create any user
interface in HTML/CSS (or any other
framework capable to bind to JavaScript) if you need something from scratch.
Otherwise you can use, modify or start with one of
the html included in the webphone package: the softphone.html, the click2call.html or the examples in the samples folder.
5.
Configure the webphone via its parameters. This can be done in multiple ways (but it is enough
if you use one method only):
a.
by using webphone_api.setparameter() API from JavaScript once the webphone is loaded
b.
by setting static parameters in
the webphone_config.js file
c.
other methods described here
6.
Use the webphone API from your user interface controls (such as webphone_api.register () from your CONNECT button or webphone_api.call () from your CALL button)
7.
Handle the webphone state machine
(call state) by using the onCallStateChange and other callbacks (modify your user interface based on the webphone
state, such as displaying “Connected” when the webphone is registered or
displaying a “Incoming call from X. Accept/Reject” message on incoming calls)
8.
Consult the parameters, the API, the examples in the samples folder and other parts of this documentation for more details
There are 3 basic things which you
have to do while working with the SIP SDK:
1.
Set parameters:
There is a long list of parameters that you can set to configure the
webphone after your needs (but only a few really important).These can be set
statically in the webphone_config.js files, dynamically from your code using
the setparameter API or with other methods as described at the beginning of the
parameters
chapter.
2.
Call API
functions: You can interact with the webphone by calling its API. For example you can initiate a
call with the call function.
3.
Process the
events: Handle the callback notifications according to your application logic. The most important
is the onCallStateChange callback from where can update your user interface
from there as required.
Note:
You can use the webphone also without point 2 and 3, bye just configuring a
html shipped with the webphone (for example the softphone.html).
Also even if you use point 2 (API), for very simple apps you might not need to
watch for events at all (For example to make blind calls to a destination).
A minimal
implementation (a simple VoIP call) can be achieved with less than 5 lines of
code on your website. See the minimal_example.html (found in the webphone
package samples folder).
Example:
<head>
<!-- Include the
webphone_api.js to your webpage -->
<script src="webphone_api.js"></script>
</head>
<body>
<script>
//Wait until the webphone
is loaded, before calling any API functions
webphone_api.onAppStateChange(function (state)
{
if (state ===
'loaded')
{
//Set parameters (Replace
upper case worlds with your settings)
//Alternatively these can
be also preset in your webphone_config.js file or passed as URL parameters
webphone_api.setparameter('serveraddress',
SERVERADDRESS);
webphone_api.setparameter('username',
USERNAME);
webphone_api.setparameter('password',
PASSWORD);
//See the “Parameters”
section below for more options
//Start the webphone
(optional but recommended)
webphone_api.start();
//These API calls below
actually should be placed behind separate functions (button clicks)
//Make a call (Usually
initiated by user action, such as click on a click to call button. Number can
be extension, SIP username, SIP URI or mobile/landline phone)
webphone_api.call(NUMBER);
//Hang-up (usually called
from “disconnect” button click)
webphone_api.hangup();
//Send
instant message (Number can be extension, SIP username. Usually called from a
“send chat” button)
webphone_api.sendchat(NUMBER,
MESSAGETEXT);
}
});
//You should also handle events from the webphone and change your GUI
accordingly (onXXX callbacks)
</script>
</body>
See the html files in the webphone/samples folder for more examples.
o a very simple but functional basic example can be
found in the webphone package: basic_example.html
o as a better example, see the tech demo page
(techdemo_example.html / techdemo_example.js) or the api_example.html
o click2call.html is a ready to use click to call
implementation
o softphone.html implements a fully features browser
softphone (this can be found in the webphone root folder, not in the samples
folder). You might choose to extend this skin instead of creating your own from scratch (in case if your goal is to
create a complex dialer based solution).
You can also try the same examples from
our online demo.
You are free to use/modify any of these
files and adjust it after your needs or create your own solution from scratch.
For beginners we would recommend to
start with the “basic_example.html “, “api_example.html “ or “techdemo_example”
and modify/improve it after your needs.
If you need something ready to use,
than just use the “softphone.html” (this can be also customized with the many
webphone parameters or by changing the html/css/js files)
Most of the traditional VoIP
functionalities (in/our calls, chat, call divert) can be handled very easily
with the webphone, however some advanced features might require special care if
you wish to interact with them.
Lots of things can be achieved by the
webphone parameters, without the need of any programming effort.
Here are some examples for advanced
usage:
o settings/auto-provisioning: it can be done easily
with the setparameter API but you
might have special needs which would require to pass the parameters in a
special way. See the beginning of the parameters section for the possibilities and some more in the FAQ.
o multiple lines: handled automatically but you might
handle it explicitly if required for your project
o low-level engine messages:
this is only for advanced users and rarely needed to intercept these messages.
You might use the onEvent
callback for this but it is recommended to use the other high level events such
as the onCallStateChange to handle
the web SIP state machine
o low-level interaction with the native engines: if
somehow you have some extra requirements which is not available with this
high-level API then you might use the low-level jvoip API with the NS and Java engines
o dtmf, call transfer, hold, forward: we took special
care to make these as simple to use as possible so all of these can be handled
by a single API call
o voice call recording: just set the voicerecupload parameter or use the voicerecord API from Java Script
o conference: handled automatically by default via a
single API call but optionally you might implement some specific user interface
to display all parties
o parameter encryption/obfuscation: usually not
required since you are working with them in the otherwise secure user session,
but if you wish to use it then it is described here
o video: you must provide a html element where the
video have to be displayed and manage this GUI accordingly: <div
id="video_container"></div>
o chat, sms: these also requires some extra user
interface to send the messages and display the call history
o manipulating SIP messages: requires some VoIP/SIP
skills if you need to interact this way with your VoIP server and you can use
the setsipheader/getsipheader
API’s
o create a native application by using the webphone
from a WebView
Note: all of these are also implemented
in the “softphone” skin which is included with the webphone so you
might use/modify this skin if you need a complete softphone like solution
instead to develop your own from scratch (if you don’t have specific
requirements which can’t be handled by customizing the softphone skin)
For more details regarding custom
development, see the “JavaScript API” section
below in this documentation.
The webphone parameters can be
used to fully customize the webphone behavior including SIP settings, media settings,
user interface settings, for example parameters like the SIP server domain,
authentication, called party number, autodial and many others.
Most of the settings are optional
except the "serveraddress" (but also this can be provided at
runtime via the API).
The other important parameters are the
SIP user credentials (username, password) and the called number (callto)
which you can also preset (for example if you wish to implement click to call)
however these are usually entered by user (and optionally can be saved in local
cookie for later reuse).
The webphone parameters can be set in
multiple ways (statically and dynamically)
to allow maximum flexibility and ease the usage for any work-flow.
Use one (or more) of the following methods for the webphone configuration:
·
Preset the settings in the "webphone_config.js" file. This should be used for parameters which
are expected to not change at runtime, such as the serveraddress parameter.
·
Use the setparameter() API call from JavaScript. For most parameters the setparameter function
must be called from the onAppStateChange callback “loaded” event. Never
sooner (API functions, including the setparameter, works only after the
“loaded” event was triggered in onAppStateChange).
·
Changing the parameters by using
the webphone_api.parameters['paramname'] = 'value'
format is NOT recommended because parameters changed in this way can’t be
overwritten later by the setparameter() API.
·
Webpage URL query string (The webphone will look at the
embedding document URL at startup. Prefix
all keys with “wp_”. For example &wp_username=x or any other parameter
specified in this documentation)
·
Via the scurl_setparameters settings which can load the parameters from your
server side application (This will be
called after the onAppStateChange “started” event and can be used to provision
the webphone from server API. The answer should contain parameters as key/value
pairs, ex: username=xxx,password=yyy)
·
Cookies (prefix
all keys with “wp_”. For example wp_username)
·
Web session
variables (PHP example)
·
SIP signaling
(sent from server) with the x-mparam header (or x-mparamp if need to persist).
Example: x-mparam=loglevel=5;aec=0
·
Auto-provisioning: the browser
phone is also capable to download it’s settings from a config file based on
user entered OP CODE (although this way of configuration is a little bit
redundant for a web app, since you can easily create different versions of the
app –for example by deploying it in different folders- already preconfigured
for your customers, providing a direct link to the desired version instead of
asking the users to enter an additional OPCODE)
·
User input: You can let the user
to modify the settings. For example to enter username/password for SIP
authentication (For example using the softphone skin most of the settings can
be specified by the users at login/settings screens, which might overwrite
server side settings loaded from the webphone_config.js file if any)
·
Also see here and here
Any of these methods can be used or
they can be even mixed.
The quick and easiest way to start
is to just set all the required parameters in the webphone_config.js file. For
example:
webphone_api.parameters = {
serveraddress: 'voip.mizu-voip.com', //your
SIP server domain:port or IP:port
username: 'webphonetest1', //the
username is usually specified by the enduser and not need to be set globally
here
password: 'webphonetest1', //the
password is usually specified by the enduser and not need to be set globally
here
displayname: 'John
Smith', //optional display name, usually specified by
the enduser and not need to be set globally here
brandname: 'BestPhone', //your
brand name
rejectonbusy: true, //will
reject incoming call if user already in call
ringtimeout: 50000,
//disconnect the call after 50 sec on no answer
loglevel: 5 //enable
detailed logs
//no comma is needed after the
last parameter
};
Usually you might set some parameters in the above webphone_config.js
file (the common static/global parameters applicable for all users which
doesn’t need to be changes such as the serveraddress or proxy address), then
you might use one of the other methods to specify instance specific parameters
(for example ask the user credentials at login screen and set it as the
username/password parameters with the setparameter API).
Note:
·
For a basic usage you will have
to set only your VoIP server ip or domain name (“serveraddress” parameter).
The SIP username/password
are asked from the user with the default skins if not preconfigured.
The rest of the
parameters are optional and should be changed only if you have a good reason
for it.
·
Some parameters
(username/password, displayname) are usually set by the user via some user
interface (using the setparameter() API), however in some situation you might
hardcode them on the server side webphone_config.js file. For example if you
have some static IVR service and the caller user identity doesn’t matter.
·
All parameters can be passed as
strings and will be converted to the proper type internally by the webphone
browser plugin.
·
Most parameters are saved by the
webphone (in web storage and cookies) and reused at next sessions (but you can
always overwrite already stored settings or clear them by setting the value to
'NULL' or use different profiles).
·
Don’t remove or comment out
already set parameters because the old value might be already cached by the
browser webphone. Instead of this you should just set to 'NULL'/ 'DEF' or
its default value. Details here.
·
If you have changed
the parameters in the webphone_config.js then you might change its
jscodeversion parameter where you include it in your project, to avoid any caching and force a re-download by the browser.
For example: <script
src="webphone_config.js?jscodeversion=1234"></script>
·
Prefix parameter name with
“ucfg_” if it should prefer client side settings (otherwise server side settings
defined in the webphone_config.js will overwrite the client settings). Example:
ucfg_aec: 2
·
You can also clear the settings
with the delsettings API or force the webphone to forget old settings
with the resetsettings parameter. Details here.
·
Parameters can be also encrypted
or obfuscated. See the “Parameter security” section for the details.
The most important parameters are
the followings:
·
serveraddress (your SIP server domain or IP:port, usually set statically
in the webphone_config.js)
·
username/password (SIP account details, usually
entered by the endusers and passed to the webphone with the setparameter
API or by URL)
Other important parameters you might
need to set are the followings:
·
sipusername (sometimes required for authentication or for Caller-ID
purposes)
If your SIP server
requires a different auth vs user id, then you can set the user id with the username
parameter and the authorization username with the sipusername. You can also use
it to configure a Caller ID (different from the auth user name) if your SIP server
accepts a different username/sipusername.
With other words:
o The username will be used as user id
(extension number / Caller–ID)
o The sipusername parameter will be used
as the authentication username
o If only one is set, then it will be
used for both the above purposes
·
displayname
(usually from user input –enduser full name)
·
proxyaddress (only if you have an outbound proxy different from your SIP
server address)
·
register
(you might set it to 0 if no registration is not required)
·
other sip
account related settings (change any only if needed for your goals)
·
engine priority (only if you prefer a specific engine for some special
reason, otherwise the “best” possible engine will be used automatically)
·
webrtcserveraddress (if you have your own WebRTC gateway or your softswitch has built-in
WebRTC capabilities, set this to your websocket listener URL)
·
codec and prefcodec (no any changes are recommended for
these since the webphone is capable to auto negotiate the “best”
possible codec to
use, but you might change it if you have some special needs)
·
other engine
related settings
(change any only if needed for your goals)
·
callto and autoaction (in case if you wish to make an
action at startup which otherwise can be done also with the API)
·
other call divert
related settings
such as autoaccept,
callforwardonbusy and others (you might use the API instead for these tasks)
·
user interface related settings if you use the softphone
skin (the
softphone.html, included with the webphone)
There is no need to any “fine-tuning” of
the parameters.
The webphone has a long list of configurable settings (listed below)
for maximum flexibility, however it is not recommended to change any parameter
unless strictly required to achieve your project goals. All parameters has
meaningful optimal value by default or it is auto-negotiated regarding
server/network/environment and unnecessarily altering the settings might result
in sub-optimal behavior.
Credentials and other basic SIP
parameters:
(string)
The address of your SIP server
(domain or IP + port), usually the same with your SIP domain.
It can be specified as IP address or
as A or SRV domain name.
Specify also the port if your server
is not using the default 5060; in this case append the port after the address
separated by colon.
Examples:
mydomain.com (this will use the default SIP port 5060)
sip.mydomain.com:5062
10.20.30.40:5065
10.20.30.40 (this will use the default SIP port 5060)
This is the single most important
parameter for the webphone (along with the username/password but those can be
also entered by the user).
Default value is empty.
Note:
·
Sometime you might have to set
also the SIP
proxy address and the transport parameters (depending on your server side
requirements). Read here for
more details.
·
If you are using a (sub)domain as
your SIP server address, then we recommend to always set it’s DNS A record also
(not just the SRV record) for full WebRTC compatibility, since browsers might not
ask for SRV records.
·
If your server address is
different from your SIP domain, then you might set the SIP domain as the realm parameter.
·
If you SIP server doesn’t allow
UDP for the SIP signaling then set the transport
parameter accordingly.
(string)
This is the SIP account user name
(User ID / Extension ID).
Default value is empty.
Note:
o Technically speaking, this is the user
part of the Address of Record (AOR), sent in the “From” and “Contact” SIP
headers.
It is used for authentication (if no sipusername parameter is set) and as A
number/Caller-ID for the outgoing calls. Other users can make call to this
endpoint by dialing this value. Some SIP service providers use a globally
routable telephone number (DID) as the SIP username.
o The username/password parameters are
usually supplied by the user (via some user interface and then calling the
setparameter API), however in some cases you might just set it statically in
the webphone_config.js file (when caller user credentials doesn’t matter). See
more here.
In case if you set it “statically” in the webpone_api.js and you are using the
softphone skin (softphone.html) the username will not be asked from the enduser
at login.
o Even if you don’t need a username
and/or your server accepts all calls without authentication, you must set the
username to some value: the “anonymous” username might be used in this case.
o If you set the username setting to
“Anonymous” then the username input box will be hidden on the “softphone” skin
settings and login screens.
o If you wish to set a separate
caller-id you can use this parameter to specify it and then use the sipusername parameter to specify the username used for authentication as
specified in SIP standards. However please note that most SIP server can treat
also the below mentioned “displayname” parameter as the caller-id so the usage
of separate username/sipusername is usually not necessary and confusing. See
more details here.
o If the showusername parameter is set
to 2 then both the username and the caller-id input will be displayed on the
softphone skin login page.
o For maximum compatibility with
third-party software and services, avoid using special and non-ASCII
characters.
(string)
This is the username used for SIP
digest authentication (Auth User Name or Authorization Name).
It is an optional setting which
should be set only if your SIP server requires a different username for
authentication.
If your SIP user name and auth user
name are different, the proceed like this:
·
Set the webphone username to the SIP user name (also known as
extension number or the user part of the AOR)
·
Set the webphone sipusername parameter to the Auth user name (also
known as Auth ID or PIN in some systems)
If only one of the above are set
(username or sipusername) then the same will be used for both purposes (both as
user id and authorization user name)
You need to set this if only the username parameter is not the same with the auth
user name (when you need to use a different caller id and username for
authentication).
o If this is not set, then the username parameter will be used for both the
caller-id (public-identity sent with the From
SIP header) and authorization (private identity sent with the Authorization SIP header).
o If this is set, then this parameter
will be used for authorization and the username parameter will be used for caller ID.
o If you expect the @ character (full
SIP URI) in the sipusername, then set the handleusernameuri parameter to 0 to
prevent extracting the domain from it on the softphone skin
Default value is empty.
See more details here and here.
(string)
This is the SIP account password
used for authentication.
Default value is empty.
Note:
o Make sure to never hardcode the
password in html or set it via insecure http. See more details here about
security.
o You can use the webphone also without
password (if not using via server or your server doesn’t authenticate the
users). In this case you can set the password to any value since it is supposed
that it will not be required for calls or registrations.
o Usually you ask the password from the
endusers and set it at runtime with the setparameters API. In case if you set
it “statically” in the webpone_api.js and you are using the softphone skin
(softphone.html) the password will not be asked from the enduser at login.
o For the softphone user interface you
can also set hidepassword and pwdautocomplete parameters.
o If your IP-PBX accept blind
registrations and/or calls then the value of the password doesn’t matter (it
will not be used anyway)
o If you set the password setting to
“nopassword” then the password input box will be hidden on the “softphone” skin
settings and login screens.
o If your IP-PBX doesn’t require
registrations or you are not using any server then you should set the “register” setting to 0.
o SIP passwords are always case sensitive.
(string)
Optional SIP display name.
Specify default display name used in
“from” or “contact” SIP headers.
This is often sent to peer as Caller
ID when placing a call (if not overwritten on the server side).
Default value is empty (which means that only the “username” field will be
sent to the peers).
Note:
This has nothing to do with the text displayed by the
webphone skin. This is a SIP parameter to specify the display name sent to the
others with call setup.
See more details here.
(string)
Optional parameter to set the SIP
realm (logical SIP domain) if not the same with the serveraddress.
Rarely required. (Only if your VoIP
server has different realm setting as its domain and it strictly enforces that
realm for authentication)
Default value is empty. (By default the serveraddress will be used without
the port number)
(string)
Outbound SIP proxy address
(Examples: mydomain.com, proxy.mydomain.com:5065,
10.20.30.40:5065)
Leave it empty if you don’t have a
stateless proxy. (Use only the serveraddress parameter)
Default value is empty.
Note:
Set to “NULL” if you already set it before (to a wrong value) and wish to clear
it.
If the showproxyaddress parameter is
set to 2 then the proxy address input will be displayed on the softphone skin
login page.
(number)
With this parameter you can set
whether the softphone should register (connect) to the sip server.
0: no (the webphone will not send
REGISTER requests)
1: auto guess (yes if
username/password are preset, otherwise no)
2: yes (and must be registered
before to make calls)
Default value is 1.
Related
parameters: autostart
(start webphone with page load), appengine_startat (native engine launch),
startsipstack (NS engine specific), autologin (softphone skin specific),
mustconnect (if set to true the webphone will not allow any calls before
registered; default is false), regtimeout (register no answer timeout for the
WebRTC engine in milliseconds; default is 6000; 0 means no retry).
(number)
Registration interval in seconds (used
by the re-registration expires timer).
Default value is 120 or 300 depending
on the circumstances.
This is important for SIP servers to find out unexpected termination of
the webphone application or webpage such as killing the browser, power loss or
others (so the server will know that the client is no longer alive if this time
is expired, but no new re-registration were received from the client).
Note: we don’t recommend to set the re-register interval below 30
seconds (it just causes unnecessary server load; below 30 seconds most of the
SIP servers will not decide anyway and some servers doesn’t accept such short
re-registration periods). Also you should not set it longer than 3600 (one
hour).
Library, engine, transport, SIP,
media, DTMF, presence and BLF related settings:
By default the webphone will choose
the “best” suitable engines automatically based on OS/browser/server support.
This algorithm is optimized for all OS and all browsers so you can be sure that
your users will have the best experience with default settings, however, if you
wish, you can influence this engine selection algorithm by setting one or more
of the following parameters:
·
enginepriority_java
·
enginepriority_webrtc
·
enginepriority_ns
·
enginepriority_flash
·
enginepriority_app
·
enginepriority_p2p
·
enginepriority_accessnum
·
enginepriority_nativedial
·
enginepriority_otherbrowser
Possible values:
0: Disabled (never
use this engine)
1: Lower (decrease
the engine priority)
2: Normal (default)
3: Higher (will boost
engine priority)
4: Highest (will use
this engine whenever possible)
5: Force (only this
engine will be used)
Example:
-if you wish to prioritize the NS
engine, just set: enginepriority_ns: 3
-if you wish to prioritize the
WebRTC engine, just set: enginepriority_webrtc: 3
-if you wish to avoid WebRTC engine,
just set: enginepriority_webrtc: 1
-if you wish to force the WebRTC
engine only, just set: enginepriority_webrtc: 5
Best practices:
-You should not change
the engine priorities unless you have a good reason (one of the main strength
of the webphone is automatic optimal engine selection based on circumstances, so there should be
rare cases when you might need to adjust this manually)
-Even if you have a
favorite engine, you should not force it or disable the others. Just set your
favorite engine priority to 3 or 4. This way even endusers which doesn’t have a
chance to run your favorite engine might be able to make calls with other
engines.
-Even if for some reason
you don’t like an engine, don’t entirely disable it, just lower its priority
(set its enginepriority to 1 instead of 0). This means that the webphone will
pickup the engine only if there is no -any other alternatives and having the
webphone working with an unwanted engine is much better then not working at all
-It is recommended to
set engine priority from static settings (for example in the webphone_config.js
file) and not at runtime. In case if you have to change the engine priorities
at runtime using the setparameter() API, then you must do it only from the
onAppStateChange “loaded” event, not sooner or later.
The engines also have a
built-in default priority number assigned, which can range from 0 to 100 and
can be changed with the enginedefpriority_ENGINENAME settings.
Default values:
enginedefpriority_java:
32
enginedefpriority_webrtc: 20
enginedefpriority_flash: 13
enginedefpriority_ns: 30
enginedefpriority_app: 10
enginedefpriority_p2p: 5
enginedefpriority_callback: 5
enginedefpriority_nativedial: 3
You should not touch these
values!
Note:
o
You can disable
the NS engine for linux by setting the linnsengine
parameter to false.
o
You can disable
the NS engine for MacOS by setting the macnsengine
parameter to false.
o
You can disable
the linux NS engine for windows by setting the winlinmacnsengine
parameter to false (this is for test only
and defaults to false).
o
You can disable
the NS engine for Windows only if you completely disable the NS engine by
setting enginepriority_ns to 0.
(string)
WebSocket server URL for WebRTC.
Optional setting to indicate the
domain name or IP address of your websocket service used for WebRTC if any
(your server address and websocket listen port).
The following URI format can be
used:
protocol:address:port/path
Where:
The protocol can be ws
(unsecure websocket) or wss (secure
websocket)
The address can be an IP address or a (sub)domain name
The port is where the websocket is listening and it
must be specified if not 80
The path part must be set if your server require it
(For example Asterisk requires the “ws” path). Check your server documentation
for the exact format.
Examples:
ws://mydomain.com
ws://10.20.30.40:5065
wss://subdomain.mydomain.com/anypath
wss://asterisk.mydomain.com:8089/ws
wss://sip.mydomain.com:8080
Default value is empty (which means
auto service discovery and if no webrtc service found then the mizu webrtc
service can be used if accessible).
Note:
o
You can verify
if the address you have set is correct by trying a simple websocket connect
with some tool.
o
Latest browsers
require secure websocket (wss), otherwise media (call recording) permissions
will be denied. You will need to install an SSL certificate for your WebRTC server
for this and set this parameter with the domain name (not IP address). This is
needed only if your VoIP server is WebRTC capable or you have your own WebRTC
to SIP gateway. Otherwise no changes are required.
o
Multiple servers
can be set separating the addresses by comma. In this case the webphone will
use the closest by default (with fastest response time) and it is capable to
failover to other server/gateway
o
By default the
webphone might use our WebRTC-SIP service if your SIP server has a public IP
(accessible over the internet) AND the webphone auto selects the WebRTC
engine AND you haven’t set your own websocket listener for webrtc. This
is a free service tier offer by us for your convenience, but its usage is
optional and the webphone works also without this service.
More details about
webrtc can be found in the FAQ: here and here.
(string)
Optional setting to indicate the
address (domain name or IP address + port number) of your flash service if any
(flash media + RTMP) which might improve the SIP availability in some exotic or
outdated browsers where the other engines such as WebRTC, Java or NS are not
available.
If not set, then the mizu flash to
sip service might be used (rarely used in normal circumstances and it can be
also disabled if for some reason you always wish to avoid it).
Format: yourdomain.com:rtmpport
Example: 10.20.30.40:5678
Default value is empty.
(string)
STUN server address in address:port
format (RFC 5389)
You can set to “NULL” to completely
disable STUN. Usually STUN is not required at all, however in some
circumstances (mostly depending on your SIP server and outbound trunk
capabilities) it might help to avoid unnecessary RTP routing (direct peer to
peer RTP routing bypassing your server).
Examples:
11.22.33.44:3478
mystunserver.com:3478
NULL
By default (if you leave this
setting unchanged) the webphone will use the Mizutech STUN servers (unlimited
free service for all webphone customers). You can change this to your own STUN
server or use any public server if you wish.
Note:
If you set an incorrect STUN server, then the symptoms
are extra delays at call setup (up to “icetimeout”).
Instead of using the stunserveraddress parameter, you
might use the ice parameter to configure both stun and turn together.
(string)
TURN server address in address:port
format (RFC 5766)
You can set to “NULL” to completely
disable TURN.
Examples:
11.22.33.44:80
mystunserver.com:80
NULL
If your server is capable to route
the RTP, then TURN is usually not required at all.
TURN is used mostly only with WebRTC
and might be useful only if the webphone cannot send the media directly to the
peer (which is usually your VoIP server) and your server doesn’t support TCP
candidates. For example if all UDP is blocked or only TCP 80 is allowed or you
need peer to peer media via TURN relay.
By default (if you leave this
setting unchanged) the webphone can use the Mizutech TURN servers. If you wish,
you can deploy your own TURN server using the popular open source coturn server. The MizuTech WebRTC to SIP gateway also has its own built-in TURN
server and there is no
need to set this parameter.
Note: Instead of using the turnserveraddress
parameter, you might use the ice parameter to configure both stun and turn
together.
(string)
Any TURN URI parameter. Required only if the turnserveraddress is set.
Example: transport=tcp
(string)
Username for turn authentication. Required only if the turnserveraddress is set.
(string)
Password for turn authentication. Required only if the turnserveraddress is set.
Note: in case if you are using the mizu server or
gateway then don’t bother securing the turn password as the server will use
also other mechanisms to reject unauthorized TURN requests.
(string)
Instead of using the above STUN and
TURN parameters, you can use this ice parameter in the following format:
ice: ' [{
url:"stun:stun.l.google.com:19302"}, { url: "turn:user@myturnserver.com",
credential: "myTurnPassword"}] '
or
ice: ' [{
url:"stun:stun.l.google.com:19302"}, { url: "turn:myturnserver.com:PORT",
username: "myTurnUsername", credential: "myTurnPassword"}] '
In case if you don’t use WebRTC or
you are using mizutech WebRTC-SIP gateway (MRTC) then there is no need to set
any ice/stun/turn parameter as they are discovered automatically (service
provided by the gateway). Otherwise the default in this case is:
ice: '[{
url:"stun:rtc.mizu-voip.com:8090"}, {
url:"turn:rtc.mizu-voip.com:80?transport=tcp","username":"mzturnusr","credential":"***"}]'
In case if you configured the
webrtcserveraddress parameter to point to your WebRTC server or gateway
websocket listener, then you might reconfigure this ice parameter if you also
have stun/turn service (you might use the coturn).
You might also configure any other
stun service. A list of public stun servers can be found here or here.
There are no public free turn
servers (as turn is routing the media also and not cheap to host).
You can also set multiple STUN and
TURN servers if you wish.
(number)
Timeout for ICE address gathering
(STUN/TURN/others) in milliseconds.
Default is 2000 (2 seconds).
You might increase in special
circumstances if you are using some slow STUN/TURN server or decrease if peer
address is public (like if your SIP or WebRTC server is on public IP always
routing the media, so calls will work also without STUN).
(number)
STUN/TURN usage on local LAN. This
setting helps to avoid unnecessary STUN/TURN connections, negotiations and call
setup delay.
Possible values:
0: no (will set the TURN and STUN
servers to null, regardless of user settings and configurations)
1: STUN only (keep using STUN, but
no TURN)
2: use both STUN and TURN (use STUN
and TURN also with local servers)
Default: 1
(number)
Check rport in SIP signaling
(requested and received from the SIP server by the VIA header)
0=don’t ask (rtport request will not
be added to the VIA header)
1=use only for symmetric NAT (only
when it is sure that the public address will be correct)
2=always (always request and use the
returned value except if already on public ip)
3=request even on public IP
(meaningless in most cases)
9=request with the signaling, but
don’t use the returned value (good If you want to keep the local IP and for
peer to peer calls)
Change to 0 or 2 only if you have
NAT issues (depending on your server type and settings)
(You might adjust also the
use_fast_stun parameter if you change the use_rport)
Default is 1
(number)
Fast stun request on startup.
-1=force private address (if the client
has both private and public IP, than the private IP will be sent in the
signaling)
0=no
1=use only for stable symmetric NAT
2=use only if both tests match even if
not symmetric (recommended)
3=use for symmetric NAT even if only
one match
4=always
5=use even on public IP
Change if you have NAT issues
(depending on your server type and settings)
(You might adjust also the use_rport
parameter if use_fast_stun is changed)
Default is 2
(number)
Specify to enable or disable peer to
peer signaling routing feature.
Possible values:
o 0: no (direct user to user routing
fully disabled forcing the call to travel via upper SIP server –will also add
X-P2P: no header)
o 1: yes (full p2p direct signaling
enabled when possible)
o 2: proxy (might go over proxy socket
processing. Actually this is a special option between no and yes where the
signaling might be forwarded by proxy but might not sent directly or via upper
server –will also add X-P2P: proxy header)
o 3: process (might go over proxy with
full endpoint processing. Actually this is a special option between no and yes
where the signaling might get fully processed by proxy but might not travel via
upper server –will also add X-P2P: process header)
Default is 1.
You might set to 0 (disable) in case if the call
signaling has to reach your server (for example if you are using ring groups to
fork the calls, or you wish to record the calls on your SIP server or if for
billing purposes it is important that your server see also the enduser to
enduser calls).
Otherwise with the default 1 value the webphone might
contact directly the other party or the WebRTC gateway (in case of the WebRTC
engine) might route the call directly between endusers, thus saving your server
resources and shortening the network path.
Note: this might add a X-P2P: no/process/proxy/yes
header to the SIP signaling notifying the gateway/server if routing have to be
forced/ignored.
(number)
Fast ICE negotiations (for p2p rtp
routing):
-1: suggest server side media
routing (X-P2PM: 1)
0: no (set to 0 only if your server
needs to always route the media)
1: auto
2: yes
3: always (not recommended)
Default is 1
Note:
If set to 1 or 2 then stun should not be disabled
Old parameter name was p2prtp.
Specify to enable (1,2) or disable (0,-1) peer to peer
media routing feature (direct RTP routing). You might set to -1 (disable) in
case if the call media (RTP) must be routed through your SIP server (for
example if you wish to voice record the calls on your server). Otherwise the
webphone might route the media directly between webphone instances thus saving
your server resources and shortening the network path. Please note that the
media might be routed directly between the endpoint even if this parameter is
set to 0, according the SDP and ICE negotiation (this can be influenced by your
SIP server configuration by the usual NAT and RTP related settings globally or
by extension).
Default is 1 (p2p for media enabled routing encrypted
RTP directly between the endpoints when possible).
(number)
Try to auto-detect webrtc address if
not set (if the active SIP server has built-in WebRTC capabilities)
0: no
1: yes
Default is 1.
(number)
Specify how to launch the app engine
(native dialer / native softphone) if the rare events when it might be required
(if no any other engine can be used).
1: at start
2: auto (default)
3: at call attempt
(string)
Android native softphone download
URL if any. (Optional setting to allow alternative softphone offer on Google
Play).
Note: Android browsers has support
also for WebRTC so this might be selected only with old phones or if you
disable WebRTC.
Default is empty (which means the
default app).
(string)
iOS native softphone download URL if
any. (Optional setting to allow alternative softphone offer on Apple App
Store).
Old Safari browsers (up to v.11)
under iOS doesn’t offer any plugin for VoIP so the webphone can use its native
softphone (will be auto provisioned from your webphone settings).
Default is empty (which means the
default app).
(string)
Specify the URI handler to be
registered to launch native apps if needed.
The defaults are: sip, tel, webphone
You might reconfigure it if you use
some other third-party app that is triggered for other protocol. For example: app_protocol: “myapp”
(string)
Set this if your IP-PBX has an
access number where users can call into from PSTN and it can forward their call
on VoIP (IVR asking for the target number).
This can be used when no other
engines are working (no suitable environment, no internet connection).
Default is empty.
(string)
Set this if your server has a
callback access number where users can ring into and will receive a call from
your server (possibly with an IVR which might offer the possibility to specify
the destination number via DTMF).
This can be used when no other
engines are working (no suitable environment, no internet connection) and it is
very useful in situation where call from the server is cheaper than user call
to server.
Default is empty.
(string)
This will overwrite the default
User-Agent setting.
Do not set this when used with mizu
VoIP servers because the server detects extra capabilities by reading this
header.
Default is empty.
(string)
Set a custom sip header (a line in
the SIP signaling) that will be sent with all messages. Can be used for various
integration purposes and usually has a key:val format. For example: myheader:myvalue.
Default is empty.
Note:
Custom SIP headers should begin with
“X-“ to be able to bypass servers, gateways and proxies (For example: X-MyHeader: 47).
You can add more than one header,
separated by semicolon or “CRLF” in case if you must use semicolon in the value
(For example: customsipheader: 'x-key1:
val1;x-key2: val2',).
You can also use the setsipheader API call at runtime. It can be used
instead of this parameter or you can use both together (both this parameter and
the API)
(string)
Set custom SIP Contact URI
parameters for REGISTER and INVITE requests.
Default is empty.
Set to 'NULL' to clear.
Example:
If the original contact line looks like Contact:
<sips:1111@any.invalid;transport=wss>;expires=180
and you set the contact_uri_parameters
to 'a=1;b=2',
then the contact will be modified to: Contact:
<sips:1111@any.invalid;transport=wss;a=1;b=2>;expires=180
(string)
Set custom SIP Contact parameters
for REGISTER and INVITE requests.
Default is empty.
Set to 'NULL' to clear.
Example:
If the original contact line looks like Contact:
<sips:1111@any.invalid;transport=wss>;expires=180
and you set the contact_parameters
to 'x=1;y=2',
then the contact will be modified to: Contact: <sips:1111@any.invalid;transport=wss>;x=1;y=2;expires=180
(number)
Specify whether the settings have to
be downloaded from a central config server.
Possible values:
0: no
1: auto (if not ip or domain was entered)
2: yes
(number)
Specify whether calls should fail or
succeed also without a microphone device.
-1: disable microphone recording
(call will use only playback from remote)
0: no (calls with be allowed even if
client doesn’t have any microphone audio device)
1: with warning (call will be
allowed but a warning message might be displayed for the user; sdp might be
fixed; call might be reloaded with audio only)
2: yes (calls might fail if user
doesn’t have a microphone device)
3: same as 1 but if incoming video
call then it will retry with audio only
Default is 1.
If your device doesn’t have
microphone or doesn’t need microphone recording at all, you should also set the
useaudiodevicerecord parameter to false. Old parameter name was checkmicrophone.
(number)
Use VoIP optimizations on windows
(WAVE_MAPPED_DEFAULT_COMMUNICATION_DEVICE). This will also enable audio ducking
(audio focus: auto lowering the volume for other processes while the webphone
is in call).
0: No
1: Yes
2: Force
Default value is 1.
Set to 0 if you encounter audio
volume issues, especially for multi-calls.
(number)
Check if audio device is muted or
volume settings are too low (and un-mute and/or increase volume if necessary).
0: no
1: at first run
2: always
Default value is 1
(number)
Enable background call listener.
If the WebRTC engine is used, this
means push notifications.
If you are using the NS engine on
Windows, your webpage can be started automatically on incoming calls if you set
this parameter to true.
When background calls is turned on,
the NS engine will listen continuously for incoming call and chat notifications
and will launch your website with the incoming session details if your page is
not already started by the user. This will enable incoming SIP calls even if
the browser is closed.
Possible values:
-1: auto
0: disable all incoming calls
1: enable incoming calls (while app
is running; no background listener)
2: enable also background calls
(WebRTC push or NS engine or android service)
Default is -1.
Note:
·
This has nothing
to do with the HTML5 notification support which can be configured with the incomingcallpopup parameter.
·
In case if you
need only NS engine background calls but not push notifications, then you might
set the enablepush parameter to 0 (possible values: -1: auto, 0: no, 1: yes).
·
The old
parameter was named backgroundcalls and it
is still supported as-is
Here you can read more details about
VoIP push notifications.
(number)
Transport protocol for the SIP
signaling.
-1: Auto detect
0: UDP (User Datagram Protocol. The
most commonly used transport for SIP)
1: TCP (signaling via TCP. RTP will
remain on UDP)
2: TLS (SIPS encrypted signaling)
3: HTTP tunneling (both signaling
and media. Supported only by mizu server or mizu tunnel)
4: HTTP proxy connect (requires
tunnel gateway or server)
5: Auto tunnel (automatic failover
from UDP to HTTP as needed if tunnel gateway or server is used)
Default is -1.
TLS related notes:
o To encrypt also the media, set the mediaencryption parameter to 2.
o When using TLS, you might need to
change the port in the serveraddress parameter (from the default 5060) to 5061.
For example: serveraddress: ‘yourdomain.com:5061’)
o WebRTC always uses full encryption.
When using WebRTC this parameter will mean the SIP transport protocol to be
used with your server as for WebRTC itself the transport is controlled by the
browser: http/https, websocket/secure websocket (ws/wss) and always encrypted
media (DTLS/SRTP).
(String)
Specify local IP address to be used.
This should be used only on devices
with multiple ethernet interface to force the specified IP.
Default is empty (autodetect)
Note: This setting is not applicable
for WebRTC (In case of WebRTC this is handled entirely by the browser internal
WebRTC stack)
(number)
Specify local SIP signaling port to
use.
Default is 0 (a stable port which is
selected randomly at the first usage)
Note: This is not the port of your
server where the messages should be sent. This is the local port of the
signaling socket (Usually UDP if you don’t explicitly set the transport to TCP)
Note: This setting is not applicable
for WebRTC (In case of WebRTC this is handled entirely by the browser internal
WebRTC stack)
(number)
Specify local RTP port base.
Default is 0 (which means
signalingport + 2)
Note: If not specified, then VoIP
engine will choose signalingport + 2 which is then remembered at the first
successful call and reused next time (stable rtp port). If there are multiple
simultaneous calls then it will choose the next even number.
Note: This setting
is not applicable for WebRTC (In case of WebRTC this is handled entirely by the
browser internal WebRTC stack)
(number)
NAT keep-alive packet send interval in
milliseconds.
Set to 0 to disable.
Default value is 28000 (28 sec)
(number)
Keep-alive interval for the WebRTC
websocket in milliseconds.
Set to 0 to disable.
Default value is 30000 (30 sec)
(boolean)
Send rtp even if muted (zeroed
packets)
Set to true only if your server is
malfunctioning when no RTP is received.
Default value is false.
(number)
Media encryption method
-1: auto guess
0: not encrypted
1: auto (will encrypt if initiated
by other party)
2: SRTP
Default is -1 which auto set to 1 if TLS transport is used, otherwise
will use 0/not encrypted
Note:
o With SRTP it is recommended to also
set the signaling transport to TLS.
o This parameter will not have effect
with the WebRTC engine since WebRTC calls are always secured using DTLS/SRTP
encryption for the media streams.
(number)
DTMF send method
0=disabled
1=SIP INFO method (out-of-band in SIP
signaling INFO messages)
2=auto (auto guess from peer advertised
capabilities)
3=INFO + NTE (not
recommended)
4=NTE (Named Telephone Events as
specified in RFC 2833 and RFC 4733)
5=In-Band (DTMF audio tones in the RTP
stream)
6=INFO + InBand (not
recommended)
Default is 2.
Note:
o When more than one method is used
(dtmfmode 3 or 6), the receiver might receive duplicated dtmf digits
o Received DTMF are recognized by
default in both INFO or RFC2833/ RFC4733
formats (no In-Band DTMF processing)
o DTMF messages can be sent from the
existing skin templates or using the dtmf API. Incoming dtmf messages are displayed
automatically on skins or can be cached with the onDTMF callback.
o
DTMF messages can be
also sent by adding it to the called number after a comma. For example if you
make a call to 123,456 then it will call 123 and then it will send dtmf 456
once the call is connected.
o If DTMF doesn’t work by default with
Asterisk, then we recommend to set the dtmfmode=info
configuration for the extensions used by the webphone
o WebRTC doesn’t support InBand DTMF
o If you are using the mizu WebRTC-SIP
gateway, you can set dtmf type for both inbound and outbound globally with the fs_dtmf_type_intern and fs_dtmf_type_extern
server side settings and also per user with the inbounddtmf
and outbounddtmf webphone parameters. The
out-bound is also handled automatically after the dtmfmode
setting (defaults to SIP info) and for in-bound both info and rfc2833 are
accepted by default.
o If gateway side WebRTC DTMF conversion
is required, you might also set the use_fast_ice
parameter to -1.
(number)
Specify whether the webphone should
generate local DTMF tone when DTMF is sent.
0=no
1=if one digit
2=always (also when multiple digits
are sent at once)
Default is 1.
(number)
Start to send media when session
progress is received.
0: no
1: reserved
2: auto (will early open audio if
wideband is enabled to check if supported)
3: just early open the audio
4: null packets only when sdp
received (NS only)
5: yes when sdp received
6: always forced yes
Default is 2.
(string)
Set your preferred audio codec. Will
accept one of the followings: pcmu,
pcma, g.711 (for both PCMU and PCMA), g.729, gsm, ilbc, speex, speexwb,
speexuwb, opus, opusnb, opuswb, opusuwb, opusswb
Default is empty which means the
built-in optimal prioritization.
By default the
engine will present the codec list optimized regarding the circumstances (the
combination of the followings):
·
available
client codec set (not all engines supports all codecs)
·
server
codec list (depending on your server, peer device or carrier)
·
internal/external
call: for IP to IP calls will prioritize wideband codecs if possible, while for
outbound calls usually G.729 will be selected if available
·
network
quality (bandwidth, delay, packet-loss, jitter): for example iLBC is more
tolerant to network problems if supported
·
device
CPU: some old mobile devices might not be able to handle high-complexity
codec’s such as opus or G.729. G711 and GSM has low computational costs
You can also
fine-tune the codec settings with the use_xxx settings where xxx is the codec
name as described in JVoIP documentation.
(string)
List of allowed audio codec’s
separated by comma.
By default the webphone will
automatically choose the best codec depending on available codec’s,
circumstances (network/device) and peer capabilities.
Set this parameter only if you have
some special requirements such as forcing a specific codec, regardless of the
circumstances.
Example: Opus,G.729,PCMU
(This will disable Speex, GSM, iLBC, GSM and PCMA).
Default: empty (which means auto
detection and negotiation)
Recommended value: leave it empty
Under normal circumstances, the
following is the built-in codec priority:
I.
Wideband Speex
and Opus (These are set with top priority as they have the best quality. Likely
used for VoIP to VoIP calls if the peer also has support for wideband)
II.
G.729 (Usually
the preferred codec for VoIP trunks used for mobile/landline calls because it’s
excellent compression/quality ratio for narrowband)
III.
iLBC, GSM (If
G.729 is not supported then these are good alternatives. iLBC has better
characteristics and GSM is better supported by legacy hardware)
IV.
G.711: PCMU and
PCMA (Requires more bandwidth, but has the best narrowband quality. Preferred
from WebRTC if Opus is not supported as these are present in almost any WebRTC
and SIP endpoints and servers)
With the NS and Java engines you can
also use the use codecname settings to disable/enable codec. Possible values:
0=never,1=don’t offer,2=yes with low priority,3=yes with high priority. For
example to disable all codec except PCMU you can use the following settings:
use_pcmu: 3, use_pcma: 0, use_g729: 0,
use_gsm: 0, use_speex: 0, use_speexwb: 0, use_speexuwb: 0, use_opusnb: 0,
use_opuswb: 0, use_opusuwb: 0, use_opusswb: 0, use_ilbc: 0,
alwaysallowlowcodec: 0
(string)
List of allowed video codec’s
separated by comma.
You might use this parameter to
exclude some codec from the offer list.
For example if you don’t wish to use
VP8, then set this to: “H264, H263”
Default: empty (which means auto
detection and negotiation)
More details here.
(string)
Set preferred video codec.
(number)
Enable/disable video.
-1: auto (default)
0: disable
1: enable
2: force always
More details about video
calls can be found here.
(number)
Max bandwidth for audio in kbits.
It will be sent also with SDP “b:AS”
attribute.
Default is 0 which means auto
negotiated via RTCP and congestion control.
(number)
Max bandwidth for video in kbits for
WebRTC video.
It will be sent also with SDP “b:AS”
attribute.
Default is 0 which means auto
negotiated via RTCP and congestion control.
(number)
You can suggest the size of the
video (in pixels) with the following parameters:
·
video_width
·
video_height
·
video_min_width
(WebRTC only)
·
video_min_height
(WebRTC only)
·
video_max_width
(WebRTC only)
·
video_max_height
(WebRTC only)
You might set all of these to 0 to
not set any constrains. Otherwise some default values might be applied.
(string)
Will set the facingMode WebRTC video
parameter:
Possible parameters:
·
"no":
will not set the facingMode at all (default)
·
"user":
The video source is facing toward the user; this includes, for example, the
front-facing camera on a smartphone.
·
"environment":
The video source is facing away from the user, thereby viewing their
environment. This is the back camera on a smartphone.
·
"left":
The video source is facing toward the user but to their left, such as a camera
aimed toward the user but over their left shoulder.
·
"right":
The video source is facing toward the user but to their right, such as a camera
aimed toward the user but over their right shoulder.
(number)
Enable/disable screen sharing:
0=No (default)
1=Auto (if supported by the
platform)
2=Yes (always force)
Default is: 1
Note:
Softphone skin users: If the
screensharing is set, a screen share button will appear on the softphone user
interface.
Enable extension:
o
Screen sharing was
a long term experimental feature in WebRTC standards and you might need a
browser extension to enable it.
o
You might also
need the followings:
o
Chrome: start the
browser with --enable-usermedia-screen-capturing flag
o
Firefox: in the
config create a media.getusermedia.screensharing.enabled key and set its
value to true and in media.getusermedia.screensharing.allowed_domains append
the IP address of your server
The latest webphone will try to
resolve screensharing without the need for any extensions in latest browsers.
(number)
Number of
payloads in one UDP packet (frames per packet). This will directly influence
RTP packet time (packetization interval) and packet size as shown here.
o By default it is set to 0 which means 2 frames for
G729 and 1 frame for all other codec.
This usually means 20 msec rtp packetization interval
for all codec’s and it is the most optimal setting, compatible with all
SIP/media stack implementations.
o In case if you wish to minimize delay, then you might
set the codecframecount to 1. This usually will result in 10 msec packetization
interval and will increase the required bandwidth by 40% due to high
header/data ratio.
o In case if you wish to minimize bandwidth, then you
might set the codecframecount to 4.
Note: with the WebRTC engine the codec
frame count is controlled by the browser WebRTC media stack and can’t be
changed. Usually it will be 20 msec frame time.
(number)
Specify how to handle conference,
especially for the WebRTC engine as other engines has built-in local RTP mixer.
0: disabled
1: auto
2: native only with local rtp mixer
(on WebRTC will force the NS or java engine)
3: server side conference mixing
controlled by DTMF
4: 3-way SIP conference
5: conference rooms via SIP MESSAGE
and REFER
6: conference rooms via SIP MESSAGE
7: conference rooms via SIP REFER
Default is 1.
Old parameter name was conferenceroom, which is
deprecated now.
For server side DTMF conference, you should also set
the use_fast_ice parameter to -1.
For more details see here.
(boolean)
Enable/disable packet loss concealment
Default is true (enabled)
(number)
Enable/disable voice activity
detection.
0: auto
1: no
2: yes for player (will help the
jitter)
3: yes for recorder
4: yes for both
Default is 2.
Notes:
-This parameter is supported only by
the NS and Java engines (not for WebRTC. For WebRTC you might use the
getrtcpeerconnection API as described here)
-The vad parameter is automatically set
to 4 by default if the aec2 algorithm is used.
-If you wish to use VAD related
statistics in your application, you might have to also set the “vadstat”
parameter after your needs. Possible values: 0=no,1=auto (default),2=detect no
mic audio,3=send statistics. See the VAD notification for more details.
-If you want to disable audio related
notifications for the NS and Java engines (microphone warning on no signal
detected) then set the “enablenomicvoicewarning” parameter to 0
(number)
Enable/disable acoustic echo
cancellation
0=no
1=yes except if headset is guessed
2=yes if supported
3=forced yes even if not supported
(might result in unexpected errors)
Default is 1.
(number)
Secondary AEC algorithm.
0=no
1=auto
2=yes
3: yes with extra (this might be too
much under normal circumstances)
Default is 1
Note: for maximum echo cancellation you can set the aec to 1,2 or 3 and
aec2 to 2 or 3.
(number)
Automatic gain control.
0=Disabled
1=For recording only
2=Both for playback and recording
3=Guess
Default value is 3
(number)
Enable/disable silence suppression
Usually not recommended unless your
bandwidth is really bad and expensive.
-1=auto
0=no (disabled)
1=yes
Default is -1 (which means no,
except mobile devices with low bandwidth)
(number)
Noise suppression.
0=Disabled
1=For recording only
2=Both for playback and recording
3=Auto guess
Default value is 3
(number)
Although the jitter size is
calculated dynamically, you can modify its behavior with this setting.
0=no jitter,1=extra
small,2=small,3=normal,4=big,5=extra big,6=max
Default is 3
(number)
Enable/disable presence.
Possible values:
-1: auto
0: disable presence
1: auto (if presence capabilities
detected)
2: always enable / force
Default is 1.
More details here.
(string)
List of users separated by comma to
request presence state from (the webphone will SUBSCRIBE to their presence
state and will accept NOTIFY reports).
You can also use the checkpresence() API for this.
(number)
Enable/disable BLF (busy lamp
field).
Possible values:
0:
disable BLF
1:
auto (from here it will auto switch to 0 or 2 regarding the circumstances
–whether BLF was initiated and succeed/failed)
2:
enable BLF
3:
force always (if you set to 3 then it can’t be switched off later and will use
BLF even after failure)
Default is 1.
Note: If BLF is an important feature for you, then we
recommend the usage of the NS or Java engines as this is unreliable with WebRTC
(set the enginepriority_ns and enginepriority_java to 4)
More details here.
(string)
List of users separated by comma to
request call state from (the webphone will SUBSCRIBE to their call state and
will accept NOTIFY reports).
You can also use the checkblf() API for this.
(number)
Specify the minimum accepted NS
engine version.
This is applicable only if the NS
engine is used and the webphone will ask the user to upgrade if the installed
NS plugin version is lower than this number (one click installer).
By default this is handled
automatically by the webphone and you should change it only if you need to
enforce a specific NS engine version for some reason.
Special values:
-2: disable asking for upgrades
regardless of the NS engine version
-3: completely disable asking for
all kind of ns engine install and upgrades
Default value: depends on the
webphone version
Note:
o The NS service plugin version for v.3.6.22061 engine
executable which was shipped with webphone v.3.6 is 55 (so you might set the “minserviceversion” setting to 55 to force the
latest version for all users)
o Upgrades for very old (outdated/incompatible) NS
engines are handled automatically by the webphone (with a reasonable default
“minserviceversion” settings in new webphone versions)
o Never set this to a higher value then the latest NS
plugin version (will result in continuously asking to upgrade)
o (Developer info: this value is loaded from the NS
engine MAPPVERSION define)
More details about NS engine
upgrades can be found here
(number)
Set how/when to upgrade the NS
engine.
-1: never (not recommended. Use the
0 option instead which might trigger an upgrade only on user interaction or if
there are no other options)
0: delayed background install only
(the new version will be downloaded and applied silently in the background with
no user interaction)
1: background or ask for user
(default behavior to handle the upgrade. Might be delayed especially if the
enduser doesn’t actively using the NS engine)
2: immediate install (will ask the
enduser immediately to download and install new versions)
Default: 1
Note: To completely disable all NS engine upgrades
(which is not recommended), you should set the nsupgrademode to 0 or -1 and the
autoupgrade to 6.
(string)
Use this setting for multi-account
registration.
You can specify multiple SIP accounts
in the following format:
IP,usr,pwd,t,proxy,realm;IP2,usr2,pwd2,t2,proxy2,realm2;
IP3,usr3,pwd3,t3,proxy3,realm3;
Account parameters:
·
IP: is the SIP server IP or
domain name
·
usr: is the SIP username
·
pwd: is the SIP password
·
t: is the register timeout in
seconds (optional)
·
proxy: SIP proxy (optional)
·
realm: SIP realm (optional)
·
authusr: auth (optional. Use only
if separate extension id and authorization username have to be used)
Most of the parameters are optional.
The parameters have to be separated by
comma (,) and the accounts have to be separated by semicolon (;).
All have to be passed in a single line
which should look like this: server,usr,pwd,ival;server2,usr2,pwd2,ival2;
Example:
sip1.mydomain,com,1111,xxx,300;sip2.mydomain.com,2222,xxx;
For more details read here.
(number)
Specify whether the webphone stack
should be started automatically on page load.
Possible values:
0: no (webphone will not start
automatically and you might need to call the start() API)
1: yes (webphone will start once
loaded if previous session was not failed)
2: always (webphone will always auto
start, regardless of previous success)
Default is 1.
If set to 0 or 1, then the start()
method needs to be called manually in order for the webphone to start. Also the
webphone will be started automatically on some other method calls such as
register() or call().
You might set this parameter to 0 to
prevent the auto initialization of the webphone, so you might delay the start()
until actually the user wish to interact with your phone UI (such as pushing
your click to call button).
Related
parameters: register
(auto register after start), appengine_startat (native engine launch),
startsipstack (NS engine specific), autologin (softphone skin specific)
forcereregister
(number)
Specify whether you wish to
disable/force reregistrations.
Please note that this is not about the
normal SIP re-registrations enforced by the expires interval (That is handled
automatically regardless of this settings).
This setting is considered when the sip
stack unregisters unexpectedly due to error response, no response, no network
or other reasons.
Possible values:
0: never auto reregister
1: try auto reregister if it was
already registered successfully before
2: always force reregister regardless
of the error (for example this will attempt to reregister even if user supplied
wrong username/password and server rejected the registration because of the
wrong credentials)
Default value is 1.
(boolean)
Set to false to prevent unregister
messages to be sent (for example to prevent unregister on web page reload).
Default is true.
(number)
Set to 1 to unregister all endpoints
for the users, not only the current one.
Will send Contact: * with the
unregister requests (REGISTER with Expires: 0).
Default is 0.
(number)
Unregister on idle (seconds).
If set to a positive value then the
webphone will automatically unregister when the user doesn’t user the browser
anymore for the specified seconds (no click, mouse move, etc on the browser
window).
The webphone will automatically
re-register again on user activity.
If you set it to 1 then it will be
treated specially by the NS engine only, unregistering immediately on idle. If
you wish to check the browser activity instead, then you should set it to 2 or
higher.
Default is 0.
(number)
Specify what type of web storage should
the webphone use.
Possible values:
-1=Auto(default)
0=None (no persistent storage)
1=IndexedDB
2=localStorage
3=WebSQL
The webphone might need to store various
things for proper functionality. For example: remember old user settings so the
user don’t have to type it again, remember old decisions (for example the VoIP
engine to use) so it will not spend time next time to lookup or to remember if
certain notifications was already showed for the user.
It is highly recommended to keep this
value at -1 (auto) as each browser has different capabilities which is handled
automatically if the preferred_storage is -1.
Note:
o
It will use other storage method,
if the preferred one is not supported by the browser.
o
This parameter can be set in the webphone_config.js only and not passed via the setparameter() API.
o
Storage can also failback to cookie
(only for the most important settings).
This can be enabled/disabled with the storagecookiefailback
parameter: 0 means no,1 means yes (default 1)
(boolean)
Set to true to clear all previously
stored or cached settings on startup.
This will reset all settings at
every start. You might use the configversion parameter instead if you wish to
reset only once (for example when you made some major changes).
Warning: this will forget all settings, even those that should be
remembered between sessions, such as “Have we already asked X from the
enduser?”. To deal with different settings we recommend using the profiles instead or just set unneeded settings to NULL.
More details can be found here.
Default is false.
(number)
Set to a positive value if you wish
to reset the config (clear old cached config) on webphone start on
configversion change.
This will reset the settings only
once (not at every startup).
If already set and you wish to reset
the settings again, then just increment the number.
Warning: this will forget all settings, even those that should be
remembered between sessions, such as “Have we already asked X from the
enduser?”. To deal with different settings we recommend using the profiles instead or just set unneeded settings to NULL.
More details can be found here.
Default is false.
(string)
By default all settings are
remembered by the webphone depending on your html document full URI (full
path).
However if you specify a value for
this profile parameter, then the settings will be stored in a storage named
root path + profile name.
For example if you deploy a webphone
to https://domain.com/path1 and a separate webphone to https://domain.com/path2
then the settings of these two webphones will be stored separately.
If you set the profile parameter to
“myprofile1” for both webphones, then they will use the same settings storage
(at domain.com_myprofile1).
You can also switch the settings
with this parameter. For example if your webphone is hosted at
https://domain.com/pathX then you might create two separate profile. Sometime
you might set the profile to “profileA” and sometime to “profileB”. This way
you can use the webphone with unrelated settings and you can be sure that the
settings will never mismatch.
Default value is empty (which means
settings bound to the webphone path or as specified by the usepathinfilenames
parameter).
(number)
Specify where to save the internal settings
and cache.
0: don't use any path
1: bind settings just to domain
2: bind settings to whole path
3: just path without domain
(default)
Note: this parameter can be set only
in the webphone_config.js and can’t be changed by the API at runtime.
Among the mentioned ice/turn/stun
related settings, you can now specify the following additional webrtc options
for the peer connection object:
·
bundlePolicy
·
iceCandidatePoolSize
·
iceTransportPolicy
·
rtcpMuxPolicy.
More details can be found here.
(number)
Trace/debug level. Values from 1 to
5.
Log level 5
means a full log including SIP signaling. Higher log levels should be avoided,
because they can slow down the softphone.
Loglevel above 9 is meant only for Mizutech developers and might
slow down the webphone (includes also RTP packets).
Do not set to 0 because that will disable also the important
notifications presented for the users.
Recommended values:
·
1: minimal logs for production
·
5: detailed logs for tests
More details about logs can be found
here.
There is also a maxloglevel parameter which you can use to prevent
users to set the log level above this predefined value.
By default the demo and trial versions might ship with
loglevel 5 and the licensed versions with loglevel 1 (which you can overwrite
with this parameter).
(boolean)
Specify whether to send logs to
console.
true: will output all logs to console
(default)
false: will output only level 1
(important events also displayed for the user)
The amount of logs depends on the
“loglevel” parameter.
Default is: true
NS and Java extra settings
With the NS and Java engines you can
also use any parameters supported by the Mizu JVoIP SDK as listed in the JVoIP documentation.
(Unrecognized parameters will be
skipped if the WebRTC engine is used)
Call divert and
other settings
These parameters are used for call
auto-answer, forward, transfer, voicemail, number rewrite and similar tasks:
(string)
The webphone can initiate call on
startup if this is set. It can be used to implement click to call or similar
functionality.
Can be any phone number, username,
extension number or full SIP URI acceptable by your VoIP server.
Default value is empty.
(number)
Useful for click-to-call to specify
what to do if you pass the “callto” parameter
0: Nothing (do nothing,
just preset the destination number; the user will have to initiate the
call/chat)
1: call (default. Will auto start the call to “callto”
–auto-call)
2: chat (will show the chat user interface presenting a chat
session with “callto”)
3: video call (will auto start a vide call)
Default is 0.
Note:
·
You can achieve
the same (and more flexible) behavior also via the API. For example just
initiate a call (by using the Call function) once the webphone is registered.
·
Some more advanced
SIP settings can be found in the “Engine related settings” below (such as
dtmfmode, transport or codec).
(string)
Specify the voicemail number (which the
user can call to hear its own voicemails) if any.
Most PBX servers will automatically
send the voicemail access number so usually this is detected automatically.
Default value is empty (auto-detect).
(number)
Normalize called telephone numbers.
If the dialed number looks like a
phone number (at least 5 number digits and no a-z, A-Z or @ characters and
length between 5 and 20) then will drop all special characters leaving only
valid digits (numbers, *, # and + at the beginning).
Possible values:
-1: auto (usually defaults to 1 yes, except if our username also contains
special characters)
0: no, don’t normalize
1: yes, normalize (default)
Default is -1
(string)
Add any prefix for the called
numbers.
Default is empty.
(string)
Called number prefix rewrite.
In case if you need to rewrite
numbers after your dial plan on the client side, you can use the numpxrewrite
parameter (although these kind of number rewrite are usually done after server
side dial plan):
You can set multiple rules separated
by semicolon.
Each rule has 4 parameters,
separated by comma: prefix to rewrite, rewrite to, min length, max length
For example:
‘74,004074,8,10;+,001,7,14;',
This will rewrite the 74
prefix in all numbers to 004074 if the number length is between 8 and 10.
Also it will rewrite the
+ prefix in all numbers to 001 if the number length is between 7 and 14.
Note: this parameter is same with
numrewriterules or the old filters parameter
(string)
Block incoming communication (call,
chat and others) from these users. (username/numbers/extensions separated by
comma).
Default value is empty.
(string)
Specify a number where incoming
calls should be forwarded when the user is already in a call. (Otherwise the
new call alert will be displayed for the user or a message will be sent on the
JS API)
Default is empty.
(string)
Forward incoming calls to this number
if not accepted or rejected within 15 seconds. You can modify this default 15
second timeout with the callforwardonnoanswertimeout
setting.
Default is empty.
(string)
Specify a number where ALL incoming
calls should be forwarded.
Default is empty.
(string)
Specify a number where ALL incoming
calls should be transferred to.
This might be used if your server
doesn’t support call forward (302 answers) otherwise better to set this on
server side because the call will not reach the webphone when it is
offline/closed, so no chance for it to forward the call.
Default is empty.
(number)
Set to ignore all incoming calls.
0: don’t ignore
1: silently ignore
2: reject
Default value is 0.
(boolean)
Set to true to automatically accept
all incoming calls (auto answer / auto connect).
Default value is false.
Note:
You can also auto-answer calls by using the accept API function.
The calls are also auto accepted if the received
INVITE contains the “x-p-auto-answer: normal"
or "x-answer-mode: auto” SIP header and
the enableautoaccept parameter is set to 2.
These are useful if only certain calls have to be auto
accepted and you wish to control which one from your JS code or from your SIP
server side.
With the WebRTC engine some user interaction (such as
a button click) might be required before the webphone will be capable to auto
answer incoming calls as new browser versions doesn’t allow auto-play without
user interaction.
(number)
Specify if to enable auto-answer
suggestions from peers for the incoming calls.
Possible values:
0: never
1: enable only if the autoacceptheader is set and it has a match in the
incoming call INVITE message
2: enable also for server-side
initiated auto answer (if headers such as Call-Info,
Alert-Info, Answer-Mode
or Auto-Answer are received with the
incoming INVITE)
3: force auto answer: auto connect all
incoming calls (works the same way like autoaccept
set to true)
Default is 1.
(number)
Specify whether to auto accept
incoming calls when the user clicks to enable device sharing for WebRTC (the
audio device permission browser popup) on media permission accepted.
Possible values:
0: no (Do nothing. The user will
have to click the “Accept” button to accept the incoming call or you must call
the accept() API)
1: auto (guess when to auto accept)
2: always (Always accept webrtc call
on browser share device click)
Default is 1.
(number)
Will play a short sound on incoming
calls.
0: No
1: Yes
Default value is 0
Note: this is not the ringtone.
(number)
Will play a short sound when calls
are connected
0: Disabled
1: For auto accepted incoming calls
2: For incoming calls
3: For outgoing calls
4: For all calls
Default value is 0
(number)
Retry the call on failure or no
response.
0: no
1: yes
Default value is 1.
(boolean)
Set to true to automatically reject
(disconnect) incoming call if a call is already in progress.
Default value is false.
(number)
Set to 1 to auto-redial on 301/302
call forward.
Set to 0 to disable auto call forward.
Default value is 1.
(number)
Specify how the call hold function
should work:
-2=no (will ignore hold requests)
-1=auto (defaults to 2)
0=no
1=not used
2=hold (standard hold by sending
“a=sendonly”)
3=other party hold (will send “a=recvonly”)
4=both in hold (will send “a=inactive”)
Default is -1
(number)
Default mute direction:
0: both
1: mute out (speakers)
2: mute in (microphone)
3: both
4: both
5: disable mute
Default: 0 or 2
(number)
Auto Mute/Hold all call legs on
conference calls.
0=no
1=yes
Default is 0.
(number)
Specify if other lines will be muted
on new call.
0=no (default)
1=on incoming call
2=on outgoing call
3=on incoming and outgoing calls
4= on line change (with setline or
with other line button click if you are using the softphone user interface)
5=on outgoing call and on line
change (like 2+4)
6=on any call and on line change
(like 3+4)
Default is 0
(number)
Specify if other lines will be put
on hold on new call.
0=no (default)
1=on incoming call
2=on outgoing call
3=on incoming and outgoing calls
4=on line change (with setline or
with other line button click if you are using the softphone user interface)
5=on outgoing call and on line
change (like 2+4)
6=on any call and on line change
(like 3+4)
Default is 0
(number)
Specify hold-mute workaround for the
WebRTC engine with multiple simultaneous calls.
With the WebRTC engine the webphone might
use mute instead of hold with multiple lines as a workaround for some
multi-line hold related WebRTC issues in some browsers.
-1: always use mute instead of hold
(even if there are no multiple calls)
0: use mute instead of hold with
multiple calls
1: usually use mute with multiple
calls
2: use mute instead only in some
cases for multi-line calls
3: never use mute instead of hold
Default is 2
(string)
Audio device name for recording
(microphone). Set to a valid device name or “Default” which would select the
system default audio device.
Note: this is usually set at run-time
from the API or from an audio device select control presented to the users
(already implemented by the softphone skin). If not set, then the webphone will
use the OS default recording device.
(string)
Audio device name for playback
(speaker). Set to a valid device name or “Default” which would select the
system default audio device.
Note: this is usually set at run-time
from the API or from an audio device select control presented to the users
(already implemented by the softphone skin). If not set, then the webphone will
use the OS default playback device.
(string)
Audio device name for ringtone. Set
to a valid device name or “Default” which would select the system default audio
device. You can also set it to “All” to have the ringtone played on all
devices.
Note: this is usually set at run-time
from the API or from an audio device select control presented to the users
(already implemented by the softphone skin). If not set, then the webphone will
use the OS default playback device. Separate ringer device selection is not
available with the WebRTC engine.
(number)
Default microphone volume in percent
from 0 to 100. 0 means muted. 100 means maximum volume.
This is the audio input volume which
are going to be streamed to the other end.
Default is 50% (not changed)
Note:
·
The default
volume level is determined by the OS volume setting. The webphone volume
changes will be only relative to the OS settings
·
The result
volume level might be affected by the AGC if it is enabled.
·
Some browsers
doesn’t expose volume change functionality if you are using the WebRTC engine
(number)
Default speaker volume in percent
from 0 to 100. 0 means muted. 100 means maximum volume.
This is the audio output volume
heard by the local user from the incoming audio stream sent by the other party.
Default is 50% (not changed)
Note:
·
The default
volume level is determined by the OS volume setting. The webphone volume
changes will be only relative to the OS settings
·
The result
volume level might be affected by the AGC if it is enabled.
·
Some browsers
doesn’t expose volume change functionality if you are using the WebRTC engine
(number)
Default ringback volume in percent
from 0 to 100. 0 means muted. 100 means maximum volume, 0 is muted.
Default is 50% (not changed)
Note: the ring volume can’t be changed
for the WebRTC engine (use the OS volume settings)
(number)
Control the default playback device
on Android phones and tablets.
-2: ignore (don’t make any changes)
-1: auto guess (prefer loudspeaker
for video call, otherwise speakerphone)
0: default (most Android smartphones
will use the loudspeaker by default as the playback device)
1: switch to speakerphone before the
first call
2: switch to speakerphone after
first call
3: switch to speakerphone at start
Default: -1
Note:
You can also use the setloudspeaker API to change it at runtime.
There is no similar setting for iOS, because changing
an audio device requires "setSinkId()" which is not supported even by
the latest versions of Safari.
(number)
Specify transfer mode for native
SIP.
-1: default transfer type
0: call transfer is disabled
1: transfer immediately and
disconnect with the A user when the Transf button is pressed and the number
entered (unattended/blind transfer)
2: transfer the call only when the
second party is disconnected (attended transfer)
3: transfer the call when the VoIP
phone is disconnected from the second party (attended transfer)
4: transfer the call when any party
is disconnected except when the original caller was initiated the disconnect
(attended transfer)
5: transfer the call when the VoIP
phone is disconnected from the second party. Put the caller on hold during the
call transfer (standard attended transfer)
6: transfer the call immediately
with hold and watch for notifications (unattended transfer)
7: transfer with no hold and no
disconnect (simple unattended transfer)
8: transfer with conference (will put the
parties to conference on transfer; will mute or hold the old party by default)
Default is -1 (which is the same as
6 or 7)
Note:
·
Unattended means simple immediate
transfer (just a REFER message sent)
·
Attended transfer means that there
will be a consultation call first. The softphone skin has its own attended
transfer control options.
·
It is also possible to create an
attended transfer by initiating a simple call to the transfer target and on
hangup an unattended call-transfer (transfertype 1, 6 or 7)
·
If you have any incompatibility
issue, then set to 7 (unattended is the simplest way to transfer a call and all
sip server and device should support it correctly)
·
More details can
be found here
(number)
Specify if replace
should be used with transfer requests, so the old call (dialog) is not
disconnected but just replaced.
This way the transferee
and the transfer-target parties are not disconnected, just the other party is
changed at runtime.
The feature is
implemented by adding a Replaces= for the Contact header in the REFER request
as described in RFC 5589 and RFC 5359.
The transferee (the
party which receives the REFER transfer request) or the SIP server must be able
to handle replaces for this to work.
Possible values:
-1: auto (if
transfertype is -1 (default), 6 or 7; server/peer has replaces support; we are
connected with the transfer target)
0: no
1: yes
2: force (use replaces
even if peer doesn’t have replaces support or there is no session with the
target)
Default is -1
Note: some SIP servers doesn’t announce
replace capabilities ("replace" tag into the Supported or Require SIP
headers). In this can you will have to set the transfwithreplace parameter to
2.
(number)
Specify how to handle
incoming call transfer with replaces requests (How to handle the Replaces=
Contact tag in incoming REFER requests)
-1: auto (defaults to
1)
0: disable
1: standard (sending
the Replaces header in the new call INVITE request as described in RFC 3891)
2: in place (might be
useful with servers without replaces support; not supported by the WebRTC
engine)
Default is -1
(number)
If to treat session progress (183)
responses as ringing (180). This is useful because some servers never sends the
ringing message, only a session progress and might not start to send in-band
ringing (or some announcement). In this circumstances the webphone can generate
local ringback.
The following values are defined:
0: do nothing (no ringback on
session progress message)
Will not call
startRingbackTone() on 183 (only for 180)
1: change status to ring
2: start local ring if needed and be
ready to accept media (which is usually a ringtone or announcement and will
stop the locally generated ringback once media received)
Will call
startRingbackTone() on 180 and 183 but stop on early media receive.
3: start media receive and playback
(and media recording if the “earlymedia” parameter is set)
4: change status to ringing and
start media receive and playback (and media recording if the “earlymedia”
parameter is set to true)
5: play early ringback and don’t
stop even if incoming early media starts
Will call
startRingbackTone() on 180 and 183 and do NOT stop on early media receive.
Default value is 2.
*Note: on ringing status the web phone
is able to generate local ringback tone. However with the default settings this
locally generated ringtone playback is stopped immediately when media is
started to be received from the server (allowing the user to hear the server
ringback tone or announcements)
(number)
Maximum ring time allowed in
millisecond.
Default is 90000 (90 second)
You can also set separate ring
timeout for incoming and outgoing calls with the “ringtimeoutin” and
“ringtimeoutout” settings.
(number)
Maximum speech time allowed in
millisecond.
Default is 10800000 (3 hours)
(number)
RTP timeout in seconds to protect
again dead sessions.
Calls will be disconnected if no
media packet is sent and received for this interval.
You might increase the value if you
expect long call hold or one way audio periods.
Set to 0 to disable call cut off on
no media.
Default value is 300 (5 minute).
At the beginning of the calls, the
half of the mediatimeout value is applied (2.5 minute by default if there was
no incoming audio at all).
(string)
Voice record upload URL (FTP or
HTTP).
With this setting you can setup VoIP
call recording (voice recording).
Default value is empty (no voice
call recording).
If set then calls will be recorded
and uploaded to the specified ftp or http address in pcm/wave, gsm, mp3 or ogg
format.
Note: mp3 support is not included by
default in the NS engine to minimize the package size. Contact Mizutech to
include this in your build if you need mp3 recording also from the NS engine (build option voicerecformat=3;)
The files can be uploaded to
·
your FTP server
(any FTP server with specified user login credentials)
·
or to your HTTP
server using HTTP PUT or multipart/form-data POST (in this case you need a
server side script to save the uploaded data to file)
The following keywords can be used
in the file name as these will be replaced automatically at runtime to their
respective values:
·
DATETIME: will
be replaced to current date-time
·
DATE: will be
replaced to current date (year/month/day)
·
TIME: will be
replaced to current time (hour/min/sec)
·
CALLID: will be
replaced to sip call-id
·
USER: will be
replaced to local user name
·
CALLER: will be
replaced to caller party name (caller id)
·
CALLED: will be
replaced to callee party name
·
SERVER: the
domain or IP of the SIP server
·
COUNTER: an auto-increasing
number
If you set a HTTP URI, then the
following headers will be also set in the HTTP PUT or POST: X-type, X-filename,
X-user, X-caller, X-called, X-callid and X-server.
We recommend to use FTP first (or
try this first) as this is very easy to configure and doesn’t require any
server side script.
If you need unique file names then we recommend using
the SIP Cal-ID (CALLID keyword), so you can associate your call detail records
(CDR’s obtained from your VoIP server) with the recorded files. You can also
access the SIP Call-ID from the webphone in many ways: use the onCallStateChange
or onCdr callbacks or use the linetocallid function to get the call-id of a call.
FTP Example:
ftp://user01:pass1234@ftp.foo.com/voice_DATETIME_CALLER_CALLED
You can also suggest a particular
file format by appending its extension to the file name (for example .wav or
.mp3).
For example: ftp://user01:pass1234@ftp.foo.com/voice_DATETIME_CALLER_CALLED.wav
Since the username:password
is part of the URI here, no special characters are allowed in the file path
(don’t use ftp accounts with characters like @ ; ‘ “ / \ in the username or in
the password).
HTTP Example:
http://www.foo.com/myfilehandler.php/filename=callrecord_CALLID
You can also suggest a particular
file format by appending its extension to the file name (for example .wav or
.mp3).
For example: http://www.foo.com/myfilehandler.php?filename=callrecord_DATETIME_USER.wav
You can also set just a path,
without any URL query parameter, like this:
For example: http://www.foo.com/myfilehandler.php/rec_DATETIME_CALLID
Example HTTP POST header packet if
you set the url to “http://yourdomain.com/myapi/voicerecord/anyentry?filename=callrecord_DATE_CALLID.mp3”:
POST /myapi/voicerecord/anyentry?filename=callrecord_2024_04_04_xxx.mp3
HTTP/1.1
Host: yourdomain.com
User-Agent: webphone
Accept: */*
X-type: fileupload
X-filename:
callrecord_2024_04_04_xxx.mp3
X-user: local_username
X-caller: caller_party
X-called: called_party
X-callid: sip_callid
X-server:
your_sip_server_address
Content-Length: 18623
Expect: 100-continue
Content-Type:
multipart/form-data; boundary=------------------------fde9999399e1b8eb
--------------------------fde9999399e1b8eb
Content-Disposition:
form-data; name="file";
filename="callrecord_2024_04_04_xxx.mp3"
Content-Type:
application/octet-stream
.....
You will receive “file” as the form
name parameter and the name of the file as the form data “filename” parameter.
(So you will receive the file name
as both the “filename” form parameter and also in the X-filename HTTP header).
The content type can be
application/octet-stream, audio/x-wav, audio/mpeg, audio/x-gsm or audio/ogg.
(Regardless of the suggested file
name, you can save the files on your server with any name, this is your
choice).
A working example for PHP can be
downloaded from here.
More details about handling HTTP
file upload: C#, ASP.NET, PHP, PHP (2), NodeJS, Java.
More details about voice recording
can be found here.
Note:
·
You can also use the voicerecord API to turn on/off the voice recording at runtime (if
not all calls have to be recorded)
·
The voicerecord API should be
called before the call you wish to record as changing the recording state
during the calls might not be supported
·
With the NS or Java engine you can
also record to local file. For this, you need to set the voicerecording
parameter which has the following values defined: 0=no, 1=record to local file
system, 2=remote http/ftp only, 3=both local and remote
·
If you are using the WebRTC engine
with FTP voice file storage, avoid using special characters in the ftp
username/password
·
Ogg/vorbis format can be also used
with NS or Java engines (this is not supported by WebRTC)
·
With the NS and Java engines the
call recording is performed on the client side by the webphone. With the WebRTC
engine the call recording is performed on the gateway or server side (but the
voicerecupload parameter is still handled correctly, passing it to the server)
·
If you are using the NS engine
with built-in JVM then HTTPS upload might not work (old tiny version of the JVM
might not implement the latest TLS protocols). In this case you can still use
HTTP or FTP storage (not HTTPS) or notify Mizutech to build with a new full JVM
(will increase the size).
User
interface related settings
Most of these apply only to the
Softphone user interface which is shipped with the webphone to further
customize the web softphone user interface and behavior (Softphone.html)
(string)
Brand name of the softphone to be
displayed as the title and at various other places such as SIP headers such as
the User-Agent.
Default is empty.
Note: purchased webphones always comes with a
predefined brand name as you communicated to Mizutech. This brand must be a
short unique name, with no special characters. You can overwrite the default
with this setting if needed.
(string)
Your company name to be displayed in
the about box and various other places.
Default is empty.
(string)
Displayed on login page.
Can be text or an image name, ex:
"logo.png" (image must be stored in images/folder)
Default is empty.
Note: if you set a logo, then this
will be placed on the softphone skin (softphone.html), taking up some space of
its user interface.
The useloginpage might be also set
to 1 or 2 to show the logo.
Since the webphone is usually
embedded in webpages, you might consider to place logo on other places of your
website and not into the softphone skin itself as in this case it would just
take precious space inside the app.
Otherwise, you also have all the
html in your hand so you can edit the user interface as you wish, placing any
image at any location after your like.
(number)
You can easily change the skin of
the supplied user interfaces with this setting (softphone, click to call).
Possible values:
1.
Default
2.
Light
Blue
3.
Light
Green
4.
Light
Orange
5.
Light
Purple
6.
Dark
Red
7.
Yellow
8.
Blue
9.
Purple
10.
Turquoise
11.
Light
Skin
12. Green Orange
Default is 0.
More
details about design changes.
Set the language for the user
interface.
This is usually a two character
language code (for example en for English or
pt for Portuguese) or for specific
accents/countries you can use the long format such as en-US.
If this parameter is not set, then
by default the webphone will auto detect the browser language and will use it
if there is a good translation for that language. This behavior can be turned
off by setting the languageautodetect
parameter to 0 (will always default to
original/English in this case).
Before you preset any language, make
sure that the webphone has a good quality built-in translation for it.
Otherwise, you might need to add the
translation yourself or improve the existing translation.
See the details here.
(number)
User interface complexity level.
0=minimal
5=reduced
10=full (default)
15=more (for tech user)
You might set to 5 for novice users
or if only basic call features have to be used.
Default is 10.
(number)
This can be used to hide the server
address setting from the user if you already preconfigured the server address
in the webphone_config.js
(“serveraddress” config option), so the enduser have to type only their
username/password to use the softphone.
Possible values:
0: no (will hide the server input
setting for the endusers)
1: auto (default)
2: yes (will shot the server input
setting for the endusers)
(number)
Specify if to show proxy server
input on the softphone user interface login page.
Possible values:
0: no
1: if set
2: yes
Default is 1
(number)
Specify if to show the username
(caller id) input on the softphone user interface login page.
Possible values:
0: no
1: if set
2: yes
Default is 1
(number)
Specify how to handle if the user
type a full SIP URI as the username input.
Possible values:
0: always ignore (will ignore also
for the username; not recommended)
1: ignore for the sipusername (auth
username)
2: extract username only in basic
settings
3: config as serveraddress if
missing in basic settings
4: config as serveraddress if
missing
5: config as serveraddress always
6: config as proxyaddress always
Default is 3
(number)
Specify how to handle if the user
type a full SIP URI as the sipusername input.
-1: auto (keep it as-is but might
retry the auth with the user part only if rejected)
0: keep it as-is (the sip auth
username can have user@domain format)
1: remove the domain part and keep
only the SIP URI
Default is -1.
This parameter might be ignored if
the handleusernameuri is set to 0.
If you (your VoIP server) are using
sip auth username in user@domain format, then you might set this parameter to 0
(to avoid unneccessary auth retry with the default -1).
Otherwise (if you don't use
user@domain format for sip authnetication), then you might set it to 1 (to fix
the user@domain user input and keep only the user part for SIP auth).
Note: the old allowsipuriasusername
parameter was deprecated by this new one.
(number)
Whether to use a simplified login
page with username/password in the middle (instead of list style settings; old
haveloginpage).
Possible values:
-1: auto (will auto set to 1 if
featureset is Minimal, otherwise 0)
0: no
1: only at first login
2: always
Default is: -1
autologin
(number)
Specify when to skip the login page.
Possible values:
-1=Auto
0=No
1=Yes
Default is: -1
More details can be found here.
(number)
Specify if to hide the password
string on the softphone user interface (login page / settings).
Whether to use a simplified login
page with username/password in the middle (instead of list style settings; old
haveloginpage).
Possible values:
0: don’t hide
1: replace text element with *****
if the password is already set
2: use password input element if the
password is already set (instead of text)
3: always use password input element
(instead of text)
4: always use password input element
(instead of text) and disable password reveal if the password was already set
Default is 4.
Note: When set to 2 or 3, the password string can be
revealed by double-click.
(number)
Enable/disable password autocomplete
on the softphone user interface (login page / settings)
Possible values:
-1: don’t set any flag (use browser
default)
0: disable (off)
1: enable (on)
Default is -1
quick_access_list
(number)
Enable/disable recent important
contact list on the main page.
Possible values:
0: disable (show only the dial pad)
1: enable
Default is: 1
(number)
Specify text messaging mode
(IM/chat/SMS/API)
-1: auto guess or ask (default)
0: disable all
1: disable incoming messages and
auto guess outgoing mode
2: disable message sending and auto
guess incoming mode
3: API (if SMS API URI have been
defined)
4: reserved
5: VoIP SMS (will send the X-Sms:
yes SIP header. More details here)
6: VoIP IM/chat (SIP MESSAGE)
Note: the old haschat and chatsms parameters are
deprecated now but still supported
(number)
Define how to handle incoming chat
messages.
0: open/show chat window if not in
call
1: just set a notification
Default is 0.
(string)
Can be used to add call park and
call pickup (will be sent as DTMF for call park and user need to call to pickup
number to later reload the call from the same or other device).
If set, then it will be displayed on
the call page as an extra option.
(boolean)
Enable/disable the time counter
during ring-time.
(boolean)
Set to true to enable file transfer.
(string)
HTTP URI used for file transfer. By
default Mizutech service is used which is provided for free with the web
softphone.
(number)
Show notifications in phone
notification bar (usually on the top corner of your phone).
0:No
1:Yes (display missed call and
missed chat notifications)
Default is 1.
(boolean)
Always display volume controls when
in call.
Default is false.
Old/deprecated parameter name was
“hasvolume”.
(boolean)
Always display audio device when in
call.
Default is false.
Display video preview window on
video device select:
Possible values: 0 mean No
(default), 1 means Yes
When set to 1, then a video preview
will appear when you select a video device on the device form or via the
devicepopup() API. This preview window can be closed by the user or it will be
closed automatically after 10 seconds once the device form is closed.
(string)
Specify where to display the
information returned by scurl_displaypeerdetails.
It can be used display details about
the peers from your CRM such as full name, address or other details.
(Useful in call-centers and for
similar usage)
Possible values:
0: show on call page (instead of
contact picture)
1: on new page
div id: display on the specified DIV
element
(number)
Whether to (automatically) add new
called numbers to your contact list.
0:No
1:Ask
2:Yes (will not ask for a contact
name)
Default is 1.
(string)
Display custom popup for user once.
Default is empty.
(boolean)
Enable/disable hint popups.
Possible values:
true: show all toasts (default)
false: don't show toasts and popup
messages
(number)
Whether to display a popup about
incoming calls (uses the HTML5 notification API for WebRTC or native popup for
NS/Java).
Possible values:
0.
No
1.
Auto (show only
if browser window is not in foreground/focused)
2.
Yes
3.
Always force
from all engines
Default is 1.
Set to 0 to disable (in this case
make sure that you handle the incoming call alert from your HTML/JS if
required).
Set the callreceiver parameter to 2 to catch incoming
calls even when the webphone is not running.
Note: The old name of this parameter
name was hasincomingcallpopup and hasincomingcall
The incoming call HTML5 popup can be
optionally customized with the following parameters:
·
callnot_title
(string) – the title of the notification. By default this is the brand name of
the webphone.
·
callnot_body
(string) – the body text of the notification. By default this is: “Incoming
call from: PEERNAME”
·
callnot_icon
(string) – URL of the notification icon. By default this is:
“notification_icon.png” from “images” directory.
·
callnot_image
(string) – URL of the notification image. By default this is empty.
(number)
Specify when to ask for permissions
if HTML5 notifications are required:
-1: auto
0: never
1: when required
2: when required and on startup/call
if failed
3: on start and on call (always)
(number)
The call page will remain active
after successful call hangup for this amount of time in milliseconds, after
which it will close automatically.
Set to 0 to disable.
Default is 3000 (3 sec)
(number)
The call page will remain active
after failed call hangup for this amount of time in milliseconds, after which
it will close automatically.
Set to 0 to disable.
Default is 8000 (8 sec)
(string)
Header text displayed for users on
top of softphone windows.
Default is empty.
(string)
Footer text displayed for users on
the bottom of softphone windows.
Default is empty.
(string)
Version number displayed for users.
Default is empty (will load the
built-in version number)
(number)
This is to allow contact
synchronization between mobile and desktop.
-1=don't show
0=show Sync option in menu and
Contacts page (if no contacts available)
1=show in menu only
Default is 1
(string)
Set one or more contacts to be
displayed by default in the contact list.
Contact fields: name, number, email,
address, notes, website
Fields must be separated by comma
and contacts separated by semicolon:
Example: defcontacts:
'John Doe,12121;Jill Doe,231231,jill@g.com'
Note: Contacts can be added also at runtime using the addcontact API.
(string)
List of settings options and
features to be disabled or hidden.
To disable entire features, use the
upper case keywords such as CHAT,VIDEO,VOICEMAIL,CONFERENCE.
To disable settings, use
the setting label or name such as Audio device, Call forward.
Example: disableoptions:
'theme,email,Call forward,callforwardonbusy,callforwardonnoanswer,callforwardalways,VIDEO'
Other examples:
"chatsms,textmessaging,disablewbforpstn,audiorecorder,audioplayer,speakerphoneplayer,useroutingapi,callback_mode,transfertype,transfwithreplace,balance_uri,rating_uri,creditrequest,ratingrequest,p2p_uri,p2p,callback_uri,callback,sms_uri,sms, disablecontactmenu";
You can also disable
main pages:
PAGE_MAIN, PAGE_CONTACTS, PAGE_HISTORY, RECENTS
(string)
Custom parameters can be set in a
key-value pair list, separated by semicolon Ex: displayname=John;
Default is empty.
(number)
Specify allowed actions on the logs
page.
0: no options (users will still be
able to copy-paste the logs)
1: upload (default)
2: email launch (the email address
set by the “supportmail” parameter or support@mizu-voip.com if not set)
(strings)
The webphone GUI can load additional
information from your web server application or display some content from your
website internally in a WebView or frame. You can integrate the included
softphone user interface with your website and/or VoIP server HTTP API (if any)
by using the following parameters:
·
advertisement:
Advertisement URL,
displayed on bottom of the softphone windows.
·
supportmail: Company support email address.
·
supporturl: Company support URL.
·
newuser: New user registration http request
OR link (if API then suffix with star *)
·
forgotpasswordurl:
Will be displayed
on login page if set.
·
homepage: Company home page link.
·
accounturi: Company user account page link.
·
recharge: Recharge http request (pin code must
be sent) or link.
·
p2p: Phone to phone http request or link.
·
callback: Callback http request or link (For
example: *https://yourdomain.com/callback?user=USERNAME)
·
sms: SMS http request.
·
creditrequest:
Balance http
request, result displayed to user. (For example: *https://yourdomain.com/balance?user=USERNAME)
·
ratingrequest:
Rating http
request, result displayed for user on call page. (For example: *http://yourdomain.com/rating?destination=CALLEDNUMBER)
·
helpurl: Company help link.
·
licenseurl: License agreement link.
·
extramenuurl:
Link specifying
custom menu entry. Will be added to main page (dialpad) menu.
·
extramenutxt:
Title of custom
menu entry. Will be added to main page (dialpad) menu.
·
serveraddressbook_url:
address book URL or
API (details here)
Parameters can be treated as API
requests (specially interpreted) or links (to be opened in built-in
webview). For http API request the value must begin with asterisk character:
"*http://domain.com/...." For example if the "newuser" is a
link, then it will be opened in a browser page; if it's an API http request
(begins with *), then a form will be opened in the softphone with fields to be
completed.
o
The followings
are always treated as API request: creditrequest, ratingrequest
o
The followings
can be links OR API http requests: newuser, recharge, p2p, callback, sms
o
The rest will be
treated always as links (opened in built-in webview or separate browser tab)
You can also use keywords in these
settings strings which will be replaced automatically by the web softphone. The
following keywords are recognized:
o DEVICEID: unique identifier for the
client device or browser
o SESSIONID: session identifier
o USERNAME: sip account username.
preconfigured or entered by the user
o PASSWORD: sip account password
o CALLEDNUMBER: dialed number
o PEERNUM: other party phone number or
SIP uri
o PEERDETAILS: other party display
name and other available details
o DIRECTION: 1=outgoing call,
2=incoming call
o CALLBACKNR,PHONE1,PHONE2: reserved
o PINCODE: reserved. will be used in
some kind of requests such as recharge
o TEXT: such as chat message
o STATUS: status messages: onAppStateChange,
onRegStateChange, onCallStateChange, inChat, outChat
o MD5SIMPLE: md5 (pUser +
":" + pPassword)
o MD5NORMAL: md5 (pUser +
":" + pPassword+":"+randomSalt)
o MD5SALT: random salt
Example credit http request:
https://domain.com/balance/?user= USERNAME
(Where “USERNAME” will be
dynamically replaced with the currently logged in username)
Note: Ensure that you have proper authentication for
payable functions such as callback, p2p or sms. Some other functions can also
affect user privacy, such as creditrequest.
From security perspective the webphone
can be treated as any other regular SIP endpoint: make sure to not reveal the
password of your SIP accounts and your app will be secure.
Webphone parameters are safe by default
since they are used only in the user http session. This means that the enduser
can discover its own settings including the password, but other users
–including users for the same browser or middle-men such as the ISP- will not
be able to see the sensitive parameters if you are using secure http (HTTPS)
and don’t statically set a SIP account password in your HTML, which could be
discovered from your webpage source.
The only sensitive parameter is the SIP
account “password”! This is sent only as digest hash in signaling, but make
sure to never display or log from your code.
The easiest way to maintain maximum
security is to allow the endusers to type their SIP password as needed, instead
of hardcoding or provisioning.
You should not hardcode the password
into your website (It should not be found if you check the source of your
webpage in the browser. The only exception would be if you offer some free to
call service which is not routed to outside paid trunks/carriers). If the
password has to be preconfigured then load it via an ajax call or similar
method; just make sure to use HTTPS in this case because otherwise all the
communication is in clear text between the browser and your server if the page
is running on unsecure HTTP. Otherwise just let the endusers to enter their
password on a login/settings form and pass it to the webphone with the
setsipheader() API call.
If the password needs to be passed
dynamically then:
·
make sure to use HTTPS if it is
sent from the server (for example via an AJAX or other API request)
·
if you pass it from JavaScript,
then you might encrypt or obfuscate it with your preferred method
Please note that even if you pass the
password around in clear text, you are still protected if your page is in
secured (on HTTPS). Only the enduser might be able to found its own password
from the browser in this case, but this is usually not a problem since the
users should know their own password anyway (Or if somehow you don’t wish the
enduser to known its own password then you can implement your own custom
encryption or obfuscation in JavaScript)
There is no much reason to try to
obfuscate or hide other parameters.
For example the “serveraddress” can be
discovered anyway by analyzing the low level network traffic and this is
perfectly normal. Most of the other parameters are completely irrelevant. Some
sensitive information’s are also managed by the webphone (such as the user
contact list) however these are stored only locally in the browser secure web
storage or secure cookie by default (on HTTPS) and further encrypted or
obfuscated by the webphone.
The following methods can be used to
further secure the webphone usage:
·
set the loglevel to 1 (with
loglevel 5 the password might be written in the logs)
·
use strong passwords for all your
SIP extensions or trunks
·
don’t hardcode the password if
possible (let the users to enter it) or if you must hardcode it then use
encryption and/or obfuscation
·
restrict the account on the VoIP
server (for example if the webphone is used as a support access, then allow to
call only your support numbers and disable outbound calls)
·
set a maximum simultaneous call
limit and rate limiter for your SIP accounts
·
instead of preconfigured
parameters you can use the javascript VoIP api (setparameter)
·
use HTTPS (secure http / TLS)
·
encrypt/obfuscate the password in
JavaScript code if you wish to hide it even from its owner or if you need to
use a preconfigured account for your app
·
for parameter encoding (encryption/obfuscation) you can use XOR + base64 with your built-in
key (ask passphrase from Mizutech), prefixed with the “encrypted__3__” string
(you can verify your encryption with this tool
selecting XOR Base64 Encrypt)
·
you can quickly encrypt any
parameter using this link:
https://mnt.mizu-voip.com/mmexreqvitserverjrsktt/xwencode?wkey=YOURKEY&wstring=YOURSTRING&wversion=3
Replace YOURKEY with your webphone key provided by mizutech.
The key in the demo version is h39idbfqw7116ghh
Replace YOURSTRING with a parameter value (for example the password parameter).
URI encode if contains special characters such as spaces.
More details can be found here.
·
secure your VoIP server (account
limits, rate-limits, balance limits, fraud detection) and follow the VoIP
security best practices. For example here you
can find details about mizu VoIP server security.
You can use the webphone javascript SIP
library in multiple ways for many purposes:
·
create your own web dialer
·
add click to call functionality to
your webpage
·
add VoIP capability to your
existing web project or website
·
integrate with any CRM,
callcenter client or other projects
·
modify one of the existing
projects to achieve your goal (see the included softphone and click to call
examples) or create yours from scratch
·
and many others
The public JavaScript API can be found
in "webphone_api.js" file, under global javascript namespace
"webphone_api".
To be able to use the webphone as a
javascript VoIP library, just copy the webphone folder to your web project and
add the webphone_api.js to your page.
The API functions should not throw
exceptions and should not return null or undefined values (will return
empty/false/0/minus/'ERROR' values on failure, depending on the context).
In case if you have to manage multiple
simultaneous calls explicitly, then you might call the setline() API to specify
the line before the other API calls.
For example to mute a call on line 2
first set the line to 2 (webphone_api.setline(2);)
then call the mute function (webphone_api.mute();)
More details about multi line
management can be found here.
<head>
<!-- Include the
webphone_api.js to your webpage -->
<script src="webphone_api.js"></script>
</head>
<body>
<script>
//Wait until the webphone
is loaded, before calling any API functions
webphone_api.onAppStateChange (function (state)
{
if (state === 'loaded')
{
//Set parameters (Replace
upper case worlds with your settings)
webphone_api.setparameter('serveraddress',
SERVERADDRESS);
webphone_api.setparameter('username',
USERNAME);
webphone_api.setparameter('password',
PASSWORD);
webphone_api.setparameter(‘other’,
MYCUSTOMSETTING);
//See the “Parameters”
section below for more options
//Start the webphone
(optional but recommended)
webphone_api.start();
//Make a call (Usually
initiated by user action, such as click on a click to call button. Number can
be extension, SIP username, SIP URI or mobile/landline phone)
webphone_api.call(NUMBER);
//Hang-up (usually called
from “disconnect” button click)
webphone_api.hangup();
//Send
instant message (Number can be extension, SIP username. Usually called from a
“send chat” button)
webphone_api.sendchat(NUMBER,
MESSAGETEXT);
}
});
//You should also handle events from the webphone and change your GUI
accordingly (onXXX callbacks)
</script>
</body>
See the webphone
package for more examples. You should check especially the tech demo
(techdemo_example.html / techdemo_example.js).
Note: If you don’t have JavaScript/web
development experience, you can still fully control and customize the webphone:
·
by its numerous configuration
options which can be passed also as URL parameters
·
from server side as described here
·
we can also send ready to use fully
customized web softphone with preconfigured settings, branding and integration
with your web and VoIP server
More details can be found here.
Use the following API calls to control
the webphone:
setparameter
(param, value)
You can use this function to set the
webphone parameters (the various settings which are described in the Parameters chapter) dynamically (at run-time) from JavaScript.
(Alternatively you can just hardcode
the parameters in the webphone_config.js or pass by URL query parameters)
Example:
setparameter('username ', 'john'); //this will set the SIP username to be used for upcoming
registration or call
Note:
All parameters are saved/cached by the
webphone so they will persist (except if you clear the browser storage and/or
cookies).
This function also has a third optional
allowempty parameter. If set to false then empty values are ignored and you
should use 'NULL' instead to clear the previous/cached setting if any. Its
default value is true.
You can clear previously set values using
the delsettings () API or by using the setparameter with an empty or 'NULL’
value. Example: setparameter('displayname', 'NULL');
Return type: string
Will return value of a parameter if
exists, otherwise will return empty string.
Example:
var mystringvariable =
getparameter('displayname '); //this
will return the display name if it was set previously
Optionally you can "start"
the phone, before making any other action.
In some circumstances the
initialization procedure might take a few seconds (depending on usable engines)
so you can prepare the webphone with this method to avoid any delay when the
user really needs to use by pressing the call button for example.
Set the “autostart”
parameter to 0 if
you wish to use this function. Otherwise the webphone will start automatically
on your page load.
If the serveraddress/username/password
is already set and auto register is not
disabled (not 0), then the webphone will
also register (connect) to the SIP server upon start.
If start()
is not called, then the webphone will initialize itself the first time when you
call some other function such as register()
or call().
The webphone parameters should be set
before you call this method (preset in the js file or by using the setparameter() function). See the “Parameters” section for details.
Optionally you can "stop" the
webphone engine (but this is done automatically on browser close or refresh, so
usually not required).
Calling the stop() API will also unregister.
Optionally you can "register"
if your SIP server has also registrar roles (most of them have this). This will
"connect" to the SIP server by sending a REGISTER request and will
authenticate if requested by the server (by sending a second REGISTER with the
digest authorization details).
Note:
o If the serveraddress/username/password
is already set and auto register is not
disabled (not 0), then the webphone will
register (connect) to the SIP server upon start, so no need to use this
function in these circumstances.
o There is no need to call the register() multiple times
as the webphone will automatically manage the re-registrations (based on the registerinterval parameter)
You can use this function to register
with multiple SIP accounts (multi-account feature).
The accounts
are passed as string in the following format: server,usr,pwd,ival,proxy,realm,authuser;server2,usr2,pwd2,ival2,proxy2,realm2,authuser2
For more details read here.
Un-register from your SIP server (will
send a REGISTER with Expire header set to 0, which means de-registration).
Unregister is called also automatically
at browser close so usually there is no need to call this explicitly.
Initiate call to a number, extension,
sip username or SIP URI.
Perhaps this is the most important
function in the whole webphone API.
It will automatically handle all the
details required for call setup (network discover, ICE/STUN/TURN when needed,
audio device open and call setup signaling).
With this function you can make calls via
your SIP server or SIP service provider:
·
to any SIP endpoint (such as
softphone or IP phone)
·
to any WebRTC endpoint
·
to pstn/mobile/landline (if your
server allows outbound calls. If you have a SIP subscription then most probably
you need a positive balance to be able to make pstn calls)
·
to any SIP server (including IVR or
callback access numbers)
You can also send dtmf messages once the
call connected by appending it to the number after a comma. For example if you make a call to 123,456 then it will call
123 and then it will send dtmf 456 once the call is connected.
For video chat use the videocall function mentioned below.
Call disconnect (disconnect the current
call or the call on the active line)
For incoming not yet connected call, hangup acts like reject.
Notes about line-management (in case if
you are implementing a multi-line user interface, otherwise you don’t need to
deal with line numbers):
o
If the line is set to -2 it will
disconnect all active calls.
o
If line is set to -1, then it will
disconnect the call on the current line (default behavior).
o
Otherwise it will disconnect the
call on the specified line.
o
More details here
Connect incoming call.
Disconnect incoming call.
(You can also use the hangup() function for this)
Silently ignore incoming call.
Forward incoming call to the specified number (phone number, username or extension).
For call forward to work, your SIP
server and/or the caller endpoint must support the 301 and 302 response codes
(Moved Temporarily/Permanently).
Forward should be used for incoming
calls only when the call is not connected yet. Otherwise use transfer() to
redirect connected calls.
Hold current call. This will issue an
UPDATE or a reinvite with the hold state flag in the SDP (sendrecv, sendonly,
recvonly and inactive).
Set state to true
to put the call on hold or false to un-hold.
Mute current call.
Pass true for the state to mute or
false to un-mute.
The direction
can have the following values:
0: mute in and out
1: mute out (speakers)
2: mute in
(microphone)
Disable/enable video(stream) during a
video call.
Pass true for the state to mute the
video or false to un-mute.
The direction
can have the following values:
0: mute in and out
1: mute remote
2: mute local
Transfer current call to number which
is usually a phone number or a SIP username. (Will use the REFER method after
SIP standards).
If the number parameter is empty string
and there are two calls in progress, then it will transfer line A to line B.
You can set the mode of the transfer
with the transfertype parameter.
For call transfer to work, your SIP
server and/or the caller endpoint must support the SIP REFER message (the
standard SIP call transfer as specified in RFC 3515 and RFC 5589).
Transfer should be used for connected
calls only. For not connected incoming calls you should use the forward()
function to redirect the call.
More details can be found here.
Add/remove people to conference.
Parameters:
-number: the peer username/number or
line number
-add: true if to add, false to remove
If number is empty than will mix the
currently running calls (interconnect existing calls if there is more than one
call in progress).
If number is a number between 1 and 9
then it will mean the line number.
Otherwise it will call the new number
(usually a phone number or a SIP user name) and once connected will join with
the current session.
Example:
call('999'); //normal call to 999
conference('1234'); //will call 1234 and add
to conference (conference between local user + 999 + 1234)
conference('2',false); //remove line 2 from
conference
conference(''); //add all current calls to
conference
conference('',false); //destroy conference (but
keep the calls on individual lines)
setline(3); //select the third line
hangup(); //will disconnect the third line
setline(-2); //select all lines
hangup(); //will disconnect all lines
Note:
o
if number is empty and there are
less than 2 active calls, then the conference function can’t be used (you can’t
put one single active call into a conference)
o
NS and Java engines also has a
local conference mixer thus they are more reliable for conferencing and doesn’t
depend on any server/gateway/proxy side conference support. If your main
use-case is conferencing then we recommend to force one of these engines
instead of WebRTC.
o
you can also use the webphone with
your server conference rooms/conference bridge. In this way, there is no need
to call this function (just make a normal call to your server conference
bridge/room access number)
o
the conference method can be
changed with the conferencetype parameter
o
more details here
Send DTMF message by SIP INFO or
RFC2833 method (depending on the "dtmfmode"
parameter).
This is often used for on key press
events or keypad events when to send the pressed number to the server or to the
peer for IVR or voicemail inputs.
Please note that the msg parameter is a
string. This means that multiple dtmf characters can be passed at once and the
webphone will streamline them properly.
The dtmf messages are sent with the
protocol specified with the “dtmfmode” parameter.
Use the space character to insert
delays between the digits.
Valid dtmf characters in the passed
string are the followings: 0,1,2,3,4,5,6,7,8,9,*,#,A,B,C,D,space.
Example:
dtmf("1");
dtmf("
12 345 #");
Note: dtmf messages can be
also sent by adding it to the called number after a comma. For example if you
make a call to 123,456 then it will call 123 and then it will send dtmf 456
once the call is connected.
Send a chat message via SIP MESSAGE
method as specified in RFC 3428.
Number can be a phone number or SIP
username/extension number (or whatever is accepted by your server).
The message can be clear ASCII or UTF-8
text or html encoded.
In order for IM to work your SIP server
needs to support SIP
MESSAGE. More details can be found here.
Send a SMS message if your
provider/server has support for SMS.
The number parameter can be any mobile
number.
The msg is the SMS text.
The from is the local user phone number
and it is optional.
SMS can be handled on your server by:
-converting normal chat message to SMS
automatically if the destination is a mobile number
-or via an HTTP API (you can specify
this to the webphone as the “sms” parameter)
More details can be found here.
play (start, file,
looping, toremotepeer)
Play sound file.
At least wave (.wav) files (raw linear
PCM) are supported in the following format: PCM SIGNED 8000.0 Hz (8 kHz) 16 bit
mono (2 bytes/frame) in little-endian (128 kbits).
Parameters:
o start: (number) 1 for start or 0 to stop the playback
o file: (string) file name or full path
o looping: (number) 1 to repeat, 0 to play once
o toremotepeer: (boolean) stream the playback to the
connected peer
Start/stop voice recording at runtime.
Set the start parameter to true for
start or false to stop.
The url is the address where the
recorded voice file will be uploaded as described by the voicerecupload setting.
Note:
You can also just set the “voicerecupload” parameter to have all calls
recorded.
More details about voice recording can be found here.
Initiate a video call to a number,
extension, sip username or SIP URI.
More details about video
calls can be found here.
Initiate a screen sharing session with
the user specified by the number parameter.
Parameters:
·
number: the peer number,
username, extension or SIP URI
·
screenid: optional parameter to
pass the screen id (It might be useful for some special use-case when you
acquire the screen-id via external tools such as the Chrome OS desktop capture
API)
Special
permissions might be needed. See also the screensharing
parameter for details. More details
about video calls can be found here.
Stop screen sharing.
setvideodisplaysize
(type,width, height)
Use this function to control the video
display size (both for remote and local video).
Accepted parameters:
·
type: 1=for remote video
container, 2=for local video container
·
width: integer value of width in
pixels
·
height: integer value of height
in pixels; this parameter can be left empty or null, and the height will be set
depending on the video's aspect ratio
More details can be found in
webphone_api.js and video.css file respectively (You can also set the size in
the video.css file).
Open audio/video device selector dialog
(built-in user interface)
getdevicelist(dev, callback)
Call this function and pass a callback,
to receive a list of all available audio devices.
For the dev parameter pass 0 for
recording device names list, 1 for the playback or ringer devices or 3 for
video camera devices.
The callback will be called
with a string parameter which will contain the audio device names in separate lines (separated by CRLF).
Note:
o
With the Java or NS engine it might
be possible that you receive only the first 31 characters from the device name.
This is a limitation coming from the OS audio API but it should not cause any
problem, as you can pass it as-is for the other audio device related functions
and it will be accepted and recognized.
o
Some browsers requires HTTPS or
file hosting to list the audio devices (might not work from localhost) if you
are using the WebRTC engine.
Call this function and pass a callback,
to receive the currently set audio device.
For the “dev” parameter one of the
followings are expected:
0: for recording
device
1: for the playback
device
2: for ringer device
3: for video camera
The callback will be called with a string parameter, which will contain
the currently selected audio device.
setdevice(dev, devicename, immediate)
Select an audio or video device. The devicename should be a valid audio or video device
name which can be listed with the getdevicelist()
call.
For the “dev”
parameter pass:
0: for recording
device
1: for the playback
device
2: for ringer device
3: for video camera
The "immediate"
parameter can have the following values:
0: default
1: next call only
2: immediately for active calls
Note:
o Before
calling this function, you might call the getdevice function first to obtain
the available devices. Then pass one of them with this setdevice API.
o When
using the NS winapi audio engine, the device names might be truncated to the
first 31 characters due to the wave audio API limitations. You can pass the
same back to the webphone and it will select the audio device correctly.
o The ring
device cannot be changed at runtime (the immediate flag will not have any
effect if you call this function while the webphone is already ringing).
o For the
WebRTC engine the ringtone playback needs user interaction. No ringtone will be
played for incoming calls if the user doesn’t interact with the webphone before
the call arrives due to browser media permission / auto-play policy as
described here.
Call this function, passing a callback
and will return the volume (percent) for the selected device.
The dev
parameter can have the following values:
0 for the recording (microphone) audio device
1 for the playback (speaker) audio device
2 for the ringback (speaker) audio device
The callback will be called with the volume parameter
which will be 0 (muted), 50 (default volume) or other positive number.
Note: the reason why this needs a callback (and doesn’t
just returns the volume as the function return value is because for some
engines the volume will be requested in an asynchronous way so it might take
some time to complete).
Set volume
(percent for the selected device).
0% means muted, 100% means maximum volume.
Default value is 50%, which means no change.
The dev
parameter can have the following values:
0 for the recording (microphone) audio device
1 for the playback (speaker) audio device
2 for the ringback (speaker) audio device
WebRTC limitations:
-Changing the recording volume level for WebRTC at run-time will take
effect only for the next call. You can also use the volumein
parameter to change the default volume.
-Some browsers doesn’t support changing the volume with WebRTC. It is
expected that the user will control the volume with the OS volume settings.
-A separate volume for ring is not supported on WebRTC
Call this function with boolean
parameter "true" to set the default playback device to loudspeaker on
supported devices such as Android phones and tablets.
The speakerphone will be restored if
called with “false”.
Note: You can also use the androidspeaker
parameter to preconfigure.
Set a custom sip header (a line in the
SIP signaling) that will be sent with all messages.
Can be used for various integration
purposes (for example for sending the http session id or any custom data).
For example: setsipheader('X-MyExtra:
whatever');
You can also set extra SIP headers with
the customsipheader parameter (setting this parameter is the easiest way
if you have some parameter which have to be sent always, regardless of the
circumstances)
Note:
·
It is recommended to prefix
customer headers with X- so it will bypass SIP proxies.
·
Multiple lines can be separated by
semicolon ; Example: setsipheader('X-MyExtra1: aaa; X-MyExtra2: bbb');
If you must use semicolon in the string, then use the
CRLF separator even if you have to set only one SIP header (in this case just
append it at the end)
·
Multiple lines can be also set by
calling this function multiple times with different keys.
·
There are two kinds of headers that
you can set:
o
Global (set for all lines including
the registrar endpoint): if the line is -2 or there is no current call on the
selected line (for example if you set it at startup, before any calls or with
line set to -2)
o
Per line: if the current line is
set and there is an active call on that line.
Note that you cannot set it for not already existing
lines (lines which doesn’t have calls on it yet. For the upcoming call you
should set it globally)
·
You can remove all the previously
passed headers (per line or global) by calling this function with an empty
string. Example: setsipheader(‘’);
·
You can remove a previously set
header by calling this function with an empty key for that header. Example:
setsipheader('X-MyExtra:');
getsipheader(header, callback, must)
Call this function passing a callback.
Example: getsipheader("Contact",
mycallback); //will call mycallback with the
Contact header from the incoming message
The passed callback function will be
called with one parameter, which will be the string value of the requested sip
header from the received SIP messages (received from your server of from the
other peer). If no such header is found or some other error occurs, then the
returned string begins with “ERROR” (for example: “ERROR:
no such header”) so you might ignore these.
The must parameter is optional and
defaults to false. If set to true, then the webphone might try to return the
header from any line (not just the current active line).
Note:
-The reason why this needs a callback
(and doesn’t just returns the last seen header values is because for some
engines the signaling messages have to be requested in an asynchronous way so
it might take a little time –usually only a few milliseconds- to complete the
request).
-The getsipheader() will send you the
headers from the incoming SIP messages (not the headers previously set by the
setsipheader() function call)
-If you are using the WebRTC engine with
a WebRTC-SIP gateway, then you should prefix the extra headers with X- to have
to forwarded by the gateway. For example instead of Alert-Info: URN your SIP
server should send X-Alert-Info: URN.
getsipmessage(dir,
type, callback, must)
Will return the last SIP signaling
message as specified by the current line and the dir/type parameters.
Call this function passing a callback.
Example: getsipmessage(0,
3, mycallback); //will call mycallback with
the incoming INVITE message text on the current line
The passed callback function will be
called with one parameter, which will be the string value of the requested sip
message as raw text.
If no such message is found or some
other error occurs, then the returned string begins with “ERROR” (for example:
“ERROR: SIP message not found”) so you might
ignore these.
The following parameters are defined:
dir:
-1: any
0: in
(incoming/received message)
1: out (outgoing/sent
message)
type:
0: any
1: SIP request (such as
INVITE, BYE)
2: SIP answer (such as
200 OK, 401 Unauthorized and other response codes)
3: INVITE (the last
INVITE received or sent)
4: the last 200 OK
(call connect, ok for register or other)
callback:
The callback function
must:
Optional boolean value.
Defaults to false.
If set to true, then
the webphone might try to return a SIP message from any line (not just the
current active line).
You can use this function if you have
good SIP knowledge and wish to parse the SIP messages yourself from JavaScript
for some reason (for example to extract some part of it to be processed for
other purposes).
Example to return the last received
INVITE message about an incoming call: getsipmessage(0,3,mysipmsgrecvcallback)
Note: just as other functions, this will
take in consideration the active line (set by setline() or auto set on in/out
call setup). You can set the active line to “all” [with setline(-2)] to get
the last message regardless of the line.
getlastrecinvite
(callback)
Get last received SIP INVITE message.
This is a simplified version of the
getsipmessage function if you are interested only in the last received INVITE
request.
Call this function passing a callback.
The passed callback function will be
called with one String parameter, which will be the last incoming call's SIP
INVITE message.
This is a helper function which might
be useful to get the whole INVITE message on call setup.
getlastsentinvite
(callback)
Get last sent SIP INVITE message.
This is a simplified version of the
getsipmessage function if you are interested only in the last sent INVITE
request.
Call this function passing a callback.
The passed callback function will be
called with one String parameter, which will be the last outgoing call's SIP
INVITE message.
This is a helper function which might
be useful to get the whole INVITE message on call setup.
Will return the state and various
parameters of an endpoint as a string in the following format:
LINEDETAILS,line,state,callid,remoteusername,localusername,type,localaddress,serveraddress,mute,hold,remotefullname
Basically, the parameters here are very
similar with the STATUS parameters described here.
Returns an unstructured string with
details about the previously disconnected call.
You should call this function after the
call is actually finished. For example after the onCdr callback have been fired.
For example in case of the NS engine,
this might return something like:
Line: 1 , Direction:
outgoing
Local Username: CALLER
, AuthUsername: CALLER
Peer Username: CALLED ,
Name: CALLED Called: CALLED
Server: SERVERDDRESS
Connectime: X msec
Duration: X msec
Disc By: Local ,
Reason: User Hung Up
AEC_SETT: 1, AEC_FULL:
2, AEC_FAST: 2, no, AEC_VOL: 1, AGC: 2, Denoise: 2, mediaench: aec: 2, denoise:
2, agc: 2, silencesupress: 0
Payload: X CODEC, pf:
1, network: fast
CPU: speed: 3500, load:
0.0, reccpuhigh: false, subshigh: 0, highdetected: no, meassured: 0 0
Audio: Record: count:
254 ival: 20 last: 5 0 Playback: count: 257 ival: 20 last: 5 0 issues: 2 500 16
Queue: 1 0 2 4 0
getcallerdisplayfull (callback)
Call this function and pass a callback,
to receive the incoming detailed caller id (might return two lines: caller id
\n caller name)
Note: If you just need the caller id,
you should just use the onCallStateChange peer name instead of this function.
The callback will be called with a
string parameter which will contain the incoming detailed caller id.
See the Caller-ID FAQ point for more details.
Returns a string with the reason about
failed connect/registration.
Deprecated! Use the onRegStateChange callback “unregistered” event instead!
This function can be used for explicit
line/channel management and it will set the current active channel.
For the line
parameter you can pass one of the followings:
-line number: -2 (all),
-1 (current/best), 0 (invalid), 1 (first channel), 2 (second channel) …. 100
-call id (so the active
line will be set to the line number of the endpoint with this SIP Call-ID)
-peer username (so the
active line will be set to the line number of the endpoint where the peer is
this user)
Use this function only if you present
line selection for the users. Otherwise you don’t have to take care about the
lines as it is managed automatically (with each call on the first “free” line)
Note:
o You can set the line to -2 and -1 only for a short
period. After some time the getline() will
report the real active line or “best” line.
o The internal state machine might automatically change
the active line after 300 milliseconds (this means that you must perform the
operation on the selected line quickly after this setline API call)
o Using the setline function will not mute the other
lines if there are multiple simultaneous calls. It will just select the line
for any further operation. For example if you wish to mute line 2, then you
have to call setline(2); and then mute(true);
More details about multi-line can be
found in the FAQ.
Return type: number
Will return the current active line
number. This should be the line which you have set previously except after
incoming and outgoing calls (the webphone will automatically switch the active
line to a new free line for these if the current active line is already
occupied by a call).
More details about multi-line can be
found in the FAQ.
linetocallid (line, callback)
Utility function to get the SIP Call-ID
for a line number. Might be useful in some circumstances.
The passed callback function will be
called with one parameter, which will be the SIP Call-ID for the passed line
number.
If not found then an empty string will
be returned in the callback.
callidtoline
(callid, callback)
Utility function to get the line number
for a SIP Call-ID. Might be useful in some circumstances.
The passed callback function will be
called with one parameter, which will be the line number for the passed SIP
Call-ID.
If not found then a negative line
number will be returned.
Set/get the SIP Call-ID used for the
first upcoming new SIP session.
This function might be used if you need
the SIP Call-ID before the call for some reason. For example you can use it
before the call function to set/get the SIP
Call-ID of the new call. Otherwise the webphone will automatically generate an
unique SIP Call-ID for each new session which you can query using the linetocallid function or receive it with the onCallStateChanged or onCdr
callbacks.
If this function is called without the
callid parameter or the callid as an empty string then the webphone will
generate and return a random call-id.
The return value is the new SIP Call-ID
as string.
Return type: boolean
Return true if the webphone is
registered ("connected") to the SIP server.
Note: you can track the phone state
machine also with the events
callbacks or check this FAQ.
Return type: boolean
Return true if the webphone is in call,
otherwise false.
Note: you can track the phone state
machine also with the events callbacks.
Return type: boolean
Return true if the call is muted,
otherwise will return false.
Return type: boolean
Return true if the call is on hold,
otherwise will return false.
Check if communication channel is
encrypted: -1=unknown, 0=no, 1=partially, 2=yes, 3=always
Subscribe to call state of
other extensions to receive call state change information as BLF notifications
by triggering the onBlfStateChange callback.
Userlist: list of sip account username separated by comma.
In order for BLF (busy
lamp field) to work, make sure that your server and peer(s) has support for BLF
subscribe/notify with dialog event package as described in RFC 3265 and RFC
4235.
Note:
If BLF is an important feature for you, then we recommend
the usage of the NS or Java engines as this is unreliable with WebRTC (set the
enginepriority_ns and enginepriority_java to 4)
More details here.
Will receive presence information
PRESENCE notifications and will trigger the onPresenceStateChange callback.
Userlist: list of sip account username separated by comma.
In order for presence to work, make
sure that your server has support for subscribe/notify. More details here.
setpresencestatus
(status)
Function call to change the user online
status with one of the followings strings: Online, Away, DND, Invisible,
Offline (case sensitive).
Returns the currently used engine name
as string: "java", "webrtc", "ns",
"app", "flash", "p2p", "nativedial".
Can return empty string if engine
selection is in progress.
Might be used to detect the
capabilities at runtime (for example whether you can use the jvoip function or
not)
This function will return a String
containing the whole call history list. If there are no entries in call
history, it will return null.
Call history entries will be separated
by "carriage return new line": \r\n
Call history fields will be
separated by "tabs": \t
The order of fields and their meaning:
o
type: int - 0=Outgoing call,
1=Incoming call, 2=Missed call
o
name: String - can be a name, can
be the same as the number or can be empty String
o
number: String - the phone
number/SIP URI
o
date: int - timestamp date of
call
o
duration: int - duration of the
call in milliseconds
o
discreason: String - call
disconnnect reason
Example: 1 \t Name \t Number \t Date
\t Duration \t Discreason
This function will return a String
containing the whole contact list. If there are no contacts, it will return
null.
Set the all parameter to true to
receive also virtual contacts as well, like voicenumber, etc...
Contacts will be separated by
"carriage return new line": \r\n
Contact fields will be
separated by "tabs": \t
A contact can have more than
one phone numbers or SIP URIs, so these will be separated by Pipe(Vertical
bar): |
See example below:
The order of fields and their meaning:
name: String - the name of the contact
number: array of String - the
number(s)/SIP URI(s) of the contact
favorite: int - 0=No, 1=Yes
email: String - email address of the
contact
address: String - the address of the
contact
notes: String - notes attached to this
contact
website: String: web site attached to
this contact
types: array of String –the type of the
above number(s)
Example: Name \t Number1|Number2 \t
Favorite \t Email \t Address \t Notes \t Website \t Type1| Type2 \r\n
addcontact
(fullname, number, email, address, notes, website, type, favorite)
Add a contact to the contact list.
This is useful only with the softphone
skin (otherwise most probably you don’t need a contact list or you manage it
yourself on a custom user interface after your needs).
The number and the type can be a list (strings separated by | ).
For the type you can set any string, but on the softphone skin only the
following are handled: phone, home, mobile, work, other, fax_home, fax_work,
pager, sip.
Examples:
webphone_api.addcontact('Kate',
'1111'); //add a simple
contact with name: Kate, number: 1111
webphone_api.addcontact('John
Smith', '2222|3333'); //add
contact with name: John Smith and two numbers
webphone_api.addcontact('James
Oliver', '+40741234567’, 'james@gmail.com', 'Victoria street', 'hi',
'www.example.com', 'mobile', '1'); //add a favorite contact with all parameters set
webphone_api.addcontact('James
Oliver', 444444|555, 'james@gmail.com', 'Victoria street', 'hi',
'www.example.com', 'phone|sip', '0'); //add contact with multiple numbers and all parameters set
Note:
Contacts can be prepopulated also by using the defcontacts
parameter.
If the normalize_contact parameter
is set to 1, then the webphone will
“normalize” the contact details. Set to 0 if
you wish to disable this.
getcontact
(name, number)
Call this function passing the name
and/or number of the contact.
Will return a String with the following
parameters separated by "tabs": \t if found:
·
name: String - the name of the
contact
·
number: String - number(s)/SIP
URI(s) of the contact separated by Pipe(Vertical bar): |
·
favorite: int - 0=No, 1=Yes
·
email: String - email address of
the contact
·
address: String - the address of
the contact
·
notes: String - notes attached to
this contact
·
website: String: web site
attached to this contact
·
type: the type of the above
number(s)
If contact is not found, then it will
return null.
delcontact
(name, number)
Delete contact from the contact list
where the name or the number match.
This is useful only with the softphone
skin (otherwise most probably you don’t need a contact list or you manage it
yourself on a custom user interface after your needs).
Use the delallcontacts()
API if you wish to delete all contacts.
Returns the working directory for the
NS and Java engines (not applicable for WebRTC and Flash).
The working directory is the folder
which is used to save any files (configurations, logs, voice recordings).
Delete stored data (from cookie, config
file and local-storage).
For the level parameters is optional
and it can be set to one of the followings:
·
0: delete the settings only if it
was not already cleared (default)
·
1: delete the settings
·
2: force all (delete everything:
settings, contacts, call history, messages and all other data)
·
3: delete also library cache
Warning: this will delete all settings, even those that should be
remembered between sessions, such as “Have we already asked X from the
enduser?”. To deal with different settings we recommend using the profiles instead of using this API or just set unneeded
settings to NULL. More details can be found here.
This API might stop or restart the SIP engine.
You should call this on logout (not at start) if for some reason you
wish to delete the stored phone settings.
Returns a string containing all the
accumulated logs by the webphone (the logs are limited on size, so old logs
will be lost after long run).
More details about logs can be found
here.
Returns the webphone global status. The
possible returned texts are the same like for getEvenetsnotifications.
You might use the events described
below instead of polling this function.
We have listed all the important and
commonly used API’s in this documentation, however, there are some other
advanced/deprecated/internal API’s that can be accessed.
Advanced functions
There are a few additional not so
important functions provided in the webphone_api.js.
Inspect the webphone_api.js file for the details.
Helper functions
There are a few helper/internal/not so
important functions that can be accessed from \js\lib\api_helper.js.
WebRTC internals
When using the WebRTC engine, you can
access the WebRTC browser API via the following functions:
webphone_api.getrtcsocket() -Returns a reference to the WebRTC engine socket object.
Returned value can be null or the reference to the WebSocket object.
webphone_api.getcallsession (line,
destnr, callid) -Returns a reference to the internal
call session object. Returned value can be null or the reference to the call
session object. You might pass one or more parameters to specify the required
call session: line, destination number, Call-ID. If no parameters are
specified, then it will return the default/current session if any.
webphone_api.getrtcpeerconnection(line,
destnr, callid) -Returns a reference to the
current/last WebRTC RTCPeerconnection object or null if no RTCPeerconnection
exists.
Deprecated functions
The webphone is fully backward and
forward compatible and we never remove old functions. All the old deprecated
functions can be still used as-is, without the need to change your code. These
functions are declared in the webphone_api.js or moved to \js\lib\api_helper.js
(they are still available via the webphone_api object).
The major deprecated functions are the
followings:
·
onLoaded, onStart, onStop
(replaced with onAppStateChange)
·
onRegistered, onRegisterFailed,
onUnRegistered (replaced with onRegStateChange)
·
callSetup, callRinging,
callConnected, callDisconnected (replaced with onCallStateChange
setup/ringing/connected/disconnected events)
·
onDisplay, onLog, onEvents
(replaced with onEvent)
The call state events strings was also
changed from callSetup/callRinging/callConnected/callDisconnected to
setup/ringing/connected/disconnected. You can restore the old behavior by
setting the apibehaviour to 0. For the new behavior you can set the
apibehaviour parameter to 1. New webphone build are set with this by default.
For old customers the default value is -1 which means reporting strings both in
old and new format.
Internal engines
If engine is Java or the NS Service
plugin, then you can access the full low-level API as described in the JVoIP SDK documentation.
This can be done with the jvoip function call:
jvoip(name, jargs)
Parameters:
Name: name of the function
Jargs: array of arguments passed to the
called function. Must be an array, if API function has parameters. If API
function has no parameters, then it can be an empty array, null, or omitted
altogether.
For example the low level API function:
API_Call(number) can be called like this: webphone_api.jvoip('API_Call',
line, number);
The below callback functions can be
used to receive events from the webphone such as the phone state machine status
(registered/call init/call connected/disconnected) and other important events
and notifications.
Note: passing null as the callback
parameter for these functions will remove all previously set callbacks (clear
the internal callback functions array).
onAppStateChange (callback)
You can use this function to track app
state changes.
The passed callback function will be
called on every webphone app state change. The callback function has a state string parameter containing the new state of
the application.
The states are the followings:
·
"loaded"
- the webphone library is completely loaded so you can start the usage (call
any other API functions only after this state is received!).
·
"started"
- the VoIP engine has successfully started (ready to register or make calls).
Note: you can initiate calls also from the “loaded” event and it will be queued
to be executed after started.
·
"stopped"
- the VoIP engine has stopped (all endpoints unregistered/disconnected and the
sipstack was destroyed). Usually triggered at page unload.
Example:
webphone_api.onAppStateChange(function
(state) //watch
for webphone state changes
{
if (state === 'loaded') //webphone library loaded
{
webphone_api.setparameter("name",
"value"); //set any parameters
webphone_api.start(); //start if not started
automatically (for example if the autostart parameter is set to 0)
//setup call state machine
watcher
webphone_api.onCallStateChange(function
(event, direction, peername, peerdisplayname, line, callid)
{
//handle
any call events here. For example to catch the call connect events:
if
(event === 'connected')
{
alert("Call
connected with " + peername);
}
//else if (event === ' disconnected') …
});
}
else if (state ===
'started') //sip
stack started
{
webphone_api.call('NUMBER');
//make a call
immediately once started
}
});
Note: the onAppStateChange deprecated to old onLoaded, onStart and
onStop functions but these are still available and you don’t need to change any
old code.
onRegStateChange
(callback)
You can use this function to track
register state changes.
The REGISTER method in SIP is used to
“connect” to the SIP server, so the server can learn the device location to be
used to route incoming calls and other messages.
The passed callback function will be
called on every register state change with a state string parameter.
The states are the followings:
·
"registered"
– registered successfully to the SIP server
·
"unregistered"
– unregistered from the SIP server (if user closes the webpage, then you might
not have enough time to catch this event)
·
"failed"
– register failed. You can receive the cause of the failure in a second reason
string parameter.
onCallStateChange
(callback)
You can use this function to track call
state changes.
The passed callback function will be
called on every call state change (triggered when the webphone is in call).
Parameters:
·
event: can have following string
values: setup, ringing,
connected, disconnected (other events such as "midcall" can be ignored)
·
direction: 1 (for outgoing call), 2 (for
incoming call)
·
peername: is the other party
username (or phone number or extension)
·
peerdisplayname: is the other
party display name if any
·
line: channel number (this might
be important only if you wish to handle multi-line management explicitly)
·
callid: SIP Call-ID
A simple usage example can be found here.
Note:
o the call might
change from setup state directly into disconnected state if it was connected
o ringing
state is optional (it is not a definitive answer for the INVITE transaction so
it is not mandatory in SIP)
o you might
receive other event strings which can be just safely ignored
onPresenceStateChange
(callback)
You can use this function to track
presence changes.
The passed callback function will be
called on every presence (online/offline/others) state change (of the remote
users).
To initiate presence requests, you can
use the checkpresence() API or the presenceuserlist parameter.
Parameters:
·
peername: is the other party
username (or phone number or extension)
·
presence: can have following
values: CallMe,Available,Pending,Other,CallForward,Speaking,Busy,Idle,DoNotDisturb,Unknown,Away,Offline,Exists,NotExists,Unknown
·
displayname: optional peer
display name if sent as part of presence
·
email: optional peer email
address if sent as part of presence
onBLFStateChange
(callback)
You can use this function to track BLF
changes.
The passed callback function will be
called on every call state change (of the remote users) which might be used as
BLF (busy lamp field)
To initiate presence requests, you can
use the checkblf() API or the blfuserlist parameter.
Parameters:
·
peername: is the other party
username (or phone number or extension)
·
direction: can have one of
following values: undefined, initiator (outgoing call) or receiver (incoming
call)
o
undefined (not for calls or no announced by the peer)
o
initiator (outgoing call)
o
receiver (incoming call)
·
state: can have one of following
values: trying , proceeding, early, comfirmed, terminated, unknown or failed
o
trying (call connect initiated)
o
proceeding (call connecting)
o
early (ringing or session progress)
o
confirmed (call connected)
o
terminated (call disconnected)
o unknown (unrecognized call state received)
o
failed (BLF subscribe or notify failed)
·
callid: optional SIP call-id of
the call (if reported by the BLF notify)
The passed callback function will be
called when chat message is received.
Parameters:
·
from: username, phone number or
SIP URI of the sender
·
msg: the content of the text
message
·
line number
·
group: group name; the name of
the group if it's group chat, otherwise it will be an empty string or “null”
(“null” might be received if other endpoint has group chat support but this
message is not part of a group chat
The passed callback function will be
called when an SMS message is received.
Might be triggered only if the server
has VoIP SMS support or SMS API implemented.
Parameters:
·
from: username, phone number or
SIP URI of the sender
·
msg: the content of the text
message
The passed callback function will be
called when a DTMF digit is received.
Parameters:
·
dtmf: received DTMF character as
string
·
line: channel number
Supported DTMF receive method with all engines is INFO SIP messages.
The NS and Java engines has support also for RFC 2833 in RTP.