Logiciel VOIP Annexe

Transcription

1 Logiciel VOIP Annexe Présenté par : Tuteur : FERRAN Olivier LANUSSE Florian TEBIB Leïla M. Rachid Elazouzi 1 ère de Master RTM Université d Avignon et des Pays de Vaucluse IUP GMI

2 Année

3 Liste des abréviations Présentation Introduction I- Partie théorique 1- Protocole H Définition 1.2- Avantages 1.3- Inconvénients SOMMAIRE : 2- Protocole SIP 2.1- Définition 2.2- Fonctionnement 2.3- Sécurité et authentifications 3- Comparaison entre le protocole H323 et le protocole SIP 4- API JAIN SIP 4.1- Pourquoi Java comme langage de programmation 4.2- Pourquoi cette API 4.3- Spécificités 4.4- Architecture

4 Liste des abréviations : GUI : Graphique User Interface PS: Proxy Server QOS: Quality Of Service RAS: Registration, Admission and Status RFC: Request For Comment RNIS: Réseau Numérique à Intégration de Service RTP: Real-Time Transport Protocol RTCP: Real-Time Control Protocol SDP: Session Description Protocol SIP: Session Initiation Protocol TCP: Transmission Control Protocol UAC: User Agent Server UAS: User Agent Server UDP: User Datagram Protocol URI: Uniform Resource Indicator URL: Uniform Resource Locator

5 Présentation Ce projet de première année de Master Réseaux Télécom et Multimédia se désigne sous l appellation «Logiciel VOIP». Par l analyse des objectifs et des taches induites, ce projet s articule autour de deux groupes de travail de trois étudiants chacun. Nous représentons le groupe n 7 et travaillons de pair avec le groupe de projet n 8, tous deux sous la tutelle de M. Elazouzi. Le travail des deux groupes est complémentaire. Il a nécessité une totale coopération de la part des étudiants, étant donné que le projet a été divisé en deux parties dépendantes l une de l autre. Les taches effectuées sont résumées comme suit : - Le groupe n 7 : o o o o o o Etude du protocole SIP Implémentation de SIP Etude de l API JAISIP et utilisation pour l implémentation de SIP. Imbrication des codecs étudiés par le groupe n 8. Développement de l interface graphique GUI comportant les fonctionnalités développées par le groupe n 8. Intégration de la transmission vidéo. - Le groupe n 8 : Etude des différents Codecs et des protocoles RTP, RTCP. o Etude des différents codecs. o Choix des codecs à implémenter (G711, LPC10-15, GSM et SPEEX). o Etude des protocoles RTP :RTCP o Gestion et réalisation de la QOS ( la qualité de service) o Ajout de fonctionnalités techniques qui incluent l appui de la tonalité o La rédaction d un manuel utilisateur complet. Objectif du projet L objectif du projet est d implémenter un modèle de communication multimédia (voix et vidéo) en temps réel entre deux ordinateurs qui n utilisent pas obligatoirement le même modèle (le même soft phone). Et ce, en nous basant sur la modélisation orientée objet du protocole de signalisation SIP

6 Il s agit ici de développer une application utilisant une interface graphique homme-machine (interface utilisateur). Dès lors, elle permettra un échange de données multimédia (audio, vidéo et messagerie instantanée). Dans le premier chapitre, comporte une première définition du protocole H323 ainsi qu une définition plus approfondie du protocole SIP. En outre, il y figure une comparaison entre ces deux protocoles. Notez ici, que le protocole SIP, considéré à ce jour comme une amélioration du H323, constitue le noyau dur de ce projet. Enfin, une dernière partie présente l API et le langage utilisés pour implémenter et réaliser ce projet. L API, dénommée JainSIP, se base sur le langage Java Dans le second chapitre, nous présenterons le travail réalisé durant le second semestre, l implémentation du protocole SIP, l imbrication des travaux réalisés par les deux groupes ainsi que la création d une interface graphique, comportant les fonctionnalités des deux groupes. A mi-parcours du dernier semestre. Au vu de l avancement du travail et des objectifs déjà atteints, nous avons décidé, avec l accord de notre tuteur, de tenter l intégration de la vidéo au projet. Ceci faisait partie des perspectives pour les projets des prochaines années

