Le protocole SIP Le protocole SIP SIP est un protocole de commande de couche application qui peut établir, modifier et terminer des sessions multimédia (conférences) telles que des communications téléphoniques par l’Internet. SIP peut aussi inviter des participants à des sessions déjà existantes, telles que des conférences en multi diffusion. Des supports peuvent être ajoutés (et retirés) à une session existante. SIP prend en charge de façon transparente la transposition de nom et les services de redirection, ce qui sert de support à la mobilité personnelle. les utilisateurs peuvent conserver une identification unique vue de l’extérieur, indépendamment de leur localisation dans le réseau. SIP prend en charge cinq facettes de l’établissement et de la terminaison de communications multimédia : Localisation de l’utilisateur : détermination du système terminal à utiliser pour la communication. Disponibilité de l’utilisateur : détermination de la volonté de l’appelé à s’engager dans une communication. Capacités de l’utilisateur : détermination du support et des paramètres de support à utiliser. Etablissement de session : "sonnerie", établissement des paramètres de session à la fois chez l’appelant et l’appelé. Gestion de session : y compris le transfert et la terminaison des sessions, la modification des paramètres de session et l’invocation des services. Copyright © 2011 - Global Knowledge France

Sommaire Module 1 Introduction au protocole SIP Le protocole SIP Sommaire Module 1 Introduction au protocole SIP Module 2 Les différents composants SIP et leurs rôles au sein de l'architecture Module 3 Les messages SIP Module 4 Les Extensions de SIP Module 5 SIP et la sécurité Copyright © 2011 - Global Knowledge France

MODULE 1 Introduction au protocole SIP Le protocole SIP MODULE 1 Introduction au protocole SIP Copyright © 2011 - Global Knowledge France

Un bref Historique de SIP Le protocole SIP Un bref Historique de SIP Protocole Internet Engineering Task Force (IETF) Inventeurs: M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg Devient un “Proposed Standard” et la RFC 2543 en Mars 1999 dans le groupe de travail MMUSIC de l’IETF. Création d’un groupe de travail séparé , le SIP WG en September 1999. Création d’un groupe de travail SIPPING pour les applications de SIP Création d’un groupe de travail SIMPLE (présence et messagerie instantanée). La RFC 2543 est remplacée par la RFC 3261 en Février 2002 Les spécifications sont ré-écrites pour plus de clareté, et on ajoute de nouvelles fonctionnalités On assure un maximum de compatibilité avec la RFC 2543 SIP a débuté en 1996 comme composante de l’architecture "Mbone ». Le Mbone, ou BackBone multicast, était un réseau de multidiffusion expérimental superposé au réseau Internet public. Il a été utilisé pour la distribution de contenu multimédia, y compris pour des discussions et des séminaires, ainsi que des réunions de l'IETF. SIP a été conçu pour être un composant de la signalisation afin d’inviter les utilisateurs à participer à des sessions multimédias en cours ou futures. Le développement de SIP est resté fidèle à la philosophie de l'IETF qui consiste à créer des protocoles hautement interopérables et qui s'adaptent à la taille de l'Internet. L'IETF suit également le principe de la réutilisation des protocoles existants plutôt que la création de nouveaux protocoles de toutes pièces. Ainsi dès le début , SIP utilise MIME, les URL et le SDP. SIP a emprunté des idées à HTTP et SMTP , ce qui a rendu son implémentation familière aux développeurs et ceci depuis le début. SIP a immédiatement gagné la réputation de «la facilité» par rapport à des protocoles VoIP concurrents comme H.323. Malheureusement cette simplicité n’a pas été conservée et rend aujourd’hui SIP très extensible mais du même coup très complexe. Copyright © 2011 - Global Knowledge France

Caractéristiques du Protocole SIP Le protocole SIP Caractéristiques du Protocole SIP Orienté Transaction Séquence de Requêtes-Réponses Indépendant des couches de transport UDP, TCP, SCTP Transport sécurisé possible : TLS sur TCP, IPSec support de la fiabilité sur UDP ( retransmission ) Indépendant de la session en cours (reconfiguration) Basé sur une syntaxe HTTP 1.1 Protocole orienté texte (encodage UTF-8) Serveurs permettent de maintenir des infos minimales sur l‘etat des sessions : Stateless proxy SIP se fonde sur un modèle de transaction de demande/réponse du style HTTP. Chaque transaction consiste en une demande qui implique une méthode ou fonction particulière sur le serveur, et au moins une réponse. Des supports peuvent être ajoutés (et retirés) à une session existante. SIP prend en charge de façon transparente la transposition de nom et les services de redirection, ce qui sert de support à la mobilité personnelle. Les utilisateurs peuvent conserver une identification unique vue de l’extérieur, indépendamment de leur localisation dans le réseau. SIP n’est pas un système de communications intégré verticalement. SIP est plutôt un composant qui peut être utilisé avec d’autres protocoles de l’IETF pour construire une architecture multimédia complète. Normalement, ces architectures vont inclure des protocoles tels que le protocole de transport en temps réel (RTP). Le protocole de description de session (SDP, Session Description Protocol pour la description des sessions multimédia). Donc, SIP devrait être utilisé en conjonction avec les autres protocoles afin de fournir des services complets aux utilisateurs. Cependant, la fonction et le fonctionnement de base de SIP ne dépendent d’aucun de ces protocoles. Copyright © 2011 - Global Knowledge France

Faisons les présentations : Alice-Bob-Charlotte Extrait de la RFC 2543 Le protocole SIP Faisons les présentations : Alice-Bob-Charlotte Extrait de la RFC 2543 Voici Alice ou “A” B C A Voici Bob ou “B Alice appelle toujours Bob Quelquefois Bob transfère l’appel à Charlotte Charlotte reçoit rarement des appels en direct Ces trois personnages, Alice, Bob et Charlotte ont été rendus célèbres car ils sont utilisés dans toutes les RFC SIP expliquant la dynamique des flux. Dans les scénarios d’appels : Alice appellera Bob et lorsque le scénario d’appel utilisera une troisième entité nous solliciterons les services de Charlotte. Voilà pour les présentations … continuons donc notre voyage dans le monde de SIP. Voici Charlotte ou “C” Copyright © 2011 - Global Knowledge France

Comparaison Téléphonie Traditionnelle & Téléphonie IP Le protocole SIP Comparaison Téléphonie Traditionnelle & Téléphonie IP VoIP Traditionnelle Réseau De Conversion Circuit VoIP Protocoles SS7 Q.931 (RNIS) Analogique Numérique Equipements Commutateur Circuit Multiplex SDH Brasseur IT Protocoles RTP/RTCP SIP Equipements SoftSwitch SBC Proxys Reseaux IP Le système téléphonique le plus commun dans le monde utilise encore, surtout en bordure de réseau , une technologie analogique pour laquelle la voix est représentée sous forme d’une grandeur physique continûment variable. Le téléphone analogique utilise la modulation de signaux électriques le long d’un câble pour transporter la voix. Pour des raisons économiques et techniques, la plupart des pays utilisent aujourd’hui une technologie numérique au cœur de leur réseau téléphonique. Le multiplexage temporel est au cœur de ces technologies. Toutefois tous les réseaux téléphoniques utiliseront le multiplexage statistique sur une technologie en mode paquet basé sur le protocole IP sans établissement de circuits virtuels comme en ATM ou Relais de trames. La technologie IP s’adapte bien mieux aux grands réseaux et permet d’apporter des communications vocales IP de bout en bout. Le formidable développement de nouveaux réseaux de télécommunications tels qu’Internet a été incontestablement la source de l’émergence de la voix sur IP. La voix sur IP s’appuie sur un nombre important de protocoles issus de l’Internet. Copyright © 2011 - Global Knowledge France

Trouver Bob ! Comparaison mode Circuit et mode Paquet ( SIP ) Le protocole SIP Trouver Bob ! Comparaison mode Circuit et mode Paquet ( SIP ) Philosophie Circuit : Parallèle C’est bien , mais est-ce efficace??? signalisation voix NICE PARIS LYON RENNES BREST Bob est proche du bureau d’Alice Bob est proche du bureau d’Alice Les Réseaux NGN (Next Generation Network) permettent une grande souplesse car ils sont basés sur les technologies Internet en empruntant les enseignements tirés de HTTP et SMTP, qui sont les deux protocoles les plus utilisés sur l'Internet aujourd'hui. Notez que les deux réseaux (circuits et paquets), permettent d’entrer en relation avec Bob. Mais sur un réseau IP basé sur SIP, l’efficacité est bien meilleure et permet de trouver Bob quelque soit sa localisation avec un flux média optimisé en terme de chemin. Philosophie SIP : Séparé {Idéalement , le média prend le chemin optimum } Les services IP proposent cette philosophie (WEB, SMTP) Copyright © 2011 - Global Knowledge France

Le protocole SIP Module 2 Les différents composants SIP et leurs rôles au sein de l’architecture Copyright © 2011 - Global Knowledge France

Les composants Le protocole SIP Copyright © 2011 - Global Knowledge France

User Agent SIP Requêtes UA ou Réponses User Agent SIP INVITE: ACK: Le protocole SIP User Agent SIP Requêtes INVITE: ACK: BYE: CANCEL: OPTIONS: REGISTER: User Agent Client Envoi les requêtes Reçoit les réponses UA UAC ou UAS Réponses 100 200 300 400 500 600 User Agent Serveur Reçoit les requêtes Envoi les réponses User Agent SIP User Agent Client User Agent Serveur Application Un UAC est une application cliente qui initie la demande SIP. Un UA est une application qui contient à la fois un UAC et un UAS. Un UAS est une application serveur que les utilisateurs contactent au travers une requête SIP. La réponse sera une acceptation, un refus ou une redirection. Un UA peut s’interfacer avec: Une Personne Une ligne Téléphonique Une Messagerie Vocale Un Softswitch l Un Session border controller Un Serveur de Media Le User Agent transporte les requêtes initiées par une personne ou un logiciel de traitement d’appels. Copyright © 2011 - Global Knowledge France

Proxy SIP Proxy Serveur Stateful ou Stateless Routage des appels Le protocole SIP Proxy SIP Registrar SIP Proxy UA UAS UAC Invite UA UAS UAC UAC Invite UAC UAS UAS SIP UA Proxy / Location Server SIP UA Proxy Serveur Stateful ou Stateless Routage des appels Charger de l’authentification Support des applications Proxy (Proxy Server) : Un proxy est un dispositif qui agit comme un serveur d’un côté car il reçoit des requêtes, et comme un client de l’autre car il retransmet des requêtes. Selon le niveau de contrôle que la fonction de proxy a sur les messages SIP, elle est désignée sous le nom : Stateless Proxy Stateful Proxy On retrouve aussi des rôles de proxy : Outbound Proxy Registrar Copyright © 2011 - Global Knowledge France

Stateful ou. Stateless Proxy ? Le protocole SIP Stateful ou. Stateless Proxy ? Définition d’un proxy Stateless Reçoit la demande, accède aux services et transfère la demande Il ne mémorise pas la demande après le transfert Lorsque la demande arrive, il utilise l’entête Via afin de connaître la destination. Définition d’un proxy Stateful Il mémorise les informations après les avoir transféréés Un proxy doit être stateful lorsque : Il envoie la demande en multicast. Il utilise le protocole TCP. Copyright © 2011 - Global Knowledge France

. Redirect SIP 4428@gkn.fr sip.gkn.fr 4003@gkn.fr 4000@gkn.fr Le protocole SIP Redirect SIP SIP proxy server sip.gkn.fr INVITE 4428 ACK 4428 Bob 302 {4003} 4428@gkn.fr INVITE 4003 Charlotte . Alice Le serveur de redirection (Redirect Server) agit comme un intermédiaire entre le terminal client et le serveur de localisation. Il est sollicité par le terminal client pour contacter le serveur de localisation afin de déterminer la position courante d’un utilisateur. L’appelant envoie une requête de localisation d’un correspondant au serveur de redirection. Celui-ci-joint le serveur de localisation afin d’effectuer la requête de localisation du correspondant à joindre. Le serveur de localisation répond au serveur de redirection, lequel informe l’appelant en lui fournissant la localisation trouvée. Ainsi l’utilisateur n’a pas besoin de connaître l’adresse du serveur de localisation. 4003@gkn.fr 4000@gkn.fr Copyright © 2011 - Global Knowledge France

