0% found this document useful (0 votes)
46 views4 pages

Checkpresence (Userlist) : and Enginepriority - Java To 4)

Uploaded by

syndronize
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
46 views4 pages

Checkpresence (Userlist) : and Enginepriority - Java To 4)

Uploaded by

syndronize
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

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)

checkpresence (userlist)
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.

setpresencestatus (status)
Function call to change the user online status with one of the followings strings: Online, Away, DND, Invisible, Offline (case sensitive).

getenginename ()
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 below jvoip function or not)

listcallhistory ()
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

listcontacts (all)
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

Example: Name \t Number1|Number2 \t Favorite \t Email \t Address \t Notes \t Website\r\n

addcontact (fullname, number, email, address, notes, website )


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).
Note: Contacts can be prepopulated also by using the defcontacts parameter.

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

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)

getworkdir ()
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).

delsettings (level)
Delete stored data (from cookie, config file and local-storage).
For the level parameters the following are defined:
1: just settings file
2: delete everything: settings, contacts, call history, messages

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.

getlogs ()
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.

getstatus ()
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.

others
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 existing 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);

Events
The following 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:

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

//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
 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)

You might also like