1 Introduzione
1 Introduzione
1.1 Purpose
Il Real-Time Streaming Protocol (RTSP) stabilisce e controlla uno o piu flussi di media continui sincronizzati nel tempo, come audio e video. Di solito non consegna esso stesso i flussi continui, sebbene sia possibile intrecciare il flusso di media continui con il flusso di controllo (vedere la Sezione 10.12). In altre parole, RTSP funge da "telecomando di rete" per i server multimediali.
L'insieme dei flussi da controllare e definito da una descrizione di presentazione. Questo memorandum non definisce un formato per una descrizione di presentazione.
Non esiste il concetto di connessione RTSP; al contrario, un server mantiene una sessione identificata da un identificatore. Una sessione RTSP non e in alcun modo legata a una connessione a livello di trasporto come una connessione TCP. Durante una sessione RTSP, un client RTSP puo aprire e chiudere molte connessioni di trasporto affidabili verso il server per inviare richieste RTSP. In alternativa, puo usare un protocollo di trasporto senza connessione come UDP.
I flussi controllati da RTSP possono usare RTP [1], ma il funzionamento di RTSP non dipende dal meccanismo di trasporto usato per i media continui. Il protocollo e intenzionalmente simile per sintassi e operazioni a HTTP/1.1 [2], cosi che i meccanismi di estensione HTTP nella maggior parte dei casi possano essere aggiunti anche a RTSP. Tuttavia, RTSP differisce da HTTP in diversi aspetti importanti:
- RTSP introduce diversi nuovi metodi e ha un identificatore di protocollo diverso. * Un server RTSP deve mantenere stato per impostazione predefinita in quasi tutti i casi, a differenza della natura stateless di HTTP. * Sia un server RTSP sia un client possono inviare richieste. * I dati sono trasportati fuori banda con un protocollo diverso. (Vi e un'eccezione.) * RTSP e definito per usare ISO 10646 (UTF-8) anziche ISO 8859-1, in linea con gli attuali sforzi di internazionalizzazione HTML [3]. * Il Request-URI contiene sempre l'URI assoluto. Per retrocompatibilita con un errore storico, HTTP/1.1 [2] porta solo il percorso assoluto nella richiesta e colloca il nome host in un campo header separato.
Cio rende piu semplice il "virtual hosting", in cui un singolo host con un indirizzo IP ospita piu alberi di documenti.
Il protocollo supporta le seguenti operazioni:
Recupero di media da un server media: Il client puo richiedere una descrizione di presentazione via HTTP o altro metodo. Se la presentazione e in multicast, la descrizione di presentazione contiene gli indirizzi multicast e le porte da usare per i media continui. Se la presentazione deve essere inviata solo al client via unicast, il client fornisce la destinazione per motivi di sicurezza.
Invito di un server media a una conferenza: Un server media puo essere "invitato" a unirsi a una conferenza esistente, per riprodurre media nella presentazione o per registrare tutto o parte dei media in una presentazione. Questa modalita e utile per applicazioni di didattica distribuita. Piu partecipanti nella conferenza possono alternarsi nel "premere i pulsanti del telecomando".
Aggiunta di media a una presentazione esistente: In particolare per presentazioni live, e utile che il server possa informare il client di ulteriori media disponibili.
Le richieste RTSP possono essere gestite da proxy, tunnel e cache come in HTTP/1.1 [2].
1.2 Requirements
Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in RFC 2119 [4].
1.3 Terminology
Parte della terminologia e stata adottata da HTTP/1.1 [2]. I termini non elencati qui sono definiti come in HTTP/1.1.
Aggregate control: Il controllo di piu flussi usando una singola linea temporale da parte del server. Per flussi audio/video, cio significa che il client puo inviare un unico messaggio play o pause per controllare sia l'audio sia il video.
Conference: una presentazione multipartecipante e multimediale, dove "multi" implica maggiore o uguale a uno.
Client: Il client richiede dati di media continui dal server media.
Connection: Un circuito virtuale a livello di trasporto stabilito tra due programmi ai fini della comunicazione.
Container file: Un file che puo contenere piu flussi di media che spesso costituiscono una presentazione se riprodotti insieme. I server RTSP possono offrire controllo aggregato su questi file, sebbene il concetto di file contenitore non sia incorporato nel protocollo.
Continuous media: Dati in cui esiste una relazione temporale tra sorgente e sink; cioe il sink deve riprodurre la relazione temporale esistita alla sorgente. Gli esempi piu comuni di media continui sono audio e video in movimento. I media continui possono essere in tempo reale (interattivi), con una relazione temporale "stretta" tra sorgente e sink, o in streaming (riproduzione), con relazione meno rigida.
Entity: Le informazioni trasferite come payload di una richiesta o risposta. Un'entita consiste in metainformazioni come campi entity-header e contenuto come entity-body, come descritto nella Sezione 8.
Media initialization: Inizializzazione specifica per tipo di dati/codec. Include elementi come frequenze di clock, tabelle colori, ecc. Qualsiasi informazione indipendente dal trasporto richiesta da un client per la riproduzione di un flusso media avviene nella fase di inizializzazione media dell'impostazione del flusso.
Media parameter: Parametro specifico per un tipo di media che puo essere modificato prima o durante la riproduzione del flusso.
Media server: Il server che fornisce servizi di riproduzione o registrazione per uno o piu flussi di media. Flussi di media diversi nella stessa presentazione possono provenire da server media diversi. Un server media puo risiedere sullo stesso host o su un host diverso dal server web da cui la presentazione e invocata.
Media server indirection: Reindirizzamento di un client media verso un server media diverso.
(Media) stream: Una singola istanza di media, ad esempio un flusso audio o video, nonche una singola lavagna o gruppo di applicazioni condivise. Usando RTP, un flusso consiste in tutti i pacchetti RTP e RTCP creati da una sorgente in una sessione RTP. Equivale alla definizione di flusso DSM-CC ([5]).
Message: L'unita base di comunicazione RTSP, costituita da una sequenza strutturata di ottetti conforme alla sintassi definita nella Sezione 15 e trasmessa via connessione o protocollo senza connessione.
Participant: Membro di una conferenza. Un partecipante puo essere una macchina, ad esempio un server di registrazione o riproduzione media.
Presentation: Un insieme di uno o piu flussi presentati al client come feed media completo, usando una descrizione di presentazione come definito sotto. Nella maggior parte dei casi nel contesto RTSP, cio implica controllo aggregato di tali flussi, ma non e obbligatorio.
Presentation description: Una descrizione di presentazione contiene informazioni su uno o piu flussi di media in una presentazione, come insiemi di codifiche, indirizzi di rete e informazioni sul contenuto. Altri protocolli IETF come SDP (RFC 2327 [6]) usano il termine "session" per una presentazione live. La descrizione di presentazione puo assumere diversi formati, incluso ma non limitato al formato SDP.
Response: Una risposta RTSP. Se si intende una risposta HTTP, cio e indicato esplicitamente.
Request: Una richiesta RTSP. Se si intende una richiesta HTTP, cio e indicato esplicitamente.
RTSP session: Una "transazione" RTSP completa, ad esempio la visione di un film. Una sessione tipicamente consiste nel client che imposta un meccanismo di trasporto per il flusso di media continui (SETUP), avvia il flusso con PLAY o RECORD e chiude il flusso con TEARDOWN.
Transport initialization: La negoziazione delle informazioni di trasporto (ad esempio numeri di porta, protocolli di trasporto) tra client e server.
1.4 Protocol Properties
RTSP ha le seguenti proprieta:
Extendable: Nuovi metodi e parametri possono essere aggiunti facilmente a RTSP.
Easy to parse: RTSP puo essere analizzato da parser HTTP o MIME standard.
Secure: RTSP riutilizza i meccanismi di sicurezza web. Tutti i meccanismi di autenticazione HTTP come basic (RFC 2068 [2, Sezione 11.1]) e digest (RFC 2069 [8]) sono direttamente applicabili. Si possono anche riutilizzare meccanismi di sicurezza a livello di trasporto o rete.
Transport-independent: RTSP puo usare un protocollo datagramma non affidabile (UDP) (RFC 768 [9]), un protocollo datagramma affidabile (RDP, RFC 1151, poco usato [10]) o un protocollo a flusso affidabile come TCP (RFC 793 [11]) perche implementa affidabilita a livello applicativo.
Multi-server capable: Ogni flusso di media in una presentazione puo risiedere su un server diverso. Il client stabilisce automaticamente piu sessioni di controllo concorrenti con i diversi server media. La sincronizzazione dei media avviene a livello di trasporto.
Control of recording devices: Il protocollo puo controllare sia dispositivi di registrazione sia di riproduzione, nonche dispositivi che possono alternare tra le due modalita ("VCR").
Separation of stream control and conference initiation: Il controllo del flusso e separato dall'invito di un server media a una conferenza. L'unico requisito e che il protocollo di avvio conferenza fornisca o possa essere usato per creare un identificatore di conferenza univoco. In particolare, SIP [12] o H.323 [13] possono essere usati per invitare un server a una conferenza.
Suitable for professional applications: RTSP supporta accuratezza a livello di frame tramite timestamp SMPTE per consentire editing digitale remoto.
Presentation description neutral: Il protocollo non impone un particolare formato di descrizione di presentazione o metafile e puo comunicare il tipo di formato da usare. Tuttavia, la descrizione di presentazione deve contenere almeno un URI RTSP.
Proxy and firewall friendly: Il protocollo dovrebbe essere gestibile facilmente da firewall a livello applicativo e di trasporto (SOCKS [14]). Un firewall puo dover comprendere il metodo SETUP per aprire un "buco" per il flusso media UDP.
HTTP-friendly: Dove sensato, RTSP riusa concetti HTTP, cosi che l'infrastruttura esistente possa essere riutilizzata. Questa infrastruttura include PICS (Platform for Internet Content Selection [15,16]) per associare etichette ai contenuti. Tuttavia, RTSP non si limita ad aggiungere metodi a HTTP perche il controllo dei media continui richiede stato del server nella maggior parte dei casi.
Appropriate server control: Se un client puo avviare un flusso, deve poterlo fermare. I server non dovrebbero iniziare lo streaming verso i client in modo che i client non possano fermare il flusso.
Transport negotiation: Il client puo negoziare il metodo di trasporto prima di dover effettivamente elaborare un flusso di media continui.
Capability negotiation: Se le funzionalita di base sono disabilitate, deve esistere un meccanismo chiaro affinche il client determini quali metodi non saranno implementati. Cio consente ai client di presentare l'interfaccia utente appropriata. Ad esempio, se il seeking non e consentito, l'interfaccia deve poter impedire lo spostamento di un indicatore di posizione scorrevole.
Un requisito precedente in RTSP era la capacita multi-client. Tuttavia, si e ritenuto migliore assicurare che il protocollo sia facilmente estendibile allo scenario multi-client. Gli identificatori di flusso possono essere usati da piu flussi di controllo, cosi che sia possibile "passare il telecomando". Il protocollo non affronta come piu client negoziano l'accesso; cio e lasciato a un "protocollo sociale" o ad altro meccanismo di controllo del pavimento.
1.5 Extending RTSP
Poiche non tutti i server media hanno la stessa funzionalita, i server media supporteranno necessariamente insiemi diversi di richieste. Ad esempio:
- Un server puo essere capace solo di riproduzione e quindi non ha bisogno di supportare RECORD. * Un server puo non essere capace di seeking (posizionamento assoluto) se deve supportare solo eventi live. * Alcuni server potrebbero non supportare l'impostazione dei parametri di flusso e quindi non supportare GET_PARAMETER e SET_PARAMETER.
Un server DOVREBBE implementare tutti i campi header descritti nella Sezione 12.
Spetta ai creatori delle descrizioni di presentazione non chiedere l'impossibile a un server. La situazione e simile in HTTP/1.1 [2], dove i metodi descritti in [H19.6] probabilmente non sono supportati da tutti i server.
RTSP puo essere esteso in tre modi, elencati qui per ordine di entita delle modifiche supportate:
- I metodi esistenti possono essere estesi con nuovi parametri, purché tali parametri possano essere ignorati in sicurezza dal destinatario. (Equivale ad aggiungere parametri a un tag HTML.) Se il client ha bisogno di un riscontro negativo quando un'estensione di metodo non e supportata, un tag corrispondente all'estensione puo essere aggiunto nel campo Require: (vedere Sezione 12.32). * Si possono aggiungere nuovi metodi. Se il destinatario del messaggio non comprende la richiesta, risponde con codice di errore 501 (Not implemented) e il mittente non dovrebbe tentare di usare di nuovo quel metodo. Un client puo anche usare OPTIONS per chiedere quali metodi supporta il server. Il server DOVREBBE elencare i metodi supportati usando l'header di risposta Public. * Si puo definire una nuova versione del protocollo, consentendo di cambiare quasi tutti gli aspetti (salvo la posizione del numero di versione del protocollo).
1.6 Overall Operation
Ogni presentazione e flusso di media puo essere identificato da un URL RTSP. La presentazione complessiva e le proprieta dei media di cui e composta sono definite da un file di descrizione di presentazione, il cui formato e fuori dall'ambito di questa specifica. Il file di descrizione di presentazione puo essere ottenuto dal client usando HTTP o altri mezzi come email e non deve necessariamente risiedere sul server media.
Ai fini di questa specifica, si assume che una descrizione di presentazione descriva una o piu presentazioni, ciascuna con un asse temporale comune. Per semplicita espositiva e senza perdita di generalita, si assume che la descrizione di presentazione contenga esattamente una tale presentazione. Una presentazione puo contenere piu flussi di media.
Il file di descrizione di presentazione contiene una descrizione dei flussi di media che compongono la presentazione, incluse codifiche, lingua e altri parametri che consentono al client di scegliere la combinazione di media piu appropriata. In questa descrizione, ogni flusso di media controllabile individualmente da RTSP e identificato da un URL RTSP che punta al server media che gestisce quel flusso e nomina il flusso memorizzato su quel server. Piu flussi possono trovarsi su server diversi; ad esempio audio e video possono essere suddivisi per bilanciamento del carico. La descrizione elenca anche quali metodi di trasporto il server supporta.
Oltre ai parametri dei media, devono essere determinati indirizzo di destinazione di rete e porta. Si distinguono diverse modalita operative:
Unicast: I media sono trasmessi alla sorgente della richiesta RTSP, con numero di porta scelto dal client. In alternativa, i media sono trasmessi sullo stesso flusso affidabile di RTSP.
Multicast, server chooses address: Il server media sceglie indirizzo multicast e porta. Tipico per trasmissione live o quasi media-on-demand.
Multicast, client chooses address: Se il server deve partecipare a una conferenza multicast esistente, indirizzo multicast, porta e chiave di cifratura sono forniti dalla descrizione di conferenza, stabilita con mezzi fuori dall'ambito di questa specifica.
1.7 RTSP States
RTSP controlla un flusso che puo essere inviato tramite un protocollo separato, indipendente dal canale di controllo. Ad esempio, il controllo RTSP puo avvenire su TCP mentre i dati passano via UDP. Cosi la consegna dei dati continua anche se il server media non riceve richieste RTSP. Inoltre, durante la sua vita, un singolo flusso di media puo essere controllato da richieste RTSP emesse in sequenza su connessioni TCP diverse. Pertanto il server deve mantenere uno "stato di sessione" per correlare le richieste RTSP a un flusso. Le transizioni di stato sono descritte nella Sezione A.
Molti metodi in RTSP non contribuiscono allo stato. Tuttavia, i seguenti hanno un ruolo centrale nell'allocazione e nell'uso delle risorse di flusso sul server: SETUP, PLAY, RECORD, PAUSE e TEARDOWN.
SETUP: Fa si che il server allochi risorse per un flusso e avvii una sessione RTSP.
PLAY e RECORD: Avviano la trasmissione dati su un flusso allocato via SETUP.
PAUSE: Sospende temporaneamente un flusso senza liberare le risorse del server.
TEARDOWN: Libera le risorse associate al flusso. La sessione RTSP cessa di esistere sul server.
I metodi RTSP che contribuiscono allo stato usano il campo header Session (Sezione 12.37) per identificare la sessione RTSP il cui stato viene manipolato. Il server genera identificatori di sessione in risposta alle richieste SETUP (Sezione 10.4).
1.8 Relationship with Other Protocols
RTSP ha una certa sovrapposizione funzionale con HTTP. Puo anche interagire con HTTP nel senso che il primo contatto con contenuto in streaming avviene spesso tramite una pagina web. La presente specifica di protocollo mira a consentire diversi punti di passaggio tra un server web e il server media che implementa RTSP. Ad esempio, la descrizione di presentazione puo essere recuperata con HTTP o RTSP, riducendo round-trip in scenari basati su browser, consentendo anche server e client RTSP standalone che non dipendono da HTTP.
Tuttavia, RTSP differisce fondamentalmente da HTTP perche la consegna dei dati avviene fuori banda con un protocollo diverso. HTTP e asimmetrico: il client invia richieste e il server risponde. In RTSP sia il client media sia il server media possono inviare richieste. Le richieste RTSP non sono stateless; possono impostare parametri e continuare a controllare un flusso di media molto dopo che la richiesta e stata accettata.
Riutilizzare funzionalita HTTP ha vantaggi in almeno due aree, sicurezza e proxy. I requisiti sono molto simili, quindi poter adottare il lavoro HTTP su cache, proxy e autenticazione e prezioso.
Sebbene la maggior parte dei media in tempo reale usera RTP come protocollo di trasporto, RTSP non e legato a RTP.
RTSP assume l'esistenza di un formato di descrizione di presentazione in grado di esprimere proprieta statiche e temporali di una presentazione con piu flussi di media.