Communications et collaboration

Pilotage vocal d'OCS 2007

Rajesh Ramanathan

En un coup d'œil :

• Appels avec OCS 2007
• Mode de sécurisation des appels
• Conversations multimodales dans OCS
• Intégration avec la messagerie unifiée d'Exchange pour la messagerie vocale

Sommaire

Appels vocaux de base
Utilisation des numéros de téléphone
Appels sécurisés
Franchissement des NAT et pare-feu
Routage des numéros de téléphone
Routage entrant
Rapports qualité et résolution des incidents
Vue d'ensemble
Comportement multimodal et conversations
Messagerie vocale
Conclusion

La première partie de cette série sur Microsoft Office Communication Server (OCS) 2007 expliquait comment OCS reprenait les points forts de Live Communication Server (LCS) 2005 pour mettre en place

une messagerie instantanée améliorée pour les entreprises et des fonctionnalités de présence, ainsi que des supports avancés et une fonctionnalité téléphonique (voir l'édition de février 2008 de TechNet Magazine sur technet.microsoft.com/magazine/cc194409). Le présent article permet d'approfondir l'aspect VoIP (Voice over IP). J'expliquerai comment de simples appels vocaux sont passés dans le système OCS et je présenterai la technologie couche par couche, de façon à ajouter chaque composant à la fonctionnalité correspondante.

Comme mentionné dans l'article précédent, OCS peut être configuré pour fournir des services de téléphonie sous plusieurs configurations :

Enterprise Voice Cette solution de communications unifiées complète a recours à OCS, ainsi qu'au serveur Microsoft® Mediation sans nécessiter de PBX. La messagerie unifiée d'Exchange apporte des fonctionnalités de messagerie vocales à ce système. Je ferais référence aux utilisateurs de ce service sous la forme « utilisateurs UC » dans le reste de cet article. J'utiliserai également le terme « point de terminaison UC » pour faire référence à un client dans cette configuration.

Enterprise Voice avec intégration de PBX Cette configuration permet aux utilisateurs de bénéficier de tous les avantages des communications unifiées tout en conservant les téléphones PBX existants sur leur bureau. Elle permet de configurer OCS et les PBX en parallèle de façon à ce que les appels entrants puissent atteindre les points de terminaison Office Communicator et PBX de façon simultanée. Le PBX possède toujours le routage d'appel et fournit les services de messagerie vocale.

Contrôle distant des appels Cette fonctionnalité utilise le téléphone PBX en tant que téléphone principal et permet de contrôler le téléphone via le client Office Communicator.

Appels vocaux de base

La section suivante porte sur le traitement des utilisateurs d'Enterprise Voice. Les appels vocaux simples sont configurés dans le système OCS à l'aide du mécanisme SIP INVITE, tel qu'il est décrit dans RFC 3261. Le serveur OCS tient le rôle d'un proxy similaire à un administrateur qui relaie des messages entre les clients (ou des points de terminaison). Les nouveaux SIP INVITE proviennent de clients lorsqu'une session en temps réel, telle qu'un appel ou une session de messagerie immédiate, est créée. Si INVITE est validé avec une réponse (dans ce cas, le point de terminaison distant envoie une réponse 200 OK), l'appel est établi (voir figure 1).

Figure 1 Format INVITE et 200 OK

INVITE sip:bob@example.com SIP/2.0
To: <sip:bob@example.com>
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:alice@xyz.example.com
Content-Type: application/sdp
Content-Length: 156

**Note: Alice Audio SDP payload not shown**

SIP/2.0 200 OK
To: <sip:bob@example.com>;tag=f5c728454a;epid=e73443245
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:bob@xyz.example.com
Content-Type: application/sdp
Content-Length: 160

**Note: Bob Audio SDP payload not shown**

Dans la figure 2, Alice appelle Bob en choisissant Communicator Call dans Office Communicator (OC) 2007 et OC 2007 envoie un signal INVITE à l'URI SIP de Bob (sip:bob@exemple.com). Le signal INVITE comporte le descripteur de session audio (appelé SDP, pour le protocole SDP - Session Description Protocol) des points de terminaison multimédia où Alice peut recevoir les données audio. OCS transmet le signal INVITE aux points de terminaison SIP enregistrés de Bob (par exemple, Communicator Phone Edition et Communicator Desktop). Le signal INVITE contient un en-tête De provenant de sip:alice@exemple.com. Ces informations sont utilisées par les points de terminaison client de Bob lors d'une recherche de nom inversée, RNL (Reverse Name Lookup), portant sur (Alice) et à afficher dans la notification d'appel entrant.

Figure 2 Routage d'un appel vers plusieurs points de terminaison (cliquer sur l'image pour l'agrandir)

Le GRUU (Globally Routable User Agent URI) s'affiche pour chaque point de terminaison. Le GRUU identifie de façon unique le point de terminaison SIP et s'obtient pendant le processus d'enregistrement du serveur OCS. L'adresse GRUU permet de router des messages SIP. Ainsi, lorsque l'appel est pris par un point de terminaison, les signalisations SIP suivantes pour les autres opérations en cours d'appel peuvent être transmises entre les points de terminaison à l'aide de l'adresse GRUU.

La figure 3 poursuit le processus, dans lequel Bob répond depuis le bureau Communicator. La session OC de Bob envoie un message 200 OK indiquant qu'il peut recevoir des données audio. Dès que le proxy OCS détecte la réponse d'un point de terminaison, il annule l'appel aux autres points de terminaison Communicator Phone Edition. Lorsque la réponse 200 OK atteint le point de terminaison Communicator d'Alice, les deux points de terminaison Communicator disposent d'informations suffisantes (ports IP, paramètres de chiffrement, et ainsi de suite) pour lire le média.

Figure 3 Réponse à partir d'un point de terminaison (cliquer sur l'image pour l'agrandir)

Utilisation des numéros de téléphone

Jusqu'à présent l'utilisateur cliquait sur Communicator Call (Appel Communicator) pour créer une invitation. Le processus est un peu différent lorsque l'utilisateur sélectionne ou tape un numéro de téléphone :

• Le client normalise en premier lieu le numéro de téléphone et le représente sous forme d'URI TEL, qui décrit les ressources identifiées par les numéros de téléphone comme indiqué dans RFC 3966.
• Dans la mesure où le serveur OCS reconnaît uniquement les URI SIP, les clients convertissent l'URI TEL sous forme d'URI SIP en ajoutant le suffixe de domaine et une balise user=phone.
• Si le numéro correspond à un utilisateur interne, OCS route l'invitation de façon directe. Si le numéro est externe, l'invitation est routée vers la passerelle SIP-PSTN la plus proche.

Certains appels vers le réseau public commuté (RTC) nécessitent la mise en place du chemin multimédia avant de répondre à l'appel, de façon à ce que les annonces distantes puissent être lues ou que des chiffres supplémentaires soient rassemblés pour compléter l'appel. Dans ce genre de scénario, la passerelle RTC envoie l'indicateur 183 de progression de session avec un SDP audio. Communicator utilise ces informations pour configurer un chemin multimédia bidirectionnel avec un point de terminaison de destination avant la prise d'appel par l'utilisateur distant.

Une fois le chemin multimédia initial configuré, Communicator active la tonalité de signalement du téléphone (DTMF - Dual-Tone Multi-Frequency, multifréquence en code) de façon à permettre à l'utilisateur d'entrer les chiffres supplémentaires requis par le système à distance. Les chiffres DTMF entrés sont envoyés sur le chemin multimédia sous forme de paquets RFC 2833. La passerelle RTC se charge de générer les signaux DTMF nécessaires côté RTC.

Si Bob a activé la sonnerie simultanée sur son téléphone cellulaire, le proxy OCS route l'appel vers la passerelle et fait sonner tous les points de terminaison Communicator de Bob en même temps. Dans ce type de scénario, le proxy OCS indique que la bifurcation est active dans la réponse 183 de progression de session, et ceci permet force Communicator à établir un canal multimédia dédié aux réponses vers la passerelle RTC.

Appels sécurisés

L'une des principales fonctionnalités des appels vocaux configurés par OC est que le support est chiffré par défaut au moyen du protocole SRTP (Secure Real-Time Transport Protocol), comme défini dans RFC3711. Le protocole SRTP assure au trafic RTP la confidentialité, l'authentification de messages et la protection contre les répétitions. Lors de la configuration des appels, les clients négocient les fonctionnalités de sécurité entre eux et échangent des clés cryptographiques dans le cadre du mécanisme INVITE.

Le paramètre de chiffrement par défaut pour OC est « optional » (facultatif), ce qui permet à deux points de terminaison OC de configurer un canal multimédia chiffré. Ce paramètre peut être réglé par l'administrateur en fonction des besoins de mise en conformité de l'organisation. Par exemple, vous pouvez le rendre plus strict de façon à imposer le chiffrement sur tous les appels ou il peut être désactivé.

Franchissement des NAT et pare-feu

Les clients du système OCS ont recours à la technologie ICE (Interactive Connectivity Establishment) pour assurer une connectivité multimédia aux utilisateurs derrière les périphériques de conversion réseau (NAT) et les pare-feu, sans modifier les composants NAT existants. La technologie ICE est en cours de standardisation par Internet Engineering Task Force (IETF). Chaque client a connaissance du serveur audio/vidéo (A/V) Edge qui le dessert par l'intermédiaire d'un mécanisme d'attribution de privilèges d'accès et maintient un lien authentifié vers le serveur A/V Edge pendant l'ouverture de session.

Avant de téléphoner, le client alloue des ressources aux emplacements de connectivité possibles (les adresses et les ports, également appelés des candidats) sur le serveur Edge A/V (pour le relais multimédia), sur le NAT, voire sur le client hôte. Lorsque la commande INVITE du protocole SIP (Session Initiation Protocol) est envoyée, il inclut ces informations de connectivité dans la commande INVITE. La réponse 200 OK contient des informations similaires sur l'homologue. Lorsque chaque point de terminaison comporte une liste de candidats homologues, un mécanisme complexe de classement et de vérification sélectionne le chemin optimal entre les deux homologues et avec lequel le média est sûr d'aboutir.

Routage de numéros de téléphone

Le routage des numéros de téléphone rend plus complexe le mécanisme d'appel de base en raison des facteurs suivants :

• Les entreprises peuvent adopter différents plans de numérotation en interne pour la numérotation abrégée.
• Les numéros peuvent être enregistrés sous des formats non standard (par exemple, les utilisateurs peuvent avoir enregistré des chaînes à sept chiffres dans Microsoft Office Outlook®).
• Différentes stratégies peuvent être associées à différents numéros sortants. Par exemple, la numérotation de numéros internationaux peut être bloquée pour certains utilisateurs.

Le système OCS nécessite des numéros de téléphone au format RFC 3966 TEL URI afin de les router correctement. Les numéros qui ne sont pas à ce format peuvent être convertis avant que le client envoie une commande INVITE. Le diagramme de la figure 4 indique comment ceci se produit dans le système OCS.

Figure 4 Routage des numéros de téléphone (cliquer sur l'image pour l'agrandir)

Les numéros mis à la disposition du client peuvent provenir de sources diverses. Les numéros prénormalisés proviennent du service de carnet d'adresses et peuvent comporter des règles de normalisation définies par l'administrateur pour la conversion des numéros au format normalisé E.164. Lorsqu'un client envoie une commande INVITE SIP au numéro normalisé, OCS applique un processus de conversion pour mapper le numéro à un utilisateur interne.

• L'étape 1 indique que les numéros qui entrent dans le système sont uniques (normalisés suivant le plan de numérotation E.164) ou avec un contexte téléphonique qui identifie l'emplacement. Ces numéros sont envoyés au serveur au sein du paramètre INVITE SIP. OCS route INVITE vers le processus de conversion.
• Le processus de conversion (étape 2) tente de mapper le numéro de téléphone avec un point de terminaison UC au moyen d'un RNL côté serveur. La conversion permet d'identifier la voie de routage sortant ou vers un utilisateur UC ou de faire échouer l'appel avec un code 4xx si le numéro ne peut pas être converti correctement.
• Si le numéro est converti en un numéro non UC ou externe, il est envoyé au composant de routage sortant, qui redirige le paramètre INVITE vers la passerelle SIP-RTC appropriée pour y effectuer des traitements supplémentaires, après avoir appliqué des stratégies au numéro correspondant à l'appelant (étape 3A). Le routage sortant se charge de l'équilibrage de la charge de l'appel sur les différentes passerelles ou d'employer des passerelles différentes si nécessaire. Le processus de routage sortant peut faire échouer ou refuser l'appel et renvoyer un code de réponse SIP 403 si l'accès est interdit pour un numéro donné. Le routage sortant ne s'applique que lorsque l'appelant est un utilisateur UC. Lorsque ce n'est pas le cas, OCS tente d'utiliser les voies statiques vers les passerelles configurées pour cet URI.
• Si le numéro est converti en un numéro d'utilisateur UC, le paramètre INVITE est routé vers l'URI SIP de cet utilisateur (étape 3B). Le routage entrant est une fonction OCS qui s'applique uniquement aux utilisateurs UC et à tous les appels ciblés vers l'URI SIP. Comme vous pouvez le constater, le routage entrant applique des règles d'expiration des sonneries, de transfert d'appel et de transfert des messages vocaux pour l'utilisateur UC.

Le numéro qui résulte du processus de normalisation peut varier en fonction de l'emplacement du client. Les administrateurs peuvent configurer les profils d'emplacement et appliquer des règles de conversion de numéros spécifiques à un emplacement donné, telles que le fonctionnement d'un code à quatre chiffres à cet emplacement. Chaque utilisateur UC est associé à un profil d'emplacement et tous les clients du système téléchargent les règles spécifiques propres à leurs profils d'emplacement au moyen de l'attribution de privilèges d'accès. Nous allons voir plus en détails le routage entrant.

Routage entrant

Les règles de routage entrant spécifient la façon dont les appels vers un utilisateur doivent être routés en présence ou en l'absence de clients inscrits dans le système. Le composant de routage entrant prend également en charge l'application de règles de présence en fonction de l'appel entrant. Par exemple, il peut transférer les appels entrants vers la messagerie vocale si l'utilisateur a défini l'état de présence sur Ne pas déranger. Le routage entrant tient compte des niveaux du conteneur de présence et refuse automatiquement les appels de rejet des utilisateurs figurant dans les conteneurs bloqués. La figure 5 affiche le résumé des options prises en charge par le composant de routage entrant d'OCS.

Figure 5 Fonctionnalités de routage entrant

Les règles de routage entrant sont chargées sur le serveur sous forme de schéma XML, parmi les informations de type « self-provisioning » de l'utilisateur. La figure 6 présente le fonctionnement du routage entrant. Un appel entrant destiné à un utilisateur du système OCS sonne sur le poste de l'utilisateur par défaut (ici, « Moi »). Si l'appel n'est pas pris pendant la période de sonnerie, il est transféré vers la messagerie vocale par défaut. L'utilisateur peut alors modifier la configuration par défaut en procédant au transfert immédiat vers un numéro, une autre personne ou directement vers la messagerie vocale.

Figure 6 Routage d'appels (pendant les heures ouvrables) (cliquer sur l'image pour l'agrandir)

Tout appel transféré immédiatement à une autre personne ou un autre numéro entraîne l'application des règles de routage entrantes à cette personne ou ce numéro. L'utilisateur peut également définir des transferts d'appels restés sans réponse vers un autre numéro ou une autre personne.

Lorsque l'utilisateur sélectionne l'option Appliquer uniquement durant mes heures ouvrables Outlook des règles de transfert, les règles qui s'affichent dans la figure 6 s'appliquent uniquement pendant les heures ouvrables et le comportement par défaut, à savoir l'appel des points de terminaison enregistrés, s'applique en dehors de ces heures. Ce comportement implique que l'organisation a déployé Microsoft Exchange Server 2007 et les clients Outlook 2007, car Communicator reprend les définitions d'heures ouvrables du service Web d'Exchange 2007 et la prise en charge de la découverte automatique d'Outlook 2007 pour déterminer l'emplacement sur le serveur.

Rapports qualité et résolution des incidents

Les clients du système OCS 2007 utilisent RTAudio, qui est un codec audio de nouvelle génération qui peut tolérer les réseaux présentant des défauts, tels que l'instabilité, la perte de paquets, etc. Cependant, il reste indispensable de le superviser, de façon à ce que les administrateurs puissent rechercher et corriger les zones à problème. Les clients du système OCS 2007 indiquent la qualité de chaque appel et fournissent des statistiques détaillées notamment sur la bande passante, les pertes de données, l'instabilité, l'opinion moyenne (mesure de la perception des utilisateurs), les périphériques utilisés et bien plus encore à un serveur de mesure de la qualité de l'environnement utilisateur à la fin de chaque appel. Pour ce faire, la charge est transmise par la requête SERVICE de SIP au serveur de mesure de la qualité de l'environnement utilisateur, dont l'adresse est programmée à l'aide du mécanisme d'attribution de privilèges d'accès.

Tous les points de terminaison client indiquent la qualité des appels au serveur de mesure de la qualité de l'environnement utilisateur de manière indépendante. Lorsqu'un appel échoue en raison d'une erreur de signalisation, les clients signalent la même OCS, ce qui permet de constituer un référentiel des erreurs créées par les clients.

Vue d'ensemble

Après avoir passé en revue plusieurs aspects de configuration des appels, ce qui inclut la saisie de numéros, le routage entrant ou sortant et les vérifications de connectivité, nous allons examiner le processus dans son ensemble. La figure 7 permet de visualiser ce qui se produit après qu'un utilisateur passe un appel. Les clients du système OCS jouent un rôle essentiel lors de la mise en place d'un appel et gèrent l'ensemble du processus de configuration des appels. OCS est impliqué dans le routage initial de l'appel et les serveurs Edge permettent aux clients d'optimiser le routage multimédia. Nous allons aborder le stade suivant, la conversation.

Figure 7 Flux d'appels de bout en bout (cliquer sur l'image pour l'agrandir)

Comportement multimodal et conversations

Le concept de conversation est au centre du système OCS. Une conversation est une session multimodale entre deux ou plusieurs personnes, ce qui peut inclure la voix, la vidéo et la messagerie instantanée en même temps, de même que les composants, tels que les transferts de fichiers pendant la session, la messagerie dans Outlook ou les remarques enregistrées dans Microsoft Office OneNote®.

Les conversations présentent différents aspects qui peuvent avoir un impact sur la conception des systèmes client OCS :

• Toutes les modalités impliquées dans une conversation utilisent la même fenêtre. Si un message instantané est ajouté à une conversation audio, il est associé à la même fenêtre.
• Les conversations peuvent avoir lieu sur plusieurs périphériques. Les utilisateurs peuvent choisir d'activer la fonction audio sur Communicator Phone Edition et la messagerie instantanée sur le bureau Communicator.
• Tous les modes peuvent converger vers une conférence : En cas de convergence, toutes les modalités d'une conversation doivent être réunies, indépendamment du périphérique exécutant cette modalité. Par exemple, si un mode audio est disponible sur Communicator Phone Edition et si un mode messagerie instantanée est disponible pour la même conversation sur le bureau Communicator, la convergence vers la conférence garantit que les fonctionnalités audio et de messagerie instantanée disposent de la même série de participants pour cette conversation.
• Les conversations et non pas les différentes sessions sont consignées. Les journaux d'appels contiennent des informations complètes sur la conversation, ce qui inclut des détails sur les notes prises lors de la conversation, les échanges de messages instantanés, la durée du message audio, et ainsi de suite. L'utilisateur dispose ainsi des éléments essentiels de la conversation lorsqu'il ouvre le journal d'appels dans Outlook.
• Les conversations peuvent se poursuivre à partir des journaux de conversation. Les clients OCS lient les conversations à l'aide d'une référence de conversation (un numéro qui identifie de façon unique la conversation sur les périphériques et les applications). Un mécanisme élaboré permet de calculer les deltas des conversations lorsque de nouvelles conversations sont démarrées à partir de l'historique d'une ancienne conversation. Cette même référence de conversation est également enregistrée en tant que référence du message électronique dans Outlook.

La référence de conversation transite avec la requête INVITE de SIP en tant que propriété personnalisée, Ms-Conversation-Id. La figure 8 affiche une transaction où la voix est ajoutée en premier, suivie par un message instantané. À la fin de la conversation multimodale, l'historique qui est enregistré dans Outlook conserve la même référence de conversation.

Figure 8 Conversations multimodales et référence de conversation (cliquer sur l'image pour l'agrandir)

La messagerie unifiée d'Exchange correspond au système de messagerie vocale d'OCS 2007. OCS achemine uniquement les appels destinés aux utilisateurs UC vers la messagerie unifiée d'Exchange. OCS fournit plusieurs fonctionnalités d'intégration avec la messagerie unifiée d'Exchange :

• L'option de messagerie vocale de l'interface utilisateur de Communicator Phone (voir figure 9) permet à l'utilisateur de gérer la boîte aux lettres de messagerie unifiée, de modifier les messages d'accueil, et ainsi de suite, sans avoir à entrer le code confidentiel dans la mesure où il est déjà identifié.
• L'indicateur de message en attente de l'interface utilisateur de Communicator (voir figure 10) permet à l'utilisateur d'ouvrir le dossier de messagerie vocale dans Outlook tandis que celui de Communicator Phone Edition permet de lire les messages vocaux directement à partir du téléphone.
• Les appels peuvent être transférés vers la messagerie vocale de l'interface utilisateur de Communicator.
• Les appels refusés sont routés de façon automatique vers la messagerie vocale.
• La lecture sur un téléphone de l'élément de messagerie vocale dans Outlook permet d'appeler les clients Office Communicator directement.

Figure 9 Option de messagerie vocale dans Communicator

Figure 10 Voyant de message en attente dans Communicator

Le mécanisme de réception des notifications de messages vocaux d'OC est différent de celui de Communicator Phone Edition. OC s'abonne aux notifications de nouveaux messages dans le dossier de recherche de messages vocaux d'Outlook et signale tous les nouveaux messages de ce dossier. Communicator dispose également de journaux des conversations auxquelles vous n'avez pas participé et d'appels.

Conclusion

J'ai présenté ici le mode de fonctionnement des appels vocaux dans OCS 2007, un système qui repose sur SIP et qui exploite plusieurs RFC. Les points de terminaison clients jouent un rôle essentiel dans la gestion des appels au sein d'OCS. Tous les appels vocaux sont chiffrés de façon sûre par défaut. OCS offre des composants souples permettant de manipuler des numéros et de gérer leur flux sur le système.

Les conversations constituent un aspect central d'OCS, ce qui implique la voix, la messagerie instantanée et la vidéo. OCS s'intègre à la messagerie unifiée d'Exchange et permet de notifier les points de terminaison Communicator lors de la réception de messages vocaux et d'accéder à la messagerie vocale au moyen d'Outlook, voire directement à partir du serveur.

Rajesh Ramanathan a travaillé dans le secteur de la communication pendant 14 ans et a conçu des protocoles vocaux, des environnements utilisateur, ainsi que des modules vocaux ou de conférence pou Office Communicator 2007. Il travaille actuellement en tant que responsable de programme de l'équipe Office Communicator de Microsoft. Vous pouvez le joindre à l'adresse suivante : rajeshra@microsoft.com.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.