VI.

SIP- Session Initiation Protocol

Le protocole SIP de l’IETF, est un protocole de signalisation pour l’établissement d’appel et de

conférences temps réel sur des réseaux IP. Proposé comme standard à l’IETF en 1999, SIP est
rapidement apparu comme une alternative à H.323.
Chaque communication doit pouvoir inclure différents types de données telles que l’audio et la
vidéo. SIP est indépendant du protocole de transport utilisé. Il utilise le protocole SDP (Session
Description Protocol) pour la description des communications média.
Les terminaux peuvent communiquer directement entre eux ou par l'intermédiaire d'autres serveurs.

1. Adressage

SIP est un protocole standardisé qui permet l'initiation, la modification et la fin de sessions
multimédias interactives entre deux ou plusieurs participants sur un réseau IP. L'adressage SIP utilise
des identificateurs appelés URI (Uniform Resource Identifier) pour localiser les utilisateurs et les
services.

URI SIP : Les adresses SIP sont souvent appelées URI SIP. Un URI SIP ressemble à une adresse e-
mail, mais il est utilisé pour identifier des ressources ou des utilisateurs dans le contexte des
communications en temps réel. Par exemple, sip:utilisateur@[Link] est un URI SIP.
 Parties de l'URI SIP :
 sip: : Indique qu'il s'agit d'un URI SIP.
 utilisateur : Identifie l'utilisateur ou l'entité.
 @ : Sépare l'utilisateur du domaine.
 [Link] : Indique le domaine où l'utilisateur est enregistré.
Exemple d'URI SIP : sip:alice@[Link] : Cela indique l'URI SIP pour l'utilisateur Alice
dans le domaine "[Link]".
 Utilisation dans les requêtes SIP :
Lorsqu'un utilisateur souhaite initier une session, son client SIP envoie une requête INVITE à l'URI
SIP de la partie avec laquelle il souhaite communiquer.
 Utilisation dans les réponses SIP :
Lorsque la partie destinataire reçoit la requête, elle répond par une série de messages SIP, comme
"100 Trying", "180 Ringing", et finalement "200 OK" si la session est établie avec succès.
L'adressage SIP permet donc aux participants d'initier des sessions de communication et de se trouver
sur le réseau, facilitant ainsi la mise en place de connexions multimédias via des protocoles.

1
Remarque
Les termes "URL" (Uniform Resource Locator) et "URI" (Uniform Resource Identifier) sont
étroitement liés mais ont des significations légèrement différentes. URI (Uniform Resource
Identifier) : C'est un terme plus général qui englobe les URL.
URL (Uniform Resource Locator) : C'est un type spécifique d'URI qui fournit l'adresse complète
d'une ressource sur Internet. Une URL indique comment récupérer la ressource, qu'il s'agisse d'une
page Web, d'un fichier, d'une image, etc. Une URL comprend généralement le schéma (comme "http"
ou "https"), le nom de domaine, le chemin d'accès et parfois des informations spécifiques sur la
ressource (comme un numéro de port ou une ancre).
2. Localisation d’un usager

La localisation physique d’un usager s’effectue en deux étapes. L’URL SIP permet à l’usager
appelant de localiser le SIP server. Celui-ci sera la destination du message « Invite » initial.
 Soit le serveur connaît l’adresse physique de l’usager appelé et il permettra l’établissement
d’une connexion,
 soit il redirige la requête vers un autre lieu où il sait que l’appelé pourra être joint.
Le fait que l’URL SIP pointe sur un serveur et non sur l’usager terminal donne à ce dernier une
plus grande mobilité. Cela permet aussi de soulager le serveur DNS (Domain Name Service) qui
n’a qu’à connaître l’adresse du serveur et non de tous les terminaux reliés au serveur.
3. Etablissement d’appel SIP directement de terminal à terminal

