Protocole SIP

Protocole SIP

1 – La définition du protocole SIP

SIP, signifiant Session Initiation Protocole, vient du monde de l’informatique contrairement aux autres. Le protocole SIP a été initié à l’origine par le groupe MMusic (Multiparty Multimedia Session Control) et est désormais géré par l’IETF (Internet Engeneering Task Force). Le protocole SIP est représenté principalement par la RFC 3261 « SIP: Session Initiation Protocol » qui est complété par l’ensemble des RFC suivantes :

  • 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 :

entete-sip entete sip message

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 :

entete-sip fonctionnement enregistrement ua

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 :

entete-sip appel proxy sip rtp

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 :

entete-sip appel proxy sip

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.

SIP 100 Essai Cette réponse indique que la demande a été reçue par le serveur du saut suivant et qu’une 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 182 En file d’attente Le demandé est temporairement indisponible, mais le serveur a décidé de mettre l’appel en file d’attente plutôt que de le rejeter. Lorsque l’appelé devient disponible, il retournera la réponse d’état finale appropriée. La phrase de cause peut donner plus de précisions sur l’état de l’appel, par exemple, « 5 appels en file d’attente ; le temps d’attente prévu est de 15 minutes ». Le serveur peut produire plusieurs réponses 182 (En file d’attente) pour tenir l’appelant au courant de l’état de l’appel en file d’attente.
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

2xx Réussite

La demande a réussi.

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

 

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.

SIP 300 Choix multiples L’adresse dans la demande peut se résoudre en plusieurs choix, chacun avec sa propre localisation spécifique, et l’utilisateur (ou agent utilisateur) peut choisir un point de terminaison de communication préféré et rediriger sa demande sur cette localisation.
La réponse peut inclure un corps de message contenant une liste de caractéristiques et localisation(s) de ressources à partir desquelles l’utilisateur ou agent utilisateur peut choisir la plus appropriée, si c’est permis par le champ d’entête Accept de la demande. Cependant, aucun type MIME n’a été défini pour ce corps de message.
Les choix devraient aussi être énumérés comme champs Contact. A la différence de HTTP, la réponse SIP peut contenir plusieurs champs Contact ou une liste d’adresses dans un champ Contact. Les agents d’utilisateur peuvent utiliser la valeur du champ d’entête Contact pour une redirection automatique ou peuvent demander à l’utilisateur de confirmer un choix. Cependant, la présente spécification ne définit aucune norme pour une telle sélection automatique.
Cette réponse d’état est appropriée si l’appelé peut être joint à plusieurs localisations différentes et le serveur ne peut pas ou préfère ne pas mandater la demande.
SIP 301 Déplacement définitif L’utilisateur ne peut plus être joint à l’adresse figurant dans l’URI-de-demande, et le client demandeur devrait réessayer à la nouvelle adresse donnée par le champ d’entête Contact. Le demandeur devrait mettre à jour tout répertoire local, carnet d’adresses, et mémoires caches de localisation d’utilisateur avec cette nouvelle valeur et rediriger les demandes futures sur la ou les adresses listées.
SIP 302 Temporairement déplacé Le client demandeur devrait réessayer la demande à la ou aux nouvelles adresses données par le champ d’entête Contact. L’URI-de-demande de la nouvelle demande utilise la valeur du champ d’entête Contact dans la réponse.

La durée de validité de l’URI Contact peut être indiquée par un champ d’entête Expires ou un paramètre expires dans le champ d’entête Contact. Les mandataires et les agents d’utilisateur peuvent tous deux mettre cet URI en mémoire cache pour la durée du délai d’expiration. Si il n’y a pas de délai d’expiration explicite, l’adresse n’est valide pour recommencer qu’une seule fois, et NE doit PAS être cachée pour des transactions ultérieures.

Si l’URI caché tiré du champ d’entête Contact échoue, l’URI-de-demande de la demande redirigée peut être essayé encore une seule fois.

L’URI temporaire peut être périmé plus tôt que le délai d’expiration, et un nouvel URI temporaire peut être disponible.

