empower embedded. +1 416 621 0125 pre release release notes · an ats status query command. this...

PROPRIETARY AND CONFIDENTIAL – RELEASED UNDER LICENSE 1

PRE RELEASE

Release Notes

DATE August 11, 2009

HARDWARE uC53281-EVM rev 1.2 (MCF53281)

DEPENDENCIES Device must be running software version 1.0.2r224 Reset to factory defaults required after software upgrade

BINARY FILES THIS IS A BINARY TEST CANDIDATE TEST CANDIDATE IS AVAILBLE FOR uC53281 rev 1.2 HARDWARE ONLY Firmware Binaries (with MD5 header checksum - for webUI upload): pmd5x-120225.82 – uC53281-EVM rev 1.2 (MCF53281) Firmware Binaries (without MD5 header checksum - for TFTP or serial upload): partx-120225.82 – uC53281-EVM rev 1.2 (MCF53281)

SOFTWARE VERSONS

1.0.2-pre225.82

RELEASE TYPE TEST CANDIDATE – PRE RELEASE

DEVICE SETTINGS DEFAULT

LAN IP ADDRESS DHCP CLIENT

USER LOGIN admin

USER PASSWORD admin

OTHER

IMPORTANT NOTE – VERIFY PROCESSOR VERSION: MCF53281 SOFTWARE WILL NOT RUN ON PCF53281 PROCESSOR PARTS – DEVICE WILL BECOME INOPERABLE!

Arcturus empower embedded. [email protected]

+1 416 621 0125


1. SUMMARY This firmware load (BINARY PRERELEASE) is the current load under test and includes the following major improvements from the previous release. (see detail section for more information)

August 11, 2009 .....................................................................................................................................1

1. SUMMARY .......................................................................................................................................2

2. INSTALLATION INSTRUCTIONS ....................................................................................................3

3. DETAIL .............................................................................................................................................3

3.1 Management Middleware API Enhancements ....................................................................................3

3.1.1 Management Middleware STATUS Feature .................................................................................3

3.1.2 Shell Script Example Implementation ...........................................................................................4

3.2 Voice and Media Middleware API Enhancements ...............................................................................4

3.2.1 API Progress Message Enhancements ........................................................................................4

3.2.2 API Command Status Enhancements ...........................................................................................5

3.2.3 Feature Magic Enhancement for Enable / Disable Call Waiting ...................................................6

3.2.4 API Timing and Messages ............................................................................................................6

3.3 Broadcast and Mass Notification Software Module Enhancements ....................................................7

3.3.1 Broadcast API Message Enhancements.......................................................................................7

3.3.2 Broadcast Last in Wins Support and Priority.................................................................................7

3.3.2.1 Expected Behavior – Broadcast Listener ...................................................................................7

3.3.2.2 Expected Behavior – Broadcast Sender ....................................................................................8

3.3.2.3 Limitations ..................................................................................................................................8

3.4 NTP Behavior Change .........................................................................................................................8

3.4.1 MSNTP Usage ..............................................................................................................................9

3.4.2 XML Start Script ............................................................................................................................9

3.4.3 Starting MSNTP ............................................................................................................................9

3.4.4 Expected Behavior ........................................................................................................................9

3.4.5 Limitations .................................................................................................................................. 10

3.4.6 Configuring DHCP to Deliver NTP Server Information .............................................................. 10

3.5 Diagnostic Tool Support .................................................................................................................... 10

3.6 LCD Demo Resolution Increase ....................................................................................................... 11

3.7 Additional Notes ................................................................................................................................ 11

4. FEATURE OPERATION ................................................................................................................ 13


2. INSTALLATION INSTRUCTIONS Three firmware files have been provided pmd50, pmd51, pmd52. To install: 1. unzip files. 2. log into the device web page by following the instructions in the Getting Started Guide

2.1. connect device to network with DHCP 2.2. press button 3 to hear IP address of device through headset 2.3. enter IP address into URL line of web browser 2.4. login: admin / password: admin

