Translate

mercredi 23 décembre 2009

INFO: Démystifier le carnet d'adresses OCS 2007 R2 et son utilisation avec MOC 2007 R2

Le carnet d'adresses d'Office Communications Server 2007 (et R2) a toujours été le *gros* défaut du produit...

A titre d'exemple aux débuts d'OCS 2007: nous avons connu des problématiques chez un client, où la génération entrait en erreur (deux frontaux généraient les carnet d'adresses en même temps) et badaboom, les clients s'amusaient à télécharger une carnet d'adresses complet à chaque démarrage. A 15 Mo le carnet d'adresses et 20 000 clients en pilote dit "étendu" dans un Active Directory qui comportait plus de 75 000 utilisateurs "actifs", je vous laisse imaginer les dégâts sur la consommation réseau... Ce bug avait été remonté à Microsoft à l'époque et un correctif "privé" fourni en retour, pour enfin être intégré dans un hotfix "officiel".

Heureusement depuis, le service de carnet d'adresses a évolué. Le but de cert article est de résumer les améliorations apportées dans OCS 2007 R2 visant à réduire les impacts sur la consommation réseau des téléchargements du carnet d'adresses, et surtout comment les configurer afin qu'elles soient 100% fonctionnelles.

Compact Deltas

Dans la mise à jour cumlative #2 (Juillet 2009) d'OCS 2007 R2, Microsoft a introduit un nouveau procédé de génération des deltas, appellé "Compact Deltas". Ces compacts deltas sont les fameux fichiers "C-xxx-yyy.labs" dont vous avez peut-être noté la présence dans votre répertoire (ou partage) où sont stockés les fichiers générés par le processus "ABServer.exe" (s'exécutant (par défaut à 1:30 du matin) sur un serveur frontal, une instance unique tournant à un instant T par Pool...).

Cela va de soit, vous devez avoir un client Communicator 2007 R2 à jour (mise à jour cumulative #2 (build 37) ou ultérieure) pour tirer parti des nouveaux compacts deltas. Mais il ne s'agit pas de la seule amélioration visant à réduire les effets (négatifs) du téléchargement du carnet d'adresses OCS 2007 R2...

Utilisation du service de transfert intelligent en tâche de fond (BITS - Background Intelligent Transfer Service)

Cette modification a été aussi introduite dans la mise à jour cumulative de Juillet 2009, et permet à MOC 2007 R2 (build 37 ou plus donc) d'utiliser BITS afin de 1) ne pas faire échouer le téléchargement lorsque les conditions réseau sont "difficiles" et 2) de s'auto-restreindre en cas de saturation du lien réseau.

L'utilisation de BITS ne s'applique (pour l'instant) qu'aux téléchargements du carnet d'adresses complet (fichiers F-xxxx.lsabs) et requiert d'être activé sur les clients (cf configuration des clients ci-après dans cet article).

Configuration des serveurs frontaux - Web Components dans IIS

Afin que les téléchargements BITS fonctionnent, il est nécessaire de forcer les Web Components IIS (le fameux "Handler") de l'Address Book afin d'envoyer un verbe HTTP "Redirect" (302) au client. Ce processus permet au client d'être directement réferré vers le chemin du fichier à télécharger, et autoriser le client BITS d'y accéder directement.

Pour configurer l'emission du Redirect au travers des Web Components IIS, il est nécessaire de modifier les fichiers "Web.Config" de chaque "Handler" (interne et externe) sur chaque serveur frontal OCS 2007 R2. Cette action n'est pas nécessaire sur les frontaux servant un Pool Directeur puisque ceux-ci ont (normalement) les services d'Address Book et IIS désactivés.
  • Utiliser Notepad pour éditer %OCSInstallDir%\Web Components\Address Book Files\Int\Handler\Web.Config
  • Changer la valeur dans la clef "redirect" de "false" à "true" (défaut: false);
  • Enregistrer et fermer le fichier, et répéter l'opération avec %OCSInstallDir%\Web Components\Address Book Files\Ext\Handler\Web.Config
  • Redémarrer les services IIS (iisreset /noforce) ou recycler l'application IIS associée.
Remplacez %OCSInstallDir% par le chemin d'installation des binaires OCS 2007 R2 (par défaut: %ProgramFiles%\Microsoft Office Communications Server 2007 R2).

Voici donc quelques captures:

Comportement avant changement du Handler (pas de REDIRECT)


Configuration du Handler

Comportement après configuration du Handler (avec REDIRECT)

Configuration des serveurs frontaux - Générateur de carnet d'adresses

Le générateur de carnet d'adresses (ABServer.exe) étant une application .NET, vous aurez probablement remarqué qu'il existe un fichier "ABServer.exe.config" au même emplacement que l'exécutable. Ce dernier permet en particulier de configurer la génération des "Compact Deltas":
  • Clef "CompactDeltaOnly" (défaut: "false") - Passer à "true" afin d'éviter la génération des "anciens Deltas" (D-xxx-yyy.lsabs). Particulièrement utile pour libérer un espace disque non négligeable à condition de n'avoir que des clients MOC 2007 R2 build 37 ou plus;
  • Clef "CompactDelta_ExcludedIfSipURI" (défaut: "title,physicalDeliveryOfficeName") - Permet d'exclure les attributs "title" (Titre) et "physicalDeliveryOfficeName" (Office) des entrées dans les compact deltas pour les contacts étant activés pour OCS. Les clients exécuteront des requêtes LDAP pour récupérer ces attributs s'ils n'ont jamais été récupérés auparavant;
  • Clef "CompactDelta_AlwaysExclude" (défaut: "otherHomePhone,otherMobile,manager") - Permet purement et simplement d'ignorer ces attributs dans les compacts deltas.
Il est important que vous vérifiez que ces clefs sont bien présentes dans le fichier "ABServer.exe.config" de chaque serveur frontal participant à un Pool, et qu'elles soient bien sûr toutes en corrélation. Dans le cas contraire, vos Compact Deltas ne seront plus cohérents en fonction du serveur frontal qui sera en charge de la génération et vous risquez de compromettre leur intégrité, forçant ainsi les clients à ré-effectuer un téléchagement complet du carnet d'adresses.

Configuration du carnet d'adresses via ABSConfig.exe

ABSConfig.exe est un outil du Resource Kit permettant (comme son nom l'indique :)) de configurer la génération du carnet d'adresses sur les serveurs frontaux d'un Pool donné (il n'est donc utile de ne le faire qu'une fois par Pool, et non par serveur frontal).

Je passe la partie (certes importante mais hors sujet ici) sur la normalisation des numéros de téléphone... Le but est de s'intéresser ici aux optimisations qu'il est possible d'apporter lors de la génération du carnet d'adresses afin de réduire la taille de celui-ci.

La génération du carnet d'adresses considère qu'un objet Active Directory (et certains de ses attributs) doivent être transposés dans le carnet d'adresses OCS 2007 (R2) sous certaines conditions. Une de ces conditions, la plus fondamentale est la colonne "Is this Attribute Required?" qui peut être positionné à "Yes" (coché) ou "No" (décoché). Il s'agit donc d'une logique déterministique, à savoir que si l'un de ces attributs est présent (non vide) dans l'objet Active Directory, alors ce dernier est transposé dans la carnet d'adresses.

Par défaut, les attributs requis sont donc l'adresse SIP, et les champs de type téléphone. Ce filtre, très inclusif, a pour but d'autoriser les clients activés pour la téléphonie de "voir" et donc "appeler" les numéros de téléphones d'utilisateurs non activés pour OCS (qu'il s'agisse de fonctionnalités pures "Enterprise Voice" ou juste de type "PBX Integration" (comme le Remote Call Control par exemple)).

Cependant, un certain nombre de sociétés, donc certains de mes clients, n'intègrent pas (et n'intègreront malheureusement peut-être jamais) OCS avec de la téléphonie, et désirent donc n'inclure dans le carnet d'adresses OCS *que* les utilisateurs activés pour OCS.

Ainsi, les paramètres par défaut sont les suivants:


Et les paramètres permettant d'inclure *seulement* les utilisateurs activés pour OCS, ainsi que les groupes de distribution Exchange sont les suivants (en laissant les autres attributs configurés par défaut):


Afin d'alléger encore le carnet d'adresses, il est aussi possible de supprimer certains attributs en sélectionnant la ligne correspondant ceux-ci et en pressant la touche "Suppr" (ou "Del"). Evidemment, vous devez conserver l'attribut msRTCSIP-PrimaryUserAddress

Une fois les paramètres changés, effectuez une regénération complète des ressources utilisateurs (ABServer.exe -RegenUR), ce qui a pour effet de supprimer tous les carnet d'adresse jusqu'alors générés, et de repartir sur une nouvelle base. Le nouveau carnet d'adresses sera alors généré en prenant en compte la nouvelle configuration.

Cette configuration est à faire au plus tôt car elle va forcer les clients à télécharger un carnet d'adresses complet. D'ici là, la récupération des deltas échouera.

Configuration des clients

Réglage des téléchargements

Il existe essentiellement deux paremètres qui sont susceptibles de vous intéresser afin de régler les clients:
  • Le premier permet de régler le délai initial de téléchargement du carnet d'adresses après démarrage du client. Par défaut, et depuis la mise à jour cumulative #2 (Juillet 2009, build 37), le client introduit un délai aléatoire avant de vérifier/télécharger les mises à jour du carnet d'adresses (cela peut aller jusqu'à 60 minutes).
    • Ce changement permet de réduire les chances qu'un nombre exceptionnellement grand de clients téléchargent au même moment le carnet d'adresses (ce qui est fréquent le matin lors des pics de connexion...)
    • Ce délai peut donc être soit désactivé (mis à 0) ou forcé à une valeur (exemple: 5) en *minutes*
    • En toute objectivité, je recommande de conserver la configuration par défaut, sauf lors des phases de troubleshooting (avec Fiddler par exemple) et/ou pilote -- les seuls cas où l'on est "pressé" de recevoir les mises à jour rapidement.
  • Le second a été introduit dans la mise à jour cumulative #3 (Octobre 2009, build 56) permet de régler le mode de téléchargement des Compact Deltas:
    • Désactiver le téléchargement des Compact Deltas
    • Activer le téléchargement des Compact Deltas (mode par défaut)
    • Activer le téléchargement des Compact Deltas mais ne pas utiliser de requêtes LDAP
Activation de BITS

Une fois satisfaits avec le comportement du générateur d'Address Book et de votre client, il ne vous reste plus qu'à activer le téléchargement au travers du service BITS (Background Intelligent Transfert Service). N'oubliez pas que BITS est natif dans Windows et que BITS 2.0 est requis (Windows XP ou ultérieur il me semble).

Pour activer BITS, il suffit de mettre la stratégie HKCU\Software\Policies\Microsoft\EnableBitsForGalDownload (REG_DWORD) a 1 (un). Pour désactiver, mettre 0 (zéro) ou supprimer la valeur.

Template ADM pour stratégie de groupe (GPO)

Afin de faciliter la configuration de vos clients, votre serviteur (moi =°)) a donc mis à votre disposition un fichier Communicator.adm modifié (et donc non officiel) ici:


Pour conclure

Depuis les mises à jour cumulative #2 d'OCS 2007 R2 et de MOC 2007 R2 il est possible de réellement et considérablement réduire les impacts liés au téléchagement du carnet d'adresses.

Pour que ces améliorations soient optimales, il est nécessaire que les étapes suivantes soient effectuées:
  • Maintenir une excellente corrélation entre les versions "serveur" et "client": Je dirai que les mises à jour cumulatives #2 sont un "must have", et je ne saurai que trop conseiller à minima les mises à jour cumulatives #3 [EDIT 16/04/2010 - le CU #5 est disponbile, cf mon article à ce sujet]
  • Configurer les serveurs frontaux OCS 2007 R2 afin de configurer les "Handlers" internes et externes pour que BITS fonctionne - configurez ensuite les clients manuellement, ou par stratégie.
  • Optionnellement, optimiser la taille de votre carnet d'adresses en n'incluant que les utilisateurs et/ou attributs donc vous avez besoin.
Un dernier petit conseil pour la route... TESTEZ toute modification dans un environnement de pré-production (avec un annuaire Active Directory peuplé et idéalement représentatif de la production). Cela permettra d'OBSERVER tout changement comportemental du serveur ou des clients, et de valider que ceux-ci réagissent comme attendu.

vendredi 18 décembre 2009

RIGOLO: Boulette sur le site Technet français =)

Un collègue m'a pointé vers ce lien, que je voulais partager avec vous en cette période de fêtes de fin d'année emplies de bonne humeur... Heureusement que l'on est pas le 1er Avril ! :)


jeudi 10 décembre 2009

INFO: Sortie de l'Update Rollup 1 pour Exchange Server 2010 - Ajout du support de Blackberry 5.0.1

Certains l'attendaient avec impatience, la DevTeam Exchange a officiellement annoncé sur son Blog la mise à disposition de l'Update Rollup 1 d'Exchange Server 2010.

Pourquoi un Rollup si tôt ? Essentiellement pour une question de support de ces petits boitiers démoniaques que sont les Blackberries :) - Microsoft et RIM ont travaillé ensemble pour rendre leurs produits phares compatibles dans des délais somme toute très acceptables au regard de la date de sortie de la RTM d'Exchange Server 2010.

Au menu, trois pré-requis permettent l'interopérabilité:
L'occasion est prise aussi d'incorporer un certain nombre de "bugfixes" comme décrit dans cet article (anglais).

Lire l'article du Blog de la DevTeam. Notre ami Scott Schnoll a aussi posté un excellent article sur la déploiement du Rollup 1 (généralisable aux futurs prochains) sur son Blog (en anglais).

Bon(s) déploiement(s) !

lundi 7 décembre 2009

INFO: Microsoft et Cisco annoncent un support conjoint du Direct SIP entre OCS 2007 (R2) et Call Manager

Microsoft et Cisco ont annoncé le support de l'interconnexion directe via le protocole SIP (Direct SIP).
En gros, les deux géants ont testé diverses versions (plus facile pour Cisco, étant donné que seuls OCS 2007 et OCS 2007 R2 sont pour l'instant disponibles :) alors que Microsoft a testé les versions 4.x, 5.x, 6.x)

La page UCOIP de Microsoft résume très bien la situation: les versions 4.2, 5.1 et 6.1 (les versions d'IOS varient) sont pleinement supportées pour Direct SIP. C'était bien plus compliqué avant, lorsqu'il fallait passer par une passerelle, ou un GETS... :p -- Attention toutefois, il convient que l'intégration soit supportée aussi bien par Microsoft que Cisco. Le plus "direct" est la mise en oeuvre de l'intégration OCS 2007 R2 avec CCM 6.1.

lundi 30 novembre 2009

TUTORIEL: Intégration Exchange 2007/2010, SIPnPBX et SIP Trunk Freephonie!

Hier, j'expliquais comment intégrer Exchange UM avec Asterisk/Trixbox et Freephonie. Aujourd'hui nous allons voir comment en quelques minutes nous pouvons réitérer cette intégration avec un petit bijou de simplicité nommé PBXnSIP. Merci à Benoit Q de m'en avoir parlé, car je ne connaissais pas!

Étant parfois un peu fainéant, je ne vais pas réécrire la totalité des étapes de configuration Exchange, vous les trouverez dans la première et la seconde partie des articles consacrés à Asterisk/Trixbox.

Installation de PBXnSIP

PBXnSIP est un IP-PBX bien ficelé, qui tourne sur Windows, Linux ou Mac OS ! Contrairement à Asterisk, il n'est ni gratuit ni Open Source mais reste abordable pour des TPE/PME.
Pour mes tests, j'utilise une licence de démo permanente mais dont la durée des appels est limitée. Aucune chance donc que je ne l'utilise pour une "vraie" démo. Cependant, il est possible d'utiliser une licence de démo parfaitement fonctionnelle, mais limitée dans le temps (14 jours) -- cela est peut-être une meilleure option pour vous...

Pour mon lab, j'utilise une machine virtuelle Windows Server 2003 SP2 32-bit avec 256 Mo de mémoire. L'installation de PBXnSIP se fait sans accroc en quelques secondes. Lisez le guide d'installation et les instructions sur le site PBXnSIP (configuration du support du TOS et configuration du redémarrage du service en cas de crash... peu important dans un lab, mais à considérer en production).

Dans le même esprit que ma Trixbox, j'ai deux interfaces, dont celle connectée en interne a une route statique par mon interface privée afin de joindre mon serveur UM qui est dans un sous-réseau spécifique.

L'autre interface est bien évidemment connectée à mon réseau "maison", directement NATé à Internet via ma Freebox. Cette interface n'a aucun service type "Client Microsoft" ou "Partage de fichiers/imprimantes" et ne s'enregistre pas dans le DNS. Netbios/TCP est aussi désactivé.

Bref, comme d'habitude, adaptez votre serveur à vos besoin. L'essentiel est que vous puissiez joindre votre serveur UM d'un côté et Internet de l'autre.

Si vous avez joué avec une Trixbox, n'oubliez pas de l'éteindre, en particulier pour tester les appels entrants lorsque la configuration PBXnSIP sera terminée !

Configuration de PBXnSIP

L'interface d'administration de PBXnSIP est accessible au travers d'un navigateur. Par défaut elle s'exécute sur le port 80. Il suffit donc d'aller sur http://localhost et vous de vous authentifier avec le compte 'admin' (mot de passe = vide). Vous pourrez le changer ultérieurement.

La première étape consiste a enregistrer votre n° de licence. Pour cela allez dans "Settings" ==> "Licence". Copiez-collez le n° reçu et faites "Save".



Aller ensuite dans la configuration des domaines en cliquant sur "Domains". Vous y trouverez des domaines pré-configuré. Personnellement je les ai détruits afin de comprendre ce que je recréais au fur et à mesure. A vous de voir...

Il importe de configurer ces paramètres dans votre domaine:
  • Default Dial Plan: vous n'en avez pas pour l'instant, nous le positionnerons plus tard...
  • Calling own extension number goes to mailbox: No ==> Si vous laissez à "Yes", vous aurez des problèmes plus tard en utilisant le Play-on-Phone depuis Outlook Web App (Exchange appellera PBXnSIP qui appellera votre boîte vocale Exchange)
  • External Voice Mail System: 1000 ==> cela correspond au "Pilot Number" Exchange UM qui sera associé à votre UM IP Gateway correspondant à votre serveur PBXnSIP. J'ai volontairement utilisé le même numéro pilote que pour mon Asterisk, cela n'est pas gênant puisqu'ils ne sont pas associés à la même UM IP Gateway. 


Sauvegardez ("Save") puis allez faire un tour du côté de l'onglet "Trunks".

Configuration du SIP Trunk Exchange

Ajouter un SIP Trunk de type "SIP Gateway" avec les paramètres suivants:
  • Name: ExchangeUM
  • Type: SIP Gateway
  • Direction: Inbound and Outbound
  • Domain: 192.168.101.20
  • Account:
  • Username: Anonymous
  • Password/Password (repeat):
  • Outbound Proxy: sip:192.168.101.20:5060;transport=tcp
  • Accept Redirect: Yes ==> requis pour le support des 302/Redirect
  • Trunk requires out of band-DTMF tones: Yes ==> requis pour que le DTMF fonctionne au travers du SIP Trunk Freephonie
  • Remote Party/Privacy Indication: RFC3325 (P-Asserted-Identity)
  • Assume that calls come from: 2000 ==> fausse extension qui sera créée pour rediriger vers notre UM Auto Attendant mais qui nous servira aussi à appeler depuis Exchange vers l'extérieur


Sauvegardez avec "Save" puis créer le SIP Trunk Freephonie.

Configuration du SIP Trunk Freephonie

Ajouter un SIP Trunk de type "SIP Registration" avec les paramètres suivants:
  • Name: Freephonie
  • Type: SIP Registration
  • Direction: Inbound and Outbound
  • Domain: freephonie.net
  • Account: 09XXXXXXXX
  • Username: 09XXXXXXXX
  • Password/Password (repeat):
  • Outbound Proxy: sip:freephonie.net:5060;transport=udp
  • Remote Party/Privacy Indication: Remote Party-Id ==> Car Freephonie utilise Asterik !!!
  • Send call to extension: 2000 ==> la pseudo-extension qui sera dirigée vers l'Attendant UM de notre choix


Sauvegardez avec "Save" puis allez faire un tour du côté de l'onglet "Accounts". Au final vos SIP Trunks existants ressembleront à ceci:




Configuration des extensions

Ajoutez les extensions 2001, 2002, ... dont les noms doivent correspondre aux extensions UM déclarées dans Exchange.

Ajoutez une extension 2000 avec un PIN/mot de passe top secret... Nommez la comme vous le souhaitez (peu importe, ce qui compte c'est qu'elle existe...). Une fois celle-ci créée, éditez les propriétés de cette extension afin d'ajouter un transfert inconditionnel vers le numéro pilote de votre standard automatique (j'utilise 1000 pour le Subscriber Access et 1900 pour l'Auto Attendant).





Au final, vos extensions ressembleront à ceci:



Nous y sommes presque, il nous reste à configurer les règles de routage. Allez pour cela dans l'onglet "Dial-Plans".

Configuration du Dial Plan

Ajouter un Dial Plan, nommez le comme vous le souhaitez cela n'a que peu d'importance, si ce n'est de s'y retrouver dans un environnement du "monde réel" :)

Ajoutez les règles pour les numéros pilotes 1000 et 1900 vers le SIP Trunk ExchangeUM. La règle 0* permet de composer n'importe quel numéro préfixé par 0 et de passer le reste au SIP Trunk. Par exemple, composer 00112345678 passera 0112345678 au SIP Trunk Freephonie.



Note: OCS-MS est un SIP Trunk vers mon Mediation Server OCS 2007 R2 (oui ça marche aussi très bien!). Je compose 5xxxx pour appeler l'extension xxxx déclarée dans OCS (les règles de normalisation faisant le reste).

Maintenant à vous de jouer !!!

N'oubliez pas de créer votre UM IP Gateway dans la configuration UM d'Exchange, le Hunt Group qui va bien, et de l'associer avec le bon numéro pilote au bon UM Dial Plan.

Voilà, si je n'ai rien oublié (ce que je ne garanti pas vu que j'ai tapé cet article très très vite), votre environnement est prêt. Vous devriez vous retrouver dans un environnement fonctionnellement similaire à ce que nous avions avec Asterisk/Trixbox.

Post-mortem

Grâce à notre extension fictive, nous pouvons effectuer des appels depuis Exchange (Play-on-Phone, contacter un n° externe depuis l'annuaire...) sans devoir utiliser une "ruse" comme avec Asterisk. Bon point pour PBXnSIP.

Le MWI d'Exchange 2010 ne fonctionne cependant pas mieux. Tout comme avec Asterisk, PBXnSIP refuse les messages NOTIFY en dehors d'un dialogue SIP établi. Rigolo, quand on sait que Cisco Call Manager sait très bien le faire !

samedi 28 novembre 2009

TUTORIEL: Intégration Exchange 2007/2010, Trixbox/Asterisk et SIP Trunk Freephonie! (Seconde partie)

Dans la première partie, j'expliquais comment intégrer Exchange UM et Asterisk (sur base d'une Trixbox) avec un SIP Trunk.

L'état des lieux suite à cette première partie est celui-ci:
  • Asterisk est configuré et sait router vers Exchange UM
  • Exchange UM sait router vers Asterisk, mais cela n'est pas encore configuré
  • L'appel vers une extension non disponible sera redirigé vers Exchange UM
  • Tout utilisateur Asterisk peut appeler le "nombre pilote" de la messagerie vocale ou du standard automatique.
Nous allons dans un premier temps nous intéresser à la partie permettant de configurer la reception d'un appel avec un SIP Trunk Freephonie et de le rediriger directement vers le standard automatique Exchange.

Configuration d'une route entrante

Dans la première partie, je disais réserver l'extension 2000 pour un usage particulier. C'est ici que celle-ci intervient.

Avant de créer une route entrante, nous allons créer deux "Custom Destinations". Pour ceci, nous allons dans le menu "PBX" ==> "PBX Settings". Dans le panneau de gauche, aller dans l'onglet "Tools" puis cliquez sur "Custom Destinations".

Ajouter les destinations suivantes:

Outlook Voice Access
  • Custom Destination: app-eum,ova,1
  • Description: Outlook Voice Access
Exchange Auto Attendant
  • Custom Destination: app-eum,aa,1
  • Description: Exchange Auto Attendant
Explications:
  • Une "Custom Destination" permet de déclencher un contexte personnel tel qu'une application
  • Ici nous exécutons les sous-routines "ova" et "aa" de notre application "app-eum" que nous avons installé dans l'article précédent - La syntaxe correspond au macro language d'Asterisk
Nous pouvons maintenant créer une route entrante. Pour ceci il suffit d'aller dans l'onglet principal "Setup" puis dans la section "Inbound Call Control" et de cliquer sur "Inbound Routes".

De là, ajouter une route entrante:
  • DID Number: 2000
  • Set Destination
    • Sélectionner "Custom Destinations" ==> sélectionner "Exchange Auto Attendant"

Validez et appliquez les changements.

Configuration du SIP Trunk avec Freephonie

Créez un nouveau SIP Trunk avec les paramètres suivants:

Trunk name: Freephonie

PEER Details:
type=peer
context=from-pstn
username=09XXXXXXXX
secret=motdepassetopsecret
host=freephonie.net
fromuser=09XXXXXXXX
fromdomain=freephonie.net
insecure=port,invite
nat=yes
qualify=yes
disallow=all
allow=alaw&ulaw
dtmfmode=auto

USER Context: 09XXXXXXXX

Incoming Settings:
type=user
host=freephonie.net
disallow=all
allow=alaw&ulaw
dtmfmode=auto

Register String: 09XXXXXXXX:motdepassetopsecret@freephonie.net/2000

Validez la création de la route puis rechargez la configuration d'Asterisk.

Explications:
  • La section "PEER Details" permet d'appeler au travers du SIP Trunk Freephonie et contrôle ce contexte
  • La section "User Details" permet de contrôler le contexte des appels entrants
  • La valeur de "Register String" permet de s'authentifier auprès de Freephonie. Petite subtilité ici, le "/2000" permet de dirgier tous les appels entrants vers la route que nous avons créé précédemment, et qui porte donc le "faux DID" 2000.
Afin que les appels entrants soient bien dirigés vers votre Trixbox, assurez-vous que vous avez configuré votre compte Free en conséquence ("Rediriger les appels entrants vers le compte SIP").


Une fois cette modification effectuée, vous pouvez tester la configuration en appelant votre n°Freephonie.

Configuration de la route sortante via le SIP Trunk Freephonie

Pour créer la route sortante, allez dans l'onglet principal "Setup" puis dans la section "Basic" et de cliquer sur "Outbound Routes".

Modifier la route sortante par défaut afin qu'elle utilise le SIP Trunk Freephonie au lieu du Zaptel. Au passage, changez les règles de numérotation afin qu'elles correspondent à vos souhaits.

Ci-dessous un exemple:

Validez la création de votre route, puis appliquer les changements de configuration.

Une fois la route créée, vous devriez être capable d'appeler un numéro extérieur depuis votre SIP phone et une extension définie dans Asterisk/Trixbox (ex 2001, 2002, ...)

Configuration d'Exchange pour le "Play on Phone" et les appels sortants

Exchange UM a une fonctionnalité nommée "Play on Phone", qui permet, via Outlook Web Access/Outlook Web App de demander à Exchange de vous appeler sur un numéro que vous lui spécifiez.

Il est aussi possible d'activer les appels sortants au travers des standards automatiques, pour appeler des numéros présents dans les listes d'adresses Exchange ou dans les contacts personnels.

Pour que les fonctionnalités d'appels sortants fonctionnent, vous devrez configurer plusieurs éléments:
  • Dial Codes: au niveau de l'UM Dial Plan, permettant de reformer un numéro en fonction de lu pays/région du Dial Plan et permettant de déterminer le type de destination ("In Region" ou "International");
  • Dial Rule Groups: au niveau de l'UM Dial Plan, permettant de transposer un numéro en fonction de sa destination en un numéro formaté tel que l'UM IP Gateway (une passerelle ou un IP-PBX) l'attend.
Voici des exemples de Dial Codes et Dial Rule Groups:


Ensuite, il suffit d'autoriser (ou pas) les appels vers ces Dial Rules. Pour le "Play on Phone", cela se configure au niveau des UM Policies (stratégies UM).

Dans mon lab, j'ai par exemple une stratégie UM me permettant d'appeler des téléphones mobiles, tandis que la stratégie par défaut n'autorise que les 0[1-59]xxxxxxxx !


A partir de là, vous avez la capacité de vous faire appeler par Exchange sur un numéro français, il suffit d'aller dans Outlook Web App puis Options ==> Téléphone ==> Appelez le numéro...


Et là me direz vous "Non ça ne marche pas!!!". En effet, il faut savoir que dans notre cas Exchange UM appelle depuis l'extension "2xxx" telles que nous l'avions défini dans notre première partie.

Or, Asterisk n'est pas un Proxy SIP, c'est un Back-to-Back User Agent (B2BUA) -- si vous activez le debug sip sur Asterisk vous verrez clairement le problème:
  • Le serveur Exchange envoie une INVITE au numéro externe
  • Le serveur Asterisk répond avec un erreur 401 (non autorisé)
Le fait est que l'appelant dans notre scénario est, par exemple, 2001. Or cette extension est connue dans Asterisk et doit être authentifiée (avec un REGISTER) avant de pouvoir émettre un appel. Ceci malgré le fait que nous ayons un contexte "from-internal" et configuré un niveau bas de sécurité "insecure=invite,port" pour notre serveur Exchange. Asterisk refuse donc le "spoofing" d'identité, ce qui ne nous arrange pas dans notre cas...

J'ai trouvé deux parades:
  1. Ne pas mettre de "secret" sur l'extension qui doit pouvoir appeler via Exchange... L'extension n'ayant pas de mot de passe, un appel sans REGISTER préalable fonctionne!
  2. Utiliser le fameux UMOUTDIALPREFIX (par exemple, 5)
    • Créer un UM Dial Plan à 5 chiffres au lieu de 4
    • Lors de l'activation UM des utilisateurs, préfixez l'extension UM du chiffre choisi (par exemple, 2001 devient 52001)
    • Ajouter un Hunt Group dont le Pilot Number est 51000 et pointe vers le nouveau Dial Plan
    • Ajouter un Auto Attendant dont le Pilot Number est 51900
    • De là, il faut tout reconfigurer côté UM :(
Ensuite, il suffit de spécifier dans le fichier /etc/asterisk/global_custom.conf:

UMOUTDIALPREFIX = 5
UMVMPILOTNUMBER = 51000
UMAAPILOTNUMBER = 51900

Il ne sera plus possible d'appeler "facilement" des extensions Asterisk depuis Exchange (ex: au travers de l'Auto Attendant). Cela requerra une petite manipulation que je ne détaillerai que succinctement ici:
  • Créer un contexte "from-internal-Exchange" qui inclue le contexte "from-internal" - Définir ce contexte au niveau du SIP Trunk Exchange UM
  • Ajouter du code Asterisk dans ce contexte qui permet de tronquer le préfixe de l'extension UM lorsque le numéro appelé correspond à 52xxx
Voici ce qui conclue donc notre seconde partie, où nous avons intégré Exchange UM derrière Asterisk/Trixbox mais aussi et surtout notre SIP Trunk Freephonie.

Il va de soit qu'il est possible d'utiliser virtuellement n'importe quel SIP Trunk, voire même plusieurs numéros si votre fournisseur le supporte.

Dans ce dernier cas, il suffira de faire une route entrante par numéro, ce que j'aurai pu faire sans extension "2000" (l'intérêt de mon extension étant de pouvoir la retirer rapidement au niveau de mon SIP Trunk sans modifier la route entrante).

