fév 04

Haute-disponibilité et Load-Balancing par Cascade de NS

©Disney/Pixar

 Un retour aux premiers amours de ce blog, avec, pour changer, une suite de billets système et réseau.

Cette série est issue d’une petite discussion que j’ai eu avec mon ami Horacio, du blog LostinBrittany, durant un projet technique professionnel commun.
Plutôt que de garder pour moi mes réflexions, autant vous les faire partager :)

Cette discussion concerne surtout le prochain billet de ce blog, mais avant de l’aborder, il fallait poser les bases d’une certaine architecture et c’est ce que nous allons tout d’abord voir aujourd’hui.

Je vais vous parler d’une technique qui paraît bien triviale mais étonnamment efficace et largement employée dans les architectures disposant de 2 branches d’accès Internet.

Après tout, dans votre soucis constant de disposer d’une architecture hautement disponible et partant du sacro-saint adage « on ne met pas les oeufs dans le même panier », vous avez décidé de confier l’accès internet de votre infrastructure à deux opérateurs différents (par exemple, si  > 2, cela marche aussi…)

Bien évidemment, cela peut aussi être l’hébergement de vos serveurs dédiés chez deux entités différentes, ou encore, plus simplement, des serveurs dédiés dans 2 datacenters différents, ou tout bêtement, de 2 serveurs dédiés devant lesquelles vous n’avez pas de load-balancer…

Quoi qu’il en soit, la multiplication des points d’entrées « Internet » de votre service sur plusieurs chemins différents, vous donne, déjà, une meilleure sérénité de sa disponibilité envers le « monde ».

L’inconvénient de ce choix est qu’il est difficile de positionner un Load-Balancer devant vos serveurs pour répartir la charge ou tout simplement de renvoyer tout le trafic sur le serveur « vivant » quand l’autre est tombé.

On ramenant le concept à deux serveurs web (que je vais utiliser pour un exemple plus « accessible » ), nous allons voir comment utiliser le service DNS pour aller sur l’un ou l’autre des serveurs et pouvoir basculer le trafic sur l’un des deux en cas de panne d’un accès (ou du décès de l’un des serveurs Web).

Dans un vision très habituelle des choses, que l’on rencontre fréquemment sur les architectures exposées par les sysadmins, la technique souvent utilisée est le « Round Robin DNS« .

Je vous rassure tout de suite, rien à voir avec des problèmes d’obésité d’un quelconque défenseur de la fôret de Sherwood, mais d’une bidouille d’un enregistrement dns.

En effet, pour un enregistrement de type A (un enregistrement DNS spécifiant un nom = une adresse IP  pour faire simple), on peut donner 2 entrées pour le même nom.

Exemple :

blog.guiguiabloc.fr  IN A 10.10.10.10
blog.guiguiabloc.fr  IN A 10.20.20.20

Les plus pointus allant même jusqu’à modifier l’entrée TTL pour peaufiner.

Résultat, alternativement, les requêtes sont envoyées sur 10.10.10.10 ou sur 10.20.20.20.

Le gros inconvénient de cette technique est que les requêtes iront toujours sur l’un ou l’autre, même si l’un des deux est mort… Un accès sur 2 n’aura donc pas de réponse… Gênant.
C’est donc une technique « a pas cher » de load-balancing, mais nullement une solution de haute-disponibilité (ou de Fail-Over).

Alors comment utiliser les DNS pour faire et du load-balancing et du fail-over ?
La réponse s’appelle du « Cascading NS » (ou cascade de serveurs NS).

Si une entrée DNS de type A fait la correspondance entre un nom d’hôte et une adresse IP, un enregistrement de type NS vous donne le serveur DNS ayant autorité sur le domaine (et qui donc sera à même de vous donner l’adresse IP (ou type A) du nom d’hôte que vous recherchez ou de vous indiquez à qui le demander).

Un dessin valant un long discours, regardons un peu le fonctionnement du cascading NS :

Que se passe t-il quand le client demande « blog.guiguiabloc.fr » ?

- Les autorités TLD répondent que le domaine « guiguiabloc.fr » est géré par les NS de tel registrar (OVH, GANDI, etc…) (je simplifie hein :p)

- Les serveurs DNS du Registrar répondent qu’il faut interroger deux autres NS, NS1.mondns.fr et NS2.mondns.fr qui sont autorité de zone pour le domaine « guiguiabloc.fr » (on arrive la sur VOS serveurs DNS) (1)

