UNIVERSITE HENRI POINCARE NANCY I Ecole Supérieure d Informatique et Applications de Lorraine Xavier AMEZIANE Sébastien LEVEQUE Lionel ZEINER ESIAL Troisième année Année universitaire 2002 2003 PROJET RESEAUX Voice over Internet Protocol
Sommaire Introduction 2 1. Idée 3 2.Le but : une réduction des coûts attendus 3 3. La voix 3 4. Difficultés associées à la transmission de la voix sur IP 4 4.1 Comparaison IP - Télécoms 4 4.2 Le transfert de la voix : un chemin semé d embûches 5 4.2.1 Analyse des délais 5 4.2.2 Analyse des pertes 7 4.2.3 Conclusions 7 5. Principe de fonctionnement 7 6. Les protocoles 8 6.1 Le protocole H.323 8 6.2 Le protocole SIP 9 6.2.1 Les fonctionnalités utilisées par SIP 10 6.2.2 Les composants de SIP 10 6.2.3 Utilisation de SIP 11 6.2.4 Les protocoles utilisés 11 6.2.5 Les messages SIP 12 6.2.6 Exemples de transactions 17 6.2.7 Conclusions 19 6.3 Le protocole MGCP 20 6.3.1 Généralités 20 6.3.2 Fonctionnement de MGCP 21 7. Matériels nécessaires à la mise en place de la VoIP 27 7.1 Introduction 27 7.2 Approche centralisée contre approche distribuée 27 7.3 Exemple de matériel proposé par le constructeur Cisco 28 7.4 Détail des matériels Cisco à utiliser 30 Conclusion 37 1
Introduction Avec plus de 100 millions d'utilisateurs au niveau mondial, Internet représente à l'évidence un phénomène en forte croissance (exponentielle depuis plusieurs années) dans le domaine des nouveaux moyens de communication. Bien que l Internet se développe rapidement, le téléphone reste encore le favori du public en matière de communication. Plus convivial car le contact est presque réel, il reste en plus simple d'utilisation. Pourtant, il fusionne de plus en plus avec le matériel informatique. Les utilisateurs du téléphone ont depuis toujours été habitués à payer leurs communications en fonction de la distance et de la durée de celles-ci, mais depuis l'émergence et l'extraordinaire développement de l'internet, les mentalités changent et on s'habitue au principe de réseau informatique et de son accès forfaitaire. On peut ainsi communiquer, par écran interposé, n'importe où dans le monde sans aucune considération financière puisque le prix est toujours celui d'une communication locale. C'est évidemment cet aspect financier qui est à l'origine de la téléphonie sur IP. Car c'est une révolution au niveau des tarifs qui s'annoncent démesurément bas. 2
1. Idée Voice over IP : voix sur IP. Transport de la voix sur des réseaux de données IP. La voix est numérisée, enfermée dans des paquets de données, puis transmise sur le réseau. Confondue parfois avec la téléphonie sur IP (ToIP : telephony on IP), terme désignant une architecture tout-ip et ses services de téléphonie associés. L'enjeu de la voix sur IP est de taille : téléphoner en utilisant les réseaux de données traditionnels. À la clé, une convergence voix-données-images autour d'un protocole unique (IP), une réduction des coûts et la centralisation des infrastructures dans un unique réseau. Pour le grand public, la téléphonie sur IP désigne avant tout les logiciels ou les offres permettant de coder la voix sur un réseau IP public. Avec évidemment une qualité et une sécurité minimales. Dans le monde de l'entreprise, qualité de service oblige, la VoIP ne se conçoit aujourd'hui que dans le cadre d'un réseau privé, WAN (Wide Area Network) ou LAN (Local Area Network). 2. Le but : une réduction des coûts attendue Premier bénéfice attendu de la VoIP : l'allégement des factures téléphoniques intraentreprises, voire entreprises-fournisseurs-clients dans le cas de réseaux étendus. Imaginons, par exemple, la société Durand disposant de deux sites de production, l'un à Paris, l'autre à Lyon. Pour tout ce qui concerne le transfert de données informatiques, les deux entités sont reliées par une ligne spécialisée. Pour les communications téléphoniques, chacune dispose d'une infrastructure télécoms traditionnelle construite autour d'un PBX (autocommutateur téléphonique interne). Lorsqu'un salarié parisien téléphone à l'un de ses collègues lyonnais, l'appel transite par le PBX avant d'être acheminé jusqu'à Lyon par le réseau téléphonique traditionnel ou RTC (réseau téléphonique commuté). Comment la société Durand peut-elle passer à la VoIP? En reliant directement, dans un premier temps, ses deux PBX par la ligne spécialisée. Le signal de voix analogique est alors compressé et codé pour être inséré dans des paquets IP, transmis sur le lien, puis décodé et décompressé à l'autre extrémité. Mais l'entreprise Durand peut aller plus loin. Elle peut faire le choix du tout-ip et miser sur la téléphonie sur IP. Elle pourra alors remplacer ses anciens combinés téléphoniques par des terminaux IP (téléphones IP ou PC équipés d'un logiciel de téléphonie). Cet exemple se place dans un contexte de WAN ou de réseau étendu. Reste qu'avec la chute actuelle des tarifs téléphoniques, un changement d'architecture n'est pas toujours facile à justifier. Certains défendent néanmoins que la téléphonie sur IP est déjà rentable au niveau d'un LAN ou réseau local. Ici, le surcoût de la téléphonie classique est à mettre au compte du déplacement fréquent des téléphones (déménagements, aménagements de nouveaux bureaux...) et à la gestion du câblage. Avec la téléphonie sur IP, ce souci disparaît car les terminaux, dotés chacun d'une adresse IP, peuvent être connectés instantanément à n'importe quel endroit du réseau. 3. La voix Le système vocal est complexe et basé sur des ondes sonores de fréquences différentes. Le spectre des fréquences perçues par l oreille humaine s étale de 100 Hz à 20 khz. Cette fourchette est, cependant, à réduire si l on veut distinguer les fréquences utiles des fréquences audibles. En effet, la quasi-totalité d un message sonore est compréhensible dans 3
la fourchette 300-3400 Hz. Cette dernière correspond, d ailleurs, à celle utilisée par le téléphone standard. Une conversation entre deux personnes respecte deux principes : intelligibilité et interactivité. Couper la parole à quelqu un ne se fait pas, mais c est un gage d interactivité et de dialogue. En terme de transmission numérique, cela se traduit par le terme duplex. Une conversation full duplex assure cette interactivité car chaque locuteur peut parler en même temps, ce qui arrive quand deux personnes parlent de leur propre expérience sans s écouter... Un mode half duplex induit une conversation unidirectionnelle du style CB (Citizen Band) : «quel est ton QRZ, à toi! je viens de Moselle, à toi!» Cette interactivité implique des notions de délais dans le transport de la voix (avec le téléphone, par exemple). Les mesures effectuées montrent qu un temps de transit inférieur à 150 ms garantit un dialogue actif. Jusqu à 400 ms (limite supérieure) le dialogue reste tout de même assez réactif. Au-delà de cette limite le contradicteur aura l impression de parler dans le vide. 4. Difficultés associées à la transmission de la voix sur IP Afin de bien percevoir les difficultés associées au transport de la voix sur IP, un comparatif entre la commutation de circuits des télécoms et la commutation de paquets d IP est nécessaire. Ensuite, une étude des différents délais associés à VoIP permettra de comprendre les facteurs incompressibles négatifs pour la communication. 4.1 Comparaison IP Télécoms Les deux approches IP et télécoms sont pratiquement opposées. Où IP est simple et débrouillard, les télécoms sont complexes et figés. Le réseau qui est utilisé par les télécoms est le réseau X25. Le tableau suivant établi la comparaison entre ces deux systèmes sur différents points : 4
4.2 Le transfert de la voix : un chemin semé d embûches Le tableau précédent fait un état des lieux des différences entre IP et X25. Il est cependant nécessaire d'expliquer comment arrivent ses défauts de transmission. Voici pourquoi cette partie répertorie les trois principales causes des difficultés et des limites associées à VoIP : Délai : temps de transmission d'un paquet (doit rester inférieur à 400ms pour respecter les contraintes d'une conversation interactive). Gigue : variation de délai (nécessite un buffer de resynchronisation en bout de chemin). Perte : disparition de paquets au cours de la communication (fait partie de la transmission IP mais doit être soit réduite, soit inhibée). Le schéma ci-dessus reprend les difficultés évoquées et permet de comprendre quels sont les effets indésirables impliqués. 4.2.1 Analyse des délais Quantifier le délai de transmission sur le réseau de manière fiable est quasi impossible, car il y a trop d'inconnues : Table de routage, congestion, pannes, files d'attente Cependant sur le chemin que prendrait une transmission de voix, on peut détailler certains délais inhérents au réseau : 5
Délais de l'émetteur : Numérisation et codage : temps mis par une carte son ou une passerelle pour numériser et coder un signal initialement analogique. Compression qui se décompose en trois parties : o Délai de trame : contrairement à la numérisation d'un signal qui se fait en continue, la compression porte sur une certaine longueur de données. Attendre ces informations induit un temps non nul de traitement o Délai d'encodage : la compression par synthèse s'appuyant sur la prédiction, ce délai est nécessaire à l'encodeur pour savoir, pendant qu'il est en fonctionnement comment évolue le signal. o Délai de traitement : temps mis par l'algorithme pour compresser une trame. Il dépend du processeur et de l'algorithme utilisé. Mise en paquets : intervalle de temps pendant lequel l'application constitue un paquet (création de l'en-tête, remplissage des données). Transmission : ce temps dépend de la configuration dans laquelle on se trouve. A savoir soit on est relié par modem soit par accès direct sur un LAN-WAN. Délais réseau : Propagation : sur un réseau filaire, la vitesse de propagation est de 200000 km/s, cela induit un temps de propagation non nul.1111111111111111111111111111111111111 - Commutation et files d'attente : suivant la nature du réseau différents temps peuvent être indexés. Délais du récepteur (ce sont les mêmes que pour l'émetteur) : Réception. Buffer de gigue : cette mémoire tampon permet de resynchroniser les paquets arrivant avec des délais variables. Elle sert donc à compenser les décalages et remettre en ordre les paquets. Dépaquetisation. Décompression. 6
Décodage et conversion numérique analogique. Jusqu'à présent les mesures effectuées avec une solution téléphone à téléphone (via IP), sur un réseau bien géré et surdimensionné (en bande passante), montrent un délai total de 200 ms. 4.2.2 Analyse des pertes La perte d'un paquet occasionne un manque d'information lors de la réception du signal audio. Suivant le nombre de paquets perdus, la qualité sonore en bout de ligne peut s'en ressentir. Dans la philosophie IP, cette perte de paquet fait partie intégrante du concept. En effet les routeurs sont obligés (avec l'algorithme Random Early Detection) de détruire des paquets afin d'anticiper d'éventuelles congestions. Il existe principalement quatre causes de perte de paquet : Durée de vie épuisée (TTL = 0). Retard à la réception supérieur au buffer de gigue. Destruction par un module congestionné. Invalidité du paquet due à des défauts de transmission. 4.2.3 Conclusions Toutes ces contraintes et défauts inhérents à IP sont les fondements des difficultés rencontrées par le concept VoIP. 5. Principe de fonctionnement Tout projet de VoIP ou de téléphonie sur IP nécessite une transformation du PBX de l'entreprise. Une première solution consiste à y insérer une carte IP faisant office de passerelle entre le réseau téléphonique et le réseau IP. Cette démarche présente l'avantage de préserver l'existant et les postes analogiques. Seconde possibilité : remplacer le PBX par un IPBX, un matériel profilé pour le tout-ip et qui implique un déploiement massif de terminaux IP. Ces deux solutions techniques intègrent différentes fonctions de base, dont une unité de contrôle d'accès (gatekeeper), qui gère l'identification des appels, la traduction du numéro de téléphone en adresse IP, et éventuellement la définition des règles d'appel. Viennent ensuite une passerelle (gateway), chargée de l'interconnexion entre équipements réseaux hétérogènes (téléphone analogique ou numérique, carte RNIS...), et enfin une unité de contrôle (MCU Multipoint Controller Unit) gérant les sessions multicast. Aujourd'hui, l'un des freins de la téléphonie sur IP réside dans l'absence de standards communs à tous les constructeurs. Même s'il constitue souvent une base commune, le protocole de signalisation H.323 (issu d'une recommandation de l'international Telecommunication Union - Telecommunication standardization (ITU-T)) est rarement utilisé tel quel. Plus simple, SIP (proposé par Internet Engineering Task Force (IETF)) est encore peu adopté par les constructeurs de matériels. Enfin, MGCP (Media Gateway Control Protocol), autre standard de l'ietf, peine aussi à s'imposer. Une fois la communication établie, le transport et le contrôle des flux de données sont assurés par deux autres protocoles : RTP (Realtime Transport Protocol) et RTCP (Realtime Transport Control Protocol). Le premier permet de reconstituer la base de temps, de détecter les pertes et d'identifier le contenu des paquets pour leur transmission sécurisée. Le 7
second, RTCP fournit, entre autres, des informations sur la qualité de la session. Lorsque les paquets de voix transitent sur le réseau, les paramètres à maîtriser sont la latence (délai de transmission), la gigue (variation du délai de transmission), la perte des paquets (au-delà de 20 %, le signal n'est plus audible). Pour s'en assurer, les différents équipements du réseau (postes clients, routeurs...) doivent être dotés de dispositifs de QoS (qualité de service). La priorité est ainsi donnée aux paquets de voix. Sur Internet, l'hétérogénéité des matériels réseau impliqués empêche toute maîtrise de la qualité de transmission. C'est la raison pour laquelle il est aujourd'hui impossible de mettre en place de la voix sur IP sur Internet avec un niveau d'exigence acceptable pour une entreprise. 6. Les protocoles Ainsi, nous pouvons conclure qu il existe trois principaux protocoles utilisés pour la voix sur IP : Le protocole H.323 (de l ITU-T) Le protocole SIP (de l IETF) Le protocole MGCP (de l IETF) 6.1 Le protocole H.323 H.323 («Visual Telephone Systems and Equipment for Local Area Networks which Provide a Non-Guaranteed Quality of Service») : le standard H.323 fournit les services pour le transfert de l audio, de la vidéo ou de données à travers des réseaux IP. En se référant à ce standard, les produits de constructeurs différents sont censés interopérer, sans souci de compatibilité. H.323 est un ensemble de recommandations venant le ITU-T, qui définissent des standards pour le transport de données multimédia sur des réseaux locaux qui ne fournissent pas une qualité de service garantie. La première version a été approuvée en 1996 par le Study Group 16 de l ITU-T, la version 2 l ayant été en janvier 1998. Ce standard a une étendue très large, incluant à la fois des stations de visio conférence que des PC multimédia, en mode point à point ou en mode multi points. H.323 définit également le contrôle des appels, la gestion de la bande passante, les interfaces entre le(s) LAN(s) et les autres réseaux. H.323 définit quatre composants majeurs qui interagissent dans un réseau de paquets : les endpoints, qui initient un appel audio, vidéo ou de visio conférence une passerelle ( gateway ) pour l interaction avec un réseau téléphonique commuté un élément optionnel ( gatekeeper ) qui permet la connectivité entre des équipements ISDN externes qui appellent dans le réseau de paquets pour atteindre un élément H.323 les MCUs ( «Multipoint Control Units» ) pour la conduite de visio conférences en multi points. Concernant le support de la voix, H.323 supporte 5 algorithmes : G.711 ( obligatoire ), G.722, G.728, G.723.1 et G.729, G.723.1 ayant été choisi comme celui par défaut pour les applications de téléphonie dans le monde Internet. H.323 fait partie d une série plus large de standards de communication qui permettent la visioconférence à travers un ensemble de réseaux. Connus sous le terme générique, H.32x, cette série inclut notamment H.320 et H.324, qui adressent les communications dans le monde ISDN d une part, et pour les réseaux RTCs d autre part. 8
Schéma de la pile protocolaire H.323 : Architecture globale d H.323 : 6.2 Le protocole SIP Cette partie se concentre sur le protocole d ouverture de session (SIP), qui est un protocole récent publié par l I.E.T.F. (Internet Engineering Task Force) sous la RFC (Request For Comments) 2543 en mars 1999. La RFC 2543 présente la source d information la plus complète sur le sujet. Selon la RFC 2543, le protocole d initiation de session (SIP) est un protocole de signalisation appartenant à la couche application du modèle OSI. Son rôle est d ouvrir, modifier et libérer les sessions ou appels ouverts entre un ou plusieurs utilisateurs. Pour ouvrir une session, l utilisateur émet une invitation transportant un descripteur de session permettant aux utilisateurs souhaitant communiquer de s accorder sur la compatibilité de leur média. SIP 9
peut relier des stations mobiles en transmettant ou redirigeant les requêtes vers la position courante de la station appelée. 6.2.1 Les fonctions utilisées par SIP Pour établir et terminer des communications multimédia, SIP utilise les 5 fonctions suivantes : User location : permet de localiser le poste terminal utilisé pour communiquer User capabilities : détermine quels média vont être échangés(voix, vidéo, données ) ainsi que les paramètres associés User availability : détermine si le poste appelé souhaite communiquer et autorise l appelant à la contacter Call setup ou " ringing ": avertit les parties appelant et appelé de la demande d ouverture de session (sonnerie ou message de réception d appel) et mise en place des paramètres d appel Call handling : gère le transfert et la fermeture des appels 6.2.2 Les composants de SIP Comme HTTP, SIP propose l établissement, la modification et la clôture de sessions en mode client / serveur, c est à dire l échange de requêtes coté client et réponse coté serveur. Exemple : User Agent SIP A 1 INVITE Serveur SIP 2 INVITE User Agent SIP B 4 OK 3 OK 5 ACK 6 ACK Dans un système SIP on trouve deux composantes, les users agents (U.A.S et U.A.C) et un réseau de serveurs. l U.A.S (User Agent Server) : 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 l U.A.C (User Agent Client) : représente l agent de la partie appelante, c est une application de type client qui initie les requêtes le relais mandataire ou P.S. (Proxy Server) : auquel est relié un terminal fixe ou mobile (lors de son déplacement, le terminal est relié au PS le plus proche et change 10
constamment de PS) agit à la fois comme client et serveur. Un tel serveur peut interpréter et modifier les messages qu il reçoit avant de les retransmettre le R.S (Redirect Server) : 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 L.S (Location Server)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) 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. 6.2.3 Utilisation de SIP L ouverture d une session à l aide du protocole SIP peut s effectuer de façon directe entre deux User Agents qui jouent le rôle de client et de serveur ou de façon indirecte au travers d un serveur proxy. Dans ce dernier cas, le serveur à en charge la localisation du serveur B (exemple) dont l adresse est passé dans le message INVITE. Dans le cas de changement de localisation, le serveur proxy est renseigné sur l adresse de l utilisateur à l aide du serveur de localisation. Et le serveur proxy adresse un message 302 MOVE TEMPORARILY avec les nouvelles coordonnées de localisation 6.2.4 Les protocoles utilisés L architecture en couches de SIP, telle que la présente le modèle OSI, incorpore les protocoles : RTP, RSVP, RTCP, SAP et SDP. SDP Media RTSP SIP RTCP RTP RSVP TCP UDP IPV4,IPV6 RSVP est un protocole utilisé pour réserver les ressources réseaux sur IP avec une excellente qualité de service(qos) R.T.P.(Real-time Transport Protocol) pour transporter des informations en temps réel avec une excellente qualité de services 11
R.T.C.P.(Real-Time streaming Control Protocol) pour assurer le contrôle de flux des données multimédia S.A.P.(Session Announcement Protocol) pour préciser si les sessions mutimedia ouvertes S.D.P.(Session Description Protocol) est un protocole de description des sessions multimédia Exemple de SDP pour la téléphonie sur internet : 6.2.5 Les messages SIP Contrairement au protocole HTTP, qui est basé sur TCP, SIP utilise UDP pour les applications multimédia. Pour transporter plusieurs transactions à la fois, SIP peut utiliser une simple connexion TCP(mode flux) ou des datagrammes UDP(mode bloc). Seulement,les datagrammes UDP, tout en-têtes compris, ne doivent pas excéder une certaine longueur(m.t.u. pour Maximum Transmission Unit). Si la MTU est inconnue, elle est de 1500 octets par défaut. Cette taille permet l encapsulation des datagrammes UDP ou segments TCP dans des paquets IP sans fragmentation. Un message SIP peut être à la fois une requête d un client vers un serveur ou une réponse d un serveur vers un client. Ces deux types de messages SIP utilisent le format suivant : Ligne de requête ou ligne d état Entête de requête ou de réponse CRLF : Balise indiquant le début de corps du message Corps du message 6.2.5.1 Les requêtes et les réponses SIP Les requêtes SIP Les méthodes utilisées dans une requête SIP sont : 12
INVITE : indique que l application ou utilisateur est invité à participer à une session. Le corps du message contient la description de la session (média supportés par l appelant entre autres). ACK : confirme que le client a reçu une réponse définitive à une requête INVITE. OPTIONS : un PS en mesure de contacter l UAS appelé, doit répondre à une requête OPTIONS en précisant ses capacités à contacter l UAS. BYE : est utilisée par l UAS de l'appelé pour signaler au PS local qu il ne souhaite plus participer à la session. CANCEL : la requête CANCEL permet d annuler une requête non validée par une réponse finale d état. 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é. Les réponses SIP Une réponse à une requête est caractérisée, par un code et un motif, appelés code d état et reason 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 Exemple : 13
SIP/2.0 200 OK Requête INVITE Via : SIP/2.0/UDP swerdet.ausys.se FROM : Mattias<sip : mattias@ausys.se> TO: Lars<sip: lars@ausys.se> Call-ID: 4353456345@swerdet.ausys.se Content- Type: application/sdp Content-length : 158 V=0 O=lars 3245436364 3453633533 IN IP4 172.4.5.4 S=Hello again C= IN IP4 mars.ausys.se M=audio 3456 RTP/AVP 0 3 4 5 Réponse à la requête INVITE INVITE sip :mattias@mars.ausys.se SIP/2.0 Via : SIP/2.0/UDP swerdet.ausys.se From : Lars<sip :lars@ausys.se> To: Mattias<sip:mattias@ausys.se> Call ID: 4353456345@swerdet.ausys.se Cseq: 1 INVITE Subject: Hello Mattias Content Type: application/sdp Content-type : application/sdp Content-Lengt : 187 V=0 O=mattias 52655765 2687637 IN IP4 172.2.2.5 S= Hello Mattias C= IN IP4 swerdet.ausys.se M = audio 3456 RTP/AVP 0 3 4 5 6.2.5.2 Les en-têtes SIP Les différents champs d'en-tête qu'utilise SIP ne nécessitent pas d'ordre particulier sauf dans le cas de l'en-tête général Via où l'ordre des champs d'en-tête importe. En particulier, l'on distingue les champs d'en-têtes des messages transmis saut par saut(c'est-à-dire qui sont interprétés et peuvent être modifiés ou ajoutés par tous les serveurs qu'ils traversent) des entêtes des messages transmis de bout en bout(interprétés par les émetteurs et destinataires uniquement et non modifiables par les serveurs traversés). Les champs d'en-tête saut par saut doivent apparaître avant les champs d'en-tête de bout en bout. Les PS ne doivent pas réordonner les champs d'en-tête mais peuvent ajouter éventuellement des champs Via ou autres champs de type "saut par saut". Chaque méthode (ACK, BYE, CANCEL, INVITE, OPTIONS, REGISTER) requière, ne supporte pas ou supporte de façon optionnelle certains champs d'en-tête. Par exemple, les champs d'en-tête CALL-ID, Cseq, FROM, TO et Via sont requis par toutes les méthodes(dans le cas de la méthode OPTIONS, il faut ajouter en plus le champ d'en-tête Allow). Ces champs d'en-tête sont de type "de bout en bout". Il existe 4 types de champs d'en-tête: En-tête général s applique à la fois aux messages de requête et de réponse : Accept ou Accept-Encoding ou Accept-Language ou CALL-ID ou Contact ou Cseq ou Date ou Encryption ou Expires ou From ou Record-Route ou Timestamp ou To ou Via En-tête d entité définit le type d'informations contenues dans le Corps du message ou la ressource identifiée par la requête en l'absence du Corps du message : Content- Encoding ou Content-Lenght ou Content-Type 14
En-tête de requête Le champ d'en-tête de requête autorise le client à ajouter des informations concernant sa requête et lui-même à destination du serveur : Authorization ou Contact ou Hide ou Max-Forwards ou Organization ou Priority ou Proxy-Authorization ou Proxy-Require ou Route ou Require ou Response-Key ou Subject ou User-Agent En-tête de réponse Le champ d'en-tête de réponse autorise le serveur à ajouter des informations concernant sa réponse, qui ne peuvent pas être placées dans la ligne d'état, sur lui-même et sur l'accès à la ressource identifiée par la requête URI : Allow ou Proxy-Authorization ou Retry-After ou Server ou Unsupported ou Warning ou WWW-Authenticate. Dans le tableau suivant on donnera le détail d utilisations de ces différents champs : Champs Accept Accept-Encoding Accept-Language Allow Authorization Call-ID Contact Content-Encoding Content-Length Content-Type Utilisations Utilisé dans les messages INVITE, OPTIONS et REGISTER qui permet d'indiquer les types de média qui seront acceptés dans la réponse à ce message. Conditionne la réponse car il détermine quels codages text-based y seront acceptés. Il permet au client d indiquer au serveur quel langage à utiliser dans le corps du message de la réponse au client. Indique les méthodes valides supportées par les entités identifiées par la requête URI. Champ optionnel à inclure par l'utilisateur souhaitant s'authentifier vis à vis du serveur auquel il est relié Identifie une invitation précise ou tous les enregistrements d un client particulier. Champ pouvant apparaître dans les requêtes INVITE, ACK et REGISTER ou dans les réponses de codes 1xx, 2xx, 3xx et 485. Il fournit en général l URL où l'utilisateur pourra Indique le code utilisé pour écrire et lire l'en-tête d'entité. Ainsi le serveur qui reçoit le message sait quel mécanisme de décodage appliquer pour lire le Content-Type décrit ci-dessus et peut connaître le type de média utilisé. Ce champ est très utile si l'on veut compresser les en-têtes sans perdre les informations précieuses qu'ils contiennent Il indique simplement la taille du Corps du message envoyé, en nombre décimal d'octets. Il indique les types de média utilisés dans le Corps du message envoyé. 15
Cseq Date Encryption Expires From Hide Max-Forwards Organization Priority Proxy-Authenticate Proxy-Authorization Proxy-Require Record-Route Response-Key Retry-After Server Chaque requête doit obligatoirement contenir un numéro de séquence Cseq (entier non signé de 32 bits). Le Cseq initial est choisi arbitrairement par celui qui envoie la requête INVITE mais doit toujours être inférieur à 2^31. donne la date d émission de la requête ou de la réponse. Les retransmissions possèdent la même date que la requête ou réponse d origine. Ce champ spécifie si le message est crypté et suivant quel cryptage. donne la durée au-delà de laquelle le message expire. indique la personne à l'origine du message Le client utilise ce champ lorsqu'il veut que le chemin compris dans l'en-tête VIA soit caché aux prochains Proxy Servers que traversera le message. utilisé pour limiter le nombre de PS ou passerelles que la requête peut traverser jusqu au prochain serveur dans le sens de l'uac vers l'uas (downstream). Précise le nom de l organisation à laquelle l entité dont émane la requête ou la réponse appartient Indique le niveau d urgence de la requête, tel qu il est perçu par le client. Ce champ doit être rempli dans une réponse Proxy Authentification Required (code 407). Permet au client de s identifier dans sa requête en destination d un PS le lui ayant demandé. Indique quels champs d en-tête le PS supporte. Ce champ permet de mémoriser un chemin pour faciliter l'acheminement de la réponse. Chaque Proxy Serveur traversé ajoute son adresse dans ce champ en début de liste. Le serveur appelé copie cette liste, sans la changer, dans l'en-tête Route de sa réponse. La première entrée est ainsi l'adresse du serveur le plus proche de celui qui répond. le client utilise cet en-tête dans sa requête pour déterminer la clé a utilisé pour crypter la réponse. ce champ n'est utilisé que dans les réponses Service Unavailable(code 503), Not Found (code 404), Busy (code 600) ou bien Decline (code 603) pour indiquer à l'emetteur de la requête quand est-ce qu'un service "normal" pourra reprendre. Il contient une date ou un nombre en décimal de secondes. Il contient les informations sur les softwares utilisés par les 16
Subject Timestamp To Unsupported User-Agent UAS. Résumé ou nature de l'appel qui peut permettre de le filtrer sans avoir à lire la description de la session. Précise l'instant (date) où le client a envoyé la requête au serveur. C'est l'adresse du destinataire. Ce champ est bien sûr obligatoire. Liste quelles configurations ne sont pas supportées par le serveur. Contient des informations sur le terminal de l'utilisateur (UAC/UAS) à l origine de la requête. Via Contient les adresses des serveurs (PS) que traverse la requête. Warning Les avertissements sont contenus dans les réponses dans le langage le plus compréhensible pour l'utilisateur. WWW-Authenticate Doit être inclus dans une réponse Unauthorized (code 401). Contrairement aux protocoles standards tels que IP ou TCP, où le format des paquets ou segments est bien déterminé, le format des messages SIP n est pas standard. Les champs d en-tête sont choisis " à la carte " selon un panel de champs. Lorsque les messages SIP sont transportés par UDP, avec authentification et une description de session complexe, il arrive que la taille du message SIP de requête ou réponse dépasse la MTU. Pour résoudre ce problème, un format compact a été défini utilisant des abréviations pour les champs d en-tête suivants : Champ d en-tête Abréviation associée Content-Type C Content - Encoding E From F CALL-ID I Contact M(pour " moved ") Content-Length L Subject S To T Via V Les clients doivent être capables de mélanger des champs d en-tête de messages courts (format normal) avec ceux de messages longs (format compact) en utilisant les mêmes requêtes. Les serveurs doivent accepter ces deux formats à la fois. 6.2.6 Exemples de transactions Pour faire appel à SIP, l application de l UAC appelant envoie une requête INVITE au Proxy Server (PS) auquel il est relié. Ce serveur, via d'autres PS, transmet cette requête à l'uas auquel est relié l appelé. Cette requête demande à l appelé s il veut rejoindre un forum 17
de discussion, assister à une visioconférence ou établir simplement une communication privée avec l appelant. Si l appelé est d accord, il renvoie une réponse OK (code 200) à l appelant qui confirme alors qu il a bien reçu la réponse de l appelant. Pour cela, il envoie une requête ACK, acquittement (acknoledgement) à l appelé. De la même manière, si l utilisateur souhaite se déconnecter, l application de l utilisateur émet une requête BYE au lieu de ACK. La requête INVITE contient la description de la session ouverte qui stipule quels sont les médias et formats des messages SIP utilisés (protocole SDP). Pour une communication unicast, la requête INVITE précise les types de média et formats que l appelant utilisera et vers où il souhaite que les données soient envoyées. Si l appelé est d accord avec cette description, sa réponse contiendra les mêmes paramètres(toutes les requêtes et leurs réponses ont le même Call-ID). En multicast, l appelé répondra que si sa description est différente. Exemple de fonctionnement d une requête INVITE en mode Proxy Server (PS) : 1. Le client appelant (UAC) envoie au PS une requête INVITE avec l adresse SIP du destinataire henning@columbia.edu 2. Le PS contacte le Location Serveur et lui fournit toute ou une partie de l adresse SIP du destinataire : henning 3. Le PS obtient alors une adresse plus précise hgs@play 4. Le PS envoie une requête INVITE au serveur destinataire dont l adresse lui a été fournie par le service de localisation du Location Server : play 5. L UAS du destinataire avertit l'appelé 6. Et retourne au PS de l'appelant l accord du destinataire pour communiquer par une réponse OK (code 200) 7. Ce PS retourne alors au client appelant l accord du destinataire 8. La réception de l accord du destinataire est acquittée par le client appelant par une requête ACK 9. Cet acquittement est transmis directement à l appelé 10. Communication établie 18
Exemple de fonctionnement d une requête INVITE en mode Redirect Server [5] 1. Le client appelant (UAC) envoie une requête INVITE au redirect serveur (RS) avec l adresse destinataire 2. et 3. Le RS contacte le Location Server qui lui fournit l adresse du serveur destinataire : columbia.edu 4. Le RS renvoie au client appelant la nouvelle adresse par une réponse Moved (code 302) signalant que le terminal destinataire a changé de PS ; 5. Le client appelant envoie une requête ACK au RS pour acquitter ; 6. Puis ce client envoie une requête INVITE au serveur du destinataire. Cette requête possède le même Call-ID que la première mais son numéro de séquence Cseq est plus élevé 7. Le PS du destinataire avertit l'uas de l'appelé, qui retourne au PS son accord pour communiquer par une réponse OK (code 200). Le PS retourne au client appelant l accord du destinataire 8. La réception de l accord du destinataire est acquittée par le client appelant par une requête ACK, Cet acquittement est transmis directement à l appelé Nous venons de voir, à travers ces 2 exemples que si certains paramètres de la session doivent être changés, un nouveau INVITE est émis tout en conservant le Call-ID mais un Cseq plus grand doit être utilisé. Pour localiser un utilisateur SIP, notons d abord qu un terminal utilisateur peut constamment se déplacer. Sa position doit être enregistrée dynamiquement par un location server. Un tel serveur enregistre plusieurs positions pour un même terminal, qui est relié à plusieurs PS à la fois lorsqu il se déplace (les PS les plus proches). Lorsqu'un serveur SIP interroge son location server, il établit une liste des postions possibles de l utilisateur à partir des résultats reçus. Cette liste contient 0 position ou plus. Pour communiquer sa nouvelle position au serveur SIP, le terminal de l utilisateur lui envoie une requête REGISTER. 6.2.7 Conclusions SIP (Session Invitation Protocol) est un protocole de signalisation permettant à un appelant de retrouver un appelé via des serveurs dits "proxy" ou "redirect", ceux-ci pouvant consulter des serveurs de "localisation" ou des serveurs "registrars" auprès desquels les utilisateurs ont pu enregistrer leur localisation (même temporaire). Une fois que le client 19