DRIVER

List of all drivers
Drivers
-> Public pagers
-> Private pagers / beep / DECT
-> Email / printer / fax
-> SMS (via analog modem)
-> SMS (via ISDN modem)
-> SMS (via GSM modem)
-> Other
-> Network
-> Compatibility with Processor Message script

Voice over IP: a new media to transmit your alerts

With its VoIP-SIP driver, today Micromedia proposes you a new media for alarm transmission and voice communications with its products ALERT, JERICHO and SIREN.

By integrating the Voice over IP technologies, Micromedia opens its solutions to the telecommunications world of the future, and enables you to benefit from these technologies:

• A simplified and economic installation: no more telephonic line, nor modem, just a simple network connection to transmit and receive telephonic calls. In addition, the option but not to use modems, particularly analog modems, increases the durability of your installations faced with the obsolescence risk of this type of device.
• Enhanced call capacities: several dozen of voice communications can be managed simultaneously, without having to put additional hardware in the station.
• Increased mobility: the capabilities of user logical addressing provided by the IP telephony, independently of the user location, enabling operators to register where they can be reached, and so avoid losing time with unnecessary calls, particularly when mobile phones can be used.
• Reduced communication costs, or even none for full IP communications.

Of course, VoIP technologies are relatively recent and not much expanded, but they are highly increasing and will soon become essential. Tomorrow they will offer more advanced capabilities at the level of the service integration and interoperability between the different equipments and services providers, interoperability that is still very limited today.

And if the real power of these technologies will only be proven in a full IP context, the solutions that are installed today must be designed in a heterogeneous environment where it is necessary to be able to reach analog or numeric (ISDN) telephone, or GSM mobile.

And if the real power of these technologies will only be proven in a full IP context, the solutions that are installed today must be designed in a heterogeneous environment where it is necessary to be able to reach analog or numeric (ISDN) telephone, or GSM mobile.

To face this constraint, various configurations can be proposed, according to existing environment.

• Installation on a local network connected to a telephonic switch (PBX ) integrating an IP gateway
• Installation on a local network connected with one or several IP/ISDN gateways
• Installation with an ADSL line

PBX

Installation on a local network connected to a telephonic switch (PBX ) integrating an IP gateway

In this configuration, the principle is to use the PBX to the maximum for what it was designed: the telephonic switching.

All call requests are transmitted through the PBX which establishes the required connections and performs conversions that might be necessary (IP<->analog, IP<-> ISDN).

All internal or external telephone set that are displayed on this schema can be called by ALERT (or SIREN), whatever their type, through the IP network and PBX (for communications with no IP sets).

The system security can be reinforced by an ISDN connection between the ALERT (or SIREN) station and the PBX, allowing the communications to be ensured in case of failure on the TCP/IP network.

IP/ISDN

Installation on a local network connected with one or several IP/ISDN gateways

In this configuration, there is no connection with a PBX, or the PBX installed on the site does not handle the voice over IP.

To take advantage of the Voice over IP, always being enable to communicate with standard telephone sets, the proposed solution is to use one or several IP/ISDN gateways (IPBX) made up of a simple PC under Linux, an IPBX software(as Asterisk provided in Open Source) and one or more ISDN adapters.

This solution allows Voice over IP functionalities to be added to an existing telephone network and communications resources to be federated between different applications.

As in the configuration A, all internal or external telephone set that are displayed on this schema can be called by ALERT (or SIREN), whatever their type, through the IP network and IPBX gateway. In case of failure of a gateway, ALERT (or SIREN) automatically switches to the valid gateway and can inform of the failure of the other gateway.

ADSL

Installation with an ADSL line

In this configuration, there is no connection with a local network. The station is isolated and communicates with external telephone set through an ADSL line In this configuration, there is no connection with a local network. The station is isolated and communicates with external telephone set through an ADSL line.

The ADSL line enables external voice communications with all SIP compatible devices (IP sets, Smartphones, Softphones, …).
Voice communications with traditional telephone equipments need to be routed by a SIP compatible IP telephony provider, which proposes services to transfer IP communications to the Public Telephone Network. However, that solution is not really operational today, insofar as most of the providers which propose that service still use proprietary protocols. But the trend for the years to come should push towards homogenisation of the standards, notably with products as Google Talk willing to integrate the SIP protocol.

The ADSL line can also be used for transmission of emails and communication with client stations via Internet (ALERT or SIREN client stations, or WEB browser in case of AlertWeb).

Ascom Alert Driver

• -> For serial ascom equipment (select the type of equipment: P940AI or T940SI)

AscomIP Alert Driver

• -> For Ascom IP equipment: The OAS card is required or the PAO software license

This document describes the interaction between Alert and the Cisco CallManager

To resolve this issue, edit Email.ini (located in C:\MMI\Alert). Change the FALSE to TRUE in the value UIDInSubjectForCallAck = ...
This will add the ID of the operator in the subject of the email and ALERT will then be able to process the acknowledgment Warning: There are several drivers in Email.ini, choose the driver you are using.

• -> Alert must be able to access the mail servers (SMTP or MAPI mail (Windows Exchange Server))
• -> You can send emails with an analog modem as long as you have an ISP or another modem accepting the connection and if you can reach the SMTP server when connected.

This document specifies how to configure Alert to use with the SIP driver for VOIP.

This document specifies how to configure Alert to use with the SIA driver.

This document specifies how to configure Alert to send message to an Astrid pager.

Description and configuration guide for the Alert OXEPaging driver.

This document aims to compare the Alert drivers OXEPaging and MiniMess, which enables to send text messages on DECT phones and phones with text display.

This document explains how to configure the driver Aastra ATAS for ALERT.

When Alert sends a message with the ESPA protocol, the latter depending on the options validated, waits for 3 call statuses from the central.
The three expected responses are:

• SOH>2<STX1><US>xxxx<RS>7<US>2<ETX>1
• SOH>2<STX>1<US>xxxx<RS>7<US>3<ETX>1
• SOH>2<STX>1<US>3000<RS>7<US>5<ETX>1

Field 7 indicates the call status and the values 2,3 and 5 show the status:

• - 2: In Queue
• - 3: Paged
• - 5: Call Teminated.

By default the ESPA4.4.4 driver waits for the status 5 to end the call and informs Alert that the message has been sent. In some cases, only the first 2 answers are returned by the Central or just one. This causes a timeout.

To overcome these timeout problems, several solutions are possible:

• - Uncheck the driver option "end transmission Waiting" in this case, Alert terminates the call immediately upon receipt of status 2.
• - Edit ESPA.ini and change the value of the variable "AckOnPaged" for the driver concerned. By putting 1 in this field, Alert will terminate the call when it receives the status 3.

In case no frame comes back, so no answer, amend the NoWaitAckData variable to 1 (NoWaitAckData=1) in ESPA.ini.