SIP — Notions élémentaires

Le protocole SIP (Session Initiation Protocol) propose une interface supplémentaire pour l’intégration de produits de sécurité dans un système. Norme très courante dans le secteur des télécommunications, le protocole SIP offre encore plus de souplesse pour l’interconnectivité et les usages quotidiens. Les interfaces normalisées ouvertes sont plébiscitées par les intégrateurs de systèmes, les développeurs et les utilisateurs finaux, qui en tirent de nombreux avantages car les produits sont utilisables dans une variété de systèmes. Les produits Axis qui prennent en charge SIP sont destinés à être utilisés dans des solutions dans les domaines de la sécurité et de la communication.

Un système SIP peut être simple à configurer. Néanmoins, si la topologie réseau est complexe ou s’il faut mettre en œuvre des fonctions évoluées de sécurité et de traitement des appels, des méthodes avec serveur SIP et traduction NAT s’imposent. Ces méthodes exigent avantage de compétences techniques de la part de l’installateur ou du technicien.

Le protocole SIP (Session Initiation Protocol) est utilisé pour établir, gérer et terminer des sessions multimédia entre plusieurs parties. Ces sessions sont généralement constituées d’audio, mais contiennent parfois aussi de la vidéo. SIP est le protocole standard utilisé dans les applications de voix sur IP (VoIP) et les plates-formes de communication unifiée (UC) (voir Section 3).

SIP constitue un moyen de connecter, d'intégrer et de contrôler vos produits réseau Axis. Il est pris en charge par tous les haut-parleurs réseau Axis, tous les interphones réseau Axis, certains dispositifs système Axis et certaines caméras Axis.

Pour communiquer avec SIP, il faut au moins deux clients SIP. Un client SIP peut être un téléphone physique ou logiciel, un client mobile ou un produit Axis compatible SIP.

Une adresse SIP spécifique est attribuée à chaque client SIP. Une adresse SIP ressemble à une adresse e-mail, mais avec le préfixe « sip: ».

Par exemple, sip:bob@axis.com [sip:<utilisateur@]<fournisseur>. Cet identifiant est utilisable sur une variété de dispositifs ; il est comparable à un numéro de téléphone lié à une carte SIM, utilisable sur divers appareils.

Un système SIP peut prendre de nombreuses formes. Dans le cas le plus simple, le système est composé d’au moins deux agents utilisateurs (UA, User Agent) qui communiquent directement entre eux. Cette configuration peut être qualifiée de configuration poste à poste, configuration d’appel direct ou configuration locale. Dans ce cas, une adresse SIP typique prend la forme sip:<adresse IP locale>, par exemple sip:192.168.0.90.

Pour effectuer un appel poste à poste d’un UA à un autre sur un réseau local, il suffit de l’adresse SIP contenant l’adresse IP de l'unité.

Une infrastructure VoIP basée sur SIP est très extensible. L'étape suivante consiste à utiliser un serveur SIP, ou un autocommutateur privé (PBX), comme concentrateur central. Les UA SIP s’inscrivent auprès du registraire du serveur, puis contactent d’autres UA en composant simplement un numéro de poste sur le PBX.

Dans ce cas, une adresse SIP standard prend la forme sip:<utilisateurs>@<domaine>. Elle peut également être de type sip:<utilisateur>@<IP-registraire>, par exemple sip:6007@ serveurip.net. Un PBX fonctionne comme un standard traditionnel : il affiche le statut actuel des clients, permet le transfert d’appel, les messages vocaux, les redirections et bien d'autres choses.

Un serveur SIP inclut généralement des fonctions de proxy, de registraire et de redirection. Les proxys acheminent les appels et apportent une logique supplémentaire aux appels entrants. Les registraires acceptent les demandes d’inscription et font office de service de localisation sur le domaine qu’ils gèrent. Les serveurs de redirection redirigent le client pour qu’il contacte une autre adresse SIP.

Le serveur SIP peut être configuré en tant qu’entité locale ou implanté hors site. Il peut être hébergé sur site ou dans le nuage. Les appels SIP d’un site à l’autre sont généralement acheminés initialement à travers un ensemble de proxys SIP. Ces proxys interrogent le site de l’adresse SIP à atteindre.

Pour utiliser votre dispositif avec un serveur SIP, vous devez créer un compte sur le serveur avec un ID utilisateur spécifié et un mot de passe. Pour inscrire votre dispositif auprès du serveur, vous devez configurer un compte sur le dispositif en renseignant l’adresse du serveur, l’ID utilisateur et le mot de passe.

Avec une liaison SIP, les UA SIP sont basculables vers le réseau téléphonique traditionnel (commuté). De cette manière, vous pouvez même attribuer un numéro de téléphone standard à l’UA SIP.

