Passa al contenuto principale

Appendix C: Use of SDP for RTSP Session Descriptions (Uso di SDP per le descrizioni di sessione RTSP)

Appendix C: Use of SDP for RTSP Session Descriptions (Uso di SDP per le descrizioni di sessione RTSP)

Il Session Description Protocol (SDP, RFC 2327 [6]) può descrivere flussi o presentazioni in RTSP, limitato a mezzi di accesso e codifiche.

Controllo aggregato : presentazione con flussi da uno o più server non disponibili per controllo aggregato ; descrizione tipicamente recuperata via HTTP o altro non-RTSP, oppure con ANNOUNCE.

Controllo non aggregato : più flussi da un singolo server con controllo aggregato ; descrizione tipicamente in risposta DESCRIBE su un URL o ricevuta con ANNOUNCE.

Questo appendice spiega come un file SDP ottenuto via HTTP determini il funzionamento della sessione RTSP e come il client interpreti il SDP nelle risposte DESCRIBE. SDP non consente di distinguere, senza guida umana, tra più flussi multimediali da riprodurre simultaneamente e un insieme di alternative (es. due tracce audio in lingue diverse).

C.1 Definitions

I termini «session-level», «media-level» e gli altri nomi/valori di attributo si usano come definito in SDP (RFC 2327 [6]).

C.1.1 Control URL

L'attributo a=control: trasporta l'URL di controllo (sessione e media). A livello media : URL per controllare quel flusso ; a livello sessione : URL per controllo aggregato.

Esempio : a=control:rtsp://example.com/foo

URL relative o assolute secondo RFC 1808 [25]. Ordine per URL di base : campo Content-Base RTSP, Content-Location RTSP, URL della richiesta RTSP. Solo asterisco : URL incorporato vuoto, eredita l'intera base.

C.1.2 Media streams

Il campo m= enumera i flussi ; si presume che tutti siano resi con sincronizzazione appropriata. In unicast il numero di porta è una raccomandazione ; il client deve comunque includerlo in SETUP e può ignorarla. Senza preferenze il server DOVREBBE impostare la porta a zero.

C.1.3 Payload type(s)

Specificati in m=. Tipo statico RFC 1890 [1] : nessun'altra informazione. Tipo dinamico : attributo media rtpmap. Il nome di codifica può essere uno di RFC 1890 (§5–6) o codifica sperimentale con prefisso «X-» in SDP. Parametri specifici del codec in fmtp. Nuove codifiche : procedura RFC 1890 [1]. Se il tipo non si adatta al profilo RTP/AVP, creare un nuovo profilo e usare il nome appropriato in m=.

C.1.4 Format-specific parameters

Parametri specifici del formato con attributo media fmtp ; sintassi dipendente dalle codifiche ; intervallo di pacchettizzazione con ptime.

C.1.5 Range of presentation

L'attributo a=range definisce l'intervallo temporale totale della sessione memorizzata (sessioni live dedotte da t e r). Salvo durate diverse tra flussi, attributo a livello sessione. Prima l'unità, poi l'intervallo (sezioni 3.5–3.7).

C.1.6 Time of availability

Il campo t= DEVE contenere valori adatti per controllo aggregato e non aggregato. Con controllo aggregato il server DOVREBBE indicare un tempo di stop per cui garantisce la validità della descrizione e un inizio uguale o precedente al DESCRIBE ; PUÒ 0,0 per sempre disponibile. Con controllo non aggregato i valori riflettono il periodo reale secondo la semantica SDP, senza dipendere dalla vita della pagina web.

C.1.7 Connection Information

In SDP il campo c= contiene l'indirizzo di destinazione del flusso ; per unicast on demand e alcuni multicast la destinazione è specificata dal client in SETUP. Senza indirizzo fisso, valore nullo appropriato ; per «IP4» : 0.0.0.0.

C.1.8 Entity Tag

L'attributo opzionale a=etag identifica una versione della descrizione (opaco al client). SETUP può includere questo identificatore in If-Match (12.22) per consentire l'avvio della sessione solo se il valore corrisponde ancora alla descrizione corrente.

Si può sostenere che o= offra la stessa funzione ma vincola i server che supportano più tipi di descrizione oltre SDP per lo stesso contenuto.

C.2 Aggregate Control Not Available

Se la presentazione non supporta il controllo aggregato e sono specificate più sezioni media, ogni sezione DEVE avere l'URL di controllo tramite a=control:.

Esempio:

v=0 o=- 2890844256 2890842807 IN IP4 204.34.34.32 s=I came from a web page t=0 0 c=IN IP4 0.0.0.0 m=video 8002 RTP/AVP 31 a=control:rtsp://audio.com/movie.aud m=audio 8004 RTP/AVP 3 a=control:rtsp://video.com/movie.vid

La posizione degli URL implica sessioni di controllo RTSP separate verso audio.com e video.com.

Si raccomanda un file SDP con informazioni complete di inizializzazione media anche se consegnato fuori RTSP.

C.3 Aggregate Control Available

Il server ha più flussi controllabili come intero. Attributi a=control: a livello media (URL dei flussi) e a livello sessione (URL di richiesta per controllo aggregato). Se l'URL media è relativo, risolverlo in assoluto come in C.1.1.

Se la presentazione ha un solo flusso, l'attributo a=control: a livello media può essere omesso. Se più di un flusso, ogni sezione media DEVE contenere il proprio a=control:.

Esempio:

v=0 o=- 2890844256 2890842807 IN IP4 204.34.34.32 s=I contain i= t=0 0 c=IN IP4 0.0.0.0 a=control:rtsp://example.com/movie/ m=video 8002 RTP/AVP 31 a=control:trackID=1 m=audio 8004 RTP/AVP 3 a=control:trackID=2

Il client stabilisce una singola sessione RTSP al server e usa rtsp://example.com/movie/trackID=1 e trackID=2 per configurare video e audio ; rtsp://example.com/movie/ controlla l'intero film.