3. select the ADMIN tab page 4. select FIRMWARE 5. repeat until all three files are uploaded (pmd50, pmd51, pmd52).

3. DETAIL

3.1 Management Middleware API Enhancements

3.1.1 Management Middleware STATUS Feature

The management middleware API has been extended to support a STATUS feature that enables an application or script to read the status of a file and determine the condition on the middleware engine

(mibd). If the file does not exist then the middleware engine is not running or is not in a running state.

An example shell implementation script is provided below that checks for the PID (process ID) of mibd to

confirm it has been started and then checks the mibd.status file and report the condition. This

implementation example may be modified to run in a while loop or built into an application to determine normal operation of the system after initialization and act as a launch point for execution.

The mibd.pid file is created before the main processing loop of the mibd application. The file contains

the process id of the application. On exit the file is removed. This is done by a routine that is registered

by the the atexit() function.

The file location: /var/run/mibd.pid files:

The mibd.status file is created before the main processing loop of the mibd application. The file has

two valid flags that are written to this file. They are INIT and RUNNING in both cases the status word is terminated by a "\n". The location: /var/run/mibd.status


mibd.status file Condition Description

File does not exist - no status is currently available the application is not running or not in a running state

INIT\n - mibd is initializing its data base files. - occurs at start up and at any time that mibd has been signalled to rebuild or update its database files.

RUNNING\n mibd is running

3.1.2 Shell Script Example Implementation

The example shell script below tests to see if mibd has been started (test for mibd.pid) and looks for

the mibd.status file.. If mibd is not running (has no PID) the script will exit. If mibd is running (has a

valid PID) and has written its status file then the script returns the contents of the status file. If mibd is

running and no status then the script will report “mibd is not reporting status”

#!/bin/bash

if -s [ /var/run/mibd.pid ] ; then

# mibd has written a PID so it has been started

if -s [ /var/run/mibd.status ] ; then

# mibd has written a STATUS

read status < /var/run/mibd.status

echo "mibd Status is $status

else

echo "mibd is not reporting status"

fi

fi

3.2 Voice and Media Middleware API Enhancements The voice and media middleware API has been extended to provide more progress messages as well as

an ats status query command. This allows application developers to maintain better state

synchronization between the middleware and applications.

3.2.1 API Progress Message Enhancements

API Progress Messages

Description Note

[REJECT] Call Has Been Rejected The progress message [Rejected] is sent from the middleware under the following conditions 400 and 500 class failure messages with the exception 401 and 407 Authentication Challenges

[HANGUP] Please Hang Up The [HANGUP] progress message is sent from the


announcement is Playing

middleware when the Please Hang Up announcement is playing. The Please Hang Up announcement precedes the howler tone on calls where the far-end has disconnected or the call has been off-hook idle with no call connected for at least 30 seconds.

[HANGUP HOWLER]

Howler Tone is playing The [HANGUP HOWLER] progress message is sent from the middleware when the Howler Tone is playing. The Howler Tone occurs after the Please Hang Up announcement has played for 60 seconds

[DTMF=n]

DTMF in RTP Receive Output

When enabled using the ats90 mode selection

DTMF digits received in RTP event packets (not in-band audio) will get output as a messages using

the DTMF=n format where n is the DTMF digit.

DTMF digits may be transmitted during a call using

the normal atd <n> functions. A related DTMF

configuration option must be configured to support DTMF in RTP.

[CONNECT] [NO CARRIER]

Announcement The play announcement file that uses feature code

atd **79<0..9> and the record announcement file

that uses **78<0..9> now supports standard

progress messages CONNECT to indicate the start

of playback or record and NO CARRIER to indicate

the end-of-playback-file or to confirm the termination of a recording as an acknowledgment to a hangup (ath) command.

In either case the NO CARRIER indicates the

system has returned to idle.

3.2.2 API Command Status Enhancements

API Command Description Note

ats105 Hook State The hook state status provides a method to query the condition of the telephony system. The ats105 command will return 0 = on-hook 1 = off-hook