Post-mortem

Ce qui fonctionne bien:
  • Redirections vers la messagerie vocale
  • Accès aux standards automatiques Exchange UM
Ce qui fonctionne, mais au prix de quelques bidouilles:

  • Appels sortants, à cause de la façon dont Asterisk fonctionne - je conserve dans mon lab l'astuce de ne pas avoir de secret sur mes extensions, mais cela rend l'intégration non viable dans un environnement de production, à moins que cette fonctionnalité ne soit pas utilisée.
  • Il serait possible de mettre en oeuvre un Proxy SIP tel que SipX (qui sait aussi faire SIP Registar) et l'utiliser pour les appels sortants. Cela ajoute un serveur dans l'environnement et complifie légèrement notre environnement de tests, mais pourquoi pas...
Ce qui ne fonctionne pas du tout:
  • Indicateur de messages (MWI - Message Waiting Indicator) - Une fois encore Asterisk n'autorise pas la réception de messages de type NOTIFY en dehors d'un dialogue SIP (ayant donc commençé par un INVITE) ce qui a pour conséquence un retour avec une erreur 489 (Bad request).
  • Un patch est censé exister, il me semblait même qu'il était incorporé dans la 1.6.0. Si tel est le cas, j'ai dû rater quelque chose :p -- Il sera vraisemblablement incorporé dans la v1.6.2.

