8.3.2 Changing the Set of Media Formats

8.3.2 Changing the Set of Media Formats

La liste des formats médias utilisés dans la session PEUT être modifiée. Pour ce faire, l'offreur crée une nouvelle description média, avec la liste des formats médias dans la ligne m= différente du flux média correspondant dans le SDP précédent. Cette liste PEUT inclure de nouveaux formats, et PEUT retirer des formats présents dans le SDP précédent. Toutefois, dans le cas de RTP, la correspondance entre un numéro de type de charge utile dynamique (dynamic payload type) particulier et un codec particulier dans ce flux média NE DOIT PAS changer pendant la durée d'une session. Par exemple, si A génère une offre avec G.711 assigné au numéro de type de charge utile dynamique 46, le numéro de type de charge utile 46 DOIT désigner G.711 à partir de ce point pour toute offre ou réponse pour ce flux média dans la session. Toutefois, il est acceptable que plusieurs numéros de type de charge utile soient mappés au même codec, de sorte qu'une offre mise à jour pourrait aussi utiliser le numéro 72 pour G.711.

Les correspondances doivent rester fixes pendant la session en raison de la synchronisation lâche entre les échanges de signalisation SDP et le flux média.

Le flux média correspondant dans la réponse est formulé comme décrit à la section 6, et peut entraîner un changement de formats médias également. De même, comme décrit à la section 6, dès qu'il envoie sa réponse, le répondant DOIT commencer à envoyer des médias en utilisant tout format de l'offre qui était aussi présent dans la réponse, et DEVRAIT utiliser le format le plus préféré de l'offre qui était aussi listé dans la réponse (en supposant que le flux autorise l'envoi), et NE DOIT PAS envoyer en utilisant des formats qui ne sont pas dans l'offre, même s'ils étaient présents dans un SDP précédent du pair. De même, lorsque l'offreur reçoit la réponse, il DOIT commencer à envoyer des médias en utilisant tout format dans la réponse, et DEVRAIT utiliser le plus préféré (en supposant que le flux autorise l'envoi), et NE DOIT PAS envoyer en utilisant des formats qui ne sont pas dans la réponse, même s'ils étaient présents dans un SDP précédent du pair.

Lorsqu'un agent cesse d'utiliser un format média (en ne listant pas ce format dans une offre ou une réponse, bien qu'il fût dans un SDP précédent), l'agent devra tout de même être prêt à recevoir des médias avec ce format pendant un bref instant. Comment sait-il quand il peut cesser d'être prêt à recevoir avec ce format ? S'il a besoin de le savoir, trois techniques peuvent s'appliquer. Premièrement, l'agent peut changer les ports en plus des formats. Lorsque les médias arrivent sur le nouveau port, il sait que le pair a cessé d'envoyer avec l'ancien format, et il peut cesser d'être prêt à recevoir avec celui-ci. Cette approche a l'avantage d'être indépendante du format média. Toutefois, les changements de ports peuvent exiger des changements de réservation de ressources ou une nouvelle clé pour les protocoles de sécurité. La deuxième approche consiste à utiliser un ensemble entièrement nouveau de types de charge utile dynamiques pour tous les codecs lorsqu'on en abandonne un. Lorsque des médias sont reçus avec l'un des nouveaux types de charge utile, l'agent sait que le pair a cessé d'envoyer avec l'ancien format. Cette approche n'affecte pas les réservations ni les contextes de sécurité, mais elle est spécifique à RTP et gaspille un espace de types de charge utile très limité. Une troisième approche consiste à utiliser une minuterie. Lorsque le SDP du pair est reçu, la minuterie est armée. Lorsqu'elle expire, l'agent peut cesser d'être prêt à recevoir avec l'ancien format. Une valeur d'une minute serait typiquement largement suffisante. Dans certains cas, un agent peut s'en moquer, et ainsi rester continuellement prêt à recevoir avec les anciens formats. Rien n'est nécessaire dans ce cas.

Bien sûr, si le flux offert est rejeté, l'offre peut cesser d'être prête à recevoir avec tout nouveau format dès la réception du rejet.