7 Introduction Dans le contexte actuel de mondialisation des échanges économiques et de l information, une demande toujours grandissante liée aux télécommunications s exprime. Ainsi, les domaines public et privé d activité emploi de manière croissante les techniques de communications longues distances. Le principal frein au déploiement de ces services réside dans le fort coût de facturation des fournisseurs de service téléphoniques classiques. En parallèle de ce fait, l émergence, aussi violente que rapide de l Internet témoigne des possibilités d accès à l information sans aucune considération liée aux distances. La question est alors posée de savoir comment faire coïncider les deux afin que les besoins de l un profitent des possibilités de l autre. Les utilisateurs du téléphone considère comme acquis un certain mode de facturation : les coûts de communication dépendent à la fois de la distance et de la durée d occupation de la ligne. Par contre, le coût de l Internet suit une tout autre logique : la facturation demeure uniquement forfaitaire. Fort de ce constat, l utilisateur désire voir disparaître le premier au profit du second. A la fois dans un souci d économie, mais aussi de simplicité. A ce fait s ajoute un courant relativement récent, qui vise à une convergence des moyens de communications vers l Internet, ou le «Tout IP». Ces solutions constitueraient dès lors des alternatives uniquement forfaitaire assurant un confort d utilisation équivalent à la téléphonie standard. C est dans ce contexte là que la téléphonie sur IP fut développée. La téléphonie sur IP utilise la technique VOIP (Voice Over IP : VOix sur IP) et doit son succès grandissant aux coûts réduits du transport de l'information via le réseau internet. Plusieurs acteurs de l'informatique se sont lancés dans ce marché extrêmement concurrentiel à l'égard des grands opérateurs de téléphonie classique ; le plus connu est la société luxembourgeoise Skype Technologies SA, dont l'offre commerciale SkypeOut (passerelle SIP sur le réseau téléphonique classique) concurrence directement ces opérateurs. Dans les grandes lignes, la Voix sur IP suit ce principe : Lors de l'émission, un programme appelé codec numérise et compresse un signal audio (la voix humaine par exemple), les données numériques ainsi obtenues sont acheminées jusqu'au destinataire dans des paquets TCP/IP. Le codec du programme récepteur effectue les opérations inverses (décompression, puis restitution analogique du signal audio)

8 1. Protocole H Définition I- Partie théorique Le protocole H323 est utilisé pour l'interactivité en temps réel, notamment la visioconférence (signalisation, enregistrement, contrôle d'admission, transport et encodage). C'est le leader du marché pour la téléphonie IP. Il s'inspire du protocole H320 qui proposait une solution pour la visioconférence sur un réseau numérique à intégration de service (RNIS ou ISDN en anglais), comme par exemple le service numéris proposé par France Telecom. Le protocole H323 est une adaptation de H320 pour les réseaux IP. A l'heure actuelle, la visioconférence sur liaison RNIS est toujours la technique la plus déployée. Les réseaux utilisés sont à commutation de circuits. Ils permettent ainsi de garantir une Qualité de Service (QOS) aux utilisateurs (limite les coupures du son ou de l'image). Aujourd'hui, c'est encore un avantage indiscutable. Par contre, comme pour le téléphone, la facturation est en fonction du débit utilisé, du temps de communication et de la distance entre les appels. Plus qu'un protocole, H323 ressemble d'avantage à une association de plusieurs protocoles différents pouvant être regroupés en trois catégories : la signalisation, la négociation de codec, et le transport de l information. Les messages de signalisation réunissent l ensemble des informations qui ne correspondent pas directement au flux multimédia échangé. Il correspondent par exemple aux messages demandant d être mis en relation avec un interlocuteur, informant que la ligne est occupée ou encore indiquant que le téléphone de l appelé sonne, En H323, la signalisation s appuie sur le protocole RAS pour l enregistrement et l authentification, et le protocole Q.931 pour l initialisation et le contrôle d appel. La négociation est utilisée pour faire correspondre les méthodes de codage des deux éléments en communication. Il est important que les téléphones (ou systèmes) utilisent un langage commun s ils veulent se comprendre. Par ailleurs, si tous permettent l utilisation d une grande variété de codecs, Il est préférable d adapter celui utilisé aux propriétés de la communication. Ce choix peut se faire en fonction des capacités d accès de l utilisateur à Internet, mais aussi de la qualité exigée pour son service (qualité d image et du son, réactivité des échanges, ). Dans tous les cas, Le protocole utilisé pour la négociation de codec est le H.245 Le transport de l information s appuie sur le protocole RTP qui transporte la voix, la vidéo ou les données numérisées par les codecs. Les messages RTCP assure, quant à eux, le contrôle de qualité, et les demandes de renégociation des codecs en cas de changement des propriétés de la ligne