TUTORIEL: Intégration Exchange 2007/2010, Trixbox/Asterisk et SIP Trunk Freephonie! (Première partie)

Dans cette première partie nous allons aborder la configuration d'une Trixbox avec la messagerie unifiée d'Exchange 2007 ou Exchange 2010 (mon lab utilisant Exchange 2010).

Je passe les détails d'installation des deux parties, vous devez bien sûr avoir un environnement Exchange qui fonctionne parfaitement, donc avec tous les rôles requis installés (CAS, MBX, HTS, UM). Je prends donc l'hypothèse que tout fonctionne bien de ce côté là...

Votre Trixbox (http://www.trixbox.org/) doit utiliser Asterisk 1.6.x (qui supporte nativement le SIP/TCP (enfin!!!)) et disposer d'au moins une interface réseau routé vers le serveur Exchange UM. Pour la seconde partie, nous aurons besoin d'une interface réseau routée vers Internet (au travers de votre *Box) -- bien sûr ce n'est pas requis pour l'intégration Exchange UM.

Dans ma configuration j'ai donc:
  • eth0: interface "publique" - 192.168.1.7 ==> passerelle par défaut 192.168.1.1
  • eth1: interface "privée" - 192.168.100.7 ==> aucune passerelle mais une route statique car j'ai plusieurs sous réseaux vrituels (pour ajouter une route statique, lisez la documentation CentOS ici: http://www.centos.org/docs/5/html/5.1/Deployment_Guide/s1-networkscripts-static-routes.html)
  • Assurez vous que votre Trixbox a bien accès aux deux réseaux, qu'elle peut résoudre les noms internes et externes et qu'elle a bien accès à Internet.
  • N'hésitez pas à passer du temps pour vérifier tous ces points 
  • Effectuez ensuite une mise à jour complète de votre Trixbox avec la commande "yum -y update" puis redémarrez avec "reboot".
Pour administrer votre Trixbox vous devrez définir un mot de passe au compte "maint". Vous devez effectuer ceci puis un shell après installation et configuration avec la commande "passwd-maint".

L'interface d'administration de votre Trixbox est accessible par un navigateur (ex: http://192.168.1.7 depuis mon réseau "maison"). N'utilisez pas IE8 car celle-ci fonctionne mal sous le navigateur de Microsoft. Personnellement j'utilise Firefox... :°)

Définition des numéros/noms de la configuration Asterisk 
  • Nom de mon SIP Trunk: Exchange UM 
  • Numéro Pilote pour la messagerie vocale (Pilot Number): 1000
  • Numéro Pilote pour le standard automatique (Auto Attendant): 1900
Ces valeurs seront celles reprises ultérieurement dans la configuration personnalisée d'Asterisk. Si vous souhaitez utiliser d'autres valeurs, n'hésitez pas, mais n'oubliez pas de les changer où cela est nécessaire (en général elles apparaitront en rouge dans les explications/valeurs mentionnées dans l'article).

Configuration de l'environnement Asterisk

Avant toute chose, nous allons configurer certains fichiers permettant:
  • De définir des variables globales dans la configuration d'Asterisk, et donc d'être "propre" au regard de la logique de l'IP-PBX;
  • D'ajouter une macro permettant de prendre en charge la diversion vers Exchange sans traffiquer les fichiers natifs d'Asterisk/Trixbox.
  • D'ajouter une application permettant de prendre en charge les appels entrants depuis l'extérieur (nous verrons cela dans la configuration du SIP Trunk Freephonie).
Le but de ces manœuvres, vous l'aurez peut-être compris, est de minimiser l'impact sur la configuration initiale d'Asterisk, mais aussi d'éviter en cas de mise à jour de la Trixbox un écrasement "sauvage" de nos modifications.  Nous aurons aussi la capacité de gérer les appels entrants de plusieurs manières !

Vous pouvez utiliser un shell directement sur votre serveur Trixbox, ou utiliser un client SSH pour y accéder à distance. Utilisez l'éditeur de texte de votre choix pour créer ou modifier les fichiers. Sachez qu'il est possible de modifier les fichiers existants dans la configuration Trixbox (PBX => Config file editor), mais "l'éditeur" est particulièrement simpliste et désagréable à l'usage... 

/etc/asterisk/sip_general_custom.conf

Ce fichier nous permet d'ajouter le support du SIP/TCP pour Asterisk 1.6.x et autoriser les messages SIP de type redirection (302) hors d'Asterisk. Ceci est requis car Exchange UM gère la signalisation des appels entrants sur les ports 5060 (TCP) et 5061 (TLS) au travers du service Exchange UM mais redirige ceux-ci vers le service Speech Engine qui écoute sur d'autres ports (en fonction du "recyclage"), à savoir 5065/5067 en SIP/TCP et 5066/5077 en SIP/TLS.

La partie 'RTP' de la configuration n'est pas requise pour Exchange UM, mais me sert à l'intégration Asterisk/OCS 2007 R2 via mon Mediation Server. Pour information, certains IP-PBX ou certaines passerelles IP ne gèrent pas bien les appels en attente (On Hold) et ont tendance à ne plus envoyer de paquets RTP/RTCP dans ce cas. Par conséquent, le Mediation Server (qui respecte les RFC de ce point de vue) considère son partenaire HS (Hors Service) et donc clos l'appel.

; Enables SIP/TCP support for Asterisk (default post is 5060)
;
tcpenable=yes

; Enables 302/Redirect messages outside of Asterisk
; Required for Exchange UM to redirect from port 5060 (UM listening port) to 5065/5067 (Speech Engine)
;
promiscredir=yes

; Raises RTP timeouts
; This is required to predvent dropping a call when it has been put on hold
; As per RFCs, OCS 2007 R2 Mediation Server expects RTCP packets to still being sent
; while on hold and uncertified IPPBXes and IP Gateways typically don't follow this RFC rule
; All values below are in seconds.
;
rtptimeout=30 ; A value of 0 means 'infinite'
rtpholdtimeout=300 ; A value of 0 means 'infinite'
rtpkeepalive=20 ; A value if 0 means 'no keepalive'

/etc/asterisk/globals_custom.conf

; Exchange UM Configuration
UMSIPTRUNK = ExchangeUM
UMOUTDIALPREFIX =
UMVMPILOTNUMBER = 1000
UMAAPILOTNUMBER = 1900

La variable UMOUTDIALPREFIX permet d'avoir un espace d'extensions séparé entre Asterisk et Exchange. Par exemple, si les extensions Asterisk sont sous forme XXXX, alors la diversion sera faite pour l'extension Exchange XXXX. Ainsi si le prefixe est 5, l'extension UM pour l'extension Asterisk 2001 sera 52001 Dans ce cas, le Dial Plan Exchange sera configuré pour une longueur d'extension de 5.

Je reviendrai plus tard sur le pourquoi-du-comment et l'interêt du préfixe... Pour l'instant faisons sans... :)

/etc/asterisk/extensions_custom.conf

Le fichier extensions_custom.conf est inclus par le fichier extensions.conf et permet de définir des macros ou applications développées pour un besoin spécifique. C'est ce que nous allons faire ici.

Dans ce fichier, nous allons donc créer:
  • Une macro nommée "eum-vm" (en-tête [macro-eum-vm]) qui permet de gérer la diversion vers Exchange si l'extension est activé pour Exchange UM (nous reviendrons sur le "comment" lors de la configuration de nos extensions/utilisateurs Asterisk)
  • Une application nommée "app-eum" (en-tête [app-eum]) qui va permette de définir des destinations personnalisées ("Custom Destinations") que nous utiliserons plus tard. Nous distinguons deux procédures stockées dans cette application: ova et aa. "ova" pour Outlook Voice Access et "aa" pour "Auto Attendant".

[macro-eum-vm]
exten => s,1,NoOp(Entering Exchange UM Voicemail)

exten => s,n,Set(EXTTOCALL=${ARG1})
exten => s,n,Set(VMBOX=${UMDIALPREFIX}${EXTTOCALL})
exten => s,n,Set(DIALSTATUS=${ARG2})
exten => s,n,Set(REASON=unavailable)

exten => s,n,Macro(get-vmcontext,${EXTTOCALL})
exten => s,n,GotoIf($["${VMCONTEXT}"="eum"}]?eum,1)
exten => s,n,NoOp(Leaving Exchange UM Voicemail because user is not EUM-enabled)

exten => eum,1,GoSub(diversion-${DIALSTATUS},1)
exten => eum,n,SIPAddHeader(Diversion: <tel:${vmbox}>\;reason=${REASON}\;screen=no\;privacy=off)
exten => eum,n,Dial(SIP/${UMSIPTRUNK}/${UMVMPILOTNUMBER})
exten => eum,n,NoOp(Extension is reporting ${DIALSTATUS} but is not passing to Exchange UM!)

exten => diversion-BUSY,1,Set(REASON=user-busy)
exten => diversion-BUSY,n,Return

exten => diversion-NOANSWER,1,Set(REASON=no-answer)
exten => diversion-NOANSWER,n,Return

exten => diversion-CHANUNAVAIL,1,Set(REASON=unavailable)
exten => diversion-CHANUNAVAIL,n,Return

exten => _diversion-.,1,Set(REASON=unavailable)
exten => _diversion-.,n,Return

[app-eum]
exten => ova,1,NoOp("Incoming call to Exchange UM Outlook Voice Access")
exten => ova,n,Dial(SIP/${UMSIPTRUNK}/${UMVMPILOTNUMBER})
exten => ova,n,NoOp("Call is not passing to Exchange UM!")
exten => ova,n,Playback(sorry-youre-having-problems&goodbye)
exten => ova,n,Macro(hangupcall,)

exten => aa,1,NoOp("Incoming call to Exchange UM Auto Attendant")
exten => aa,n,Dial(SIP/${UMSIPTRUNK}/${UMAAPILOTNUMBER})
exten => aa,n,NoOp("Call is not passing to Exchange UM!")
exten => aa,n,Playback(sorry-youre-having-problems&goodbye)
exten => aa,n,Macro(hangupcall,)

Explications:
  • La macro "eum-vm" recupère le contexte de messagerie vocale de l'extension (VMCONTEXT). Si celui-ci est positionné à "eum", alors Asterisk effectuera un appel vers le numéro pilote défini (que nous configurerons dans Exchange)
  • L'application "app-eum" contient les procédures stockées définies par le mot-clef "exten" et les valeurs "<nom>,<ligne>,<commande>", ce qui permet d'effectuer des sauts directs depuis d'autres contextes/macros/applications.

/etc/asterisk/extensions_override_freepbx.conf

Le problème majeur d'Asterisk et de la Trixbox est le manque de souplesse dans la configuration par l'interface (Trixbox). Aussi, il n'est pas prévu de prendre en compte un autre système de messagerie vocale que celui inclus dans l'application (au contraire de SipX, qui est prévu pour...).

L'idée est donc d'utiliser le fichier extensions_override_freepbx.conf, qui permet d'écraser une macro existante par une macro "personnelle". Nous allons donc écraser la macro "exten-vm" qui gère l'appel aux extensions/groupes et redirige vers la messagerie vocale si l'extension est activée pour, ou gère l'échec de l'appel sinon...

En utilisant cette méthode, nous conservons la logique initiale d'Asterisk/Trixbox, tout en rajoutant la gestion de la messagerie vocale d'Exchange avant celle de la messagerie vocale native.

Il suffit donc de copier-coller la macro "exten-vm" depuis le fichier extensions.conf dans le fichier extensions_override_freepbx.conf et d'ajouter les lignes en rouge. L'appel a la macro "eum-vm" est donc effectué avant la vérification de la messagerie vocale intégrée. On passe les arguments EXTTOCALL et DIALSTATUS qui correspondent au numéro d'extension appelé et à la raison d'échec de l'appel.

Voici ce que ça donne:

; Ring an extension, if the extension is busy or there is no answer send it
; to voicemail
; ARGS: $VMBOX, $EXT
[macro-exten-vm]
exten => s,1,Macro(user-callerid)
exten => s,n,Set(RingGroupMethod=none)
exten => s,n,Set(VMBOX=${ARG1})
exten => s,n,Set(EXTTOCALL=${ARG2})
exten => s,n,Set(CFUEXT=${DB(CFU/${EXTTOCALL})})
exten => s,n,Set(CFBEXT=${DB(CFB/${EXTTOCALL})})
exten => s,n,Set(RT=${IF($[$["${VMBOX}"!="novm"] | $["foo${CFUEXT}"!="foo"]]?${RINGTIMER}:"")})
exten => s,n,Macro(record-enable,${EXTTOCALL},IN)
exten => s,n,Macro(dial,${RT},${DIAL_OPTIONS},${EXTTOCALL})
;
exten => s,n,Macro(eum-vm,${EXTTOCALL},${DIALSTATUS})
;
exten => s,n,GotoIf($[ $["${VMBOX}" != "novm"] & $["${SCREEN}" != ""] & $["${DIALSTATUS}" = "NOANSWER"] ]?exit,return)
exten => s,n,Set(SV_DIALSTATUS=${DIALSTATUS})
exten => s,n,GosubIf($[$["${SV_DIALSTATUS}"="NOANSWER"] & $["${CFUEXT}"!=""] & $["${SCREEN}" = ""]]?docfu,1) ; check for CFU in use
on no answer
exten => s,n,GosubIf($[$["${SV_DIALSTATUS}"="BUSY"] & $["${CFBEXT}"!=""]]?docfb,1) ; check for CFB in use on busy
exten => s,n,Set(DIALSTATUS=${SV_DIALSTATUS})
exten => s,n,NoOp(Voicemail is '${VMBOX}')
exten => s,n,GotoIf($["${VMBOX}" = "novm"]?s-${DIALSTATUS},1) ; no voicemail in use for this extension
exten => s,n,NoOp(Sending to Voicemail box ${EXTTOCALL})
exten => s,n,Macro(vm,${VMBOX},${DIALSTATUS},${IVR_RETVM})

; Try the Call Forward on No Answer / Unavailable number
exten => docfu,1,Set(RTCFU=${IF($["${VMBOX}"!="novm"]?${RINGTIMER}:"")})
exten => docfu,n,Dial(Local/${CFUEXT}@from-internal/n,${RTCFU},${DIAL_OPTIONS})
exten => docfu,n,Return

; Try the Call Forward on Busy number
exten => docfb,1,Set(RTCFB=${IF($["${VMBOX}"!="novm"]?${RINGTIMER}:"")})
exten => docfb,n,Dial(Local/${CFBEXT}@from-internal/n,${RTCFB},${DIAL_OPTIONS})
exten => docfb,n,Return

exten => s-BUSY,1,NoOp(Extension is reporting BUSY and not passing to Voicemail)
exten => s-BUSY,n,GotoIf($["${IVR_RETVM}" = "RETURN" & "${IVR_CONTEXT}" != ""]?exit,1)
exten => s-BUSY,n,Playtones(busy)
exten => s-BUSY,n,Busy(20)

exten => s-NOANSWER,1,NoOp(Extension is reporting NOANSWER and not passing to Voicemail)
exten => s-NOANSWER,n,GotoIf($["${IVR_RETVM}" = "RETURN" & "${IVR_CONTEXT}" != ""]?exit,1)
exten => s-NOANSWER,n,Return

; Anything else comes here
exten => _s-.,1,Noop(IVR_RETVM: ${IVR_RETVM} IVR_CONTEXT: ${IVR_CONTEXT})
exten => _s-.,n,GotoIf($["${IVR_RETVM}" = "RETURN" & "${IVR_CONTEXT}" != ""]?exit,1)
exten => _s-.,n,Playtones(congestion)
exten => _s-.,n,Congestion(10)

; Short burst of tones then return
exten => exit,1,Playback(beep&line-busy-transfer-menu&silence/1)
exten => exit,n(return),MacroExit()

Rechargement de la configuration Asterisk

Maintenant que nous avons configuré nos personnalisations, il est nécessaire qu'elles soient prises en compte :)
Le plus simple est de se connecter au shell et de taper asterisk.reload ou alors asterisk -r -x reload.

Création du SIP Trunk et de la route vers Exchange

Maintenant que la configuration est prise en compte, nous allons créer notre SIP Trunk vers Exchange.

Dans la console Trixbox, allez dans le menu PBX ==> PBX Settings ==> (Basic) ==> Trunks. Ajoutez alors un SIP Trunk ("Add SIP Trunk") avec les paramètres suivants:
Si vous voulez faire un copier-coller:

type=friend
host=192.168.101.20
context=from-internal
transport=tcp
insecure=invite,port
qualify=yes
canreinvite=no
disallow=all
allow=alaw&ulaw
dtmfmode=auto


Bien sûr, vous devez modifier l'attribut "host" en spécifiant l'adresse IP ou le nom d'hôte complet de votre serveur Exchange UM (ex: exum.domaine.local). J'utilise l'adresse IP pour m'affranchir de problèmes éventuels de résolution de nom, et par fainéantise aussi... :)

