RETI INTERNET MULTIMEDIALI. Protocolli di trasporto e applicativi

RETI INTERNET MULTIMEDIALI Protocolli di trasporto e applicativi

Protocolli di trasporto Protocolli end-to-end User Datagram Protocol Servizi, formati, controllo errore, porte Transmission Control Protocol Servizi, entità protocollari, formati Instaurazione della connessione Scelta del numero di sequenza Abbattimento della connessione Stima del time-out di ri-trasmissione Controllo di flusso a finestra Controllo della congestione

Protocolli end-to-end I sistemi terminali o host Conoscono le applicazioni Spesso conoscono la propria esigenza di capacità di rete in funzione delle applicazioni Non conoscono la capacità di rete effettivamente disponibile Non sono consapevoli della competizione nell uso delle risorse di rete I protocolli end-to-end interessano gli host e non i router ed arricchiscono il servizio offerto dallo strato di rete del modello OSI Il livello di trasporto è il primo livello end-to-end (livello 4 del modello OSI)

Livello di trasporto 7 6 5 4 3 2 1 Application Presentation Session Transport Network Link Physical layer-to-layer communication Peer-layer communication Router Router Network Network Link Link Physical Physical Application Presentation Session Transport Network Link Physical 7 6 5 4 3 2 1

Due protocolli di trasporto principali User Datagram Protocol (UDP) Trasporto inaffidabile Il valore aggiunto al servizio di rete non include: garanzie sulla consegna dei dati al destinatario meccanismi espliciti per sopperire alle carenze del servizio di rete dal punto di vista dell affidabilità del trasporto dei dati e2e Transmission Control Protocol (TCP) Trasporto affidabile La protocol data unit del livello di trasporto Internet TCP si chiama segmento

Incapsulamento Application Message TCP Segment TCP hdr MSS TCP data IP Packet IP hdr 20 bytes IP data Ethernet Frame Ethernet 20 bytes Ethernet data 14 bytes MTU 1500 bytes MSS: Maximum Segment Size; MTU: Maximum Transfer Unit 4 bytes

User Datagram Protocol RFC 768 Offre un servizio connectionless L invio di dati in rete non è preceduto dalla fase di apertura di una connessione Orientato al messaggio Conserva i confini della PDU di trasporto Privo di stato Trasmettitore e ricevitore non mantengono alcuno stato per scambi di dati basati su UDP Trasporto inaffidabile Non offre: Rilevamento di perdita o duplicazione di dati Ri-trasmissione dei dati persi Consegna in sequenza Controllo di flusso

Servizi offerti da UDP Multiplazione di flussi di pacchetti da/verso più applicazioni contemporaneamente attive in un host Rilevamento errore opzionale Incluso, rilevamento degli errori di consegna grazie all impiego di uno pseudoheader nella fase di calcolo del checksum UDP è adatto ad offrire il servizio di trasporto ad applicazioni: orientate alle transazioni (gestione: SNMP, naming service: DNS, file transfer elementare: TFTP) tolleranti rispetto alla perdita ma sensibili alla quantità di dati trasferita nell unità di tempo ed al ritardo (streaming audio e video, voce: RTSP, RTP) B1 App UDP B2 App

Header del segmento UDP SOURCE PORT (16 bit): porta del processo applicativo che invia i dati DESTINATION PORT (16 bit): porta del processo applicativo destinatario dei dati MESSAGE LENGTH (16 bit): indica, in numero di byte, la lunghezza del pacchetto UDP, incluso header UDP CHECKSUM (16 bit): campo di controllo dell errore opzionale (tutti 0 se non usato) IP Datagram UDP Segment IP Header UDP Header UDP Data 20 bytes 8 bytes

Formato del segmento UDP 16-bit Source Port 16-bit UDP Length 16-bit Destination Port 16-bit UDP Checksum (opt) 8 Bytes Data (if any) IP Header UDP Header UDP Data IP Header UDP Header IP Pesudo-Header UDP Data

Controllo dell errore Il mittente: Considera il segmento UDP con appeso lo pseudoheader come una sequenza di parole di 16bit (appendo eventuale padding) Inserisce tutti 0 nel checksum Somma le parole con aritmetica in complemento a 1 Inserisce il risultato del complemento a 1 della somma nel checksum Il destinatario: Riceve il segmento UDP e, dopo aver aggiunto lo pseudoheader, opera la somma in complemento a 1 delle parole di 16 bit Se il risultato è tutti 1, la verifica del checksum è OK In caso contrario, la verifica del checksum è NOK: Rilevato errore o consegna errata

Verifica checksum

Pseudoheader 32-bit Source IP address 32-bit Destination IP address Zero Protocol UDP 16-bit UDP Length 16-bit Source Port 16-bit UDP Length 16-bit Destination Port 16-bit UDP Checksum (opt) Data (if any) 0100 Possible odd byte PAD 1 8 16 19 24 Version (4 bits) Header Length Time to Live (8 bits) 8 16 19 24 32 TOS (8 bits) (4 bits) Identification (16 bits) Total Length (16 bits) Flags (3) Fragment Offset (13 bits) Protocol (8 bits) 1=ICMP, 6=TCP, Header Checksum (16 bits) 17=UDP Source IP Address (32 bits) Destination IP Address (32 bits) Options (if any) Padding 20 byte

Rilevo destinazione errata Usa UDP come protocollo Host destinazione IP 1.2.3.4, usata nel computo del checksum UDP Router Lo strato IP compromette l indirizzo di destinazione IP e lo trasforma in 1.2.3.5 Il pacchetto IP arriva alla destinazione errata 1.2.3.5. (assumiamo che esista ) Viene anche calcolato il checksum dell header IP coerentemente UDP usa lo pseudo header per fare la validazione a livello trasporto Transport Layer Lo strato IP valida il checksum dell header IP Non viene validato il checksum ( in quanto era stato calcolato con l indirizzo di destinazione IP 1.2.3.4) Messaggio UDP scartato Il checksum ricevuto non corrisponde a quello calcolato usando lo pseudoheader Scarto messaggio UDP

Porte standard UDP

Transmission Control Protocol RFCs: 793, 1122, 1323, 2018, 2581 Servizio end-to-end orientato alla connessione Orientato al flusso di byte Garantisce la consegna sequenziale il recupero dei dati persi o corrotti l eliminazione dei duplicati Offre la multiplazione di più flussi contemporanei che interessano lo stesso host Trasmissione full duplex Offre funzioni per trasmissioni privilegiate

TCP è orientato alla connessione TCP offre un servizio orientato alla connessione creando un associazione tra host sorgente e host destinatario Poiché lo strato di rete IP è connectionless, non vi è traccia della connessione nei nodi di rete User User Connessione end-to-end TCP IP TCP IP Nessuna connessione

Meccanismi del TCP Instaurazione della connessione Scelta del numero di sequenza Abbattimento della connessione Stima del time-out di ritrasmissione Controllo di flusso a finestra

Apertura della connessione L entità protocollare TCP comunica con: Il processo applicativo locale per stabilire:» Tipo di connessione» Parametri del trasferimento in rete L entità paritetica corrispondente sull host remoto per:» Assicurarsi che siano disponibili ed allocate risorse» Confermare che la richiesta di connessione sia mutuamente accettata» Identificare le porte cui associare i dati» Veicolare i parametri del trasferimento

Handshake a tre vie Il processo applicativo invia una primitiva Open all entità TCP locale L entità TCP locale risponde con una primitiva Open ID ed invia un comando di sincronizzazione (SYN) all entità paritetica remota e comunica il numero di sequenza iniziale prescelto L entità TCP remota risponde con un riscontro (SYN, ACK) e sceglie e comunica il proprio numero di sequenza iniziale L entità TCP locale invia il riscontro (ACK) dell avvenuta ricezione della disponibilità ad aprire la connessione

Handshake a tre vie SYN 1742: Richiedo connessione su porta 17 Usero 1742 come numero di sequenza iniziale TCP su client SYN 2856,ACK 1743: Ok, ricevo che il tuo numero di sequenza iniziale è 1742. Userò 2856 come mio numero di sequenza iniziale TCP su server ACK 2857: Ok, ho ricevuto che il tuo numero di sequenza iniziale è 2856. Scambio dati susseguente...1748 1747 1746 1745 1744 1743 2857 2858 2859 2860 2861 2862 2863...

Vantaggi dell handshake a tre vie Previene le false connessioni Rileva riscontri di richiesta di apertura connessione ritardati o duplicati Posso includere dati nel terzo messaggio di apertura della connessione

Abbattimento graceful Una delle due applicazioni in comunicazione passa una primitiva CLOSE all entità TCP locale L entità TCP informa l entità protocollare corrispondente e svuota la coda di trasmissione L entità remota informa il processo applicativo e trasmette i dati accodati Viene riscontrata la richiesta di abbattimento non appena non vi sono più dati accodati Non appena l entità che ha richiesto l abbattimento riceve il riscontro, passa una primitiva TERMINATE al processo applicativo locale L entità locale invia un riscontro all entità remota e rilascia le risorse L entità remota riceve il riscontro e passa una primitiva TERMINATE al processo applicativo corrispondente

Esempio abbattimento FIN 1755: Ho terminato i dati da trasmettere e chiedo l abbattimento della connessione. Please acknowledge. TCP su client ACK 1756: Ok, non attendo più dati. FIN 2869: Ho terminato i dati da trasmettere, chiedo l abbattimento della connessione. Please acknowledge. TCP su server ACK 2870: Ok, non attendo più dati. 1754 1753 1752 1751 1750 1749 1748......2863 2864 2865 2866 2867 2868

Chiusura abrupta della connessione Cause» Chiusura brutale per esaurimento risorse» Scade il give-up timer» Iniziativa del processo applicativo Non si accettano ulteriori dati sulla connessione L entità protocollare TCP usa la primitiva ABORT per informare il processo applicativo

Connection management BEGIN/socket() Server Passive Open bind(),listen(),accept() CLOSED Close() Client Active Open connect() send SYN rcv SYN send SYN,ACK LISTEN Active Open send SYN Close() send FIN SYN-RCVD rcv ACK of SYN Close() send FIN rcv RST ESTABLISHED rcv SYN send SYN,ACK rcv SYN,ACK send ACK SYN-SENT Close() rcv ACK FIN-WAIT-1 FIN-WAIT-2 rcv FIN send ACK rcv FIN,ACK send ACK CLOSING rcv ACK rcv FIN send ACK Close() send FIN CLOSE-WAIT LAST-ACK rcv ACK rcv FIN send ACK TIME-WAIT timer ~ 2 min

Formato del segmento TCP 1 16 17 32 Source port (16) Destination port (16) Sequence number (32) Header length (4) Acknowledgement number (32) Reserved (6) Flags (6) Window (16) Checksum (16) Urgent Pointer (16) Options (0 or 32 if any) 20 Bytes Data (varies)

Header del segmento TCP SOURCE PORT (16 bit): porta sull host sorgente DESTINATION PORT (16 bit): porta sull host destinatario SEQUENCE NUMBER (16 bit): numero del primo byte nel segmento o numero di sequenza iniziale usato per una connessione ACKNOWLEDGMENT NO. (32 bit): numero di sequenza del prossimo byte che l host si attende di ricevere HEADER LENGTH (4 bit): numero di parole di 32-bit che compongono l header RESERVED (6 bit): riservati ad usi futuri FLAGS (6 bit): ognuno dei sei bit ha un significato particolare se posto ad 1 WINDOW (16 bit): numero massimo di byte che l host è disposto a ricevere CHECKSUM (16 bit): campo di rilevamento dell errore URGENT POINTER (16 bit): punta all ultimo byte della porzione dei dati contenenti dati urgenti (possono trasgredire i limiti dei controlli di flusso)

FLAG URG il segmento contiene anche dati urgenti ACK il segmento contiene un riscontro PHS funzione di PUSH (i dati devono essere trasmessi o passati allo strato applicativo ricevente immediatamente) RST messaggio di reset di una connessione SYN sincronizzazione dei numeri di sequenza e dei parametri per una connessione FIN il mittente non ha ulteriori dati da inviare e chiede l abbattimento della connessione

Header TCP evoluto