Exemple de Proxy Server SIP * Le protocole SIP Exemple de Proxy Server SIP * 4428@gkn.fr = 4428@71.5.5.2 SIP proxy server sip.gkn.fr Location server INVITE (+SDP) 4428@71.5.5.2 200 (+SDP) OK ACK 4428@71.5.5.2 ACK 4428@sip.gkn.fr DNS INVITE (+SDP) 4428@sip.gkn.fr 4428??? 71.5.5.2 Adresse(s) IP de sip.gkn.fr 180 Ringing 11 12 RTP Etablit durant les étapes 3&6, activé durant les étapes 11 & 12 Etablit durant les étapes 9&10, activé durant les étapes 11 & 12 Résolution DNS sip.gkn.fr Dans ce scénario un appelant identifié 4000 souhaite joindre un appelé par 4428@gkn.fr. 4000 ne sait pas exactement où "4428" est situé. C'est le travail du serveur SIP. Mais où se situe donc le serveur SIP pour gkn.fr.? Dans cet exemple, (1) représente la requête SIP pour le serveur DNS local (Domain Naming System) pour l'adresse IP de sip. gkn.fr. Si le DNS local ne peut pas la résoudre, alors il va déclencher une réaction en chaîne au travers d’une hiérarchie de serveurs DNS jusqu‘à ce que l'on lui retourne l'adresse IP de sip. 4428@gkn.fr Un INVITE est envoyé au serveur proxy. Le serveur proxy de gkn.fr. Le serveur proxy génère une invitation vers l'endroit précité. Lorsque cette invitation est acceptée, un accusé de réception est envoyé à 4000. Alice Bob 4428@gkn.fr 4000@gkn.fr Copyright © 2011 - Global Knowledge France

Triangle ou Trapèze ? SIP SS SS SS SIP SIP SIP SIP RTP RTP UA UA UA UA Le protocole SIP Triangle ou Trapèze ? SIP SS SS SS SIP SIP SIP SIP RTP RTP UA UA UA UA Triangle “Philosophie du modèle VoIP Trapèze Très évolutif mais manque de sécurité Copyright © 2011 - Global Knowledge France

Forking Proxy Proxy UA Bureau Invite Mobile UA Invite UA UA Domicile Le protocole SIP Forking Proxy Registrar UA Bureau Invite Proxy UA Mobile Invite UA UA Domicile Copyright © 2011 - Global Knowledge France

Requêtes SIP (Méthodes ) Le protocole SIP Requêtes SIP (Méthodes ) Remarque Importante : Les messages garderont leur code d’origine en anglais pour aider à la compréhension des traces Elle représente les requêtes SIP ACK [RFC3261] BYE [RFC3261] CANCEL [RFC3261] INFO [RFC2976] INVITE [RFC3261] MESSAGE [RFC3428] NOTIFY [RFC3265] OPTIONS [RFC3261] PRACK [RFC3262] PUBLISH [RFC3903] REFER [RFC3515] REGISTER [RFC3261] SUBSCRIBE [RFC3265] UPDATE [RFC3311] Copyright © 2011 - Global Knowledge France

Elle représente les réponses SIP Le protocole SIP SIP Response Codes Remarque Importante : Les messages garderont leur code d’origine en anglais pour aider à la compréhension des traces Elle représente les réponses SIP 1xx Provisional 2xx Successful 3xx Redirection 4xx Request Failure 5xx Server Failure 6xx Global Failures Codes de réponse : Les codes de réponse sont cohérents avec les codes de réponse HTTP/1.1, et les étendent. Tous les codes de réponse HTTP/1.1 ne sont pas appropriés, et seuls ceux qui le sont, sont donnés ici. D’autres codes de réponse HTTP/1.1 4xx et 5xx pour les erreurs de clients et les erreurs de serveur. SIP définit une autre nouvelle classe, 6xx. Copyright © 2011 - Global Knowledge France

Architecture Fonctionnelle SIP Le protocole SIP Architecture Fonctionnelle SIP TU (Transaction User) Transaction UAC UAS Transport Syntax/Encoding UDP TCP SCTP Application SIP Gestion des transactions Mécanismes de fiabilité et timers. Contient un composant UAC et UAS . Envoi et Réception de messages SIP Analyse les messages SIP Couche de Transport Niveau 4 Copyright © 2011 - Global Knowledge France

Les RFC SIP …… RFC 3261 SIP Spécification principale Le protocole SIP Les RFC SIP …… RFC 3261 SIP Spécification principale Extensions SIP (Quelques unes) RFC 3312 Integration of Resource Management and SIP Framework for preconditions RFC 3311 SIP UPDATE Method RFC 3262 PRACK and 100rel RFC 3263 Locating SIP Servers RFC 3264 The SDP Offer/Answer Model RFC 3265 Event Notification “Nous Décrirons plus tard le rôle de ces RFC dans le fonctionnement de SIP” Le document de base SIP est actuellement RFC 3261. Ce document RFC est une réécriture complète du document original SIP RFC 2543. L'industrie estime que la RFC 3261 constitue «le protocole SIP de base » et tous les autres RFC SIP sont appelés extensions SIP. Cela peut être déroutant pour les non-initiés car la plupart des extensions SIP sont essentielles pour rendre le travail de SIP efficace. Beaucoup de ces extensions doivent être considérées comme faisant partie du protocole SIP, et par conséquent devrait se trouver dans la RFC SIP. L’ industrie considère que cette approche est la plus évolutive possible car elle rend le protocole SIP très ouvert aux modifications. Par conséquent, la RFC 3261 constitue les bases du protocole SIP et tous les autres RFC SIP connexes sont des extensions SIP. Notez qu’aujourd’hui on comptabilise près de 300 RFC autour de SIP !!! Copyright © 2011 - Global Knowledge France

Exemple d’application Le protocole SIP Exemple d’application Copyright © 2011 - Global Knowledge France

Utilisation du SIP-Trunking en Débordement Le protocole SIP Utilisation du SIP-Trunking en Débordement SERVICES ATTENDUS DU SIP TRUNKING Mobilité Totale Haute disponibilité Intéressant dans les architectures PRA SIPconnect :Standard emergeant SS PSTN LAN Ethernet Phones ATA MG Border Controller ITSP SBC The Internet SIP Trunk Un Trunk SIP permet la connectivité au RTPC sans une passerelle média. Bien sûr, il y aura toujours une Media Gateway, mais il sera localisé au niveau du réseau opérateur , et non en entreprise. Comme encore beaucoup d’entreprises ne veulent pas prendre le risque de migrer sur un lien principal 100% SIP trunking, il n'y a aucune raison de ne pas installer un lien SIP en parallèle des trunks TDM actuels. Cette approche permet au personnel télécom d’expérimenter un SIP Trunking sans accepter le risque d’une conversion totale. Les normes SIPConnect font leur apparition pour aider à assurer l’intéropérabilité des implémentations SIP. Ceci comprend le transfert d'appel, transfert, «RE-INVITE », la manipulation de digit DTMF, etc… SS - Softswitch MG - Media Gateway ATA - Analog Terminal Adapter SBC – Session Border Controller Copyright © 2011 - Global Knowledge France

Utilisation du SIP Trunking en lien principal Le protocole SIP Utilisation du SIP Trunking en lien principal SS PSTN LAN Ethernet Phones ATA Border Controller ITSP MG SBC The Internet SIP Trunk Un exemple de Trunk SIP ... Outbound Proxy1: pa.sip.orange.com. Outbound Proxy2: ly.sip.orange.com Registrar: sip.orange.com Phone Number: 7175664428 Authentication ID: 7175664400 Password: “88orkzzorf” DTMF Method: Au Choix RFC-2833 Inband SIP INFO Simultaneous calls: 10 Si une connectivité IP existe avec un ITSP ( Internet Telephony Service Provider), un Trunk SIP peut être déployé en mettant en œuvre une configuration sur le serveur de signalisation ou IPBX ( Asterisk par exemple). Un Trunk SIP n'est pas quelque chose de visible. Un Trunk SIP est 100% virtuel au travers d’une session TCP . Voici un exemple de ce que vous devez configurer pour activer un réseau SIP. ITSP : Internet Telephony Service Provider Outbound Proxy: C’est l'adresse IP du SBC de l’ITSP , qui à son tour route les appels valides au SoftSwitch de l'ITSP Registrar: Information qui apparait à droite du signe « @ » dans une URI Sip . Par exemple, dans ce cas, l'enregistrement serait 7175664428@sip.orange.com Phone Number: Le numéro de téléphone enregistré. Authentication ID: Si plusieurs numéros de téléphone sont enregistrés, ils peuvent tous utiliser un ID d’ authentification commun, ce qui facilite grandement la configuration pour les ITSP. Copyright © 2011 - Global Knowledge France

Le protocole SIP URI SIP Copyright © 2011 - Global Knowledge France

RFC 2396 URI Universal Resource Identifier Le protocole SIP RFC 2396 URI Universal Resource Identifier Cette partie est l’URL http://www.gkn.fr/training/CAC/presentation.htm Composant du schéma Composant de l’autorité Composant du chemin http://www.gkn.fr /training/CAC/presentation.htm Les termes URI et URL sont utilisés de manière interchangeable, comme s’ils signifiaient la même chose ; mais en fait, il y a des différences . Un URI identifie à l'échelle atomique, comme c'est le cas ici lorsque l'URI pointe vers un fichier spécifique sur le web www.alta3.com. L'URL est un pointeur plus grossier, qui pointe vers le périphérique logique qui fournit le service. Dans ce cas, l'URL est www.gkn.fr et le serveur web gkn.fr ,mais cela ne renvoie pas vers une page web, en particulier. Copyright © 2011 - Global Knowledge France

Informations génériques RFC 2396 Le protocole SIP Informations génériques RFC 2396 pres:pkeros@pa.gkn.fr -- presence im:crystal@pa.gkn.fr -- schema messagerie instantanée http://www.gkn.fr /training/CAC/presentation.htm -- schema http pour services HTTP mailto:pkeros@gkn.fr -- mailto schema pour la messagerie electronique sip:pkeros@sip.gkn.fr -- schema RFC 3261 pour SIP tel:+33-6-127-21234;postd=pp34 -- dial 33-6-127-21234, ext 34 Voici quelques-unes des adresses URI les plus courantes qui sont référencées dans la voix sur IP de configuration Copyright © 2011 - Global Knowledge France

Structure SIP URI RFC 3261 section: 19.1.1. URI SIP et SIPS Le protocole SIP Structure SIP URI RFC 3261 section: 19.1.1. URI SIP et SIPS mauvaise idée Utilisateur SIP (peut être absent si pas de notion d’utilisateur) Adresse IP ou nom de domaine Header SIP sip:user:password@host:port;uri-parameters?headers maddr = multicast address lr = loose routing ttl = time to live user = user’s ID phone = user’s ID method = method other = anything else Un URI SIP peut pointer vers une personne en particulier : quand l’atteindre, comment l’atteindre, l'itinéraire à prendre pour l’atteindre, et ainsi de suite. Des en-têtes SIP peuvent être ajoutés à un URI SIP. Port TCP ou UDP Copyright © 2011 - Global Knowledge France

Structure SIP URI sip:user:password@host:port;uri-parameters?headers Le protocole SIP Structure SIP URI sip:user:password@host:port;uri-parameters?headers maddr = multicast address lr = signifie “loose routing” comme spécifié dans la RFC 3261, pas la 2543 ttl = Temps de vie user = user’s ID comme “Julien” phone = user’s “phone” ID. Voici un exemple: tel:+33-612-72-1234;postd=pp34 deviendra sip:+33-612-72-1234;postd=pp34@gkn.fr;user=phone method = Méthode SIP appliquée sur cette URI other = n’importe quoi d’autre Un URI SIP ou SIPS identifie une ressource de communication. Comme tous les URI, les URI SIP et SIPS peuvent être placés dans des pages web, des messages électroniques ou de la littérature imprimée. Ils contiennent des informations suffisantes pour initialiser et maintenir une session de communication avec les ressources. Un URI SIPS spécifie que les ressources sont contactées en confiance. Cela signifie, en particulier, que TLS doit être utilisé entre l’UAC et le domaine qui possède l’URI. A partir de là, les communications sécurisées sont utilisées pour joindre l’utilisateur, et le mécanisme spécifique de sécurité dépend de la politique du domaine. Toute ressource décrite par un URI SIP peut être "mis à niveau" en URI SIPS en changeant simplement le schéma, si on désire communiquer en toute sécurité avec cette ressource. Copyright © 2011 - Global Knowledge France

