Présentation du protocole SIP

• RFC 3265, « Session Initiation Protocol (SIP)-Specific Event Notification »
• RFC 3853, « S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP) »
• RFC 4320, « Actions Addressing Identified Issues with the Session Initiation Protocol’s (SIP) Non-INVITE Transaction »
• RFC 4916, « Connected Identity in the Session Initiation Protocol (SIP) »
• RFC 5393, « Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies »

SIP est un protocole de signalisation conçu pour établir et contrôler des sessions multimédia. Pour cela, SIP associe une session avec des supports de type audio (appel téléphonique), vidéo (visio conférence) et donnée (gestion de présence). SIP est un protocole fonctionnant sous TCP/IP. Il se base plus précisément sur UDP et fonctionne par défaut sur le port 5060.

Le protocole SIP est aujourd’hui le plus utilisé dans le monde de la voix sur IP et Téléphonie sur IP. Il a des caractéristiques principales qui le rendent si attrayant :

• Système d’adressage d’URL
  L’adressage peut être un nombre de téléphone, une adresse IP ou une adresse email. Les messages sont très semblables à ceux employés par l’Internet HTTP1.1. Grâce à CPL (Call Processing Language) qui utilise XML, il est très facile d’ajouter des services intelligents de redirection.
• Multimédia
  Le protocole SIP peut avoir des sessions multiples de média pendant un appel. Le protocole SIP étant indépendant de la transmission des données, tout type de données et de protocoles peut être utilisé pour cet échange.
• Simplicité
  SIP est un protocole « léger » qui nécessite peu de ressource physique et peu de temps de développement. Ainsi il devient la cible favorite des constructeurs d’équipements et intégrateurs de solutions.

2 – Les terminologies

Dans un système SIP on trouve deux types de composantes, les users agents (UAC, UAS) et les applications de type serveurs (PS, RS, LS, RG) :

2.1 – AE – Terminal SIP

Le terme AE signifiant « Agent Equipment » représente l’ensemble des UAC « User Agent Client » et UAS « User Agent Server ». L’AE définit plus pragmatiquement les terminaux client IP ( téléphone, hardphone, Softphone, boîtier ATA …) qui initie ou reçoit les requêtes.

2.2 – PS – Serveur Proxy

Le terme PS signifiant « Proxy Server » ou aussi appelé « Relais mandataire » représente l’équipement agissant à la fois comme un client UAC et comme un serveur UAS. Le Proxy est chargés du routage d’une session SIP. Lorsqu’il réceptionne une requête SIP, il la transmet à un autre serveur proxy sur la route, ou directement à l’AE concerné, s’il est en liaison directe avec lui.

2.3 – RS – Serveur de redirection

Le terme RS signifiant « Redirect Server » permet de rediriger les appels vers la position actuelle d’un utilisateur. Il réalise simplement une conversion de l’adresse contenue dans la requête SIP en 0 ou plusieurs nouvelles adresses destinataires suivant qu’elle a été reconnue ou non.

2.4 – LS – Serveur de localisation

Le terme LS signifiant « 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 composée d’une base de donnée ou un ficher texte contenant la liste des UA, leurs droits et mot de passe.

2.5 – RG – Serveur d’enregistrement

Le terme RG signifiant « Registrar » est un serveur qui accepte les requêtes Register. Plus concrètement, il permet aux UA de s’inscrire et fournit les informations relative à la localisation d’un utilisateur.

3 – L’entête des messages

Les messages du protocole SIP sont codés en utilisant la syntaxe de message semblable au protocole HTTP1.1. Voici le schéma représentant la syntaxe de base d’un message SIP :

Un message SIP est donc composée de 2 rubriques principales qui sont la méthode et l’entête SIP. La ligne vide représente la possibilité d’utiliser d’autres protocoles multimédia tel que SDP « Session Description Protocol » définit par la RFC 2327.

3.1 – La méthode – Les requêtes

Les échanges client-serveur se font à l’aide de requêtes dont voici le détail de chacun des messages :

• INVITE (Définit par la RFC 3261)
  Le message invite indique que l’application ou l’utilisateur est invité à participer à une session. Le Corps du message décrit cette session (média supportés par l’appelant entre autres). En cas de réponse favorable à l’invitation, l’invité doit spécifier également les médias qu’il supporte dans son Corps du message. Un serveur est tenu de répondre à une telle invitation, identifiée par son CALL-ID, par une réponse OK (code 200). Si un UAS reçoit une requête INVITE avec un numéro de séquence Cseq supérieur à celui de la dernière requête INVITE de même CALL-ID reçue, celui-ci doit mettre à jour cette dernière.