Opzioni del TCP Opzione Maximum Segment Size (MSS): Dimensione massima del segmento, scelta in modo da evitare la frammentazione a livello IP In fase di instaurazione della connessione, ogni entità esplicita nell opzione Maximum Segment Size la MSS gradita (default 576-40=536 byte) Il valore di MSS gradito è determinato in funzione della Maximum Transmission Unit delle reti fisiche interposte tra sorgente e destinazione Opzione Window scaling Attraverso l applicazione di un fattore di scala consente di ampliare la dimensione delle finestre Il fattore di scala indica la dimensione dello shift da applicare al numero di 16 bit che rappresenta in byte la finestra W Window scale: Window = W 2 Scale (W finestra in byte)

Opzioni del TCP End of option list kind =0 No Operation kind =1 2 bytes Max Segment Size kind =2 len=4 Max Seg Size Window Scale Factor kind =3 len=3 shift count 1 byte Timestamp kind =8 len=10 timestamp value timestamp echo reply 1 byte 1 byte 4 bytes 4 bytes

Controllo dell errore in TCP Controllo dell errore obbligatorio su intestazione e campo dati del segmento TCP per UDP il controllo è opzionale! IP ha un controllo dell errore limitato all header I segmenti in cui si rilevano errori vengono eliminati e quindi non viene inviato riscontro L assenza di riscontro provoca la ritrasmissione, trascorso un dato time-out Il controllo dell errore è basato sul calcolo e sulla verifica del campo checksum, in modo analogo all UDP

Ripristino sequenza e scarto duplicati Basati sul numero di sequenza dei segmenti ricevuti L entità TCP ricevente memorizza i segmenti pervenuti fuori sequenza e ne ripristina l ordine Analogamente scarta i segmenti pervenuti in multipla copia 4 3 2 1 4 3 2 1 TCP TCP IP IP 4 3 2 3 1

Porte standard TCP

Numerazione Ogni byte nel campo dati di un segmento TCP ha un numero di sequenza La duplicazione dei numeri di sequenza è scongiurata attraverso una opportuna scelta del numero iniziale e un tempo di riciclo ampio I numeri di sequenza sono un elemento cardine del ripristino della sequenza, del riscontro dei dati ricevuti, della ritrasmissione e del controllo di flusso Il riscontro TCP indica il prossimo byte che ci si attende di ricevere per proseguire una sequenza ininterrotta (ack cumulativo)

Initial sequence number (ISN) La scelta del numero di sequenza iniziale non è indifferente in quanto ha l obiettivo di evitare che segmenti in forte ritardo vengano ricevuti creando ambiguità Si usa un orologio locale per selezionare l ISN in modo pseudocasuale, con l avvertenza che il wraparound dell orologio (ossia il ritorno sugli stessi valori) sia più grande del tempo massimo di vita del segmento Si impiega un contatore di 32 bit incrementato ogni 4 microsecondi Il rischio di ricopertura dei numeri di sequenza si ha nelle reti a larga banda in cui rapidamente avanzano i numeri di sequenza

Tempo di wraparound dei numeri di sequenza Correndo su 32 bit, il tempo di ricopertura del numero di sequenza dipende dalla velocità di trasmissione Per ovviare al problema il ricevitore considera il timestamp come una discriminante: scarto dati fuori-sequenza sia sulla base del numero di sequenza che del timestamp Bandwidth T1 (1.5Mbps) Ethernet (10Mbps) T3 (45Mbps) FDDI (100Mbps) STS-3 (155Mbps) STS-12 (622Mbps) STS-24 (1.2Gbps) Time to Wraparound 6.4 hours 57 minutes 13 minutes 6 minutes 4 minutes 55 seconds 28 seconds

Principi del trasporto affidabile Ogni volta che si trasmette un segmento se ne tiene copia in un buffer e si avvia un timer Quando il destinatario riceve correttamente un segmento, risponde con un riscontro o acknowledgment (ack) in cui indica il numero di sequenza del prossimo byte atteso al ricevente Se il mittente non riceve il riscontro dei byte contenuti nel segmento entro un determinato tempo limite, tali dati vengono ritrasmessi Buffers, Ack s, Retransmissions, Timeouts =BART

Rilevamento e recupero dell errore Rilevamento di segmenti affetti da errore Copertura su intestazione TCP e campo dati Utilizzo della tecnica di checksum usata per l IP (somma complemento a 1 di parole di 16 bit) Introduzione dello pseudoheader atto ad accertare se la consegna è avvenuta ad una destinazione erronea Il rilevamento dell errore determina lo scarto del segmento senza che vi siano ulteriori notifiche esplicite né all entità paritetica né all entità protocollare di livello superiore Ovviamente il ricevente che opera lo scarto non invia notifica di riscontro per il segmento corrotto La ritrasmissione del segmento scartato, in quanto corrotto, avviene per lo scadere del timeout di ritrasmissione senza che sia pervenuto il riscontro esplicito del segmento

T imeout T imeout T imeout T imeout T imeout T ime T imeout T imeout Casistiche di comportamento Sender Receiver Sender Receiver (a) (c) Sender Receiver Sender Receiver (b) (d)

timeout Seq=100 timeout Seq=92 timeout Esempi di ritrasmissione Host A Host B Host A Host B X loss time lost ACK scenario time premature timeout, cumulative ACKs

Strategia di trasmissione receive window (advertised by receiver) usable window 1 2 3 4 5 6 7 8 9 10 11... sent and acknowledged sent and not ACKed can send ASAP can't send until window moves Size N

Sliding window Il controllo di flusso opera secondo il principio della finestra scorrevole (sliding window) I numeri di sequenza esplicitati dagli ACKs indicano il numero di sequenza del prossimo byte che il ricevente si attende La ricezione di un ACK informa il trasmettitore della possibilità di trasmettere ulteriori dati, compatibilmente con la dimensione della receive window Il meccanismo del windowing opera a livello di byte e non di segmento (usando i sequence number espressi negli ACK per regolare l evoluzione della trasmissione)

Controllo di flusso Il TCP ricevente è responsabile del flusso di dati in ingresso Esso regola la quantità di dati che il trasmettitore gli può inviare attraverso la comunicazione dello spazio di memoria disponibile in ricezione e l invio dei riscontri Il ricevitore decide quanti dati è disposto a ricevere, e lo comunica al trasmettitore Durante la connection setup, ogni partner specifica la dimensione del buffer disponibile al ricevitore (receive window), che è tipicamente un multiplo intero di MSS Per ogni connessione attiva, ogni volta che il ricevente invia un riscontro, esplicita la dimensione della finestra di ricezione disponibile (receive window) La finestra di trasmissione (transmit window) è la parte inutilizzata del buffer di trasmissione, e indica il numero di byte che possono essere trasmessi senza attendere ulteriori riscontri La quantità di dati che il trasmettitore è autorizzato a trasmettere è limitata dalla dimensione della receive window

Il punto di vista del trasmettitore e del ricevitore Sending application Receiving application TCP TCP LastByteWritten LastByteRead LastByteAcked LastByteSent NextByteExpected LastByteRcvd Sending side LastByteAcked < = LastByteSent LastByteSent < = LastByteWritten buffer bytes between LastByteAcked and LastByteWritten Receiving side LastByteRead < NextByteExpected NextByteExpected < = LastByteRcvd +1 buffer bytes between NextByteRead and LastByteRcvd

Le regole del controllo di flusso Sender buffer size: MaxSendBuffer Receive buffer size: MaxRcvBuffer Receiving side LastByteRcvd - NextByteRead <= MaxRcvBuffer ReceiveWindow = MaxRcvBuffer - (LastByteRcvd - NextByteRead) Sending side LastByteSent - LastByteAcked <= ReceiveWindow EffectiveWindow = ReceiveWindow - (LastByteSent - LastByteAcked) LastByteWritten - LastByteAcked <= MaxSendBuffer block sender if (LastByteWritten - LastByteAcked) + y > MaxSendBuffer

Dimensione della finestra La dimensione della finestra ha un effetto importante sulle prestazioni di una connessione TCP Come scegliere la dimensione della finestra all apertura della connessione? Come aggiornarla per ottenere prestazioni ottimali? Una finestra eccessivamente piccola può determinare spreco di risorse (mentre tornano i riscontri il trasmettitore è inattivo) Una finestra eccessivamente grande può determinare il sovraccarico dei router o del destinatario Il valore di default, usato in fase di apertura della connessione è di 4096 bytes La dimensione massima della finestra (Maximum window size) è 65535 bytes (avendo 16 bit nel campo dell header per la finestra)

Finestra e prestazioni Round-trip time Round-trip time Host A Window Size??? Window Size Window Size Host B ACK ACK ACK (1) RTT > Window size (2) RTT = Window size Window size : tempo per trasmettere la dimensione della finestra

Keep the pipe full Il massimo valore della finestra utilizzabile deve consentire di raggiungere la saturazione della rete La maximum window size con 16 bit (64KB= 65535 byte) è limitante in alcuni casi Bandwidth T1 (1.5Mbps) Ethernet (10Mbps) T3 (45Mbps) FDDI (100Mbps) STS-3 (155Mbps) STS-12 (622Mbps) STS-24 (1.2Gbps) Bandwidth-Delay Product (RTT=100msec) 18 KB 122 KB 549 KB 1.2 MB 1.8 MB 7.4 MB 14.3 MB

Windowing in reti LFN Long Fat Pipe Networks (LFN): esempio reti via satellite Necessitano di finestre molto ampie per non incorrere in spreco di risorse Usano la window scale option con uno shift massimo di 14 Max window = 2 30 http://www.ietf.org/rfc/rfc1323.txt L opzione è inviata solo nei segmenti SYN e SYN/ACK RFC 1323 Kind = 3 Length = 3 Scale

Pipelining Il mittente ammette che vi siano molteplici dati in-flight, in attesa di ricevere ack Lo spazio dei numeri di sequenza deve essere esteso Il buffering al ricevente ed al mittente assumono più rilevo

Sindrome della finestra sciocca Situazione degenere in cui la trasmissione risulta essere regolata in modo frammentario e altamente inefficiente Necessità di intervenire sul comportamento del ricevitore e del trasmettitore nel controllo di flusso

Sindrome del ricevente lento L applicazione ricevente rimuove lentamente piccole quantità di dati dal buffer di ricezione quasi pieno (per esempio, 1 byte per volta) Se il ricevitore manda al trasmettitore un aggiornamento della RCVWND per 1 byte ogni volta, il trasmettitore invierà piccoli pacchettini con un grande overhead Proposta di Clark (1982) La soluzione proposta è semplice: il ricevitore non invia aggiornamenti della RCVWND fino a che non si è rimossa una quantità significativa di dati: Il buffer di ricezione è vuoto almeno per metà Oppure nel buffer di ricezione si può accomodare un segmento MSS il ricevitore inganna al trasmettitore indicando una finestra RCWND nulla sino a che il suo buffer di ricezione non si è svuotato per metà o per una porzione almeno pari al MSS Proposta alternativa: delayed ack, ritardare l invio dei riscontri Rischio di causare ritrasmissioni inutili Necessità di limitare il massimo ritardo possibile (500ms)

Sindrome da trasmittente lento L applicazione trasmittente scrive piccole quantità di dati nel buffer di trasmissione vuoto (per esempio, 1 byte per volta) Se il trasmettitore manda un segmento ogni volta che è pronto 1 byte si invieranno piccoli pacchettini con un grande overhead Proposta di Nagle (1984) Il mittente invia la prima porzione di dati, anche se si tratta di 1 solo byte Per l invio di ulteriori dati il trasmittente attende che Ci siano almeno dati per trasmettere un MSS Oppure sia stato ricevuto un ACK Problemi nel caso di protocolli fortemente interattivi: es. tracking della posizione del mouse

Round Trip Time Combinazione di Ritardo di trasmissione dei link interposti tra un terminale e il terminale remoto Ritardo di propagazione su tutte le tratte trasmissive Ritardi di elaborazione e di accodamento in tutti i nodi sul percorso (diretto e inverso) tra un terminale e il terminale remoto