Exemples : URI SIP sip:crystal@gkn.fr;maddr=239.255.255.1;ttl=3 Le protocole SIP Exemples : URI SIP sip:crystal@gkn.fr;maddr=239.255.255.1;ttl=3 sip:crystal@gkn.fr sip:crystal@gateway.gkn.fr;transport=tcp sips:crystal@gkn.fr?subject=le%20chat%20aime%20dormir sip:crystal@192.168.10.20;expires=3600 sip:Paris.com;method=REGISTER?to=crystal%40gkn.fr sip:crystal;day=Vendredi@Lyon.com Copyright © 2011 - Global Knowledge France

Où sont utilisées les URI SIP ? Le protocole SIP Où sont utilisées les URI SIP ? INVITE sip:appele@u2.domaine.com SIP/2.0 From: “appelant” <sip:appelant@u1.domain.com>;tag=1D3EF3C-19F1 To: <sip:appele@u2.domaine.com> Contact: sip:appelant@u1.exemple.com Record-Route: <sip:p2.domaine.com;lr> Record-Route: <sip:p1.exemple.com;lr> Guillemets : Indique où l’URI débute et termine Utilisés quand les champs Contact:, From:, et To: contiennent une URI Doivent être utilisés si l’URI contient “,”ou “?” Copyright © 2011 - Global Knowledge France

Schéma SIP URI Deux schémas URI : Deux types de SIP URI : Le protocole SIP Schéma SIP URI Deux schémas URI : sip:pkeros@gkn.fr RFC 2543 sips:pkeros@secret.gkn.fr Le mode sécurisé SIP est introduit par la RFC 3261 Exige l’utilisation de TLS sur TCP Même syntaxe que SIP, en ajoutant simplement un “s” Deux types de SIP URI : Address of Record (AOR) Nécessite le DNS Fully Qualified Domain Name (FQDN) Utilisé dans le champ Contact sip:pkeros@192.168.10.12 sip:pkerosr@pa.gkn.fr RFC 3261 a spécifié un nouvel URI, appelé SIP sécurisé, d'où l'URI "SIPS". Un URI SIP se divise en deux types distincts, le premier est l'adresse d'enregistrement qui est habituellement une adresse e-mail ou un numéro de téléphone. Le nom réel du serveur SIP est inconnue jusqu'à ce qu'un DNS est effectué la résolution afin de déterminer l'adresse du serveur SIP effectivement. Si l'adresse du serveur SIP est connue, soit que l'adresse IP réelle ou le nom d'hôte, il est référé aux aa nom de domaine pleinement qualifié. Copyright © 2011 - Global Knowledge France

RFC 2806 : URL pour Appels Téléphoniques Le protocole SIP RFC 2806 : URL pour Appels Téléphoniques tel:+33-492-910-710 fax:+ 33-492-910-711 modem:+3585551234567;type=v32b?8e1 modem V.32bis 8 bits, parité paire, 1 bit de stop tel:+ 33-492-910-710;postd=pp10 33-492-910-710 ext 10 tel:9w17175664428;phone-context=+1717 appel 9, attente de la tonalité appel 1-717-566-4428 Uniquement si vous êtes aux Etats-Unis dans la zone 717 Copyright © 2011 - Global Knowledge France

Module 3 Les messages SIP Le protocole SIP Module 3 Les messages SIP Copyright © 2011 - Global Knowledge France

En-têtes SIP Via Max_Forwards Dialog (To:, From:, Tag) CSeq Call-ID Le protocole SIP En-têtes SIP Via Max_Forwards Dialog (To:, From:, Tag) CSeq Call-ID Contact Authentification Et les autres… Copyright © 2011 - Global Knowledge France

La séquence d’appel SIP Le protocole SIP La séquence d’appel SIP Poste A Poste B Message INVITE + SDP du poste A 180 Ringing 200 OK + SDP poste B ACK Flux RTP BYE 200 : OK ACK Copyright © 2011 - Global Knowledge France

Compléments sur certaines requêtes SIP Le protocole SIP Compléments sur certaines requêtes SIP INVITE: Le message “INVITE” démarre une session. ACK: Le message “ACK” confirme que le destinataire a bien reçu le message “INVITE”. BYE: Le “User Agent” a utilisé le message “BYE” pour indiquer au serveur qu’il souhaite raccrocher l’appel. CANCEL: Le message “CANCEL” demande une suspension de l’appel mais cela ne signifie pas qu’il souhaite raccrocher. OPTIONS: Les méthodes de “OPTIONS” sollicitent des fonctionnalités mais cette demande ne provoque pas une autre connexion. REGISTER: Le message “REGISTER” permet un à “User Agent” de s’enregistrer sur un serveur SIP. Copyright © 2011 - Global Knowledge France

Compléments sur certaines réponses SIP Le protocole SIP Compléments sur certaines réponses SIP Note: Les codes1xx sont des réponses provisoires. Les codes 2xx - 6xx sont des réponses finales. Copyright © 2011 - Global Knowledge France

Compléments sur les entités SIP Le protocole SIP Compléments sur les entités SIP Serveur Proxy Il assure que la demande a bien été envoyée vers la plus proche entité Handles registrations, Implements call-routing policies Gère l’authentification et l’autorisation des accès Serveur Redirect Il accepte les demandes SIP, Il oriente les demandes pour la destination finale en leur indiquant leur location (par adresse IP ou par nom) Serveur Registrar Les User Agents SIP s’enregistrent avec leur réseau initial en envoyant le message REGISTER. Il est typiquement situé en co-location avec le serveur proxy ou redirect Location Server Il est utilisé par le protocol SIP des serveurs Redirect ou Proxy afin d’obtenir des information concernant la localisation possible de l’appelé. Serveur Proxy : Entité intermédiaire qui agit à la fois comme un serveur et comme un client pour les besoins de l’élaboration de demandes au nom des autres clients. Un serveur Proxy joue principalement un rôle d’acheminement, ce qui signifie que sa tâche est de s’assurer qu’une demande est envoyée à une autre entité "plus proche" de l’utilisateur cible. Les Proxys sont aussi utiles pour mettre en application la politique (par exemple, s’assurer qu’un utilisateur est autorisé à effectuer un appel). Un Proxy interprète, et, si nécessaire, réécrit des parties spécifiques d’un message de demande avant de le retransmettre. Serveur de redirection : c’est un serveur d’agent d’utilisateur (UAS) qui génère des réponses 3xx aux demandes qu’il reçoit, amenant le client à contacter un ensemble d’URI de remplacement. Registrar : c’est un serveur qui accepte les demandes REGISTER et qui place les informations qu’il reçoit dans ces demandes dans le service de localisation pour le domaine qu’il gère. Service de localisation : un service de localisation est utilisé par un redirect SIP ou serveur Proxy pour obtenir des informations sur la ou les localisations possibles d’un appelé. Il contient une liste de liens de clés d’address-of- record pour zéro ou plusieurs adresses de contact. Les liens peuvent être créés et retirés de nombreuses façons ; la présente spécification définit une méthode REGISTER qui met à jour les liens. Copyright © 2011 - Global Knowledge France

Syntaxe message SIP : Requête Le protocole SIP Syntaxe message SIP : Requête SIP Message Syntax: Request INVITE sip:*98@192.168.1.23 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.22:5060;branch=z9hG4bK-e3e20b97 From: Jack <sip:4001@192.168.1.23>;tag=cc585e8b73088fe6o0 To: <sip:*98@192.168.1.23> Call-ID: b1f9b2f-fc77db92@192.168.1.22 CSeq: 102 INVITE Max-Forwards: 70 Proxy-Authorization: Digest username="4001", realm="asterisk", nonce="4b920751", uri="sip:*98@192.168.1.23", algorithm=MD5, response="a357d3f453215798c4bdc8393fc6287d" Contact: Jack <sip:4001@192.168.1.22:5060> Expires: 240 User-Agent: Sipura/SPA2000-2.0.13(g) Content-Length: 422 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER Supported: 100rel, x-sipura Content-Type: application/sdp v= 0 o= 303734 303734 IN IP4 192.168.1.22 s= - c= IN IP4 192.168.1.22 t= 0 0 m= audio 16404 RTP/AVP 4 0 2 8 18 100 101 a= rtpmap:4 G723/8000 a= rtpmap:0 PCMU/8000 a= rtpmap:2 G726-32/8000 a= rtpmap:8 PCMA/8000 a= rtpmap:18 G729a/8000 a= rtpmap:100 NSE/8000 a= rtpmap:101 telephone-event/8000 a= fmtp:101 0-15 a= ptime:20 a= sendrecv Start Line INVITE sip:*98@192.168.1.23 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.22:5060;branch=z9hG4bK-e3e20b97 From: Jack <sip:4001@192.168.1.23>;tag=cc585e8b73088fe6o0 To: <sip:*98@192.168.1.23> Call-ID: b1f9b2f-fc77db92@192.168.1.22 CSeq: 102 INVITE Max-Forwards: 70 Proxy-Authorization: Digest username="4001", realm="asterisk", nonce="4b920751", uri="sip:*98@192.168.1.23", algorithm=MD5, response="a357d3f453215798c4bdc8393fc6287d" Contact: Jack <sip:4001@192.168.1.22:5060> Expires: 240 User-Agent: Sipura/SPA2000-2.0.13(g) Content-Length: 422 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER Supported: 100rel, x-sipura Content-Type: application/sdp v= 0 o= 303734 303734 IN IP4 192.168.1.22 s= - c= IN IP4 192.168.1.22 t= 0 0 m= audio 16404 RTP/AVP 4 0 2 8 18 100 101 a= rtpmap:4 G723/8000 a= rtpmap:0 PCMU/8000 a= rtpmap:2 G726-32/8000 a= rtpmap:8 PCMA/8000 a= rtpmap:18 G729a/8000 a= rtpmap:100 NSE/8000 a= rtpmap:101 telephone-event/8000 a= fmtp:101 0-15 a= ptime:20 a= sendrecv Ligne de début En-tête du message Corps du message Message Headers Message Body Copyright © 2011 - Global Knowledge France

Syntaxe message SIP : Response Le protocole SIP Syntaxe message SIP : Response SIP Message Syntax: Response Start Line SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.22:5060;branch=z9hG4bK-e3e20b97;received=192.168.1.22 From: Jack <sip:4001@192.168.1.23>;tag=cc585e8b73088fe6o0 To: <sip:*98@192.168.1.23>;tag=as13e70482 Call-ID: b1f9b2f-fc77db92@192.168.1.22 CSeq: 102 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Max-Forwards: 70 Contact: <sip:*98@192.168.1.23> Content-Type: application/sdp Content-Length: 238 v= 0 o= root 2564 2564 IN IP4 192.168.1.23 s= session c= IN IP4 192.168.1.23 t= 0 0 m= audio 15246 RTP/AVP 0 8 101 a= rtpmap:0 PCMU/8000 a= rtpmap:8 PCMA/8000 a= rtpmap:101 telephone-event/8000 a= fmtp:101 0-16 a= silenceSupp:off - - - - Ligne de début SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.22:5060;branch=z9hG4bK-e3e20b97;received=192.168.1.22 From: Jack <sip:4001@192.168.1.23>;tag=cc585e8b73088fe6o0 To: <sip:*98@192.168.1.23>;tag=as13e70482 Call-ID: b1f9b2f-fc77db92@192.168.1.22 CSeq: 102 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Max-Forwards: 70 Contact: <sip:*98@192.168.1.23> Content-Type: application/sdp Content-Length: 238 v= 0 o= root 2564 2564 IN IP4 192.168.1.23 s= session c= IN IP4 192.168.1.23 t= 0 0 m= audio 15246 RTP/AVP 0 8 101 a= rtpmap:0 PCMU/8000 a= rtpmap:8 PCMA/8000 a= rtpmap:101 telephone-event/8000 a= fmtp:101 0-16 a= silenceSupp:off - - - - En-tête du message Message headers Corps du message Message body Copyright © 2011 - Global Knowledge France