Un client SIP peut contacter un autre terminal SIP en envoyant une simple requête « Invite ». Ce
message « Invite » contient assez d’informations pour permettre au terminal appelé d’établir une
communication média avec l’appelant. Ces informations listent les différents types de média que
l’appelant peut recevoir et envoyer, ainsi que l’adresse transport (adresse IP et port) sur laquelle
l’appelé pourra établir la connexion média utilisant le protocole RTP. Le terminal appelé doit alors
indiquer qu’il accepte la demande.
 Comme la requête était une invitation, l’acceptation du demandé (OK message) contient aussi
ses capacités ainsi que l’adresse sur laquelle il attend les données média.
 L’appelant conclut cet échange pour un message d’acquittement (ACK message).Une
communication média peut donc être établie en un aller-retour et demi ce qui permet un
établissement de connexion très rapide par rapport à H.323 v1 (6 à 7 aller-retour).

Initiation d’un appel avec le protocole SIP

2
 4. L’architecture du protocole SIP
L'architecture de SIP est basée sur des relations client/serveur. Les principales composantes sont le
terminal (User Agent), le Proxy Server, le Redirect Server et le Registrar.

 Les terminaux sont considérés comme clients lorsqu'ils effectuent une requête, et comme des
serveurs lorsqu'ils y répondent. Les terminaux peuvent communiquer directement entre eux
ou par l'intermédiaire d'autres serveurs.
Les serveurs SIP intermédiaires peuvent se comporter comme proxy serveur ou serveur de
redirection (redirect server).
 Le proxy server joue le rôle de serveur d’un côté (réception de requête) et de client de l’autre
(envoi de requête). Un proxy server peut transmettre une requête, sans changement, à la
destination finale ou éventuellement modifier certains paramètres.

 Un redirect server répond à une requête SIP « Invite ». Il établit la correspondance entre
l’adresse SIP du terminal appelé et la ou les adresses où il pourra effectivement être joignable.
Le redirect server n’est pas chargé d’accepter les appels ni d’émettre des requêtes. Il ne fait que
répondre aux requêtes émises par des terminaux SIP appelants.

 Registrar server :Un registrar est un serveur qui traite les requêtes « Register » et peut
aussi avoir la fonction de proxy. Sa fonction est de connaître l’endroit où se trouve un
usager et de fournir cette information au proxy et au redirect server. En effet pour
pouvoir joindre un usager à partir d’une adresse SIP, il faut faire une correspondance
avec une adresse IP qui peut être variable (mobilité IP) : c’est le rôle du registrar.

3
 Par exemples :

 Réponse 300 _ l’URL SIP peut être contactée à différentes adresses (ex: sip:
robert_gsm@[Link], sip:robert_home@[Link])
 Réponse 301 _ l’URL SIP ne peut plus être contactée à première adresse mais à la nouvelle
adresse indiquée
 Réponse 302 _ redirection du client vers une adresse mais de façon provisoire.
5. Session Description Protocol (SDP)

Le protocole SDP est un protocole qui décrit les sessions audio, vidéo et multimédia. SDP utilise
des caractères ASCII (American Standard Code for Information Interchange) et donne les
informations nécessaires à l’établissement d’une communication multimédia telles que l’identité
de l’initiateur de la session, la bande passante disponible, les codeurs utilisés.
6. Les requêtes
Les échanges client-serveur se font à l’aide de requêtes dont voici le détail de chacun des messages :

 INVITE 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 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 :
o le tag de l’URL TO de la requête ACK est égal au tag de l’URL TO de la réponse
o l’URL FROM, le CALL-ID et le Cseq de la requête ACK sont égaux à ceux de la
réponse.

4
 OPTIONS 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 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 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 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
5
 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.
 INFOInformation de session en cours.
 MESSAGE Permettre l’envoi de messages instantanés.
 NOTIFYEnvoyer des notifications d’événements.
 PRACK Implémenter le mécanisme spécial de sécurisation des réponses provisoires.
 REFER Permettre la redirection d’appels.
 SUSCRIBE Demander une notification d’événements.
 UPDATE

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

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
SIP
Essai toutes les autres réponses provisoires, arrête les retransmissions d’un INVITE
100
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.

L’agent utilisateur qui reçoit l’INVITE est en train d’essayer d’alerter

