5.1 Unicast Streams (Flussi unicast)
5.1 Unicast Streams (Flussi unicast)
Se l'offerente desidera inviare media su un flusso solo al peer, DEVE contrassegnare il flusso come sendonly con l'attributo "a=sendonly". Si dice che un flusso è marcato con una certa direzione se un attributo di direzione era presente come attributo del flusso multimediale o di sessione. Se l'offerente desidera ricevere media solo dal peer, DEVE marcare il flusso come recvonly. Se desidera comunicare ma in questo momento né inviare né ricevere media, DEVE marcare il flusso con "a=inactive". L'attributo di direzione inactive è specificato in RFC 3108 [3]. Nota: nel caso del Real Time Transport Protocol (RTP) [4], RTCP viene ancora inviato e ricevuto per flussi sendonly, recvonly e inactive. Cioè la direzionalità del flusso multimediale non incide sull'uso di RTCP. Se l'offerente desidera sia inviare sia ricevere media con il peer, PUÒ includere "a=sendrecv" oppure ometterlo, poiché sendrecv è il default.
Per flussi recvonly e sendrecv, il numero di porta e l'indirizzo nell'offerta indicano dove l'offerente desidera ricevere il flusso multimediale. Per flussi RTP sendonly, indirizzo e porta indicano indirettamente dove l'offerente vuole ricevere i report RTCP. Salvo indicazione esplicita diversa, i report sono inviati alla porta con numero superiore di uno rispetto a quello indicato. L'indirizzo IP e la porta presenti nell'offerta non dicono nulla sull'indirizzo IP sorgente e sulla porta sorgente dei pacchetti RTP e RTCP che l'offerente invierà. Una porta zero nell'offerta indica che il flusso è offerto ma NON DEVE essere usato. Non ha semantica utile in un'offerta iniziale, ma è consentita per completezza, poiché la risposta può contenere porta zero per un flusso rifiutato (Sezione 6). Inoltre i flussi esistenti possono essere terminati impostando la porta a zero (Sezione 8). In generale, porta zero indica che il flusso multimediale non è desiderato.
L'elenco dei formati multimediali per ogni flusso trasmette due informazioni: l'insieme dei formati (codec e parametri associati al codec, nel caso RTP) che l'offerente è capace di inviare e/o ricevere (a seconda degli attributi di direzione) e, per RTP, i numeri di tipo di payload RTP usati per identificarli. Se sono elencati più formati, significa che l'offerente può usare ciascuno di essi durante la sessione. In altre parole, il rispondente PUÒ cambiare formato nel corso della sessione usando qualsiasi formato elencato, senza inviare una nuova offerta. Per un flusso sendonly, l'offerta DOVREBBE indicare i formati che l'offerente è disposto a inviare; per recvonly quelli che è disposto a ricevere; per sendrecv i codec che è disposto a usare in entrambe le direzioni.
Per flussi RTP recvonly, i numeri di tipo di payload indicano il valore del campo tipo di payload nei pacchetti RTP che l'offerente si aspetta di ricevere per quel codec. Per sendonly, i valori nei pacchetti che intende inviare. Per sendrecv, il valore che si aspetta di ricevere e preferirebbe inviare. Tuttavia, per sendonly e sendrecv, la risposta può indicare numeri diversi per gli stessi codec; in tal caso l'offerente DEVE inviare con i numeri della risposta.
Numeri di tipo di payload diversi per direzione possono essere necessari per interoperabilità con H.323.
Come da RFC 2327, i parametri fmtp POSSONO essere presenti per ulteriori parametri del formato multimediale.
Nel caso di flussi RTP, tutte le descrizioni multimediali DOVREBBERO contenere mappature "a=rtpmap" dai tipi di payload RTP alle codifiche. Se non c'è "a=rtpmap", si usa il mapping predefinito del profilo corrente (ad esempio RFC 1890 [5]).
Ciò facilita la migrazione dai tipi di payload statici.
In tutti i casi, i formati nella riga "m=" DEVONO essere elencati in ordine di preferenza, il primo è il più preferito. Preferito significa che il destinatario dell'offerta DOVREBBE usare il formato di preferenza più alta accettabile.
Se è presente l'attributo ptime per un flusso, indica l'intervallo di pacchettizzazione desiderato che l'offerente vorrebbe ricevere. L'attributo ptime DEVE essere maggiore di zero.
Se è presente l'attributo di larghezza di banda, indica la larghezza di banda desiderata in ricezione. Il valore zero è consentito ma sconsigliato: indica che non deve essere inviato alcun media; per RTP disabiliterebbe anche tutto RTCP.
Se sono presenti più flussi multimediali di tipi diversi, l'offerente intende usarli contemporaneamente. Caso tipico: audio e video in una videoconferenza.
Se nell'offerta ci sono più flussi dello stesso tipo, l'offerente intende inviare (e/o ricevere) più flussi di quel tipo contemporaneamente. Quando se ne inviano più dello stesso tipo, è politica locale mappare ogni sorgente multimediale di quel tipo (es. telecamera e VCR per il video) su ciascun flusso. Con una sola sorgente per un dato tipo di media, ha senso una sola politica: la sorgente va inviata a ogni flusso dello stesso tipo. Ogni flusso PUÒ usare codifiche diverse. Quando se ne ricevono più dello stesso tipo, è politica locale mappare ogni flusso alle varie sink per quel tipo (es. altoparlanti o registratore per l'audio). Vi sono però vincoli. Primo: ricevendo più flussi dello stesso tipo, ciascun flusso DEVE essere mappato ad almeno una sink per la presentazione all'utente; l'intento è presentarli tutti in parallelo, non sceglierne uno solo. Secondo: se più flussi ricevuti vanno alla stessa sink, DEVONO essere combinati in modo specifico per il media (es. due audio agli altoparlanti → mixaggio; più flussi di messaggistica istantanea con schermo come sink → presentarli tutti nell'interfaccia). Terzo: se più sorgenti sono mappate sullo stesso flusso, quelle sorgenti DEVONO essere combinate in modo specifico per il media prima dell'invio sul flusso. Oltre questi vincoli la politica è flessibile; in genere un agente non vorrà copiare media dalle sink alle sorgenti salvo che sia un server di conferenza (cioè non copiare media ricevuti su un flusso su un altro).
Esempio tipico di più flussi dello stesso tipo: carta telefonica prepagata, in cui l'utente può tenere premuto il cancelletto ("#") in qualsiasi momento per chiudere e fare una nuova chiamata con la stessa carta. Serve inviare media dell'utente a due destinazioni: gateway remoto e applicazione DTMF che rileva il cancelletto. Si possono usare due flussi: uno sendrecv verso il gateway, l'altro sendonly (dal punto di vista dell'utente) verso l'applicazione DTMF.
Una volta inviata l'offerta, l'offerente DEVE essere pronto a ricevere media per ogni flusso recvonly descritto nell'offerta. DEVE essere pronto a inviare e ricevere per ogni flusso sendrecv e a inviare per ogni sendonly (naturalmente non può inviare finché il peer non fornisce risposta con indirizzo e porta). Nel caso RTP, anche se può ricevere media prima della risposta, non potrà inviare report RTCP del ricevente fino all'arrivo della risposta.