Résumé

  • sendmode annonce le mode courant de l’encodeur, mais cette annonce peut arriver après les médias. La dernière SDP ne date donc pas automatiquement chaque paquet.
  • mode-set-recv et recvmode expriment une préférence du récepteur. L’émetteur distant peut l’ignorer tout en restant conforme ; il faut observer sa décision et son exécution séparément.

Le collecteur reçut d’abord une série de paquets. Quelques instants plus tard, une nouvelle SDP indiqua sendmode=4. Le rapport reclassa rétroactivement toute la séquence en mode 4, comme si l’annonce tardive avait toujours accompagné les médias.

Elle ne les avait pas accompagnés. Elle était un état de contrôle reçu plus tard. Peut-être décrivait-elle exactement ces trames ; peut-être seulement celles qui suivirent. Sans chronologie de l’encodeur et observation des paquets, le rapport avait remplacé une incertitude mesurable par une certitude documentaire.

Une déclaration courante n’est pas un horodatage universel

Dans RFC 5188, sendmode permet à l’émetteur d’annoncer le mode courant de son encodeur EVRC-WB ou EVRC-B. L’encodeur peut changer de mode à tout moment sans empêcher le décodage. Le texte souligne aussi que les médias RTP peuvent parvenir bien avant la SDP initiale ou mise à jour qui porte sendmode.

Ces deux règles forment une limite opérationnelle précise. Le plan de contrôle et le flux média ont des délais distincts. Un état SDP reçu à T2 ne prouve pas, à lui seul, le mode appliqué au paquet reçu à T1. Inversement, un paquet antérieur à l’annonce n’est pas automatiquement fautif : la déclaration peut simplement être en retard.

Le reçu durable doit joindre la version de l’offre et de la réponse, leur heure de réception, la transition effective de l’encodeur, les séquences et horodatages RTP, puis l’entrée du décodeur. Il ne doit pas étirer la dernière valeur connue sur une période qu’elle ne couvre pas.

Le récepteur exprime un souhait, pas un ordre

EVRC-WB utilise mode-set-recv pour indiquer un ensemble de modes que le récepteur préférerait recevoir. EVRC-B utilise recvmode pour indiquer un mode préféré. Ces paramètres sont unidirectionnels et concernent la réception.

Le correspondant distant peut les ignorer. RFC 5188 conserve cette liberté parce que le décodeur continue de fonctionner même si l’émetteur choisit un autre mode. Un exemple montre précisément un offreur prêt à recevoir le mode 0 tandis que le répondant choisit d’émettre en mode 4.

Il faut donc distinguer : préférence demandée, politique de l’émetteur, mode annoncé, mode exécuté et résultat décodé. Une réponse SDP valide ne fusionne pas ces cinq états. Le mot « négocié » devient trompeur s’il signifie à la fois « demandé » et « appliqué ».

Une préférence ignorée peut être un choix conforme, à documenter comme tel. Une préférence marquée « satisfaite » sans preuve d’encodeur est un défaut de preuve. Une annonce contredite par les médias est encore un autre problème. Chacun appelle une action différente.

La direction détermine l’autorité

mode-set-recv et recvmode sont receive-only ; sendmode est send-only. Sur un flux sendonly, déclarer une préférence de réception n’a pas d’utilité. Sur un flux recvonly, annoncer un mode d’émission n’en a pas davantage.

Les systèmes qui recopient tous les paramètres connus dans les deux directions fabriquent une symétrie absente du protocole. La chaîne peut être syntaxiquement correcte tout en attribuant la déclaration au mauvais acteur.

Le reçu doit donc stocker non seulement le champ, mais son auteur, sa direction effective, le payload auquel il s’attache et la version SDP. Sans ces coordonnées, une valeur 4 n’est qu’un nombre flottant entre deux rôles.

Le payload ne prouve ni le mode ni l’acoustique

Les sous-types audio/EVRCWB, audio/EVRCWB0 et audio/EVRCWB1 désignent respectivement les formats interleaved/bundled, header-free et compact bundled. Le payload type négocié établit la règle d’interprétation des paquets. Il ne prouve pas le mode effectivement choisi pendant un intervalle.