ats90=<1-3>

DTMF display digit output enable/disable

1 – Display Digit ON 2 – Display Digit OFF 3 – Display Digit ON with locals tones OFF 4 – Echo Digits such as speed dials to ATCMD as DTMF= 5 – Echo Digits with Tones 6 – Echo digits without tones


3.2.3 Feature Magic Enhancement for Enable / Disable Call Waiting

Feature magic is a 16 bit configuration parameter in which each bit represents a feature. Feature magic is used to control low-level signaling and call handling primarily for interoperability or device setup. The binary Feature Magic number is represented by a decimal equivalent value and is stored as a field in the MIB account table MIB-254.11.1.1. Feature Magic may be configured using the API, command line client, provisioning or web UI. The reference implementation under the web UI VoIP account page contains a Feature Magic field that, when clicked will redirect to the ADVANCED options page. This page contains a tool that enables the configuration of the individual Feature Magic settings. Feature Magic supports the configuration of:

Signaling Overlay – type of signaling interoperability model to use

SIP Tag Length – the number of characters to be used in the SIP hash tag

Digit Padding – the ability to pre-pend 1+nnn (where nnn is the telephone area code if not over written by the default area code field)

Conference Mixing – Mix 3way calling locally on the device or refer to a conference server (if supported)

Ptime compensation – try to force negotiation of 20mS codec ptime (legacy)

SIP Ping – use the SIP ping method of firewall traversal (Nortel® specific)

REPLACES in REFER – use the REPLACES method of call transfer

Disable Robust signaling – Disable the fast successive ACKs

Fall Back To G.711 – Always list G.711 in the codec preference order even when not explicitly specified in the codec list

Disable Call Waiting – see note below

Configurable Parameter Description Note

Disable Call Waiting Feature Magic A feature magic number has been added to enable or disable call waiting persistently on the device. This can be useful for devices operating in intercom or broadcast mode where no user intervention is available to switch between calls. The disable call waiting feature will respond with BUSY messages to incoming INVITES if the telephony system is already in use.

0x8000

32768

Feature magic is contained as a field in the MIB account table MIB-254.11.1.1 and may be configured using the API, command line client, provisioning or web UI. The web UI VoIP account page contains a Feature Magic field that, when clicked will redirect to the ADVANCED options page. This page contains a tool that enables the configuration of the individual Feature Magic settings.

3.2.4 API Timing and Messages

In previous releases of the firmware, under varying system loads, API messages could provide premature system condition information. In previous firmware versions it could be possible for an application to issue a command in response to an API message and have the command be accepted by an OK, but ignored. A delay was required by the application prior to issuing the command. Optimizations have been made to improve accuracy of the API message conditions to ensure that DOWN/UP, NO CARRRIER messages may be interpreted as conditions of readiness with the noted exception below:


When autohangup is enabled, a minimum 200 mS delay must be inserted after a "NO CARRIER" response in order for the on-hook operation to complete before the next command is issued. Failure to insert the delay "may" result in the hangup occurring after the next command is issued.

3.3 Broadcast and Mass Notification Software Module Enhancements

3.3.1 Broadcast API Message Enhancements

The Broadcast and Mass Notification Software Module has been extended to provide better integration with API progress messages. Developers can use the additional messages to determine when broadcasts start and stop as well as receiving information about the broadcast group.

API Progress Messages Description Note

[CONNECT BROADCAST RX : <GROUP>]

Broadcast Connect Message

The broadcast connect message provides notification that a broadcast is being received and played from a subscribed broadcast <group>. The broadcast connect message will appear only for subscribed groups and only when the system is a condition to play the broadcast or if the broadcast is a higher priority than the existing operation on the device and thus cutting in.

[CONNECT BROADCAST TX<GROUP>]

Broadcast Transmit Message

The broadcast transmit message indicates that a broadcast is being transmitted on the broadcast <group>

[NO CARRIER BROADCAST RX]

End of Broadcast Message

Indicates the completion of the broadcast. (normally or by error)

