Introduction à la VoIP/UC

1. POTS (Plain Old Telephony Systems)

1.1. POTS

POTS est un sigle anglais qui signifie Plain Old Telephone System que l'on peut traduire en français par "le bon vieux téléphone". Dans certains pays on parle de réseau fixe ou de téléphone fixe. Il s'agit en fait des services rendus par une ligne téléphonique analogique avant l'avènement des technologies ISDN, téléphone mobile, ADSL et VoIP.

Le service POTS existe depuis l'introduction du téléphone à la fin du XIXe siècle, sous une forme pratiquement inchangée pour l'utilisateur lambda malgré l'introduction de la numérotation par tonalité ou de la fibre optique en remplacement des fils de cuivre qui composaient les lignes. Outre la communication de la voix à travers le réseau RTC, on peut citer ces services communs comme :

  1. Voicemail, service de boîte vocale
  2. Caller ID, service d'identification de l'appelant
  3. Call waiting, service de mise en attente
  4. Speed dialing, composition rapide
  5. Conference call (three-way calling), chambres de conférences
  6. Enhanced 911, services d'urgences améliorés
  7. Centrex, central téléphonique
  8. Fac-simile (FAX), télécopie
  9. Communications digitales

Le réseau RTC/PSTN utilise des technologies, des supports et des protocoles différents de ceux qui supportent TCP/IP.

Les principaux concepts utiles à retenir sont :

  1. Communications digitales mais à commutation de circuit
  2. Architecture : Boucle locale/Trunks
  3. Compostion Pulse Dialing/DTMF
  4. Trunks
  5. Numérotation standard E.164
  6. Signalisation SS7

Ils permettent de mieux comprendre les architectures de connexions d'accès aux téléphones des entreprises et des particuliers sur lignes fixes et mobiles. Des interfaces et des protocoles permettent de connecter les deux mondes RTC et VoIP.

1.2. Commutation de circuit

La commutation de circuit est un mode d'établissement d'une liaison de télécommunication pour laquelle :

  • un chemin physique ou logique est établi entre deux équipements

et

  • est bloqué pour toute la durée de la communication.

L'établissement de circuit est aujourd'hui exécutée de manière électronique.

Dans la commutation par circuit, il y a un risque de sous-utilisation du support en cas de "silence" pendant la communication.

RNIS (ISDN) est un exemple de technologie à commutation de circuit qui digitalise la voix en tant que service.

Le temps passé est facturé.

1.3. Commutation de paquet

La commutation de circuits s'oppose au principe de la commutation de paquets qui optimise le canal de transmission laissant le soin à des commutateurs intermédiaires d'acheminer les paquets (Ethernet, Wi-Fi, IP) ou en établissant des Circuits Virtuels (ATM, Frame-Relay).

Ces technologies sont facturées par quantité de données échangées.

Le protocole MPLS permet de construire des réseaux IP cohérents sur ces architectures préexistantes avec une forme de confidentialité et de la gestion de qualité de service.

1.4. Boucle locale

Le réseau téléphonique commuté (RTC ou PSTN) peut transporter la voix mais aussi des données. Il utilise le principe de la commutation de circuit qui est celui de l'établissement d'un circuit dédié pour une communication.

Les téléphones sont connectés à des commutateurs téléphoniques (manuels, automatiques, électroniques) qui constitue des points d'échange téléphonique.

Ils sont situés chez l'opérateur au central office (CO) ou dans l'entreprise (en tant que Private Branch Exchange, PBX).

Boucle locale

Ces commutateurs s'interconnectent entre eux via des Trunks digitaux ou analogiques.

Si le nuage opérateur fonctionne entièrement en technologies digitales, du client à l'opérateur il reste souvent une connexion analogique avec des fréquences audibles pour transmettre la voix et la signalisation (Dial Tone Multi Frequency, DTMF). Cette zone est appelée boucle locale du CO de l'opérateur au bâtiment du client par une paire (téléphonique) de fils en cuivre.

1.5. Trunk

Un trunk est une liaison spéciale vers le réseau PSTN. Les opérateurs proposent des services digitaux sur la boucle locale analogique et parmi ceux-ci le transport de la voix :

  • sur ISDN
  • mais ausssi sur TCP/IP supporté par des technologies d'accès plus intéressantes telles que xDSL, DOCSIS (câble/Fibre), Metro Ethernet, etc.

Chaque communication vocale digitalisée prend 64 Kbps de bande passante.

Sur une technologie à commutation de circuits comme ISDN cette bande passante est monopolisée (même le silence est codé).

Sur une technologie à commutation de paquets, comme TCP/IP cette bande passante est optimisée en fonction de l'occupation.

1.6. Signalisation dual-tone multi-frequency signaling (DTMF)

La signalisation Dual-tone multi-frequency signaling (DTMF) est celle qui est utilisée "in band", c'est-à-dire dans le canal de communication, pour établir les destinations des appels auprès d'un central téléphonie privé ou public. DTMF est utilisé sur les claviers alphanumériques téléphoniques qui ont peu à peu remplacé les cadran à disque. Chaque touche correspond à deux fréquences audibles qui sont jouées simultanément.

Fréquences de touches DTMF :

1209 Hz 1336 Hz 1477 Hz 1633 Hz
697 Hz 1 2 3 A
770 Hz 4 5 6 B
852 Hz 7 8 9 C
941 Hz * 0 # D

