En SIP, ce qui est négocié n'est pas ce qui est supporté

Un trunk SIP marche en lab. Il casse en prod, entre deux équipements de vendeurs différents. À chaque fois que ça m'est arrivé, la cause était la même. Un pair qui signale une capacité, un rôle ou un format, et qui en fait un autre. Le SIP est un contrat que les deux côtés prétendent honorer. Les implémentations divergent.

Trois cas réels. Trois trunks qui refusaient de passer un appel. À chaque fois, le fix était sur le SBC, jamais sur l'équipement fautif en face.

Ce qui est négocié	Ce que le pair fait vraiment	Résultat
UPDATE envoyé	UPDATE hors-séquence, offre pas encore résolue	Ignoré, retransmis en boucle, aucun appel
refresher=uac	Le UAC ne rafraîchit jamais	Appel coupé à l'expiration du timer
Early Offer attendu	Le SBC envoie du Delayed Offer	Appel rejeté

Cas 1 : un UPDATE que personne n'avait le droit d'envoyer

En face, un Cisco CUBE. Chez moi, un SBC AudioCodes. Le symptôme était brutal. Aucun appel ne passait. Zéro.

La trace donne la réponse. Le CUBE envoyait un UPDATE alors que l'offre SDP de l'INVITE initial n'avait pas encore reçu sa réponse. La RFC 3311 l'interdit. On ne lance pas une nouvelle négociation offre/réponse tant que la première n'est pas résolue. AudioCodes fait exactement ce que la RFC demande. Il ignore l'UPDATE, sans répondre.

Le CUBE, lui, n'obtient pas de réponse. Alors il retransmet. Encore. En boucle. Le comportement était systématique sur chaque appel, donc le trunk restait à plat.

Le fix : désactiver UPDATE sur le SBC. La négociation initiale se termine normalement, l'appel passe.

Ici, le pair conforme, c'est AudioCodes. Il suivait la RFC à la lettre. Ça n'a pas empêché le trunk de tomber. Ce qui casse un trunk, ce n'est pas toujours une faute au sens du protocole. C'est l'écart entre ce qu'un équipement envoie et ce que l'autre tolère.

Cas 2 : un refresher qui ne rafraîchit jamais

Mon SBC en face d'un Alcatel-Lucent OXE, l'OmniPCX Enterprise. Les appels tombaient. Systématiquement, toujours au même moment.

Les session timers de la RFC 4028 servent à couper les appels morts. Les deux côtés négocient un Session-Expires et désignent un refresher, celui qui renverra périodiquement un re-INVITE ou un UPDATE pour signaler que l'appel est vivant.

Session-Expires: 1800;refresher=uac

Le refresher désigné était le UAC. Le UAC ne rafraîchissait jamais. À l'expiration du timer, personne n'avait donné signe de vie. L'appel était déclaré mort et coupé, alors que le média coulait des deux côtés.

Le fix : basculer le refresh côté UAS. Le rôle va à celui qui le tient vraiment. Les appels ne tombent plus.

Négocier un rôle ne garantit pas qu'il sera tenu. refresher=uac est une promesse. Le UAC ne l'a pas honorée. Le SBC réattribue la promesse à quelqu'un de fiable.

Cas 3 : Early Offer, ou rien

Un SBC AudioCodes qui émet du Delayed Offer, un IPBX en face qui exige l'Early Offer. Appel rejeté d'entrée.

Deux façons de présenter le SDP :

Early Offer   : INVITE + SDP
Delayed Offer : INVITE sans SDP, puis SDP dans le 200 OK

Les deux sont valides. Tous les équipements ne les gèrent pas. Cet IPBX voulait l'offre dans l'INVITE, point. Un INVITE sans SDP, il le refuse.

Le fix : reconfigurer le SBC pour qu'il envoie de l'Early Offer. Conversion Delayed vers Early Offer sur AudioCodes. L'IPBX reçoit ce qu'il attend, l'appel s'établit.

Valide selon la RFC ne veut pas dire accepté par le pair. Le Delayed Offer était légitime. Il était quand même rejeté. Le SBC adapte le format à ce que l'autre côté sait lire.

Ce que ces trois cas ont en commun

À chaque fois, un côté signale une chose et en fait une autre. UPDATE hors-séquence. Refresher désigné mais inactif. Early Offer attendu, Delayed Offer envoyé. Deux implémentations conformes peuvent refuser de se parler.

Deux réflexes en sortent.

On ne corrige pas le vendeur en face. Je n'ai patché ni le CUBE, ni l'OXE, ni l'IPBX. Les trois fix étaient des configs sur le SBC. Le SBC est la couche où on absorbe la réalité du pair. C'est son rôle.

La trace est la seule vérité. La doc constructeur dit ce que l'équipement est censé faire. La capture SIP dit ce qu'il fait. Les deux ne sont pas toujours d'accord. Devant un trunk qui refuse de marcher, je ne lis pas une fiche produit. Je capture, je compare ce qui est négocié à ce qui se passe, et j'adapte sur le SBC.

Un trunk qui casse entre deux vendeurs, une migration SBC, un go-live qui coince sur la signalisation ? Prendre contact.