Explications:
  • context ==> Le contexte "from-internal" permet à Exchange d'appeler au travers d'Asterisk. L'utilisation d'un autre contexte est possible, mais Exchange ne sera pas autorisé à appeler vers l'extérieur à moins de personnaliser le contexte pour y inclure des routes.
  • insecure ==> permet d'effectuer des dialogues SIP depuis Exchange UM (pour les appels sortants) en mode "anonyme" -- ici, nous restreignons sur le verbe "INVITE" (qui initie un dialogue SIP) et sur le port. Certains utilisent "insecure=very" qui fonctionne aussi mais qui pour le coup est vraiment non sécurisé !
  • transport ==> permet de dire à Asterisk que ce SIP Trunk utilise le SIP/TCP, car sinon le transport par défaut est UDP.
  • disallow/allow ==> permet de retirer tous les codecs supportés puis de n'autoriser que G.711 a-Law et u-Law dans la négociation média (protocole SDP encapsulé dans le dialogue SIP)
  • dtmfmode ==> permet de négocier le meilleur mode pour la prise en charge du Dial Tone Multi-Frequencing au travers du codec utilisé. J'ai mis cette valeur car j'avais des soucis depuis des appels effectués par mon GSM. Il est important aussi que cela soit géré au niveau du SIP Trunk depuis Freephonie (ou tout autre SIP Trunk depuis lequel on accepte de router vers Exchange)