- Les serveurs DNS, ns1.mondns.fr et ns2.mondns.fr répondent qu’ils gèrent bien le domaine « guiguiabloc.fr » mais le sous-domaine « blog.guiguiabloc.fr » est géré par deux autres DNS, web-1.mondns.fr et web-2.mondns.fr (qui sont vos serveurs Web sur lesquelles tournent un serveur DNS ne s’occupant que de cette zone) (2)

- Le client interroge alors l’un des NS (web-1.mondns.fr ou web-2.mondns.fr) pour connaitre l’entrée A de blog.guiguiabloc.fr (3)

- Si c’est web-1.mondns.fr qui est interrogé, il répondra 10.10.10.10, si c’est web-2.mondns.fr, il répondra 10.20.20.20, avec une durée de vie d’1 minute de la correspondance (60 secondes plus tard, si le client doit demander de nouveau blog.guiguiabloc.fr, il devra demander de nouveau l’adresse IP (lors d’une nouvelle session par exemple).

Voila ce que donnera une demande de résolution :

guigui@Clara:~$ dig blog.guiguiabloc.fr
 
; <<>> DiG 9.7.3 <<>> blog.guiguiabloc.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41551
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
 
;; QUESTION SECTION:
;blog.guiguiabloc.fr.              IN      A
 
;; ANSWER SECTION:
blog.guiguiabloc.fr.       49      IN      A       10.10.10.10
 
;; AUTHORITY SECTION:
blog.guiguiabloc.fr.       49      IN      NS      web-1.mondns.fr.
 
;; ADDITIONAL SECTION:
web-1.mondns.fr.         3922    IN      A       10.10.10.10

Et 60 secondes plus tard :

...
;; ANSWER SECTION:
blog.guiguiabloc.fr.       60      IN      A       10.20.20.20
 
;; AUTHORITY SECTION:
blog.guiguiabloc.fr.       60      IN      NS      web-2.mondns.fr.
 
;; ADDITIONAL SECTION:
web-2.mondns.fr.         5006    IN      A       10.20.20.20

Vous avez compris que le site web blog.guiguiabloc.fr tourne sur les deux serveurs web avec chacun une IP différente.

A l’inverse du Round-Robin DNS, le client interroge les NS aléatoirement et prend la réponse du plus rapide (et donc également du plus proche géographiquement).
Rassurez vous, toute cette séquence ne prend que quelques millisecondes.

Mais que se passe-t-il quand web-1.mondns.fr tombe (et donc ne peut plus répondre).

 Le début est identique mais quand le client demande « blog.guiguiabloc.fr »  aux serveurs NS de la sous-zone, seul le « NS » 2 répondra.

Vous avez la un fail-over immédiat (tout au moins a 60 secondes après le crash) puisque NS1 ne répondra jamais.
La technique est aussi très efficace quand vous souhaitez retirer un des serveurs web de votre pool, il vous suffit d’arreter le serveur DNS dessus. Il ne répondra plus aux requètes NS et donc ne prendra pas de trafic :D

La configuration des DNS est des plus basiques pour cela, il faut bien évidemment que les serveurs DNS de web-1.mondns.fr et web-2.mondns.fr soit chacun master (maître) (puisqu’ils donnent une entrée de type A différente).

Pré-requis, vous avez bien entendu défini une entrée de type A pour web-1 et web-2 dans la zone « mondns.fr ».

Sur vos serveurs DNS principaux (ns1.mondns.fr et ns2.mondns.fr), pour la zone « guiguiabloc.fr » (bien sûr remplacez tout cela par vos domaines/IP ;) )

$TTL 600
@                IN SOA  ns1.mondns.fr. noc.mondns.fr. (
2013020400 ; serial
3600       ; refresh
3600       ; retry
3600000    ; expire
3600       ; minimum
)
 
IN NS ns1.mondns.fr.
IN NS ns2.mondns.fr.
blog                  IN NS web-1.mondns.fr.
                        IN NS web-2.mondns.fr.

Sur web-1, pour la zone « blog.guiguiabloc.fr » :

$ORIGIN .
$TTL 60
blog.guiguiabloc.fr                IN SOA  ns1.mondns.fr. noc.mondns.fr. (
2013020400 ; serial
3600       ; refresh
3600       ; retry
3600000    ; expire
3600       ; minimum
)
 
IN NS          web-1.mondns.fr.
IN A       10.10.10.10

Sur web-2, pour la zone « blog.guiguiabloc.fr »

