6.1 Unicast Streams (Flux unicast)
6.1 Unicast Streams (Flux unicast)
Si un flux est proposé avec une adresse unicast, la réponse pour ce flux DOIT contenir une adresse unicast. Le type de média du flux dans la réponse DOIT correspondre à celui de l'offre.
Si un flux est proposé en sendonly, le flux correspondant DOIT être marqué recvonly ou inactive dans la réponse. Si un flux média est listé recvonly dans l'offre, la réponse DOIT être marquée sendonly ou inactive. Si un flux proposé est listé sendrecv (ou s'il n'y a pas d'attribut de direction au niveau média ou session, auquel cas le flux est sendrecv par défaut), le flux correspondant dans la réponse PEUT être marqué sendonly, recvonly, sendrecv ou inactive. Si un flux proposé est listé inactive, il DOIT être marqué inactive dans la réponse.
Pour les flux marqués recvonly dans la réponse, la ligne "m=" DOIT contenir au moins un format média que le répondant est disposé à recevoir parmi ceux listés dans l'offre. Le flux PEUT indiquer des formats média supplémentaires, non listés dans le flux correspondant de l'offre, que le répondant est disposé à recevoir. Pour les flux marqués sendonly dans la réponse, la ligne "m=" DOIT contenir au moins un format que le répondant est disposé à envoyer parmi ceux listés dans l'offre. Pour les flux marqués sendrecv, la ligne "m=" DOIT contenir au moins un codec que le répondant est disposé à envoyer et à recevoir, parmi ceux listés dans l'offre. Le flux PEUT indiquer des formats supplémentaires, non listés dans le flux correspondant de l'offre, que le répondant est disposé à envoyer ou à recevoir (bien entendu, il ne pourra pas les envoyer pour l'instant puisqu'ils n'étaient pas dans l'offre). Pour les flux marqués inactive dans la réponse, la liste des formats média est construite à partir de l'offre. Si l'offre était sendonly, la liste est construite comme si la réponse était recvonly. De même, si l'offre était recvonly, comme si la réponse était sendonly ; si l'offre était sendrecv, comme si la réponse était sendrecv. Si l'offre était inactive, la liste est construite comme si l'offre était en réalité sendrecv et la réponse sendrecv.
L'adresse de connexion et le port dans la réponse indiquent l'adresse où le répondant souhaite recevoir le média (pour RTP, le RTCP sera reçu sur le port supérieur d'une unité sauf indication explicite contraire). Cette adresse et ce port DOIVENT être présents même pour les flux sendonly ; pour RTP, le port supérieur d'une unité sert toujours à recevoir le RTCP.
Dans le cas RTP, si un codec particulier était référencé avec un numéro de type de charge utile spécifique dans l'offre, le même numéro DEVRAIT être utilisé pour ce codec dans la réponse. Même si le même numéro est utilisé, la réponse DOIT contenir des attributs rtpmap définissant les mappages pour les types dynamiques, et DEVRAIT en contenir pour les types statiques. Les formats dans la ligne "m=" DOIVENT être listés par ordre de préférence, le premier étant le plus préféré. Ici, préféré signifie que l'offreur DEVRAIT utiliser le format de plus haute préférence parmi ceux de la réponse.
Bien que le répondant PEUT lister les formats dans l'ordre de préférence souhaité, il est RECOMMANDÉ que, sauf raison spécifique, il les liste dans le même ordre relatif que dans l'offre. Autrement dit, si un flux de l'offre liste les codecs audio 8, 22 et 48 dans cet ordre, et que le répondant ne prend en charge que 8 et 48, il est RECOMMANDÉ que, s'il n'a pas de raison de changer, l'ordre dans la réponse soit 8, 48, et non 48, 8. Cela favorise l'usage du même codec dans les deux directions.
L'interprétation des paramètres fmtp dans une offre dépend des paramètres. Souvent, ils décrivent des configurations précises du format média et doivent donc être traités comme la valeur du format elle-même. Cela signifie que les mêmes paramètres fmtp avec les mêmes valeurs DOIVENT être présents dans la réponse si le format qu'ils décrivent y figure. D'autres paramètres fmtp sont plus proches de paramètres généraux, pour lesquels il est parfaitement acceptable que chaque agent utilise des valeurs différentes. Dans ce cas, la réponse PEUT contenir des paramètres fmtp, avec les mêmes valeurs que dans l'offre ou des valeurs différentes. Les extensions SDP définissant de nouveaux paramètres DEVRAIENT préciser l'interprétation correcte en offre/réponse.
Le répondant PEUT inclure un attribut ptime non nul pour tout flux média ; cela indique l'intervalle de paquetisation qu'il aimerait recevoir. Il n'est pas exigé que l'intervalle soit le même dans chaque direction pour un flux donné.
Le répondant PEUT inclure un attribut de bande passante pour tout flux média ; cela indique la bande passante qu'il souhaite que l'offreur utilise lors de l'envoi du média. La valeur zéro est autorisée, interprétée comme décrit à la section 5.
Si le répondant n'a aucun format média en commun pour un flux proposé donné, il DOIT rejeter ce flux en mettant le port à zéro.
S'il n'y a aucun format en commun pour tous les flux, la session offerte entière est rejetée.
Une fois la réponse envoyée, le répondant DOIT être prêt à recevoir du média pour tout flux recvonly décrit dans cette réponse. Il DOIT être prêt à envoyer et recevoir pour tout flux sendrecv de la réponse, et PEUT envoyer du média immédiatement. Il DOIT être prêt à recevoir pour les flux recvonly ou sendrecv en utilisant n'importe lequel des formats listés pour ces flux dans la réponse, et PEUT envoyer immédiatement. Lors de l'envoi, il DEVRAIT utiliser un intervalle de paquetisation égal à la valeur de l'attribut ptime de l'offre, s'il était présent. Il DEVRAIT envoyer avec une bande passante au plus égale à celle de l'attribut de bande passante de l'offre, s'il était présent. Le répondant DOIT envoyer en utilisant un format présent à la fois dans l'offre et dans la réponse, et DEVRAIT utiliser le format le plus préféré de l'offre qui figure aussi dans la réponse. Pour RTP, il DOIT utiliser les numéros de type de charge utile de l'offre, même s'ils diffèrent de ceux de la réponse.