Cette page détaille les bonnes pratiques à l'AUF en matière de mise en place d'un serveur VoIP basé sur Asterisk et capable de gérer les protocoles IAX et SIP.

Infrastructure matérielle

Asterisk ne consomme pas excessivement de ressources. Sur une petites implantation (jusqu'à 5 employés) il peut être placé sur une machine effectuant d'autres opérations. Idéalement, il faut l'installer sur une machine virtuelle, OpenVZ étant la solution de virtualisation conseillée.

Note : si vous devez installer du matériel spécifique à Asterisk comme une carte TDM pour liaison avec la téléphonie classique, il faudra sans doute une machine physique dédiée, "non virtuelle".

Le système d'exploitation doit être Debian GNU/Linux 4.0, c'est-à-dire Etch. Comme les paquets Asterisk que nous installons sont des rétro-portages (backports), il est préférable que le système soit dédié à Asterisk et ne fasse rien d'autre.

Infrastructure réseau

Note : Il s'agit de l'infrastructure conseillée, vous êtes libre de trouver mieux ou de faire autrement si vos pratiques ou votre configuration vous l'impose.

Accès aux postes VoIP locaux

La liaison entre le serveur Asterisk et les postes VoIP locaux doit être directe, c'est-à-dire ne passer par aucun système de NAT. Il est cependant recommandé de ne pas la placer sur le même réseau IP que les postes, et d'appliquer un filtrage entre le serveur Asterisk et les postes locaux.

• pour que les téléphones IP puissent joindre Asterisk : cela se fait juste par routage uniquement, avec quelques ports à ouvrir.

  • La machine doit être accessible depuis le réseau local privé 10.x.x.x sans système de NAT.
  • protocole IAX : il faut laisser passer les paquets à destination de 4569/udp vers le serveur Asterisk

  • protocole SIP : le serveur doit pouvoir recevoir tout paquet 5060/udp ainsi que tout paquet RTP, c'est-à-dire tout paquet UDP dont le port de destination se situe entre 61000 et 62000 (limites indiquées dans le fichier /etc/asterisk/rtp.conf, que vous pouvez adapter si besoin) ;

• pour que Asterisk puisse joindre les téléphone IP : toujours juste par routage, sans NAT.

  • protocole IAX : il faut laisser passer les paquets provenant de 4569/udp depuis le serveur Asterisk
  • protocole SIP : le serveur doit pouvoir envoyer aux postes VoIP des paquets provenant de son port 5060/udp, ainsi que tout paquet RTP, c'est-à-dire tout paquet UDP dont le port source se situe entre 61000 et 62000

Liaison avec Internet

Les filtrages sont identiques à ceux indiqués ci-dessus. Il faut gérer les deux protocoles IAX et SIP, dans les deux sens (pour appeler et pour être appelé) :

• émettre et recevoir des appels IAX : il suffit d'ouvrir 4569/udp, dans les deux sens ;

• émettre et recevoir des appels SIP : il faut que le serveur Asterisk puisse

  1. envoyer des paquets vers Internet sur 5060/udp ;
  2. recevoir des paquets 5060/udp ;

  3. envoyer des paquets RTP, c'est-à-dire tout paquet UDP dont port source UDP est compris entre 61000 et 62000 (voir /etc/asterisk/rtp.conf) ;

  4. recevoir tous les paquets RTP, c'est-à-dire UDP vers ses ports 61000 à 62000/udp.

Cas d'un serveur avec IP privée (DNAT+SNAT)

Rappel : il ne faut pas faire de NAT (ni DNAT, ni SNAT) entre vos postes VoIP locaux et votre serveur Asterisk. Le NAT dont il s'agit ici se situe entre le serveur et «Internet».

Pour envoyer des appels : classiquement, faire un SNAT général de la machine.

Pour recevoir des appels :

• protocole IAX : ajoutez un DNAT vers la machine pour les protocoles IAX (4569/udp) ; c'est tout.
• protocole SIP : faire un DNAT pour 5060/udp et pour tous les paquets RTP (dans les deux sens : tout paquet UDP partant ou arrivant sur les ports 61000 à 62000 du serveur).

Si vous ne faites que cela, SIP ne fonctionnera pas car Asterisk enverra son adresse interne (privée) comme adresse IP dans les messages SIP. Il faut donc configurer Asterisk pour lui dire l'IP publique qu'il doit publier. Pour cela, ajouter les lignes suivantes dans /etc/asterisk/auf/sip.local :

• # lignes à ajouter dans /etc/asterisk/auf/sip.local pour faire du SIP sur une machine SNATtée
  [general](+)
  externip = 200.201.202.203

Note : en théorie il est de se passer de l'ouverture des ports RTP avec un parefeu à noyau récent disposant des modules netfilter nf_conntrack_sip et nf_nat_sip. Cependant, étant donné que différentes implémentations de SIP existent, il n'est pas certain que cela fonctionne toujours. Nous vous conseillons donc, si c'est possible, de placer votre serveur Asterisk sur une IP publique, sinon d'utiliser un DNAT et d'adapter votre configuration SIP.

Pourquoi le filtrage de SIP est compliqué ?

SIP n'est pas un protocole qui transfert la voix. C'est juste un Protocole d'Initiation de Session (Session Initiation Protocol) qui permet entre autre à deux machines de se mettre d'accord sur les flux qu'elles vont utiliser pour s'échanger des informations. Il ne suffit donc pas de laisser passer SIP pour que la communication passe : il faut aussi laisser passer les flux qui vont être négociés pour transporter les données. Ces flux sont en général des flux UDP, utilisant un protocole nommé RTP.

On a alors deux solutions, la «simple-pas-très-regardante-mais-efficace» et la «jolie-mais-pas-garantie-à-100%».

Solution simple et efficace : forcer une plage de ports UDP spécifique pour le procole RTP

On demande au serveur Asterisk de négocier les ports UDP dans une certaine plage, par exemple entre 61000/udp et 62000/udp. C'est le protocole RTP (Real Time Protocol) qui va gérer les flux, c'est lui que SIP va piloter par négociation. La configuration de la plage de ports se fait donc dans /etc/asterisk/rtp.conf. Au niveau du filtrage, on peut alors autoriser en entrée tous les paquets UDP pour cette plage, et en sortie (s'il y a un filtrage en sortie) tous les paquets émis par Asterisk depuis cette plage.

Solution un peu plus élégante mais moins garantie (nécessite un firewall avec noyau récent type backport.org)

On peut mettre en place le suivi de connexion dédié à SIP sur le pare-feu. Le module nf_conntrack_sip va analyser les paquets SIP (5060/udp et tcp) qui transitent sur la machine et il ouvrira de façon dynamique les flux UDP en fonction des négociations en cours. Cependant, l'étude de divers client SIP montre que tout le monde ne respecte pas forcément le format de négociation et il n'est pas impossible que cette solution ne fonctionne pas avec certains clients. Néanmoins c'est une solution à tester, même si en terme de sécurité elle n'est pas vraiment beaucoup plus efficace que la solution simple ci-dessus.

Quelques détails sur les protocoles en jeu :

• SIP pour la négociation de la session et RTP pour les flux de données (voix, image, etc.)

• IAX, session et flux sur un seul port UDP, c'est plus simple mais mal adapté à la facturation (en cas de redirection d'appel, le premier opérateur perd la vue de la session en même temps que le flux)... donc ne gagnera pas la guerre !