[NO CARRIER BROADCAST TX]

End of Broadcast Message

Indicates the completion of the broadcast transmission. (normally or by error or by interrupt of equal or greater priority transmission on the same broadcast group)

[REJECT : NOT MEMBER OF GROUP <GROUP>]

Error Error indicating an attempt to transmit on a group without permissions.

3.3.2 Broadcast Last in Wins Support and Priority

The last in wins support is designed to allow for multiple broadcast senders to co-exist on the same system in a managed way. It takes into consideration “stuck mic” situations where one broadcaster could dominate a channel and all group.

3.3.2.1 Expected Behavior – Broadcast Listener

Broadcast listeners that are subscribed to one group will automatically switch and listen to the newest broadcast sender on that group.

Broadcasts listeners subscribing to several groups will automatically switch and listen to the newest broadcast sender on the groups they are subscribed to.

Broadcast listeners subscribed to multiple broadcast groups will automatically revert and listen to a previous broadcast.

A broadcast listener may hangup on an existing broadcast and start a subsequent broadcast (if configured).


3.3.2.2 Expected Behavior – Broadcast Sender

A broadcast sender may interrupt a broadcast in progress by sending on the broadcast group.

Broadcast senders sending on a group will be interrupted and the broadcast will be stopped by a subsequent broadcast on the same broadcast group.

A broadcast sender, sending on group and subscribing to a subsequent broadcast will have their broadcast terminated and will automatically begin to listen to the subsequent broadcast group

Broadcast senders will automatically revert and listen to a previous broadcast upon completion of their broadcast.

3.3.2.3 Limitations

Switching transitions will take longer when concurrent multiple priority broadcasts occur using the same IP channel and port. It is recommended wherever possible to isolate frequently used broadcast groups into a unique IP channel and port.

Broadcast announcement tones are synchronized and maybe truncated or lost during a broadcast switching transition. Short announcement tones should not be relied up during switching transitions. Long tones should be used for applications that require critical announcement tones. Refer to the VMM_Broadcast_Module.pdf documentation for information on mcpaging.conf file

A broadcasts listener subscribing to multiple broadcast groups, listening to a broadcast in progress and interrupted by a broadcast on a second broadcast group may experience momentary audio loss during CONTINUE messages from the first broadcast group. It is recommended wherever possible to isolate frequently used broadcast groups into a unique IP channel and port or terminate the original broadcast.

3.4 NTP Behavior Change NTP is the network time protocol and changes to the expected behavior have been made. A description of the updated behavior is described below. NTP is required by the OS and middleware for a variety of functions including VoIP signaling. An accurate time source is a requirement for correct operation. The software package used is MSNTP. NTP is a client / server protocol designed to standardize time across a network. The purpose of NTP client is to connect to an upstream clock reference in order to obtain accurate time. NTP has built in algorithms that will check the trust of the clock reference as well as coalesce accurate time over a period. NTP server responds to client requests and provides time reference. The NTP client relies on a remote NTP server to respond to NTP requests and synchronize time. The system contains 5 predefined NTP servers and offers the user or service provider the ability to add NTP servers as required, through provisioning or the web UI. NTP servers may contain domain names providing a valid DNS is available at the time of the NTP request. It is expected service providers will want users to be able to set local NTP servers and as such, the user exposed setting will over-ride the default values; however, it is also expected that service providers will want time to be synchronized regardless of whether the user defined NTP server become unavailable. Therefore, if no NTP value is entered by the user (or defined within provisioning), the device will use the default NTP servers. If the user enters a value (or they are provisioned), then the system will pre-pend these to the list in the following order; user defined server-1 , pre-defined server-2 , predefined server-3. Multiple servers can be added through provisioning or the web UI by using a space delimited format. It is not recommended to add more than three additional servers. Predefined Public Stratum-1 NTP Servers

192.5.41.40 U.S. Naval Observatory

192.5.41.41 U.S. Naval Observatory

128.252.19.1 Washington University


209.81.9.7 VIA.net