9 Une communication H323 se déroule en cinq phases : Établissement de l appel Échange de capacité et réservation éventuelle de la bande passante à travers le protocole RSVP (Ressource reservation Protocol) Établissement de la communication audio-visuelle Invocation éventuelle de services en phase d'appel (par exemple, transfert d'appel, changement de bande passante, etc.) Libération de l'appel. 1.2.Avantages Il existe de nombreux produits (plus de 30) utilisant ce standard adopté par de grandes entreprises telles Cisco, Nortel, IBM, Intel, Microsoft, Netscape, etc. Les cinq principaux logiciels de visioconférence Picturel 550, Proshare 500, Trinicon 500, Smartstation et Cruiser 150 utilisent sur l IP la norme H323. Un niveau d'interopérabilité très élevé, ce qui permet à plusieurs utilisateurs d'échanger des données audio et vidéo sans faire attention aux types de média qu'ils utilisent. 1.3.Inconvénients Protocole très complexe, manque d interopérabilité entre les différentes implémentations (RadVision, Elemedia-Lucent, ) Difficultés d intégrations dans les rêgles de filtrage des FireWall Support des fonctions avancées de la téléphonie. H450.x très peu utilisé. Sort des standards du modèle OSI assurant l interopérabilité avec l ensemble du parc réseau IP

10 2. Protocole SIP 2.1. Définition Le protocole SIP (Session Initiation Protocol) est un protocole suivant le standard de l'ietf (RFC 3261 et 3265). Il a été conçu afin d établir, de modifier et de terminer des sessions multimédia. Il assure l'authentification et la localisation des différents participants. Il se charge également de la négociation des types de média utilisables. Ceci s effectue à l aide de l encapsulation de messages SDP (Session Description Protocol). SIP ne transporte pas les données échangées durant la session comme la voix ou la vidéo. Il demeure indépendant de la transmission des données. Dès lors, tous types de donnés et de protocoles peuvent être utilisés pour cet échange. SIP est le standard «open» de VoIP (Voice Over IP, voix sur IP). Disposant d une interopérabilité particulièrement étendue, il se destine à devenir le principal standard des télécommunications multimédia (son, image, etc.). SIP n'est donc pas seulement destiné à la VoIP mais pour de nombreuses autres applications telles que la visiophonie, la messagerie instantanée, la réalité virtuelle ou même les jeux vidéo. Application Présentation Session Transport Réseau Liaison Physique SIP dans le model OSI Comme on peut le voir sur ce petit schéma, SIP s est superposé à 3 couches du modèle OSI : la couche Application, la couche Présentation et la couche Session ; ceci afin de faciliter sa programmation, son intégration et son utilisation dans les logiciels de communication. Ainsi, SIP possède l'avantage de ne pas être attaché à un médium particulier et est sensé être indépendant du protocole de transport des couches basses

11 Exemple de communication simple : Ce schéma représente l établissement d une session SIP à travers un proxy entre 2 utilisateurs. Il montre les différentes étapes de cette communication ainsi que quelques requêtes d établissement de session spécifiques au protocole. Un utilisateur peut se connecter avec les utilisateurs d'une session déjà ouverte. Pour ouvrir une session, un utilisateur émet une invitation transportant un descripteur de session permettant aux autres utilisateurs souhaitant communiquer de s'accorder sur la compatibilité de leur média. SIP permet donc de relier des stations mobiles en transmettant ou redirigeant les requêtes vers la position courante de la station appelée