SIP INVITE INVITE sip:jill@hill.edu SIP/2.0 Le protocole SIP SIP INVITE INVITE sip:jill@hill.edu SIP/2.0 Via: SIP/2.0/UDP hill.edu:5060;branch=z9hG4bK0086 Max-Forwards: 7 To: Jill <sip:jhill@hill.edu> From: Jack <sip:Jack@spratt.com>;tag=111234 Call-ID: 545317007@99.1.2.3 CSeq: 1 INVITE Contact: sip:jill@hill.edu Content-Type: application/sdp Content-Length: 159 v=0 o=splatt 289084526 28904529 IN IP4 uphill.spratt.com c=IN IP4 99.1.2.3 m=audio 16384 RTP/AVP 4 a=rtpmap:4 G723/8000 Le début du message SIP commence par le mot INVITE : type de demande: INVITE Qui fait la demande: sip:jill@hill.edu AOR ou contact (FQDN) est OK. La demande URI est un AOR. Il peut être converti par la suite en FQDN par le serveur PROXY. Version SIP = SIP/2.0 La requête INVITE permet à un poste client d’inviter un correspondant à participer à une conférence à deux ou plusieurs. La requête INVITE contient dans le corps du message, une description de la session proposée à l’intention du correspondant. Elle peut être écrite en format SDP, et contient le type de média, audio, vidéo ou data, les formats et les codages qui seront en vigueur dans la conférence, et que l’appelant est capable de recevoir sur son poste client. Le poste de destination envoie à son tour un message décrivant le type de média et les formats associés qu’il souhaite recevoir. Si le correspondant accepte l’ invitation, le message ACK lui est transmis pour confirmation de son message et pour finaliser la « poignée de main » (Handshake ). Copyright © 2011 - Global Knowledge France

Via Field INVITE sip:jill@hill.edu SIP/2.0 Le protocole SIP Via Field INVITE sip:jill@hill.edu SIP/2.0 Via: SIP/2.0/UDP hill.edu:5060;branch=z9hG4bK0086 Max-Forwards: 7 To: Jill <sip:jhill@hill.edu> From: Jack <sip:Jack@spratt.com>;tag=111234 Call-ID: 545317007@99.1.2.3 CSeq: 1 INVITE Contact: sip:jill@hill.edu Content-Type: application/sdp Content-Length: 159 v=0 o=splatt 289084526 28904529 IN IP4 uphill.spratt.com c=IN IP4 99.1.2.3 m=audio 16384 RTP/AVP 4 a=rtpmap:4 G723/8000 L’entête Via montre que la demande a été prise en compte. L’entête Via est inséré par le User Agent qui a généré la demande.. Les entêtes Via supplémentaires sont insérés par chaque serveur proxy. Les entêtes Via sont utilisés pour router les réponses vers le même chemin. Le paramètre branch contient un cookie (z9hG4bK), puis une transaction ID Le champ Via : Indique la route empruntée par la requête jusqu’à ce nœud. Permet de prévenir les boucles et garantit que la réponse prendra la même route que la requête. Le client appelant est le premier à insérer un champ VIA contenant son adresse. Par la suite, tous les proxies qui relaieront la requête devront ajouter leur champ VIA en tête de la liste Une valeur de champ d’en-tête Via contient le protocole de transport utilisé pour envoyer le message, le nom d’hôte du client ou l’adresse réseau, et si possible le numéro de port auquel il souhaite recevoir les réponses. Les protocoles de transport définis ici sont UDP, TCP, TLS . Copyright © 2011 - Global Knowledge France

Via: Fonctionnement Le champ via est ajouté au sein de la requête SIP Le protocole SIP Via: Fonctionnement INVITE Jill Via: C Via: B Via: Jack INVITE Jill Via: B Via: Jack INVITE Jill Via: Jack UA A Proxy B Proxy C UA D UAC UAS UAC SIP UAC UAS UAC UAS SIP UAS UAC UAS 180 Via: Jack 180 Via: B Via: Jack 180 Via: C Via: B Via: Jack Le champ via est ajouté au sein de la requête SIP Le champ Via est ensuite soustrait dans la réponse Ceci permet aux réponses de suivrent exactement le chemin inverse SIP. Champ Via Chaque proxy ajoute son adresse dans la requête. Chaque proxy soustrait son adresse dans la réponse. L'en-tête permet via une requête SIP de se rappeler le chemin exact qu'il a pris afin qu'une réponse puisse revenir par le même chemin d’où provient la demande. Chaque proxy ajoute le champ VIA à toute demande qu'il transmet. Un nouveau champ est inséré par l'intermédiaire de sorte qu'il apparaisse en premier dans la liste par l'intermédiaire. Lorsque la demande SIP arrive à la destination, la liste des champs VIA représente l'itinéraire que la réponse suivra. Copyright © 2011 - Global Knowledge France

Via: Limitation du champ Via Le protocole SIP Via: Limitation du champ Via Je n’ai aucune idée du chemin que mon INVITE va prendre INVITE Jill Via: C Via: B Via: Jack INVITE Jill Via: B Via: Jack INVITE Jill Via: Jack Jack Proxy B Proxy C Jill UAC UAS UAC UAS UAC UAS SIP SIP UAS UAC UAS UAC UAS UAC 180 Via: Jack 180 Via: B Via: Jack 180 Via: C Via: B Via: Jack Ne pas confondre le champ Via avec le champ Record-Route: Via: N’a pas un rôle d’apprentissage de routes Jack ne peut rien apprendre depuis le champ Via: Copyright © 2011 - Global Knowledge France

Strict Routing – RFC 2543 Loose Routing – RFC 3261 Le protocole SIP Strict Routing – RFC 2543 Loose Routing – RFC 3261 P1 .spratt .com jack jill u1.spratt.com u8.hill.edu P2 P3 .middle P4 .domain Invite sip:jack@u1.spratt.com SIP/2.0 Route: <sip:p2.spratt.com;lr> Route: <sip:p3.middle.com;lr> Route: <sip:p4.hill.edu;lr> To:jack@u1.spratt.com Invite sip:jack@p2.spratt.com SIP/2.0 Route: <sip:p3.middle.com> Route: <sip:p4.hill.edu> Loose Strict Change à chaque proxy Ne change jamais INVITE Routage strict : Un Proxy est dit à routage strict s’il suit les règles de traitement de Route de la RFC 2543. Routage lâche : Un proxy est dit être à routage loose s’il suit les procédures définies dans la RFC 3261 pour le traitement du champ d'en-tête Route. Copyright © 2011 - Global Knowledge France

Max-Forwards INVITE sip:jill@hill.edu SIP/2.0 Le protocole SIP Max-Forwards INVITE sip:jill@hill.edu SIP/2.0 Via: SIP/2.0/UDP hill.edu:5060;branch=z9hG4bK0086 Max-Forwards: 7 To: Jill <sip:jhill@hill.edu> From: Jack <sip:Jack@spratt.com>;tag=111234 Call-ID: 545317007@99.1.2.3 CSeq: 1 INVITE Contact: sip:jack@spratt.com Content-Type: application/sdp Content-Length: 159 v=0 o=splatt 289084526 28904529 IN IP4 uphill.spratt.com c=IN IP4 99.1.2.3 m=audio 16384 RTP/AVP 4 a=rtpmap:4 G723/8000 Le Max-Forwards est un compteur qui se décrémente à chaque passage dans un proxy qui transfère la demande. Lorsque le compteur est à zéro, la demande est alors rejetée. Si Max-Forwards est égal à 483, alors un message TooManyHops (trop de sauts) est envoyé. Cet en-tête obligatoire est utilisé pour prévenir les cas de bouclage lorsque l’appel est routé par des proxys dans le réseau. Chaque proxy décrémente le compteur d’une unité lors de la retransmission de la requête, et répond par un message d’erreur si le compteur atteint la valeur 0. Copyright © 2011 - Global Knowledge France

SIP Dialog (Formerly Call Leg) Le protocole SIP SIP Dialog (Formerly Call Leg) INVITE sip:jill@hill.edu SIP/2.0 Via: SIP/2.0/UDP hill.edu:5060;branch=z9hG4bK0086 Max-Forwards: 7 To: Jill <sip:jhill@hill.edu> From: Jack <sip:Jack@spratt.com>;tag=111234 Call-ID: 545317007@99.1.2.3 CSeq: 1 INVITE Contact: sip:jack@spratt.com Content-Type: application/sdp Content-Length: 159 v=0 o=splatt 289084526 28904529 IN IP4 uphill.spratt.com c=IN IP4 99.1.2.3 m=audio 16384 RTP/AVP 4 a=rtpmap:4 G723/8000 Dialog (formerly called call leg) Une étiquette (tag) est assignée par l’appelé. Dans cet exemple, Jack appelle et Jill répondra avec la même étiquette (tag). To et From URI contiennent généralement des AOR URIs. Toutes les demandes et réponses avec cet appel utiliseront les mêmes informations de dialogue. Call-ID est une identification unique qui est généralement composée d’une chaîne de caractères plus @ suivi du nom de l’hôte ou de l’adresse IP. Le champ « TO » : la valeur de ce champ est disponible de bout en bout pour les implémentations de terminaux, mais en général il identifie l’utilisateur ou la ressource cible de la requête SIP. Remarque : l’entête « TO » a un rôle formel dans la requête REGISTER car elle permet d’enregistrer l’ URI SIP contenue dans ce champ. Cette entrée constitue l’ AOR ( Address Of Record ). Le Champ « FROM »: l’entête FROM identifie l’émetteur de la requête pour les implémentations de SIP conforme à la RFC 3261. Ce champ doit être présent dans toutes les requêtes et est simplement recopié dans les réponses. Le Champ Call-ID : il constitue un numéro d’identification d’une invitation ou d’un appel. Un appel est constitué de l’ensemble des participants à une conférence, invités par une même source. Un appel SIP est identifié par un Call-ID unique. Si un usager est invité par plusieurs participants à une même session multipoint, chacune de ces invitations constituera un appel. Le Call-ID n’est utilisé que par SIP. Copyright © 2011 - Global Knowledge France

Command Sequence INVITE sip:jill@hill.edu SIP/2.0 Le protocole SIP Command Sequence INVITE sip:jill@hill.edu SIP/2.0 Via: SIP/2.0/UDP hill.edu:5060;branch=z9hG4bK0086 Max-Forwards: 7 To: Jill <sip:jhill@hill.edu> From: Jack <sip:Jack@spratt.com>;tag=111234 Call-ID: 545317007@99.1.2.3 CSeq: 1 INVITE Contact: sip:jack@spratt.com Content-Type: application/sdp Content-Length: 159 v=0 o=splatt 289084526 28904529 IN IP4 uphill.spratt.com c=IN IP4 99.1.2.3 m=audio 16384 RTP/AVP 4 a=rtpmap:4 G723/8000 CSeq command sequence number Initialisé au démarrage de l’appel (1, dans cet exemple) Incrémenté à chaque requête successive Utilisé pour distinguer une retransmission d’une nouvelle requête Contient aussi le type de requête (method): INVITE Le Champ Cseq : il signifie « Command Sequence » et correspond à un numéro d’ordre de sortie des messages. Plusieurs messages peuvent avoir le même Call-ID, mais le numéro de séquence s’incrémentera d’une unité pour chaque nouveau message. Les messages de réponse aux requêtes utiliseront « Cseq » comme référence au message d’origine. Copyright © 2011 - Global Knowledge France

Contact INVITE sip:jill@hill.edu SIP/2.0 Le protocole SIP Contact INVITE sip:jill@hill.edu SIP/2.0 Via: SIP/2.0/UDP hill.edu:5060;branch=z9hG4bK0086 Max-Forwards: 7 To: Jill <sip:jhill@hill.edu> From: Jack <sip:Jack@spratt.com>;tag=111234 Call-ID: 545317007@99.1.2.3 CSeq: 1 INVITE Contact: sip:jack@spratt.com Content-Type: application/sdp Content-Length: 159 v=0 o=splatt 289084526 28904529 IN IP4 uphill.spratt.com c=IN IP4 99.1.2.3 m=audio 16384 RTP/AVP 4 a=rtpmap:4 G723/8000 L’entête Contact contient le SIP FQDN URI pour une communication directe entre user agents. L’entête Contact est aussi présent dans le message de réponse 200-OK. Contact : en SIP l’usage de l’entête Contact peut être complexe . En effet dans le cadre d’une Méthode REGISTER , il contient le ou les URI sur lesquelles on peut joindre les AOR. Par contre lorsqu’il est présent dans les requêtes ou les réponses établissant un dialogue, il indique une URI où le client (ou serveur) accepte de recevoir les requêtes suivantes du dialogue, permettant ainsi de court-circuiter d’éventuels proxys intermédiaires Copyright © 2011 - Global Knowledge France

