SIP (Session Initiation Protocol)

Reading time: 14 minutes

Informations de base

SIP (Session Initiation Protocol) est un protocole de signalisation et de contrôle des appels largement utilisé pour établir, modifier et terminer des sessions multimédias, y compris la voix, la vidéo et la messagerie instantanée, sur des réseaux IP. Développé par l'Internet Engineering Task Force (IETF), SIP est défini dans le RFC 3261 et est devenu la norme de facto pour la VoIP et les communications unifiées.

Certaines caractéristiques clés de SIP incluent :

1. Protocole basé sur du texte : SIP est un protocole basé sur du texte, ce qui le rend lisible par l'homme et plus facile à déboguer. Il est basé sur un modèle de requête-réponse, similaire à HTTP, et utilise des méthodes comme INVITE, ACK, BYE et CANCEL pour contrôler les sessions d'appel.
2. Scalabilité et flexibilité : SIP est hautement évolutif et peut être utilisé dans des déploiements à petite échelle ainsi que dans des environnements d'entreprise et de niveau opérateur. Il peut être facilement étendu avec de nouvelles fonctionnalités, le rendant adaptable à divers cas d'utilisation et exigences.
3. Interopérabilité : L'adoption et la normalisation généralisées de SIP garantissent une meilleure interopérabilité entre différents appareils, applications et fournisseurs de services, favorisant une communication fluide sur diverses plateformes.
4. Conception modulaire : SIP fonctionne avec d'autres protocoles comme le RTP (Real-time Transport Protocol) pour la transmission multimédia et le SDP (Session Description Protocol) pour décrire les sessions multimédias. Cette conception modulaire permet une plus grande flexibilité et compatibilité avec différents types de médias et codecs.
5. Serveurs proxy et de redirection : SIP peut utiliser des serveurs proxy et de redirection pour faciliter le routage des appels et fournir des fonctionnalités avancées comme le renvoi d'appels, le transfert d'appels et les services de messagerie vocale.
6. Présence et messagerie instantanée : SIP n'est pas limité à la communication vocale et vidéo. Il prend également en charge la présence et la messagerie instantanée, permettant une large gamme d'applications de communication unifiée.

Malgré ses nombreux avantages, SIP peut être complexe à configurer et à gérer, en particulier lorsqu'il s'agit de la traversée NAT et des problèmes de pare-feu. Cependant, sa polyvalence, sa scalabilité et son large soutien dans l'industrie en font un choix populaire pour la VoIP et la communication multimédia.

Méthodes SIP

Les méthodes SIP de base définies dans le RFC 3261 incluent :

1. INVITE : Utilisé pour initier une nouvelle session (appel) ou modifier une session existante. La méthode INVITE transporte la description de la session (généralement en utilisant SDP) pour informer le destinataire des détails de la session proposée, tels que les types de médias, les codecs et les protocoles de transport.
2. ACK : Envoyé pour confirmer la réception d'une réponse finale à une demande INVITE. La méthode ACK garantit la fiabilité des transactions INVITE en fournissant une reconnaissance de bout en bout.
3. BYE : Utilisé pour terminer une session établie (appel). La méthode BYE est envoyée par l'une ou l'autre des parties dans la session pour indiquer qu'elles souhaitent mettre fin à la communication.
4. CANCEL : Envoyé pour annuler une demande INVITE en attente avant que la session ne soit établie. La méthode CANCEL permet à l'expéditeur d'abandonner une transaction INVITE s'il change d'avis ou s'il n'y a pas de réponse du destinataire.
5. OPTIONS : Utilisé pour interroger les capacités d'un serveur SIP ou d'un agent utilisateur. La méthode OPTIONS peut être envoyée pour demander des informations sur les méthodes prises en charge, les types de médias ou d'autres extensions sans établir réellement une session.
6. REGISTER : Utilisé par un agent utilisateur pour enregistrer sa position actuelle auprès d'un serveur d'enregistrement SIP. La méthode REGISTER aide à maintenir une correspondance à jour entre l'URI SIP d'un utilisateur et son adresse IP actuelle, permettant le routage et la livraison des appels.

En plus de ces méthodes de base, il existe plusieurs méthodes d'extension SIP définies dans d'autres RFC, telles que :