SIP Sonnerie en
l’utilisateur. Cette réponse peut être utilisée pour initialiser la sonnerie de retour
180 cours
d’appel locale.

L’appel est
SIP Un serveur peut utiliser ce code d’état pour indiquer que l’appel est en train
en cours de
181 d’être retransmis à un ensemble de destinations différent.
transmission

SIP En file Le demandé est temporairement indisponible, mais le serveur a décidé de mettre
182 d’attente l’appel en file d’attente plutôt que de le rejeter. Lorsque l’appelé devient

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

La réponse 183 (Avancement de la session) est utilisée pour porter des

SIP Avancement informations sur la progression de l’appel qui n’est pas autrement classifiée. La
183 de la session 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 La demande a réussi. Les informations retournées avec la réponse dépendent de la

OK
200 méthode utilisée dans la demande.

SIP Accepted
202
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.

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.
SIP
Choix multiples Les choix devraient aussi être énumérés comme champs Contact. A la
300
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 Déplacement L’utilisateur ne peut plus être joint à l’adresse figurant dans l’URI-de-
301 définitif 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

7
 d’utilisateur avec cette nouvelle valeur et rediriger les demandes futures
sur la ou les adresses listées.

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
SIP Temporairement URI en mémoire cache pour la durée du délai d’expiration. Si il n’y a pas
302 déplacé 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.

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
SIP Utiliser un
mandataire. Le receveur est censé répéter cette seule demande via le
305 mandataire
mandataire. Les réponses 305 (Utiliser un mandataire) DOIVENT être
générées par les seuls UAS.

L’appel n’a pas réussi, mais des services de remplacement sont possibles.
SIP Service de Les services de remplacement sont décrits dans le corps de message de la
380 remplacement 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.

La demande n’a pas pu être comprise à cause d’une syntaxe mal

SIP
Mauvaise demande formée. La phrase de cause devrait identifier le problème de syntaxe
400
plus en détail, par exemple, « Champ d’entête Call-ID manquant ».

La demande exige une authentification de l’utilisateur. Cette réponse

SIP est produite par les UAS et registraires, alors que la réponse 407
Non autorisé
401 (Authentification du mandataire exigée) est utilisée par les serveurs
mandataires.

SIP Payement exigé Réservé pour utilisation future.

8
402

Le serveur comprend la demande, mais refuse d’y satisfaire.

SIP
Interdit L’autorisation n’y fera rien, et la demande NE devrait PAS être
403
répétée.

Le serveur a des informations certaines que l’utilisateur n’existe pas

SIP au domaine spécifié dans l’URI-de-demande. Cet état est aussi
Pas trouvé
404 retourné si le domaine dans l’URI-de-demande ne correspond à aucun
des domaines traités par le receveur de la demande.

La méthode spécifiée dans la ligne de demande est comprise, mais non

SIP Méthode non autorisée pour l’adresse identifiée par l’URI-de-demande.
405 autorisée La réponse doit inclure un champ d’entête Allow contenant une liste
de méthodes valides pour l’adresse indiquée.

La ressource identifiée par la demande est seulement capable de

SIP générer des entités de réponse qui ont des caractéristiques de contenu
Non acceptable
406 non acceptables en fonction du champ d’entête Accept envoyé dans la
demande.

Ce code est similaire à 401 (Non autorisé), mais indique que le client
doit d’abord s’authentifier avec le mandataire.
SIP Authentification du Ce code d’état peut être utilisé pour des applications où, plutôt que le
407 mandataire requise demandé, l’accès au canal de communication (par exemple, une
passerelle de téléphonie) exige l’authentification.

Le serveur n’a pas pu produire une réponse dans le délai requis, par
SIP Expiration du délai exemple, s’il n’a pas pu déterminer la localisation de l’utilisateur dans
408 de demande les temps. Le client peut répéter la demande sans modifications à tout
moment ultérieurement.

La ressource demandée n’est plus disponible au serveur et aucune

adresse de retransmission n’est connue. Cette condition est supposée
SIP
Parti être permanente. Si le serveur ne connaît pas, ou n’ aucune facilite
410
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 Conditional
412 Request Failed

