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

Un trunk SIP qui marche en lab peut casser en prod dès qu'il relie 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. Les deux implémentations peuvent être défendables et diverger quand même.

Les trois cas ci-dessous sont réels, et dans les trois le trunk refusait de passer un appel. Le fix était à chaque fois 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, j'avais un Cisco CUBE et, de mon côté, un SBC AudioCodes. Le symptôme était simple à constater, puisque aucun appel ne passait.

La trace a donné 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, parce qu'on ne lance pas une nouvelle négociation offre/réponse tant que la première n'est pas résolue. AudioCodes faisait exactement ce que la RFC demande et ignorait l'UPDATE sans y répondre.

Le CUBE, qui n'obtenait donc jamais de réponse, retransmettait en boucle. Le comportement se reproduisait sur chaque appel et le trunk restait à plat.

Le fix a consisté à désactiver UPDATE sur le SBC : la négociation initiale se termine alors normalement et l'appel passe.

Le pair conforme, dans ce cas, était AudioCodes, qui suivait la RFC à la lettre, et ça n'a pas empêché le trunk de tomber. Ce qui l'a fait tomber n'était pas une faute au sens du protocole, mais l'écart entre ce que le CUBE envoyait et ce qu'AudioCodes tolérait.

Cas 2 : un refresher qui ne rafraîchit jamais

Mon SBC faisait face à un Alcatel-Lucent OXE, l'OmniPCX Enterprise, et 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, et ce UAC ne rafraîchissait jamais. À l'expiration du timer, personne n'avait donné signe de vie, donc l'appel était déclaré mort et coupé alors que le média coulait des deux côtés.

Le fix a consisté à basculer le refresh côté UAS, pour que le rôle revienne à celui qui le tient vraiment, et les appels ne tombent plus.

Négocier un rôle ne garantissait pas qu'il serait tenu : refresher=uac était une promesse que le UAC n'a pas honorée, et le SBC l'a réattribuée à un pair qui la tenait.

Cas 3 : Early Offer, ou rien

Un SBC AudioCodes émettait du Delayed Offer alors que l'IPBX en face exigeait l'Early Offer, et l'appel était 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 formes sont valides, mais tous les équipements ne les gèrent pas. Cet IPBX voulait l'offre dans l'INVITE et refusait un INVITE sans SDP.

Le fix a consisté à reconfigurer le SBC pour qu'il envoie de l'Early Offer, avec la conversion Delayed vers Early Offer d'AudioCodes. L'IPBX recevait alors ce qu'il attendait et l'appel s'établissait.

Valide selon la RFC ne voulait pas dire accepté par le pair, puisque le Delayed Offer était légitime et rejeté quand même. Le SBC a adapté le format à ce que l'autre côté savait lire.

Ce que ces trois cas ont en commun

Dans les trois, un côté signalait une chose et en faisait une autre : un UPDATE hors-séquence, un refresher désigné mais inactif, un Early Offer attendu contre un Delayed Offer envoyé. Deux implémentations conformes peuvent refuser de se parler.

J'en tire deux réflexes.

Le premier est que je ne corrige pas le vendeur en face. Je n'ai patché ni le CUBE, ni l'OXE, ni l'IPBX, et les trois fix étaient des configurations sur le SBC, qui est la couche où on absorbe la réalité du pair.

Le second est que je me fie à la trace. La doc constructeur dit ce que l'équipement est censé faire, la capture SIP dit ce qu'il fait, et les deux ne sont pas toujours d'accord. Devant un trunk qui refuse de marcher, je capture plutôt que de lire une fiche produit, 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.