$ORIGIN .
$TTL 60
blog.guiguiabloc.fr                IN SOA  ns1.mondns.fr. noc.mondns.fr. (
2013020400 ; serial
3600       ; refresh
3600       ; retry
3600000    ; expire
3600       ; minimum
)
 
IN NS          web-2.mondns.fr.
IN A       10.20.20.20

Bien entendu, je vous laisse adapter à votre configuration, c’est juste un exemple :)

Alors, elle n’est pas sympa cette technique ? :)

« oui,oui. Très sympa oh Grand Guiguiabloc, mais y’a quand même un problème ! »
« Ah ? Je t’écoute jeune Padawan »
« si le service web de web-1 plante par exemple, mais pas le serveur, mon DNS il répond toujours !!! et les visiteurs ils arrivent toujours sur mon serveur !! Ca craint ! »
« Je m’attendais à cette remarque, jeune youglin, et comme je suis dans une année de grande bonté, je vais te donner une solution pour cela »

« oh merci Grand Guiguiabloc !!! » (flap-flap-flap)

La solution pour couper votre DNS local sur votre serveur web (ou votre reverse-proxy hein) en cas de crash du service http s’appelle :
MONIT.

MONIT est un utilitaire qui surveille vos process (mais également vos répertoires, fichiers, programmes etc..) et execute des actions en cas de soucis.

L’action la plus courante est d’avertir l’admin (forcément :p) mais également par exemple, de tenter de relancer le programme.

Exemple pour surveiller le process Nginx

check process nginx with pidfile /var/run/nginx.pid
  start program = "/etc/init.d/nginx start"
  stop program  = "/etc/init.d/nginx stop"
  group www-data

Vous trouverez des exemples sur la page wiki du projet :

http://mmonit.com/wiki/Monit/ConfigurationExamples

En cas de non réponse du process, vous pouvez appeler un script par « exec » ‘de type « /etc/init.d/bind9 stop » ;)

Plus simple encore, un simple script bash appeler en crontab :

#!/bin/bash
#pre-requis blog.guiguiabloc.fr a une entrée dans
#le fichier /etc/hosts avec son ip locale
#pour éviter d'interroger les DNS
TESTING=`curl -sL -w "%{http_code} %{url_effective}\\n" "blog.guiguiabloc.fr" -o /dev/null`
if test "$TESTING" != "200 http://blog.guiguiabloc.fr"
then
echo "CA CHIE"
else
echo "ok"
fi

Et donc arreter le service DNS si « CA CA CHIE » :D

En espérant que cela vous donne des idées

Amusez-vous bien :D

 

 

Classé dans architecture, linux | Taggé , | 22 Commentaires
jan 20

Envoyer des SMS en xPL avec SMSGateway

 

Dans un environnement domotisé, l’une des premières taches de communication avec le monde extérieur que l’on met en place est le SMS.

Aujourd’hui, pour un abonnement à 2 euros par mois et un vieux téléphone sous Androïd, vous pouvez envoyer autant de SMS que vous le souhaitez (dans la limite bien sûr du raisonnable, aka « le bon père de famille de Free« …)

Il y a quelques mois, mon confrère Hervé sur son blog Abavala, nous a fait découvrir l’excellent logiciel SMSGateway.

Je n’en reparlerais donc pas, je vous invite plutôt à lire son très bon billet (comme il a l’habitude de nous offrir ;) ):

http://www.abavala.com/2012/07/09/sms-gateway-une-passerelle-sms-a-la-maison/

Je m’en sers depuis la découverte de ce produit et j’en suis très satisfait.
Toutefois, comme vous le savez, mon environnement domotique est très fortement basé sur le protocole xPL et il me manquait l’interfaçage entre xPL et SMSGateway.

Je vous propose donc un petit client xPL, xPL-SendSMSGateway, qui vous permettra par un message xPL de type sendmsg.basic, d’envoyer directement vos SMS via SMSGateway.

http://code.google.com/p/guiguiabloc/downloads/detail?name=xPL-SendSMSGateway.py

Ce client est bien évidemment téléchargable sur mon Google Code et devrait également être intégré directement a xPL-PyHAL dans les jours qui viennent (d’abord sur le SVN, puis dans la version BETA qui devrait sortir rapidement).

Le fonctionnement est des plus aisé.

La configuration se fait au début du fichier, en spécificant l’url de votre téléphone Android (suivant l’installation de SMSGateway) :

url = 'http://192.168.1.1:9090/sendsms?'

