Stentofon AlphaCom E Quick Start Manual

Table of Contents 1. INTRODUCTION ................................................................................3 1.1. About this document .................................................................3 1.2. Terms and acronyms .................................................................3 1.3. Related documents ...................................................................3 1.4. SDK ...........................................................................................3 1.5. Publication log ...........................................................................3 2. API DESCRIPTION ............................................................................4 2.1. General Description ..................................................................4 2.2. DLL description .........................................................................5 2.2.1. Licensed features ..........................................................5 2.3. Communication with the AlphaCom E exchange ......................5 2.4. Remote connections .................................................................6 2.5. Connecting to the exchange .....................................................8 2.6. AlphaCom Data Protocol message classes ..............................9 2.7. Event reports .............................................................................9 2.8. Application synchronization ......................................................9 2.9. Sending commands to AlphaCom E .......................................10 2.10. API custom events ..................................................................10 2.10.1. OnCustomParameter event ........................................ 11 2.10.2. OnCustomString event ................................................ 11 2.10.3. Comparing the two OnCustom events ........................ 11 2.10.4. OnCustomParameter example ...................................12 2.11. Intercom station state ..............................................................12 2.12. Mail messages ........................................................................14 2.13. Call request .............................................................................14 2.14. Connect call ............................................................................15 2.15. Call connected ........................................................................15 2.16. Cancel call command ..............................................................15 2.17. Call disconnected ....................................................................15 2.18. Method to send ACDP messages ...........................................15 2.19. Other available events and methods ......................................16 3. SDK APPLICATION .........................................................................17 3.1. General ...................................................................................17 3.2. Stentofon.AlphaCom.Example.Stations ..................................17 3.2.1. Connection to the exchange .......................................17 3.2.2. Station selection and status ........................................17 3.2.3. Station commands ......................................................18 3.3. Stentofon.AlphaCom.Example.CallRequest ...........................19 3.3.1. Connection to the exchange .......................................19 3.3.2. Station selection and status ........................................19 3.3.3. Call Requests ..............................................................19 Zenitel Norway AS and its subsidiaries assume no responsibilities for any errors that may appear in this publication, or for damages arising from the information in it. No information in this publication should be regarded as a warranty made by Zenitel Norway AS. The information in this publication may be updated or changed without notice. Product names mentioned in this publication may be trademarks, they are used only for identification. Zenitel Norway AS, June 2010

A100K10674 V.2.0 INTRODUCTION 1. About this document 1.1. This manual is a ‘Quick Start’ guide for using the Application Programming Interface (API) for the STENTOFON AlphaCom E exchange. Detailed information can be found under ‘Related documents’. This document is intended for system integrators. ● Terms and acronyms 1.2. API – Application Programming Interface ● - A set of routines, data structures, object classes and/or protocols provided by libraries and/or operating system services in order to support the building of applications. SDK – Software Development Kit ● - A collection of programming tools, utilities, documentation, and libraries of functions or classes. SDK is a term popularized by Microsoft as in Windows SDK or Windows Media SDK. Related documents 1.3. �API�help�file:�� Stentofon.AlphaCom.AlphaNet.chm ● �API�help�file:�� Stentofon.AlphaCom.Data.chm ● �AlphaWiki:�� The�online�technical�documentation�centre�for�the ● AlphaCom E exchange AlphaWiki�can�be�accessed�from�the�API�help�file.�Users�outside�the� STENTOFON network must have a user name and password to access AlphaWiki. Please send an e-mail to [email protected] to request a user name and password. SDK 1.4. Zenitel provides an SDK to support application software developers. The�SDK�is�contained�in�the�file�‘Stentofon.AlphaCom.SDK.msi’.�The� following�files�are�part�of�the�SDK: �The�help�files�as�listed�in�section�1.3 ● �The�dll�files�described�in�section�2.2 ● 2 example applications which implement all concepts as described in ● the rest of this document plus the source code for those applications ● AlphaCom Service Provider as described in section 2.4 Chapter 3 describes the example applications in detail. Publication log 1.5. Version Date Modifications 1.0 2009.08.26 New document 1.1 2009.11.30 Added description of SendAlphaExecuteCommand 1.2 2009.12.15 SendAlphaExecuteCommand replaced by SendAlphaCommand Product name change to STENTOFON SDK 2.0 2010.06.01 Remote API capability added