Voici notre SIP Trunk créé, il suffit maintenant de créer une route vers Exchange. Dans la console Trixbox, allez dans le menu PBX ==> PBX Settings ==> (Basic) ==> Outbound Routes.

Ajoutez alors une route ("Add Route") avec les paramètres suivants:
Explications:
  • Route Name: ExchangeRoute ==> mettez le nom que vous voulez :)
  • Dial Patterns: 1XXX ==> Permet de router tous les numéros à 4 chiffres commençant par 1. Mes numéros "pilote" étant 1000 et 1900, ceci explique cela...
  • Trunk Sequence ==> choissez le SIP Trunk ExchangeUM créé précédemment.
Assurez-vous que la route est prioritaire par rapport aux routes existantes, dont en particulier la route "Outbound". Une fois toutes ces modifications appliquées, cliquez sur "Apply configuration changes" en haut de la console de gestion du PBX.

Configuration des extensions/utilisateurs Asterisk

Maintenant que nous sommes prêts à nous connecter avec Exchange, nous allons créer des extensions/utilisateurs Asterisk. Dans mon environnement les extensions sont dans la plage 2001-2999, j'ai donc créé les extensions 2001, 2002, 2003... Je réserve 2000 pour un usage ultérieur (gestion des appels entrants).

Dans la console Trixbox, allez dans le menu PBX ==> PBX Settings ==> (Basic) ==> Extensions. Ajoutez alors aux moins deux extensions avec les paramètres suivants: 
  • Device Type: Generic SIP Device
  • Extension: 2XXX (où XXX est compris entre 001 et 999)
  • Display Name: Ce que vous voulez
  • Voicemail & Directory:
    • Status: Enabled
    • VM Context: eum
