4.1.10.1. Use of Provisional Answers (Utilisation des réponses provisoires)
4.1.10.1. Use of Provisional Answers (Utilisation des réponses provisoires)
La plupart des applications n'auront pas besoin de créer des réponses en utilisant le type "pranswer". Bien qu'il soit de bonne pratique d'envoyer une réponse immédiate à une offre, afin de préchauffer le transport de session et d'éviter le découpage des médias, la gestion préférée pour une application JSEP est de créer et d'envoyer une réponse finale "sendonly" avec un MediaStreamTrack null immédiatement après réception de l'offre, ce qui empêchera les médias d'être envoyés par l'appelant et permettra aux médias d'être envoyés immédiatement lors de la réponse par l'appelé. Plus tard, lorsque l'appelé accepte réellement l'appel, l'application peut brancher le vrai MediaStreamTrack et créer une nouvelle offre "sendrecv" pour mettre à jour la paire offre/réponse précédente et démarrer le flux multimédia bidirectionnel. Bien que cela puisse également être fait avec une pranswer "sendonly" suivie d'une réponse "sendrecv", la pranswer initiale laisse l'échange offre/réponse ouvert, ce qui signifie que l'appelant ne peut pas envoyer une offre mise à jour pendant ce temps.
À titre d'exemple, considérez une application JSEP typique qui souhaite configurer l'audio et la vidéo aussi rapidement que possible. Lorsque l'appelé reçoit une offre avec des MediaStreamTracks audio et vidéo, il enverra une réponse immédiate acceptant ces pistes comme sendonly (ce qui signifie que l'appelant n'enverra pas encore de média à l'appelé, et parce que l'appelé n'a pas encore ajouté ses propres MediaStreamTracks, l'appelé n'enverra pas non plus de média). Il demandera ensuite à l'utilisateur d'accepter l'appel et d'acquérir les pistes locales nécessaires. Lors de l'acceptation par l'utilisateur, l'application branchera les pistes qu'elle a acquises, qui, parce que la négociation ICE et la négociation DTLS ont probablement été complétées à ce stade, peuvent commencer à transmettre immédiatement. L'application enverra également une nouvelle offre au côté distant indiquant l'acceptation de l'appel et déplaçant l'audio et la vidéo pour être des médias bidirectionnels. Un flux d'exemple détaillé dans ces lignes est présenté dans la Section 7.3.
Bien sûr, certaines applications peuvent ne pas être en mesure d'effectuer ce double échange offre/réponse, en particulier celles qui tentent de passer par une passerelle vers des protocoles de signalisation hérités. Dans ces cas, pranswer peut toujours fournir à l'application un mécanisme pour préchauffer le transport.