1. SUBSCRIBE : Définie dans le RFC 6665, la méthode SUBSCRIBE est utilisée pour demander des notifications sur l'état d'une ressource spécifique, comme la présence d'un utilisateur ou l'état d'un appel.
2. NOTIFY : Également définie dans le RFC 6665, la méthode NOTIFY est envoyée par un serveur pour informer un agent utilisateur abonné des changements dans l'état d'une ressource surveillée.
3. REFER : Définie dans le RFC 3515, la méthode REFER est utilisée pour demander que le destinataire effectue un transfert ou se réfère à un tiers. Cela est généralement utilisé pour des scénarios de transfert d'appel.
4. MESSAGE : Définie dans le RFC 3428, la méthode MESSAGE est utilisée pour envoyer des messages instantanés entre des agents utilisateurs SIP, permettant une communication textuelle au sein du cadre SIP.
5. UPDATE : Définie dans le RFC 3311, la méthode UPDATE permet de modifier une session sans affecter l'état du dialogue existant. Cela est utile pour mettre à jour les paramètres de session, tels que les codecs ou les types de médias, pendant un appel en cours.
6. PUBLISH : Définie dans le RFC 3903, la méthode PUBLISH est utilisée par un agent utilisateur pour publier des informations d'état d'événement sur un serveur, les rendant disponibles à d'autres parties intéressées.

Codes de réponse SIP