SIP Entité de demande Le serveur refuse de traiter une demande parce que l’entité corps de la
413 trop longue 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

9
 d’entête Retry-After pour indiquer qu’elle est temporaire et après quel
délai le client peut réessayer.

SIP URI de demande Le serveur refuse de servir la demande car l’URI-de-demande est plus
414 trop long long que ce que le serveur désire interpréter.

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
SIP Type de support pour la méthode demandée. Le serveur doit retourner une liste de
415 non accepté formats acceptables en utilisant les champs d’entête Accept, Accept-
Encoding, ou Accept-Language, selon le problème spécifique du
contenu.

SIP Schéma d’URI non Le serveur ne peut pas traiter la demande parce que le schéma de
416 accepté l’URI dans l’URI-de-demande est inconnu du serveur.

SIP Unknown
417 Resource-Priority

Le serveur n’a pas compris l’extension de protocole spécifiée dans un

SIP Mauvaise champ d’entête Proxy-Require ou Require. Le serveur doit inclure une
420 extension liste des extensions non prises en charge dans un champ d’entête
Unsupported dans la réponse.

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
SIP extensions requises.
Extension requise Un UAS NE devrait utiliser cette réponse que s’il ne peut vraiment
421
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 Session Interval

422 Too Small

Le serveur rejette la demande parce que le délai d’expiration des

SIP ressources rafraîchi par la demande est trop court. Cette réponse peut
Intervalle trop bref
423 ê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.

SIP Temporairement Le système de terminaison du demandé a été contacté avec succès

480 indisponible 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

10
 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 L’appel/transaction Cet état indique que l’UAS a reçu une demande qui ne correspond à
481 n’existe pas aucun dialogue ou transaction existant.

SIP
Boucle détectée Le serveur a détecté une boucle.
482

SIP Le serveur a reçu une demande qui contient un champ d’entête Max-
Trop de bonds
483 Forwards avec la valeur zéro.

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
SIP numérotation en recouvrement, le client ne connaît pas la longueur de
Adresse incomplète
484 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 Ambiguïté L’URI-de-demande est ambigu. La réponse peut contenir une liste
485 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@[Link] :
SIP/2.0 485 Ambigu
Contact: Carol Lee <sip:[Link]@[Link]>
Contact: Ping Lee <sip:[Link]@[Link]>
Contact: Lee M. Foote <sips:[Link]@[Link]>
Certains systèmes de messagerie électronique et de messagerie vocale

11
 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).

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
SIP indiquer un meilleur moment pour appeler dans le champ d’entête
Occupé ici
486 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.

La demande a été terminée par un BYE ou une demande CANCEL.

SIP
Demande terminée Cette réponse n’est jamais retournée pour une demande CANCEL
487
elle-même.

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.
SIP Un corps de message qui contient une description de capacités support
Non acceptable ici peut être présente dans la réponse, qui est formatée conformément au
488
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.

SIP La demande a été reçue par un UAS qui avait une demande en cours
Demande en cours
491 dans le même dialogue.

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
SIP
Indéchiffrable clé de déchiffrement appropriée. Cette réponse peut avoir un seul
493
corps contenant une clé publique appropriée qui devrait être utilisée
pour chiffrer les corps MIME envoyés à cet agent utilisateur.

Security
494 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 Erreur Le serveur a rencontré une condition inattendue qui l’a empêché de satisfaire

12
 la demande. Le client peut afficher la condition d’erreur spécifique et peut
interne du réessayer la demande après plusieurs secondes.
500 Si la condition est temporaire, Le serveur peut indiquer quand le client peut
serveur
réessayer la demande en utilisant le champ d’entête Retry-After.

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
SIP Non mis en utilisateurs. (Les mandataires transmettent toutes les demandes sans
501 oeuvre 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.

Le serveur, alors qu’il agit comme une passerelle ou un mandataire, a reçu

SIP Mauvaise
une réponse invalide de la part du serveur aval auquel il a accédé en essayant
502 passerelle
de satisfaire la demande.

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).
SIP Service Un client (mandataire ou UAC) recevant une 503 (Service indisponible)
503 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).