Proxy-Authorization: Le protocole SIP Proxy-Authorization: INVITE sip:*98@192.168.1.23 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.22:5060;branch=z9hG4bK-e3e20b97 From: Jack <sip:4001@192.168.1.23>;tag=cc585e8b73088fe6o0 To: <sip:*98@192.168.1.23> Call-ID: b1f9b2f-fc77db92@192.168.1.22 CSeq: 102 INVITE Max-Forwards: 70 Proxy-Authorization: Digest username="4001", realm="asterisk", nonce="4b920751", uri="sip:*98@192.168.1.23", algorithm=MD5, response="a357d3f453215798c4bdc8393fc6287d" Contact: Jack <sip:4001@192.168.1.22:5060> Expires: 240 User-Agent: Sipura/SPA2000-2.0.13(g) Content-Length: 422 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER Supported: 100rel, x-sipura Content-Type: application/sdp v= 0 o= 303734 303734 IN IP4 192.168.1.22 s= - c= IN IP4 192.168.1.22 t= 0 0 m= audio 16404 RTP/AVP 4 0 2 8 18 100 101 a= rtpmap:4 G723/8000 a= rtpmap:0 PCMU/8000 a= rtpmap:2 G726-32/8000 a= rtpmap:8 PCMA/8000 a= rtpmap:18 G729a/8000 a= rtpmap:100 NSE/8000 a= rtpmap:101 telephone-event/8000 a= fmtp:101 0-15 a= ptime:20 a= sendrecv Authorization: Digest username= “4001" realm=“asterisk", nonce=" 4b920751 ", uri=" sip:*98@192.168.1.23, response=" a357d3f453215798c4bdc8393fc6287d” integrity-protected=“MD5“ Contient les informations requises pour l’authentification. Cette exemple est un message INVITE, avec un NONCE et une réponse calculée servant à s’authentifier ( rsuite à la réception d’un 401 Unauthorized ). Proxy-Authorization Le champ d’en-tête Proxy-Authorization permet au client de s’identifier (ou d’identifier son utilisateur) à un Proxy qui exige l’authentification. Une valeur de champ Proxy-Authorization consiste en accréditations qui contiennent les informations d’authentification de l’agent utilisateur pour le Proxy et/ou le domaine des ressources demandées. Copyright © 2011 - Global Knowledge France

Le protocole SIP Expires: INVITE sip:*98@192.168.1.23 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.22:5060;branch=z9hG4bK-e3e20b97 From: Jack <sip:4001@192.168.1.23>;tag=cc585e8b73088fe6o0 To: <sip:*98@192.168.1.23> Call-ID: b1f9b2f-fc77db92@192.168.1.22 CSeq: 102 INVITE Max-Forwards: 70 Proxy-Authorization: Digest username="4001", realm="asterisk", nonce="4b920751", uri="sip:*98@192.168.1.23", algorithm=MD5, response="a357d3f453215798c4bdc8393fc6287d" Contact: Jack <sip:4001@192.168.1.22:5060> Expires: 240 User-Agent: Sipura/SPA2000-2.0.13(g) Content-Length: 422 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER Supported: 100rel, x-sipura Content-Type: application/sdp v= 0 o= 303734 303734 IN IP4 192.168.1.22 s= - c= IN IP4 192.168.1.22 t= 0 0 m= audio 16404 RTP/AVP 4 0 2 8 18 100 101 a= rtpmap:4 G723/8000 a= rtpmap:0 PCMU/8000 a= rtpmap:2 G726-32/8000 a= rtpmap:8 PCMA/8000 a= rtpmap:18 G729a/8000 a= rtpmap:100 NSE/8000 a= rtpmap:101 telephone-event/8000 a= fmtp:101 0-15 a= ptime:20 a= sendrecv Expires: 240 Le champ d’en-tête Expires donne l’heure relative après laquelle le message (ou le contenu) expire. L’heure d’expiration dans un INVITE n’affecte pas la durée de la session réelle qui peut résulter de l’invitation. Expires : le champ d’en-tête Expires donne l’heure relative après laquelle le message (ou le contenu) expire. La signification précise dépend de la méthode. L’heure d’expiration dans un INVITE n’affecte pas la durée de la session réelle qui peut résulter de l’invitation. Les protocoles de description de session peuvent cependant offrir la capacité d’exprimer des limites à la durée de session. Copyright © 2011 - Global Knowledge France

User-Agent: User-Agent: Sipura/SPA2000-2.0.13(g) Le protocole SIP User-Agent: INVITE sip:*98@192.168.1.23 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.22:5060;branch=z9hG4bK-e3e20b97 From: Jack <sip:4001@192.168.1.23>;tag=cc585e8b73088fe6o0 To: <sip:*98@192.168.1.23> Call-ID: b1f9b2f-fc77db92@192.168.1.22 CSeq: 102 INVITE Max-Forwards: 70 Proxy-Authorization: Digest username="4001", realm="asterisk", nonce="4b920751", uri="sip:*98@192.168.1.23", algorithm=MD5, response="a357d3f453215798c4bdc8393fc6287d" Contact: Jack <sip:4001@192.168.1.22:5060> Expires: 240 User-Agent: Sipura/SPA2000-2.0.13(g) Content-Length: 422 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER Supported: 100rel, x-sipura Content-Type: application/sdp v= 0 o= 303734 303734 IN IP4 192.168.1.22 s= - c= IN IP4 192.168.1.22 t= 0 0 m= audio 16404 RTP/AVP 4 0 2 8 18 100 101 a= rtpmap:4 G723/8000 a= rtpmap:0 PCMU/8000 a= rtpmap:2 G726-32/8000 a= rtpmap:8 PCMA/8000 a= rtpmap:18 G729a/8000 a= rtpmap:100 NSE/8000 a= rtpmap:101 telephone-event/8000 a= fmtp:101 0-15 a= ptime:20 a= sendrecv User-Agent: Sipura/SPA2000-2.0.13(g) Indique le Hardware du UA ainsi que la version logicielle. User-Agent : le champ d'en-tête User-Agent contient des informations sur l'UAC à l’origine de la demande. Révéler la version du logiciel spécifique de l'agent utilisateur peut permettre à l'agent utilisateur de devenir plus vulnérable aux attaques contre les logiciels qui sont connus pour contenir des failles de sécurité. Les développeurs devraient rendre le champ d'en-tête User-Agent configurable. Copyright © 2011 - Global Knowledge France

Content-Length: Content-Length: 422 Le protocole SIP Content-Length: INVITE sip:*98@192.168.1.23 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.22:5060;branch=z9hG4bK-e3e20b97 From: Jack <sip:4001@192.168.1.23>;tag=cc585e8b73088fe6o0 To: <sip:*98@192.168.1.23> Call-ID: b1f9b2f-fc77db92@192.168.1.22 CSeq: 102 INVITE Max-Forwards: 70 Proxy-Authorization: Digest username="4001", realm="asterisk", nonce="4b920751", uri="sip:*98@192.168.1.23", algorithm=MD5, response="a357d3f453215798c4bdc8393fc6287d" Contact: Jack <sip:4001@192.168.1.22:5060> Expires: 240 User-Agent: Sipura/SPA2000-2.0.13(g) Content-Length: 422 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER Supported: 100rel, x-sipura Content-Type: application/sdp v= 0 o= 303734 303734 IN IP4 192.168.1.22 s= - c= IN IP4 192.168.1.22 t= 0 0 m= audio 16404 RTP/AVP 4 0 2 8 18 100 101 a= rtpmap:4 G723/8000 a= rtpmap:0 PCMU/8000 a= rtpmap:2 G726-32/8000 a= rtpmap:8 PCMA/8000 a= rtpmap:18 G729a/8000 a= rtpmap:100 NSE/8000 a= rtpmap:101 telephone-event/8000 a= fmtp:101 0-15 a= ptime:20 a= sendrecv Content-Length: 422 Indique la longueur du corps du message Content-Length : indique la taille de corps de message, en nombre décimal d'octets, envoyé au destinataire. Les applications doivent utiliser ce champ pour indiquer la taille du corps de message, quel que soit le type de support de l'entité. Si TCP est utilisé comme transport, le champ d'en-tête DOIT être utilisé. Si aucun contenu est présent dans un message, alors la valeur de l'en-tête Content-Length champ sera mis à zéro. Copyright © 2011 - Global Knowledge France

Allow: Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, Le protocole SIP Allow: INVITE sip:*98@192.168.1.23 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.22:5060;branch=z9hG4bK-e3e20b97 From: Jack <sip:4001@192.168.1.23>;tag=cc585e8b73088fe6o0 To: <sip:*98@192.168.1.23> Call-ID: b1f9b2f-fc77db92@192.168.1.22 CSeq: 102 INVITE Max-Forwards: 70 Proxy-Authorization: Digest username="4001", realm="asterisk", nonce="4b920751", uri="sip:*98@192.168.1.23", algorithm=MD5, response="a357d3f453215798c4bdc8393fc6287d" Contact: Jack <sip:4001@192.168.1.22:5060> Expires: 240 User-Agent: Sipura/SPA2000-2.0.13(g) Content-Length: 422 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER Supported: 100rel, x-sipura Content-Type: application/sdp v= 0 o= 303734 303734 IN IP4 192.168.1.22 s= - c= IN IP4 192.168.1.22 t= 0 0 m= audio 16404 RTP/AVP 4 0 2 8 18 100 101 a= rtpmap:4 G723/8000 a= rtpmap:0 PCMU/8000 a= rtpmap:2 G726-32/8000 a= rtpmap:8 PCMA/8000 a= rtpmap:18 G729a/8000 a= rtpmap:100 NSE/8000 a= rtpmap:101 telephone-event/8000 a= fmtp:101 0-15 a= ptime:20 a= sendrecv Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER Cette entête liste les méthodes supportées par le UA ayant généré le message L’absence de Allow: ne signifie pas que rien est accepté. Toutes les méthodes, y compris ACK et CANCEL, compris par l'UA DOIVENT être incluses dans la liste des méthodes dans le domaine de tête Allow, lorsqu'il est présent. Copyright © 2011 - Global Knowledge France

Supported: Supported: 100rel, x-sipura Le protocole SIP Supported: INVITE sip:*98@192.168.1.23 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.22:5060;branch=z9hG4bK-e3e20b97 From: Jack <sip:4001@192.168.1.23>;tag=cc585e8b73088fe6o0 To: <sip:*98@192.168.1.23> Call-ID: b1f9b2f-fc77db92@192.168.1.22 CSeq: 102 INVITE Max-Forwards: 70 Proxy-Authorization: Digest username="4001", realm="asterisk", nonce="4b920751", uri="sip:*98@192.168.1.23", algorithm=MD5, response="a357d3f453215798c4bdc8393fc6287d" Contact: Jack <sip:4001@192.168.1.22:5060> Expires: 240 User-Agent: Sipura/SPA2000-2.0.13(g) Content-Length: 422 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER Supported: 100rel, x-sipura Content-Type: application/sdp v= 0 o= 303734 303734 IN IP4 192.168.1.22 s= - c= IN IP4 192.168.1.22 t= 0 0 m= audio 16404 RTP/AVP 4 0 2 8 18 100 101 a= rtpmap:4 G723/8000 a= rtpmap:0 PCMU/8000 a= rtpmap:2 G726-32/8000 a= rtpmap:8 PCMA/8000 a= rtpmap:18 G729a/8000 a= rtpmap:100 NSE/8000 a= rtpmap:101 telephone-event/8000 a= fmtp:101 0-15 a= ptime:20 a= sendrecv Supported: 100rel, x-sipura Liste les nouvelles fonctionnalités de ce UA en dehors de la description de la RFC 3261 Si cette section est vide , elle signifie : pas d’extensions supportées. Supported : le champ d’en-tête Supported (Accepté) énumère toutes les extensions acceptées par l’UAC ou l’UAS. S’il est vide, il signifie qu’aucune extension n’est acceptée. Exemple : Supported: 100rel Copyright © 2011 - Global Knowledge France

Content INVITE sip:jill@hill.edu SIP/2.0 Le protocole SIP Content INVITE sip:jill@hill.edu SIP/2.0 Via: SIP/2.0/UDP hill.edu:5060;branch=z9hG4bK0086 Max-Forwards: 7 To: Jill <sip:jhill@hill.edu> From: Jack <sip:Jack@spratt.com>;tag=111234 Call-ID: 545317007@99.1.2.3 CSeq: 1 INVITE Contact: sip:jack@spratt.com Content-Type: application/sdp Content-Length: 159 v=0 o=splatt 289084526 28904529 IN IP4 uphill.spratt.com c=IN IP4 99.1.2.3 m=audio 16384 RTP/AVP 4 a=rtpmap:4 G723/8000 Content-Type : indique le type de message qui est envoyé. Content-Type : le champ d’en-tête Content-Type (Type-de-contenu) indique le type de support du corps de message envoyé au receveur. Le champ d’en-tête Content-Type DOIT être présent si le corps n’est pas vide. Si le corps est vide, et si un champ d’en-tête Content-Type est présent, il indique que le corps de ce type spécifique a une longueur de zéro (par exemple, un fichier audio vide). Copyright © 2011 - Global Knowledge France

