Sommaire 2. Diagramme de use Case. 3. Diagramme de classes 4. Diagrammes de sé en a. Authentification….. Sni* to View b. Communication 5. Diagramme de classe V1 1. Problématique De plus en plus la téléphonie d’entreprise s’oriente vers la TolP (Telephony on IP). Côté serveur, il y a des préférences au déploiement d’Ip3X d’hébergés (Cisco IPMG, Asterisk, Kamailio, etc. ), celui-ci utilise le protocole SIP.
Et côté client, deux alternatives sont envisageables : d’effectuer des appels vers d’autres usagers de softphones, nscrits chez le même opérateur ou chez un opérateur différent ; D Permettre à l’utilisateur de gérer une liste de contacts (enregistrement des noms et no SIP de ses contacts) ; Mettre à disposition de l’utilisateur, l’historique de ses appels (entrants et sortants).
Un usager potentiel de ce système a, au préalable, créé un compte chez un opérateur qui a enregistré des informations le concernant (son nom, prénom, mot de passe, l’adresse IP d’une machine depuis laquelle il est susceptible de se connecter) et lui a attribué une adresse SIP. Cet usager est alors un client de ‘opérateur. n appel se déroule alors de la façon suivante Cusager, depuis l’interface TOIP présente sur son ordinateur, compose le no SIP de son correspondant ; Ce no SIP, ainsi que l’adresse IP de l’ordinateur, sont transmis ? l’opérateur qui les interprète comme une requête de demande d’appel • C] L’opérateur demande en retour son mot de passe ? l’utilisateur ; L’utilisateur le fournit , L’opérateur le vérifie ; Sil est correct, il délivre une autorisation de communication qui n’est valide que le temps de l’appel et vérifie la correspondance ntre l’adresse IP qui a été transmise dans la requête d’appel et l’adresse IP que lui-même a enregistré dans les informations de son client. Si elles ne correspondent pas, l’adresse IP enregistrée est mise ? jour. C] Ily a alors recherche du correspondant de l’usager, PAG » OF d l’adresse IP enregistrée est mise à jour.
Ily a alors recherche du correspondant de l’usager, dans la base de comptes-clients de l’opérateur lui-même ou dans celle d’un autre opérateur, si le correspondant n’est pas client du même opérateur ; Une fois le correspondant trouvé, il y a établissement de la ommunication par une mise en relation directe des 2 usagers via leurs interfaces softphone ; Une fois la communication terminée, l’appel est enregistré dans l’historique des appels de l’usager et le système revient ? son état initial (suppression de Pautorisation d’appel). Le processus d’appel comporte donc 3 étapes : enregistrement, mise en relation, communication. Chacune pouvant être considérée comme un service rendu par l’opérateur.
Dans la réalité, les services sont répartis sur des machines physiques différentes, ce qui donne Parchitecture et le onctionnement décrit sur le schéma suivant : L’opérateur correspond aux 3 serveurs « proxy b, « registrar » et « location server C’est le « registrar » qui gère les comptes clients et délivre les autorisations temporaires d’appel ; le « location server » gère les correspondances entre adresses SIP et adresses IP ; le « proxy server » orchestre la totalité du fonctionnement. 2. Diagramme de Use Case 3. Diagramme de classes VO 4. Diagrammes de séquence a. Authentification Marcel qui a envie d’appelé son ami Jean-Michel ouvre son oftphone, son softphone lui demande une adresse SIP et mot de passe. Le softphone va envoyer ses identifiants aux proxy de son opérateur qui va le relayer au serveur registrar. Le serveur registrar va vérifier son identité, l’identité est correcte et il en renvoie un message « OK » au proxy et au softphone pour que Marcel puisse appeler son ami Jean-Michel.
Use case et descriptions : Diagramme de séquence • Les méthodes rajoutées : Envoieldentifiant(adresseSlP String, mdp String) :String Cette méthode a été rajouté dans la classe proxyOperateur et egistrar pour permettre l’envoie des identifiants du client qui lance son softphone. Cette nouvelle méthode prend en paramètre Vadresse SIP et mot de passe entré par l’utilisateur. La méthode possède un paramètre de retour en String qui permet de renvoyer le message « OK » ou « NOK » VerifieClient(adresseSlP String, mdp String) :String Cette méthode se trouve sur le serveur registrar qui permet de tester les identifiants reçu en argument, s’il est correct, le serveur délivre une autorisation de communication avec le message de retour « OK » ou dans le ca NOK».
