5.1 Unicast Streams (Flux unicast)
5.1 Unicast Streams (Flux unicast)
Si l'offreur souhaite n'envoyer du média sur un flux qu'à son pair, il DOIT marquer le flux comme sendonly avec l'attribut "a=sendonly". On dit qu'un flux est marqué avec une certaine direction si un attribut de direction était présent comme attribut de flux média ou comme attribut de session. Si l'offreur souhaite uniquement recevoir du média de son pair, il DOIT marquer le flux comme recvonly. S'il souhaite communiquer mais sans envoyer ni recevoir de média pour l'instant, il DOIT marquer le flux avec l'attribut "a=inactive". L'attribut de direction inactive est spécifié dans la RFC 3108 [3]. Notez que pour le Real Time Transport Protocol (RTP) [4], le RTCP est toujours envoyé et reçu pour les flux sendonly, recvonly et inactive. Autrement dit, la directionnalité du flux média n'a pas d'impact sur l'usage du RTCP. Si l'offreur souhaite à la fois envoyer et recevoir du média avec son pair, il PEUT inclure un attribut "a=sendrecv", ou PEUT l'omettre, car sendrecv est la valeur par défaut.
Pour les flux recvonly et sendrecv, le numéro de port et l'adresse dans l'offre indiquent où l'offreur souhaite recevoir le flux média. Pour les flux RTP sendonly, l'adresse et le port indiquent indirectement où l'offreur souhaite recevoir les rapports RTCP. Sauf indication explicite contraire, les rapports sont envoyés au numéro de port supérieur d'une unité à celui indiqué. L'adresse IP et le port présents dans l'offre n'indiquent rien sur l'adresse IP source et le port source des paquets RTP et RTCP que l'offreur enverra. Un numéro de port zéro dans l'offre indique que le flux est proposé mais NE DOIT PAS être utilisé. Cela n'a pas de sémantique utile dans une offre initiale, mais est autorisé pour des raisons d'exhaustivité, car la réponse peut contenir un port zéro indiquant un flux rejeté (section 6). De plus, les flux existants peuvent être terminés en mettant le port à zéro (section 8). En général, un port zéro indique que le flux média n'est pas souhaité.
La liste des formats média pour chaque flux média véhicule deux informations : l'ensemble des formats (codecs et paramètres associés au codec, dans le cas RTP) que l'offreur est capable d'envoyer et/ou de recevoir (selon les attributs de direction), et, pour RTP, les numéros de type de charge utile RTP utilisés pour identifier ces formats. Si plusieurs formats sont listés, cela signifie que l'offreur peut utiliser n'importe lequel de ces formats pendant la session. Autrement dit, le répondant PEUT changer de format en cours de session, en utilisant n'importe lequel des formats listés, sans envoyer une nouvelle offre. Pour un flux sendonly, l'offre DEVRAIT indiquer les formats que l'offreur est disposé à envoyer pour ce flux. Pour recvonly, l'offre DEVRAIT indiquer ceux qu'il est disposé à recevoir. Pour sendrecv, l'offre DEVRAIT indiquer les codecs qu'il est disposé à envoyer et à recevoir.
Pour les flux RTP recvonly, les numéros de type de charge utile indiquent la valeur du champ de type de charge utile dans les paquets RTP que l'offreur s'attend à recevoir pour ce codec. Pour sendonly, ils indiquent la valeur dans les paquets RTP qu'il prévoit d'envoyer. Pour sendrecv, ils indiquent la valeur qu'il s'attend à recevoir et préfère envoyer. Cependant, pour sendonly et sendrecv, la réponse peut indiquer des numéros de type de charge utile différents pour les mêmes codecs ; dans ce cas, l'offreur DOIT envoyer avec les numéros de la réponse.
Des numéros de type de charge utile différents peuvent être nécessaires dans chaque direction en raison de problèmes d'interopérabilité avec H.323.
Conformément à la RFC 2327, des paramètres fmtp PEUVENT être présents pour fournir des paramètres supplémentaires du format média.
Dans le cas des flux RTP, toutes les descriptions média DEVRAIENT contenir des mappages "a=rtpmap" des types de charge utile RTP vers les encodages. S'il n'y a pas de "a=rtpmap", le mappage par défaut défini par le profil en cours (par exemple la RFC 1890 [5]) doit être utilisé.
Cela facilite la migration hors des types de charge utile statiques.
Dans tous les cas, 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 le destinataire de l'offre DEVRAIT utiliser le format de plus haute préférence qui lui est acceptable.
Si l'attribut ptime est présent pour un flux, il indique l'intervalle de paquetisation souhaité que l'offreur aimerait recevoir. L'attribut ptime DOIT être strictement positif.
Si l'attribut de bande passante est présent pour un flux, il indique la bande passante souhaitée que l'offreur aimerait recevoir. La valeur zéro est autorisée mais déconseillée ; elle indique qu'aucun média ne doit être envoyé. Pour RTP, cela désactiverait aussi tout le RTCP.
Si plusieurs flux média de types différents sont présents, cela signifie que l'offreur souhaite utiliser ces flux en même temps. Un cas typique est un flux audio et un flux vidéo dans une visioconférence.
Si plusieurs flux média du même type sont présents dans une offre, cela signifie que l'offreur souhaite envoyer (et/ou recevoir) plusieurs flux de ce type en même temps. Lors de l'envoi de plusieurs flux du même type, la manière de mapper chaque source média de ce type (par exemple une caméra et un magnétoscope pour la vidéo) à chaque flux relève de la politique locale. Lorsqu'un utilisateur n'a qu'une seule source pour un type de média donné, une seule politique est raisonnable : la source est envoyée vers chaque flux du même type. Chaque flux PEUT utiliser des encodages différents. Lors de la réception de plusieurs flux du même type, la manière de mapper chaque flux aux différents puits média pour ce type (par exemple haut-parleurs ou enregistreur pour l'audio) relève de la politique locale. Quelques contraintes s'imposent cependant. Premièrement, lors de la réception de plusieurs flux du même type, chaque flux DOIT être mappé à au moins un puits aux fins de présentation à l'utilisateur. Autrement dit, l'intention est de les présenter tous en parallèle plutôt que d'en choisir un seul. Deuxièmement, lorsque plusieurs flux reçus sont envoyés au même puits, ils DOIVENT être combinés d'une manière spécifique au média. Par exemple, pour deux flux audio, les médias reçus peuvent être mappés aux haut-parleurs ; l'opération de combinaison serait alors le mixage. Pour plusieurs flux de messagerie instantanée dont le puits est l'écran, la combinaison consisterait à tous les présenter dans l'interface utilisateur. Troisièmement, si plusieurs sources sont mappées au même flux, ces sources DOIVENT être combinées d'une manière spécifique au média avant d'être envoyées sur le flux. Bien que les politiques au-delà de ces contraintes soient flexibles, un agent ne voudra généralement pas une politique qui copie le média de ses puits vers ses sources sauf s'il s'agit d'un serveur de conférence (c'est-à-dire ne pas copier le média reçu d'un flux vers un autre).
Un exemple d'usage typique pour plusieurs flux média du même type est une application de carte téléphonique prépayée, où l'utilisateur peut appuyer et maintenir la touche dièse ("#") à tout moment pendant un appel pour raccrocher et passer un nouvel appel avec la même carte. Cela exige d'envoyer le média de l'utilisateur vers deux destinations : la passerelle distante et l'application de traitement DTMF qui surveille le dièse. On peut y parvenir avec deux flux média, un sendrecv vers la passerelle, et l'autre sendonly (du point de vue de l'utilisateur) vers l'application DTMF.
Une fois l'offre envoyée, l'offreur DOIT être prêt à recevoir du média pour tout flux recvonly décrit dans cette offre. Il DOIT être prêt à envoyer et recevoir pour tout flux sendrecv de l'offre, et à envoyer pour tout flux sendonly (bien entendu, il ne peut réellement envoyer qu'une fois que le pair fournit une réponse avec l'adresse et le port nécessaires). Dans le cas RTP, même s'il peut recevoir du média avant l'arrivée de la réponse, il ne pourra pas envoyer de rapports RTCP récepteur tant que la réponse n'est pas arrivée.