18.26.4.105 MIT

3.4.1 MSNTP Usage

MSNTP is run as in client Daemon mode and is started with the following parameters (see example below). msntp -r -P no -x 192.168.1.110 192.5.41.40 192.5.41.41 128.252.19.1

209.81.9.7 18.26.4.105

Usage Description

-r sets the system time

-P allows for a large difference between the current system date/time and the response from the queried NTP server to be accepted. Normally, MSNTP restricts the change difference.

-x goes into daemon mode with the default NTP query time of 300 minutes

<ipaddress> IP address / name / [NULL] - this name / parameter comes from the MIB subsystem (MIB-254.8.14) - only set from the GUI interface or a provisioning script

<ipaddress> IP address(es) returned from DHCP server for NTP servers - kept in a MIB table (MIB-254.2.6.9.*.1)

<ipaddress> <ipaddress>..

Hard coded IP addresses of 5 Internet NTP servers

& background mode

3.4.2 XML Start Script

The script that starts MSNTP is start-254.8.4-HUB. This script kills any running versions of MSNTP

first. The template for the start script is located in in /etc/conf. MIBXML processes the template, filling in

any XML values a located the executable script output in RAM disk /var/conf/start-254.8.4-HUB.

3.4.3 Starting MSNTP

There are a number of triggers / ways which can cause the MSNTP start script to be run:

every five minutes, cron runs an application checker (app_check). If app_check determines that the MSNTP daemon is not running, the MSNTP start script is run.

The scripts that runs after a DHCP lease has been obtained, can cause the MSNTP start script to be run for various reasons.

Changes to MIB-254.8.4 will also trigger the MSNTP start script to be run. This is usually modified by the GUI interface (NTP Time Server:)

3.4.4 Expected Behavior

MSNTP will issue an NTP request to the 1st NTP server in the command line list. If the start script is not run before 300 minutes has elapsed, MSNTP will query the second NTP server in the command line list. Every 300 minutes the next NTP server in the command line list will be queried. When the list is


exhausted, MSNTP will restart at the beginning of the list. This assumes that any of the above mechanisms to start MSNTP have not run during this period.,

3.4.5 Limitations

The following is a list of know limitations of the application package MSNTP. Possible modifications to MSNTP to allow a local NTP server to be queried during "temporary" Internet / WAN interruptions is being investigated for a future release.

If a DNS Server does not exist on the network, MSNTP will never set the time.

NTP server names starting with a digit will not currently properly be resolved.

If none of the names / ip addresses of the NTP servers listed on the command line can be resolved, MSNTP will never set the time.

- a DNS request for a name must return the IP address - a DNS request for an IP address must return the Fully Qualified Domain Name (FQDM)

Only NTP servers with a successful DNS response ([2]) will ever be sent a NTP request from MSNTP. NTP servers with a DNS response of "not found" will be removed from MSNTP’s list of NTP servers.

If none of the NTP servers on the MSNTP command line are valid or receive DNS responses, MSNTP will fail

If the DNS server responds with a "server failure", MSNTP will continue to try to validate it’s command line list of NTP servers.

- NOTE: MSNTP will not send an NTP request until all the servers have either a DNS response with "not found" or a successful DNS response is returned. Depending on the DNS server’s configuration, a "server failure" may be returned from a DNS server if it’s upstream DNS server is inaccessible. In standard networks this might be a temporary condition which should get resolved; however, if a network is isolated from the Internet, it is possible that MSNTP will continuously try to validate it’s NTP server list WITHOUT ever issuing a NTP request to get the time.

- NOTE: If any of the NTP servers in the MSNTP command line result continues to cause a response of "server failure", MSNTP will stay in the validation loop.

3.4.6 Configuring DHCP to Deliver NTP Server Information

To set up the DHCP client to request the DHCP server for a list of NTP Servers you can enable the options

004 time_servers

042 ntp_servers

by adding the following lines to the default /etc/conf/dhcpcd.conf file: options ntp_servers

options time_servers