SIP 305 Utiliser un mandataire On doit accéder à la ressource demandée par l’intermédiaire du mandataire donné par le champ Contact. Le champ Contact donne l’URI du mandataire. Le receveur est censé répéter cette seule demande via le mandataire. Les réponses 305 (Utiliser un mandataire) DOIVENT être générées par les seuls UAS.
SIP 380 Service de remplacement L’appel n’a pas réussi, mais des services de remplacement sont possibles.

Les services de remplacement sont décrits dans le corps de message de la réponse. Les formats pour de tels corps ne sont pas définis ici, et pourront être le sujet d’une normalisation future.

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.

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 402 Payement exigé Réservé pour utilisation future.
SIP 403 Interdit Le serveur comprend la demande, mais refuse d’y satisfaire. L’autorisation n’y fera rien, et la demande NE devrait PAS être répétée.
SIP 404 Pas trouvé Le serveur a des informations certaines que l’utilisateur n’existe pas au 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 405 Méthode non autorisée La méthode spécifiée dans la ligne de demande est comprise, mais non autorisée pour l’adresse identifiée par l’URI-de-demande.

La réponse doit inclure un champ d’entête Allow contenant une liste de méthodes valides pour l’adresse indiquée.

SIP 406 Non acceptable La ressource identifiée par la demande est seulement capable de générer des entités de réponse qui ont des caractéristiques de contenu non acceptables en fonction du champ d’entête Accept envoyé dans la demande.
SIP 407 Authentification du mandataire requise Ce code est similaire à 401 (Non autorisé), mais indique que le client doit d’abord s’authentifier avec le mandataire.

Ce code d’état peut être utilisé pour des applications où, plutôt que le demandé, l’accès au canal de communication (par exemple, une passerelle de téléphonie) exige l’authentification.

SIP 408 Expiration du délai de demande Le serveur n’a pas pu produire une réponse dans le délai requis, par exemple, s’il n’a pas pu déterminer la localisation de l’utilisateur dans les temps. Le client peut répéter la demande sans modifications à tout moment ultérieurement.
SIP 410 Parti La ressource demandée n’est plus disponible au serveur et aucune adresse de retransmission n’est connue. Cette condition est supposée être permanente. Si le serveur ne connaît pas, ou n’ aucune facilite pour déterminer si la condition est permanente ou non, c’est le code d’état 404 (Non trouvé) qui devrait être utilisé à la place.
SIP 412 Conditional Request Failed  
SIP 413 Entité de demande trop longue Le serveur refuse de traiter une demande parce que l’entité corps de la demande est supérieure à ce que le serveur est désireux ou capable de traiter. Le serveur peut fermer la connexion pour empêcher le client de continuer la demande.
Si la condition est temporaire, le serveur devrait inclure un champ d’entête Retry-After pour indiquer qu’elle est temporaire et après quel délai le client peut réessayer.
SIP 414 URI de demande trop long Le serveur refuse de servir la demande car l’URI-de-demande est plus long que ce que le serveur désire interpréter.
SIP 415 Type de support non accepté Le serveur refuse de servir la demande parce que le corps de message de la demande est dans un format qui n’est pas accepté par le serveur pour la méthode demandée. Le serveur doit retourner une liste de formats acceptables en utilisant les champs d’entête Accept, Accept-Encoding, ou Accept-Language, selon le problème spécifique du contenu.
SIP 416 Schéma d’URI non accepté Le serveur ne peut pas traiter la demande parce que le schéma de l’URI dans l’URI-de-demande est inconnu du serveur.
SIP 417 Unknown Resource-Priority  
SIP 420 Mauvaise extension Le serveur n’a pas compris l’extension de protocole spécifiée dans un champ d’entête Proxy-Require ou Require. Le serveur doit inclure une liste des extensions non prises en charge dans un champ d’entête Unsupported dans la réponse.
SIP 421 Extension requise L’UAS a besoin d’une extension particulière pour traiter la demande, mais cette extension ne figure pas dans la liste du champ d’entête Supported dans la demande. Les réponses avec ce code d’état DOIVENT contenir un champ d’entête Require faisant la liste des extensions requises.