Stima di RTO e RTT Timeout di ritrasmissione, Retransmission Time Out ( RTO), dopo aver inviato un segmento il TCP inizializza un timer ed attende il riscontro. Se il riscontro non arriva entro il periodo di timeout RTO, il TCP ritrasmette il segmento Se il timeout è troppo breve, il trasmettitore riempirà il canale di ritrasmissioni di segmenti, ma se è troppo lungo impedisce il recupero veloce di errori Il reale ritardo di rete dipende dalle condizioni di congestione della rete, per cui fissare un valore di RTO a priori è troppo difficile e critico, perchè il timeout ottimo dipende dalle condizioni Il TCP si adatta alle condizioni reali della rete tramite gli algoritmi di Karn e Jacobson In questi algoritmi, RTO è calcolato dinamicamente misurando il tempo di andata e ritorno Round Trip Time, RTT, definito come il tempo che passa tra la trasmissione di un segmento e la ricezione del relativo riscontro Sulla base delle misure il sender TCP calcola lo Smoothed Round Trip Time (SRTT) tramite l algoritmo di Jacobson New_SRTT = (1-a) x Old_SRTT + a x Latest_RTT Con a compreso tra 0 e 1 (tipicamente 1/8)

Algoritmo di Jacobson E dunque New_SRTT = 7/8 x Old_SRTT + 1/8 x Latest_RTT Il timeout di ri-trasmissione è calcolato sulla base del SRTT, tenendo conto di una stima della deviazione standard di SRTT DEV = Latest_RTT - Old_SRTT e New_SDEV = 3/4 x Old_SDEV + 1/4 x DEV Infine, il retransmission timeout RTO è calcolato come RTO = SRTT + 2 x SDEV All inizio SRTT viene posto uguale a zero e SDEV = 1,5 s, e quindi il valore del timeout RTO parte da 3 s

Retransmission Time Out Round-trip time (RTT) Retransmission TimeOut (RTO) Host A Guard Band Estimated RTT Data1 ACK Data2 ACK Host B

Algoritmo di Karn La ritrasmissione avviene quando termina il timeout RTO, oppure a seguito della ricezione di messaggi di errore ICMP, es. Source Quench A seguito di una ritrasmissione è meglio passare all algoritmo di Karn, per cui ad ogni ritrasmissione non si aggiorna il calcolo di RTT e il timeout è moltiplicato per un fattore fisso: tipicamente 2 New_RTO = 2 x Old_RTO Due valori limite sono necessari il timeout cresce fino ad un valore massimo e poi si ferma New_RTO Max_RTO (es. 16 volte la stima di Jacobson) c è un limite massimo al numero di ritrasmissioni non riscontrate, una volta superato questo limite la connessione viene chiusa Number_UNACK MAx_Number_UNACK Non appena una ritrasmissione viene riscontrata, si ripassa all algoritmo di Jacobson

Trattamento della Congestione Utilizzando le finestre di trasmissione e di ricezione, il TCP può eseguire un controllo di flusso efficace D altra parte, questo meccanismo non è sufficiente ad evitare la congestione nella rete Per reagire alla congestione il trasmettitore mantiene una Congestion Window, CWND, e non può trasmettere più del minimo tra RCVWND e CWND SNDWND = Min {RCVWND, CWND} Il meccanismo per il trattamento della congestione nel TCP consiste dello Slow Start e del Congestion Avoidance

Slow Start & Congestion Avoidance La variabile SSTHRESH è mantenuta al trasmettitore per distinguere le due fasi Slow Start: CWND < SSTHRESH Congestion Avoidance: CWND > SSTHRESH La condizione CWND = SSTHRESH è una condizione di transizione, il trasmettitore può usare sia Slow Start che Congestion Avoidance All inizio, il trasmettitore fa partire la trasmissione in Slow Start inviando un segmento MSS (per esempio 536 byte), e la finestra di congestione CWND e posta a 1 MSS Quando il trasmettitore riceve l ACK del segmento, CWND viene incrementata di 1 MSS, e cioè raddoppiata; il trasmettitore emette due segmenti e ai successivi ACK, la finestra CWND viene incrementata di altri 2 MSS, e così via: la finestra di congestione raddoppia ad ogni RTT Pertanto, sul canale la trasmissione è a burst, con lunghezza dei burst che incrementa esponenzialmente Quando la dimensione della finestra è uguale al prodotto Banda x RTT, allora la trasmissione è continua

Slow start 1 RTT cwnd sender 1 2 data packet ACK receiver 3 4 5 6 7 8 cwnd cwnd + 1 MSS (for each ACK)

Congestion Avoidance Lo Slow Start continua fino a che CWND diventa grande come SSTHRESH, (valore tipico 65.535 byte), valore che determina il passaggio alla fase di Congestion Avoidance (CWND > SSTHRESH), durante la quale ad ogni ACK si aumenta CWND di 1/CWND, dando origine ad una crescita lineare di CWND Se scatta un timeout, o il trasmettitore riceve in messaggio ICMP particolare (es. source quench), il TCP trasmittente reagisce ponendo SSTHRESH uguale alla metà della corrente FLIGHTHSIZE, più precisamente SSTHRESH = Max {2, FLIGHTHSIZE/2} [MSS] ove FLIGHTHSIZE è il numero di byte totali inviati e non ancora riscontrati, misurati in MSS e CWND e posta a 1 [MSS] Come risultato, CWND è minore di SSTHRESH e si entra nella fase di Slow Start; il trasmettitore invia il segmento e la sua CWND è incrementata di 1 MSS ad ogni ACK Il trasmettitore trasmette tutti i segmenti a partire da quello per cui il timeout è fallito (politica go-back-n)

Slow start e congestion avoidance Inizia con cwnd = 1 MSS (slow start) Ad ogni ACK ricevuto incrementa cwnd cwnd cwnd + 1 MSS Crescita esponenziale di cwnd ad ogni RTT: cwnd 2 x cwnd Si passa a Congestion Avoidance quando cwnd >= ssthresh Inizia con cwnd = ssthresh Ad ogni ACK ricevuto: cwnd cwnd + (1/cwnd)*MSS Crescita lineare di cwnd ad ogni RTT: cwnd cwnd + 1 Si passa a Slow Start quando c e una perdita (e si aggiorna ssthresh)

Slow start and congestion avoidance Open connection CWND = 1 MSS Slow Start Congestion Avoidance Incremento Esponenziale Incrementa CWND finche CWND= SSTHRESH Cwnd = SSTHRESH Retransmission Timeout SSTHRESH = FLIGHTSIZE/2 CWND = 1 MSS Incremento Lineare Retransmission Timeout SSTHRESH = CWND/2 CWND = 1 MSS Incremento Esponenziale: CWND = CWND +1 MSS (per ogni ACK) Incremento lineare: CWND = CWND + (1 / CWND)*MSS (per ogni ACK)

CWND esempio di traccia cwnd Timeout AIMD Timeout AIMD ssthresh Slow Start Slow Start Slow Start Time

Fast Retransmit e Fast Recovery Algoritmi implementati nella versione TCP detta TCP Reno ACK duplicati = immediate Acknowledgement; se al TCP ricevente pervengono pacchetti fuori sequenza, successivi a quello atteso, esso invia immediatamente un ACK con l ACK Number contenente il segmento atteso ACK duplicati possono essere causati da perdite di pacchetti isolati I meccanismi di Fast Retrasmit e Fast Recovery cercano di recuperare velocemente queste perdite Quando si perde un pacchetto isolato, il ricevitore non può riscontrare i successivi pacchetti ricevuti correttamente e continua a richiedere il pacchetto perso al trasmettitore Il trasmettitore ritrasmetterà il pacchetto perso soltanto alla scadenza del timeout, nonostante gli ACK duplicati che gli arrivano. Allora si ricorre al Fast Retransmit

Fast Retransmit e Fast Recovery Fast Retransmit Alla ricezione del terzo ACK duplicato consecutivo, con lo stesso ACK Number, il trasmettitore pone SSTHRESH = Max {2, FLIGHTHSIZE/2} [MSS] CWND = SSTHRESH + 3 [MSS] e ritrasmette il pacchetto indicato dall ACK Number Fast Recovery Per ogni ulteriore ACK duplicato ricevuto la CWND viene incrementata di 1 MSS Vengono trasmessi nuovi segmenti se consentito dai valori di CWND e RWND Appena arriva un ACK che riscontra nuovi segmenti si esce dalla fase di Fast Recovery e si pone di nuovo CWND = SSTHRESH = Max {2, FLIGHTHSIZE/2} [MSS]

mittente destinatario PCKT 1 PCKT 2 PCKT 3 PCKT 4 PCKT 5 PCKT 6 PCKT 3 ACK 1 ACK 2 ACK 2 ACK 2 ACK 2 ACK 6 Esempio Fast Retransmit RTT

Fast retransmit e fast recovery cwnd Ritrasmetto dopo aver ricevuto 3 duplicate-ack Evito di attendere lunghi time-out Riduco l impiego dello slow-start In regime stazionario la CWND oscilla attorno al valore ottimale della finestra Slow Start AI/MD Fast retransmit Time