Le SIP trunking basé sur le nuage est une approche moderne qui s'appuie sur internet pour fournir des appels et d'autres services de communication. Cette méthode élimine le besoin de lignes téléphoniques physiques, ce qui facilite l'intégration avec les solutions en nuage et les systèmes VoIP.

Exemple : En utilisant une liaison SIP (1) avec un fournisseur de services, vous pouvez attribuer des numéros de téléphone externes à vos dispositifs (2, 3). Ainsi, vous pouvez passer des appels entre un haut-parleur réseau ou un interphone réseau et des téléphones standards (4).

Lorsque le dispositif est utilisé avec une liaison SIP, il se connecte au serveur de la manière expliquée plus haut.

Les communications unifiées (UC) désignent l'intégration de divers outils et technologies de communication dans un système unique et cohérent. Le protocole SIP joue un rôle essentiel dans les UC en activant une interaction transparente entre les différents canaux de communication, tels que la voix, la vidéo, la messagerie instantanée et les informations de présence. En tirant parti du protocole SIP, les sociétés peuvent créer un environnement de communication unifié qui renforce la collaboration, améliore la productivité et offre une expérience utilisateur cohérente sur plusieurs dispositifs et plates-formes.

Les UC peuvent être fournies localement dans des solutions sur site ou via des solutions en nuage (UC en tant que service — UCaaS). Cisco Webex, Microsoft Teams et Zoom sont des exemples de fournisseurs de services pour les solutions en nuage.

Pour effectuer un appel SIP, une séquence d’étapes est exécutée pour échanger des informations entre l’UA qui établit l’appel et l’UA qui le reçoit.

Lors de l’initialisation d’un appel, l’UA initiateur (1) envoie une demande ou un INVITE à l’adresse SIP de l’UA destinataire (2). L’INVITE contient un corps SDP (Session Description Protocol) qui décrit les formats de média disponibles et les informations de contact pour l’initiateur de l’appel.

Dès réception de l’INVITE, le destinataire accuse immédiatement réception en répondant avec une réponse 100 TRYING.

L’UA destinataire compare ensuite les formats de média proposés décrits dans le SDP avec les siens. S’il est possible de convenir d’un format commun, l’UA avertit le destinataire qu’il y a un appel entrant et renvoie une réponse provisoire à l’UA : 180 RINGING.

Lorsque le destinataire prend l’appel, une réponse 200 OK est envoyée à l’initiateur pour confirmer l’établissement d’une connexion. Cette réponse contient un SDP négocié qui indique à l’initiateur les formats de média à utiliser et la destination des flux de média.

Les flux de média négociés sont maintenant configurés en utilisant le protocole RTP (Real-time Transport Protocol) avec des paramètres basés sur le SDP négocié, et le média est transmis directement entre les deux parties. L’initiateur envoie un accusé de réception (ACK) via SIP pour confirmer qu’il a configuré les flux de média comme convenu. La session SIP est toujours active, mais elle ne participe plus au transfert de média.

Lorsque l’une des parties décide de terminer l’appel, elle envoie une nouvelle demande : BYE. Dès la réception d’un BYE, la partie destinataire la confirme avec 200 OK et les flux de média RTP sont alors interrompus.

SDP (Session Description Protocol) est un format qui décrit les paramètres d’initialisation de médias en streaming. Le corps de SDP contient des informations sur les formats multimédias (c’est-à-dire les codecs) pris en charge par les clients et l’ordre de sélection des codecs qu’ils privilégient.

Les codecs audio courants utilisés pour les appels SIP sont PCMU, PCMA, G.722, G.726 et L16. Si l’initiateur et le destinataire prennent en charge plusieurs codecs qui se recoupent, le codec dont la priorité est la plus haute côté destinataire est généralement sélectionné. Comme le choix des codecs influe au final sur la bande passante, il convient d’examiner avec attention les critères de compatibilité des autres UA SIP et de maintenir des conditions de bande passante adaptées au scénario d’utilisation. Par exemple, sur un réseau local où tous les clients prennent en charge L16, le choix de l’audio non compressé est pertinent. À l’inverse, si l’accès à l’UA SIP se fait par internet sur un téléphone portable, le codec PCMU est plus judicieux.

Dans une infrastructure SIP plus complexe, l’initialisation est un peu différente, car la session SIP est configurée étape par étape pour chaque saut. Cependant, une fois la session SIP configurée, le trafic n’est généralement pas acheminé, mais il est transmis directement entre les différentes parties, comme dans l’exemple précédent.

DTMF (Dual-Tone Multiple-Frequency) est un format permettant d’envoyer des informations sur une connexion téléphonique. Les signaux DTMF peuvent être transmis dans les appels SIP et servir à commander un dispositif SIP. La plage de caractères DTMF comprend les chiffres 0 à 9, les lettres A à D, * et #.