API DESCRIPTION 2. General Description 2.1. STENTOFON AlphaCom E is a powerful communications exchange with many features directly applicable to the security industry such as direct calling, call requests and call queue handling, call transfers and escalation, PA functionality through All Call and Group Calls, priority calls and much more. The STENTOFON Application Programming Interface (API) is a set of routines, data structures, object classes and protocols. The API provides a high level interface for Windows applications and Web services to access STENTOFON AlphaCom E communication services. The STENTOFON Software Development Kit (SDK) API for the AlphaCom E exchange allows for a very close integration between the AlphaCom E exchange and security management systems. Internal exchange status information is reported by raising events, and commands can be sent into the exchange by calling the appropriate method. Some of the exchange features which are of particular interest for integration into security systems are described in this document. For more information about the functions supported by the underlying AlphaCom Data Protocol, please refer to AlphaWiki. The STENTOFON SDK API for AlphaCom E consists of a number of assemblies (DLLs) which can easily be integrated with software written in C# or VB.NET. CRM station PA Radio Intercom Remote I/O Public telephone and PBX IP telephones and DECT AlphaCom E network (AlphaNet) Security management integration

A100K10674 V.2.0 DLL description 2.2. The�API�consists�of�two�DLL�files: Stentofon.AlphaCom.AlphaNet.dll The Stentofon.AlphaCom.AlphaNet.dll implements the AlphaCom Data Protocol and handles the communication with the AlphaCom E exchanges. It raises events and exposes methods to be able to receive data from, and send commands to the exchange. The .dll supports auto-discovery of the complete AlphaCom E network configuration.�This�makes�the�system�very�easy�to�configure�and�set� up. In addition, the .dll will track and report all state changes in the AlphaCom E network which the 3rd program subscribes to. The .dll supports the STENTOFON AlphaNet. This means that all AlphaCom E exchanges and stations in a network can be addressed by having an IP connection to just one of the AlphaCom E exchanges. The .dll requires Microsoft .NET 2.0. The�DLL�contains�three�name�spaces: .Messages ● .Client ● .Config ● Stentofon.AlphaCom.Data.dll The Stentofon.AlphaCom.Data.dll is not strictly required, but it provides a standardized way of storing and retrieving AlphaCom E network, exchange and station information and states. Storage can be in an MSSQL database or in memory ’AlphaComStateStorages.MSSQL’ or ‘AlphaComStateStorages.IN_ MEMORY’. The .dll requires Microsoft .NET 3.5. The�DLL�contains�one�name�space: .State ● Licensed features 2.2.1. The possibility to retrieve intercom station state information from the exchange is a licensed feature, and requires the presence of an ‘OPC interface’ license in the AlphaCom E exchange for at least as many stations as that of the status to be retrieved. If the application does not need station state information, then the OPC interface license is not required. Station state is further explained in section 2.10. Communication with the AlphaCom E exchange 2.3. The�API�files�communicate�with�the�AlphaCom�E�exchange�via�TCP�port� 61112. As an alternative, port 61113 is also available as from AMC-IP software version 10.54; this can, for instance, be used for redundancy purposes or if two independent management systems are connected to the AlphaCom E exchange. Stentofon.AlphaCom.AlphaNet.dll AlphaCom Application AlphaCom Web Service Stentofon.AlphaCom.Data.dll Stentofon.AlphaCom.Data.dll AlphaCom State DataBase

