Résumé

  • Les protocoles CAS imposaient parfois une réaction en quelques dizaines de millisecondes. RFC 3064 plaça donc la machine d’états, les temporisations et les délais d’attente dans la passerelle, tout en réservant au Call Agent l’analyse des chiffres et les choix de niveau supérieur.
  • rel puis rlc libéraient la branche téléphonique et rendaient le trunk réutilisable. Ils ne supprimaient pas les connexions de paquets, qui exigeaient une opération DLCX distincte.

La latence ne devait pas devenir un état téléphonique

La signalisation associée au canal, ou CAS, transportait la prise de ligne, la réponse, la suspension et la libération au voisinage du circuit. Quand une transition devait recevoir une réponse en quelques dizaines de millisecondes, demander chaque détail à un Call Agent éloigné aurait incorporé la latence du réseau de commande dans la machine d’états.

Publié en février 2001, RFC 3064 choisit une répartition fonctionnelle. La passerelle média traiterait autant que possible le protocole CAS de bas niveau, ses temporisateurs et ses timeouts. Le Call Agent interviendrait pour l’analyse des chiffres, la sélection de la destination et la gestion des connexions entre réseaux. La proximité donnait compétence sur le délai, pas sur tout l’appel.

Les six paquets couvraient des surfaces différentes : MS pour le CAS MF de base, DT pour DTMF et les impulsions, BL pour PBX/FXS, DO pour FXO, MD pour EANA/EAIN de Feature Group D et MO pour les services opérateur. Leur présence actuelle dans le registre IANA atteste l’attribution des noms de version 0, non leur mise en œuvre dans un équipement précis.

Une interface commune ne rendait pas les trunks identiques

Pour un appel entrant fournissant une seule chaîne de chiffres, le Call Agent pouvait recevoir le même événement de setup qu’il s’agisse de wink start ou d’immediate start. La passerelle absorbait la différence locale et permettait de réutiliser le flux de commande.

La configuration physique ne disparaissait pourtant pas. Le type concret du trunk était provisionné dans la passerelle hors de MGCP. Le contrôleur devait encore connaître le paquet et le sens entrant, sortant ou bidirectionnel. Le nom commun décrivait une convention d’interface ; il ne découvrait ni le câblage, ni la capacité réelle, ni l’état du commutateur distant.

RFC 3064 distingua également les directions de preuve. Un signal était une commande du Call Agent vers la passerelle. Un événement était détecté par la passerelle puis notifié au Call Agent. Une réponse 200 OK constatait l’acceptation d’une étape ; une notification operation complete constatait plus tard la fin de l’émission locale des chiffres ; la supervision de réponse venait encore après.

Cette séquence interdit de transformer un acquittement de commande en preuve de conversation. L’acceptation ne prouvait ni la fin de la numérotation, ni le décroché distant, ni le passage d’un média intelligible. Les états marqués S pouvaient être audités, mais ne répondaient qu’à des questions étroites : un appel a-t-il commencé, ou la branche téléphonique est-elle idle et disponible ?

Deux libérations pour deux objets

La commande ou l’événement rel ne signifiait pas seulement « raccroché ». Il abandonnait la branche téléphonique et ses ressources, sans possibilité de reprendre ensuite. rlc, release complete, indiquait que les ressources du trunk étaient libérées et disponibles pour un nouvel appel.

Le texte pose aussitôt la limite : rel n’implique pas la suppression des connexions. Pour libérer tout l’appel, connexions comprises, le Call Agent devait envoyer DLCX, avec rel ou séparément.

Ce ne sont pas deux formulations du même résultat. Un trunk peut redevenir disponible alors qu’une connexion de paquets subsiste dans la passerelle. Une connexion peut être supprimée alors que le circuit distant n’a pas achevé sa libération. rlc est donc le reçu d’un objet téléphonique ; DLCX, celui d’un objet réseau.

Les chemins anormaux renforcent cette distinction. rel pouvait être produit après un raccrochage normal, mais aussi lorsque la passerelle ne pouvait plus maintenir la branche, notamment en cas de glare — la prise simultanée d’un trunk bidirectionnel par les deux extrémités. Dans ce dernier cas, rlc pouvait achever la transition sans correspondre littéralement à un raccrochage observé. Il décrivait l’état de la ressource, pas l’intention d’une personne.

Le comportement face au glare pouvait être provisionné localement, jusque par DS0. Cette latitude était logique : la collision se présentait au bord du circuit et sous contrainte de temps. Le Call Agent devait néanmoins recevoir la cause, rapprocher les événements et terminer les connexions restantes. Un voyant final « libre » ne révélait ni quelle prise avait gagné, ni si le réseau de paquets avait été nettoyé.

RFC 3064 était Informational, non une norme Internet. La note de l’IESG indiquait un déploiement contemporain dans plusieurs produits, tout en signalant les travaux successeurs de Megaco et de l’UIT-T SG16. Les RFC ultérieurs donnent le contexte d’évolution ; ils ne prouvent ni une adoption actuelle ni une sémantique rétroactive.

Le principe historique demeure : placer la réaction là où son délai peut être tenu, garder la décision globale auprès de l’acteur qui voit la transaction entière, puis produire un reçu pour chaque changement d’objet. La passerelle pouvait posséder les millisecondes. Elle ne possédait pas, à elle seule, la conclusion de l’appel.

Sources