12 2.2. Fonctionnement SIP intervient aux différentes phases de l'appel : Localisation du terminal correspondant, Analyse du profil et des ressources du destinataire, Négociation du type de média (voix, vidéo, données...) et des paramètres de communication, Disponibilité du correspondant, détermine si le poste appelé souhaite communiquer, et autorise l'appelant à le contacter. Etablissement et suivi de l'appel, avertit les parties appelantes et appelées de la demande d'ouverture de session, gestion du transfert et de la fermeture des appels. Gestion de fonctions évoluées : cryptage, retour d'erreurs,... Avec SIP, les utilisateurs qui ouvrent une session peuvent communiquer en mode point à point, en mode diffusif ou dans un mode combinant ceux-ci. SIP permet donc l'ouverture de sessions en mode : Point-à-point - Communication entre 2 machines, on parle d'unicast. Diffusif - Plusieurs utilisateurs en multicast, via une unité de contrôle M.C.U (Multipoint Control Unit) Combinatoire - Plusieurs utilisateurs pleinement interconnectés en multicast via un réseau à maillage complet de connexions. Voici les différents éléments intervenant dans l'ouverture de session : Suivant nature des échanges, choix des protocoles les mieux adaptés (RSVP, RTP, RTCP, SAP, SDP). Détermination du nombre de sessions, comme par exemple, pour véhiculer de la vidéo, 2 sessions doivent être ouvertes (l'une pour l'image et l'autre pour la vidéo). Chaque utilisateur et sa machine est identifié par une adresse que l'on nomme Url SIP et qui se présente comme une Url Mailto. Requête Uri permettant de localiser le proxy server auquel est rattaché la machine de l'appelé. Requête SIP, une fois le client (machine appelante) connecté à un serveur SIP distant, il peut lui adresser une ou plusieurs requêtes SIP et recevoir une ou plusieurs réponses de ce serveur. Les réponses contiennent certains champs identiques à ceux des requêtes, tels que : Call-ID, Cseq, To et From

13 Les échanges entre un terminal appelant et un terminal appelé se font par l'intermédiaire de requêtes : Invite - Cette requête indique que l'application (ou utilisateur) correspondante à l'url SIP spécifié est invité à participer à une session. Le corps du message décrit cette session (par ex : média supportés par l appelant). En cas de réponse favorable, l'invité doit spécifier les médias qu'il supporte. Ack - Cette requête permet de confirmer que le terminal appelant a bien reçu une réponse définitive à une requête Invite. Options - Un proxy server en mesure de contacter l'uas (terminal) appelé, doit répondre à une requête Options en précisant ses capacités à contacter le même terminal. Bye - Cette requête est utilisée par le terminal de l'appelé à fin de signaler qu'il souhaite mettre un terme à la session. Cancel - Cette requête est envoyée par un terminal ou un proxy server à fin d'annuler une requête non validée par une réponse finale comme, par exemple, si une machine ayant été invitée à participer à une session, et ayant accepté l'invitation ne reçoit pas de requête Ack, alors elle émet une requête Cancel. Register - cette méthode est utilisée par le client pour enregistrer l'adresse listée dans l'url TO par le serveur auquel il est relié. Une réponse à une requête est caractérisée, par un code et un motif, appelés code d'état et raison phrase respectivement. Un code d'état est un entier codé sur 3 bits indiquant un résultat à l'issue de la réception d'une requête. Ce résultat est précisé par une phrase, textbased (UTF-8), expliquant le motif du refus ou de l'acceptation de la requête. Le code d'état est donc destiné à l'automate gérant l'établissement des sessions SIP et les motifs aux programmeurs. Il existe 6 classes de réponses et donc de codes d'état, représentées par le premier bit : 1xx = Information - La requête a été reçue et continue à être traitée 2xx = Succès - L'action a été reçue avec succès, comprise et acceptée 3xx = Redirection - Une autre action doit être menée afin de valider la requête 4xx = Erreur du client - La requête contient une syntaxe éronnée ou ne peut pas être traitée par ce serveur 5xx = Erreur du serveur - Le serveur n'a pas réussi à traiter une requête apparemment correcte 6xx = Echec général - La requête ne peut être traitée par aucun serveur Dans un système SIP on trouve deux types de composantes, les users agents (UAS, UAC) et un réseau de serveurs : L'UAS (User Agent Server) - Il représente l'agent de la partie appelée. C'est une application de type serveur qui contacte l'utilisateur lorsqu'une requête SIP est reçue. Et elle renvoie une réponse au nom de l'utilisateur

14 L'U.A.C (User Agent Client) - Il représente l'agent de la partie appelante. C'est une application de type client qui initie les requêtes. Le relais mandataire ou PS (Proxy Server), auquel est relié un terminal fixe ou mobile, agit à la fois comme un client et comme un serveur. Un tel serveur peut interpréter et modifier les messages qu'il reçoit avant de les retransmettre : Le RS (Redirect Server) - Il réalise simplement une association (mapping) d'adresses vers une ou plusieurs nouvelles adresses. (lorsqu'un client appelle un terminal mobile - redirection vers le PS le plus proche - ou en mode multicast - le message émis est redirigé vers toutes les sorties auxquelles sont reliés les destinataires). Notons qu'un Redirect Server est consulté par l'uac comme un simple serveur et ne peut émettre de requêtes contrairement au Ps. Le LS (Location Server) - Il fournit la position courante des utilisateurs dont la communication traverse les Rs et PS auxquels il est rattaché. Cette fonction est assurée par le service de localisation. Le RG (Registrar) - C'est un serveur qui accepte les requêtes Register et offre également un service de localisation comme le LS. Chaque PS ou RS est généralement relié à un Registrar Sécurité et inconvénients : Les messages SIP peuvent contenir des données confidentielles, en effet le protocole SIP possède 3 mécanismes de cryptage : Cryptage de bout en bout du Corps du message SIP et de certains champs d'entête sensibles aux attaques. Cryptage au saut par saut (hop by hop) à fin d'empêcher des pirates de savoir qui appelle qui. Cryptage au saut par saut du champ d'en-tête Via pour dissimuler la route qu'a emprunté la requête. De plus, à fin d'empêcher à tout intrus de modifier et retransmettre des requêtes ou réponses SIP, des mécanismes d'intégrité et d'authentification des messages sont mis en place. Et pour des messages SIP transmis de bout en bout, des clés publiques et signatures sont utilisées par SIP et stockées dans les champs d'en-tête Autorisation. Une autre attaque connue avec TCP ou UDP est le «deny of service», lorsqu'un Proxy Server intrus renvoie une réponse de code 6xx au client (signifiant un échec général, la requête ne peut être traitée). Le client peut ignorer cette réponse. Si il ne l'ignore pas et émet une requête vers le serveur "régulier" auquel il était relié avant la réponse du serveur "intrus", la requête aura de fortes chances d'atteindre le serveur intrus et non son vrai destinataire