Un UAS NE devrait utiliser cette réponse que s’il ne peut vraiment fournir aucun service utile au client. Au lieu de cela, si une extension souhaitable ne figure pas sur la liste du champ d’entête Supported, les serveurs devraient traiter la demande en utilisant les capacités SIP de base et toute extension acceptée par le client.

SIP 422 Session Interval Too Small  
SIP 423 Intervalle trop bref Le serveur rejette la demande parce que le délai d’expiration des ressources rafraîchi par la demande est trop court. Cette réponse peut être utilisée par un registraire pour rejeter un enregistrement dont le délai d’expiration du champ d’entête Contact est trop bref.
428 Use Identity Header  
429 Provide Referrer Identity  
433 Anonymity Disallowed  
436 Bad Identity-Info  
437 Unsupported Certificate  
438 Invalid Identity Header  
440 Max-Breadth Exceeded  
470 Consent Needed  
SIP 480 Temporairement indisponible Le système de terminaison du demandé a été contacté avec succès mais le demandé est actuellement indisponible (par exemple, il n’est pas enregistré, ou bien il est enregistré mais se trouve dans un état qui empêche les communications avec l’appelé, ou il a activé le dispositif « ne pas déranger »). La réponse peut indiquer un meilleur moment pour appeler dans le champ d’entête Retry-After. L’utilisateur peut aussi être disponible ailleurs (à l’insu de ce serveur). La phrase de cause devrait indiquer une raison plus précise comme pourquoi l’appelé est indisponible. Cette valeur devrait être réglable par l’agent utilisateur. L’état 486 (Occupé ici) peut être utilisé pour indiquer plus précisément une raison particulière pour l’échec de l’appel.

Cet état est aussi retourné par une redirection ou un serveur mandataire qui reconnaît l’utilisateur identifié par l’URI-de-demande, mais n’a pas actuellement de localisation de retransmission valide pour cet utilisateur.

SIP 481 L’appel/transaction n’existe pas Cet état indique que l’UAS a reçu une demande qui ne correspond à aucun dialogue ou transaction existant.
SIP 482 Boucle détectée Le serveur a détecté une boucle.
SIP 483 Trop de bonds Le serveur a reçu une demande qui contient un champ d’entête Max-Forwards avec la valeur zéro.
SIP 484 Adresse incomplète Le serveur a reçu une demande avec un URI-de-demande incomplet. Des informations supplémentaires devraient être fournies dans la phrase de cause.

Ce code d’état permet la numérotation en recouvrement. Avec la numérotation en recouvrement, le client ne connaît pas la longueur de la chaîne de numérotation. Il envoie des chaînes de longueur croissante, pressant l’utilisateur d’envoyer des entrées supplémentaires, jusqu’à ce qu’il ne reçoive plus de réponse d’état 484 (Adresse incomplète).

SIP 485 Ambiguïté L’URI-de-demande est ambigu. La réponse peut contenir une liste d’adresses possibles non ambiguës dans le champ d’entête Contact. Révéler les solutions de remplacement peut porter une atteinte à la vie privée de l’utilisateur ou de l’organisation. Il doit être possible de configurer un serveur pour qu’il réponde par l’état 404 (Pas trouvé) ou de supprimer la liste des choix possibles pour les URI-de-demande ambigus.

Exemple de réponse à une demande avec l’URI-de-demande sip:lee@example.com :
SIP/2.0 485 Ambigu
Contact: Carol Lee <sip:carol.lee@example.com>
Contact: Ping Lee <sip:p.lee@example.com>
Contact: Lee M. Foote <sips:lee.foote@example.com>

Certains systèmes de messagerie électronique et de messagerie vocale fournissent cette fonction. Un code d’état distinct de 3xx est utilisé dans la mesure où les sémantiques sont différentes : pour 300, il est supposé que la même personne ou service sera joint par les choix fournis. Alors qu’un choix automatisé ou une recherche séquentielle a un sens pour une réponse 3xx, une intervention de l’utilisateur est requise pour une réponse 485 (Ambigu).

