Résumé

  • L’intersection ordonnée des profils AAL2 dans RFC 3441 produisait une liste compatible ; elle n’affectait pas, à elle seule, chaque service à une ligne du profil.
  • vsel, dsel et fsel exprimaient des préférences d’association entre service et ligne. Ils ne prouvaient ni la ligne utilisée par un émetteur actif, ni l’établissement d’un support ATM, ni l’arrivée du média chez l’appelant.

Une liste de codecs semble anodine, jusqu’au moment où deux passerelles doivent s’en servir pour construire une seule communication vocale. En AAL2, un profil décrit des lignes contenant des informations de codec et de paquétisation. Le contrôle d’appel peut proposer une liste ordonnée ; chaque passerelle possède sa propre liste locale ; il faut trouver les profils communs sans confondre cet ensemble avec l’affectation des services à l’intérieur d’un profil.

RFC 3441 traite cette frontière au moyen d’un paquet ATM pour le Media Gateway Control Protocol (MGCP). MGCP permet à un agent d’appel externe de contrôler les points d’extrémité d’une passerelle média. Le paquet ajoute des options de connexion locales pour le type de support ATM, la couche d’adaptation, les paramètres de service et de trafic, ainsi que la négociation des profils et des codecs. Le document est informatif : sa syntaxe décrit ce qu’un échange conforme peut représenter, pas les produits qui l’ont implémenté ni le nombre d’appels qui l’ont utilisé.

La distinction commence avec les listes de profils. La liste L d’une passerelle décrit ce qu’elle prend en charge localement. L’agent d’appel peut fournir une liste C, ordonnée selon ses préférences. Pour un appel entre deux côtés, le descripteur distant apporte une liste R. RFC 3441 impose une intersection ordonnée selon le sens de l’appel et la politique locale. Un profil conservé atteste une compatibilité dans ces listes et selon cette politique ; il ne constitue ni un circuit de support, ni un service, ni la preuve qu’un média a circulé.

L’exemple du RFC rend visible le caractère intermédiaire de ce résultat. La passerelle 1 prend en charge custom 100, itu 3, itu 1, itu 8 ; son agent propose itu 8, itu 9, atmf 7, itu 3, itu 1, custom 100. La priorité de la passerelle d’origine produit itu 8, itu 3, itu 1, custom 100. Cette liste est transmise à la passerelle 2 comme liste distante. Celle-ci l’intersecte avec ses profils locaux et l’offre de son agent, puis obtient itu 3, itu 1 et sélectionne itu 3. La préférence de la première passerelle pour itu 8 n’impose donc pas ce choix au côté destinataire.

Le contenu des profils pose une seconde question. L’initiateur avait associé vsel et dsel à son premier profil, itu 8. Ces paramètres ne décrivaient pas itu 3 ; la passerelle 2 ne pouvait pas simplement les transférer. Elle a utilisé les associations locales disponibles pour le profil retenu et renvoyé ses propres indications : la voix correspondait à certaines lignes de codec, tandis que les données en bande vocale — fax compris dans l’exemple — correspondaient à d’autres. L’intersection n’avait pas réglé l’affectation des services ; le profil sélectionné déterminait quelles associations étaient pertinentes.

RFC 3441 nomme les sélecteurs voix, données en bande vocale et fax vsel, dsel et fsel. Ce sont des préférences d’association entre service et ligne de profil, non une garantie qu’une ligne donnée sera employée pour chaque paquet. Le RFC précise que, une fois le profil associé à la connexion, l’émetteur AAL2 peut passer d’une ligne à une autre à la volée. Une application peut restreindre ces changements selon l’état du service, au prix d’une moindre flexibilité ; les paramètres de préférence ne l’imposent pas eux-mêmes. Le nom d’un profil n’est donc pas un reçu du codec de chaque paquet.

Les autres champs du paquet appartiennent à d’autres couches. Le type de connexion ATM, l’identifiant du circuit virtuel et les options d’établissement concernent le support. Les options AAL décrivent l’adaptation. Les options de gestion du trafic décrivent les catégories et paramètres du service ATM. Les choix de codec décrivent des préférences média. L’acceptation d’une commande MGCP, un descripteur SDP, un profil négocié, une réponse d’établissement du support, des cellules sur un circuit virtuel et un son intelligible sont des observations différentes. L’architecture de passerelle média de RFC 2805 et le protocole de base de RFC 3435 expliquent pourquoi contrôleur, passerelle et réseau n’ont pas la même responsabilité. RFC 3108 décrit des caractéristiques de support ATM en SDP, mais ne transforme pas l’accord de profil en preuve de transport.

Cette séparation importe parce qu’aucun acteur ne prend seul toutes les décisions. L’agent d’appel maîtrise son offre et sa politique. Chaque passerelle connaît ses profils locaux et ses associations de service. Le réseau ATM décide si un circuit virtuel peut être établi avec les paramètres demandés. La passerelle émettrice choisit la ligne active à un instant donné. Un descripteur distant peut rapporter une intention négociée ; il n’atteste pas que des cellules ont traversé le réseau ni que le destinataire a reconstruit et joué le service voulu.

L’analyse porte sur la frontière entre listes de profils et associations de service dans RFC 3441. Elle ne prétend pas établir un déploiement actuel de MGCP, le comportement d’un fournisseur, l’achèvement d’un appel ATM, la qualité d’un codec, une capacité réservée, la qualité vocale perçue ni une interopérabilité mesurée. La spécification définit un modèle d’échange et un vocabulaire de préférences ; leur donner le sens de reçus ultérieurs exige des preuves indépendantes.

Sources : RFC 3441 ; RFC 3435 ; RFC 2805 ; RFC 3108 ; RFC 3054 ; RFC 3336 ; RFC 3337. Fiches : RFC Editor ; IETF Datatracker.