15 3. Comparaison entre les protocoles H323 et SIP : La comparaison entre les deux protocoles est résumée dans le tableau suivant SIP H323 Nombre échanges pour 1,5 aller-retour 6 à 7 aller-retour établir la connexion Maintenance du code protocolaire Simple par sa nature textuelle à l'exemple de http Complexe et nécessitant un compilateur Evolution du protocole Protocole ouvert à de nouvelles fonctions Ajout d'extensions propriétaires sans concertation entre vendeurs Fonction de conférence Distribuée Centralisée par l'unité MC Fonction de téléservices Oui, par défaut H.323 v2 + H.450 Détection d'un appel en boucle Oui Inexistante sur la version 1 un appel routé sur l'appelant provoque une infinité de requêtes Signalisation multicast Oui, par défaut Non La simplicité, la rapidité et la légèreté d'utilisation, du protocole SIP sont autant d'arguments qui pourraient permettre à SIP de convaincre les investisseurs. De plus, ses avancées en matière de sécurité des messages sont un atout important par rapport à ses concurrents, d où notre choix d utilisation de ce protocole

16 4. API JAIN SIP : 4.1. Pourquoi Java comme langage de programmation? Tout d abord pour la portabilité de Java qui se prête très bien au développement d applications de téléphonie, des applications qui se doivent d être portables et multiplateformes. De plus, notre groupe de projet possède de bonnes bases en Java et beaucoup d éléments vus au cours de la Licence et de la 1 ère année de Master seront réutilisables dans cette application. Nous avons aussi choisi Java pour la puissance de la Javadoc native ainsi que celle de JAIN SIP Pourquoi l API JAIN SIP? JAIN SIP est un API Java développé par le NIST (National Institut Of Standardisation) et Sun Microsystems. Il a l avantage d être gratuit et sans aucune contrainte de licence. Il bénéficie d une interface propre, complète et documentée (Javadoc, exemples, etc.). De plus cette API est reconnue comme stable depuis la version 1.2 (celle que nous utiliserons). Il existe un support actif de cet API et les derniers petits bugs sont mis à jour constamment. Plusieurs produits ont déjà été développés grâce un JAIN SIP, parmi eux on compte : Un proxy SIP, un AppletPhone