SDP INVITE sip:jill@hill.edu SIP/2.0 Le protocole SIP SDP INVITE sip:jill@hill.edu SIP/2.0 Via: SIP/2.0/UDP hill.edu:5060;branch=z9hG4bK0086 Max-Forwards: 7 To: Jill <sip:jhill@hill.edu> From: Jack <sip:Jack@spratt.com>;tag=111234 Call-ID: 545317007@99.1.2.3 CSeq: 1 INVITE Contact: sip:jack@spratt.com Content-Type: application/sdp Content-Length: 159 v=0 o=splatt 289084526 28904529 IN IP4 uphill.spratt.com c=IN IP4 99.1.2.3 m=audio 16384 RTP/AVP 4 a=rtpmap:4 G723/8000 v= Version number (SIP l’ignore) o= Origin (La seule version utilisée par SIP est 28904529) c= Connection data (L’adresse IP pour media) m= Media (Type = audio, port = 16384, RTP/AVP profile = 0) a= Attribute (Profile = 4, codec = G723, sampling rate = 8000 Hz) Les détails de la session, comme le type de support, codec ou débit d’échantillonnage ne sont pas décrits à l’aide de SIP. Le corps d’un message SIP contient plutôt une description de la session, codée dans un autre format de protocole. Un de ces formats est le protocole de description de session (SDP, Session Description Protocol) (RFC 2327). Ce message SDP est porté par le message SIP d’une façon analogue à celle dont un document joint est porté par un message électronique, ou dont une page web est portée par un message HTTP. Copyright © 2011 - Global Knowledge France

SDP: RFC 2327 Les informations de l’entête v=0 s= Le protocole SIP SDP: RFC 2327 Les informations de l’entête Version Origine Information Adresse E-mail Les informations du contact qui est responsable de la session v=0 s= o=SipveSysAS5300Ver 7340 629 IN IP4 99.1.2.3 i=SIP applications discussion e=mbone@somewhere.com t=<starttime> <stoptime> m=audio 5004 RTP/AVP 4 c=IN IP4 99.1.2.3 a=ptime:30 a=recvonly m=video 16398 RTP/AVP 96 c=IN IP4 42.5.1.1 a=rtpmap:96 MPEG La durée de la session Profil Audio RTP (RFC 3551) Profil vidéo RTP (RFC 3551) Copyright © 2011 - Global Knowledge France

SDP: RFC 2327 Exemple de champ info SDP: v= (Protocol version) Le protocole SIP SDP: RFC 2327 Exemple de champ info SDP: v= (Protocol version) o= (Owner and creator, and session identifier) s= (Session name) u=* (URI of description) e=* (E-mail address) p=* (Phone number) z=* (Time zone adjustments) Time description: t= (Time the session is active) r=* (Zero or more repeat times) Media description: m= (Media name and transport address) i=* (Media title) c=* (Connection information) b=* (Bandwidth information) k=* (Encryption key) a=* (Zero or more media attribute lines) S.D.P. Session Description Protocol – RFC 2327 SDP est tout d’abord utilisé pour SAP. SDP permet de décrire la session RTP. Parce que le SDP est simple, il est devenu le protocole utilisé pour les sessions multimédias. Il est également utilisé pour SIP, MGCP et MEGACO Le rôle de SDP est de décrire l’ensemble des paramètres constituant une session. Cela inclut la spécification des médias utilisés, des protocoles de transport, des ports, des codages audios , des ressources nécessaires ainsi que les dates d’activation de la session. Ci -dessus vous trouverez les différents champs SDP à titre d’information. Copyright © 2011 - Global Knowledge France

Le protocole SIP 180 RINGING SIP/2.0 180 RINGING Via: SIP/2.0/UDP hill.edu:5060;branch=z9hG4bK0086 Max-Forwards: 7 To: Jill <sip:jhill@hill.edu >;tag=545317 From: Jack <sip:Jack@spratt.com>;tag=111234 Call-ID: 545317007@99.1.2.3 CSeq: 1 INVITE Contact: sip:jack@spratt.com Via, To, From, Call-ID, et CSeq sont recopiés dans les réponses L’entête To a maintenant un tag (étiquette) insérée par le UAS. 180 RINGING Sonnerie en cours L’UA qui reçoit l’INVITE est en train d’essayer d’alerter l'utilisateur. Cette réponse PEUT être utilisée pour initialiser la sonnerie de retour d’appel local. Copyright © 2011 - Global Knowledge France

Le protocole SIP 200 OK SIP/2.0 200 OK Via: SIP/2.0/UDP hill.edu:5060;branch=z9hG4bK0086 Max-Forwards: 7 To: Jill <sip:jhill@hill.edu >;tag=545317 From: Jack <sip:Jack@spratt.com>;tag=111234 Call-ID: 545317007@99.1.2.3 CSeq: 1 INVITE Contact: sip:jack@spratt.com Content-Type: application/sdp Content-Length: 165 v=0 o=splatt 2452772446 2452772446 IN IP4 uphill.spratt.com c=IN IP4 41.2.3.1 m=audio 5004 RTP/AVP 4 a=rtpmap:4 G723/8000 200 OK La demande a réussi. Les informations retournées avec la réponse dépendent de la méthode utilisée dans la demande. Copyright © 2011 - Global Knowledge France

Les Méthodes SIP REGISTER INVITE ACK) CANCEL OPTIONS INFO UPDATE REFER Le protocole SIP Les Méthodes SIP REGISTER INVITE ACK) CANCEL OPTIONS INFO UPDATE REFER PRACK Copyright © 2011 - Global Knowledge France

Méthode SIP : REGISTER sip.gkn.fr 4428@gkn.fr Le protocole SIP Méthode SIP : REGISTER SIP proxy server sip.gkn.fr Location server REGISTER 4428@gkn.fr = 71.5.5.2 Database update (Pas une spécification SIP) 4428@gkn.fr = 4428@71.5.5.2 Database update confirmed REGISTER sip:sip.gkn.fr SIP/2.0 To: sip:4428@gkn.fr From: sip:4428@gkn.fr Contact: <sip:4428@71.5.5.2>;expires=30 200 OK Un usager emploiera cette requête pour enregistrer son adresse auprès d’un proxy, ou un serveur de re-routage. L’enregistrement d’une adresse a une durée de vie limitée et le serveur la désactivera si son enregistrement n’est pas rafraîchi par le poste de l’usager. Le champ « Expire » de l’en-tête permet à l’usager de définir lui-même la durée de vie de son enregistrement auprès du serveur. 4428@gkn.fr Copyright © 2011 - Global Knowledge France

Le protocole SIP INVITE et ACK Demande au travers d’une séquence à 3 temps avec un ACK pour indiquer que le dialogue débute. Transporte usuellement SDP Effets sur le dialogue SIP Etablit ½ du dialogue SIP Un 200 ou 1XX Fiable peut confirmer le dialogue Re-INVITE Un INVITE qui utilise un dialogue existant IMPORTANT: Le Re-INVITE change l’état du dialogue On préfère utiliser un UPDATE pour modifier un Early Dialog et non un INVITE INVITE +SDP 1 100 Trying 180 Ringing 183 Ringing + SDP 200 OK +SDP 2 ACK 3 La transaction ACK est envoyée seulement après une réponse finale à un SIP INVITE. La demande ACK n’est jamais envoyée en réponse à tout autre message SIP. Donc, quand un message BYE est envoyé, une réponse 200 est retourné et il n'y a aucun message ACK pour la réponse finale. Copyright © 2011 - Global Knowledge France

Le protocole SIP Méthode SIP: INFO RFC 2976 SIP Proxy Alice’s Bank Alice Alice Session Established INFO sip:Alice’s_Bank@192.168.10.20 SIP/2.0 Via: SIP/2.0/TCP pc33.atlanta.com ;branch=z9hG4bK776asegma Max-Forwards: 70 To: Bank <sip:Bank@Bank_URI.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 22756 INFO Contact: <sip:alice@pc33.atlanta.com> Content-Type: text/plain Content-Length: 16   3 1 8 1 9 6 2 INFO INFO – Information des sessions générées lors de la session Exemple: n° compte Copyright © 2011 - Global Knowledge France

Le protocole SIP SIP Methods: PRACK Bob PRACK- Acquittement provisoire pour une session non encore établie Alice INVITE 183 Session Progress PRACK 200 OK [PRACK] SIP/2.0 200 OK sip:bob@192.168.10.20 Via: SIP/2.0/TCP pc33.atlanta.com ;branch=z9hG4bK776asi98JK ;received=10.1.3.33 To: Bob <sip:bob@biloxi.com>; tag=a6c85e3 From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 PRACK Contact: <sip:alice@pc33.atlanta.com> Content-Length: 0 Copyright © 2011 - Global Knowledge France

Dynamique des Flux Le protocole SIP Copyright © 2011 - Global Knowledge France

Principe requête /réponse RFC 3261 Section 4 Le protocole SIP Principe requête /réponse RFC 3261 Section 4 atlanta.com . . . biloxi.com . proxy proxy . Alice's . . . . . . . . . . . . . . . . . . . . Bob's softphone SIP Phone | | | | | INVITE F1 | | | |--------------->| INVITE F2 | | | 100 Trying F3 |--------------->| INVITE F4 | |<---------------| 100 Trying F5 |--------------->| | |<-------------- | 180 Ringing F6 | | | 180 Ringing F7 |<---------------| | 180 Ringing F8 |<---------------| 200 OK F9 | |<---------------| 200 OK F10 |<---------------| | 200 OK F11 |<---------------| | |<---------------| | | | ACK F12 | |------------------------------------------------->| | Media Session | |<================================================>| | BYE F13 | |<-------------------------------------------------| | 200 OK F14 | Cette section est extraite de la RFC 3261 . Copyright © 2011 - Global Knowledge France

Le trapèze SIP RFC 3261 Section 4, Figure 1 Le protocole SIP Le trapèze SIP RFC 3261 Section 4, Figure 1 SIP | | | | | INVITE F1 | | | |--------------->| INVITE F2 | | | 100 Trying F3 |--------------->| INVITE F4 | |<---------------| 100 Trying F5 |--------------->| | |<-------------- | 180 Ringing F6 | | | 180 Ringing F7 |<---------------| | 180 Ringing F8 |<---------------| 200 OK F9 | |<---------------| 200 OK F10 |<---------------| | 200 OK F11 |<---------------| | |<---------------| | | | ACK F12 | |------------------------------------------------->| | Media Session | |<================================================>| | BYE F13 | |<-------------------------------------------------| | 200 OK F14 | Atlanta.com Proxy biloxi.com Proxy SIP SIP Alice’s Softphone Media Bob’s Softphone Voici un exemple typique d'un échange de messages SIP entre deux utilisateurs, Alice et Bob. (Chaque message est marqué avec la lettre "F" et un numéro pour référence par le texte.) Dans cet exemple, Alice utilise une application SIP sur son PC (dénommé un softphone) pour appeler Bob sur son téléphone SIP sur Internet . On trouvera également deux serveurs proxy SIP qui agissent au nom d'Alice et Bob pour faciliter l'établissement de la session. Cet arrangement typique est souvent désigné comme le «trapèze SIP". Copyright © 2011 - Global Knowledge France

INVITE sip: bob@biloxi.com RFC 3261 Section 4, Figure 1 Le protocole SIP INVITE sip: bob@biloxi.com RFC 3261 Section 4, Figure 1 SIP | | INVITE F2 | | | 100 Trying F3 |--------------->| INVITE F4 | |<---------------| 100 Trying F5 |--------------->| | |<-------------- | 180 Ringing F6 | | | 180 Ringing F7 |<---------------| | 180 Ringing F8 |<---------------| 200 OK F9 | |<---------------| 200 OK F10 |<---------------| | 200 OK F11 |<---------------| | |<---------------| | | | ACK F12 | |------------------------------------------------->| | Media Session | |<================================================>| | BYE F13 | |<-------------------------------------------------| | 200 OK F14 | Atlanta.com Proxy biloxi.com Proxy SIP SIP Alice’s Softphone Media Bob’s Softphone INVITE F1 INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 v=0 o=superwaterbuffalo 5721 6762 IN IP4 12.68.2.1 s= SIP Call c=IN IP4 12.68.2.1 m=audio 5000 RTP/AVP 0 18 La méthode INVITE permet d’initier une communication en invitant un correspondant à y participer. Elle peut aussi être utilisée pour une conférence afin d’inviter plusieurs interlocuteurs à communiquer au sein d’une même session. Notons qu’une autre utilisation classique de cette méthode consiste à renégocier dynamiquement de nouveaux paramètres de session. Exemple : si , durant une session déjà établie, l’un des interlocuteurs souhaite enrichir la Voix par la vidéo, il fait sa demande par une requête d’invitation. Copyright © 2011 - Global Knowledge France