Fast retransmit e fast recovery Slow start threshold Congestion detected through 3 duplicate ACKs ssthresh set to half flight-size; congestion window set to ssthresh + 3 MSS; ( retransmit lost segment re-transmitted (fast ACK received for Re-transmitted Segment Congestion Window Size Slow start begins Time cwnd deflated to value of ssthresh. Fast recovery ends. Congestion avoidance begins Congestion window opens by 1 MSS for each Extra duplicate ACK received

Confronto

Fast recovery Slow Start Open connection CWND = 1 MSS Incremento Esponenziale Incrementa CWND finche CWND= SSTHRESH Cwnd = SSTHRESH Retransmission Timeout SSTHRESH = FLIGHTSIZE/2 CWND = 1 MSS Congestion Avoidance Incremento Lineare Retransmission Timeout SSTHRESH = FLIGHTSIZE/2 CWND = 1 MSS 3 DUP ACK 3 DUP ACK Fast Recovery Incremento Esponenziale Ricevuto ACK mancante CWND = CWND/2 Retransmission Timeout SSTHRESH = FLIGHTSIZE/2 CWND = 1 MSS

Modello del TCP Application A e.g., FTP Server e.g., FTP Client Application B CWND SSTHRESH BUFFER TR SNDWND Servizio di Rete IP BUFFER RC RCVWND RCVWND BUFFER RC SNDWND BUFFER TR TCP A TCP B CWND SSTHRESH

Read() and write() byte streams write() s read() s 26 24 23 21 20 15 14 13 12 11 26 22 21 19 18 17 16 14 13 11 26 25 18 17 14 13 12 11 tcp segments write() s TCP sends data in these segments 3...26 25 24 26 3 6 2 2 23 22 21 20 19 18 17 16 15 14 13 12 11... 25... 18 17... 14 13 12 11 5 3 2 3 3 read() s

Un protocollo di trasporto addizionale Stream Control Transmission Protocol (SCTP) nuovo standard IETF per il livello di trasporto RFC4960 del 2007 (rende obsoleti RFC2960 e RFC3309) Alternativa a TCP e UDP Proposto dalla comunità di ricercatori e tecnici operanti nel settore del trasporto dei protocolli di segnalazione telefonica (telephony over IP) In grado di colmare lacune di TCP e UDP Le peculiarità del trasporto della segnalazione su IP che hanno spinto la nuova iniziativa: Messaggi di piccole dimensioni Requisito di affidabilità elevata e ritardo contenuto Applications UDP TCP SCTP IP Physical

Funzionalità aggiuntive di SCTP (1/6) Multi-homing (host con più interfacce di rete) Scopo: migliorare l affidabilità del trasferimento dei dati in presenza di guasti anche dell interfacce dell host In una connessione TCP si specificano <IP addr,port> sorgente e <IP addr, port> destinazione e se un host è multi-homed devo scegliere un solo indirizzo IP a ciascun capo della comunicazione Se l interfaccia associata a quell indirizzo è in avaria, la connessione non lavora Con SCTP posso aprire una connessione tra due terminazioni specificando più indirizzi e, basta almeno una interfaccia attiva per far lavorare la connessione

Multihoming

Funzionalità aggiuntive di SCTP (2/6) Multi-streaming Scopo: ridurre il ritardo L introduzione della possibilità di avere un criterio di ordinamento parziale supera il limite del TCP che pretende che i dati siano passati allo strato applicativo solo se pervenuti tutti e nell ordine con cui sono stati inviati dal mittente Head of Line (HOL) blocking in caso di perdita di dati all inizio del flusso: i dati pervenuti correttamente a destinazione ritardano se non sono pervenuti i dati che li precedono In SCTP si possono inviare contemporaneamente 64K flussi (stream) indipendenti, applicando a ciascuno un criterio di ordinamento autonomo (parziale rispetto all intero flusso)

Multistreaming

Funzionalità aggiuntive di SCTP (3/6) Conservazione dei confini dei messaggi Scopo: semplificazione della codifica delle applicazioni TCP non conserva i confini dei messaggi e quindi le operazioni di write e di read sono indipendenti SCTP conserva i confini dei messaggi e quindi le operazioni di read e write dei buffer di trasmissione e ricezione operano in modo congruente, semplificando protocolli e applicazioni

Funzionalità aggiuntive di SCTP (4/6) Protezione da attacchi SYN-flood Scopo: migliorare la protezione da attacchi DOS Four way handshake (4WHS) anzichè 3WHS di TCP Lo stato del socket in listen non evolve fino a quando non viene validata la connessione

Funzionalità aggiuntive di SCTP (5/6) Parametri impostabili (Timeout, Retrans, etc.) Scopo: più flessibilità Nel TCP la modifica dei valori di alcuni parametri richiede privilegi amministrativi e modifiche del kernel del sistema operativo SCTP consente l impostazione del valore dei parametri all atto dell apertura del socket

Funzionalità aggiuntive di SCTP (6/6) Consegna di dati inaffidabile/fuori-sequenza, ma con controllo della congestione Scopo: più flessibilità TCP offre controllo della congestione, ma non ammette la consegna inaffidabile/fuori-sequenza UDP offre la consegna inaffidabile/fuori-sequenza, ma non ammette controllo della congestione SCTP offre sempre il controllo della congestione, ma ammette una gamma di servizi di consegna, da affidabile a inaffidabile, da completamente in sequenza a fuori-sequenza Nella medesima connessione SCTP si possono multiplare dati con consegna affidabile e inaffidabile

RETI INTERNET MULTIMEDIALI Protocolli Applicativi

Protocolli Applicativi HyperText Transfer Protocol (HTTP) Protocolli per i servizi real-time RTP/RTCP RTSP Architetture VoIP e protocolli di segnalazione H.323 SIP HTTP streaming Telefonia su IP: H.323 e SIP WebRTC

HyperText Transfer Protocol Protocollo introdotto per la comunicazione tra server WWW e client WWW (browser) per l accesso a ipertesti multimediali distribuiti Protocollo stateless che usa TCP (porta 80) Connessione aperta e chiusa per ogni oggetto trasferito Uso di codifica MIME-like per offrire l indipendenza dalla rappresentazione dell informazione (testo, audio, video, )

WWW Client-Server Model CLIENT Browser (Firfox, Opera,IExplorer ecc..) HTML Interpreter HTTP Server SERVER FTP Server Other Servers HTTP FTP... TCP-IP Stack HTTP FTP... TCP-IP Stack

HTTP 1.0 Client Server connect() write() Retrieve Data From Disk close() connect() write() Retrieve Image From Disk close()

HTTP 1.1 connect() Client Server write() write() Retrieve Data From Disk Retrieve Image From Disk close() Persistent connection

Semantica del protocollo HTTP Messaggi Request Response Struttura dei messaggi Request METHOD URI HEADERS BODY Response STATUS-CODE HEADERS BODY

Richieste HTTP Metodi GET HEAD POST» Scarica l oggetto identificato da URI» Scarica le meta-info di un URI (es. verifica se presente in cache di un proxy)» Primitiva di invio di oggetto da browser a server Metodi diagnostici OPTIONS TRACE» Richiesta lista opzioni del server» Echo Altri metodi meno utilizzati PUT, DELETE

Struttura richiesta HTTP

Codici di stato delle risposte HTTP Successful 2xx 200 OK Redirection 3xx 301 Moved permanently 304 Not modified Client Error 4xx 400 Bad request 401 Unauthorized 404 Not found Server Error 5xx 500 Internal server error 501 Not implemented 504 Gateway time-out 505 HTTP version not supported

Esempio di richiesta HTTP GET /index.html HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/ jpeg, image/pjpeg, */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT) Host: hypothetical.ora.com Connection: Keep-Alive Versione Lingua preferita Host con più di un nome Connessione persistente

Esempio di risposta HTTP Codice stato HTTP/1.1 200 OK Date: Mon, 06 Dec 1999 20:54:26 GMT Greenwich Mean Time Server: Apache/1.3.6 (Unix) Last-Modified: Fri, 04 Oct 1996 14:06:11 GMT Content-length: 327 Connection: close Il client si riconnetterà nel caso di più richieste Mime_version: 1.0 MIME content type Content-type: text/html Riga vuota <html><head><title>sample Homepage</title></head> <body><img src="/images/oreilly_mast.gif"> Contenuto pagina <h1>welcome</h1>hi there, this is a simple web page. Granted, it may not be as elegant as some other web pages...

Uso di Proxy HTTP Browser Proxy Server Miss Hit Hit Ratio (HR ) HR number of documents served from the cache number of documents served Fractional Bandwidth Savings (BT) BT number of bytes served with documents number of bytes served inthe cache

Protocolli per i servizi real-time: voce, audio, video I segnali voce, audio e video digitalizzati hanno requisiti di ritardo stringenti (valore assoluto e varianza), generano traffico con regolarità, sono limitatamente sensibili alle perdite (la compressione riduce la robustezza) Traffico conversazionale interattivo Le parti della sessione di comunicazione sono contestualmente presenti ed esiste una interazione che richiede tempi di risposta limitati Traffico streaming La comunicazione è asimmetrica e coinvolge una sorgente e una o più fruitori di un servizio di accesso a informazione sotto forma di flussi multimediali (es. broadcast audio o video, sia live che differito)

Video-streaming su Internet Si partiziona il flusso video in pacchetti Il playback inizia mentre il flusso viene scaricato (5-15 sec di ritardo) La simultaneità della delivery e del playback (con piccolo ritardo) ha alcuni vantaggi: Si riduce il ritardo di visualizzazione (non si deve attendere il completamento del download del file) Si minimizzano i requisiti di storage (si consuma il flusso progressivamente) Tuttavia si devono affrontare una serie di problemi dovuti alla variabilità del canale di comunicazione

Problemi del video streaming su Internet Le caratteristiche dinamiche e non note a priori della rete best-effort comportano problemi di Banda (o throughput) Si deve adattare il bitrate alla banda disponibile Ritardo (o latency) Si deve compensare la variabilità dei ritardi con un playout buffer Perdita di dati (o loss) Si deve contrastare la perdita con Forward Error Control, ritrasmissioni, error-concealment e codifica error-resilient

Problemi di banda nel video streaming La banda disponibile cambia col tempo e non può essere riservata (almeno con best-effort) Rate control: Stimare la banda disponibile e adattare il bitrate della sorgente in modo conseguente Rate control può essere attuato alla sorgente o al ricevente La stima della banda può essere fatta con probe di misura o con modelli (equazioni di stima)

Problemi di banda nel video streaming Source-based rate control: La sorgente adatta esplicitamente il video rate Si usa un feedback del ricevente per stimare la banda disponibile Il feedback contiene anche informazioni sul tasso di perdita Receiver-based rate control: Il ricevitore esplicitamente seleziona il video rate tra un numero di alternative disponibili, ad esempio Layered multicast: La sorgente codifica il video in modo scalabile (a livelli) e invia diversi livelli su diversi gruppi multicast Ogni ricevente stima la banda e si unisce al numero di gruppi multicast che consegnano livelli compatibili con la banda disponibile

Problemi di ritardo nel video streaming Delay jitter: Il ritardo di consegna end-to-end fluttua se si considerano i pacchetti che appartengono ad un medesimo flusso video streaming Jitter: variazione del ritardo end-to-end Per compensare il jitter si introduce un buffer al ricevitore Corrisponde ad aggiungere un offset al playout time di ogni pacchetto If (packet delay < offset) then OK Buffer packet until its playout time If (packet delay > offset) then problem Un playout buffer tipicamente introduce un offset di 5-15 sec Compensa il jitter e consente la ritrasmissione di pacchetti persi

Problemi di ritardo nel video streaming E importante disegnare una strategia di playout appropriata per il caso d uso Tradeoff tra ritardo di playout e perdita (pacchetti consegnati oltre la deadline) Ritardi maggiori riducono il numero di pacchetti in ritardo (e quindi persi) Ritardi inferiori aumentano il numero di pacchetti in ritardo (e quindi persi) Lo Streaming di video memorizzato può tollerare ritardi maggiori (es. 5-15 sec) Lo streaming real-time di video interattivo non tollera ritardi elevati (ordine di grandezza 150 ms) Il Jitter è tempo-variante L impiego di un playout delay fisso è una condizione sub-ottima L uso di un playout delay dinamico adattativo è una soluzione più valida (richiede la stima del jitter e di adattare il playout delay)

audio in buffer Compensazione della varianza del ritardo Trasmissione audio Ritardo di rete variabile Ricezione audio Riproduzione di audio Ritardo di playout al ricevitore tempo variable fill rate, x(t) Constant drain rate, d buffered content

Esempio Sender RouterA V IP Network Receiver RouterB V 20ms 20ms C B RTP Timestamp From Router A Interframe gap of 20ms A 10 30 50 20ms 80ms 20ms 20ms C B A 10 30 50 C B A 10 30 50 RTP Timestamp From Router A Dejitter Buffer removes Variation RTP Timestamp From Router A Variable Interframe Gap (Jitter)

Il ruolo dei silenzi nella comunicazione vocale Monologo 15% silenzi Conversazione telefonica 20% silenzio per tutta la conversazione 60% silenzio per ogni utente La soppressione dei silenzi riduce l esigenza di banda L emissione della sorgente risulta essere discontinua S silence ~ 15% S silence ~ 60%

Sincronizzazione inter-media Sincronizzo i diversi media: orchestration La sincronizzazione audio e video si chiama: lip synchronization Non necessità di sincronizzazioni spinte Una tolleranza contenuta entro 80-100 ms è oltre il limite della percezione umana Net < 100 ms

RTP e RTCP: protocolli applicativi Per le applicazioni conversazionali real-time, IETF ha introdotto il Real Time Protocol (RTP), accompagnato dal Real Time Control Protocol (RTCP) Application Application Decoding Encoding Encoding Decoding RTP RTCP RTCP RTP UDP/IP UDP/IP

Real-Time Protocol RTP (RFC 3550 del 2003, rende obsoleto l RFC 1889) Protocollo applicativo per servizi real-time multimediali RTP trasporto dati RTCP (Real Time Control Protocol) Monitorare e riferire prestazioni Veicolare informazioni sui partecipanti alla sessione Servizi offerti Pacchettizzazione dei dati con identificazione del media Header RTP numerati (2 byte) Per rilevare perdite e consegne fuori sequenza Timestamp in header RTP (4 byte) Intra-media synchronization Inter-media synchronization (e.g. for lip-synch) Usa UDP come trasporto Non interviene sulla QoS di rete Data applications (FTP, HTTP) TCP IP Real Time audio or video application UDP RTP

Formato della PDU RTP Version 2 bit attualmente versione 2 extension 1 bit CC (CSRC Count) 4 bit) Marker 1bit Marker Può essere usato per indicare estremi di un fotogramma PType Indica il tipo di codifica usato nel payload del pacchetto Sequence number Sequenza monotona crescente (+1 per ogni RTP PDU) Padding 1 bit indica riempitivo presente Source port Length V P X CC M PType Synchronization SouRCe (SSRC) Contributing SouRCe (CSRC) 32 bits Timestamp Destination port Checksum Sequence number Synchronization source (SSRC) identifier Possible header extension: Contributing Source (CSRC) identifier [0-15] UDP Header 8 B RTP Header 12 B Timestamp Istante in cui l informazione contenuta nella PDU è stata prodotta. Diverse PDU possono avere lo stesso timestamp. Il timestamp è generato da un clock indipendente dall applicazione Payload SSRC Identificativo della sorgente che ha creato il contenuto del payload. L identificativo è scelto a caso dalla sorgente Contenuto in formato dipendente dall applicazione

http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xml RTP Payload Type

Overhead IP+UDP+RTP headers = 40 bytes (12 di RTP, 8 di UDP, 20 di IP) 64 Kbps PCM 20 ms = 160 Bytes Banda lorda = 80 Kbps IP UDP RTP audio data 40 160 8 Kbps (G.729) 20 ms = 20 Bytes Banda lorda = 24 Kbps IP UDP RTP data 40 20