SIP 486 Occupé ici Le système de terminaison de l’appelé a été contacté avec succès, mais l’appelé ne peut ou ne veut pas actuellement prendre un appel supplémentaire sur ce système de terminaison. La réponse peut indiquer un meilleur moment pour appeler dans le champ d’entête Retry-After. L’utilisateur pourrait aussi être disponible ailleurs, comme sur un service de messagerie vocale. L’état 600 (Occupé partout) devrait être utilisé si le client sait qu’aucun autre système de terminaison ne sera capable d’accepter cet appel.
SIP 487 Demande terminée La demande a été terminée par un BYE ou une demande CANCEL. Cette réponse n’est jamais retournée pour une demande CANCEL elle-même.
SIP 488 Non acceptable ici La réponse a la même signification que 606 (Non acceptable), mais s’applique seulement aux ressources spécifiques adressées par l’URI-de-demande et la demande peut réussir ailleurs.

Un corps de message qui contient une description de capacités support peut être présente dans la réponse, qui est formatée conformément au champ d’entête Accept dans l’INVITE (ou l’application/sdp si il n’est pas présent), comme un corps de message dans une réponse 200 (OK) à une demande OPTIONS.

489 Bad Event  
SIP 491 Demande en cours La demande a été reçue par un UAS qui avait une demande en cours dans le même dialogue.
SIP 493 Indéchiffrable La demande a été reçue par un UAS qui contenait un corps MIME chiffré pour lequel le receveur ne possède pas ou ne fournira pas de clé de déchiffrement appropriée. Cette réponse peut avoir un seul corps contenant une clé publique appropriée qui devrait être utilisée pour chiffrer les corps MIME envoyés à cet agent utilisateur.
494 Security Agreement Required  

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é.

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 501 Non mis en oeuvre Le serveur ne prend pas en charge la fonctionnalité requise pour satisfaire la demande. C’est la réponse appropriée lorsqu’un UAS ne reconnaît pas la méthode de demande et n’est pas capable de la prendre en charge pour les utilisateurs. (Les mandataires transmettent toutes les demandes sans considération de la méthode.)

Noter qu’une réponse 405 (Méthode non admise) est envoyée lorsque le serveur reconnaît la méthode de demande, mais que cette méthode est non autorisée ou non prise en charge.

SIP 502 Mauvaise passerelle Le serveur, alors qu’il agit comme une passerelle ou un mandataire, a reçu une réponse invalide de la part du serveur aval auquel il a accédé en essayant de satisfaire la demande.
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).

SIP 504 Expiration du délai de serveur Le serveur n’a pas reçu de réponse dans les temps d’un serveur externe auquel il a accédé en essayant de traiter la demande. La réponse 408 (Expiration du délai de réponse) devrait être utilisée à la place s’il n’y a pas de réponse dans la période spécifiée dans le champ d’entête Expires de la part du serveur amont.
SIP 505 Version non acceptée Le serveur ne prend pas en charge, ou refuse de prendre en charge, la version de protocole SIP qui a été utilisée dans la demande. Le serveur indique qu’il n’est pas en mesure ou ne veut pas achever la demande en utilisant la même version majeure que le client, autrement qu’avec ce message d’erreur.
SIP 513 Message trop long Le serveur n’a pas été capable de traiter la demande car la longueur du message excède ses capacités.
580 Precondition Failure  

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.

SIP 600 Occupé partout Le système de terminaison de l’appelé a été contacté avec succès mais l’appelé est occupé et ne souhaite pas prendre l’appel en ce moment. La réponse peut indiquer un meilleur moment pour appeler dans le champ d’entête Retry-After. Si l’appelé ne souhaite pas révéler la raison pour laquelle il décline l’appel, il utilise à la place le code d’état 603 (Refus). Cette réponse d’état n’est retournée que si le client sait qu’aucun autre point d’extrémité (tel qu’une messagerie vocale) ne répondra à la demande. Autrement, 486 (Occupé ici) devrait être retournée.
SIP 603 Refus La machine de l’appelé a été contactée avec succès mais l’utilisateur souhaite explicitement ne pas participer , ou ne le peut pas. La réponse peut indiquer un meilleur moment pour appeler dans le champ d’entête Retry-After. Cette réponse d’état n’est retournée que si le client sait qu’aucun autre point d’extrémité ne répondra à la demande.
SIP 604 N’existe nulle part Le serveur a des informations certaines que l’utilisateur indiqué dans l’URI-de-demande n’existe nulle part.
SIP 606 Non acceptable L’agent d’utilisateur a été contacté avec succès mais certains aspects de la description de session, tels que le support demandé, la bande passante, ou le style d’adressage ne sont pas acceptables.