Les modes 4 et 7 d’EVRC-WB assurent l’interopérabilité avec EVRC-B. Un offreur devrait aussi annoncer EVRC-B afin qu’un répondant ancien puisse choisir ce format. Le codec sélectionné, le mode de l’encodeur et la préférence du récepteur restent donc trois faits différents.

Même le clock rate se prête aux raccourcis. EVRC-WB doit employer une horloge RTP de 16 kHz, alors que l’entrée de l’encodeur ou la sortie du décodeur peut être configurée à 8 kHz. Lire « 16000 » dans rtpmap ne constitue pas un reçu du microphone, du convertisseur ni de la bande acoustique livrée.

L’absence peut être de l’interopérabilité

RFC 5188 ajoute recvmode et sendmode aux types EVRC-B de RFC 4788. Un ancien pair ne les envoie pas et les ignore lorsqu’il les reçoit. C’est un mécanisme de compatibilité, pas un verdict d’échec.

Quand les paramètres manquent, l’observateur doit conserver plusieurs hypothèses : pair ancien, paramètre optionnel omis, SDP incomplète, attribut normalisé par un intermédiaire ou capture partielle. Attribuer d’office le mode 0 transforme l’absence de preuve en valeur exécutée.

Les paramètres inconnus reçus dans une offre doivent être ignorés et ne pas être repris dans la réponse. Les recopier pour paraître compatible créerait un faux accord sémantique. Les omettre peut au contraire être le comportement sûr exigé par l’extension du protocole.

EVRCWB1 impose une vérification plus forte

Pour EVRCWB1, toute la session doit conserver le même taux fixe et le même mode. Une transition observée au milieu de la même identité de session est donc différente d’un simple retard de sendmode.

Mais une nouvelle SDP n’autorise pas magiquement la transition. Il faut déterminer si une nouvelle session ou un nouveau binding de payload a commencé, où se termine l’ancien intervalle et à quelle configuration appartient chaque paquet. La règle fixe renforce la nécessité d’une identité temporelle ; elle ne transforme toujours pas la préférence du récepteur en reçu d’exécution.

Le dossier probant

Le dossier commence par un identifiant immuable de session et de changement. Il conserve les rôles, directions, versions d’offre/réponse, payloads proposés et retenus, sous-types, horloge RTP et lignes brutes rtpmap, fmtp, ptime et maxptime.

Il ajoute la préférence de réception, la décision de l’émetteur de la suivre ou non, chaque annonce sendmode, les transitions de l’encodeur et les paquets ou trames observés. Pour chaque intervalle, il indique si les médias précèdent la déclaration, la concordent ou lui survivent.

Enfin viennent la compatibilité du pair, le traitement des paramètres inconnus, l’acceptation du décodeur et le résultat applicatif. Aucun niveau ne parle au nom du suivant. Une trame décodable ne prouve pas une préférence satisfaite ; un mode satisfait ne prouve pas la qualité perçue.

Décision de direction

La bonne question n’est pas de savoir si la dernière SDP contient une valeur attendue. Il faut savoir qui avait l’autorité de décider, à quel instant cette décision est devenue exécutable et quels médias en portent la trace.

Conserver séparément souhait, annonce et exécution protège deux choses à la fois : l’interopérabilité prévue par RFC 5188 et la capacité de rendre compte d’un appel réel. Une organisation qui ne garde que la description finale peut encore réciter le contrat ; elle ne peut plus prouver l’histoire.

Sources

  1. RFC 5188 HTML
  2. RFC 5188 texte
  3. Notice RFC 5188
  4. Datatracker RFC 5188
  5. Historique RFC 5188
  6. Références RFC 5188
  7. Errata RFC 5188
  8. RFC 4788
  9. Notice RFC 4788
  10. RFC 3558
  11. Notice RFC 3558
  12. RFC 3264 offre-réponse
  13. Notice RFC 3264
  14. RFC 4566 SDP
  15. RFC 3550 RTP
  16. Type IANA audio/EVRCWB
  17. Paramètres RTP IANA
  18. Heng Lu — couches de réalité
  19. Heng Lu — spécification initiale minimale
  20. Heng Lu — priorité au code exécuté