Certaines fréquences audibles sont réservées, en Belgique :

Fréquence en Hz Cadences en secondes
Busy tone 425 0.5 on 0.5 off
Congestion tone 425 0.167 on 0.167 off
Dial tone 425 continuous
Special dial tone 425 1.0 on 0.25 off
Holding tone 1400 0.4 on 15.0 off
Ringing tone 425 1.0 on 3.0 off
Special information tone 900/1400/1800 3x0.33 on 1.0 off
Call waiting tone 1400 0.175 on 0.175 off 0.175 on 3.50 off

1.7. FXO/FXS

En téléphonie, un Foreign eXchange Station ou FXS est une interface téléphonique qui fournit la tonalité, le courant de charge et la tension électrique nécessaire pour faire fonctionner la sonnerie.

Un périphérique qui connecte un FXS est une interface FXO qu'elle soit un téléphone analogique ou l'interface d'un PBX pour recevoir des appels. L’interface Foreign eXchange Office est le port qui reçoit la ligne analogique.

1.8. ISDN/RNIS

Définition

ISDN (Integrated Services Digital Network), RNIS en français, est une technologie qui utilise la boucle locale pour fournir divers services de transmission digitales de la voix, de la vidéo et des sonnées. ISDN permet de se connecter au réseau PSTN, à Internet, à des sites distants.

ISDN fournit plusieurs type de canaux numériques :

  1. Canaux B de 64 Kbps pour la voix et les données (1 canal B = un canal voix)
  2. Canal D de 16 Kbps pour la signalisation.

Accès de base BRI

L'accès de base ou Basic Rate Interface (BRI ou T0) comprend deux canaux B et un canal D. Soit un total de deux canaux voix simultanés ou 128 Kbps de bande passante.

Source : Cisco Systems

Accès primaire PRI

L'accès primaire (PRA) ou Primary Rate Interface (PRI ou T2) propose trente canaux B et un canal D. Soit un total de 30 canaux voix simultanés ou 2 Mbps de bande passante. Ce type de ligne à 2 Mbps se vend aussi comme ligne dite E1.

1.9. Numérotation standard E.164

E.164 est une recommandation ITU-T qui définit le plan de numérotation international utilisé dans le réseau PSTN. Il définit aussi le format des numéros de téléphone de maximum 15 chiffres et habituellement écrits avec un sigle + en préfixe.

1.10. Signalisation SS7

Signaling System #7 (SS7) ou système de signalisation #7 est un ensemble de protocoles de signalisation téléphonique qui sont utilisés dans la grande majorité des réseaux téléphoniques mondiaux. SS7 fournit, dans le réseau téléphonique, une structure universelle pour :

  1. la signalisation,
  2. l'envoi de messages,
  3. l'interconnexion et la maintenance réseau.

Il gère

  1. l'établissement d'appels,
  2. l'échange d'informations utilisateur,
  3. le routage d'appels, la facturation et
  4. supporte les services du réseau intelligent (en anglais Intelligent Network (IN))

L'utilisation principale de SS7 est de délivrer un appel téléphonique à travers le RTC. L'appel peut avoir à traverser plusieurs réseaux de différents opérateurs téléphoniques. (Par exemple sur un appel international ou s'il y a plusieurs opérateurs nationaux...). À chaque étape sur le chemin de l'appel les commutateurs téléphoniques ont besoin de savoir d'où vient l'appel (quelle ligne téléphonique, quel canal ou quel circuit) et vers où il va. Cela nécessite beaucoup de coordination. ISUP (ou ISDN User Part signaling) est un type de communication SS7 qui s'occupe de l'établissement d'un appel tout au long de ces différents liens. Les messages ISUP sont passés de commutateur en commutateur et à chaque point du circuit l'appel est étendu un peu plus jusqu'à l'aboutissement de l'appel (établissement de bout en bout).

Remarque : En VoIP, à l'échelle des communications globales, le protocole IETF SIP a l'ambition de remplacer SS7.

2. Protocoles VoIP

2.1. Voix et vidéo sur IP

Les services Internet comme Facetime, Skype, Webex, ...

Les CPE (https://fr.wikipedia.org/wiki/Customer_Premises_Equipment), soit les "box" des opérateurs domestiques comme la Bebox de Belgacom

Les services de cartes pré-payées avec des tarifs avantageux pour certaines destinations.

2.2. Voice over Internet Protocol (VoIP)

La Voice over Internet Protocol (VoIP) est l'usage des réseaux Internet pour assurer des services téléphoniques. Ce récent paradigme technologique :

  1. Se base sur l'infrastructure de données informatiques : on parle de convergence IP. TCP/IP
  2. remplace la téléphonie analogique classique, l'ensemble des technologies ISDN d'entreprise ou d'opérateur.
  3. Supporte le service téléphonique de type POTS comme n'importe quelle application du réseau.
  4. S'intègre et complète les nouveaux services de communications unifiées et mobile.

Architecture VoIP

Le diagramme suivant représente un réseau qui utilise la même infrastructure pour la voix et les données.

On retrouve principalement :

  • des éléments d'infrastructure du réseau LAN/WAN qui transportent le trafic : des routeurs, des commutateurs, des lignes, mais aussi des services classiques : DHCP, DNS, QoS, etc.
  • des téléphones IP qui codent la voix : embarqués, logiciels, sur tablette ou smartphone.
  • Un central téléphonique IP (matériel, logiciel, composé de plusieurs éléments, virtualisé, dans le Cloud).
  • Des protocoles propres à la VoIP remplissant diversers fonctions de contrôle et de transport des médias.
  • Des Trunks passerelles VoIP/PSTN indépendantes (comme ici) ou installées dans l'IP PBX, voire un Trunk SIP vers le réseau PSTN.

Pour offrir une un service de qualité similaire à ce qu'offre la commutation de circuit, les réseaux IP doivent répondre aux défis que représente la transmission du trafic en temps réel. En effet, TCP/IP est conçus pour transmettre des données qui supportent les délais, les accusés de reception, etc. Pour qu'une transmission vocale soit audible, le réseau IP ne doit pas dépasser certains critères de délais, de pertes et de stabilité du flux. La gestion du QoS peut s'avérer nécessaire si ces critères de qualité ne sont pas respectés. Aussi, une architecture du réseau robuste et évolutive permet de s'adapter aisément à ces critères. Dans le LAN, on utilisera l'étiquetage de trame (IEEE 801.1q/802.1p) ou DSCP/RSVP dans un internet.

Le transport des medias est un élément critique qui ne supporte pas les retransmission et les délais. On peut connaître différents problèmes lors d'une transmission RTP :

  1. Packet loss – Perte de paquets. Quand le seuil de 5% de perte est atteint, on peut considérer une dégradation significative de la qualité de la voix.
  2. Delay – Délais : le temps requis pour que les paquets arrivent à destination. Des délais supérieurs à 150 ms affectent également la qualité perceptible de la voix.
  3. Jitter (delay variation) – Gigue : variation de délais. Trop de variabilité affecte également la qualité des transmissions vocales. Pour atténuer ce problème, on utilise des tampons de gigue.

Protocoles VoIP

Le transport et la signalisation des services associés à la VoIP reposent sur plusieurs protocoles. Ils sont formalisés dans la pile des protocoles TCP/IP par l'IETF. TCP/IP est le nom donné au modèle de communication.

Ce modèle se base sur les principaux protocoles des deux couches fonctionnelles (Internet et Transport) qui fournissent des services (couche Application) sur une multitude de technologies (couche Accès Réseau). Ces dernières sont aveugles à l'égard de TCP/IP.

Au milieu, pour assurer des services sur des connexions de données, on trouve de manière centrale le protocole IP. La liaison vers les applications se réalise via un protocole de transport orienté connexion tel que TCP ou non orienté connexion tel que UDP.

Typiquement dans une communication VoIP, différents protocoles interviennent quel que soient les technologies LAN ou WAN traversées d'une extrémité à l'autre du réseau :

  1. Pour la signalisation, par exemple : IP+UDP+SIP(+SDP)+charge
  2. Pour le transport de la voix, de la vidéo, etc. : IP+UDP+RTP+charge

D'autres protocoles interviennent mais il ne sont pas exclusivement destinés à l'usage VoIP, on devrait les trouver dans tout réseau bien géré :

  1. Pour la gestion du réseau au niveau global : DNS mais aussi NTP, HTTP, FTP, TFTP, DHCP, etc.
  2. Pour la gestion du réseau au niveau LAN/WAN : IEEE 802.1q (VLAN) et IEEE 802.1p (QoS) sur une infrastructure LAN commutée.

2.3. Le protocole RTP

RTP définit une méthode standardisée de transport réseau pour transmettre des échantillons de voix et de vidéo sur le réseau Internet. RTP, protocole de transport pour applications en temps-réel, est formalisé dans le RFC 3550.

RTP connaît d'autres applications que la téléphonie telles que la messagerie instantannée, l'IPTV, etc. RTP n'est pas un protocole fermé et complet mais plutôt un cadre pour spécifier d'autres protocoles.

Concrètement, RTP n'est pas responsable de la signalisation (SIP ou H.323 par exemple), de la gestion du QoS (RTCP), de la négociation des protocoles d'encodage (SDP) ou de la conversion analogique/digital (encodeurs).

La transmission s'effectue d'un téléphone IP à un autre de bout en bout, sans intermédiaire, dans une session ou en streaming.

RTP est en fait composé de deux protocoles, RTP à proprement dit et un sous-protocole RTCP qui se charge d'échanger des informations sur la QoS pour une session.

Bien que RTP se veuille indépendant des protocoles sous-jacents, il utilise largement le protocole UDP. Il peut utiliser RTSP (basé TCP) ou DCCP.

En effet, le fonctionnement simple et léger d'UDP permet de se passer de délais supplémentaires qui ne conviennent pas au transport de la voix.

Secure Real-time Transport Protocol (ou SRTP) définit un profil de RTP qui a pour but d'apporter le chiffrement, l'authentification et l'intégrité des messages, et la protection contre le replay de données RTP en unicast et multicast (RFC 3711).

Veuillez analyser la capture RTP et reconstruire la transmission vocale : https://www.cloudshark.org/captures/71c1b394bbbf.

2.4. Signalisation VoIP

Un protocole de signalisation est celui qui permet d'établir, maintenir et fermer une communication entre deux postes (téléphoniques) terminaux.

En VoIP, on trouvera plusieurs protocoles de signalisation :

  1. SIP
  2. H.323
  3. IAX
  4. Skiny/SCCP
  5. MGCP
  6. MEGACO
  7. BICC

SIP s'impose comme le protocole majeur dans les déploiement VoIP.

2.5. Protocole SIP

Session Initiation Protocol (dont l'abréviation est SIP) est un protocole normalisé et standardisé par le RFC 3261, et est complété par le RFC 3265. Il a été conçu pour établir, modifier et terminer des sessions multimédia.

  • Il se charge de l'authentification et de la localisation des multiples participants.
  • Il se charge également de la négociation sur les types de média utilisables par les différents participants en encapsulant des messages SDP (Session Description Protocol).
  • Il se charge également de prendre en compte la disponibilité (présence) des utilisateurs.

SIP ne transporte pas les données échangées durant la session comme la voix ou la vidéo.

SIP étant indépendant de la transmission des données, tout type de données et de protocoles peut être utilisé pour cet échange.

Cependant le protocole RTP (Real-time Transport Protocol) assure le plus souvent les sessions audio et vidéo.

Dans le contexte de la Téléphonie IP, SIP remplace progressivement H.323 et dans une autre mesure SS7.

Il est supporté par UDP (communément) ou TCP sur le port 5060 et/ou 5061 (sécurisé par TLS). Il est supporté aussi bien par IPv4 et IPv6. Il ne fonctionne pas sans d'autres protocoles TCP/IP qui le soutienne dans sa tâche de signalisation.

SIP est protocole de couche Application. Son fonctionnement sera plus aisé si on s'abstient de regarder les couches inférieures. Toutefois, la bonne compréhension des architectures SIP nécessite que l'on soucie des paramètres TCP/IP.

SIP est une boîte à outils pour développer sur le marché des solutions de communication en temps réel chez les particuliers et les entreprises via des fournisseurs historiques ou via des nouvels arrivants à partir des marchés des télécommunications vers celui de l'Internet (des objets).

Mais le protocole SIP est ouvert à bien d'autres usages ou contextes. Il peut être utilisé de facto comme protocole de communication au sein des solutions de back-end vocal (régie des émissions TV), protcole de liaision en direct pour de la transmission TV, dans des solutions de domotique, de télé-présence, étant supportant sur n'importe quel objet TCP/IP ...

L'idée fondamentale de SIP est d'offrir la possibilité d'établir, de maintenir et de terminer une session quelle que soit son contenu (voix, vidéo, commande, présence, message , texte) entre un ou plusieurs et un ou plusieurs hôtes TCP/IP.

Ces ressources TCP/IP sont des ressources logiques identifiées par un URIs tel que l'on trouve des URLs pour identifier des ressources SIP, de type sips:goffinet@goffinet.org ou sips:francois@test.tf, soit :

  • un protocole,
  • un identifiants
  • dans un domaine

en sachant que l'identifiant et son domaine représente une machine probablement joignable en TCP/IP soit disposant d'une adresse IP.

Un premier rôle fondamental est celui d'agent utilisateur (UA, User Agent) qui prend le nom de client (UAC) s'il établit l'appel ou de serveur (UAS) s'il reçoit l'appel.

Dès qu'un appel SIP aboutit, les hôtes d'extrémité devraient être capables de se transmettre un message dans un format négocié au préalable de l'appel grâce une charge SDP (Sesssion Description Protocol). + RFC

Sur le plan fondamental, une session SIP pour être illustré par un appel direct entre deux machine TCP/IP connectées au même réseau :

On peut trouver un exemple de cette transaction entre 10.33.6.101 (UAC) et 10.33.6.100 (UAs) sur https://www.cloudshark.org/captures/7d2a7dab3e8b.

On constate un échange de méthodes (INVITE, ACK, BYE) et de réponses (100, 180, 200)

Ce type de procédure fonctionne dans un monde idéal où toute ressource s'identifie par adresse IP et que celle-ci est parfaitement localisée.

Or les utilisateurs font appel à un service pour trouver les destinataires SIP. Ces services peuvent authentifier les utilisateurs, localiser les correspondants et les passerelles, transférer les messages d'établissement d'appels jusqu'à leur destination, les réécrire, les rediriger ou même les traduire.

SIP propose une série de rôles protocolaires tels que : REGISTRAR, PROXY, REDIRECT SERVER, B2BUA, SBC, ... qui permettent aux messages SIP de trouver leur destinataire. Ces rôles peuvent être comparés à ceux que l'on trouve au niveaux des couches TCP/IP : Switches, Routeurs, Pare-feux et contrôleurs divers.

A un niveau d'autant plus applicatifs, on peut trouver n'importe quel service qui prendra en charge un appel vidéo ou vocal tel que de l'IVR, du text-to-Speech, du chiffrement de signalisation et de transport, des services de passerelles vers le PSTN, des services de centre d'appel, un couplage à l'informatique d'entreprise, des services IP-PBX et Softswitch, ...

Aussi les utilisateurs identifient leur ressources par des noms sous un format commun qui correspond à une adresse de courrier électronique : sips:goffinet@goffinet.org

DNS est utilisé via des résolutions NAPTR et SRV pour trouver l'endroit de livraison du messsage d'appel.

Parce que les adresses IP sont embarquées dans les messages SIP, la traduction des adresses au passage des routeurs NAT (Network Address Translation) peut poser des problèmes.

Ceci dit, différentes solutions peuvent être envisagées pour déployer des solutions qui contournent ces écueuils :

  1. Se fonder sur IPv6
  2. Utiliser des solutions basées sur une implémentation des services ICE, STUN ou TURN
  3. Utiliser des passerelles et/ou des protocoles qui embarquent le trafic entre les correspondants

2.6. ENUM

ENUM, spécifié dans le RFC 3761, est un mécanisme permettant d'utiliser un numéro de téléphone comme clé de recherche dans le DNS pour trouver la manière de joindre une personne ou une autre entité. Les hypothèses de départ sont :

  1. qu'il existe déjà une infrastructure pour allouer les numéros de téléphone et que des milliards sont déjà attribués,

  2. que ces numéros sont des clés "naturelles" pour beaucoup de gens.

ENUM s'appuie sur le système DDDS ('Dynamic Delegation Discovery System', RFC 3401) et sur les enregistrements NAPTR du DNS.

Une recherche ENUM par un résolveur ENUM commence par un numéro de téléphone à la norme UIT E.164, comme +33 1 23 45 67 89.

Ce numéro est transformé en nom de domaine en l'inversant (comme on fait pour trouver un nom de domaine à partir d'une adresse IP, ici, cela donnerait 9.8.7.6.5.4.3.2.1.3.3.e164.arpa.

On cherche alors les enregistrements NAPTR pour ce nom de domaine. Si on trouve (ici, avec dig) :

% dig NAPTR 9.8.7.6.5.4.3.2.1.3.3.e164.arpa

NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:francois@test.tf!" .

NAPTR 10 102 "u" "E2U+msg" "!^.*$!mailto:goffinet@goffinet.org!" .

Cela signifie que le titulaire du numéro de téléphone +33 1 23 45 67 89 peut être joint en SIP à francois@test.tf et par courrier électronique à goffinet@goffinet.org.

La racine de ENUM est donc e164.arpa, géré politiquement par l'UIT et techniquement par le RIPE-NCC. On la nomme 'Tier 0' dans ENUM. Les 'Tier 1' sont les organismes nationaux d'attribution des numéros de téléphone et les 'Tier 2' les opérateurs. Ensuite, on peut déléguer comme on veut, comme avec n'importe quel domaine.

2.7. XMPP

Extensible Messaging and Presence Protocol (qu'on peut traduire par « Protocole extensible de présence et de messagerie »), souvent abrégé en XMPP, est un ensemble de protocoles standards ouverts de l'Internet Engineering Task Force (IETF) pour la messagerie instantanée, et plus généralement une architecture décentralisée d'échange de données. XMPP est également un système de collaboration en quasi-temps-réel et d'échange multimédia via le protocole Jingle, dont la Voix sur réseau IP (téléphonie sur Internet), la visioconférence et l'échange de fichiers sont des exemples d'applications.

XMPP est constitué d'un protocole TCP/IP basé sur une architecture client-serveur permettant les échanges décentralisés de messages instantanés ou non, entre clients, au format Extensible Markup Language (XML). XMPP est en développement constant et ouvert au sein de l'IETF.

Les serveurs peuvent être privés (en intranet, par exemple Facebook) ou bien reliés entre eux au sein du réseau Jabber. XMPP est ainsi utilisé à travers le monde par des centaines de serveurs publics et privés, et des millions d'utilisateurs. De nombreux acteurs industriels utilisent XMPP, comme Apple, Cisco, Gizmo5, GNOME, Google, IBM, Oracle Corporation, etc.

Le protocole XMPP est séparé en deux parties différentes :

  1. Le protocole de base contient les concepts fondamentaux pour faire fonctionner une infrastructure Jabber. Il est défini par les RFC 61202, 61213, 61224 (qui remplacent depuis 2011 les 39205 et 39216), 39227 et 39238. Théoriquement, une telle infrastructure ne peut pas fonctionner sans appliquer complètement ces protocoles.

  2. Les XMPP Extension Protocols (XEP) sont des propositions d'ajout de fonctionnalités au protocole Jabber. Les serveurs ou clients ne sont pas obligés d'adopter ces extensions. Cela peut bloquer certaines fonctionnalités entre deux utilisateurs.

XMPP est conçu de manière plus large et ouverte que la simple messagerie instantanée populaire et propriétaire. Il est ainsi utilisé par les entreprises et administrations dans le cadre d'échanges de données entre applications (ETL, EAI, ESB) au sein des systèmes d'informations, mais aussi dans le cadre du grid computing, des notifications d'alertes ou d'informations, de la supervision système et réseau, ou le cloud computing. Enfin, XMPP est également utilisé dans le domaine du partage et de la collaboration en quasi-temps-réel comme le tableau blanc (« whiteboard ») ou l'édition et le développement collaboratifs, mais aussi des jeux sur Internet (notamment les jeux de cartes et de plateau).

On ira lire des documents tels que :

  1. Extensible Messaging and Presence Protocol
  2. http://en.wikipedia.org/wiki/XMPP
  3. Comparison of instant messaging protocols
  4. http://en.wikipedia.org/wiki/SIMPLE

2.8. NAT Traversal

Le NAT cache les adresses privées sur le réseau public que les UAs peuvent embarquer dans leurs messages de couche application. Pour connaître l'adresse publique et les ports utilisés, les UAs passent par des techniques comme STUN, TURN, ICE ou encore d'autres techniques de type NAT Traversal.

STUN

Session Traversal Utilities for NAT (STUN), RFC 5389, est un ensemble de méthode standardisées qui permet à un hôte terminal de découvrir son adresse IP publique si il est situé derrière un routeur NAT. Il est utilisé pour permettre du NAT Tranversal pour de la voix, de la vidéo, de la messagerie et autres communications interactives en temps réel. Il est censé être utilisé par d'autres protocoles comme Interactive Connectivity Establishment (ICE) ou WebRTC. STUN nécessite l'usage d'un serveur STUN disponible dans l'Internet public.

TURN

STUN ne peut pas traverser tous les types de NAT (Symetric NAT). Traversal Using Relays around NAT (TURN) est un autre protocole qui relaie à travers un serveur public le trafic TCP/UDP émanant de réseaux privés. Il permet de traverser les pare-feux et les routeurs NAT. Il autorise seulement des connexions peer-to-peer comme en téléphonie IP.

ICE

Interactive Connectivity Establishment (ICE) est une méthode qui permet de traverser les routeur NAT pour établir des connexions directes entre des réseaux privés. Il permet de choisir entre STUN ou TURN (plus consommateur de ressources).

2.9. Enregistrement DNS SRV

Source : https://fr.wikipedia.org/wiki/Enregistrement_de_service

Un enregistrement SRV ou enregistrement de service est une catégorie de données du DNS d'Internet qui vise à indiquer quels sont les services disponibles. Ce type d'enregistrement est défini dans la RFC 2782.

Les enregistrements SRV sont souvent utilisés par les clients Microsoft Windows 2000 afin de trouver le contrôleur de domaine pour un service donné.

Par ailleurs, les enregistrements SRV sont communément utilisés en association avec les protocoles standards ci-dessous :

  • XMPP (Jabber)
  • SIP
  • LDAP

Format DNS SRV

Un enregistrement SRV contient les informations suivantes :

  • Service: le nom symbolique (commençant généralement par un symbole de soulignement) du service concerné (par exemple _sip).
  • Protocole : généralement, c'est soit _tcp pour TCP, soit _udp pour UDP.
  • Nom.de.domaine : le domaine de validité de l'enregistrement (pleinement qualifié au format FQDN ou local à la zone DNS en cours de définition pour la même autorité d'origine).
  • TTL : champ standard DNS indiquant la durée de validité (Time-To-Live, durée de vie) de la réponse (en secondes).
  • Classe : champ standard DNS indiquant la classe d'adressage (c'est toujours IN pour Internet).
  • Type : l'identifiant du type d'enregistrement DNS (toujours SRV ici pour un enregistrement de service)
  • Priorité : la priorité du serveur cible (valeur entière non négative, plus elle est faible, plus ce serveur sera utilisé s'il est disponible). S'il y a plusieurs enregistrements à différentes priorités pour le même service et un même protocole, un seul enregistrement pour chacune des priorités sera retourné aux clients DNS (les clients sont censés alors tenter de se connecter en priorité au serveur retourné ayant la plus faible valeur de priorité parmi les enregistrements retournés, mais si cela échoue, ils peuvent utiliser le serveur suivant de priorité plus élevée dans la liste de serveurs qui lui sont retournés). Différentes priorités permettent de mettre en place des services de secours (éventuellement distincts dans leur contenu et plus limité dans les possibilités, par exemple un ou plusieurs serveurs alternatifs fonctionnant en lecture seule sans support de certaines modifications par le service).
  • Poids : poids relatif pour les enregistrements de même priorité (valeur entière non nulle, permet au serveur DNS de retourner aléatoirement un des serveurs cibles ayant la même priorité, avec une distribution correspondant au poids indiqué, relativement au poids total des autres enregistrements de même priorité). Le poids indiqué n'a pas d'effet s'il n'y a qu'un serveur cible de la même priorité pour le même service et le même protocole (ce paramètre permet une distribution de charge assez sommaire entre plusieurs serveurs pour les services très fréquentés par de nombreux clients effectuant des requêtes DNS séparées, mais il n'aura pas d'effet si ces clients font leur requêtes DNS via un même serveur DNS proxy cache).
  • Port : le numéro de port (TCP ou UDP selon le protocole ci-dessus) où le service est disponible.
  • Cible : le nom du serveur qui fournit le service concerné (doit être résolu en adresse IPv4 ou IPv6 par d'autres requêtes DNS sur les enregistrements A ou AAAA du nom de service cible) avec le protocole et sur le port indiqué.

Par exemple, des enregistrements SRV peuvent ressembler à ceci :

_sip._tcp.example.com. 86400 IN SRV 0 33 5060 serveursip1.example.com.
_sip._tcp.example.com. 86400 IN SRV 0 33 5060 serveursip2.example.com.
_sip._tcp.example.com. 86400 IN SRV 0 33 5060 serveursip3.example.com.
_sip._tcp.example.com. 86400 IN SRV 10 100 5060 serveursip-offline.example.com.

Ils pointent vers trois serveurs nommés serveursip{1,2,3}.example.com qui attendent des connexions SIP sur le port TCP numéro 5060. Ici, la priorité indiquée est de 0 (priorité standard par défaut), et le poids de ces serveurs est de 33 (le serveur DNS retournera équitablement aléatoirement un des 3 serveurs aux clients DNS, mais de façon équitable). La durée de validité indiquée (86400 secondes soit une journée entière) permet aux clients DNS de garder dans leur cache local cette information pendant une journée entière avant de devoir réinterroger le serveur DNS.

Le serveur retournera aussi aux client un second serveur pour leurs requêtes, pointant sur serveursip-offline.example.com qui fournira un service SIP (éventuellement limité) si les clients ne parviennent pas à se connecter à l'un des trois premiers serveurs (ce serveur de secours à une priorité indiquée à 10 au lieu de 0, il n'est pas destiné à une utilisation permanente par les clients mais peut servir le temps d'une opération de maintenance sur l'un des 3 serveurs SIP de base, son poids indiqué à 100 n'a pas d'effet si c'est le seul serveur de secours).

Vérification de SRV DNS

Pour vérifier la présence d'un enregistrement SRV sur un domaine, les commandes nslookup et dig peuvent être utilisées.

Par exemple :

dig SRV _sip._tcp.example.com.

Sur quel port écoute le service SIP/UDP du domaine anveo.com ?

$ dig @8.8.8.8 SRV  _sip._udp.anveo.com.

; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 SRV _sip._udp.anveo.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37038
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;_sip._udp.anveo.com.        IN    SRV

;; ANSWER SECTION:
_sip._udp.anveo.com.    3599    IN    SRV    10 100 5010 sip.anveo.com.
_sip._udp.anveo.com.    3599    IN    SRV    20 100 5010 sip.ca.anveo.com.
_sip._udp.anveo.com.    3599    IN    SRV    30 100 5010 sip.de.anveo.com.

;; Query time: 39 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Nov 13 21:43:34 2016
;; MSG SIZE  rcvd: 142

Y a-t-il un serveur SIPS (TCP 5061) sur le domaine cisco.com ?

$ dig @8.8.8.8 SRV _sips._tcp.cisco.com.

; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 SRV _sips._tcp.cisco.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51584
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;_sips._tcp.cisco.com.        IN    SRV

;; ANSWER SECTION:
_sips._tcp.cisco.com.    3599    IN    SRV    10 10 5061 vcsgw.cisco.com.

;; Query time: 142 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Nov 13 21:48:07 2016
;; MSG SIZE  rcvd: 73

ou encore :

nslookup -q=SRV _sip._tcp.example.com.

2.10 Fax T.38

Source : https://fr.wikipedia.org/wiki/FoIP et https://en.wikipedia.org/wiki/T.38

Le fax sur réseau IP, ou FoIP pour « Fax over IP », est une technique qui permet d'émettre des télécopies via Internet ou tout autre réseau acceptant le protocole TCP/IP. Cette technologie est utilisée pour supporter le service de fax IP. On utilise pour cela les mêmes protocoles et les mêmes architectures que ceux mis en œuvre pour la voix sur IP.

L'une des problématiques du transfert de fax sur de la VoIP est que les codecs habituellement employés pour la voix dégradent de manière significative le signal et empêchent alors les fax de transiter correctement, la bande passante nécessaire à un fax étant supérieure à celle de la voix. Les protocoles utilisés dans la transmission des fax peuvent être le protocole T.38 pour le temps réel ou T.37 pour le mode Store and Forward. Les passerelles de conversion utilisent un codage propre au fax : le codec G.711 u-law.

2.11. Notes

3. Marchés VoIP / UC

Les premières illustrations qui viennent à l'esprit sont les déploiement de centraux téléphoniques d'entreprises de type IP-PBX ou du Trunking SIP en remplacement des lignes ISDN qui mènent vers le PSTN. Mais vu plus largement, le protocole se propose aussi de fédérer les services de téléphonie à l'échelle globale avec les technologies de l'Internet.

3.1. Marchés VoIP / UC

Les Communications Unifiées (Unified communications, UC) est un mot de marketing désignant des services d'entreprise de communication en temps réel comme la messagerie instantanée (IM, chat), les informations de présence, la voix (la téléphonie IP/VoIP incluses), des fonctionnalités de mobilité (suivi des extensions, un seul numéro d'appel), Conférence Web audio et vidéo, convergence fixe-mobile, partage de bureau, partage de données (fichiers, tableaux blancs), contrôle d'appel et reconnaissance vocale avec des services de communications comme de la Messagerie Unifiée (messages vocaux, e-mail, SMS et FAX).

Les Communications Unifiées ne correspondent pas à un seul produit. Le concept correspond à un ensemble de produits qui fournit une interface et une expérience consistante et unifiée quel que soient les multiples interfaces ou modes de communication utilisés.

3.2. Segment Cibles

  • Entreprises
  • PME
  • Cloud

3.3. Marché Unified Communications

Source : http://www.cisco.com/c/en/us/solutions/collaboration/analysts.html

3.4. Etudes Gartner

Les études Magic Quadrant de Gartner sont des études qualitatives globales sur les acteurs commerciaux d'un marché défini. Ce ne sont pas des études quantitatives, objectivées scientifiquement ou sources d'informations absolues.

Elles sont souvent offertes par les vainqueurs de ces études. Elles ne sont pas libres de droits.

Elles sont d'excellents outils pour se faire une idée de ce que les entreprises attendent d'un marché et pour prendre connaissance des offres actuellement disponibles. Elles permettent de créer un référentiel de critères pour établir un appel d'offre pour une solution de téléphonie UC. Elles permettent aussi d'établir des critères comparatifs entre différents modèles de déploiement ou commerciaux/open source.

Ces études positionnent les constructeurs et leur offre du moment selon deux axes :

  • La capacité du constructeur à répondre aux attentes du marché (ability to execute)
  • La complétude de la vision (completeness of vision) est le niveau de stratégie perçu pour atteindre les attentes du marché.

Elles positionnent les acteurs d'un marché dans un des quatre rôles :

  • Leaders
  • Challengers
  • Visionaries
  • Niche Players

On se renseignera dans les études Gartner sur :

  • La définition du marché
  • La portée et le moment de l'étude
  • Les attentes du marché
  • Le positionnement des acteurs
  • Leur actualité, forces et faiblesses

3.5. Acteurs mondiaux en Communications Unifiées

Pour Entreprise, PME et cloud

  • Cisco
  • Mitel
  • Avaya
  • Microsoft
  • Unify
  • Google
  • Alcatel-Lucent

3.6. Autres marchés

De manière plus globale celui de la "Collaboration" mais aussi :

  • Domotique
  • Surveillance
  • WebRTC
  • Conferencing

4. Aperçu des logiciels Open Source

En concurrence directe avec des solutions intégrées Cisco, Alcatel ou encore Avaya.

4.1. Solutions serveurs Open Source

  • IP PABX
    • Asterisk et dérivatifs
    • Freeswitch
  • Proxys SIP (Fed VoIP)
    • Kamailio
    • OpenSips
    • Repro
    • Flexisip

4.2. IP PABX

Ces logiciels font office de B2BUA, de serveurs Multimedia, de transcodeur de medias, d'IVR, etc.

Asterisk

Asterisk Core (http://www.asterisk.org/), sous Linux, en installation par paquet ou en installation native par compilation sur des plateformes Intel ou embarquées, voire en VM ou en Container ou encore en VPS.

Il existe aussi des dérivatifs à partir d'Asterisk et de FreePBX (GUI Web) fournis en distribution Linux :

Notons aussi l'endurance du projet Xivo (http://www.xivo.io/), basé Asterisk avec une interface spécifique.

On trouvera aussi des solutions sur l'embarqué Raspberry PI (voir https://iot.goffinet.org/labs_raspipbx.html et http://www.raspberry-asterisk.org/).

C'est sans compter les différentes appliances maintenues ou non que l'on peut trouver sur le marché.

Freeswitch

https://en.wikipedia.org/wiki/FreeSWITCH

4.3. Proxys SIP

Ces logiciels vise à exploiter la Federated VoIP : http://rtcquickstart.org/.

La "Federated VoIP" est une forme de la téléphonie qui utilise la VoIP entre des domaines autonomes dans l'Internet Public sans aucun déploiement d'un point central d'échange ou de commutateurs pour le routage du trafic. (https://en.wikipedia.org/wiki/Federated_VoIP)

Source : http://rtcquickstart.org/guide/multi/rtc-architecture-big-picture.html#arch-dia-1

La "Federated VoIP" peut utiliser notamment ENUM comme système d'adressage, de localisation et d'identification des participants. Elle exploite des entrées DNS SRV à la manière des entrées MX pour le service SMTP. Elle implémente des communications sécurisées grâce à TLS et aux certificats X.509. Elle utilise les protocoles SIP et XMPP/Jabber pour établir les communications.

Kamailio

Kamailio est un serveur SIP libre (anciennement OpenSER)

https://fr.wikipedia.org/wiki/Kamailio

https://www.kamailio.org/w/

OpenSips

Fork de OpenSER

http://www.opensips.org/

Repro

https://www.resiprocate.org/About_Repro

Flexisip

http://www.linphone.org/technical-corner/flexisip/overview

4.4. Clients VoIP Open Source

Clients graphiques

Logiciel Support OS Licence remarque
CSipSimple Android GNU GPL v3 conccurent avec le téléphone natif
Jitsi GNU/Linux, Windows, Mac OS X (Java) Apache v2 :-)
Linphone GNU/Linux, Windows, Mac OS X GNU GPL 2 ouvert
Zoiper GNU/Linux, Windows, Mac OS X, Android, Apple Ios Commercial/gratuit Robuste
Blink GNU/Linux, Windows, Mac OS X Commercial/gratuit SIPS, ZRTP

Librairies

5. Exercice de connexion SIP directe UAC à UAS avec Linphone

5.1. Logiciel Linphone

  • Pour les besoins du lab, on utillisera la version desktop
  • On s'interessera aussi aux outils de bas niveau comme linphonec et linphonecsh

Source : http://www.linphone.org/technical-corner/linphone/overview

5.2. Topologie

5.3. Exercice de connexion SIP directe UAC/UAS

A deux participants disposant de leur machine ou entre une machine physique et un machine virtuelle.

  • Télécharger Linphone pour Desktop : http://www.linphone.org/downloads-for-desktop.html
  • Noter l'adresse IP de l'interface connectée au LAN
  • Adapter le pare-feu et lancer Linphone avec les droits requis
  • Noter l'adresse IP locale et le port d'écoute de Linphone
  • Activer/désactiver le support vidéo
  • Etablir un appel vers un voisin avec l'URI : sip:<adresse ip du correspondant>
  • Activer uniquement les codecs PCMU/PCMA
  • Lancer une cature Wireshark avec le filtre "sip or rtp"
  • Etablir un nouvel appel vers le partenaire

results matching ""

    No results matching ""