Une réponse 606 (Non acceptable) signifie que l’utilisateur souhaite communiquer, mais ne peut pas prendre en charge de façon adéquate la session décrite. La réponse 606 (Non acceptable) peut contenir une liste des raisons dans un champ d’entête Warning décrivant pourquoi la session décrite ne peut être prise en charge.

Un corps de message contenant une description des capacités support peut être présente dans la réponse, et elle est formatée conformément au champ d’entête Accept dans l’INVITE (ou l’application/sdp si elle n’est pas présente), identique au corps de message dans une réponse 200 (OK) à une demande OPTIONS.

Il est souhaité qu’il ne soit pas trop fréquemment nécessaire de recourir à la négociation, et quand un nouvel utilisateur est invité à se joindre à une conférence déjà existante, la négociation peut n’être pas possible. Il appartient à l’initiateur de l’invitation de décider d’agir ou non par une réponse 606 (Non acceptable).

Cette réponse d’état n’est retournée que si le client sait qu’aucun autre point d’extrémité ne répondra à la demande.

6 – Les vidéos

  • 6.1 - RFC 3261 Simplified: SIP Part-Seven Vidéo en Anglais

    RFC 3261, Session Initiation Protocol, is a very dry document. It is hard to read and hard to understand. In this RFC 3261 Simplified series, we are going to use examples and analogies to explain RFC 3261, Session Initiation Protocol, in a language that will appeal to a wide spectrum of audience. In this tutorial, we are focusing on INVITE request, discuss the difference between a dialog & a session, and go over re-INVITE request using sample calls and analogies.

    RFC 3261 Simplified: SIP Part-Seven

  • 6.2 - RFC 3261 Simplified: SIP Part-Six Vidéo en Anglais

    RFC 3261, Session Initiation Protocol, is a very dry document. It is hard to read and hard to understand. In this RFC 3261 Simplified series, we are going to use examples and analogies to explain RFC 3261, Session Initiation Protocol, in a language that will appeal to a wide spectrum of audience. In the previous tutorial, we covered the CANCEL request and now, in part VI, will be diving into the REGISTER request with examples to understand the concepts better.

    RFC 3261 Simplified: SIP Part-Six

  • 6.3 - RFC 3261 Simplified: SIP Part-Five Vidéo en Anglais

    RFC 3261, Session Initiation Protocol, is a very dry document. It is hard to read and hard to understand. In this RFC 3261 Simplified series, we are going to use examples and analogies to explain RFC 3261, Session Initiation Protocol, in a language that will appeal to a wide spectrum of audience. By the end of RFC 3261 Simplified series part IV, we were done with method independent processes on both UAC & UAS sides. In this tutorial, part V, we will be going into details about the CANCEL method with examples to understand the concepts better.

    RFC 3261 Simplified: SIP Part-Five

  • 6.4 - RFC 3261 Simplified: SIP Part-Four Vidéo en Anglais

    RFC 3261, Session Initiation Protocol, is a very dry document. It is hard to read and hard to understand. In this RFC 3261 Simplified series, we are going to use examples and analogies to explain RFC 3261, Session Initiation Protocol, in a language that will appeal to a wide spectrum of audience. In part IV, we focus on the UAS side and go over the initial method independent steps a UAS follows to process a request; Authentication, Method Inspection, Header Inspection, Content Processing, and Applying Extensions.

    RFC 3261 Simplified: SIP Part-Four

  • 6.5 - RFC 3261 Simplified: SIP Part-Three Vidéo en Anglais

    RFC 3261, Session Initiation Protocol, is a very dry document. It is hard to read and hard to understand. In this RFC 3261 Simplified series, we are going to use examples and analogies to explain RFC 3261, Session Initiation Protocol, in a language that will appeal to a wide spectrum of audience. This is part III where we create a SIP trapezoid with Repro SIP proxies to go over a sample call to discuss how the requests are sent out and what responses are expected per RFC 3261.

  • 6.6 - RFC 3261 Simplified: SIP Part-Two Vidéo en Anglais

    RFC 3261, Session Initiation Protocol, is a very dry document. It is hard to read and hard to understand. In this RFC 3261 Simplified series, we are going to use examples and analogies to explain RFC 3261, Session Initiation Protocol, in a language that will appeal to a wide spectrum of audience. This is part II in which we go over SIP messages and analyze the sample call from Part I to discuss the mandatory Start-Line and Message-Header sections of SIP messages.

    RFC 3261 Simplified: SIP Part-Two

  • 6.7 - RFC 3261 Simplified: SIP Part-One Vidéo en Anglais

    RFC 3261, Session Initiation Protocol, is a very dry document. It is hard to read and hard to understand. In this RFC 3261 Simplified series, we are going to use examples and analogies to explain RFC 3261, Session Initiation Protocol, in a language that will appeal to a wide spectrum of audience. This is part I in which we go over an introduction to SIP, followed by a sample call capture and analysis of the messages in that sample call.

    RFC 3261 Simplified: SIP Part-One

  • 6.8 - SIP Proxy Server Vidéo en Anglais

    Cette vidéo en anglais présente le proxy SIP (Session Initiation Protocol).

    SIP Proxy Server

  • 6.9 - Learn about SIP Transactions and Dialogs Vidéo en Anglais

    Ohh.. you want to understand SIP do you? You better get the basics down before you even think about troubleshooting a call flow. In this video we cover the fundamentals of SIP Transactions and Dialogs.

    Learn about SIP Transactions and Dialogs

  • 6.10 - Detect SIP Errors with Wireshark Vidéo en Anglais

    Cette vidéo en anglais vous montre comment débugger le protocole SIP (Session Initiation Protocol). Create a filter expression button based on the sip.Status-Code field to quickly locate SIP errors in your trace files.

    Detect SIP Errors with Wireshark

  • 6.11 - SIP Troubleshooting Vidéo en Anglais

    Cette vidéo en anglais vous présente le protocole SIP (Session Initiation Protocol) via l'outil d'analyse de trame Wireshark. This video is a breakdown of a wireshark trace that captured an outgoing call between a PBX and an ITSP (SIP Provider). It will be one part of a series of videos designed to give a better understanding of the SIP protocol.

    SIP Troubleshooting

  • 6.12 - SIP with Wireshark Vidéo en Anglais

    Cette vidéo en anglais vous présente le protocole SIP (Session Initiation Protocol) via l'outil d'analyse de trame Wireshark. SIP is an application-layer control protocol that can establish, modify, and terminate multimedia sessions such as Internet telephony calls. This video will demonstrate SIP Packets flow in Wireshark, SIP Register, INVITE.

    SIP with Wireshark