INVITE sip: bob@biloxi.com RFC 3261 Section 4, Figure 1 Le protocole SIP INVITE sip: bob@biloxi.com RFC 3261 Section 4, Figure 1 INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 v=0 o=superwaterbuffalo 5721 6762 IN IP4 12.68.2.1 s= SIP Call c=IN IP4 12.68.2.1 m=audio 5000 RTP/AVP 0 18 SIP | | INVITE F2 | | | 100 Trying F3 |--------------->| INVITE F4 | |<---------------| 100 Trying F5 |--------------->| | |<-------------- | 180 Ringing F6 | | | 180 Ringing F7 |<---------------| | 180 Ringing F8 |<---------------| 200 OK F9 | |<---------------| 200 OK F10 |<---------------| | 200 OK F11 |<---------------| | |<---------------| | | | ACK F12 | |------------------------------------------------->| | Media Session | |<================================================>| | BYE F13 | |<-------------------------------------------------| | 200 OK F14 | Atlanta.com Proxy biloxi.com Proxy SIP SIP Alice’s Softphone Media Bob’s Softphone INVITE F1 INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 v=0 o=superwaterbuffalo 5721 6762 IN IP4 12.68.2.1 s= SIP Call c=IN IP4 12.68.2.1 m=audio 5000 RTP/AVP 0 18 Copyright © 2011 - Global Knowledge France

SDP RFC 3261 Section 4, Figure 1 SIP SIP SIP Media | | INVITE F2 | | Le protocole SIP SDP RFC 3261 Section 4, Figure 1 SIP | | INVITE F2 | | | 100 Trying F3 |--------------->| INVITE F4 | |<---------------| 100 Trying F5 |--------------->| | |<-------------- | 180 Ringing F6 | | | 180 Ringing F7 |<---------------| | 180 Ringing F8 |<---------------| 200 OK F9 | |<---------------| 200 OK F10 |<---------------| | 200 OK F11 |<---------------| | |<---------------| | | | ACK F12 | |------------------------------------------------->| | Media Session | |<================================================>| | BYE F13 | |<-------------------------------------------------| | 200 OK F14 | Atlanta.com Proxy biloxi.com Proxy SIP SIP Alice’s Softphone Media Bob’s Softphone INVITE + SDP F1 v=0 o=superwaterbuffalo 5721 6762 IN IP4 12.68.2.1 s= SIP Call c=IN IP4 12.68.2.1 m=audio 5000 RTP/AVP 0 18 Les détails de la session, telles que le type de support, codec, ou le taux d'échantillonnage, ne sont pas décrits en utilisant SIP. Au contraire, le corps d'un message SIP contient une description de la session, encodés dans un format autre protocole. Un tel format est le Session Description Protocol SDP, RFC 2327. Il est porté par le message SIP d'une manière qui est analogue à un document joint en étant porté par un message e-mail ou une page Web en cours dans un message HTTP. Copyright © 2011 - Global Knowledge France

Proxy Function RFC 3261 Section 4, Figure 1 Le protocole SIP Proxy Function RFC 3261 Section 4, Figure 1 SIP 180 Ringing F6 | | | 180 Ringing F7 |<---------------| | 180 Ringing F8 |<---------------| 200 OK F9 | |<---------------| 200 OK F10 |<---------------| | 200 OK F11 |<---------------| | |<---------------| | | | ACK F12 | |------------------------------------------------->| | Media Session | |<================================================>| | BYE F13 | |<-------------------------------------------------| | 200 OK F14 | Atlanta.com Proxy biloxi.com Proxy SIP SIP Alice’s Softphone Media Bob’s Softphone INVITE +SDP F1 INVITE + SDP F2 100 Trying INVITE + SDP F3 F4 100 Trying F5 Le serveur SIP atlanta.com est un type de serveur SIP connu sous le nom de serveur proxy. Un serveur proxy SIP reçoit les demandes et les transmet au nom du demandeur. Dans cet exemple, le serveur proxy reçoit la requête INVITE et envoie une réponse 100 (Trying) réponse au softphone d'Alice. La réponse 100 (Trying) indique que l'INVITE a été reçu et que le proxy fonctionne en son nom pour acheminer l'INVITE à la destination. Les Réponses SIP utilisent un code à trois chiffres suivi d'une phrase descriptive. Cette réponse contient les mêmes To, From, Call-ID, CSeq et paramètre branch dans le champ Via de l’INVITE, ce qui permet au softphone d’ Alice de corréler cette réponse à l'invitation envoyée. Copyright © 2011 - Global Knowledge France

Réponse 180 RFC 3261 Section 4, Figure 1 Le protocole SIP Réponse 180 RFC 3261 Section 4, Figure 1 SIP 200 OK F9 | 200 OK F10 |<---------------| | 200 OK F11 |<---------------| | |<---------------| | | | ACK F12 | |------------------------------------------------->| | Media Session | |<================================================>| | BYE F13 | |<-------------------------------------------------| | 200 OK F14 | Atlanta.com Proxy biloxi.com Proxy SIP SIP Alice’s Softphone Media Bob’s Softphone INVITE +SDP F1 INVITE + SDP F2 100 Trying INVITE + SDP F3 F4 100 Trying F5 180 Ringing F6 180 Ringing F7 180 Ringing F8 Le téléphone SIP de Bob reçoit l'INVITE et alerte Bob de l'appel entrant de façon à ce que celui-ci réponde. Le tléphone SIP de Bob l'indique dans une réponse 180 (Ringing) qui est renvoyée par les deux proxys dans le sens inverse. Chaque proxy utilise le champ d'en-tête Via pour déterminer où envoyer la réponse et supprime sa propre adresse à partir du haut. Par conséquent, même si le DNS et le service de localisation ont été nécessaires pour acheminer l'INVITE initiale, le 180 (Ringing) de réponse peut être renvoyé à l'appelant. Chaque proxy qui voit l'INVITE voit également toutes les réponses à l'INVITE. Lorsque le softphone Alice reçoit le 180 (Ringing) de réponse, l’information est transmise en utilisant une tonalité de retour audio ou en affichant un message sur l'écran d'Alice. Copyright © 2011 - Global Knowledge France

Réponse Finale 200 RFC 3261 Section 4, Figure 1 Le protocole SIP Réponse Finale 200 RFC 3261 Section 4, Figure 1 SIP | BYE F13 | |<-------------------------------------------------| | 200 OK F14 | |------------------------------------------------->| Atlanta.com Proxy biloxi.com Proxy SIP SIP Alice’s Softphone Media Bob’s Softphone INVITE +SDP F1 INVITE + SDP F2 100 Trying INVITE + SDP F3 F4 100 Trying F5 180 Ringing F6 180 Ringing F7 180 Ringing 200 + SDP F8 F9 200 + SDP F10 200 + SDP F11 ACK F12 Lorsque Bob décroche le combiné, son téléphone SIP envoie une réponse 200 (OK) pour indiquer que l'appel a été répondu. Le 200 (OK) contient dans le corps du message la description du type de session que Bob est prêt à établir avec Alice ainsi que les médias via le protocole SDP. En conséquence, il y a un échange en deux phases de messages SDP : Alice envoie un message à Bob et Bob envoie un message en retour à Alice. Cet échange à deux phases offre des capacités de négociation de base et est fondé sur un échange SDP de type requête / réponse. Si Bob ne souhaite pas répondre ou est occupé par un autre appel, une réponse d'erreur sera envoyée à la place du 200 (OK). Ceci ne donne lieu à aucune session de média. Le 200 (OK) (message F9) pourrait ressembler au message de la page suivante. Media (RTP) Copyright © 2011 - Global Knowledge France

Dialogue SIP SIP/2.0 200 OK Via: SIP/2.0/UDP server10.biloxi.com Le protocole SIP Dialogue SIP SIP/2.0 200 OK Via: SIP/2.0/UDP server10.biloxi.com ;branch=z9hG4bKnashds8;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com ;branch=z9hG4bK776asdhds ;received=192.0.2.1 To: Bob <sip:Bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: <sip:Bob@192.0.2.4> Content-Type: application/sdp Content-Length: 131 Le Dialog est montré ici et est identifié par les champs “To Tag + From Tag + Call-ID” Copyright © 2011 - Global Knowledge France

BYE RFC 3261 Section 4, Figure 1 SIP SIP Media Atlanta.com Proxy Le protocole SIP BYE RFC 3261 Section 4, Figure 1 SIP Atlanta.com Proxy biloxy.com Alice’s Softphone Bob’s Media SIP INVITE +SDP F1 F2 INVITE + SDP F4 F3 100 Trying F5 F6 180 Ringing F7 F8 F9 200 OK F10 F11 ACK F12 Media (RTP) F14 F13 BYE La transaction BYE marque la fin de l'appel SIP. Cette requête peut être émise indifféremment par l’appelant ou par l’appelé. Elle n’attend pas d’acquittement, puisque la fin d’une session peut être décidée unilatéralement. Copyright © 2011 - Global Knowledge France

INVITE jill@hill.edu +SDP Le protocole SIP Redirect Server SIP SIP location server sip:jill@hill.edu Where is jill@hill.edu? INVITE jill@hill.edu +SDP 198.7.7.2:5060 302 SIP UAC UAS UAC UAS 7 ACK INVITE jill@pluto.net 8 100 (trying) 180 (ringing) 200 (success) 11 ACK 12 Jill@pluto.net laptop.pluto.net 198.7.7.2 sip.hill.edu 9.1.2.2:5060 Jack@spratt.com sip.hill.edu 9.1.2.2 SIP UAC UAS hill.edu DNS Copyright © 2011 - Global Knowledge France

SIP Proxy Server Where is jill@hill.edu? sip:jill@hill.edu Le protocole SIP SIP Proxy Server SIP location server Where is jill@hill.edu? sip:jill@hill.edu pc21.hill.edu INVITE jill@hill.edu +SDP INVITE jill@hill.edu +SDP 100 (trying) 100 (trying) SIP UAC UAS SIP UAS UAC sip.hill.edu 9.1.2.2:5060 UAC UAS 12 180 (ringing) 180 (ringing) 11 14 200 (success) + SDP 13 200 (success) + SDP ACK 16 ACK 15 Voici un exemple d’utilisation d’un serveur proxy SIP : Un utilisateur nommé jack@spratt.com veut appeler jill@hill.edu : Résolution d’un nom pour connaître l’adresse IP via le DNS hill.edu Une fois que l’adresse IP est connue alors jack@spratt.com peut lancer une invitation à jill@hill.edu en passant par le proxy SIP. Le proxy SIP demande au serveur de location si dans la base de données du serveur location il y a jill@hill.edu et où il se trouve grâce au serveur Registrar Une fois l’utilisateur jill@hill.edu localisé (pc21.hill.edu), le serveur proxy demande une résolution de nom pour avoir l’adresse IP du support de jill@hill.edu Dès que l’adresse IP est connue alors le serveur Proxy peut envoyer une requête d’invitation à jill@hill.edu de la part de jack@spratt.com Le serveur proxy va servir d’intermédiaire entre l’utilisateur jack]@spratt.com et jill@hill.edu jill@hill.edu envoie un message 100 trying pour informer l’utilisateur jack@spratt.com que c’est en cours d’analyse jill@hill.edu envoie un message 180 ringing pour informer l’utilisateur jack@spratt.com que le poste est en train de sonner et jack@spratt.com reçoit une sonnerie de retour jill@hill.edu envoie un message 200 OK pour informer l’utilisateur jack@spratt.com que jill@hill.edu a décroché et envoie également le codec qu’ils vont utiliser pour dialoguer ainsi que le port RTP que jill@hill.edu va utiliser dans le corps S.D.P (Session Description Protocol) Jack@spratt.com envoie un message d’acquittement (ACK) pour confirmer le début de la conversation 41.2.3.1 Jill@hill.edu Resolve pc21.hill.edu 9.1.2.2 jack@spratt.com Resolve sip.hill.edu pc21.hill.edu 41.2.3.1 jackpc.spratt.com 99.1.2.3 hill.edu DNS Copyright © 2011 - Global Knowledge France