To be able to communicate with either of these ports, the port must be enabled in the exchange using AlphaWeb, the web server which is integrated in the AlphaCom E. Log�in�to�AlphaWeb�and�select�‘System�Configuration/Filters’�and�enable� the required port number for the physical Ethernet port the API will connect to. _client = new AlphaNetClient(“169.254.1.5”, 61112); This statement gives the IP address and port number of the AlphaCom E exchange where the API will be connected to. When there are a number of AlphaCom E exchanges networked together in an AlphaNet, the API only needs the IP address or port number of one of the exchanges in the network. By default, the API will automatically discover all other exchanges in the AlphaNet and connect to them using the AlphaNet data links and data routing (including alternative routing if implemented) between the exchanges. Remote connections 2.4. Under�certain�circumstances�the�2�available�TCP�ports�provided�by�the� AlphaCom exchange may not be enough as more clients may need to communicate with the exchange. For this purpose, the SDK contains a service provider. The service provider can connect to one of the available TCP ports on the exchange and will make another TCP port available to which multiple�clients�can�connect.�Which�TCP-port�this�is�can�be�configured. The service provider, ‘Stentofon.AlphaCom.AlphaNetServiceProvider. exe’ runs as a Windows service and needs to be installed using the InstallUtil.exe�tool.�When�Microsoft�.NET�2.0�is�installed,�this�tool�can� be�found�in�the�directory�C:\WINDOWS\Microsoft.NET\Framework\ v2.0.50727\ To install the service provider, start the ‘Command Prompt’ and navigate to�the�directory�containing�InstallUtil.exe.�Enter�the�following�command: �InstallUtil�$INSTDIR\�Stentofon.AlphaCom.AlphaNetServiceProvider. ● exe where�$INSTDIR�is�the�directory�where�Stentofon.AlphaCom. AlphaNetServiceProvider.exe is located. You can verify a successful installation has occurred by viewing the command prompt window display�or�by�viewing�the�InstallUtil.InstallLog�file�located�in�the�same� directory�as�the�InstallUtil.exe�is�located. This procedure only needs to be done once, as from now the service provider will start automatically every time the PC on which it is installed is started up.

A100K10674 V.2.0 It is possible to remove the service provider by using the /u switch as part�of�the�InstallUtil.exe�utility. Note�that�the�person�who�runs�the�InstallUtil.exe�utility�needs�to� have�sufficient�rights�to�be�able�to�do�the�installation.�In�general�this� installation can only be done with Administrator rights. The service provider only needs to run on one PC. This can be a dedicated server, but can also be a client PC. All other client PC’s which need to communicate with the AlphaCom exchange can do so via the PC running the service provider. The�service�provider�needs�to�be�configured.�This�can�be�done�in�one�of� 3�ways: �Using�Stentofon.AlphaCom.AlphaNetServiceMonitor.exe ● �Using�Stentofon.AlphaCom.AlphaNetServiceConfigurator.exe ● An advanced way is to enter the parameters in the properties dialog ● of the AlphaNetServiceProvider service This�service�monitor�software�has�3�input�fields�to�enter�the�IP�address� and TCP port number of the AlphaCom XE exchange to connect to, and the TCP port number which should be made available for clients to connect to. Click on ‘Start’ to start the service provider with the configuration�data.�If�the�configuration�of�the�service�provider�needs�to� be�changed,�the�service�provider�needs�to�be�stopped�first�by�clicking� ‘Stop’�on�the�service�monitor.�New�configuration�data�can�now�be� entered and the service provider can be started again. The service monitor is also a monitoring tool. It shows information about the connection status towards the AlphaCom, how many nodes and intercom stations have been discovered and the number of to the service provider connected clients. Further it provides a logging facility. Note that status information will also be shown by hovering over the System Tray icon. This icon will also be displayed with a red X over the icon if connection is lost. For proper operation of the service provider it is not a requirement for the service monitor tool to be running. This means that after initial configuration�of�the�service�provider�the�service�monitor�can�be�closed� again. The�AlphaNetServiceProviderConfigurator�also�has�3�fields.�A�change� in�configuration�of�the�service�provider�is�effectuated�after�clicking�the� ‘Configure’�button. When using the 3rd method, the parameters AlphaCom IP-address ● AlphaCom TCP/IP port nr ● ● Local TCP/IP port nr Can�be�entered�in�the�field�‘Start�parameter’.�The�parameters�must�be� separated by a ‘space’. The service must be stopped and started again for the new parameters to take effect.