et le mot de passe, si vous en avez défini un dans le logiciel.

C’est tout ;)

Maintenant, pour envoyer un SMS via xPL :

xpl-sender -m xpl-cmnd -c sendmsg.basic to=0612121212 body="wesh gros bien ou bien"

ou to = le numero de téléphone du destinataire
et body= « le texte a envoyer »

Sous xPL-PyHAL, il suffira de créer un fichier YAML de ce type :

ACTION: message
TARGETXPL: sms
PHONE: "0612121212"
MODULE: "m5"
COMMAND: "on"
MESSAGE: "Mouvement dans la niche du chien"

Bien évidemment, des exemples de type .sample seront disponibles dans le répertoire yamlrepo.

En espérant que vous en ferez bon usage.

Amusez vous bien :D

Classé dans domotique | Taggé , , , | 2 Commentaires
jan 09

trueCall, filtrer les appels téléphoniques entrants

Dans ce merveilleux XXIe siècle, il faut bien avouer que le Spam est une plaie qu’il est difficile de cautériser.

La première destination de ses sollicitations abusives est bien entendu votre (vos) email(s), mais heureusement, de nombreuses solutions existent et sont pour la plupart très efficace.
Personnellement, j’utilise Spamassassin mais surtout Postgrey qui à réduit mon nombre de spams emails de façon drastique (voire quasi-nulle).
Certains hurleront sur le fait que le greylisting est insupportable pour le client (5 minutes de plus en attente, oh my god !), mais je n’ai qu’une réponse à leur apporter : « C’est votre boulot de sysadmin de remplir la whitelist aussi… »
Honnêtement, si le greylisting vous gène ou insupporte le client, c’est que vous vous la couler douce…
Depuis des années que j’utilise ce système, je n’ai eu aucun retour négatif quand a son efficacité, et je passe peut être 10 minutes par mois à peaufiner ma liste blanche… A bon entendeur.

Ca c’est dit…

Bref, ce n’est pas un billet sur la façon de combattre le spam email mais plutôt le spam téléphonique.

J’avais déjà aborder le sujet dans ce billet, et j’ai découvert une solution beaucoup plus intéressante et performante que je vais vous présenter aujourd’hui.

