Présentation de RCC (Remote Call Control)

Publié le par Teruin

 Traduit de l'anglais (source technet)

 

La définition de RCC est la facultée de recevoir et d'initier des appels depuis un péripéhrique autre que votre ordinateur. Pour ocs , cela implique les fonctionnalités suivantes :

  • 1. Lorsqu'un téléphone PBX sonne, une alerte apparait dans communicator qui vous permet de répondre à l'appel
  • 2. Lorsque un numéro de téléphone est sélectionner dans dans communicator, le téléphone PBX passe en mode decroché et compose le numéro
  • 3. Le transfert d'appel peut être établi sur le téléphone PBX
  • 4. Les appels entrants peuvent être acheminés vers d'autre numéro de téléphone
  • 5. Support des fonctionnalités de transfert d'appel de type Single step Transfert (blind transfert) ou transfert d'appel consultés (Consultative Call Transfert). Exemple filtrage patron secrétaire.

 

Une des différences fondamentales entre RCC et la configuration Enterprise Voice est que dans la configuration RCC, le client Office Communicator doit simplement signaler les contrôles mises en place avec le PBX. Aucun appel VOip n'est établi par les clients Communicator. En d'autre terme, l'office Communicator n'est pas utilisé ici comme un softphone.

 

Dans sa configuration la plus simple, RCC peut être déployé en installant une passerelle SIP/CSTA entre le PBX et l'OCS. Cette passerelle SIP/CSTA fournira l'interfacage SIP du coté OCS et l'interface Computer-Supported Télécommunication Application (CSTA) de l'autre. Les messages de signalisation étant encapsulés dans le protocole SIP afin de communiquer avec les clients Office Communicator. Coté PBX la passerelle utilise des interfaces de signalisation spécifiques à l'environnement PBX.

Dans la figure si dessous le déploiement RCC tire partie de la connectivité au réseau public de téléphone (PSTN)  afin de passer des appels  vers l'extérieur.

 

 

L'implémentation des fonctionnalités RCC dans office Communicator est basé sur le rapport technique 87 de l'association européenne des fabricants d'ordinateur (ECMA : http://www.ecma-international.org/default.htm) qui a mis au point la « traduction » de CSTA pour le protocole SIP. Un autre standard (ECMA23 : http://www.ecma-international.org/publications/standards/Ecma-323.htm) fourni la description complète du schéma XML qui est envoyé dans le tunnel SIP.

Comment ca marche ?

Pendant la phase d'initiation de l'appel, les clients Communicator ont besoin de se connecter à la passerelle SIP/CSTA (qui est adressée et définie par le server URI dans la configuration utilisateur de OCS) afin de mettre en place un canal de communication permanent de type INVITE.

Le système RCC suit un model de commande/réponse. Chaque message que le client Communicator envoi à la passerelle SIP/CSTA contient une commande encodée en XML (ECMA 323). Chaque réponse ou notification provenant de la passerelle SIP/CSTA contient également une commande XML. La première invite SIP créé la session et contient un message de type RequestSystemStatus. La passerelle SIP/CSTA accepte la requête et répond avec un accusé de type RequestSystemStatusRespons en 200 OK (voir figure suivante.)

 

On notera au passage qu'il n y a pas de commande BYE correspondant a la commande INVITE. Ceci est normal car l'INVITE est basée sur une session de longue durée durant laquelle d'autres commandes provenant du client Communicator peuvent être acheminées ou reçues depuis la passerelle SIP/CSTA.

 Une fois que la sequence INVITE/200 est terminée, le client Office Communicator inspecte les fonctionnalités de la passerelle SIP/CSTA (qui normalement reflète les fonctionnalités  du PBX) afin de découvrir celles qui sont supportées. Une fois cela accompli, la surveillance de la ligne est initiée.

La reconnaissance des fonctionnalités PBX (à travers la passerelle SIP/CSTA) est un étape importante au demarrage, car selon les fonctionnalités supportés ou non par la passerelle et le PBX, certains éléments de l'interface utilisateur du client Communicator pourrons être activés ou non. Si par exemple les fonctionnalité de Single Step Transfert ne sont pas supportés par la passerelle SIP/CSTA Office Communicator ne fera pas apparaitre le bouton de transfert d'appel dans l'interface Utilisateur.