Compressione dell header Overhead 20ms@8kb/s porta a 20 byte di payload IP header 20; UDP header 8; RTP header 12 2X payload!!!!!!!! Header compression 40Bytes to 2 bytes if no UDP checksum 4 bytes if UDP checksum used Hop-by-Hop on slow links <512kbps CRTP Compressed Real-time protocol

Pacchetto VoIP CSRC ID: Contributing Source ID for payload RTP datagram Version, flags & CC Payload Type Sequence Number Timestamp Synchronization Source ID CSRC ID (if any) Codec Data 1 1 2 4 4 0-60 0-1460 UDP datagram Source Port Number Destination Port Number UDP length UDP checksum Data 2 2 2 2 0-1472 Version & header length IP packet Protocol TOS Total Length Packet ID Flags & Frag Offset TTL Header Checksum Source Address Destination Address Options (if any) Data 1 1 2 2 2 1 1 2 4 4 0-40 0-1480 Ethernet Frame Start of frame delimiter Length or Ethertype Inter-frame gap Preamble Destination Address Source Address Data Pad Checksum 12 7 1 6 6 2 0-1500 0-46 4

Pacchetti VoIP G.729 (30ms) Clear Channel Voice 30 byte voice bundles UDP Datagram RTP Frame 12 30 RTP Header Voice Payload Destination 2 2 2 2 12 30 Source Length Destination Checksum RTP Header Voice Payload IP Packet Header 12 4 4 8 12 30 Source UDP Header RTP Header Voice Payload G.729 (20ms) Clear Channel Voice IP Packet 20 byte voice bundles UDP Datagram Header RTP Frame 12 20 RTP Header Voice Payload Destination Destination 2 2 2 2 12 20 Source Length Checksum RTP Header Voice Payload 12 4 4 8 12 20 Source UDP Header RTP Header Voice Payload

Real Time Control Protocol Protocollo di controllo usato per monitorare la qualità RTP e2e Vari tipi di PDU RTCP: SR (sender report): inviato da tutte le sorgenti attive a tutti i partecipanti Contiene: Timestamp assoluto (NTP) relativo all istante di invio; Timestamp relativo al flusso RTP in corso; Quantità di dati inviati dall inizio della sessione (Numero totale di pacchetti RTP inviati e Numero totale di byte inviati) RR (receiver report): inviato da tutti i ricevitori a tutti i partecipanti a una sessione per informare sulla qualità percepita Contiene: Sorgente ascoltata, Timestamp dell ultimo SR ricevuto, Ritardo dalla ricezione dell ultimo SR, Numero di sequenza più alto ricevuto dalla sorgente, Numero di pacchetti RTP della connessione persi, Frazione di pacchetti RTP della connessione persi, Stima del jitter dei pacchetti RTP della connessione SDES: descrizione della sorgente BYE: fine della sessione APP: application-specific

Report Blocks Sender Info Header RTCP sender report V=2 P Reception Packet Type=SR=200 Length Report Count Synchronization Source Identifier (SSRC) of Sender NTP Timestamp, Most Significant Word NTP Timestamp, Least Significant Word RTP Timestamp Sender s Packet Count Sender s Octet Count Report Blocks and Profile Specific Extensions Maps format specific timestamp to wall clock time. Used to synchronize different media streams. Report blocks used in both Sender and Receiver Reports

RTCP reception record block Synchronization Source Identifier 1 (SSRC_1) Fraction Lost Cumulative Number of Packets Lost Extended Highest Sequence Number Received Interarrival Jitter Last Sender Report (LSR) Delay Since Last Sender Report (DLSR) Synchronization Source Identifier 2 (SSRC_2)...

Cadenza di invio di messaggi RTCP Periodicità dipendente dal numero dei partecipanti della sessione Conteggio dei partecipanti Per ogni RTP, source ID si incrementa I membri che non denotano attività per 5 intervalli consecutivi si marcano come inattivi Allocazione di banda per la descrizione della sorgente (SDES) Alcune informazioni inviate di frequente (e.g. name) Altre informazioni inviate raramente (e.g. email address) RTCP Control Traffic (5%) RTP Data Traffic (95%) Receiver messages (75%) Sender messages (25%)

Real Time Streaming Protocol Real Time Streaming Protocol (RTSP): RFC 2326 Protocollo usato per lo scaricamento di file audio/video da server remoti Streaming: fruizione del media contestuale allo scaricamento (a differenza dello scaricamento e della fruizione batch) Supporta controllo utente come un telecomando di rete : rewind, FF, pausa, riprendi Protocollo fuori banda: Una porta (554) per messaggi di controllo e segnalazione Una porta per lo stream multimediale Uso TCP o UDP per connessione di controllo Operazioni Invio di un metafile al browser Il browser attiva il player appropriato Il player attiva una connessione di controllo RTSP e una connessione dati RTP verso il server

Scenario RTSP I data stream (linea tratteggiata) usano RTP/RTCP I control channel (linea continua) usano RTSP

RTSP in azione HTTP GET Session description Web Server Setup Client Play RTP audio RTP video RTCP Pause Media Server Teardown

La prospettiva utente User Interface RTSP Player RTSP Server OpenURL SETUP response1 audio Activate RTP PLAY response2 Activate RTP PAUSE response3 Quit TEARDOWN response10

Controllo RTSP RTSP client RTSP server RTSP control connection(tcp) DESCRIBE request SETUP request PLAY request ANNOUNCE reply SETUP reply PLAY reply RTSP client RTSP control (TCP) RTP data (UDP) RTCP feedback (UDP) RTSP server

Comandi RTSP OPTIONS SETUP ANNOUNCE DESCRIBE PLAY RECORD REDIRECT PAUSE SET PARAMETER TEARDOWN richiesta di metodi disponibili attiva il trasporto annuncia/aggiorna la descrizione di un media object richiesta di descrizione di un media object avvio playback avvio registrazione del server ridirezione del client a un altro server pausa controllo del dispositivo o della codifica abbattimento sessione

Esempio di sessione RTSP: accesso alla descrizione C->W: GET /twister.sdp HTTP/1.1 Host: www.example.com Accept: application/sdp W->C: HTTP/1.0 200 OK Content-Type: application/sdp v=0 o=- 2890844526 2890842807 IN IP4 192.16.24.202 s=rtsp Session m=audio 0 RTP/AVP 0 a=control:rtsp://audio.example.com/twister/audio. en m=video 0 RTP/AVP 31 a=control:rtsp://video.example.com/twister/video

Esempio di sessione RTSP: apertura stream C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0 CSeq: 1 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057 A->C: RTSP/1.0 200 OK CSeq: 1 Session: 12345678 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057; server_port=5000-5001 C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 1 Transport: RTP/AVP/UDP;unicast;client_port=3058-3059 V->C: RTSP/1.0 200 OK CSeq: 1 Session: 23456789 Transport: RTP/AVP/UDP;unicast;client_port=3058-3059; server_port=5002-5003

Esempio di sessione RTSP: play C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 2 Session: 23456789 Range: smpte=0:10:00- SMPTE (Society of Motion Picture and Television Engineers) timecode V->C: RTSP/1.0 200 OK CSeq: 2 Session: 23456789 Range: smpte=0:10:00-0:20:00 RTP-Info: url=rtsp://video.example.com/twister/video; seq=12312232;rtptime=78712811 C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0 CSeq: 2 Session: 12345678 Range: smpte=0:10:00- A->C: RTSP/1.0 200 OK CSeq: 2 Session: 12345678 Range: smpte=0:10:00-0:20:00 RTP-Info: url=rtsp://audio.example.com/twister/audio.en; seq=876655;rtptime=1032181

Streaming video Lo streaming è la trasmissione di un flusso di contenuti continuo da un server a un client che lo consuma contestualmente Il tasso di consumo può essere influenzato da vincoli di real-time oltre a quelli di disponibilità di banda Il tasso di trasmissione del server corrisponde in modo più o meno stringente al tasso di consumo del client Progressive download Il server invia un file più rapidamente possibile Il client inizia il playout dopo un certo tempo iniziale di buffering Quando la rete non consegna dati con qualità sufficiente il buffer di playout si svuota: si ha il «freeze» Pseudo Streaming Il server governa il tasso di trasmissione dei dati del file Il client può saltare Devono essere usati alcuni metadati Full Streaming Il client richiede piccoli tratti (chunk) del flusso video scaricando messaggi distinti Utilizzabile per contenuto dal vivo ed on-demand

Streaming adattativo La diffusione del video su Internet ha determinato l esigenza di sviluppare soluzioni specifiche: Fruizione di contenuti video in streaming da parte di utenti che sperimentano qualità di rete diverse tra loro e mutevoli nel tempo Lo streaming adattativo rappresenta l insieme delle tecniche di rappresentazione stratificata del video e fruizione adattativa in funzione dei vincoli sperimentati dal client Sono state proposte soluzioni proprietarie basate su uso di HTTP (IIS Smooth Streaming di Microsoft, Apple HTTP Live Streaming)

Adaptive Streaming over HTTP Ibrido tra progressive download e streaming Effetto analogo allo streaming attraverso una sequenza intelligente di brevi download Piccoli download per minimizzare lo spreco di banda Abilita il monitoraggio del progresso e il controllo dei client Adattamento alle condizioni dinamiche ed alle caratteristiche del terminale Si adatta elle condizioni variabili della rete Si adatta alla risoluzione del display, alle risorse CPU e memoria del client: facilita il paradigma any device, anywhere, anytime Migliora la Quality of Experience Abilita avvio veloce e ricerca e salto Riduce skip, freeze e stutter Usa HTTP Infrastruttura ben conosciuta per naming/addressing approach, autenticazione/autorizzazione Facile attraversamento delle middlebox (es. NAT, firewall) Abilita l impiego del paradigma cloud e l uso delle infrastrutture di caching e CDN

Codifica e decodifica adattativa Lo streaming adattativo richiede che l informazione si codificata in modo stratificato per poter determinare qualità differenti, compatibili con le caratteristiche di rete

Streaming push e pull Nel paradigma streaming push, i server prendono l iniziativa (es. video streaming live) Nel paradigma pull, i client prendono l iniziativa (es. Youtube) Real Time Messaging Protocol (RTMP)

Architettura di riferimento per il video push: IPTV

Architettura di riferimento per video pull

Architettura di riferimento per video pull

MPEG Dynamic Adaptive Streaming over HTTP (MPEG-DASH) MPEG DASH ISO/IEC 23001-6

DASH DASH non è: Un nuovo sistema, protocollo, presentazione, codec, specifica di client o browser DASH è un fattore abilitante Fornisce soluzioni per streaming adattativo su Internet basato su convenzioni aperte e condivise a livello di standard ISO Viene considerato un componente di un servizio end-to-end Riusa tecnologie esistenti (contenitori MPEG2-TS e MPEG4, coded, DRM, ) Abilita all uso su infrastrutture HTTP-CDN (infrastrutture Web based, caching) Migliora l esperienza dell utente Muove l intelligenza dalla rete al client, rendendo possibile la differenziazione dei client e dei terminali Uso flessibile (live, on-demand, time-shift)

Architettura di riferimento

Struttura dati Segment Info Initialization Segment http://www.e.com/ahs-5.3gp Media Presentation Period, start=0s Period, start=100s Period, start=295s Period, start=100 baseurl=http://www.e.com/ Representation 1 500kbit/s Representation 2 100kbit/s Representation 1 bandwidth=500kbit/s width 640, height 480 Segment Info duration=10s Template:./ahs-5-$Index$.3gs Media Segment 1 start=0s http://www.e.com/ahs-5-1.3gs Media Segment 2 start=10s http://www.e.com/ahs-5-2.3gs Media Segment 3 start=20s http://www.e.com/ahs-5-3.3gh Media Segment 20 start=190s http://www.e.com/ahs-5-20.3gs

Analisi comparata SS: Smooth Streaming HLS: HTTP Live Streaming

Protocolli per servizi conversazionali real-time Servizi conversazionali real-time richiedono una relazione tra soggetti (due o più) creata per l esigenza di comunicazione (on-demand su base esigenza) con esigenze di servizio di trasporto di tipo real-time Es. telefonia, videotelefonia, videoconferenza multiparty, sessione di lavoro cooperativo in rete, Per questi servizi orientati alla rete Internet si sono sviluppate famiglie di soluzioni che utilizzano la segnalazione (scambio di dati di controllo dei terminali delle comunicazioni, tra loro e con la rete) per gestire l attivazione del servizio, in analogia con quanto fatto per i servizi della rete telefonica tradizionale