• ACK (Définit par la RFC 3261)
  Le message ack confirme que le client a reçu une réponse définitive à une requête INVITE. Les réponses de code 2xx sont acquittées par les UAC et les autres types de réponses définitives par les premiers PS ou UAC les ayant reçues. La requête ACK possède, dans son Corps de message, une description définitive de la session que doit utiliser l’appelé. Si le Corps du message est vide (car il est optionnel), l’appelé utilise le descripteur de session de la requête INVITE. Après avoir envoyé une réponse de code 3xx, 4xx, 5xx ou 6xx, un PS doit déterminer si la requête ACK lui est destinée ou si elle est destinée à un autre PS. Cette détermination se fait en examinant le paramètre tag de l’URL TO. Le ACK lui est destiné si :
  • le tag de l’URL TO de la requête ACK est égal au tag de l’URL TO de la réponse
  • l’URL FROM, le CALL-ID et le Cseq de la requête ACK sont égaux à ceux de la réponse.
• OPTIONS (Définit par la RFC 3261)
  Le message option. 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. Si l’UAS ne supporte pas cette méthode, il renvoie une réponse Busy (code 600) au PS.
• BYE (Définit par la RFC 3261)
  Le message bye est utilisée par l’UAS de l’appelé pour signaler au PS local qu’il ne souhaite plus participer à la session. Si la requête INVITE contient une URL CONTACT, l’appelé envoie la requête BYE directement à cette adresse plutôt qu’à l’URL FROM. Cette méthode doit être supportée par les PS et devrait être supportée par les RS et UAS.
• CANCEL (Définit par la RFC 3261)
  Le message CANCEL est envoyée par un UAC ou un PS pour annuler une requête non validée par une réponse finale d’état. Par exemple, un PS peut envoyer une requête CANCEL aux destinataires n’ayant pas retourné une réponse finale après avoir reçu une réponse 2xx ou 6xx du PS. Par contre, un PS qui reçoit une requête d’erreur la retransmet à tous les destinataires qui y sont reliés. Les CALL-ID, Cseq, URL TO de la requête CANCEL sont les mêmes que ceux de la requête l’ayant générée. Pour distinguer une réponse à une requête CANCEL et une réponse à la requête originale, l’entête général est de type Cseq dans le format du message de la requête CANCEL. Quand un RS ou un UAS a reçu une requête CANCEL, il renvoie à l’émetteur une réponse OK(code 200) si la transaction existe bien et une réponse Transaction Does Not Exist (code 481) sinon.
• REGISTER (Définit par la RFC 3261)
  Le message register est utilisée par le client pour enregistrer l’adresse listée dans l’URL TO par le serveur auquel il est relié. Les requêtes sont traitées par le client dans l’ordre où elles arrivent et celui-ci devra éviter d’envoyer une nouvelle requête REGISTER tant qu’il n’aura pas traité la précédente. Le client doit définir une adresse d’enregistrement du type Utilisateur@Domaine . Cette méthode assure un service de localisation.
• INFO (Définit par la RFC 2976)
  Information de session en cours.
• MESSAGE (Définit par la RFC 3428)
  Permettre l’envoi de messages instantanés.
• NOTIFY (Définit par la RFC 3265)
  Envoyer des notifications d’événements.
• PRACK (Définit par la RFC 3262)
  Implémenter le mécanisme spécial de sécurisation des réponses provisoires.
• REFER (Définit par la RFC 3515)
  Permettre la redirection d’appels.
• SUSCRIBE (Définit par la RFC 3265)
  Demander une notification d’événements.
• UPDATE (Définit par la RFC 3311)

3.2 – La Méthode – Les réponses

Une réponse à un message est caractérisée, par un code et un motif, appelés code d’état et raison. 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. Les codes de réponse sont cohérents avec les codes de réponse HTTP/1.1. Tous les codes de réponse HTTP/1.1 ne sont pas appropriés, et seuls ceux qui le sont sont donnés ici. SIP définit une nouvelle classe : La 6xx.

