Home Driver
07 | 02 | 2012
Driver
  • 1 - liste of all drivers

  • 2 - La Voix sur IP : un nouveau média pour la diffusion de vos alertes

    There are no translations available.

    Avec son driver VoIP-SIP, Micromedia vous propose aujourd’hui un nouveau media pour diffuser vos alertes et communiquer en vocal avec ses produits ALERT, JERICHO et SIREN.

    En intégrant les technologies de communication multimédia sur protocole IP, Micromedia ouvre ses solutions au monde des télécommunications de demain, et vous permet de bénéficier dès aujourd’hui des avantages apportés par ces technologies :

    • Une installation simplifiée et économique : plus de ligne téléphonique, plus de modem, une simple connexion réseau suffit pour émettre et recevoir des appels téléphoniques. En outre, la possibilité de s’affranchir des modems, en particulier des modems analogiques, renforce la pérennité de vos installations face au risque d’obsolescence de ce type de matériels.
    • Des capacités d’appel étendues : plusieurs dizaines de communications vocales peuvent être gérées simultanément, sans équipement supplémentaire  au niveau du poste.
    • Une mobilité accrue : les possibilités inhérentes à la téléphonie IP d’adressage logique des usagers, indépendamment de leur localisation, permettent aux opérateurs de s’enregistrer là où ils peuvent être joints, et donc d’éviter de perdre du temps dans des appels inutiles,  en particulier dans des contextes où la solution des téléphones portables ne peut pas être retenue.
    • Des coûts de communication réduits, voire nuls pour les communications IP de bout en bout.

    Bien entendu, les technologies de la voix sur IP sont encore jeunes et relativement peu développées,  mais elles sont en pleine expansion et deviendront vite incontournables. Elles offriront demain des possibilités encore bien plus importantes au niveau de l’intégration de services et de l’interopérabilité des différents matériels et fournisseurs de services, interopérabilité encore très limitée aujourd’hui.

    Et s’il est vrai que ces technologies donneront la pleine mesure de leur puissance dans un contexte « full » IP, les solutions installées aujourd’hui doivent être conçues dans un environnement hétérogène où il reste nécessaire de pouvoir joindre un téléphone analogique ou numérique (ISDN), ou un mobile GSM.

    Pour répondre à cette contrainte, différentes configurations peuvent être proposées, en fonction de l’environnement existant.

       

    • Installation sur un réseau d’entreprise raccordé à un autocommutateur téléphonique (PBX ) intégrant une passerelle IP

    • Installation sur un réseau d’entreprise raccordé à une ou plusieurs passerelles IP/ISDN

    • Installation derrière une ligne ADSL

     

    PBX

    Installation sur un réseau d’entreprise raccordé à un autocommutateur téléphonique (PBX ) intégrant une passerelle IP

    Dans cette configuration, le principe est d’utiliser au maximum le PBX pour ce qu’il sait très bien faire : l’interconnexion téléphonique.
    Toutes les demandes d’appel passent par le PBX qui établit les connexions demandées et effectue les conversions éventuellement nécessaires (IP<->analogique, IP<-> ISDN).

    VOIP1

    Tous les postes internes et externes représentés sur ce schéma peuvent être appelés par ALERT (ou SIREN), quelque soit leur type, au travers du réseau IP et du PBX (pour les communications avec des postes non IP).
    Bien entendu, rien n’interdit dans ce schéma de renforcer la sécurité du système par une liaison ISDN entre le poste ALERT (ou SIREN) et le PBX, permettant de garantir des communications en cas de problème sur le réseau TCP/IP.

    IP/ISDN

    Installation sur un réseau d’entreprise raccordé à une ou plusieurs passerelles IP/ISDN

    Dans cette configuration, il n’y a pas de connexion avec un PBX, ou le PBX installé sur le site ne prend pas en charge la voix sur IP.

    La solution proposée pour bénéficier de la voix sur IP tout en restant capable de communiquer avec les postes téléphoniques classiques, est d’utiliser une ou plusieurs passerelles IP/ISDN (IPBX) constituées d’un simple PC sous Linux, d’un logiciel IPBX (comme Asterisk en Open Source) et d’une ou plusieurs cartes ISDN.
    Cette solution permet d’ajouter les fonctionnalités de voix sur IP sur un réseau téléphonique existant et de fédérer les ressources de communication entre les différentes applications utilisatrices.

     

    VOIP1

    Comme dans la configuration A ( raccordé à un PBX), tous les postes internes et externes représentés sur ce schéma peuvent être appelés par ALERT (ou SIREN), quelque soit leur type, au travers du réseau IP et de la passerelle IPBX.
    Pour renforcer la sécurité du système, il est possible de doubler la passerelle IPBX. En cas de défaillance d’une passerelle, ALERT (ou SIREN) bascule automatiquement sur la passerelle valide et est capable de signaler la défaillance de l’autre passerelle.

    ADSL

    Installation derrière une ligne ADSL

    Dans cette configuration, il n’y a pas de connexion avec un réseau local. Le poste est isolé et communique avec des postes externes via une ligne ADSL.

     

    voip_3_fr.jpg

     

    La ligne ADSL permet d’établir des communications vocales externes avec tous les équipements compatibles SIP (postes IP, Smartphones, Softphones, …).
    Les communications vocales avec les équipements téléphoniques traditionnels doivent passer par un opérateur de téléphonie sur IP compatible SIP, proposant le service de routage des communications IP sur le réseau téléphonique public. Cette solution n’est toutefois pas vraiment opérationnelle aujourd’hui dans la mesure  où s’il existe de nombreux opérateurs proposant ce type de service, la plupart utilisent encore des protocoles propriétaires.  La tendance cependant dans les années à venir devrait pousser vers une homogénéisation des standards, notamment avec des acteurs comme Google Talk affirmant leur volonté d’intégrer le protocole SIP.

    La ligne ADSL peut en outre être utilisée pour la transmission des emails et l’établissement de communication avec des postes clients via Internet (poste clients ALERT ou SIREN, ou navigateur WEB dans le cas d’AlertWeb).

  • 3 - Ascom & AscomIP

    There are no translations available.

    Driver Alert Ascom
    -> pour les centrales Ascom série (sélectionner le type de centrale: P940AI ou T940SI)
    Driver Alert AscomIP
    -> pour les centrales Ascom IP: nécessite la carte OAS ou la licence software OAP
  • 4 - Cisco CallManager & ALERT

    There are no translations available.

    Ce document décrit l'interaction entre ALERT et Cisco CallManager
    pdf 
    En anglais 

  • 5 - Email: Appel non acquitté sur retour email de Gmail et Blackberry

    There are no translations available.

    Pour résoudre ce problème, il faut éditer Email.ini (qui se trouve dans C:\MMI\Alert). Il faut changer le FALSE en TRUE dans la valeur UIDInSubjectForCallAck= …
    Ceci ajoutera l'ID de l'opérateur dans le sujet du email et ALERT pourra alors traiter le retour pour acquitter l'appel.
    Attention: Il y a plusieurs drivers dans Email.ini, bien choisir le driver que vous utilisez.

  • 6 - Email: Quelle sont les conditions préalables pour envoyer des emails ?

    There are no translations available.

    -> Alert doit pouvoir accéder aux serveurs mail (SMTP ou MAPI mail (serveur Exchange Windows))
    -> il est possible d'envoyer des emails avec un modem analogique à partir du moment ou vous avez un FAI ou un autre modem acceptant la connexion et que vous pouvez atteindre le serveur smtp une fois connecté.

  • 7 - SIP (VOIP) driver GUIDE d'installation

    There are no translations available.

    Ce document précise comment configurer ALERT pour utiliser le driver SIP pour VoIP.
    pdf
  • 8 - SIA driver GUIDE d'installation

    There are no translations available.

    Ce document précise comment configurer ALERT pour utiliser le driver SIA.
    pdf
  • 9 - Astrid pager GUIDE d'installation

    There are no translations available.

    Ce document spécifie comment configurer Alert pour envoyer un message à un pager Astrid.
    pdf 
    (En anglais)

  • 10 - OXEpaging GUIDE configuration

    There are no translations available.

    Description et Guide de configuration du driver OXEPaging dans Alert.
    pdf 
    (En anglais)

  • 11 - OXEPaging et Minimes Comparaison

    There are no translations available.

    Ce document a pour but la comparaison des drivers d’Alert OXEPaging et MiniMess qui offrent la possibilité d’envoi de messages texte sur des DECT et des téléphones avec afficheurs.
    pdf

  • 12 - Aastra ATAS GUIDE configuration

    There are no translations available.

    Ce document explique comment configurer le driver Aastra ATAS pour ALERT.
    pdf 
    (En anglais) 

  • 13 - TRSII driver

    There are no translations available.

    Explication du driver TRSII
    pdf 

  • 14 - ESPA 4.4.4 driver: Problème d’échec d’appel timeout

    There are no translations available.

    Lorsque le logiciel Alert envoi un message avec le protocole ESPA, celui-ci en fonction des options de validées, attends 3 réponses d'état d'appel en provenance de la centrale.
    Les 3 réponses attendues sont les suivantes :

    SOH>2<STX>1<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

    Le champ 7 signifie un statut d'appel et les valeurs 2,3 et 5 donnent le statut :
    - 2 : In Queue
    - 3 : Paged
    - 5 : Call Teminated.

    Par défaut le driver ESPA4.4.4 attend le statut 5 pour terminer l'appel et informer Alert que le message a bien été transmis.
    Dans certains cas, seulement les 2 premieres réponses sont retournée par la centrale ou bien une seule. Cela entraine un timeout
    Pour palier ces problèmes de timeout, plusieurs solutions sont possibles :
    -       Décocher au niveau du driver l’option "Attente fin transmission" dans ce cas, Alert termine l'appel dés réception du statut 2.
    -       Modifier le fichier ESPA.ini et changer la valeur de la variable "AckOnPaged" pour le driver concerné. En mettant 1 dans ce champs, Alert terminera l'appel lorsqu'il recevra le statut 3.
    Dans le cas ou il y a pas de trame de retour, donc aucune réponse, modfier la variable NoWaitAckData a 1 (NoWaitAckData=1) dans ESPA.ini.