Des appels commerciaux ou bidons, comme tous, j’en reçois des tas (et pourtant je suis en liste Orange (la liste anti-prospection d’Orange (ça s’invente pas) et j’ai l’option Stop-secret d’Orange.
Ah oui, pour information, j’ai gardé mon numéro RTC Orange fixe en plus de mon numéro de ligne ADSL (pour pleins de raisons que vous retrouverez sûrement dans ce blog).
Avec ma solution domotique, je peux rejeter les appels indésirables avec présentation du numéro mais l’inconvénient principal, c’est que le téléphone de la maison sonne quand même 1 ou 2 fois avant de se faire couper par le modem. Gênant…

Ce bug n’est pas de mon ressort, mais du fonctionnement de la présentation du numéro en France qui n’est transmis qu’a partir de la deuxième sonnerie.

Bon j’avoue aussi jouer au jeu du sifflet avec les call-centers, mais ça va un temps… (pour ceux qui ne connaissent pas, il s’agit de détenir un simple sifflet à bille à côté du téléphone et de « vriller » les oreilles de votre interlocuteur après quelques minutes de discussion. Je sais, c’est très méchant, mais terriblement plaisant :D )

Si des solutions de filtrage d’appels entrants existent chez de nombreux FAI sur des lignes téléphoniques ADSL, il n’y a rien sur des lignes RTC. (Va comprendre pourquoi…)

Je me suis donc mis à rechercher un système pouvant s’intercaler sur ma ligne et m’offrant cette possibilité et rapidement, j’ai découvert le Call Blocker de la société TrueCall .

Commande faite pour la somme d’environ 150 euros.

Reçu rapidement, voici la bête :

Le fonctionnement de cette boite est très simple et extrêmement polyvalent.

Le CallBlocker gère 2 types de liste, la « Star list » (les amis/famille) et la « Zap list » (les emmerdeurs).
Outre ces deux listes, il gère les appels  « mobiles », « internationaux », « masqués » ou « indisponibles » (l’appelant ne présente pas d’identification du numéro. C’est ce qui se passe avec certains call-centers à l’étranger).

L’ajout des numéros dans la Zap ou la « Star list » se fait par les touches du téléphone, ou par le site web, ou durant un appel (par exemple quand vous appelez quelqu’un, il vous suffit de rajouter la touche « * » à la fin du numéro pour que le CallBlocker  le rajoute automatiquement dans la liste « Star ».

Une fois en possession de ses listes, un système de workflow permet de définir les flux vers lesquels renvoyer les appels :

- Accepter l’appel (et donc faire sonner le téléphone de la maison)
- Demander à l’appelant de se présenter (c’est le même principe que le « Stop-secret » d’Orange. Le boîtier nous appelle en nous disant que -le message de présentation de l’appelant- veut nous joindre, on accepte ou non l’appel (avec la possibilité également de rajouter son numéro en liste Star ou Zap).
- Bloquer l’appel et diffuser le message Zap (« tu me casses les bonbons » (par exemple ou plus « compréhensif ;) ))
- Renvoyer sur le répondeur interne du CallBlocker (ici la fonction de répondeur banale du boîtier)
- Bloquer l’appel en annonçant que nous refusons les appels anonymes
- Demander à l’appelant d’appuyer sur telle touche avant de faire sonner le téléphone de la maison
- Bloquer l’appel mais faire croire que notre téléphone sonne en diffusant la tonalité qui va bien
- Demander à l’appelant de taper son « caller code » (un code secret à diffuser auprès de vos correspondants)
- Bloquer l’appel en émettant une tonalité « n’est plus en service »
- Bloquer l’appel et demander à l’appelant de presser telle touche du téléphone, puis après de se présenter, puis enfin fait sonner notre téléphone pour la séquence de choix d’accepter ou pas l’appel.

Ce workflow est paramétrable ou par les touches du téléphone, ou par le site internet de TrueCall dans votre espace client.

Pour se synchroniser à cet espace client (c’est une option non obligatoire), le CallBlocker appelle (à votre demande ou automatiquement) un modem à Londres (rassurez vous, la mise a jour est très rapide et le coût de la communication est de quelques centimes). Ce qui vous permet également d’avoir une liste des appels reçus et bloqués par le CallBlocker.
Sachez toutefois que le CallBlocker appelle quand même le modem après sa mise sous tension pour synchroniser sa date et son heure.

Lors de mes premiers tests, voici donc ce que cela donne sur l’interface :

Par exemple, tout les appels masqués/indisponible sont envoyés vers « la demande de présentation », les numéros en « Zap list » sont bloqués avec le message « va te faire voir » et les autres appels font sonner normalement le téléphone de 7h à 23h (a vous de créer vos scénarios :) )

Il existe des profils pré-définis de différents types, mais l’option « customisée » est quand même plus agréable (la gestion des plages horaires est aussi possible (jour/nuit)).

Je ne vous détaillerais pas toute la documentation (que vous trouverez sur le site du fabricant) mais les possibilités de ce boîtier sont impressionnantes.

De plus, vous pouvez ajouter une carte SD (obligé de les acheter chez le fabricant par contre :( ) ce qui vous permet d’enregistrer les conversations :D

Voici un petit boîtier très performant et je suis toujours surpris que ce genre d’option n’existe pas chez Orange sur les lignes RTC classiques.

L’équipe TrueCall est très sympathique et répondent rapidement par mail ou par téléphone (attention, ils ne parlent qu’anglais ;) )

Bilan un produit efficace, avec de nombreuses possibilités et même s’il est un peu cher, il remplit parfaitement le rôle pour lequel il a été conçu.
Je vous invite à consulter le site du fabricant pour découvrir leurs produits et si vous avez des questions, n’hésitez pas à me laisser un commentaire.

EDIT : Juste 2 choses que j’ai oublié de spécifier.
Les messages des menus vocaux sont en anglais (mais vous pouvez modifiez les messages qu’entendent vos correspondants par les vôtres).
Le CallBlocker marche derrière une Freebox (même les mises a jour ;) )

Amusez vous bien :)

 

Classé dans domotique, geekerie, matériel | Taggé , , | 63 Commentaires
nov 19

Asterisk, suivi des appels en xPL

Asterisk est un serveur VoIP facilement installable à la maison.

Je ne m’étendrais pas la dessus, il y a pléthore de tutos sur le nain ternet pour vous expliquer ce que c’est et comment le mettre en place.

Je m’en sers tout les jours pour de multiples usages et l’une des fonctions qui me manquait était la possibilité de transmettre en xPL les numéros des appels entrants, et pourquoi pas, le numéro des appels émis.

(Rassurez vous, tout cela dans l’idée de l’intégrer à mon centralisateur xPL).