• 1xx (Réponses provisoires) : Ces réponses indiquent que la demande a été reçue et que le serveur continue de la traiter.
• 100 Trying : La demande a été reçue et le serveur y travaille.
• 180 Ringing : Le destinataire est alerté et va prendre l'appel.
• 183 Session Progress : Fournit des informations sur l'avancement de l'appel.
• 2xx (Réponses réussies) : Ces réponses indiquent que la demande a été reçue, comprise et acceptée avec succès.
• 200 OK : La demande a été réussie et le serveur l'a remplie.
• 202 Accepted : La demande a été acceptée pour traitement, mais elle n'est pas encore terminée.
• 3xx (Réponses de redirection) : Ces réponses indiquent qu'une action supplémentaire est requise pour satisfaire la demande, généralement en contactant une ressource alternative.
• 300 Multiple Choices : Il existe plusieurs options disponibles, et l'utilisateur ou le client doit en choisir une.
• 301 Moved Permanently : La ressource demandée a été assignée à un nouvel URI permanent.
• 302 Moved Temporarily : La ressource demandée est temporairement disponible à un URI différent.
• 305 Use Proxy : La demande doit être envoyée à un proxy spécifié.
• 4xx (Réponses d'erreur client) : Ces réponses indiquent que la demande contient une mauvaise syntaxe ou ne peut pas être satisfaite par le serveur.
• 400 Bad Request : La demande était mal formée ou invalide.
• 401 Unauthorized : La demande nécessite une authentification de l'utilisateur.
• 403 Forbidden : Le serveur a compris la demande mais refuse de la satisfaire.
• 404 Not Found : La ressource demandée n'a pas été trouvée sur le serveur.
• 408 Request Timeout : Le serveur n'a pas reçu une demande complète dans le temps qu'il était prêt à attendre.
• 486 Busy Here : Le destinataire est actuellement occupé et ne peut pas prendre l'appel.
• 5xx (Réponses d'erreur serveur) : Ces réponses indiquent que le serveur a échoué à satisfaire une demande valide.
• 500 Internal Server Error : Le serveur a rencontré une erreur lors du traitement de la demande.
• 501 Not Implemented : Le serveur ne prend pas en charge la fonctionnalité requise pour satisfaire la demande.
• 503 Service Unavailable : Le serveur est actuellement incapable de traiter la demande en raison de maintenance ou de surcharge.
• 6xx (Réponses d'échec global) : Ces réponses indiquent que la demande ne peut pas être satisfaite par aucun serveur.
• 600 Busy Everywhere : Tous les destinations possibles pour l'appel sont occupées.
• 603 Decline : Le destinataire ne souhaite pas participer à l'appel.
• 604 Does Not Exist Anywhere : La ressource demandée n'est disponible nulle part dans le réseau.

Exemples

Exemple SIP INVITE

INVITE sip:jdoe@example.com SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: John Doe <sip:jdoe@example.com>
From: Jane Smith <sip:jsmith@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:jsmith@pc33.example.com>
User-Agent: ExampleSIPClient/1.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
Content-Length: 142

v=0
o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com
s=-
c=IN IP4 pc33.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000te

Exemple SIP REGISTER

La méthode REGISTER est utilisée dans le protocole d'initiation de session (SIP) pour permettre à un agent utilisateur (UA), tel qu'un téléphone VoIP ou un softphone, de s'enregistrer auprès d'un serveur d'enregistrement SIP. Ce processus permet au serveur de savoir où acheminer les requêtes SIP entrantes destinées à l'utilisateur enregistré. Le serveur d'enregistrement fait généralement partie d'un serveur proxy SIP ou d'un serveur d'enregistrement dédié.

Voici un exemple détaillé des messages SIP impliqués dans un processus d'authentification REGISTER :

1. Requête initiale REGISTER de l'UA au serveur d'enregistrement :

REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
From: Alice <sip:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>
Call-ID: 1234567890@192.168.1.100
CSeq: 1 REGISTER
Contact: <sip:alice@192.168.1.100:5060>;expires=3600
Expires: 3600
Content-Length: 0

Ce message REGISTER initial est envoyé par l'UA (Alice) au serveur d'enregistrement. Il inclut des informations importantes telles que la durée d'enregistrement souhaitée (Expires), l'URI SIP de l'utilisateur (sip:alice@example.com), et l'adresse de contact de l'utilisateur (sip:alice@192.168.1.100:5060).

2. 401 Unauthorized réponse du serveur d'enregistrement :

cssCopy codeSIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
From: Alice <sip:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>;tag=7878744
Call-ID: 1234567890@192.168.1.100
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="example.com", nonce="abcdefghijk", algorithm=MD5, qop="auth"
Content-Length: 0

Le serveur d'enregistrement répond avec un message "401 Unauthorized", qui inclut un en-tête "WWW-Authenticate". Cet en-tête contient des informations nécessaires pour que l'UA s'authentifie, telles que le domaine d'authentification, le nonce et l'algorithme.

3. Demande REGISTER avec des informations d'identification d'authentification :

REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
From: Alice <sip:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>
Call-ID: 1234567890@192.168.1.100
CSeq: 2 REGISTER
Contact: <sip:alice@192.168.1.100:5060>;expires=3600
Expires: 3600
Authorization: Digest username="alice", realm="example.com", nonce="abcdefghijk", uri="sip:example.com", response="65a8e2285879283831b664bd8b7f14d4", algorithm=MD5, cnonce="lmnopqrst", qop=auth, nc=00000001
Content-Length: 0

L'UA envoie une autre requête REGISTER, cette fois en incluant l'en-tête "Authorization" avec les informations d'identification nécessaires, telles que le nom d'utilisateur, le domaine, le nonce et une valeur de réponse calculée en utilisant les informations fournies et le mot de passe de l'utilisateur.

Voici comment la réponse d'Authorization est calculée :

import hashlib

def calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop):
# 1. Calculate HA1 (concatenation of username, realm, and password)
ha1_input = f"{username}:{realm}:{password}"
ha1 = hashlib.md5(ha1_input.encode()).hexdigest()

# 2. Calculate HA2 (concatenation of method and uri)
ha2_input = f"{method}:{uri}"
ha2 = hashlib.md5(ha2_input.encode()).hexdigest()

# 3. Calculate the final response value (concatenation of h1, stuff and h2)
response_input = f"{ha1}:{nonce}:{nc}:{cnonce}:{qop}:{ha2}"
response = hashlib.md5(response_input.encode()).hexdigest()

return response

# Example usage
username = "alice"
password = "mysecretpassword"
realm = "example.com"
method = "REGISTER"
uri = "sip:example.com"
nonce = "abcdefghijk"
nc = "00000001"
cnonce = "lmnopqrst"
qop = "auth"

response = calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop)
print(f"MD5 response value: {response}")

4. Réponse de registration réussie du serveur d'enregistrement :

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
From: Alice <sip:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>;tag=7878744
Call-ID: 1234567890@192.168.1.100
CSeq: 2 REGISTER
Contact: <sip:alice@192.168.1.100:5060>;expires=3600
Expires: 3600
Content-Length: 0

Après que le serveur d'enregistrement a vérifié les informations d'identification fournies, il envoie une réponse "200 OK" pour indiquer que l'enregistrement a réussi. La réponse inclut les informations de contact enregistrées et le temps d'expiration de l'enregistrement. À ce stade, l'agent utilisateur (Alice) est correctement enregistré auprès du serveur d'enregistrement SIP, et les demandes SIP entrantes pour Alice peuvent être acheminées vers l'adresse de contact appropriée.

Exemple d'appel