Funzioni della segnalazione Nella rete telefonica la segnalazione ha uno scopo molteplice. Essa colloquia con la rete, per instradare la chiamata e prenotare i circuiti con il chiamato per instaurare la chiamata con la rete per fornire servizi aggiuntivi Sulla base della segnalazione la rete predispone servizi per il controllo d accesso identificare il chiamato/chiamante predisporre la documentazione d addebito

Funzioni della segnalazione Sulla rete IP la segnalazione può essere ridotta al minimo perché l indirizzo IP è fornito sulla base del nome (e-mail address) da meccanismi DNS l instradamento dei flussi stream è effettuato normalmente dal protocollo IP Potrebbe essere sufficiente l aggiunta di un protocollo di connessione (alerting dell utente chiamato) un protocollo di Session Negotiation (capacità dei terminali, diversi media stream, )

Funzioni della segnalazione In realtà esistono funzioni di controllo controllo degli accessi controllo delle risorse (QoS) controllo di sessioni multiparty tariffazione che rendono necessario l utilizzo, o meglio il filtro, di particolari server e relativi protocolli (segnalazione). Altri server sono poi necessari per l erogazione di servizi di rete quali quelli forniti oggi dalla rete Intelligente (Intelligent Network)

Architetture di segnalazione Esistono molte architetture di segnalazione Le due più utilizzate sono

Call Connection Control ITU E basato sull utilizzo dell architettura H.323 per video-conferenza su reti a pacchetto Versione 1 (1996) multimedia su LAN Versione 2 (1998) telefonia su IP Versione 3 (1999) Versione 4 (2000) Versione 5 (2003)

Famiglia ITU multimedia Altre raccomandazioni collegate sono H.323 multimedia su LAN H.320 - multimedia su ISDN H.324 - multimedia su rete telefonica normale H.321 - multimedia su BISDN H.322 - multimedia su LAN con QoS

Raccomandazione H.323 dell ITU Visual telephone for LANs with nonguaranteed QoS Nonostante il titolo riporti la dicitura LAN, lo standard non è limitato alle LAN Altri standard ITU di riferimento G.7xx series per audio codecs H.26x series per video codecs H.3xx per funzioni di controllo e trasporto Assume che il trasporto dei flussi voce pacchettizzati si avvalga di RTP

Famiglia H.323 H.323 Annessi H.323 H.225.0 (Call Signaling and RAS) H.245 (Media Control) H.235 (Security) H.341 (SNMP) H.450 (Servizi Supplementari) H.246 (Interworking Gateways) H.248 Gateway Control Protocol (MEGACO)

Scope of H.323 Pila protocollare H.323 System Control Interface User Data Apps Audio I/O equipment Video I/O equipment RAS Control (H.225.0) Call Control (H.225.0) H.245 Control Data Interface (T.120) Audio Codec (G711, G722, G723, G728, G729) RTP Video Codec (H261, H263) UDP TCP TCP UDP IP Network Interface RAS: Registration Admission and Status

Anatomia del terminale H.323 Scope of Recommendation H.323 Audio Codec G.711 G.723 G.729 Video Codec H.261 H.263 RTP Mandatory for H.323 compliance Data Interface T.120 System control H.245 Control H.225 (Q.931) Control RAS Gatekeeper Interface Network Interface

H.323 Components MCU Gatekeeper Gateway PC Endpoint H.323 IP network H.320 PC PC Endpoint H.323 Proxy ISDN / PSTN

EndPoint H.323 E la terminazione dei canali logici (media) (non H.323) E la terminazione della segnalazione per la connessione e il set up dei canali logici (media) Può operare direttamente end-to-end utilizzando l indirizzo IP e le porte TCP/UDP dei terminali segnalazione media: canale logico IP

Gatekeeper H.323 Il Gatekeeper è l analogo della centrale nella rete classica Associa l indirizzo IP al numero telefonico (o altro alias) del terminale della sua ZONA Gestisce una ZONA Può essere l interfaccia per altri servizi registrazione GK Zona registration admission control bandwidth and QoS address translation

Proxy H.323 Entità che rilanciano e instradano la segnalazione Scompone una sessione H.323 in due distinte fasi di chiamata I Gatekeeper possono fare da proxy setup setup GK GK setup Zona 1 Zona 2

Gateway H.323 Consente l interlavoro verso le altre reti setup GK setup PSTN/ISDN IP

H.323 Multi-Point Control Unit (MCU) Fornisce supporto a conferenza di tre o più terminali Stabilisce modalità comuni, governa le risorse, riceve i contributi, miscela l audio, sceglie il video e trasmette ai partecipanti Due modalità di scambio Centralizzata Decentralizzata Non utilizzata in telefonia

H.323: Protocolli Introduce tre fasi di segnalazione H.225.0 RAS (Registration, Admission, Status) Registration Address Resolution Call Admission H.225.0 Call Control : versione estesa di Q.931. H.245: Connection and media Control: endpoint capability exchange, definisce canali logici unidirezionali per i vari flussi multimediali definendo le porte per RTP e RTCP Utilizza la sintassi ASN.1

H.323 Operazioni Base I terminali si registrano col Gatekeeper (H.225.0 RAS, Registration Admission and Status) I terminali chiedono al Gatekeeper il permesso di instaurare una chiamata con un altro terminale (H.225.0 RAS) I terminali si scambiano la segnalazione di chiamata (H.225.0 Call Control - Q.931) I terminali si scambiano la segnalazione per instaurare i media (capability e canali logici con porte per RTP) H.245. I terminali si sconnettono e segnalano al GK

H.225.0 RAS Colloquia col Gatekeeper per Registration, Address Resolution, Call Admission. Funzione Request Conf/Response Reject Gatekeeper GRQ GCF GRJ Registration RRQ RCF RRJ Unregistration URQ UCF URJ Admission ARQ ACF ARJ Bandwidth BRQ BCF BRJ Location LRQ LCF LRJ Information IRQ IRR Disengage DRQ DCF DRJ

H.225.0 Registration Scoperta del gatekeeper automatica (o manuale) tramite un GRQ verso multicast address 224.0.1.41 con well known transport port 1718 GRQ T GCF GK Il gatekeeper può accettare (GCF), rifiutare (GRJ), + indicare gatekeeper alternativi. Indica il proprio indirizzo e la porta UDP per il RAS channel

H.225.0 Registration La registrazione (RRQ) può avvenire sulla well known port 1719 Il terminale comunica l indirizzo, una o più porte e gli alias del terminale (ammesso un indirizzo addizionale) Ha un tempo di vita finito e necessita di keep alive RRQ T RCF GK

H.225.0 Address Resolution Il terminale è identificato dall indirizzo IP Sono permessi più alias (E.164, URL, name@host,..) L alias può essere usato, da terminali o gatekeeper, per interrogare un gatekeeper specifico (LRQ location request), o via multicast Il gatekeeper del terminale richiesto risponde con l indirizzo RAS e Signaling del terminale, o quello del gateway (se il terminale non è raggiungibile in IP)

H.225.0 Call Admission Il messaggio ARQ (admission request) indica la destinazione (anche con alias) Specifica al gatekeeper la banda complessivamente richiesta dal terminale (sono esclusi header), canale dati e canali di controllo Indica la sua possibilità di effettuare la riservazione delle risorse (QoS) Tutte le richieste di una chiamata sono legate dal CRV (Call Reference Value) ARQ T ACF GK

H.225.0 Call Admission Nella risposta di accettazione (ACF) il gatekeeper indica l indirizzo di trasporto per la segnalazione può indicare al terminale di effettuare la prenotazione delle risorse può effettuare la prenotazione per conto del terminale può indicare che la prenotazione non serve può ridurre la banda In ogni istante si può cambiare l uso della banda col comando BRQ ARQ T ACF GK

H.225.0 Call Admission La chiusura della conversazione va segnalata T DRQ DCF GK Oppure può essere imposta DRQ T DCF GK

H.225.0 ARQ Message AdmissionRequest ::= SEQUENCE --(ARQ) { requestseqnum RequestSeqNum, calltype CallType, callmodel CallModel OPTIONAL, endpointidentifier EndpointIdentifier, destinationinfo SEQUENCE OF AliasAddress OPTIONAL, -- Note 1 destcallsignaladdress TransportAddress OPTIONAL, -- Note 1 destextracallinfo SEQUENCE OF AliasAddress OPTIONAL, srcinfo SEQUENCE OF AliasAddress, srccallsignaladdress TransportAddress OPTIONAL, bandwidth BandWidth, callreferencevalue CallReferenceValue, nonstandarddata NonStandardParameter OPTIONAL, callservices QseriesOptions OPTIONAL, conferenceid ConferenceIdentifier, activemc BOOLEAN, answercall BOOLEAN, -- answering a call..., canmapalias BOOLEAN, -- can handle alias address callidentifier CallIdentifier, srcalternatives SEQUENCE OF Endpoint OPTIONAL, destalternatives SEQUENCE OF Endpoint OPTIONAL, gatekeeperidentifier GatekeeperIdentifier OPTIONAL, tokens SEQUENCE OF ClearToken OPTIONAL, cryptotokens SEQUENCE OF CryptoH32 3Token OPTIONAL, integritycheckvalue ICV OPTIONAL, transportqos TransportQOS OPTIONAL, willsupplyuuies BOOLEAN, calllinkage CallLinkage OPTIONAL, gatewaydatarate DataRate OPTIONAL, capacity CallCapacity OPTIONAL, circuitinfo CircuitInfo OPTIONAL, desiredprotocols SEQUENCE OF SupportedProtocols OPTIONAL, desiredtunnelledprotocol TunnelledProtocol OPTIONAL, featureset FeatureSet OPTIONAL, genericdata SEQUENCE OF GenericData OPTIONAL }

H.225.0 Call Control Segnalazione fra gli end point per il set-up della chiamata multimediale Derivato da Q.931 con adattamento di header EP1 Setup Alerting Connect EP2 Release Complete Ci sono diverse modalità di segnalazione

H.225.0 Call Control Utilizza una connessione TCP sulla porta segnalata in RAS ACF o sulla porta well known 1720 Tutte le informazioni che servono alle nuove funzionalità trovano sede nell Elemento Informativo User-User Trasferisce l indirizzo (Porta TCP dinamica) per stabilire il canale H.245 Contiene strumenti per invocare i Servizi Supplementari (H.450.x)

Chiamata telefonica PSTN Local Station Idle Originating Office Idle Terminating Office Idle Local Station Line connect Dial tone Dial pulsing Trunk connect Start dial Answer Ringback Dial pulsing Answer Busy Ringing Answer

Esempio RQ: request CF: Confirm H.323 Zone-1 gatekeeper gatekeeper H.323 Zone-2 GRQ GRQ GCF Gatekeeper discovery GCF RRQ RRQ RCF Registration with gatekeeper RCF ARQ Admission control via gatekeeper ACF LRQ LCF Location of endpoints in a different zone H.225.0 setup message ACF Admission control via gatekeeper ARQ DRQ Disengage an active call DCF H.225.0 and H.245 signaling. Media established,active call DCF Disengage an active call DRQ

Instaurazione chiamata H.323 Zone-1 gatekeeper ARQ ACF SETUP CALL PROCEEDING ALERTING CONNECT SETUP CALL PROCEEDING ALERTING CONNECT

H.323 Direct Call RAS Q.931 Gatekeeper 1 Gatekeeper 2 H.245

H.323 Routed Call Gatekeeper 1 Gatekeeper 2 RAS Q.931 H.245 Per esercitare maggior controllo, agire come MCU, fornire servizi

H.323 Routed Call Gatekeeper 1 Gatekeeper 2 Q.931 H.245

H.245 Media Control Funzioni che usano un canale di controllo, e includono Capability exchange tipi di media, numero di canali contemporanei, bit rate e altre opzioni (es. QOSCapability: la possibilità di usare RSVP) Apertura e chiusura di canali logici per i media (RTP,RTPC), unidirezionali per audio e video e bidirezionali per dati Preferenze Messaggi di flow control Messaggi per la gestione della conferenza

H.245 Media Control Esistono anche comandi (richiedono un azione ma non una risposta) Send Terminal Capability Set Flow Control End session Indication (solo informativi, non richiedono azione né risposta) Jitter Indication Function Not Understood User Input (usato per trasmettere le codifiche dei tasti, es. per trasmettere DTMF)