En fouillant un peu, j’ai d’abord découvert le package d’ iranger, xplast.

Puis l’excellent billet de mon confrère Ma domotique

Tout cela était bien gentil et sympa, mais je voulais un truc plus simple et plus rapide à mettre en oeuvre.

Je me suis donc plongé (avec délicatesse je vous rassure) dans la documentation d’Asterisk et surtout sur la partie AGI.

Vous trouverez également plein d’info sur le site voip-info.org a cette adresse :

http://www.voip-info.org/wiki/view/Asterisk+AGI

Un peu de google derrière et je suis tombé sur un très bon billet d’Andy Ortlieb qui explique comment utiliser les Asterisk Gateway Interface avec python.

Je me suis donc servi de ses exemples pour écrire un simple module AGI qui transmet en xPL les numéros des appels reçus ou émis via Asterisk.

Copier ce script dans le répertoire agi-bin d’Asterisk (généralement /var/lib/asterisk/agi-bin)
Mettre l’utilisateur asterisk propriétaire de ce script et le rendre executable

Pour intercepter les appels, il faut rajouter une entrée dans votre extensions.conf :

Exemple, pour envoyer un message xPL à chaque appel sortant avec le numéro appelé:
dans votre contexte « appel sortant »:

[appelsortant]
exten => _0ZXXXXXXXX,1,AGI(/usr/bin/python,"/var/lib/asterisk/agi-bin/Asterisk2xPL.agi")
exten => _0ZXXXXXXXX,2,Dial(SIP/freephonie-out/${EXTEN})

Exemple, pour envoyer un message xPL à chaque appel entrant avec le numéro appelant :
dans votre contexte « appel entrant »:

[appelentrant]
exten => s,1,Ringing
exten => s,2,AGI(/usr/bin/python,"/var/lib/asterisk/agi-bin/Asterisk2xPL.agi")
...

Attention, par défaut le message « INBOUND » (appel entrant) est produit quand le script voit une extension « s » (comportement le plus souvent rencontré pour les appels entrants)

#!/usr/bin/python
# -*- coding: ISO-8859-1 -*-
#
# Asterisk2xPL
# http://blog.guiguiabloc.fr
import sys,os,socket
 
hostname = socket.gethostname()
xpladdr = ("255.255.255.255",3865)
xplport = 3865
UDPSock = socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
UDPSock.setsockopt(socket.SOL_SOCKET,socket.SO_BROADCAST,1)
 
 
def get():
  res = sys.stdin.readline()
  res = res.strip()
  response,delim,result=res.partition(' ')
  result=result.split('=')[1].strip()
  result,delim,data = result.partition(' ')
  return response,result,data
 
def send(data):
  sys.stdout.write("%s \n"%data)
  sys.stdout.flush()
 
AGIENV={}
 
env = ""
while(env != "\n"):
 
    env = sys.stdin.readline()
    envdata =  env.split(":")
    if len(envdata)==2:
      AGIENV[envdata[0].strip()]=envdata[1].strip()
 
incomingnumber = AGIENV['agi_callerid']
outgoingnumber = AGIENV['agi_extension']
 
if outgoingnumber == "s":
  body = 'calltype=INBOUND\nphone='+incomingnumber
  msg = "xpl-trig\n{\nhop=1\nsource=guigui-asterisk."+hostname+"\ntarget=*\n}\ncid.basic\n{\n" + body + "\n}\n"
  UDPSock.sendto(msg,xpladdr)
else:
  body = 'calltype=OUTBOUND\nphone='+outgoingnumber
  msg = "xpl-trig\n{\nhop=1\nsource=guigui-asterisk."+hostname+"\ntarget=*\n}\ncid.basic\n{\n" + body + "\n}\n"
  UDPSock.sendto(msg,xpladdr)

Vous trouverez le script en téléchargement sur mon googlecode :

http://code.google.com/p/guiguiabloc/downloads/detail?name=Asterisk2xPL.agi
Bien évidemment, si vous mettez à jour xPL-PyHAL par le SVN, il inclut la possibilité de réagir à la réception ou l’émission d’un numéro de téléphone ;)

Par exemple pour allumer le module « m5″ a la réception d’un appel du 0699999999 :

MODULE: INBOUND
TELNUMBER: "0699999999"
ACTION: command
TARGETXPL: heyu
TARGETCOMMAND: "on"
TARGETMODULE: "m5"

Amusez-vous bien :D

Classé dans domotique, geekerie | Taggé , | 1 Comment