3.5 Diagnostic Tool Support A button has been added to the Web UI ADMIN tab page /DIAGNOSTIC that captures diagnostic information in a plain text file. This information includes details about the current operation of the device including:

DNS Resolver

DHCP Client In formation

Phone Application Conf File

Phone Application Conf file hash

System Log

OS Process List

Management Database and Environment


Firmware Version and Partition Information The script is implemented in the source HTML and may be modified freely using the distribution

3.6 LCD Demo Resolution Increase The default resolution of the LCD demo has been increased from 320 x 240 to 640 x 480. The demo is freely available and source is located in the distribution.

user/microwin/src/demos/nxmasscontrol

A document on operation and features is available on the support site:

LCD/Broadcast_Module_Demo_Guide.pdf

3.7 Additional Notes

Additional Notes

Note Description Comment

1 Build Release Verification This build was initially tested for DEMONSTRATION PURPOSES ONLY using the VONAGE network

2 VoIP Accounts Page Fields The Following Fields MUST be completed: Phone Number / UID Authenticated User Authenticated Password Domain Realm SIP Proxy with port number eg xxx.xxx.xx.xx:5060 SIP Port RTP/ LAN Feature Magic:

3 DNS Required A valid and reachable DNS is required for the proper operation of this device.

4 Reset Button (GPIO-1) The reset button will reset the GUI password and LAN network settings when held in for 6 seconds during power cycle.

5 Speed Dials – Change in Behavior

Since prior to release 224 speed dials may no longer be used to override the digit map and call blocking restrictions. In release 224 and later, changes to the digit map were made to allow for feature codes to be used in speed dial settings, allowing for **nnnn, functions to be programmed as speed dials.

6 Telnet Enabled on engineering releases

7 IM features Send File, Share Whiteboard and Transfer Whiteboard SIP messages not supported for Nortel MCS. IM Not supported under Vonage

8 Watchdog Watchdog reset not enabled on engineering releases - device will halt on exception

9 Syslog Verbose logging enabled on engineering releases

10 Firmware Upload Blank Status Page During Firmware Upgrade due to timeout or network lease delay

11 *70 Cancel Call Waiting Outstanding bug reported on this issue. The work


around is to enable or disable CW using the feature magic as described in section 3.2.3. This issue will be fixed in the next release.

12 Possible Feature Conflict: Auto-Hangup/Call Waiting

Under certain call flows with auto-hang up enabled AND while maintaining two concurrent calls using the call waiting feature it is possible for a held call termination to cause the termination of both the call the progress and the held call. This is a proxy dependent issue. The work around for this is to test for this feature conflict and choose to use either auto-hangup or call waiting feature.


4. FEATURE OPERATION

Digit Map/Dial Plan Definitions

Digit Map Keys Pressed Last Action Result

*nn Timer or Pound Dials Out

*nnn… Timer or Pound Dials Out

#n Timer or Pound Dials Out

11nn Timer or Pound Dials Out

0 Timer or Pound Dials Out

00 Timer or Pound Dials Out

(2-9)11 Immediate Dials Out

nn Timer or Pound Dials Out

(1-9)nnn… Timer or Pound Dials Out

011nn… Timer or Pound Dials Out

(2-9)nn-nnnn Timer or Pound Dials Out

(2-9)nn-nnn-nnnn Immediate Dials Out

0(2-9)nn-nnnn Timer or Pound Dials Out

0(2-9)nn-nnn-nnnn Timer or Pound Dials Out

1nnn-nnn-nnnn Immediate Dials Out

[1…9] 1 Digit Entered Pound Key Speed Dials

NOTE: THE LOCALLY SUPPORTED VSC TABLE BELOW SUPERCEDES DIGITMAP

IVR Commands

Code Description Action/Note

[**00] Announces the current phone number.

[**69] Announces the caller-ID from the last caller.

*69 local IVR support disabled in this build

[**98] Announces the WAN IP Address In the even the device has not received a DHCP lease, the device will produce a “placeholder” consisting of the last least received.