The�service�provider,�service�monitor�and�service�configurator�software� can be freely distributed to users of products which are developed using this SDK. Connecting to the exchange 2.5. The following is a code example of how to connect to a single AlphaCom E exchange or all exchanges in an AlphaNet network using a direct connection. This program will register with all exchanges in the AlphaNet and maintain the connections. For an example on how to connect the client via the service provider, please refer to the with the SDK bundled source code of the ‘Stations’- example. using System; using System.Collections.Generic; using System.Text; using Stentofon.AlphaCom.AlphaNet.Client; namespace AlphaNetConnectApp { class Program { static void Main(string[] args) { #region Private Members AlphaNetClient _client; #endregion #region Initialize the Client try { _client = new AlphaNetClient(“169.254.1.5”, 61112); } catch (Exception e) { Console.WriteLine(“\r\nError connecting to AlphaCom, details:\r\n\r\n{0}”, e.Message); return; // Quit the App } #endregion #region Do the Action // Connect to the AlphaCom try { // Start listening on the AlphaCom socket _client.StartListening(); // The Monitor Thread will monitor the TCP connection, and connections with all discovered nodes // By default all nodes will be AutoDiscovered (can be turned of with the AutoDiscoverAllNodes Flag) // The monitor process will Register to all discovered nodes // If the AutoDiscoverAllNodes is not used, the AlphaNetClient method RegisterToAlphaComNode(node) // has to be used for each node, in order to receive broadcast messages _client.StartMonitorThread(); } catch (Exception e) { Console.WriteLine(“\r\nError Listening to AlphaCom socket, details:\r\n\r\n{0}”, e.Message); return; // Quit the App } // Wait for key pressed Console.Read(); try { _client.Dispose(); } catch (Exception e) { Console.WriteLine(“App quiting... {0}”, e.Message); } #endregion } } }

A100K10674 V.2.0 AlphaCom Data Protocol message classes 2.6. The API communicates with AlphaCom E via the AlphaCom Data Protocol. The ‘.Messages’-namespace provides classes for AlphaCom Data Protocol Messages. using Stentofon.AlphaCom.AlphaNet.Messages; Event reports 2.7. Activity inside the exchange can raise events. The following is an example. Register�for�some�events: // Register for some events _client.OnStationConnect += HandleStationConnect; _client.OnStationDisconnect += HandleStationDisconnect; _client.OnQueueElementAdded += HandleQueueElementAdded; The�event�handlers:� #region The AlphaNet Handlers private static void HandleStationConnect(StationConnect sc) { // Use the objects internal ToString() method: Console.WriteLine(sc); } private static void HandleStationDisconnect(StationDisconnect sd) { Console.WriteLine(sd); } private static void HandleQueueElementAdded(QElementAdded cea) { Console.WriteLine(cea); } #endregion If only part of the information contained in an object is of interest, then there are a multitude of methods available to retrieve just that information,�as�for�example: private static void HandleStationConnect(StationConnect sc) { Console.WriteLine(“ A: {0}”, sc.StationA.GetDirNo()); } Information of an object such as ‘sc’ can be passed in different formats (OneLine, Detailed, XML, XMLPretty, Short, and Custom). The format can�be�selected�by: _client.SetMessagePrinformat(MessagePrintFormat.XMLPretty); Application synchronization 2.8. When the API connects to the exchange, the exchange (-network) may already be operational with pending call requests and established calls. The AlphaNetClient object has three properties which will make synchronization of the application software to the state of the exchange network easy. AutoDiscoverAllNodes – default value True The API will discover all exchanges which are connected in the AlphaNet network and raise events when the connection is lost or re- established.

_client.OnNodeConnectionUp += HandleNodeUp; _client.OnNodeConnectionDown += HandleNodeDown; AutoGetStationState – default value False Refer to section 2.10 for a complete description of the StationState object. When all stations are discovered, the event OnAllStationsAdded is raised. AutoSyncCallRequests – default value False For each station which has a call request in its queue, an OnCallRequest event will be raised. Refer to section 2.12 for a complete description of the call request queue. When all Call Requests have been synchronized, the OnCallRequestsSynchronized event is raised. _client = new AlphaNetClient(_formConfig.ClientConfig) { AutoDiscoverAllNodes = true, AutoGetStationState = true, AutoSyncCallRequests = true }; Sending commands to AlphaCom E 2.9. Commands to the AlphaCom E exchange are normally related to a station. When a guard clicks on an area on his PC screen to make a call or cancel an established call, it is just as if he presses keys on his intercom station. All information related to an intercom station is part of an object of type StationState. The StationState class also has the methods implemented to format commands to be sent to the AlphaCom E on behalf of an intercom station. Methods where the name starts with ‘MakeCommand’, will format and store the command. The AlphaNetClient class method ‘SendAlphaCommand’ sends the stored command to the exchange. private StationState _selectedStation; _selectedStation.MakeCommandCKey(); _client.SendAlphaCommand(_selectedStation); API custom events 2.10. TCP ports 61112 and 61113 are handled by the AlphaCom E exchange as devices with device number 199 (0xc7) for port 61112 and 196 (0xc4) for port 61113. All AlphaNet broadcast messages will always be sent out from both these ports. All important activity in the exchange is reported as a broadcast message and is therefore able to raise an event in the API. But there may�be�a�specific�interface�requirement�which�depends�on�an�action� inside the exchange for which there is no API event available, as there is

A100K10674 V.2.0 no related broadcast message. To be able to support such requirements there�are�two�custom�events�which�can�be�raised:� OnCustomParameter event ● ● OnCustomString event The AlphaCom E exchange features an internal event handler with trigger points on any possible action inside the exchange. By programming a custom message inside the exchange event handler related�to�the�relevant�action�of�the�specific�interface,�it�is�possible�to� raise the above listed API events. OnCustomParameter event 2.10.1. To raise the API OnCustomParameter event, the exchange must send a�message�with�MessageID�0x7f01�followed�by�7�parameters.�The�first� two parameters are of type NET_OBJ_REF, the other 5 parameters are of�type�UINT2;�for�a�description�of�these�parameter�types,�please�refer� to AlphaWiki. Most�of�the�time,�the�first�two�parameters�will�be�the�‘owner’�and�the� ‘related to’ directory numbers of the event which was triggered inside the AlphaCom�E.�An�example�of�an�action�in�the�event�handler�action�field� is: @nnff M7F01 %1.ref %2.ref Wpar1 Wpar2 Wpar3 Wpar4 Wpar5 Where: - nn is the node number of the AlphaCom E exchange to which the API connects. It can be any value from 0x01 to 0xfe, represented by 01 to FE par1, par2, par3, par4 and par5 can be any value from 0 to 65535 - If�one�of�the�two�NET_OBJ_REF�parameters�is�not�relevant,�the�NULL� value�should�be�used,�which�is: U0�–�NULL�value�for�parameter�type�NET_OBJ_REF - If, for any reason, the message should only be sent to either port 61112 or�61113,��@nnff�can�be�replaced�by: - @nnC7�–�for�port�61112 @nnC4�–�for�port�61113 - Note that all parameters must be passed. NET_OBJ_REF parameters which are not relevant to the interfacing application must be set to NULL;�UINT2�parameters�which�are�not�relevant�can�be�set�to�any�� arbitrary value. OnCustomString event 2.10.2. With the 7 parameters which can be passed as part of the OnCustomParameter event described in section 2.9.1, most interface requirements can be met. For those requirements which are not covered by those 7 parameters, it is possible to use the OnCustomString event. Any number of parameters of any type will be passed as a single string. To raise the API OnCustomString event, the exchange must send a message with MessageID 0x7f00 Comparing the two OnCustom events 2.10.3. Assume�that�the�action�field�in�the�exchange�event�handler�is� programmed�with�two�messages,�one�for�each�OnCustom�event: @01C7 M7F00 %1.ref %2.ref W1 W2 W3 W4 W5 @01C7 M7F01 %1.ref %2.ref W1 W2 W3 W4 W5 MySQL

where the event owner is directory number 101 and the related directory number is 6901. The�first�message�will�raise�the�OnCustomString�event.�The�event� handler for this event will pass the string parameter (in this example given�in�XMLPretty�format): 3203101F3203690100010002000300040005 The second message will raise the OnCustomParameter event. The event handler for this event will pass the following parameter (in this example�given�in�XMLPretty�format): Node 3, DirNo 101 Node 3, DirNo 6901 1 2 3 4 5 In this example, the information passed by both events is the same but the interfacing application software will need to untangle OnCustomString as a single parameter passed string. OnCustomParameter example 2.10.4. An example of the use of the OnCustomParameter event is an interface application between the AlphaCom E exchange and a CCTV system. The rest of this section assumes knowledge of the AlphaCom E and its programming tool, AlphaPro. A number of guard intercom stations are associated with monitors. A number of door intercom stations are associated with cameras. When a guard sets up a call to a door, the signal of the camera at that door shall be switched to the guard’s monitor. Program�all�guard�intercom�stations�as�UDP�1 ● Program�all�door�intercom�stations�as�UDP�2 ● Program�the�User�Defined�Parameter�for�each�guard�station�with�the� ● associated monitor number Program�the�User�Defined�Parameter�for�each�door�station�with�the� ● associated camera number Program�an�event: ● Owner:�� � Stations�with�UDP:�1 - Event�type:�� � 8�–�Conversation�–�Outgoing - When�Change�to:�� ON - When�Related�To:�� Stations�with�UDP:�ID�2 - - Action: � @01FF�M7F01�U0�U0�W%1.EXP�W%2.EXP�W0�W0�W0 The OnCustomParameter event will be raised passing the monitor and camera number. Intercom station state 2.11. By�setting�the�flag�‘AutoGetStationState’�the�API�will�discover�all� intercom stations in all discovered exchanges. For each discovered station, the API will raise the ‘OnStationStateReceived’ event. This

A100K10674 V.2.0 can therefore be used to get an accurate overview of the connected intercom stations and their status at the time of the connection of the API to the exchange. Most applications need to be able to retrieve StationState at any moment and most applications will implement structures to store this information. The Stentofon.AlphaCom.Data.dll provides a standardized method to store and retrieve StationState objects either in a MySQL database or in memory. using Stentofon.AlphaCom.Data; private AlphaComState _stateStorage; _stateStorage = new AlphaComState(AlphaComStateStorages.IN_MEMORY); private void HandleStationState(StationState st) { if (_stateStorage.UpdateStation(st) > 0) { // Id added } } The intercom exchange is a dynamic environment where station states change continuously. To limit the load on the internal AlphaNet links, not all state changes will result in an OnStationStateReceived event. The�OnStationStateReceived�event�will�be�raised�when: A station is discovered ● On a change in value of StationState.IsStationOK ● On a change in value of StationState.HasMailQueue ● On a change in value of StationState.RciBitmap ● On a change in value of StationState.RcoBitmap ● The events listed below shall therefore be monitored to be able to update�the�stored�StationState�object: OnStationFreeReceived private void HandleStationFree(StationFree sf) { var station = _stateStorage.GetStationState(sf.Station); if (station != null) { station.SetBusyState(false); // Update the state storage object } } OnStationBusyReceived private void HandleStationBusy(StationBusy sb) { var station = _stateStorage.GetStationState(sb.Station); if (station != null) { station.SetBusyState(true); // Update the state storage object } } OnStationConnect

private void HandleStationConnect(StationConnect sc) { var stationA = _stateStorage.GetStationState(sc.StationA); var stationB = _stateStorage.GetStationState(sc.StationB); // Update the state storage object if (stationA != null) { stationA.RelatedStation = sc.StationB; } if (stationB != null) { stationB.RelatedStation = sc.StationA; } } OnStationDisconnect private void HandleStationDisconnect(StationDisconnect sd) { var stationA = _stateStorage.GetStationState(sd.StationA); var stationB = _stateStorage.GetStationState(sd.StationB); // Update the state storage object if (stationA != null) { stationA.RelatedStation = null; } if (stationB != null) { stationB.RelatedStation = null; } } Mail messages 2.12. Intercom stations are able to receive text messages. These may be messages from someone who wants the user to call back, but also system messages which are sent to a station, or group of stations, about the condition of the intercom system. Messages are sent to the message queue of a station, where by using the display of the station it is possible to scroll through these messages. The user can then react to the message after which it is deleted from the queue. Queue�related�messages�are�also�reported�by�the�API�by�raising�events: OnQueueElementAdded ● OnQueueElementRemoved ● Call request 2.13. A�very�powerful�feature�of�the�AlphaCom�E�is�the�call�request.�Using� this feature, a remote intercom station puts itself into the call queue of one or several guard stations. This happens when the call button on the remote intercom is pressed. The call queue handling is all done by the exchange; for instance if one guard answers, the request is removed from all call queues from other guard stations where the call was placed. Also in case of call request transfers or escalation, the internal queue and�the�resulting�events�always�reflect�the�correct�situation.�This� means that management system software only needs to monitor the appropriate�queue�events�and�use�this�information�to,�for�instance,�flash� an assigned icon to the remote intercom station. A call request is a sub-type of the mail message. This means that when a call request event is raised, the ‘OnQueueElement’ event is also raised. Depending on the kind of application, these events are used for information that is important. It is recommended to either monitor all mail events or only the call request events. Supported�events�are:

A100K10674 V.2.0 OnCallRequest ● OnCallRequestRemoved ● Connect call 2.14. Often when there is a call request, the guard wants to be able to click�on�the�flashing�icon�to�accept�the�call.�The�calling�method�is�to� send a connect message with the directory number of the guard as a parameter. The icon associated with the intercom station will set up the call. Supported�method: MakeCommandCallSetup ● Call connected 2.15. When the call is set up, the exchange API will generate the call request removed events described in section 2.12, and an event stating that the guard intercom station and the remote intercom are in conversation. These messages can directly be used to change the appearance of the remote intercom icon. The�supported�event: OnStationConnect ● Cancel call command 2.16. When the guard terminates the call, the software shall call a method to cancel the call. The�supported�method: MakeCommandCKey ● Call disconnected 2.17. When the call is disconnected, an event stating that the call between the two intercom stations has been disconnected is raised. The icon can be put in the ‘idle’ status. The�supported�event: OnStationDisconnect ● Method to send ACDP messages 2.18. The underlying protocol of the API is the AlphaCom Data Protocol. To send�commands�to�the�AlphaCom�E,�specific�methods�(some�of�which� are described in the sections above) have been implemented. These methods result in the API sending the appropriate ACDP command to the exchange. Sometimes it can be an advantage to send an ACDP command directly to the exchange. For this purpose, a method has been implemented which takes the ACDP command as a parameter in Simple Link Layer format. Public bool SendAlphaCommand(String cmd) ● The statement below will set up a call between stations with directory numbers�101�and�102: SendAlphaExecuteCommand(“$CALL�L101�L102”) ●

Other available events and methods 2.19. The AlphaCom Data Protocol provides complete control over the exchange. Examples of the functionalities that can be implemented with the�derived�API�methods�and�events�are: Force a pre-recorded alarm message to an intercom station, group of ● intercom�stations�or�PA�amplifiers Force an audio program to an intercom station, group of intercom ● stations�or�PA�amplifiers Make�a�PA�announcement�to�pre-defined�zones ● Open doors or operate other equipment through relays under the ● control of the AlphaCom E exchange Read door open/closed status or other status signals through logical ● inputs under the control of the AlphaCom E exchange The API will be extended in the future when new features become available�in�the�AlphaCom�E.�Suggestions�for�implementation�of�specific� events and methods may be sent to [email protected].

A100K10674 V.2.0 SDK APPLICATION 3. General 3.1. The SDK contains two example applications which use all the concepts described in the previous sections and more. The source code for the applications is well documented. Studying this code will provide additional information. Stentofon.AlphaCom.Example.Stations.exe ● Stentofon.AlphaCom.Example.CallRequest.exe ● Stentofon.AlphaCom.Example.Stations 3.2. Connection to the exchange 3.2.1. To connect to the exchange(network), click on the ‘Connect’-button. The dialogue which now will be shown gives the possibility to either connect to the exchange via the service provider or directly, depending on whether the checkbox ‘Remote Connection’ is enabled or not. In both cases the IP address and TCP port nr to connect to have to be entered. Once�the�Configuration�dialogue�is�closed,�click�on�the�‘Connect’-button. Station selection and status 3.2.2. Once the application has discovered stations it is possible to select one of those stations, show its status and perform commands on behalf of that station.

Enter a directory number or a Display Text in the textbox under ‘Station Selector and Status’ or select a station from the dropdown menu. The text after ‘Selected Station’, ‘Station Status’ and ‘Call Connection’ will show the relevant information for that station. When a station has been selected, it is possible to deselect it by double clicking�the�information�in�the�field�for�‘Selected�Station’. When a station has been selected, the station selector dropdown menu becomes yellow. Choosing a station from this dropdown menu will set up a connection to this chosen station. var stB = (StationState) comboBoxStationPicker.SelectedItem; if (_selectedStation.MakeCommandCallSetup(stB)) _client.SendAlphaCommand(_selectedStation); Station commands 3.2.3. Under�‘Station�Commands’�there�are�several�other�action�controls�for� the selected station. IP station output ‘IP�station�Output’�will�send�output�On/Off�commands�to�one�of�the�first� three logical outputs on an IP station. if (state == “ON”) _selectedStation.MakeCommandSetIpStationOutput(outNo, 1); else _selectedStation.MakeCommandSetIpStationOutput(outNo, 0); _client.SendAlphaCommand(_selectedStation); Station control ‘Station Control’ gives the possibility to dial digits and operate the M and C�keys: Entering a digit in the text box ‘Dial Digit’ will simulate pressing a digit on the�station�keyboard: _selectedStation.MakeCommandDialDigits(Digit); _client.SendAlphaCommand(_selectedStation); M-key�down: _selectedStation.MakeCommandMKey(KeyPressState.Press); _client.SendAlphaCommand(_selectedStation); M-key�up: _selectedStation.MakeCommandMKey(KeyPressState.Release); _client.SendAlphaCommand(_selectedStation); Clicking�the�C-key: _selectedStation.MakeCommandCKey(); _client.SendAlphaCommand(_selectedStation); DAK keys Clicking one of the DAK buttons will simulate pressing a DAK key on an intercom station. _selectedStation.MakeCommandDialDak(dak); _client.SendAlphaCommand(_selectedStation);

A100K10674 V.2.0 Stentofon.AlphaCom.Example.CallRequest 3.3. Connection to the exchange 3.3.1. To connect to the exchange(network), click on the ‘Connect’-button. In the dialogue which now will be shown enter the IP address and TCP port nr of the exchange to connect to. Once�the�Configuration�dialogue�is�closed,�click�on�the�‘Connect’-button. Station selection and status 3.3.2. By default, the textbox under ‘Station Selector and Status’ works as described in section 3.2.2. Double clicking this text box will change the search mode to only stations with a pending Call Request. Double click again to return to the default search mode. Call Requests 3.3.3. If the selected station in section 3.4.1 has pending Call Requests, they will be shown in the dropdown menu ‘Selected Station Queue’. Selecting a station in this dropdown menu will set up a conversation with that selected station. _selectedStation.MakeCommandCallSetup(cr.SendingStation); _client.SendAlphaCommand(_selectedStation); The call can be cancelled by double clicking the listed connection after ‘Call Connection’. _selectedStation.MakeCommandCKey(); _client.SendAlphaCommand(_selectedStation);

P.O. Box 4498 Nydalen NO-0403 OSLO Norway STENTOFON and VINGTOR products are developed and marketed by Zenitel Norway AS. The company’s Quality Assurance System is certified to meet the requirements in NS-EN ISO 9001:2008. Zenitel Norway AS reserves the right to modify designs and alter specifications without prior notice, in pursuance of a policy of continuous improvement. © 2010 Zenitel Norway AS. [email protected] DOC NO. A100K10674