Par exemple, dans un appel vers un visiophone compatible SIP, il est possible d’envoyer le caractère DTMF « 5 » avec le clavier du téléphone, qui peut être configuré pour que le destinataire l’interprète en tant que commande d’ouverture de la porte.

Il existe trois méthodes pour envoyer des commandes DTMF dans un appel SIP :

• La méthode traditionnelle intrabande, dans laquelle le signal est une impulsion audio entrelacée avec le flux audio. Cependant, elle manque de fiabilité et fonctionne uniquement avec des codecs non compressés.

• La méthode SIP INFO, où le caractère DTMF est envoyé dans un message SIP au sein du flux de signalisation. Cette méthode très fiable a lieu hors bande, mais sa prise en charge est limitée.

• La méthode RTP (RFC2833), où le caractère DTMF est encodé sous forme de paquet RTP et envoyé hors bande. Cette norme de fait bénéficie d’une prise en charge étendue.

Les environnements réseau complexes, comme ceux des entreprises, peuvent engendrer des difficultés pour utiliser SIP. Il en va de même si vous souhaitez chiffrer la communication.

Dans un environnement réseau plus complexe, il peut s’avérer nécessaire d’utiliser la traduction d’adresse réseau NAT (Network Address Translation). NAT est une méthode de présentation publique des adresses IP situées sur un réseau privé local. Concrètement, tous les dispositifs d’un sous-réseau privé partagent un préfixe commun d’adresse IP, par exemple 192.168.1.XXX. C’est l’adresse qu’ils utilisent lorsqu’ils communiquent entre eux. Quand ils communiquent avec un autre réseau, cette adresse est traduite en l’adresse publique du routeur, avec un mappage de port en sus.

• 192.168.1.24 => 184.13.12.33:44221

• 192.168.1.121 => 184.13.12.33:24325, et ainsi de suite.

Comme la table de traduction est stockée dans le routeur, un utilisateur externe ne connaît généralement pas l’adresse d’un dispositif traduit par NAT:. Lors de la communication par SIP, il peut en résulter l’un des problèmes suivants :

• Impossible d’initialiser, d’actualiser ou de terminer une session, c’est-à-dire impossible de passer un appel, de mettre en attente ou de raccrocher.

• Aucun flux de média

• Flux de média unidirectionnel

Pour résoudre ces difficultés, SIP prend en charge trois techniques NAT :

• STUN : Méthode consistant à demander l’adresse publique du dispositif à un serveur hébergé dans un emplacement connu. Le serveur STUN renvoie l’adresse IP publique et le mappage de port servant à effectuer la demande. Le résultat est ensuite utilisé dans la signalisation et le transfert de média. Cette méthode fonctionne dans la plupart des cas.

• TURN : L’ensemble du trafic est relayé par un serveur connu. Cette méthode impose des charges supplémentaires, car la machine hébergeant le serveur TURN doit être suffisamment puissante pour acheminer les médias de tous les clients qui utilisent le service. Cette solution est donc plus coûteuse, mais elle peut fonctionner dans certains cas où la méthode STUN est inefficace.

• ICE : Le protocole ICE rassemble toutes les adresses IP liées à un UA SIP qu’il peut détecter, puis tente de calculer celle à utiliser. Utilisée en complément de STUN et TURN sur les deux UA SIP, émetteur et destinataire, la méthode accroît les chances d’établir des appels SIP.

Le trafic de signalisation SIP est normalement transmis par le protocole sans connexion UDP. Il est également possible de le transmettre par TCP, auquel cas il peut être soumis à un chiffrement TLS (Transport Layer Security).

Pour sécuriser la connexion lors d’un appel, le protocole SIP utilise une méthode d’adressage nommée Secure SIP (SIPS), qui impose un mode de transport défini sur TLS. Lors de l’établissement d’un appel, l’adresse SIP composée contient le préfixe « sips: » au lieu de « sip », soit sips:bob@biloxi.ex.com au lieu de sip:bob@biloxi.ex.com par exemple. Ainsi, chaque saut doit être sécurisé par TLS et le destinataire doit employer le même niveau de sécurité. Un appel avec TLS à une adresse à préfixe sip garantit le chiffrement du premier saut seulement.

Pour atteindre le degré de sécurité maximal, il convient de prendre les mesures suivantes :

• Le mode de transport doit être défini sur TLS.

• Le préfixe sips doit être utilisé systématiquement.

• SIP INFO doit être utilisé pour envoyer des tonalités DTMF, car elles sont envoyées dans le canal chiffré.

Notez que les clients ne prennent pas systématiquement en charge Secure SIP.