8.4 Putting a Unicast Media Stream on Hold
8.4 Putting a Unicast Media Stream on Hold
Si une partie dans un appel souhait mettre l'autre partie "en attente (on hold)", c'est-à-dire demander qu'elle arrête temporairement d'envoyer un ou plusieurs flux médias unicast, une partie offre à l'autre un SDP mis à jour.
Si le flux à mettre en attente était auparavant un flux média sendrecv, il est mis en attente en le marquant sendonly. Si le flux à mettre en attente était auparavant un flux média recvonly, il est mis en attente en le marquant inactive.
Cela signifie qu'un flux est mis "en attente" séparément dans chaque direction. Chaque flux est mis "en attente" indépendamment. Le destinataire d'une offre pour un flux en attente NE DEVRAIT PAS automatiquement retourner une réponse avec le flux correspondant en attente. Un SDP avec tous les flux "en attente" est appelé held SDP (SDP tenu).
Certains scénarios de contrôle d'appel tiers (third party call control) ne fonctionnent pas lorsqu'un répondant répond à un held SDP par un held SDP.
Typiquement, lorsqu'un utilisateur "appuie" sur attente, l'agent générera une offre avec tous les flux du SDP indiquant une direction sendonly, et il coupera aussi localement le son, de sorte qu'aucun média n'est envoyé vers l'extrémité distante, et aucun média n'est lu.
RFC 2543 [10] spécifiait que mettre un utilisateur en attente se faisait en mettant l'adresse de connexion à 0.0.0.0. Son usage pour mettre un appel en attente n'est plus recommandé, car il ne permet pas d'utiliser RTCP avec des flux en attente, ne fonctionne pas avec IPv6, et casse les médias orientés connexion. Toutefois, il peut être utile dans une offre initiale lorsque l'offreur sait qu'il veut utiliser un ensemble particulier de flux et formats médias, mais ne connaît pas les adresses et ports au moment de l'offre. Bien sûr, lorsqu'il est utilisé, le numéro de port NE DOIT PAS être zéro, ce qui spécifierait que le flux a été désactivé. Un agent DOIT être capable de recevoir un SDP avec une adresse de connexion 0.0.0.0, auquel cas cela signifie que ni RTP ni RTCP ne doivent être envoyés au pair.