Voici la liste des différentes classes :

• 1xx Provisoire
  Les réponses provisoires, aussi connues comme réponses informatives, indiquent que le serveur contacté est en train d’effectuer certaines actions et n’a pas encore de réponse définitive. Un serveur envoie une réponse 1xx si il s’attend à ce que l’obtention d’une réponse finale prenne plus de 200 ms. Noter que la transmission des réponses 1xx n’est pas fiable. Elle n’oblige jamais le client à envoyer un ACK. Les réponses provisoires (1xx) peuvent contenir un corps de message, y compris de description de session.
• 2xx Réussite
  La demande a réussi.
• 3xx Réorientation
  Les réponses 3xx donnent des informations sur la nouvelle localisation de l’utilisateur, ou sur des services de remplacement qui pourraient être capables de satisfaire à l’appel.
• 4xx Défaillance de la demande
  Les réponses 4xx sont des réponses d’échec bien déterminées provenant d’un serveur particulier. Le client NE devrait PAS réessayer la même demande sans modification (par exemple, en ajoutant l’autorisation appropriée). Cependant, la même demande sur un serveur différent pourrait réussir.
• 5xx Défaillance de serveur
  Les réponses 5xx sont des réponses d’échec qui indique que le serveur lui-même s’est trompé.
• 6xx Echecs
  Les réponses 6xx indiquent qu’un serveur a des informations certaines sur un utilisateur particulier, et non pas seulement sur l’instance particulière indiquée dans l’URI-de-demande.

Voici les réponses les plus souvent utilisées:

• SIP 100 – Essai
  Cette réponse indique que la demande a été reçue par le serveur du saut suivant et que certaine action non spécifiée est en train d’être effectuée au titre de cet appel (par exemple, une base de données est consultée). Cette réponse, comme toutes les autres réponses provisoires, arrête les retransmissions d’un INVITE par un UAC. La réponse 100 (En cours d’essai) est différente des autres réponses provisoires, en ce qu’elle n’est jamais transmise vers l’amont par un mandataire à états pleins.
• SIP 180 – Sonnerie en cours
  L’agent utilisateur 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 locale.
• SIP 181 – L’appel est en cours de transmission
  Un serveur peut utiliser ce code d’état pour indiquer que l’appel est en train d’être retransmis à un ensemble de destinations différent.
• SIP 183 – Avancement de la session
  La réponse 183 (Avancement de la session) est utilisée pour porter des informations sur la progression de l’appel qui n’est pas autrement classifiée. La phrase de cause, le champ d’entête, ou le corps de message peuvent être utilisés pour porter plus de précisions sur la progression de l’appel
• SIP 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.
• SIP 202 – Accepted
• SIP 400 – Mauvaise demande
  La demande n’a pas pu être comprise à cause d’une syntaxe mal formée. La phrase de cause devrait identifier le problème de syntaxe plus en détail, par exemple, « Champ d’entête Call-ID manquant ».
• SIP 401 – Non autorisé
  La demande exige une authentification de l’utilisateur. Cette réponse est produite par les UAS et registraires, alors que la réponse 407 (Authentification du mandataire exigée) est utilisée par les serveurs mandataires.
• SIP 404 – Pas trouvé
  Le serveur a des informations certaines que l’utilisateur n’existe pas au sein du domaine spécifié dans l’URI-de-demande. Cet état est aussi retourné si le domaine dans l’URI-de-demande ne correspond à aucun des domaines traités par le receveur de la demande.
• SIP 500 – Erreur interne du serveur
  Le serveur a rencontré une condition inattendue qui l’a empêché de satisfaire la demande. Le client peut afficher la condition d’erreur spécifique et peut réessayer la demande après plusieurs secondes.
  Si la condition est temporaire, Le serveur peut indiquer quand le client peut réessayer la demande en utilisant le champ d’entête Retry-After.
• SIP 503 – Service indisponible
  Le serveur est temporairement incapable de traiter la demande du fait d’une surcharge temporaire ou de la maintenance du serveur. Le serveur peut indiquer quand le client devrait réessayer la demande dans un champ d’entête Retry-After. Si aucun Retry-After n’est donné, le client doit agir comme s’il avait reçu une réponse 500 (Erreur interne du serveur).
  Un client (mandataire ou UAC) recevant une 503 (Service indisponible) devrait essayer de transmettre la demande sur un serveur de remplacement. Il ne devrait pas transmettre d’autres demandes à ce serveur pour la durée spécifiée dans le champ d’entête Retry-After, s’il est présent.
  Les serveurs peuvent refuser la connexion ou abandonner la demande au lieu de répondre avec 503 (Service indisponible).