SIP Forking SIP location server Where is jill@hill.edu? Le protocole SIP SIP Forking SIP location server Where is jill@hill.edu? sip:jill@hill.edu 198.7.7.2:5060 41.2.3.1:5060 Jill@hill.edu pc21.hill.edu 41.2.3.1 UAC UAS SIP UAC UAS INVITE jill@hill.edu +SDP SIP UAC UAS INVITE jill@hill.edu +SDP INVITE jill@hill.edu +SDP SIP UAC UAS Jack@spratt.com sip.hill.edu 9.1.2.2:5060 Jill@hill.net laptop.pluto.net 198.7.7.2 Copyright © 2011 - Global Knowledge France

MODULE 4 Les extensions de SIP Le protocole SIP MODULE 4 Les extensions de SIP Copyright © 2011 - Global Knowledge France

Event Notifications Besoin d'une notification d'événement flexible. Le protocole SIP Event Notifications Besoin d'une notification d'événement flexible. Activer les informations de présence. Meilleur support pour les applications mobiles SIP. Retour d’informations : messagerie vocale, décroché. Ajoute une méthode "NOTIFY" et un en-tête « event : » Copyright © 2011 - Global Knowledge France

Event Notifications Souscription à l’évènement : Le protocole SIP Event Notifications Souscription à l’évènement : Ajout d’une méthode "SUBSCRIBE » Ajoute un en-tête « event : » Les événements peuvent être relatifs aux appels Les questions de sécurité : événements sensibles Protection des renseignements personnels Authentification Utilisé pour des applications de présence personnelle Augmentée par la méthode « MESSAGE" pour la messagerie instantanée Copyright © 2011 - Global Knowledge France

Le Modèle de PRESENCE RFC 2778 Le protocole SIP Le Modèle de PRESENCE RFC 2778 PRESENTITY Client Sends Presence info UA PRESENTITY Presence Service or WATCHER WATCHER Client (2 types) Fetcher: Polls to get Presence info Subscriber: Asks presence server for future changes L'UA SIP peut fonctionner en deux modes, deux en même temps si la situation l'exige. Quand un changement d'état se produit sur l'UA qui a été demandé par un ABONNEZ-VOUS précédent, l'UA émettra un message de notification de l'entité souscrivant du changement. Dans ce cas, l'UA est l'expéditeur dans une «entité présente" session. Il n'y a pas de limite au niveau de la sensibilité, la profondeur de l'information ou de toute notion de vie privée que ce soit. Limiter les informations mises à disposition via entité présente est fonction de la demande de l'UA, et non pas le service presentity. D'autre part, l'UA peut être regarder des informations concernant d'autres HES, État de l'inscription, ou tout ce qui peut être imaginé. Dans ce cas, l'UA est un visionné, qui peut délivrer un s'abonner aux type d'événement spécifique et d'attendre le client à distance pour répondre ENTITÉ PRÉSENTE, où l'agent peut ainsi scruter pour les informations de présence. Copyright © 2011 - Global Knowledge France

SUBSCRIBE - Acceptation Le protocole SIP SUBSCRIBE - Acceptation SUBSCRIBE Event: voice-mail Expires:3600 Accept: text/plain NOTIFY Expires:1756 subscription-State: active 200 OK Expires:1800 202 Accepted Pas d’info attente SUCCES! SUCCES! La réponse 202 illustre l'abonnement en cours et peut réussir ou échouer. Copyright © 2011 - Global Knowledge France

subscription-State: terminated Le protocole SIP SUBSCRIBE Refus SUBSCRIBE Event: voice-mail Expires:3600 Accept: text/plain NOTIFY Expires:1756 subscription-State: terminated ;reason: rejected 489 Bad Event 202 Accepted 200 OK Zut! Echec La réponse 202 illustre l'abonnement en cours et peut réussir ou échouer. Copyright © 2011 - Global Knowledge France

The Model for Instant Messaging RFC 2778 Le protocole SIP The Model for Instant Messaging RFC 2778 SENDER Client Sends IMs UA SENDER Instant Message Service or INSTANT INBOX INSTANT INBOX Receives IMs Copyright © 2011 - Global Knowledge France

Extensions SIP pour la messagerie instantanée RFC 3428 Le protocole SIP Extensions SIP pour la messagerie instantanée RFC 3428 F1 MESSAGE F2 MESSAGE F3 200 OK F4 200 OK User1 Proxy User2 MESSAGE sip:user2@domain.com SIP/2.0 Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse Max-Forwards: 70 From: sip:user1@domain.com;tag=49583 To: sip:user2@domain.com Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 18 Watson, come here. Copyright © 2011 - Global Knowledge France

La Presence SIP Alice veut être notifiée quand Betty se connecte Betty Le protocole SIP La Presence SIP DNS Presence Registrar Registrar 2 Subscribe 1 Subscribe UAS UAC UAS UAC Betty 200 OK 200 OK 4 3 NOTIFY (not signed in) NOTIFY (not signed in) 6 5 sip.ipkeros.com 67.22.7.19 sip.gkn.fr 65.16.10.24 7 200 OK 8 200 OK betty@gkn.fr (pas encore connectée) alice@ipkeros.com Alice veut être notifiée quand Betty se connecte Copyright © 2011 - Global Knowledge France

SIP Registration Betty se connecte 200 OK Le protocole SIP 2 REGISTER DNS Presence 2 Registrar Registrar REGISTER UAS UAC UAS UAC 1 200 OK 3 sip.ipkeros.com 67.22.7.19 sip.gkn.fr 65.16.10.24 betty@gkn.fr alice@ipkeros.com Betty se connecte Copyright © 2011 - Global Knowledge France

SIP Presence Le serveur de “Presence” détecte que Le protocole SIP SIP Presence DNS 1 Presence Registrar Registrar NOTIFY betty@gkn.fr signed in NOTIFY betty@gkn.fr signed in UAS UAC 2 UAS UAC 3 200 OK 200 OK 4 5 sip.ipkeros.com 67.22.7.19 sip.gkn.fr 65.16.10.24 betty@gkn.fr alice@ipkeros.com Le serveur de “Presence” détecte que Betty est maintenant connectée Copyright © 2011 - Global Knowledge France

SIP Message Le protocole SIP 4 MESSAGE – “ réunion à 9:00 ”? DNS 4 MESSAGE – “ réunion à 9:00 ”? Registrar Registrar MESSAGE – “ réunion à 9:00 ”? 3 1 MESSAGE – “ réunion à 9:00 ”? UAS UAC 2 UAS UAC 5 200 OK 200 OK 200 OK 6 7 8 sip.ipkeros.com 67.22.7.19 sip.gkn.fr 65.16.10.24 betty@gkn.fr alice@ipkeros.com Copyright © 2011 - Global Knowledge France

SIP Message sip.ipkeros.com? 67.22.7.19 200 OK sip.ipkeros.com Le protocole SIP SIP Message DNS 3 sip.ipkeros.com? 67.22.7.19 6 Registrar Registrar MESSAGE – “téléphone moi ” 5 MESSAGE “téléphone moi “ 2 MESSAGE – “téléphone moi “ UAS UAC UAS UAC 1 7 4 200 OK 8 9 200 OK 200 OK 10 sip.ipkeros.com 67.22.7.19 sip.gkn.fr 65.16.10.24 betty@gkn.fr alice@ipkeros.com Copyright © 2011 - Global Knowledge France

MODULE 5 SIP et la sécurité Le protocole SIP MODULE 5 SIP et la sécurité Copyright © 2011 - Global Knowledge France

Sécurité SIP Digest TLS/Ipsec S/MIME Le protocole SIP Sécurité SIP Digest Pour l’authentification de l’émetteur TLS/Ipsec Confidentialité/intégrité de l’échange S/MIME Confidentialité du contenu de bout en bout Copyright © 2011 - Global Knowledge France

SIP sécurisé et TLS TLS (Transport Layer Security) Le protocole SIP SIP sécurisé et TLS TLS (Transport Layer Security) RFC 2246 Utilise TCP comme transport pour une sécurité hop-by-hop. Cryptage Public/Private Key avec Certificats SIPS URI nécessite l’utilisation de TLS de bout en bout La RFC 3261 impose à SIP le support de TLS comme mécanisme de sécurité. TLS est décrit dans la RFC 2246. Copyright © 2011 - Global Knowledge France

Simple Traversal of UDP Through NATs (STUN) RFC 3489 Le protocole SIP Simple Traversal of UDP Through NATs (STUN) RFC 3489 Mécanisme permettant de détecter le type de NAT : Le serveur externe récupère l’adresse publique Renvoi cette information au client Renvoi des infos @ip,port de réception . Changement de port Changement d’adresse STUN Server STUN Client 1 2 NAT Internet 3 STUN Server Copyright © 2011 - Global Knowledge France

Traversal Using Relay NAT (TURN) Le protocole SIP Traversal Using Relay NAT (TURN) Le Client derrière le NAT a une simple connexion au serveur TURN. Le Serveur transmet les paquets entrants au client TURN Relay NAT Digest-authentication pour éviter les attaques DOS NAT TURN-enabled SIP phone TURN Server SIP Proxy/Registrar 1 2 3 4 Allocation d’un port TURN RéponseTURN, Enregistrement SIP avec le serveur TURN comme contact Les requêtes externes sont routées par TURN Un client TURN établit une session avec le serveur TURN et utilise la socket du serveur TURN pour l'établissement de sessions sur Internet. Le NAT voit toujours le serveur TURN comme source ou destination, le NAT permet la connexion, même si la destination finale de l'appel est au-delà du serveur TURN. SIP phone Copyright © 2011 - Global Knowledge France

NAT avec ALG (Application layer gateway) Le protocole SIP NAT avec ALG (Application layer gateway) Private Address Global Address SIP ALG & NAT Internet Modification des champs SIP et SDP pour les adapter au comportement du NAT Copyright © 2011 - Global Knowledge France

ANNEXE Analyse SIP Traces SIP analysées par votre formateur Le protocole SIP ANNEXE Analyse SIP Traces SIP analysées par votre formateur Copyright © 2011 - Global Knowledge France

Capture SIP sur protocole :UDP port 5060 Le protocole SIP Capture SIP sur protocole :UDP port 5060 Copyright © 2011 - Global Knowledge France

Séquence d’appel SIP Le protocole SIP Copyright © 2011 - Global Knowledge France

Trace d’un appel basique SIP Le protocole SIP Trace d’un appel basique SIP Copyright © 2011 - Global Knowledge France

Méthode SIP : REGISTER Le protocole SIP Copyright © 2011 - Global Knowledge France

Réponse SIP : 200 OK Le protocole SIP Copyright © 2011 - Global Knowledge France

Méthode SIP : INVITE Le protocole SIP Copyright © 2011 - Global Knowledge France

SDP dans la Requête SIP : INVITE Le protocole SIP SDP dans la Requête SIP : INVITE Copyright © 2011 - Global Knowledge France

SDP dans la Réponse SIP : 200 OK Le protocole SIP SDP dans la Réponse SIP : 200 OK Copyright © 2011 - Global Knowledge France

Méthode SIP : ACK Le protocole SIP Copyright © 2011 - Global Knowledge France

Méthode SIP : MESSAGE Le protocole SIP Copyright © 2011 - Global Knowledge France

Méthode SIP : SUBSCRIBE /NOTIFY Le protocole SIP Méthode SIP : SUBSCRIBE /NOTIFY Copyright © 2011 - Global Knowledge France

Capture du trafic RTP : Real Time Protocol Le protocole SIP Capture du trafic RTP : Real Time Protocol Copyright © 2011 - Global Knowledge France

Décodage du paquet UDP en tant que RTP Le protocole SIP Décodage du paquet UDP en tant que RTP Copyright © 2011 - Global Knowledge France

Filtre d’ affichage dans Ethereal ( WireShark ) Le protocole SIP Filtre d’ affichage dans Ethereal ( WireShark ) Copyright © 2011 - Global Knowledge France

Mise en Attente : HOLD Le protocole SIP Copyright © 2011 - Global Knowledge France

Récupération de l’appel : UNHOLD Le protocole SIP Récupération de l’appel : UNHOLD Copyright © 2011 - Global Knowledge France

Pour aller plus loin ……. Le protocole SIP Copyright © 2011 - Global Knowledge France

Pour aller plus loin ……. Le protocole SIP Copyright © 2011 - Global Knowledge France

Pour aller plus loin ……. Le protocole SIP Copyright © 2011 - Global Knowledge France