Aussi, une configuration RCC demande que deux paramètres soient utilisés par les clients Communicator. Le premier est le serveur URI  qui est un SIP URI contenant l'adresse de la passerelle SIP/CSTA et qui va permettre aux clients Communicator de se connecter vers le server en utilisant une invite SIP vers l'URI en question. (L'URI est généralement de la forme gateway@contoso.com)

Le second paramètre est LINE URI qui est un TEL URI qui identifie le numéro de téléphone du système PBX. Généralement cet URI suit le format RFC3966 (Exemple : TEL :+12355551212 ou TEL : 425551212 ;ext=1212)

Une fois que la séquence de démarrage est terminée Office Comunicator reçois des messages d'événements du PBX dans le cas ou le statut change en cours sessions. Lorsque Office Communicator a besoins de répondre à un appel, il envoi un message de type INFO qui contient un message XML CSTA vers la passerelle. Cet événement est reçu sur la passerelle qui contient également des messages CSTA/XML encapsulées dans des messages SIP/INFI

Exemple de MESSAGE INFO ET DE REPONSE OK 200

INFO sip:gateway@contoso.com SIP/2.0

From: <sip:alice@ocs.contoso.com>;tag=31424bf782;epid=77e47b4782

To: <sip:gateway@ocs.contoso.com>;tag=1fbe74b0

Call-ID: 52c4a528322d4457a486283ccf78b696

User-Agent: UCCP/2.0.6362.0 OC/2.0.6362.0 (Microsoft Office Communicator)

Content-Disposition: signal;handling=required

Content-Type: application/csta+xml

Content-Length: 277

<?xml version="1.0"?>

<MakeCall xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">

  <callingDevice>tel:+14255551212;ext=1212</callingDevice>

  <calledDirectoryNumber>tel:+14258828080;ext=5555</calledDirectoryNumber>

  <autoOriginate>doNotPrompt</autoOriginate>

</MakeCall>

 

SIP/2.0 200 OK

From: <sip:alice@ocs.contoso.com>;tag=31424bf782;epid=77e47b4782

To: <sip:gateway@ocs.contoso.com>;tag=1fbe74b0

Call-ID: 52c4a528322d4457a486283ccf78b696

Content-Disposition: signal;handling=required

Supported: 100rel,replaces,timer

User-Agent: Example Gateway Release 1.0 version 4.2.3

Contact: <sip:gateway@ocs.contoso.com>

Content-Type: application/csta+xml

Content-Length: 247

<?xml version="1.0" encoding="UTF-8"?>

<MakeCallResponse xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">

  <callingDevice>

    <callID>17772</callID>

    <deviceID> tel:+14255551212;ext=1212</deviceID>

  </callingDevice>

</MakeCallResponse>

 

L'on notera que dans ce cas précis, OCS est utilisé comme SIP proxy. Tous les messages de signalisation, passés entre les clients Communicator et la Passerrelle SIP/CSTA sont acheminés par le serveur OCS. Afin de s'assurer que la passerelle SIP/CSTA est toujours en fonction, le client Communicator renvoi toute les 10 Minutes une commande RequestSystemStatus.

 

Fonctionnement d'un appel Basic

La séquence d'appel est illustrée dans la figure 5. L'utilisateur peut effectuer un appel en tapant son numéro de téléphone dans le champ du client Communicator, ou en sélectionnant le numéro d'un contact dans un liste.. Lorsque que l'utilisateur sélectionne un numéro de téléphone, Office Communicator généré une commande MakeCall vers la passerelle SIP/CSTA qui contient le numéro de téléphone selectionné. L'interface RCC permet uniquement à l'utilisateurs d'appeler des numéro de téléphone. Lorsque l'utilisateur sélectionne l'options d'appel du communicateur pour appeler quelqu'un, Office Communicator génère un appel VOIP vers l'URI SIP de l'utilisateur distant.

 

Figure 5

La séquence illustrée  dans la figure 5 montre comment la passerelle SIP/CSTA traduit la commande MAkeCall en message propriétaire du PBX. On notera que l'interface de la passerelle SIP/CSTA fourni des mécanismes élaborés afin d'indiquer les différents états du téléphone. Dans cet exemple, on peut voir qu'il y a plusieurs événements qui sont reçus par le client Office Communicator qui indiquent l'activité du téléphone PBX. Cela commence avec l'envenement OriginatedEvent (Précisant que le téléphone PBX est a l'origine d'un appel externe) et l'evenement DeliveredEvent (Precisant un état 'sonnant').

Lorsque l'appel est reçu (repondu) le PBX envoi un signal correct  à la passerelle SIP/CSTA ainsi qu'un événement EtablishedEvent vers le client Communicator lui indiquant que l'appel à bien été « répondu »

 

Figure 6 : L'appel a été traité (répondu)

Fonctionnement d'une réponse basique

Lorsqu'un appel arrive au PBX, le PBX informe la passerelle SIP/CSTA qui a son tour délivre une notification CSTA de type DEliveredEvent au client Communicator. Une fois que le client Communicator reçoit la notification, la notification d'appel entrant est affiché a l'utilisateur.

Office communicator effectue également un requete de nom inversé (Reverse Name Lookup) sur le carnet d'adresse  et dans les contacts Microsoft Outlook de l'utilisateur pour afficher le nom (display name) correspondant à la personne appelée. L'utilisateur peut alors répondre à l'appel qui va engendré un commande AnswerCsta vers la passerelle SIP/CSTA. A ce point, la passerelle CTSA converti la commande AnswerCall dans un message au format correspondant au PABX et le tunnel bi directionnel est établi entre l'appelant et le téléphone PBX.

 

 

Figure 7 : Réponse  à un appel




RCC et intégration de la présence

Avec l'intégration de RCC, le statut du téléphone de l'utilisateur  est  désormais intégré a la présence. Par exemple, si jamais l'utilisateur est en communication sur le PBX, Office Communicator va modifier le statuT de l'utilisateur en précisant qu'il est en communication. Ce statut peut être visible par les autres utilisateurs Communicators. De façon complémentaire, les utilisateurs peuvent publier les numéros de téléphone personnel à travers leurs présence aux autres personnes de façon à ce qu'ils soient joignables sur le téléphone de maison ou sur leurs téléphones portables. L'on notera cependant que sur un client Office Communicateur si le statut ne pas déranger est indiqué, celui-ci n'est pas transmis au PBX. L'utilisateur devra alors l'indiquer manuellement.

 

RCC et conférence.

Lors de la mise en en place d'une conférence le RCC n'indiquera pas le statut en conférence mais précisera un statut en ligne comme si il s'agisssait d'un appel classique.

 

RCC dans l'environnement Entreprise Voice et PBX

Les fonctionnalités RCC peuvent être utilisées dans les scenarios Entreprise Voice avec l'intégration de PBX (aussi connue en tant que Dual Forking). Dans ce type de scenario le PBX et l'OCS peuvent transmettre tous les deux les appels vers l'un et l'autre. Ces options permettent en fait detirer parti de tous les bénéfices de l'entreprise Voice. L'intérêt pour les utilisateurs est qu'ils auront la possibilité de répondre soit sur l'un soit sur l'autre des dispositifs.

 

Limitations des fonctionnalités du RCC

Les fonctionnalités RCC permettent de facilement intégrer les fonctionnalités OCS dans un environnement PBX. Cependant les fonctionnalités RCC des utilisateurs seront limitées par les fonctionnalités RCC du PBX lui-même.  Il faudra donc composer avec les fonctionnalités RCC de ce dernier qui dicteront ce qu'il est possible de transmettre coté OCS. Certaines fonctionnalités disponibles  pour les utilisateurs Entreprise Voice comme la sonnerie multiple et la délégation presente dans OCS2007 R2 ne seront pas activables. D'autre part, les configuration RCC ont été  implanter pour fonctionner dans un environnement mono site. C'est d'ailleurs pour cela que les règles de numérotation multi location ne sont pas supportées dans la topologie RCC.

 

Néanmoins même si ces fonctionnalités sont limitées les fonctionnalités offrent malgré tout une intégration appréciable dans l'environnement Entreprise Voice et PBX.

 

Pour être informé des derniers articles, inscrivez vous :

Commenter cet article