Cisco Wireless Phone 800 Series Developer’s Guide 6

API Specification

Barcode API Guidelines

On Cisco Wireless Phones with barcode readers (for example 840s), a Cisco barcode system service is started during boot. The service is responsible for generating intents with barcode reader state and barcode data. If the above uses-library declaration has android:required=”false” set, the developer needs to check for this to be a Cisco device before using any barcode API.
Determining if a barcode scanner is present
Applications can determine if a barcode scanner is present, either by checking device model numbers (i.e. using Android.os.Build MODEL field) which may be challenging to keep in sync with new Cisco or OEM product offerings, or by using the BarcodeManager hasBarcodeReader method, where the latter is the preferred approach.
Note The BarcodeManager instance shall exist even on devices without a barcode scanner.
barcodeManager = BarcodeManager.getInstance(); if(barcodeManager.hasBarcodeReader()){ // do something useful with reader } else{ // no barcode reader on this phone. }
Enabling / disabling the barcode scanner
To prevent a user accidentally illuminating the scanner’s LED when pointed at someone, an app can control the scanner function using the disableBarcodeReader and enableBarcodeReader methods. The current scanner state can be identified via the BarcodeManager.STATE_INTENT and checking the extra data for STATE_BC_DISABLED or STATE_BC_ENABLED.
disableButton.setOnClickListener(new OnClickListener(){ @Override public void onClick(View v) { barcodeManager.disableBarcodeReader(v.getContext()); } }); enableButton.setOnClickListener(new OnClickListener(){ @Override public void onClick(View v) { barcodeManager.enableBarcodeReader(v.getContext()); } });
Receiving scanned barcode data
To receive barcode data, an application can register a broadcast receiver for the BarcodeManager.DATA_INTENT. The actual data is available in the extended data of the intent by using the String key BarcodeManager.SCAN_DATA_EXTRA. You can also get symbology by using the string key BarcodeManager.SCAN_DATA_SYMBOLOGY.
public class BarcodeReceiver extends BroadcastReceiver { String mReceiverName = “”; BarcodeReceiver(String receiverName){ mReceiverName = receiverName; } @Override public void onReceive(Context context, Intent intent) { String rcvData = intent.getStringExtra(BarcodeManager.SCAN_DATA_EXTRA); String rcvSymbology =

Cisco Wireless Phone 800 Series Developer’s Guide 7

Custom Intents

API Specification

intent.getStringExtra(BarcodeManager.SCAN_DATA_SYMBOLOGY); Logging.myLog(mReceiverName + ” Received: ” + rcvData, context); Logging.myLog(mReceiverName + ” Received Symbology: ” + rcvSymbology, context); } public class TestActivity extends Activity{ public void onCreate(Bundle savedInstanceState) { // Register activity barcode receiver. bcReceiver = new BarcodeReceiver(“BC Activity”); IntentFilter filter = new IntentFilter(BarcodeManager.DATA_INTENT); registerReceiver(bcReceiver, filter); } }
Enabling / disabling text input field data insertion
By default, Cisco Wireless Phone will input scanned data into a text input field if in focus. This is useful if the application does not actively interface with the barcode API to receive the data directly. However, some apps may not want this behavior, so the behavior can be disabled by an app using the disableBarcodeKeyboard and enableBarcodeKeyboard methods. The current keyboard input state can be identified via the BarcodeManager.STATE_INTENT and checking the extra data for STATE_KEYBOARD_DISABLED or STATE_KEYBOARD_DISABLED. If an application is using our API it is suggested to disable this keyboard capability.
testBarcode.disableBarcodeKeyboard(v.getContext());
Example code
Please see the example code package for the Barcode API.
Custom Intents
Cisco Wireless Phone 840S or 860S supports Custom Intents.
The example application in this SDK zip file demonstrates the usage of the custom Intents. The manifest.xml file has Intent Filters with Intent Action and Intent Categories.
The partner will need to provide the three settings to the SAM or EMM administrator.
· Intent Delivery Method
· Intent Action
· Intent Category
Those three settings collectively will enable the Barcode Service to send an Intent to the partner application using one of the following delivery methods after a scan is completed.
· Start Activity
· Start Service
· Start Foreground Service
· Send Broadcast
The custom intent will contain the data shown in the table below as String Extras.

Cisco Wireless Phone 800 Series Developer’s Guide 8

API Specification

Use Cases

Use Cases

String Extras can be obtained from the extras bundle shown below by calling “intent.getExtras()”

Key

Value (examples)

Notes

com.spectralink.Scanflex.data_string GS18061200285

Barcode value after string Manipulation

com.spectralink.Scanflex.data_dispatch_time 1586158888809

Unix time of Scan

com.spectralink.Scanflex.label_type Code 128

Type of Symbology Scanned

1. Start Activity use case
The partner app wants to move from the MainActivity to a different activity on a successfully completed scan and send data to the new activity.
2. Send Broadcast use case
The partner application wants to send a broadcast to a broadcastReceiver that it has already implemented, either within the same application or a different application developed by the same partner.

Button API
Buttons App User Interface
Cisco Wireless Phones contain multiple buttons not normally found on a consumer phone (Left, Right, Top, and Fingerprint (Cisco Wireless Phone 860 or 860S only), along with expected buttons (Power, Volume up and Volume down). Volume up and down buttons are available to apps via standard Android APIs, e.g. using class KeyEvent and keycode KeyEvent.KEYCODE_VOLUME_DOWN.
All buttons are configurable in the Buttons app except for the power button. If an app listens for a android intent via a button press, that android intent must be mapped to that respective physical button in the Buttons App. For example, remapping the left button from barcode’ tocustom 1′ will now send the custom 1 intent when the left button is pressed.
The Buttons app provides a way for the user to change the way a button functions. The function follows the change. No matter which button is selected for a function, the function intent will be delivered when the new button is pressed.
The Buttons app allows you to change which programmable button does what assignable action:

Cisco Wireless Phone 800 Series Developer’s Guide 9

Buttons App User Interface

API Specification

Button LEFT button RIGHT button Top button Fingerprint* Volume up Volume down

Default action No action PTT Alarm Fingerprint* Volume up Volume down Scanner** Run application Home key Back key Open URL Menu key Custom 1 Custom 2 Custom 3 Custom 4

Cisco Wireless Phone 800 Series Developer’s Guide 10

API Specification

Cisco Intents for Buttons App

• Cisco Wireless Phone 860 or 860S only (on the back of the phone) ** Cisco Wireless Phone 840S or 860S only The user simply selects the button to remap and then selects the new desired function. Not all actions are available on all buttons. Custom buttons are programmed by the system administrator.
  Default

Options

Cisco Intents for Buttons App
A custom app can use the physical buttons on Cisco Wireless Phone for its own purposes. There are two steps to get the appropriate functionality: 1. The custom app must register a broadcast receiver to listen for a Cisco intent. 2. The respective Cisco intent must be mapped to that button using the Button app. The following intents can be defined in a custom application and then registered to a receiver within that application:
Cisco Wireless Phone 800 Series Developer’s Guide 11

Button API Guidelines

API Specification

Note Cisco Wireless Phones use the “Apollo” code word for intents used by all models of Cisco Wireless Phones.

Table 3: Broadcast Action Intent strings

String

Description

“com.apollo.intent.action.PTT_BUTTON”

Intent action string for PTT

“com.apollo.intent.action.PANIC_BUTTON”

Intent action string for Panic

“com.apollo.intent.action.BARCODE_BUTTON” Intent action string for Barcode

“com.apollo.intent.action.FINGERPRINT_BUTTON” Intent action string for Fingerprint

“com.spectralink.intent.action.CUSTOM1_BUTTON” Intent action string for Custom 1

“com.spectralink.intent.action.CUSTOM2_BUTTON” Intent action string for Custom 2

“com.spectralink.intent.action.CUSTOM3_BUTTON” Intent action string for Custom 3

“com.spectralink.intent.action.CUSTOM4_BUTTON” Intent action string for Custom 4

For each intent, the EXTRA_TEXT string provides information on the button action as follows:
Table 4: EXTRA_TEXT String

String
“keypress” “keyrelease” “shortpress” “longpress”

Description
When key is initially pressed When key is released Indicates key was pressed for short duration Indicates key was pressed for a duration exceeding the Android longpress threshold

Button API Guidelines
Please see the Button API example app included in this SDK for more details. The following provides a simple code snippet to detect a PTT long press.
public static final String PTT_BUTTON = “com.apollo.intent.action.PTT_BUTTON”; public static final String LONGPRESS = “longpress”; public class ButtonActionReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { if(intent.getAction().equals(PTT_BUTTON)) { Bundle b = intent.getExtras(); if(b.get(Intent.EXTRA_TEXT).equals(LONGPRESS)){ //do something cool with long key press } }

Cisco Wireless Phone 800 Series Developer’s Guide 12

API Specification

Buttons Troubleshooting

} }
The generated intents do have dependencies based on Cisco Wireless Phone’s awake or asleep state, i.e. whether the screen is on or off. The following provides an explanation of the behaviors. However, application developers should become familiar with the button intent behaviors before trying to integrate them into their app:
Phone Awake, Screen On (All buttons): 1. Button pressed -> button’s respective intent generated with EXTRA_TEXT=keypress. 2. If button is held longer than Android’s longpress threshold -> button’s respective intent generated with
EXTRA_TEXT=longpress. 3. If button is released before Android’s longpress threshold -> button’s respective intent generated with
EXTRA_TEXT=shortpress. 4. Button released -> button’s respective intent generated with EXTRA_TEXT=keyrelease.
Phone Asleep, Screen Off (button set to Scanner or Custom): 1. Button pressed -> No intent generated 2. Button released -> No intent generated
Phone Asleep, Screen Off (button set to Alarm or PTT): 1. Button pressed -> Phone wakes, NO keypress intent generated 2. If button is held longer than Android’s longpress threshold -> button’s respective intent generated with
EXTRA_TEXT=longpress. 3. If button is released before Android’s longpress threshold -> button’s respective intent generated with
EXTRA_TEXT=shortpress. 4. Button released -> button’s respective intent generated with EXTRA_TEXT=keyrelease.
As shown above, buttons can behave differently, and behavior differs depending on phone state.
Buttons Troubleshooting
Adding Logcat messages will be helpful for identifying when and what Intents are received.
Miscellaneous
The following section provides additional useful programming information for Cisco Wireless Phone. These may not use Cisco proprietary APIs but offer useful Standard Android based hints.

Cisco Wireless Phone 800 Series Developer’s Guide 13

Initiating a Call Using Cisco SIP Dialer

API Specification

Initiating a Call Using Cisco SIP Dialer
Apps may want to use the integrated Cisco SIP dialer app to initiate phone calls.. Calling can be done using the standard Android Intents, ACTION_CALL and ACTION_DIAL. See Android documentation for full details on semantics. However in general terms, ACTION_CALL initiates a call, but requires Manifest permissions, whereas ACTION_DIAL does not actually start the call nor does it require Manifest permission.
An example of using the intent is:
Intent callIntent = new Intent(Intent.ACTION_CALL); callIntent.setData(Uri.parse(“tel:7203754157”)); startActivity(callIntent);
There are many examples on the Internet, one good reference is:http://www.mkyong.com/android/ how-to-make-a-phone-call-in-android/
Google Play Services
Cisco Wireless Phone is a Google certified device and accordingly the software now includes and supports Google Mobile Services. Google Play, Google Play Services, and associated APIs are available to applications as applicable.

Cisco Wireless Phone 800 Series Developer’s Guide 14

2 C H A P T E R

Web Development

Web API

· Web API, on page 15 · Your Application and Cisco Wireless Phone, on page 17 · Overview of the Cisco Wireless Phone Web API, on page 21 · Telephony Integration, on page 25 · Write Your Web Application, on page 49 · Configure the Parameters Required by the Cisco Wireless Phone Web API, on page 52 · Troubleshooting and Best Practices, on page 55 · Testing, on page 57

Cisco Web API App
The Cisco Wireless Phone ships with the Cisco Web API app to support Web developers. The Cisco Web API app contains the JavaScript extensions necessary to support developer requirements, as detailed in this document. It allows developers to interface with external services and provide links to frequently used websites in addition to providing a way to configure the wireless phones to integrate with an XML application. The Web API provides:
· A widget to display a set of customer-defined URLs for applications and a special browser (WebView),
· A custom notification management tool, AlertView, that gives applications the ability to push data or a URL to the phone and have it displayed in the AlertView notification window.
· Provides the capability for applications to receive notifications of events or poll for status.
The Alertview notification window and the APP URLs widget ensure extended app availability for the Web API app.
By providing two separate activities for both pushed content and content the user has requested, content is separated, and the user does not lose the content that they asked for if pushed HTML content is sent to them:
· Pushed content is delivered to the user as a standard Android notification, which is displayed in the notification drawer. It is not assumed that all pushed content is more important than the current user activity. Therefore, only Critical priority pushed content will take over the user’s foreground activity

Cisco Wireless Phone 800 Series Developer’s Guide 15

Interaction with other Android Applications

Web Development

and open the Alertview. Lower priority content is queued up and shown when the user selects the notification.
· User-initiated links in the App URLs launch when the user opens the widget box containing the App URLs. Once tapped, the shortcuts open applications within a browser.
Interaction with other Android Applications
Because pushed content is sent to the Android notification manager the user can choose to handle it when they choose, except in the case of Critical priority content, which will notify the user audibly and will become the foreground activity. Thus, there is no adverse interaction with other running Android applications.
Interaction with Phone Calls
If the user is in a phone call they will not be interrupted by any pushed content except for critical priority content, which will notify them audibly and will take over the foreground activity. For information about limitations to the web API when a third-party VoIP application is used instead of the Cisco SIP application, see Appendix A: Additional information
Other Browsers That May Be Installed on the Phone
Remember that the end user may have many other apps, including browsers, on their phone. These browsers will not contain the extensions that are present in the Cisco Web API app.
Web Development Overview
Web applications running on Cisco Wireless Phones can be as simple as a list of contacts or as complex as a nurse call system. Cisco Wireless Phones support App URLs, where users can interact with Web pages as they would on a computer.
Development of a web application for the Cisco Wireless Phone generally follows these steps:
1. Planning. Defining the requirements of the application according to the facility’s needs.
2. Familiarization of the capabilities of the Cisco Wireless Phone.
3. Familiarization of the infrastructure requirements of the Cisco Wireless Phones ­ example: call control (telephony server), wireless LAN, etc. You will need to learn about the components of the entire system to implement your application. This knowledge is obtained through study of the Cisco Wireless Phone Deployment Guide and VIEW Program AP Guides.
4. Application development and configuration requirements development. From your research on the requirements of the infrastructure, you will develop both the application itself and configure the parameters that the wireless phones need to use in order to integrate with the application. The settings will become central to testing your application and ultimately will be deployed along with the application in test and customer environments.
5. The first phase of Application testing and debugging uses the Cisco Wireless Phone hardware, running your customized settings, and other components to mimic a telephony deployment: a simple wireless LAN environment and call server.
6. The second phase of application testing uses Cisco Wireless Phones are deployed in a customer representative wireless LAN test environment. This test setup is detailed in this guide. During this test,

Cisco Wireless Phone 800 Series Developer’s Guide 16

Web Development

Using XHTML

applications can be tested for capacity as well as robustness for phones moving on and off the wireless LAN (due to power cycles and out of range movement). 7. The third phase of application testing is done during deployment in a working environment. 8. Launch.
Using XHTML
XHTML, or eXtensible HyperText Markup Language, is a family of XML markup languages that mirror or extend versions of the widely-used Hypertext Markup Language (HTML), the language in which web pages are written. XHTML is HTML 4.01 redesigned as XML. You should ideally have experience working with HTML and XHTML programming or access to someone who has such experience to benefit from the information and discussion provided in this guide. For more information, refer to the following online documents:
· W3C® HTML 4.0.1 Specification · W3C HTML 5 Specification · W3C XHTML 1.0 The Extensible HyperText Markup Language (Second Edition) · W3C XHTML Basic 1.1 – Second Edition · W3C XHTML 1.1 – Module-based XHTML – Second Edition · W3C XHTML Tables Module ­ XHTML 2.0
Note You can use whichever development languages or servers you choose, including JavaScript, PHP, Python®, Django®, TomcatTM or ApacheTM. Use whichever tools you are most comfortable using, or those that are most supported by your IT department.
Your Application and Cisco Wireless Phone
Cisco Wireless Phone is a powerful multi-touch phone that enables many types of applications, including native Android applications and Web-based applications. Applications that are standard web applications or pages can be accessed using any web browser in the same manner as a user would on a wireless phone. A web application that utilizes any of the features of the Cisco Wireless Phone Web API will use the Cisco App URLs instead of a common browser. Alerts sent to the phone from a web application server will show up to the user in the Cisco Alertview in addition to creating an Android notification in the notification bar.

Cisco Wireless Phone 800 Series Developer’s Guide 17

Cisco App URLs

Web Development

Cisco App URLs
The Cisco App URLs are web application shortcuts that open in a pared-down browser with enhanced Javascript capabilities designed specifically for onboard applications.
A user accesses the App URLs by using programmed shortcuts that open the application. The web application shortcut widget box supports up to 10 icons for App URLs.
Long press the home screen to open the Widgets option. Scroll down to display the Web API widget option. Long press and drag the widget box to a home screen.
Install the Apps URLs widget box. The App URLs shortcuts display together in a widget box.

The App URLs supports true Cisco Wireless Phone applications with the following features: · HTML 5 ­ without video support · CSS 3.0 ­ allowing only a single transition at a time. · SVG 1.1 (partial support) · JavaScript / The Web API app is used by developers to interface with external services and provide links to frequently used websites. · Web API allows you to configure the wireless phones to integrate with an XML application.DOM access · XMLHttpRequest · HTTP 1.1 · AJAX
Cisco Wireless Phone 800 Series Developer’s Guide 18

Web Development

Cisco Alertview

Cisco Alertview
The Cisco Alertview allows the user to see the top pushed Data or URL page (called an alert) in the queue that was sent to their Cisco Wireless Phone. It also sends notifications to the Android notification manager to alert the user of the number, and highest priority, of un-dismissed alerts. It contains the following elements:
· Title bar showing the HTML redirecting… · Add a hidden form with which to send the data: Applies to most cases (where you are not accessing the GET variables directly w/ JavaScript).

Some additional logic would be required on the server to send the correct information (accessible via the POST header of the HTTP request) back with NOTIFY.HTML but it would vary with language / framework / use case.
As a bonus, POSTed requests are considered more secure than GET style requests which include variables visible in the URL.

HTML Push
The data push enables you to send XHTML page content directly to a phone, without the overhead of the phone having to request the XHTML. Use the following format when sending the HTML Data Push:

Attribute

Permitted Values

priority1

Critical, Important, High, Normal

Sets the priority of the push (X in the above example), which determines how and when the URL is requested. Priority must be all lower case: priority. The value must have single quotes (`).

text

Text in HTML format

Any text (Y in the above example).

volume

0 to 100

Cisco Wireless Phone 800 Series Developer’s Guide 31

Use Event Notifications

Web Development

Attribute

Permitted Values

Sets an override volume for any custom alert tone embedded in the page. (See PolyUri for more information on custom embedded alert tones.) Volume must be all lower case: volume. The value must have single quotes (`).

1 If attribute is absent, Normal is used.

Note The order of the priority and volume setting must adhere to the order shown in the example with priority first, followed by volume. Also note that the volume value must have quotes and the priority value must have single quotes.

Note Tags must be defined under a root tag: · Data must have a capital D: Data · Volume must be all lower case: volume · Priority must be all lower case: priority

Note Push URL and Push Data requests follow the same priority described in HTTP Push Table: How Priority Affects URL and HTML Push Requests.
Note When performing a data push, any referenced CSS files must be an absolute path. Therefore, with a data push, the serverRoot URL is not included in the CSS file path.
Example: To push the display of an important message:

Cisco Wireless Phone 800 Series Developer’s Guide 32

Web Development

Viewing a Personal Alarm Event

For example, using a combination of events and phone state polls can allow an application to detect that a phone has registered with the call server (Line Registration Event) and then get the phone’s extension number, model # and firmware version (Device Info phone state poll). The phone can be configured to send information to a specific URI if one of the following Event Notifications occurs:
· Personal Alarm Event
· Incoming Call Event
· Outgoing Call Event
· Offhook Event
· Onhook Event
· Call State Change Event
· Line Registration Event
· Line Unregistration Event
These events are XML data posted to a Web server by the phone.
Note If you have configured a second registration for use by your application, you may use the parameter to return information to differentiate the line.
Note The header tag in the XML that identifies a Cisco Wireless Phone event notification is not present in the event notification responses.
Viewing a Personal Alarm Event
The Alarm Event can be used by a security application to record, track or otherwise manage an alarm event that has been triggered by the SAFE application. Alarm events occur when Running, Tilt, and No movement alarms are triggered and when Panic button (duress) calls are made. Use the following format when viewing the alarm event:

Cisco Wireless Phone 800 Series Developer’s Guide 33

Viewing a Personal Alarm Event

Web Development

Table 9: Alarm Notification Event Attributes

Attribute

Permitted Values

Phone IP

IP address

IP address of the phone. For example
172.24.128.160

Cellular IP (96-Series only)

IP address

Cellular IP address of the LTE phone if a working SIM card is installed.

Note

In a Wi-Fi environment, the phone will not “know” its cellular IP address until it needs to use

LTE. Therefore, disable Wi-Fi to allow the phone to find the LTE network. The Cellular IP

address will become available at that point and continue to be used when needed.

MACAddress

MAC Address

MAC address of the phone. For example:
00907a0e0f37

BSSID

MAC Address

The MAC address of the AP the phone is currently using.

Still Alarm

0 = no alarm, 1 = alarm

The current state of this alarm detector.

Tilt Alarm

0 = no alarm, 1 = alarm

The current state of this alarm detector.

Running Alarm

0 = no alarm, 1 = alarm

The current state of this alarm detector.

Duress Alarm

0 = no alarm, 1 = alarm

The current state of this alarm detector.

LineNumber

0 or 1

Returns 1 if an emergency call number is configured and 0 if no emergency call number is configured.

TimeStamp

time

The date and time that the event occurred on the phone. For example:
2013-05-11T13:19:53-08:00

Latitude

Current coordinates obtained from GPS Na for Wi-Fi (no GPS)

Cisco Wireless Phone 800 Series Developer’s Guide 34

Web Development

Viewing an Incoming Call Event

Attribute

Permitted Values

LTE only (96-Series only)
example 40.02565302689416

Longitude

Current coordinates obtained from GPS Na for Wi-Fi (no GPS)

LTE only (96-Series only)
example: -105.22406386251863

Viewing an Incoming Call Event
The Incoming Call Event can be used by an application to send metadata about the call to the phone in real time, or to allow the application to detect that the user of the phone is busy.
Use the following XML format when viewing the incoming call event:

Attribute

Permitted Values

Phone IP

IP address

IP address of the phone. For example
172.24.128.160

Cellular IP (96-Series only)

IP address

Cellular IP address of the LTE phone if a working SIM card is installed.

MACAddress

MAC Address

MAC address of the phone. For example:
00907a0e0f37

CallingPartyName

name

Cisco Wireless Phone 800 Series Developer’s Guide 35

Viewing an Outgoing Call Event

Web Development

Attribute

Permitted Values

The name displayed in phone’s `From’ label in screen. If the line is registered and the call is initiated from that line, then the registered line display name of the calling party is shown. If the line is not registered and the call is initiated from that line, then IP address of the calling party is shown. For example:
sip:172.24.128.160

CallingPartyNumber

number

The number displayed on the phone. If the line is registered and the call is initiated from that line, the registered line number of the calling party is shown. If the line is not registered and the call is initiated using IP address from that line, the IP address of the calling party is shown.

CalledPartyName

name

The name displayed in phone’s To label on screen. If the call is received by a registered line, the registered line display name of the called party is shown. If the call is received on a non registered line, the IP address of the called party is shown.

CalledPartyNumber

number

The number displayed on the phone. If the call is received by a registered line, the registered line number of the called party is shown. If the call is received on a nonregistered line, the IP address of the called party is shown.

LineNumber

1 or 2

Returns 1 for SIP registration 1 and 2 for SIP registration 2.

TimeStamp

time

The date and time that the event occurred on the phone. For example:
2013-05-11T13:19:53-08:00

When the event notification URI is set and the incoming call event is enabled to gather information, the following example shows the transmitted data for a call between one registered and one unregistered line:

Viewing an Outgoing Call Event
The Outgoing Call Event can be used by an application to detect that the user of the phone is busy in a call.
Use the following XML format when viewing the outgoing call event:

Attribute

Permitted Values

Phone IP

IP address

IP address of the phone. For example
172.24.128.160

Cellular IP (96-Series only)

IP address

Cellular IP address of the LTE phone if a working SIM card is installed.

MACAddress

MAC Address

MAC address of the phone. For example:
00907a0e0f37

CallingPartyName

name

The name displayed in phone’s From label in screen. If the line is registered and the call is initiated from that line, then the registered line display name of the calling party is shown. If the line is not registered and the call is initiated from that line, then IP address of the calling party is shown. For example:
sip:172.24.128.160

CallingPartyNumber

number

The number displayed on the phone. If the line is registered and the call is initiated from that line, the registered line number of the calling party is shown. If the line is not registered and the call is initiated using IP address from that line, the IP address of the calling party is shown.

CalledPartyName

name

The name displayed in phone’s To label in screen. If the call is received by a registered line, the registered line display name of the called party is shown. If the call is received on a nonregistered line, the IP address of the called party is shown.

CalledPartyNumber

number

The number displayed on the phone. If the call is received by a registered line, the registered line number of the called party is shown. If the call is received on a nonregistered line, the IP address of the called party is shown.

LineNumber

1 or 2

Returns 1 for SIP registration 1 and 2 for SIP registration 2.

Cisco Wireless Phone 800 Series Developer’s Guide 37

Viewing a Call State Change Event

Web Development

Attribute

Permitted Values

TimeStamp

time

The date and time that the event occurred on the phone. For example:
2013-05-11T13:19:53-08:00

When the event notification URI is set and the incoming call event is enabled to gather information, the following example shows the transmitted data for a call between one registered and one unregistered line:

Viewing a Call State Change Event
The Call State Change event notifies the application of the different call states that can exist on the phone.
Use the following format when viewing the call state change event:
<CallStateChangeEvent CallReference=” ” CallState=” “>

Attribute Phone IP IP address of the phone. For example
172.24.128.160

Permitted Values IP address

Cisco Wireless Phone 800 Series Developer’s Guide 38

Web Development

Viewing a Call State Change Event

Attribute

Permitted Values

Cellular IP (96-Series only)

IP address

Cellular IP address of the LTE phone if a working SIM card is installed.

MACAddress

MAC Address

MAC address of the phone. For example:
00907a0e0f37

LineNumber

1 or 2

Returns 1 for SIP registration 1 and 2 for SIP registration 2.

TimeStamp

time

The date and time that the event occurred on the phone. For example:
2008-07-11T13:19:53-08:00

CallReference

number

A unique identifier for a call.

LineKeyNum

1, 2 or 4

Used in polling to determine which registration is responding or if IP dialing has been used. Returns 1 for SIP registration 1 and 2 for SIP registration 2. Returns 4 for IP dialing.

LineDirNum

phone number

Phone number associated with line. For example:
1234

LineState

OK,
[any value that is not “OK” indicates a registration error that will be specific to the PBX.]

The line state.

CallState

Outgoing call states: Setup, RingBack Incoming call states: Offering Outgoing/Incoming call states: Connected, Disconnected CallConference, CallHold, CallHeld, CallConfHold, CallConfHeld

The call state.

CallType

Incoming, Outgoing

Cisco Wireless Phone 800 Series Developer’s Guide 39

Viewing a Call State Change Event

Web Development

Attribute

Permitted Values

The call type.

UIAppearanceIndex

string

The call appearance index. This number simply shows the order of the call appearance on the display.

CalledPartyName

name

If the line is registered, the value is the registered line display name. If the line is not registered, the value is the IP address of the called party.

CalledPartyDirNum

number

If the line is registered, the value is the registered line number. If the line is not registered, the value is the IP address of the called party.

CallingPartyName

name

If the line is registered, the value is the registered line display name. If the line is not registered, the value is the IP address of the calling party.

CallingPartyDirNum

number

If the line is registered, the value is the registered line number. If the line is not registered, the value is the IP address of the calling party.

CallDuration

number, seconds

The duration of the call.

Call State Change example of offering state for line 2

Cisco Wireless Phone 800 Series Developer’s Guide 40

Web Development

Viewing a Line Registration Event

Viewing a Line Registration Event
The Line Registration Event fires whenever a phone registers one of its lines to a call server. This can be used for a number of purposes but is a useful event flagging the fact that the phone is up and running on the network. Note that this event is only sent at the first registration and not when the phone refreshes an existing registration.
Use the following XML format when viewing the outgoing call event:

Attribute

Permitted Values

Phone IP

IP address

IP address of the phone. For example
172.24.128.160

Cellular IP (96-Series only)

IP address

Cellular IP address of the LTE phone if a working SIM card is installed.

MACAddress

MAC Address

MAC address of the phone. For example:
00907a0e0f37

LineNumber

1 or 2

Returns 1 for SIP registration 1 and 2 for SIP registration 2.

TimeStamp

time

The date and time that the event occurred on the phone. For example:
2013-05-11T13:19:53-08:00

Example of line registration event: LineNumber 1

Attribute

Permitted Values

Phone IP

IP address

IP address of the phone. For example
172.24.128.160

Cellular IP (96-Series only)

IP address

Cellular IP address of the LTE phone if a working SIM card is installed.

MACAddress

MAC Address

MAC address of the phone. For example:
00907a0e0f37

LineNumber

1 or 2

Returns 1 for SIP registration 1 and 2 for SIP registration 2.

TimeStamp

time

The date and time that the event occurred on the phone. For example:
2013-05-11T13:19:53-08:00

Example of line unregistration event: LineNumber 1

Cisco Wireless Phone 800 Series Developer’s Guide 42

Web Development

Viewing a Login/Logout Event

Example of line unregistration event: LineNumber 2

Viewing a Login/Logout Event
The Login/Logout Event can be used by the Biz Phone app when SIP is enabled and there are multiple users using the same phone and each has a different extension at the same SIP server address. To use the phone, each user must login by entering unique credentials in a popup window. This is the Login event. A Logout option is provided in the app menu. Tap Logout to end the session and the Logout event is captured.
Use the following format when viewing the Login/Logout event:
<UserLogInOutEvent