17 4.3. Spécificités de JAIN SIP : JAIN SIP propose un accès total au protocole SIP, il supporte le protocole SIP décrit dans le RFC 3261 ainsi que plusieurs extensions comme : la notification d événement RFC 3265, l envoi de messages instantanés RFC 3428, le transfert d appel RFC L architecture JAIN SIP : JAIN SIP propose 3 interfaces principales : SIPStack, SIPProvider et SIPListener Architecture générale de JAIN SIP

18 4.4.1.SIPListener et SIPProvider L architecture de JAIN SIP a été développée pour l environnement J2SE. Les événements (entrée et sortie de messages SIP) sont donc basés sur un model Listener/Provider (comme pour ActionListener/Component dans les interfaces graphiques SWING). Ainsi, tout type d application JAIN SIP devra implémenter l interface SIPListener et définir les 3 méthodes qui serviront aux traitements des différentes requêtes, réponses et timeouts reçu par l interface. Afin que l interface SIPListener envoie et reçoit les messages SIP, ces derniers sont encapsulés dans un objet de type Event. import java.util.eventlistener; public interface SIPListener extends EventListener { public void processrequest(requestevent requestevent); public void processresponse(responseevent responseevent); public void processtimeout(timeoutevent timeoutevent); Les providers qui devront s enregistrer auprès de l interface SIPListener (à la manière d un JButton par exemple) doivent être associés à une adresse IP ainsi qu un port et le protocole de transport. L avantage de ceci est qu une même application peut communiquer sur plusieurs port, adresse IP et cela en TCP ou UDP. Cela s avérera utile dans autre application sachant que pour la voix et la vidéo il faut établir deux sessions distinctes SIPStack Interface L interface SIPStack permet, entre autre, de créer des «ListeningPoint» qui sont des associations IP:Port /protocole de transport (Ces «ListeningPoint» se chargent en fait de créer des Socket et ServerSocket adéquats pour établir les connexions). L interface SIPstack est donc associée à une/des adresse(s) IP (suivant les ListeningPoint et Providers inscrits) et est chargée de les manager

19 Voici un exemple pour la création d un UAC (User Agent Client) avec un provider : public UAC implements SIPListener { SIPFactory = SIPFactory.getInstance(); SIPStack = SIPFactory.createSIPStack(properties); udplisteningpoint = SIPStack.createListeningPoint(« », 5060, «udp»); SIPProvider = SIPStack.createSIPProvider(udpListeningPoint); SIPProvider.addSIPListener(this);

20 4.4.3.Les messages SIP et leurs entêtes Le protocole SIP (comme le protocole http) définie deux types de messages : Les requêtes et les réponses pour lesquels JAIN SIP définit deux interfaces. Les messages de type requêtes, qui sont envoyés du client au serveur, contiennent une méthode indiquant le type de la requête, ainsi qu un URI qui indique l utilisateur ou le service que l on désire joindre. Les messages de type réponse, qui sont envoyés par le client en réponse à une précédente requête, contiennent un statut indiquant le type de réponse, un URI indiquant l utilisateur ou le service qui était adressé et une phrase indiquant le résultat de la requête. Les entête SIP sont similaires au entête très proche des entêtes http, JAIN SIP offre pour chaque entête une interface spécifique, contrairement à certains modèles qui offrent une interface générique pour traiter toute les informations qu elles contiennent. Ci-dessous, un exemple complet avec le message SIP à gauche et son implémentation avec JAIN SIP à droite :

21 4.4.4.Transactions et dialogues Dans l architecture SIP une transaction est une séquence de messages SIP (une requête et toutes les réponses à cette requête) échangés entre les différents éléments du SIP. A nouveau, JAIN SIP a standardisé ces transactions en deux interfaces : Une interface pour les transactions client et une pour les transactions serveur. Le principe de ces transactions est d associé à une requêtes ou a une réponse un objet transaction (identifiable par un ID) afin que l application prenne en charge certaines fonctions comme, par exemple, l association automatique des réponses à une requête envoyée. A l arrivée d une requetes invite, l application de l appelé pourra créer une Transaction#1 et l associer a la requete INVITE, elle se chargera alors d envoyer automatiquement le Trying, Ringing et le OK

22 Les dialogues dans l architecture SIP sont identifiés en utilisant le call-id, l étiquette From et l étiquette To des messages SIP. Les dialogues sont établit lors de la création de la transaction nécessitant une notion de dialogue (INVITE, SUBSCRIBE ). Les messages dont ces 3 champs sont respectivement identiques appartiennent à un même dialogue. Ainsi un dialogue englobera une ou plusieurs transactions. Architecture Request Respond/Transaction/Dialogue de JAIN SIP

23 La classe SipGUI : import java.awt.*; import javax.swing.*; public class SipGUI implements MouseListener, ActionListener { private JFrame fenetre; private JTextPane textpane; private StyledDocument doc; private JPanel numpanel; private JPanel optionpanel; private JMenuBar menu; private JMenu menufichier; private JMenu menuedition; private JMenu menuaide; private UA ua; private JLabel labelbas; private String adressecontact; private String callid=""; private InterfaceSauvegarde is; private InterfaceHistorique ih; private JButton carnetbutton; private ContactDialog f; private HistoriqueDialog h; private PreferenceTab pf; public SipGUI() throws Exception { fenetre = new JFrame("SIuP Phone"); JFrame.setDefaultLookAndFeelDecorated(true); JPanelFond contentpane = new JPanelFond("images/logoFAC.gif", true); contentpane.setopaque(false); contentpane.setbackground(color.white); //contentpane.setmaximumsize(new Dimension(245,505)); fenetre.setcontentpane(contentpane); fenetre.setlocation(600, 200); fenetre.setsize(240,490); fenetre.setdefaultcloseoperation(jframe.exit_on_close); fenetre.getcontentpane().setbackground(color.white); fenetre.getcontentpane().setlayout(new BoxLayout(fenetre.getContentPane(), BoxLayout.PAGE_AXIS)); fenetre.getrootpane().setbackground(color.white); menu = new JMenuBar(); menufichier = new JMenu("Fichier");

24 JMenuItem itemappeler = new JMenuItem("Appeler"); menufichier.add(itemappeler); JMenuItem itemraccrocher = new JMenuItem("Raccrocher"); menufichier.add(itemraccrocher); JMenuItem itemquitter = new JMenuItem("Quitter"); menufichier.add(itemquitter); menuedition = new JMenu("Edition"); JMenuItem itemajouter = new JMenuItem("Ajouter un contact"); itemajouter.addactionlistener(this); menuedition.add(itemajouter); JMenuItem itemhistorique = new JMenuItem("Historique des appels"); itemhistorique.addactionlistener(this); menuedition.add(itemhistorique); JMenuItem itempreferences = new JMenuItem("Prrences"); itempreferences.addactionlistener(this); menuedition.add(itempreferences); menuaide = new JMenu("Edition"); JMenuItem itemapropos = new JMenuItem("A propos"); menuaide.add(itemapropos); menu.add(menufichier); menu.add(menuedition); menu.add(menuaide); fenetre.setjmenubar(menu); JPanel panelblanc = new JPanel(); panelblanc.setbackground(color.white); panelblanc.setmaximumsize(new Dimension(300,15)); fenetre.add(panelblanc); JPanelFond panelfond = new JPanelFond("images/ecran.png", false); panelfond.setopaque(false); panelfond.setmaximumsize(new Dimension(228,103)); textpane = new JTextPane(); textpane.setpreferredsize(new Dimension(225,103)); textpane.setopaque(false); textpane.setfont(new Font("Trebuchet MS",Font.BOLD,12)); textpane.setforeground(color.black); textpane.seteditable(false); doc = textpane.getstyleddocument(); addstylestodocument(doc); panelfond.add(textpane); fenetre.getcontentpane().add(panelfond, BorderLayout.LINE_START);