Le serveur n’a pas reçu de réponse dans les temps d’un serveur externe
Expiration auquel il a accédé en essayant de traiter la demande. La réponse 408
SIP
du délai de (Expiration du délai de réponse) devrait être utilisée à la place s’il n’y a pas
504
serveur de réponse dans la période spécifiée dans le champ d’entête Expires de la
part du serveur amont.

Le serveur ne prend pas en charge, ou refuse de prendre en charge, la version

SIP Version non de protocole SIP qui a été utilisée dans la demande. Le serveur indique qu’il
505 acceptée 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 Message Le serveur n’a pas été capable de traiter la demande car la longueur du
513 trop long message excède ses capacités.

580 Precondition

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

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
SIP Occupé d’entête Retry-After. Si l’appelé ne souhaite pas révéler la raison pour
600 partout 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.

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
SIP
Refus un meilleur moment pour appeler dans le champ d’entête Retry-After. Cette
603
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 N’existe Le serveur a des informations certaines que l’utilisateur indiqué dans l’URI-
604 nulle part de-demande n’existe nulle part.

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
SIP Non
d’entête Accept dans l’INVITE (ou l’application/sdp si elle n’est pas
606 acceptable
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.

14
 8. 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.

Un message SIP peut être à la

fois une requête d’un client
(terminal appelant) vers un
serveur (terminal appelé), ou
une réponse d’un serveur vers

un client.

15
Exemples

16
 VII. RTP et RTCP pour le transport de données en temps réel

Le protocole IP permet de transporter les paquets IP à travers un réseau IP mais ne fournit aucun
mécanisme pour gérer les flux IP d’une session entre des terminaux IP. Cette fonction est
généralement effectuée par les protocoles TCP ou UDP (User Datagram Protocol), chargés de
vérifier que la transmission et la réception des paquets s’effectuent correctement.

17
 Cependant, ces protocoles n’offrent aucune fonctionnalité permettant de gérer les flux temps réel,
audio ou vidéo, qui sont présents dans toutes les communications multimédia.

Les protocoles RTP et RTCP garantissent la qualité des communications multimédia en mode
paquet (gestion et contrôle des flux temps réel). Pouvant être mis en œuvre au-dessus d’IP, ils sont
utilisés par les deux protocoles de contrôle d’appel SIP et H.323.
 UDP est préféré à TCP pour les transmissions « temps réel »; en effet la priorité est donnée à
la rapidité plus qu’à la qualité de transmission. UDP est un protocole de transport léger et sans
connexion. Il ne garantit pas la livraison des paquets ni l'ordre dans lequel ils sont reçus, mais il
est souvent privilégié dans les applications en temps réel, car il introduit moins de latence que le
protocole TCP (Transmission Control Protocol), qui assure une livraison fiable des données.
 Les retransmissions effectuées par le protocole TCP, pour gérer la qualité de services, sont en
effet incompatibles avec des contraintes « temps réel ».
 Le protocole RTP (Real-time Transport Protocol) est généralement utilisé en combinaison avec
le protocole UDP (User Datagram Protocol) pour le transport de données en temps réel, comme
la voix et la vidéo, sur les réseaux IP.
 RTP est utilisé pour encapsuler les données multimédias et ajouter des informations de
synchronisation et de séquencement, facilitant ainsi la gestion de la lecture et de la présentation
des médias en temps réel. En combinaison, RTP sur UDP est couramment utilisé dans les
applications de voix sur IP (VoIP), de vidéoconférence et d'autres services de communication
multimédia en temps réel.
 RTP est utilisé en association avec le protocole de contrôle RTCP (Real Time Control
Protocol) qui fournit les informations nécessaires sur la qualité de transmission des données et
sur les participants aux sessions multimédia.
Cependant RTP ne fournit pas de lui-même les mécanismes nécessaires à la gestion des
informations « temps réel ». Pour cela, les couches protocolaires inférieures doivent mettre en
œuvre des solutions nécessaires à ces données sensibles au délai.

1. Fonctionnement de RTP

Comme nous l’avons vu, IP est un réseau partagé en mode paquet. Les paquets envoyés sur un
réseau IP ont une gigue et un délai de transmission imprévisibles. Cependant les applications
multimédia requièrent des caractéristiques appropriées à la transmission et la gestion des
applications dites « temps réel ». RTP fournit, pour chaque paquet, un marquage temporel, un
numéro de séquence et d’autres paramètres permettant d’offrir un transport, de bout en bout, des
18
 données « temps réel » sur un réseau en mode paquet.

 Le marquage temporel (« timestamping ») est l’information la plus importante pour les

applications « temps réel ». L’émetteur envoie un marqueur temporel qui donne l’instant où le
premier octet du paquet a été traité.
 A l’arrivée, le récepteur utilise le marqueur temporel pour reconstruire le flux multimédia de
sorte qu’il puisse être correctement présenté, dans un délai approprié, à l’utilisateur final.
Cependant, ce n’est pas RTP lui-même qui gère la synchronisation des paquets, il fournit
simplement les outils. La synchronisation est effectuée au niveau de la couche applicative.
Comme UDP ne fournit pas forcément les paquets dans l’ordre dans lequel ils ont été émis, les
numéros de séquence sont utilisés pour ordonner les paquets à l’arrivée. Ils sont aussi utilisés
pour la détection des paquets perdus.

19
 L’identifiant du type de données (« payload type identifier ») spécifie le format des données
contenues dans le paquet. La connaissance de cette information permet à l’application
réceptrice de savoir comment gérer les données utiles du paquet. A un instant donné, l’émetteur
de flux RTP ne peut envoyer qu’un type de données, cependant il est possible d’en changer lors
d’une transmission. RTP donne aussi un identifiant de l’émetteur permettant au récepteur de
connaître la provenance des données.
Les paquets RTP et RTCP sont généralement transportés sur UDP/IP.
Pour débuter une session RTP, l’application définit une paire particulière d’adresses transport
(adresse IP et port UDP) de destination. Dans une session multimédia, chaque média est transporté
sur une session RTP différente pour laquelle sont émis des paquets de contrôle (RTCP). Ainsi
l’audio et la vidéo sont transportés sur des sessions différentes, ce qui permet à l’utilisateur final
de choisir le média qu’il désire recevoir.

2. Fonctionnement de RTCP (Real-Time Control Protocol)

RTCP est un protocole défini pour être utilisé en addition de RTP. Dans une session RTP, chaque
participant envoie périodiquement des paquets RTCP et donner des informations sur la qualité de
la transmission. Il existe 5 types de paquets pour transporter cette information de contrôle :
 RR: « receiver report ». Les rapports des récepteurs sont envoyés par les terminaux qui ne
sont pas des participants actifs à la communication. Ils contiennent des informations sur les
données reçues, dont le numéro du dernier paquet reçu, la valeur moyenne de la gigue et le
« marqueur » temporel qui permettra de calculer le délai de transmission entre l’émetteur et
le récepteur
 SR: « sender report ». Les rapports des émetteurs sont émis par les terminaux actifs. En plus
des informations données par le « receiver report », ils donnent des informations concernant
la synchronisation inter-média, le nombre de paquets et d’octets émis.
 SDES: « source description items ». Contient des informations décrivant la source émettrice.
 BYE: indique la fin de la participation d’un participant à une session.
 APP: fonction utilisée par des applications spécifiques.
Ce protocole fournit à l’application les informations sur la qualité de la distribution des données.
20
Ces informations de contrôle sont nécessaires pour les émetteurs et les récepteurs. Les
informations de description des sources émettrices peuvent inclure des données en format texte
telles que le nom de l’utilisateur, le numéro de téléphone et l’adresse e-mail.
La gestion de la qualité de service de bout en bout impacte toutes les couches d’un réseau NGN,
depuis les terminaux jusqu’aux applications, en passant par les protocoles de gestion de niveau
intermédiaire (situés entre les couches Contrôle et Service) comme RTP et RTCP

21