6.1 Unicast Streams (Flussi unicast)
6.1 Unicast Streams (Flussi unicast)
Se un flusso è offerto con indirizzo unicast, la risposta per quel flusso DEVE contenere un indirizzo unicast. Il tipo di media del flusso nella risposta DEVE corrispondere a quello dell'offerta.
Se un flusso è offerto come sendonly, il flusso corrispondente DEVE essere marcato recvonly o inactive nella risposta. Se un flusso multimediale è elencato come recvonly nell'offerta, la risposta DEVE essere marcata sendonly o inactive. Se un flusso offerto è elencato come sendrecv (o se non c'è attributo di direzione a livello di media o sessione, nel qual caso il flusso è sendrecv per default), il flusso corrispondente nella risposta PUÒ essere marcato sendonly, recvonly, sendrecv o inactive. Se un flusso offerto è inactive, DEVE essere marcato inactive nella risposta.
Per flussi marcati recvonly nella risposta, la riga "m=" DEVE contenere almeno un formato multimediale che il rispondente è disposto a ricevere tra quelli elencati nell'offerta. Il flusso PUÒ indicare formati aggiuntivi, non presenti nel flusso corrispondente dell'offerta, che il rispondente è disposto a ricevere. Per flussi sendonly nella risposta, la riga "m=" DEVE contenere almeno un formato che il rispondente è disposto a inviare tra quelli dell'offerta. Per sendrecv, almeno un codec che il rispondente è disposto sia a inviare sia a ricevere, tra quelli dell'offerta. Il flusso PUÒ indicare formati aggiuntivi non nell'offerta che è disposto a inviare o ricevere (naturalmente non potrà inviarli ora, non essendo stati elencati nell'offerta). Per flussi inactive nella risposta, l'elenco dei formati si costruisce in base all'offerta. Se l'offerta era sendonly, l'elenco come se la risposta fosse recvonly. Analogamente, se l'offerta era recvonly, come se la risposta fosse sendonly; se sendrecv, come se la risposta fosse sendrecv. Se l'offerta era inactive, come se l'offerta fosse in realtà sendrecv e la risposta sendrecv.
L'indirizzo di connessione e la porta nella risposta indicano dove il rispondente desidera ricevere i media (nel caso RTP, RTCP sarà ricevuto sulla porta superiore di uno salvo diversa indicazione esplicita). Questo indirizzo e porta DEVONO essere presenti anche per flussi sendonly; nel caso RTP la porta superiore di uno serve ancora a ricevere RTCP.
Nel caso RTP, se un particolare codec era referenziato con un numero di tipo di payload specifico nell'offerta, lo stesso numero DOVREBBE essere usato per quel codec nella risposta. Anche usando lo stesso numero, la risposta DEVE contenere attributi rtpmap per definire le mappature dei tipi dinamici e DOVREBBE includere mappature per i tipi statici. I formati nella riga "m=" DEVONO essere elencati per preferenza, il primo è il più preferito; preferito significa che l'offerente DOVREBBE usare il formato di preferenza più alta dalla risposta.
Sebbene il rispondente PUÒ elencare i formati nell'ordine di preferenza desiderato, si RACCOMANDA che, salvo ragione specifica, li elenchi nello stesso ordine relativo dell'offerta. Cioè, se un flusso nell'offerta elenca i codec audio 8, 22 e 48 in quell'ordine e il rispondente supporta solo 8 e 48, si RACCOMANDA che, senza motivo di modifica, l'ordine nella risposta sia 8, 48 e non 48, 8. Ciò aiuta a usare lo stesso codec in entrambe le direzioni.
L'interpretazione dei parametri fmtp nell'offerta dipende dai parametri. Spesso descrivono configurazioni specifiche del formato multimediale e vanno quindi trattati come il valore del formato stesso. Ciò implica che gli stessi parametri fmtp con gli stessi valori DEVONO essere presenti nella risposta se il formato che descrivono è presente nella risposta. Altri parametri fmtp sono più simili a parametri generici, per i quali è accettabile che ogni agente usi valori diversi. In tal caso la risposta PUÒ contenere parametri fmtp, con gli stessi valori dell'offerta o diversi. Le estensioni SDP che definiscono nuovi parametri DOVREBBERO specificare l'interpretazione corretta in offerta/risposta.
Il rispondente PUÒ includere un attributo ptime non nullo per qualsiasi flusso multimediale; indica l'intervallo di pacchettizzazione che desidera ricevere. Non è richiesto che l'intervallo sia uguale in entrambe le direzioni per un dato flusso.
Il rispondente PUÒ includere un attributo di larghezza di banda per qualsiasi flusso; indica la larghezza di banda che desidera che l'offerente usi quando invia media. Il valore zero è consentito, interpretato come nella Sezione 5.
Se il rispondente non ha formati in comune per un particolare flusso offerto, DEVE rifiutare quel flusso impostando la porta a zero.
Se non c'è alcun formato in comune per tutti i flussi, l'intera sessione offerta è rifiutata.
Una volta inviata la risposta, il rispondente DEVE essere pronto a ricevere media per ogni flusso recvonly descritto in quella risposta. DEVE essere pronto a inviare e ricevere per ogni flusso sendrecv nella risposta e PUÒ inviare media immediatamente. DEVE essere pronto a ricevere per flussi recvonly o sendrecv usando qualsiasi formato elencato per tali flussi nella risposta e PUÒ inviare subito. Quando invia media, DOVREBBE usare un intervallo di pacchettizzazione uguale al valore dell'attributo ptime nell'offerta, se presente. DOVREBBE inviare con larghezza di banda non superiore all'attributo di banda nell'offerta, se presente. DEVE inviare usando un formato presente nell'offerta e anche nella risposta e DOVREBBE usare il formato più preferito nell'offerta che compare anche nella risposta. Nel caso RTP, DEVE usare i numeri di tipo di payload dell'offerta, anche se differiscono da quelli della risposta.