7 – Suivi du document

Création et suivi de la documentation par _SebF

8 – Discussion autour du protocole SIP

Vous pouvez poser toutes vos questions, faire part de vos remarques et partager vos expériences à propos du protocole SIP. Pour cela, n’hésitez pas à laisser un commentaire ci-dessous :

Commentaire et discussion

7 commentaires sur la page : “Protocole SIP”

  1. Bonjour,
    J’aimerais savoir ou est-ce-que le protocole sip se situe au modele osi?
    En partant sur le fait que sip initie, maintient et ferme des session, j’ai considere que sip est un protocole de niveau 5 du modele osi.
    Mais partout on dit que sip est un protocole de niveau 7 (application).
    Pouvez-vous m’expliquer s’il vous plait comment ca se fait qu’il soit de niveau 7?

    1. Lu,

      Ton raisonnement est bon.
      Pour répondre à ta question, c’est bien en couche 7, car le modèle OSI est un modèle de référence. Celui que tu doit utiliser est TCP/IP.
      Tu comprendras la réponse quand tu auras intégré le modèle TCP/IP dans OSi 🙂

      @+
      Seb

  2. Bonjour,

    Existe t’il un protocole ou un moyen de lancer un appel vidéo partir d’une page web mobile; sans que le client n’ai au préalable télécharger d’application spécifique sur son smartphone ( Android et/ou IOS ).

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *