Protocoles Multimédia

Ce chapitre présente brièvement les protocoles utiles aux communications en temps réel pour la signalisation (SIP), le transport (RTP) et un grand nombre de protocoles utiles comma DNS, NTP, ICE, STUN, TURN, etc.

1. Voix et vidéo sur IP

• Les services Internet comme Facetime, Skype, Webex, …

• Les CPE, 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.

… ont popularisé les technologies Voix et vidéo sur IP.

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 ainsi que 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. Intègre et vient compléter les nouveaux services de communications unifiées et mobile.

2.1. 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, VLANs, 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 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çu pour transmettre des données qui supportent les délais, les accusés de réception, 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 médias 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.

En téléchargeant les livres du Guide SIP vous encouragez son auteur !

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

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.

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.

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 un 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), de protocole de liaison en direct pour de la transmission TV, dans des solutions “domotiques”, de télé-présence, SIP pouvant être supporté sur n’importe quel objet capable en 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 HTTP.

Elles sont 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ésentent 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ée par un appel direct entre deux machines 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

En téléchargeant les livres du Guide SIP vous encouragez son auteur !

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 les suivantes :

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

Source : Stéphane Bortzmeyer

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 6120, 6121, 6122 (qui remplacent depuis 2011 les 3920 et 3921), 3922 et 3923. 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

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.

En téléchargeant les livres du Guide SIP vous encouragez son auteur !

8.1. STUN

Session Traversal Utilities for NAT (STUN), RFC 5389, est un ensemble de méthodes 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 Traversal” pour de la voix, de la vidéo, de la messagerie et d’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.

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

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

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

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

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

En téléchargeant les livres du Guide SIP vous encouragez son auteur !

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.

Source de l’image

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.