Exploite ToIP, SIP et QoS voix sans dépendre d'un PBX précis

01Apprends le modèle, pas une marque de PBX

Le BTS doit permettre de raisonner dans plusieurs environnements.

Architecture minimale :

TEL-A / softphone A
        |
        | signalisation SIP
        v
PBX / service de téléphonie
        ^
        | signalisation SIP
        |
TEL-B / softphone B

TEL-A <========== média RTP ==========> TEL-B
        chemin direct ou relayé selon l'architecture

Asterisk, FreePBX, 3CX, CUCM ou un autre produit peuvent servir de support de laboratoire. Le produit n’est pas la compétence évaluée.

02Sépare signalisation et média

Deux plans coexistent :

PLAN DE CONTROLE
SIP
- enregistrer un terminal
- initier un appel
- négocier les paramètres utiles
- terminer l'appel

PLAN MEDIA
RTP / mécanisme média retenu
- transporter la voix
- subir directement latence, gigue et perte

Conséquence opérationnelle :

appel qui sonne mais sans audio
→ le plan de contrôle peut être sain
→ le problème peut être dans le chemin média

Ne cherche donc pas uniquement « le port SIP ».

03Observe une registration

Le laboratoire fournit deux identités synthétiques :

poste 201 -> utilisateur de lab A
poste 202 -> utilisateur de lab B

Pour chaque terminal, vérifie :

adresse IP
DNS si utilisé
adresse du service SIP
authentification de laboratoire
état enregistré / non enregistré
heure du dernier enregistrement

Une registration réussie doit être observée dans le terminal et, si disponible, côté service de téléphonie.

Aucun secret SIP réel ne doit apparaître dans une capture remise.

04Lis un appel simplifié

Le détail exact varie selon l’environnement, mais tu dois reconnaître la logique :

INVITE
→ demande d'établissement

réponses provisoires
→ traitement / sonnerie selon le scénario

réponse finale de succès
→ paramètres acceptés

ACK
→ confirmation

échange média
→ paquets voix

BYE
→ fin de session

Ne mémorise pas cette séquence comme une preuve suffisante. Dans une capture, relie chaque message aux adresses, identités et sens réels du laboratoire.

05Comprends le provisioning

Le provisioning prépare le terminal sans saisir manuellement chaque paramètre.

Chaîne générique :

terminal démarre
→ obtient sa configuration réseau
→ découvre ou connaît une source de provisioning
→ récupère une configuration autorisée
→ applique identité / serveur / paramètres
→ s'enregistre

Selon l’équipement, la découverte et le transport peuvent utiliser des mécanismes différents. Dans le dossier BTS, documente ce que le terminal doit apprendre plutôt que de présenter une méthode constructeur comme universelle.

Exemples de paramètres :

identité du poste
service SIP
politique de mise à jour
codec(s) autorisés
VLAN voix si utilisé
source horaire
certificats ou confiance si le produit les utilise

Le fichier de provisioning peut contenir des secrets. Ne le versionne pas dans Git et masque toute donnée sensible dans les preuves.

06Construis un VLAN voix si le scénario le demande

Un VLAN voix sert à séparer et administrer le trafic ; il ne garantit pas à lui seul la qualité.

Exemple de laboratoire :

VLAN 20  DATA
VLAN 40  VOICE
VLAN 99  MANAGEMENT

La matrice de flux doit préciser :

terminaux voix -> services nécessaires
service téléphonie -> terminaux selon architecture
DNS / NTP nécessaires
administration -> équipements depuis zone dédiée
VOICE -> LAN général : refus par défaut hors besoins explicités

Ne crée pas une règle large uniquement parce que les ports média peuvent être dynamiques. Utilise la plage et les besoins documentés par l’environnement de laboratoire.

07Mesure la qualité avant de parler QoS

Trois symptômes sont structurants :

latence  = délai de bout en bout
jigue    = variation du délai
perte    = paquets absents

Un appel peut rester établi tout en devenant difficile à comprendre.

Collecte des observations :

heure de l'appel
durée
sens affecté
latence observée si l'outil le permet
gigue observée si disponible
perte observée
charge du lien au même moment

La QoS ne crée pas de bande passante. Elle décide quels paquets sont servis en priorité lorsqu’une ressource devient contrainte.

08Classe le trafic au bon endroit

Une politique simple suit cette chaîne :

identifier
→ marquer
→ transporter la marque de façon maîtrisée
→ mettre en file / prioriser
→ mesurer

Pour le média voix, le scénario peut utiliser une classe de priorité et un marquage DSCP défini par la politique locale. EF est un choix courant pour un flux voix temps réel, mais l’étudiant doit vérifier la politique du laboratoire plutôt que de considérer un numéro DSCP comme une loi universelle.

Le point de confiance est essentiel :

terminal non maîtrisé
→ ne pas faire confiance aveuglément à son marquage

équipement / frontière administrée
→ classifier ou remarquer selon la politique

09Provoque la congestion de façon contrôlée

Dans le laboratoire uniquement, crée un trafic concurrent borné sur le lien prévu par le formateur.

Observe deux états :

ETAT A — sans politique de priorité voix
ETAT B — avec politique QoS attendue

Compare :

qualité perçue ou mesure disponible
gigue / perte si visibles
files d'attente ou compteurs si l'équipement les expose
marquage observé dans la capture
impact sur le trafic non voix

La conclusion doit rester limitée au laboratoire. Un test court ne prouve pas la qualité d’un réseau de production entier.

10Diagnostique par couche fonctionnelle

Le poste ne s’enregistre pas

adressage / VLAN
DNS si utilisé
joignabilité du service
heure / certificats si pertinents
identité de laboratoire
authentification
politique de pare-feu

L’appel se lance mais aucun audio ne passe

signalisation réussie ?
adresses média négociées ?
chemin RTP autorisé ?
NAT / pare-feu cohérents ?
un seul sens ou deux sens affectés ?

L’audio fonctionne mais se dégrade sous charge

lien saturé ?
classe voix identifiée ?
marquage conservé ?
file de priorité active ?
perte / gigue présentes ?
capacité réellement suffisante ?

11Panne contrôlée

Le formateur choisit une variante :

A — terminal dans le mauvais VLAN
B — adresse du service SIP erronée
C — identité de lab invalide
D — flux média bloqué mais signalisation autorisée
E — marquage voix absent ou réécrit
F — congestion sans politique de priorité active

Le candidat remet :

fait observé
hypothèses classées
test discriminant
cause confirmée
correction bornée
appel de validation
preuve média
preuve de retour de la politique réseau

12Constitue le dossier ToIP

Preuves minimales :

1. schéma signalisation / média ;
2. plan VLAN et matrice de flux ;
3. deux terminaux enregistrés ;
4. appel établi puis terminé ;
5. observation SIP utile ;
6. observation du média ;
7. principe de provisioning expliqué ;
8. politique QoS documentée ;
9. comparaison avant/après sous congestion contrôlée ;
10. diagnostic d'une panne ;
11. rollback ;
12. limites.