RAS H.323: fase RAS Terminale 1 Gatekeeper Terminale 2 LOCATION REQUEST LOCATION CONFIRM ADMISSION REQUEST ADMISSION CONFIRM In questa fase il chiamante ottiene i permessi e l indirizzo TCP/IP a cui inviare la segnalazione di Set Up

H.323: fase Q.931 Terminale 1 LOCATION REQUEST LOCATION CONFIRM ADMISSION REQUEST ADMISSION CONFIRM Gatekeeper Terminale 2 RAS SETUP CALL PROCEEDING ADMISSION REQUEST ADMISSION CONFIRM CALL PROCEEDING Q.931 RAS Q.931 In questa fase i terminali si scambiano le porte TCP su cui scambiarsi la segnalazione H.245

H.323: fase H.245 Terminale 1 Gatekeeper Terminale 2 LOCATION REQUEST LOCATION CONFIRM ADMISSION REQUEST ADMISSION CONFIRM In questa SETUP fase i terminali si scambiano le caratteristiche dei terminali e le porte UDP su cui scambiare i flussi TERMINAL CAPABILTY SET CALL PROCEEDING ADMISSION REQUEST ADMISSION CONFIRM CALL PROCEEDING RAS Q.931 RAS Q.931 TERMINAL CAPABILTY ACK OPEN LOGICAL CHANNEL QoS: non H.323 H.245 CONNECT

H.323: fasi di scambio media Terminale 1 LOCATION REQUEST LOCATION CONFIRM ADMISSION REQUEST ADMISSION CONFIRM Gatekeeper Terminale 2 RAS SETUP CALL PROCEEDING ADMISSION REQUEST ADMISSION CONFIRM CALL PROCEEDING TERMINAL CAPABILTY SET TERMINAL CAPABILTY ACK OPEN LOGICAL CHANNEL CONNECT Q.931 RAS Q.931 H.245 media

H.323 Gateway Traduzione di: H.323 Endpoint H.323 Endpoint Protocolli di trasporto Formato dei media Non- H.323 Endpoint Non-H.323 Endpoint Protocolli di segnalazione

H.323 Gateway Gatekeeper RAS IP network Q.931 H.245 Gateway PSTN/ISDN

H.323 - H.320 Gateway H.246 H.245 H.242 H.243 H.225.0 (Q.931) Q.931 Q.921 TCP H.221 IP network D channel ISDN n x 64 kb/s

Terminale telef. PSTN/ ISDN SETUP CALL PROCEEDING H.323 PSTN Gateway Gateway LOCATION REQUEST LOCATION CONFIRM Gatekeeper Terminale H.323 ADMISSION REQUEST ADMISSION CONFIRM SETUP CALL PROCEEDING ADMISSION REQUEST ADMISSION CONFIRM ALERTING ALERTING TERMINAL CAPABILTY SET TERMINAL CAPABILTY ACK OPEN LOGICAL CHANNEL CONNECT OPEN LOGICAL CHANNEL CONNECT

Session Initiation Protocol SIP è l alternativa IETF alla segnalazione H.323 Nata a partire dal 1995 nel WG MMUSIC Sfociata nel 99 nella RFC 2543 (46 pagine) Evoluta al 11/2000 nel Draft rfc2543bis-02 (171 pagine) Sostituita nel giugno 2002 da RFC 3261 (269 pagine)

Introduzione SIP serve a iniziare, modificare e terminare sessioni relative ad applicazioni multimedia: chiamate telefoniche multiparty conference con più flussi multimediali real-time e non real-time ma anche: instant messaging event notification distributed games

Introduzione Può anche collaborare con altri protocolli definiti dall IETF che compongono la suite di protocolli per applicazioni multimediali SIP generalmente usa i seguenti protocolli SDP - Session Description Protocol (RFC 2327) RTP - Real Time Protocol (RFC 3550) RTCP - Real Time Control Protocol (RFC 3550) RTSP - Real Time Streaming Protocol (RFC 2326) MGCP - Media Gateway Control Protocol (RFC 3435)

SIP Compiti SIP gestisce lo scambio per l instaurazione e la gestione della sessione, ma per i flussi relativi alla sessione non si preoccupa: del trasporto (si fa uso al solito di RTP) del monitoraggio della qualità (RTCP) della descrizione dei flussi della sessione (messaggi SDP sono incapsulati in messaggi SIP)

SIP Compiti I messaggi SIP possono essere trasferiti usando qualunque servizio di trasporto anche se viene consigliato l uso di UDP SIP consente il colloquio tra utenti individuabili grazie ad identificativi come quelli dell e-mail (proposto proprio come identificativo dell utente) o di numeri (solo per rimanere compatibili con le vecchie abitudini)

SIP Identificativi L identificativo è dell utente (o del terminale) E garantita la mobilità dell utente che può accedere al servizio da terminali diversi (personal mobility) e per questo sono richieste le funzioni di Registration User Location Inoltre l identificativo d utente può essere allo stesso tempo associato a terminali diversi (con capability diverse, come videotelefono, portatile, segreteria telefonica, ecc.) Più identificativi possono essere associati allo stesso terminale

SIP Identificativi L identificativo è dell utente (livello applicativo) (come per l e-mail) e non del terminale (di rete) E un Uniform Resource Identifier - URI: Sip:user@domain. Esempio: sip:j.doe@big.com sip:j.doe:secret@big.com;transport=tcp sip:j.doe@big.com?subject=project%20x&priority=urgent sip:+1-212-555-1212:1234@gateway.com;user=phone sip:1212@gateway.com sip:alice@10.1.2.3 sip:alice@example.com sip:alice%40example.com@gateway.com sip:alice@registrar.com;method=register

Protocollo SIP I messaggi di SIP sono implementati in modalità testuale come in molti altri protocolli applicativi IP (es. HTTP, SMTP, ecc.) SIP è un protocollo di tipo client-server richieste CLIENT risposte SERVER Negli elementi di rete sono normalmente implementati sia la parte client che la parte server

SIP Methods Le richieste dei client si chiamano methods INVITE ACK BYE CANCEL OPTIONS REGISTER Inizia la chiamata invitando un utente ad una sessione conferma la avvenuta connessione termina la chiamata resetta la chiamata chiede informazioni sulle capability registra presso il location service Non si assume affidabilità della consegna: le richieste possono essere ritrasmesse

SIP Response Codes Le risposte contengono un codice che descrive l esito dell elaborazione della richiesta da parte del server 1xx continue (request received, continuing) 2xx success 3xx redirection (further action needed) 4xx client error (request cannot be fulfilled) 5xx server error (failed to fulfill) 6xx global failure (request not fulfilled at any server)

SIP Response Codes 100 continue 180 ringing 181 forwarding 182 queuing 200 OK 300 multiple choices 301 moved permanently 302 moved temporarily 400 bad request 401 unauthorized 403 forbidden 404 not found 408 request timeout 480 Unavailable 481 Invalid Call-ID 482 Loop detected 500 internal error 501 not implemented 600 busy 601 decline 604 does not exist 606 not acceptable

SIP Transaction Richieste e risposte sono raggruppate in SIP transaction Una transaction è composta: Una richiesta Eventuali risposte di call progress (1xx) Una risposta finale Un ACK finale (solo per i messaggi di INVITE) che conferma l apertura della sessione Rappresentato come un altra transazione senza risposta

SIP Transaction Instaurazione di una sessione INVITE: hgs@play 100 PROGRESS 200 OK ACK: hgs@play

SIP Message Formato delle richieste INVITE sip:capone@elet.polimi.it SIP/2.0 Via: SIP/2.0/UDP proxy.cs.columbia.edu Via: SIP/2.0/UDP sipserv.elet.polimi.it From: sip:schultzrinne@columbia.edu To: sip:antonio.capone@polimi.it Call-Id: 263954@host1.cs.columbia.edu CSeq: 1 INVITE Subject: meeting. Content-Type: application/sdp Content-Length:... Contact: hgs@host1.cs.columbia.edu corpo messaggio SDP Method Header Message body

SIP Message SIP/2.0 200 OK Via: SIP/2.0/UDP proxy.cs.columbia.edu Via: SIP/2.0/UDP sipserv.elet.polimi.it From: sip:schultzrinne@columbia.edu To: sip:antonio.capone@polimi.it Call-Id: 263954@host1.cs.columbia.edu CSeq: 1 INVITE Subject: meeting. Content-Type: application/sdp Content-Length:... Contact: voicemail@host4.polimi.it corpo messaggio SDP Formato delle risposte Method Header Header variato Message body

SIP elementi di rete Proxy server Registrar User Agent (UA) IP network Redirect server UA

SIP User Agent (UA) User Agent (UA): Genera le richieste (UA client) ed è anche, normalmente, il Destinatario finale (UA server) Esempi: internet phone, software per teleconferenza, caselle vocali, etc. UA client INVITE: hgs@play UA server 100 PROGRESS 200 OK ACK: hgs@play

SIP Registrar All interno di un dominio associa lo URI dell utente all indirizzo del terminale su cui l utente viene rintracciato Uno UA per essere raggiungibile deve registrarsi presso i registrar inviando periodicamente un richiesta di REGISTER C->S:REGISTER sip:bell-tel.com SIP/2.0 (Request URI) Via: SIP/2.0/UDP saturn.bell-tel.com From: <sip:watson@bell-tel.com>;tag=19 To:sip:watson@bell-tel.com (user URI) Call-ID: 70710@saturn.bell-tel.com (costante per UA) CSeq: 1 REGISTER (contatore) Contact: <sip:watson@saturn.bell-tel.com:3890;transport=udp> Expires: 7200

Localizzazione del Registrar/Proxy Si hanno 3 possibilità per ottenere l indirizzo del Registrar: 1. Per configurazione 2. Utilizzando lo address-of-record dei servizi di localizzazione (DNS) Per l utente sip:carol@chicago.com si può tentare sip:chicago.com 3. Utilizzando multicast address sip.mcast.net (224.0.1.75)

SIP Proxy Server Sono di fatto dei router di livello applicativo che instradano le richieste e le risposte, in ingresso e/o in uscita DB Proxy INVITE: henning@columbia.edu Proxy Registrar INVITE: henning 200 OK ACK: henning 200 OK ACK: henning@columbia.edu ACK: hgs@play 200 OK INVITE: hgs@play

SIP Redirect Server Ricevono le richieste e rispondono con l indicazione della localizzazione di un altro server o di uno UA Possono essere implementati sull host o su server INVITE: henning@columbia.edu 200 OK Proxy Registrar INVITE: hgs@field 200 OK INVITE: hgs@play 302 Moved temporarily hgs@field

SIP Forking Un proxy server che riceve una richiesta da un client può inoltrare tale richiesta a più destinazioni (branch) Ciò può avvenire o in sequenza o in parallelo Se viene fatto in parallelo, si suppone che solo uno dei server a valle risponda positivamente In ogni caso viene mantenuta la prima risposta positiva INVITE proxy sistemi di Automatic Call Distribution

Affidabilità dei messaggi di SIP I messaggi SIP non assumono affidabilità di trasporto Se una risposta ad una richiesta non giunge entro un certo tempo T, la richiesta viene ripetuta Se il fenomeno si ripete, la richiesta successiva viene ripetuta dopo 2T, poi 4T, e così via Nel caso dell INVITE i tempi devono essere più lunghi e devono essere ripetute anche le risposte

SIP Descrizione delle sessioni SIP usa attualmente SDP (Session Description Protocol) per la descrizione delle sessioni I messaggi SDP sono trasportati in modo trasparente all interno dei messaggi di SIP Normalmente il messaggio di INVITE contiene un corpo SDP che descrive Indirizzi e porte Codifiche supportate Il server inserisce un corpo SDP normalmente nel riscontro finale 200 OK Se il client non ha inserito il messaggio SDP nell INVITE deve farlo nell ACK finale

Session Description Protocol (SDP) SDP (RFC 4566) è un formato per la descrizione di sessioni multimediali Viene utilizzato in SIP, RTSP, e-mail con estensione MIME, e HTTP SDP include Nome e scopo della sessione Durata della sessione I vari media utilizzati L informazione per ricevere tali media (porte, indirizzi) Informazioni sulla banda Informazioni di contatto

