LinkedIn DalonCorp

Interopérabilité SIP : valider son IPBX avant production

« Ça marche dans notre labo » n'est pas une preuve. Entre le banc de test et la production, se trouvent les codecs que l'opérateur ne négocie pas, les temporisations que l'IPBX n'attend pas, et les numéros que personne n'a testés. Voici comment valider une chaîne SIP avant de mettre vos utilisateurs dessus.

Pourquoi l'interopérabilité SIP est un sport de précision

Le SIP est standard, mais son interprétation est plurielle : chaque constructeur d'IPBX, chaque SBC et chaque opérateur implémente avec ses variantes. Les divergences les plus fréquentes :

  • Négociation de codecs : l'opérateur n'accepte que G.711 et G.729, votre IPBX propose Opus en premier — la première sonnerie passe, la voix ne suit pas
  • Transmission DTMF : RFC 2833, SIP INFO ou in-band ? Trois mondes qui ne se parlent pas, et un SVI qui ne reçoit plus de touches
  • Transfert d'appel : REFER, re-INVITE ou 302 ? Chaque méthode traverse les équipements différemment
  • Temporisations : timeout d'établissement, durée de session, keepalive NAT — un NAT UDP de 30 s et un keepalive de 60 s, et la registration meurt silencieusement

Une plateforme certifiée « interopérable » ne garantit rien : seule une matrice de tests exécutée sur vos équipements réels en apporte la preuve.

Le laboratoire avant le terrain

Sur nos déploiements, la chaîne complète est reconstituée en labo avant toute intervention client :

IPBX (version client) ──► SBC ──► simulateur trunk opérateur
            │                             │
        postes + softphones         scénarios de tests automatisés

Le simulateur de trunk rejoue les comportements réels des opérateurs : leurs variantes d'en-têtes, leurs temporisations, leurs rejets de codecs. C'est là que nous détectons l'incompatibilité DTMF ou la boucle de transfert — pas en production un lundi matin.

La matrice de tests d'interopérabilité

La matrice croise les fonctionnalités avec les directions (entrant/sortant) et les équipements. Les tests non négociables :

Établissement et signalisation

  • Appel sortant vers mobiles, fixes, RTC restant, international, numéros courts, 112
  • Appel entrant sur SDA, sur numéro principal, avec débordement
  • Renvoi inconditionnel, sur non-réponse, sur occupation (chaque type, dans les deux sens)
  • Transfert d'appel : annoncé, aveugle, avec retour d'appel

Média

  • Négociation de codecs par priorité : chaque codec autorisé reçoit un appel réussi
  • DTMF : RFC 2833 ET SIP INFO testés séparément (le SVI de la banque ne négocie pas)
  • Hold, reprise, musique d'attente : le RTP reprend-il dans les deux sens ?
  • Fax T.38 si applicable : établissement, transmission, reprise après erreur

Cas limites

  • Appel de plus de 60 minutes (les NAT et les refresh de session)
  • Perte du lien WAN pendant un appel (reprise ou coupure propre ?)
  • Registration renouvelée sous charge (200 postes qui redémarrent ensemble)
  • Reprise après coupure de l'opérateur (bascule second trunk, débordement RTC)

Les enseignements de nos bancs de test

Trois classes de défauts reviennent systématiquement :

  1. Le transfert en boucle : un IPBX qui renvoie le REFER vers l'opérateur, qui le renvoie au SBC, qui le renvoie à l'IPBX. Détectable uniquement avec un SIP trace complet (pcap) sur le banc.
  2. Le DTMF in-band sur codec compressé : G.729 déforme les tonalités DTMF in-band, le SVI ne reconnaît plus les touches. Le test « appeler le SVI de votre banque » fait partie de nos recettes.
  3. Le refresh de session manqué : session-timers non négociés entre IPBX et SBC — les appels tombent à exactement 30 minutes. Le test de 60 minutes le détecte.

Chacun de ces défauts est invisible sur un banc naïf « ça sonne, ça parle », et catastrophique en production.

La recette avant la bascule

Le jour de la migration, la recette est la reprise de cette matrice, exécutée sur le trunk réel :

  • Matrice complète rejouée (les résultats du labo ne préjugent pas du trunk réel)
  • Mesure QoS de référence prise (Mos, gigue, perte) comme baseline contractuelle
  • Période de coexistence RTC + SIP avec le plan de numérotation doublé
  • Plan de retour arrière documenté et testé (un rollback jamais répété échoue)

Pour aller plus loin