8.4 Putting a Unicast Media Stream on Hold (Mettere in attesa un flusso media unicast)

8.4 Putting a Unicast Media Stream on Hold (Mettere in attesa un flusso media unicast)

Se una parte in una chiamata vuole mettere l'altra parte "in attesa (on hold)", cioè richiedere che smetta temporaneamente di inviare uno o più flussi media unicast, una parte offre all'altra un SDP aggiornato.

Se il flusso da mettere in attesa era precedentemente un flusso media sendrecv, viene messo in attesa marcandolo come sendonly. Se il flusso da mettere in attesa era precedentemente recvonly, viene messo in attesa marcandolo come inactive.

Ciò significa che un flusso viene messo "in attesa" separatamente in ciascuna direzione. Ogni flusso viene messo "in attesa" in modo indipendente. Il destinatario di un'offerta per un flusso in attesa NON DOVREBBE automaticamente restituire una risposta con il flusso corrispondente in attesa. Un SDP con tutti i flussi "in attesa" è detto held SDP (SDP in attesa).

Alcuni scenari di controllo chiamate di terze parti (third party call control) non funzionano quando un answerer risponde a held SDP con held SDP.

Tipicamente, quando un utente "preme" attesa, l'agent genererà un'offerta con tutti i flussi nell'SDP che indicano una direzione sendonly, e inoltre silenzierà localmente, così che nessun media è inviato all'estremità remota e nessun media è riprodotto.

RFC 2543 [10] specificava che mettere un utente in attesa si otteneva impostando l'indirizzo di connessione a 0.0.0.0. Il suo uso per mettere una chiamata in attesa non è più raccomandato, poiché non consente di usare RTCP con flussi in attesa, non funziona con IPv6, e rompe i media orientati alla connessione. Tuttavia, può essere utile in un'offerta iniziale quando l'offerer sa di voler usare un particolare insieme di flussi e formati media, ma non conosce indirizzi e porte al momento dell'offerta. Naturalmente, quando usato, il numero di porta NON DEVE essere zero, che specificherebbe che il flusso è stato disabilitato. Un agent DEVE essere capace di ricevere SDP con indirizzo di connessione 0.0.0.0, nel qual caso significa che né RTP né RTCP dovrebbero essere inviati al peer.