Session Description Protocol (SDP) Le descrizioni sono testuali del tipo <Type>=<value> v= (protocol version) o= <username> <session id> <version> <network type> <address type> <address> s= <session name> i= <session description> u=<uri> (pointer to additional information about the conference) e=<email address> (contact information for the person responsible for the conference) c=<network type> <address type> <connection address> t=<start time> <stop time> a=<attribute>:<value> (primary means for extending SDP) m=<media> <port> <transport> <fmt list>

Esempio SDP (version) (origin/identifier) (session name) (description) (URI) (email) (connnection inf.) (start stop t.) (attribute) (media/port) v=0 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 s=sdp Seminar i=a Seminar on the session description protocol u=http://www.cs.ucl.ac.uk/staff/m.handley/sdp.03.ps e=mjh@isi.edu (Mark Handley) c=in IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 31 m=application 32416 udp wb a=orient:portrait

Esempio di INVITE per telefonata Bell chiama lista di rilanci aggiornata a partire dalla sorgente; rimossi nelle risposte Numera le transazioni Descrizione SDP (version) (origin) (session) (con. address) (media) INVITE sip:watson@boston.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:watson@bell-tel.com> Call-ID: 3298420296@kton.bell-tel.com CSeq: 1 INVITE Subject: Mr. Watson, come here. Content-Type: application/sdp Content-Length:... v=0 o=bell 53655765 2353687637 IN IP4 128.3.4.5 s=mr. Watson, come here. c=in IP4 kton.bell-tel.com m=audio 3456 RTP/AVP 0 3 4 5 (PCM, GSM, G.723, DVI4)

Esempio di INVITE per telefonata Watson risponde Watson risponde SIP/2.0 100 Trying Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311 Call-ID: 3298420296@kton.bell-tel.com CSeq: 1 INVITE Content-Length: 0 distingue istanze multiple dello stesso utente x forking SIP/2.0 180 Ringing Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311 Call-ID: 3298420296@kton.bell-tel.com CSeq: 1 INVITE Content-Length: 0

Esempio di INVITE per telefonata Watson risponde SIP/2.0 200 OK Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: <sip:watson@bell-tel.com> ;tag=37462311 Call-ID: 3298420296@kton.bell-tel.com CSeq: 1 INVITE Contact: sip:watson@boston.bell-tel.com Content-Type: application/sdp Content-Length:... v=0 o=watson 4858949 4858949 IN IP4 192.1.2.3 s=i'm on my way c=in IP4 boston.bell-tel.com m=audio 5004 RTP/AVP 0 3 (PCM, GSM)

Esempio di INVITE per telefonata Bell conferma Bell chiude ACK sip:watson@boston.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311 Call-ID: 3298420296@kton.bell-tel.com CSeq: 1 ACK BYE sip:watson@boston.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. A. Watson <sip:watson@bell-tel.com> ;tag=37462311 Call-ID: 3298420296@kton.bell-tel.com CSeq: 2 BYE

SIP Descrizione delle sessioni Se durante una sessione la descrizione deve essere cambiata (cambio di tipo di media, di indirizzo, di porta, ecc.) basta inviare un nuovo messaggio di INVITE (chiamato o chiamante) con lo stesso Call-ID Questi nuovi messaggi sono trattati allo stesso modo fatta eccezione per il fatto che non viene allertato l utente e in caso di fallimento non viene chiusa la sessione SI NOTI che i messaggi SIP e SDP non sono legati, quindi risulta possibile invitare ad una sessione un host senza che tale host sia poi coinvolto nella sessione stessa

Third Party Call Control Molti servizi richiedono che entità terze possano creare chiamate fra due utenti o servizi IVR (Interactive Voice Response) Click to dial Prepaid calling Questo tipo di controllo viene effettuato in modo naturale dagli User Agent manipolando il SDP A 200 SDP-A 1 INVITE no SDP RTP 2 5 INVITE SDP -A ACK SDP-B B 3 200 SDP-B 4 6 ACK Application Server

SIP Call Forwarding e Mobilità Personale Interna shannon.elet.polimi.it INVITE sip:bob@columbia.edu SIP/2.0 To: bob@columbia.edu From:Antonio.Capone@polimi.it Cseq: 1 INVITE Contact:sip:antonio@shannon.elet.polimi.it 2 1 SIP/2.0 100 Trying SIP/2.0 180 Ringing 7 SIP/2.0 200 OK To: <bob@columbia.edu>:tag=17 From:Antonio.Capone@polimi.it Cseq: 1 INVITE Contact: sip:carol@sec.cs.columbia.edu 9 proxy sip.columbia.edu ACK sip:carol@sec.cs.clombia.edu SIP/2.0 10 INVITE sip:bob@play.cs.columbia.edu SIP/2.0 To: bob@columbia.edu From:Antonio.Capone@polimi.it 4 3 SIP/2.0 302 Moved Temporarily Contact: sip:carol@sec.cs.columbia.edu INVITE sip:carol@sec.cs.columbia.edu SIP/2.0 To: bob@columbia.edu From:Antonio.Capone@polimi.it 6 5 SIP/2.0 180 Ringing 8 SIP/2.0 200 OK To: <bob@columbia.edu>:tag=17 From:Antonio.Capone@polimi.it Cseq: 1 INVITE Contact: sip:carol@sec.cs.columbia.edu play sec

SIP Servizi di Telefonia Molti servizi telefonici classici sono già forniti dalla modalità operativa base di SIP; ad esempio: Caller ID Number Mapping (numeri 800) Call Forwarding Call Hold L idea base di questi sistemi è però diversa: Non considerare un insieme di servizi da fornire Ma un insieme di strumenti con il quale i servizi possono essere creati o adattati da parte dell utente o operatore o fornitore di servizi

SIP Creazione di Servizi Essendo molto simile nella sintassi, SIP si può facilmente integrare con altri applicativi IP per fornire nuovi servizi non disponibili nelle reti telefoniche classiche Esempi: Instant message when busy Se il chiamato è occupato in un altra conversazione, il chiamante può fargli pervenire direttamente un instant message per avvisarlo lo stesso di qualcosa

SIP Creazione di Servizi Forward to E-mail Se il chiamato non può rispondere, le informazioni sulla chiamata ricevuta vengono inviate per e-mail Redirection to Web Il chiamante si può presentare con una web page ricca di informazioni e figure Il chiamato può mettere in attesa il chiamante con una pagina web che contiene informazioni utili

Esempio Utilizzo di applicazioni per la rivelazione della presenza presso un terminale 1 Email Invites Conversation 2 Embedded Presence Projection 3 One Click ecall servizio HearMe www.hearme.com

Esempio Utilizzo di applicazioni per la messaggistica di tutti i tipi Servizio di messag. www.mailvision.com

Esempio: PIZZERIA Quando viene fatta una chiamata ad una pizzeria il proxy automaticamente visualizza presso il client il menu in forma di documento http ASB SIP UA Proxy SIP UA User at Home Pizza Company

Strumenti per i Servizi Gli strumenti più utilizzati per la creazione dei servizi sono: Endpoint Service Markup Language Processing ability SIP CGI (Common Gateway Interface) Call Processing Language Java applets

SIP Sicurezza La sicurezza richiesta ai servizi forniti da SIP riguarda soprattutto l autenticazione degli utenti SIP eredita i meccanismi base di autenticazione da HTTP che richiedono l invio in chiaro di account e password Questi meccanismi anche se semplici sono sufficienti se il livello di trasporto è già reso sicuro mediante altri meccanismi di crittazione a livello IP E inoltre fornito un meccanismo di Digest authentication basato su un meccanismo a sfidarisposta che assicura che le due parti condividano un codice segreto (simile GSM)

SIP Sicurezza Parte dei messaggi delle richieste SIP possono essere firmati digitalmente e crittati con PGP Non si possono crittare la status line e l Header Via messaggio crittato: INVITE sip:watson@boston.bell-telephone.com SIP/2.0... Encryption: PGP version=2.6.2,encoding=ascii hqemaxkp5gpd+j5xaqf/zdifgd/... parte in chiaro: Subject: Mr. Watson, come here. Content-Type: application/sdp SDP può trasportare chiavi di crittazione per i media (quando il corpo è crittato)

Firewall and NAT I messaggi (applicativi) H.323 e SIP contengono indirizzi IP e n. di porta (molteplici) Problemi di interoperabilità se una rete privata è collegata a Internet attraverso un dispositivo che esegue NAT o Firewall H.323 RAS RRQ requestseqnum protocolidentifier nonstandarddata discoverycomplete callsignaladdress rasaddress terminaltype terminalalias gatekeeperidentifier endpointvendor SIP INVITE C->S: INVITE sip:watson@boston.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com> To: T. Watson <sip:watson@bell-tel.com> Call-ID: 3298420296@kton.bell-tel.com... v=0 o=bell 53655765 2353687637 IN IP4 128.3.4.5 s=mr. Watson, come here. c=in IP4 128.3.4.5 m=audio 3456 RTP/AVP 0 3 4 5 (PCM, GSM, G.723)

Application Level Gateway (ALG) Possibile soluzione: Application Level Gateway che cambi tutti gli indirizzi, e le numerose porte nei messaggi di segnalazione (Header e SDP in SIP) e che deve essere context aware perché i vari messaggi sono legati in modo complesso Livello TCP-UDP Livello IP

Application Level Gateway (ALG) Svantaggi di ALG inglobato nei NAT è complesso ne servono uno per applicazione va aggiornato ad ogni aggiornamento dell applicazione impedisce la crittografia end-to-end del corpo della segnalazione

MIDCOM Architecture La Middlebox Communication Architecture (RFC 3303) definisce un framework in cui dalle apparecchiature di controllo di rete (Middlebox) si isola l intelligenza di comando in MIDCOM agent ciascuno dei quali può essere specializzato in particolari applicazioni (scinde le funzioni di ALG e di NAT/FW ) Caratteristiche: Consente il riuso delle risorse La fornitura third party SIP MIDCOM protocol Firewall/NAT Midcom agent Media SIP

MIDCOM Architecture Il MIDCOM protocol consente agli agenti con intelligenza legata alle applicazioni di fare in modo che l applicazione risulti trasparente al Middlebox Midcom agent (nel proxy) SIP MIDCOM protocol SIP alloca e rilascia le associazioni NAT apre e chiude i passaggi Firewall/NAT Media

Es: Chiamata Entrante in Firewall

Es: Chiamata Entrante in NAPTP

Management and Auto-Configuration SIP MIB per proxy, redirect, registrar e user agent DHCP per i SIP Server Gli User agent possono sapere dove registrarsi e mandare richieste Service Location Protocol (SLP) Templates SLP permette ai client di scoprire i server in base ai loro servizi SLP template permette di scoprire i servizi IPSec and TLS transport CPL support Support for caller preference

HTML5 e WebRTC HTML5 è la versione più evoluta del linguaggio di markup utilizzato nell architettura applicativa WWW Introduce nuovi elementi anche multimediali (audio, video) e una nuova API basata su Javascript Apre la via all evoluzione dell architettura WWW alle comunicazioni multimediali real-time: WebRTC: il browser diventa il nuovo hub delle comunicazioni

WebRTC WebRTC (Web Real-Time Communication) è un API in via di standardizzazione presso il World Wide Web Consortium (W3C) per consentire di sviluppare applicazioni browser-to-browser per: Comunicazioni vocali Video chat multiparty Condivisione di file P2P SENZA IMPIEGARE PLUGIN

API WebRTC

Codificatori I client WebRTC devono implementare i seguenti codec audio Opus [RFC6716] G.711 (PCMA e PCMU) Per i codec video i giochi sono ancora aperti H.264 (tecnologia coperta da numerosi brevetti, opensource di Cisco da ottobre 2013, sostenuto da molte aziende: licenze gratuite per innovazione V8 (IPR di Google, da acquisizione di On2 Technologies nel 2010) http://www.opus-codec.org/ http://www.openh264.org/

WebRTC in azione Le API WebRTC rendono disponibili chiamate di controllo per stabilire una comunicazione tra browser P2P anche superando i NAT (con apposite soluzioni: ICE, STUN e TURN) I flussi P2P possono usare i protocolli SRTP, SCTP e DTLS

Attraversamento dei NAT STUN (Session Traversal Utilities for NAT) - RFC 5389 Traversal Using Relay NAT (TURN) - RFC 5766 Interactive Connectivity Establishment (ICE) - RFC 5245