Vous trouverez en annexe la liste complète des codes de réponses SIP.

3.3 – L’entête SIP

Il y a certains des champs d’entête qui sont présents toujours dans les requêtes et les réponses, et forment l’entête général :

• Call-ID
  Ce champ d’entête contient un identificateur globalement unique pour un appel.
• Cseq
  Il est un identificateur qui sert à rapprocher.
• From
  Il identifie l’appelant. Il doit présenter dans toutes les requêtes et les réponses.
• To
  Ce champ doit présenter dans toutes les requêtes et en indique la destination. Il est simplement copié dans les réponses.
• Via
  Le champ Via est utilisé pour enregistrer la route d’une requête, de manière à permettre aux serveurs SIP intermédiaires de faire suivre aux réponses un chemin exactement inverse.
• Encryption
  Ce champ d’entête spécifie que le corps du message et éventuellement certains entêtes ont été chiffrés.
• Content-Type
  Ce champ d’entête décrit le type de média contenu dans le corps du message.
• Content-Length
  Il s’agit du nombre d’octets du corps du message.

4 – Le fonctionnement de SIP

4.1 – Enregistrement d’un UA

Le schéma ci-dessous illustre l’enregistrement d’un téléphone SIP à son Registrar :

On retrouve classiquement les datagrammes de l’AE vers le RG représentant les requêtes et de droite à gauche représentant les réponses.

Voici un entete-sip echange sip enregistrement ae (195.7.101.157) auprès de son Registrar (195.7.101.1).

4.2 – Appel via un Proxy SIP/RTP

Le schéma ci-dessous illustre un échange entre un téléphone SIP et son Proxy :

Ce schéma prend le cas où c’est le Proxy qui termine la session en informant l’UE (Datagramme numéro 7). Il est bien sur possible que cela soit l’inverse et que ce soit donc l’UE qui décide de rompre la session. Dans ce cas, le sens des datagrammes 7 et 8 sera inversé.

Voici un entete-sip echange sip appel ae (195.7.101.157) auprès de son Proxy (195.7.101.1).

4.3 – Appel via Proxy SIP

Le schéma ci-dessous illustre un échange entre deux téléphones SIP via un Proxy :

Ce schéma montre le fonctionnement directe de SIP entre chaque AE et le Proxy. On remarquera, que par défaut, RTP est en peer to peer.

Voici un entete-sip echange sip appel ae proxy.  AE A (195.7.101.157), AE B (192.168.101.139) et PS Z (195.7.101.1).

5 – Annexe – Ensemble des codes réponses

Voici l’ensemble des codes réponses répertoriées par classe :

1xx Provisoire

Les réponses provisoires, aussi connues comme réponses informatives, indiquent que le serveur contacté est en train d’effectuer certaines actions et n’a pas encore de réponse définitive. Un serveur envoie une réponse 1xx si il s’attend à ce que l’obtention d’une réponse finale prenne plus de 200 ms. Noter que la transmission des réponses 1xx n’est pas fiable. Elle n’oblige jamais le client à envoyer un ACK. Les réponses provisoires (1xx) peuvent contenir un corps de message, y compris de description de session.

2xx Réussite

La demande a réussi.

3xx Réorientation

Les réponses 3xx donnent des informations sur la nouvelle localisation de l’utilisateur, ou sur des services de remplacement qui pourraient être capables de satisfaire à l’appel.

4xx Défaillance de la demande

Les réponses 4xx sont des réponses d’échec bien déterminées provenant d’un serveur particulier. Le client NE devrait PAS réessayer la même demande sans modification (par exemple, en ajoutant l’autorisation appropriée). Cependant, la même demande sur un serveur différent pourrait réussir.

5xx Défaillance de serveur

Les réponses 5xx sont des réponses d’échec qui indique que le serveur lui-même s’est trompé.

6xx Echecs totaux

Les réponses 6xx indiquent qu’un serveur a des informations certaines sur un utilisateur particulier, et non pas seulement sur l’instance particulière indiquée dans l’URI-de-demande.