[**99] Announces the LAN IP Address Use the LAN IP to access Web UI

[**ADMIN] [1] <IPaddress> [#]

Initial Provisioning Address Enter * delimited IP address of provisioning server followed by pound key


Locally Supported Vertical Service Codes

Code Description

[*123 / *98] Connect to voicemail (where available)

[**67] Outgoing Caller-ID Block (per call)

[**82] Enable Outgoing Caller-ID (per call override block from webUI)

[*70] Call Waiting Disable for current call

[*78] Do Not Disturb – Enable

[*79] Do Not Disturb – Disable

[*77] Reject Anonymous Calls – Enable (per session feature)

[*87] Reject Anonymous Calls – Disable

[**77<0..9>] Plays file <0..9> { announce("/usr/etc/user_file<0..9>.ul"); }

File encoding for these fiels is 8kHz G.711 uLaw

[**78<0..9>] Records to file <0..9> using 8kHz G.711 uLaw file encoding. { recfile("/var/recfile<0..9>"); }

Returns CONNECT when recording

use ath command to terminate

Returns OK

NO CARRIER

[**79<0..9>] Plays file <0..9> { playfile("/var/recfile<0..9>"); }

Returns CONNECT when playing

Returns NO CARRIER when complete

Returns BUSY, NO CARRIER when invalid

Use ath command to terminate

File encoding for these files is 8kHz G.711 uLaw Returns: CONNECT

NO CARRIER

(hangs up automatically)

[**30<0..99>] Start Broadcast on channel <0..99>

use ath to terminate broadcast

[Flash], [#90], <transfer number>

Unattended Call Transfer. See detailed instructions below

[Flash], [#91], <transfer number>

Attended Call Transfer. See detailed instructions below

BUSY [**5] Redials busy number at 30 second intervals for 20 minutes. Successful call completion will ring the local phone. See instructions below.

Unattended Call Transfer: 1. During a live call press FLASH 2. Wait for dial tone, press #90 3. Wait for dial tone, dial destination number 4. Wait for announcement, hang up phone


Attended Call Transfer: 1. During a live call press FLASH 2. Wait for dial tone, press #91 3. Wait for dial tone, dial third party 4. Announce call to third party 5. hang up to complete the transfer Redial on Busy: 1. Upon receiving a busy signal, dial **5 2. Wait for confirmation tone 3. Hang-up Redials busy number at 30 second intervals for 20 minutes. Successful call completion will ring the local phone.

Admin Codes

Code Description Action/Note

[**ADMIN] Enables Admin Mode eg **23646

[**ADMIN] [1] <IPaddress> [#]

Initial Provisioning via API Enter * delimited IP address of provisioning server followed by pound key eg **236461nnn*nnn*nnn*nnn

[**ADMIN] [9] <RESET> [#]

Reset to factory defaults Resets the device to factory default state eg **23646973738

Command Line VoIP Middleware API

Code Description Action/Note atcmd /atemul0 Enables Command Mode Attaches to SIP instance 0 atcmd AT command emulator. Attaches

emulator to console or terminal atemul<0> atemul device_id AT emulator daemon attach

command. Attaches emulator to to

SIP instance device_id

ata ata off hook – answer atd atd nnnnnnn

atd n# dials nnnnnnn

dials speed dial n # special terminator key ath ath Hangup atf atf flash hook att att n generates DTMF tone atR Force reset of telephony

application Forces the application to terminate immediately. The application will then restart and reload its configuration file

atr Signal reload of telephony application config file

Signals the application to restart and reload the configuration file as soon as the application has been on-hook for a minimum of 30 seconds

ats90=<1-3>

DTMF display digit output enable/disable

1 – Display Digit ON 2 – Display Digit OFF 3 – Display Digit ON with locals


tones OFF 4 – Echo Digits such as speed dials to ATCMD as DTMF= 5 – Echo Digits with Tones 6 – Echo digits without tones

ats91=<0..6>

ats91 0 is mute, 6 is max. - query using ats91 (return value is +1)

Persistent TX (microphone) level

ats92=<0..6>


Persistent RX (speaker) level

ats93=<0..6>


Non-persistent TX (microphone) level

ats94=<0..6>


Non-persistent RX (speaker) level

ats99 ats99 status query of attached SIP instance Returns; 0 – Line is not provisioned / Network NOT Available 1 – Line is REGISTERED 2 – Line is trying to REGISTER / Network Available

ats100 ats100 Hardware Revision ats101 ats101 Software Revision ats102 ats102 HostName ats103 ats103 Serial Number ats104 ats104 status query of MWI (message

waiting indicator) 0 – OFF 1 – ON

ats105 ats105 Status query of Hook state 0 – on-hook 1 – off hook

Q or q Exit quit emulator application and return to prompt

Progress Message State Description

OK: UP Application ready The signal indicates the application has completed a reset/reload and is ready for commands

ERROR: DOWN Application down The signal indicates that the application is going down.

OK Command Event Acknowledgment Response ERROR Command Event Invalid Command RING Incoming Call Incoming Call <no caller ID>

RING

DATE=mmdd

TIME=hhmm

NMBR=nnnnnnnnnnn

NAME=TEXT

Incoming Call / Call Display

Incoming call with caller ID


RINGING Outgoing Call Ringing at Destination (callee) CONNECT Incoming Call /

Outgoing Call / Play file Call is connected / Audio

WAIT Incoming Call While

CONNECTED Call Waiting

WAIT

DATE=mmdd

TIME=hhmm

NMBR=nnnnnnnnnnn

NAME=TEXT

Incoming Call While CONNECTED

Call Waiting with caller ID

NO CARRIER Call In Progress / Play File

Call Terminated / End of File / End of Broadcast

[DTMF=n] Call In Progress

When enabled using the ats90

mode selection DTMF digits received in RTP packets (not in-band audio) will get output as a messages using

the DTMF=n format where n is the

DTMF digit. DTMF digits may be transmitted during a call using the

normal atd <n> functions. A

related DTMF configuration option that must be configured to support DTMF in RTP.

BUSY Outgoing Call / Play File

Destination Busy / Not Available or File Does Not Exist / Not Allowed to Broadcast on Requested Group

REJECT Outgoing Call The progress message [Reject] is sent from the middleware under the following conditions: all 400 and 500 class failure messages with the exception 401 and 407 Authentication Challenges

HANGUP Off-hook / Not Connected

The [HANGUP] progress message is sent from the middleware when the Please Hang Up announcement is playing. The Please Hang Up announcement precedes the howler tone on calls where the far-end has disconnected or the call has been off-hook idle with no call connected for at least 30 seconds.

HANGUP HOWLER

Off-hook / Not Connected

The [HANGUP HOWLER] progress message is sent from the middleware when the Howler Tone is playing. The Howler Tone occurs after the Please Hang Up announcement has played for 60 seconds

CONNECT BROADCAST RX :

<GROUP>

Broadcast Connect Message

The broadcast connect message provides notification that a broadcast is being received and played from a subscribed broadcast <group>. The


broadcast connect message will appear only for subscribed groups and only when the system is a condition to play the broadcast or if the broadcast is a higher priority than the existing operation on the device and thus cutting in.

CONNECT BROADCAST TX

<GROUP> Broadcast Transmit Message

The broadcast transmit message indicates that a broadcast is being transmitted on the broadcast <group>

NO CARRIER BROADCAST

END <GROUP> End of Broadcast Message

The end of broadcast message indicates the termination of the broadcast on the specified <group>.

[REJECT : NOT MEMBER

OF GROUP <GROUP>] Error Error indicating an attempt to

transmit on a group without permissions.

GOODBYE Exit Exit of VoIP AT Command Set


FOR TECHNICAL SUPPORT PLEASE CONTACT:

ARCTURUS NETWORKS [email protected] SUBJECT TO CHANGE

empower embedded. +1 416 621 0125 pre release release notes · an ats status query command. this...

Documents