Voici ce que ça donne:

Explications:
  • Activation de la prise en charge de la messagerie vocale pour cette extension
  • Le VM Context permet de mettre le mot clef "eum" permettant à notre macro d'effectuer la diversion vers le numéro pilote Exchange UM. Ainsi, il est possible de basculer simplement du système de messagerie vocale intégré à celui d'Exchange... Pratique ;)
Notes:
  • Trixbox va vous avertir de deux choses:
    • Si vous n'avez pas défini de "secret" (en général il s'agit d'un PIN), l'extension pourra émettre des appels sans être authentifiée. Bien sûr dans le monde réel, mettre un mot de passe est une bonne idée, mais nous verrons plus tard pourquoi cela vas nous poser un problème...
    • Vous n'avez pas mis de "secret" sur la messagerie vocale... Pour cause, le PIN est géré par Exchange. Vous pouvez en mettre un ici, mais il ne servirait à rien.
N'oubliez pas de valider vos changements à coups de "Apply configuration changes" en haut de la console de gestion du PBX.

Configuration d'Exchange

Dans Exchange, nous devons configurer:
  • Un UM Dial Plan
    • Le mien est nommé FR-0001 et configuré ainsi:
      • Type: TelephoneExtension
      • Voip Security: Unsecured
      • Number of digits in extensions: 4
      • Sur Exchange 2010, un "Country/Region Code" est requis, utilisez 33 pour la France.
  • Une UM IP Gateway
    • Name: Trixbox
    • IP address: 192.168.x.y (l'IP interne de votre Trixbox)
    • Ne pas associer un UM Dial Plan par défaut (autant faire propre et l'associer au travers du Hunt Group)
  • Un UM Hunt Group
    • Name: HG-0001
    • Pilot Number: 1000
    • Associated Dial Plan: FR-0001
  • Un UM Auto Attendant
    • Name: FR-0001_AA
    • Pilot Number: 1900
Notes:
  • Ajoutez les packs de langue de votre choix sur votre serveur Exchange UM
  • N'oubliez pas d'associer votre serveur Exchange UM à l'UM Dial Plan nouvellement créé !!!
  • Choisissez la langue par défaut de votre Dial Plan et de votre Auto Attendant une fois le serveur associé car la liste des langues disponibles est générée en fonction des langues disponibles sur le (ou les) serveur(s) associé(s)
  • N'oubliez pas de configurer la stratégie créée par défaut (FR-0001 Default Policy) afin de simplifier la securité des codes PIN (par exemple: 4 digits, empêcher l'expiration, autoriser les PIN non complexes (cocher "Allow common patterns in PIN")
Attendez quelques minutes que la configuration soit prise en compte sur le serveur UM.

Activez alors la Messagerie Unifiée sur vos utilisateurs dont l'extension téléphonique correspond avec celle d'Asterisk/Tribox. Assurez vous que l'utilisateur A correspond à l'extension A, utilisateur B à l'extension B, etc etc...

Premiers tests, commençons (enfin) à "jouer" !

Voici les actions permettant de valider que votre intégration est un succès:
  • Connectez un SIP Phone type X-Lite, eyeBeam (payant!) ou autre... à votre Asterisk. Utilisez par exemple l'extension 2002.
  • Appelez l'extension 2001. Celle-ci étant indisponible, la diversion va s'effectuer vers Exchange UM. Magique, vous pouvez laisser un message !
  • Composez maintenant l'extension 1000, vous tombez sur Outlook Voice Access
    • Entrez un numéro d'extension, par exemple 2001 puis le PIN Exchange UM correspondant
    • Pilotez votre BàL avec la voix !
  • Composez maintenant l'extension 1900, vous tombez sur votre Auto Attendant
    • Prononcez le nom de quelqu'un pour être mis en relation!
    • Selon la configuration de votre Auto Attendant, il faudra recourir à quelques modifications...
Avant de conclure cette première partie, voici un aperçu de ma configuration:



Vous l'autrez compris, les élements ci-dessous vont permettre d'introduire la configuration des appels sortants d'Exchange UM vers le reste du monde.

Nous verrons donc ces points dans la prochaine partie:
  • Configuration du SIP Trunk vers Freephonie
  • Configuration du routage Sortant/Entrant au travers du SIP Trunk Freephonie
  • Configuration des appels sortants depuis Exchange
  • Configuration des appels entrants vers Exchange
D'ici là, amusez vous bien !!!!

Quelques astuces si cela ne fonctionne pas:
  • Depuis un shell Linux, utilisez asterisk -r pour vous connecter à la console Asterisk
  • De là, vous verrez "sans rien faire" les commandes liées aux macros et contextes s'exécuter lors d'un appel. Assurez vous que les macros que nous avons définies au début de cet article soient bien prises en compte.
  • Si vous voulez diagnostiquer les messages SIP, utilisez sip set debug ip 192.168.x.x (où bien sûr 192.168.x.x correspond à l'adresse IP de votre serveur Astrisk/Trixbox)