RETI MOBILI E MULTIMEDIALI

1
RETI MOBILI E MULTIMEDIALI
Università degli Studi di Roma La Sapienza
Dipartimento INFOCOM

• Aldo Roveri
• Lezioni dell a.a. 2009-2010

1
2
VI. Multimedia
Aldo Roveri, RETI MOBILI E MULTIMEDIALI Univ.
di Roma La Sapienza - a.a. 2009-2010
3
CONTENUTI

• VI.1 Compressione audio e video
• VI.2 Loperazione di streaming
• VI.3 Streaming audio/video memorizzato
• VI.4 Servizi audio e video interattivi
• VI.5 Controllo della multimedialità

4
Multimedia

• VI.1 Compressione audio e video

5
Digitalizzazione della voce

• La voce telefonica analogica ha una larghezza di
  banda lorda di 4 kHz
• può quindi essere campionata con una frequenza di
  8 kHz ciò produce 8000 campioni/s.
• Secondo la codifica PCM standard, ogni campione è
  codificato con 8 bit il segnale numerico
  risultante ha quindi un ritmo uguale a 64 kbit/s.

6
Digitalizzazione dei suoni musicali (1/2)

• Se si desidera riprodurre suoni ad alta fedeltà
  (HF), la larghezza di banda lorda del segnale
  analogico viene normalmente assunta uguale a
  22,050 kHz per ogni canale (tra i due di una
  riproduzione stereo).
• Il campionamento per ogni canale deve essere
  allora alla frequenza di 44,100 kHz.

7
Digitalizzazione dei suoni musicali (2/2)

• Utilizzando una codifica a 16 bit/campione il
  segnale digitale che ne risulta per musica HF
  mono-canale ha un ritmo uguale
• 44,1 x 16 705,6 kbit/s ,
• mentre per musica HF stereo (due canali) il
  ritmo binario è uguale a
• 44,1 x 16 x 2 1,411 Mbit/s.
• Per un trasferimento o una memorizzazione è
  necessaria unoperazione di compressione.

8
Digitalizzazione di dati video (1/5)

• Un segnale video è il risultato di una sequenza
  di immagini fisse che vengono presentate su uno
  schermo con una velocità tale da dare
  limpressione del movimento i nostri occhi non
  possono infatti distinguere le singole immagini
  quando queste vengono riprodotte in sequenza con
  sufficiente velocità.

9
Digitalizzazione di dati video (2/5)

• Per ingannare locchio umano con limpressione
  del movimento sono sufficienti 25 immagini/s, ma
  per evitare effetti di tremolio dellimmagine
  ogni immagine viene ridisegnata una seconda
  volta ne consegue che la presentazione è
  equivalente a 50 immagini/s.
• Daltra parte ogni immagine è composta da una
  matrice di pixel (Picture Elements), il cui
  numero (in verticale e in orizzontale)
  costituisce la risoluzione dellimmagine.

10
Digitalizzazione di dati video (3/5)

• Ogni pixel viene rappresentato da una sequenza di
  bit, che specifica il colore del pixel per
  immagini in bianco e nero basta 1 bit/pixel per
  immagini a colori il numero di bit per ogni pixel
  dipende dal numero di colori impegnati.

11
Digitalizzazione di dati video (4/5)

• La risoluzione standard di ogni immagine (quadro)
  di un segnale televisivo su schermo di formato
  43 contiene 720x576 pixel, mentre per un sistema
  ad alta definizione (HD TV) su uno schermo di
  formato 169 la risoluzione prevede un quadro
  contenente 1920x1152 pixel.

12
Digitalizzazione di dati video (5/5)

• Se allora ciascuno dei tre colori primari (rosso,
  verde, blu) è codificato con 8 bit e se quindi
  ogni pixel è rappresentato con 24 bit, ogni
  immagine di un segnale televisivo a colori con
  risoluzione standard è codificabile con
• 720 x 576 x 24 9,95 Mbit.
• Conseguentemente il segnale televisivo, che è una
  sequenza di immagini di questo tipo, viene
  numerizzato con un ritmo binario, che è uguale a
• 25 x 9,95 248,8 Mbit/s
• e che per essere trasferito o memorizzato
  richiede unoperazione di compressione.

13
Tecniche di compressione (1/2)

• Nella compressione di segnali numerici audio e
  video si adottano attualmente due principali
  tecniche di compressione
• quella predittiva
• quella percettiva.
• Si distinguono poi tecniche di tipo
• lossless, senza perdita di informazione,
• lossy, con perdita di informazione.

14
Tecniche di compressione (2/2)

• Una tecnica di compressione è qualificabile
  attraverso il cosiddetto rapporto di compressione
  e cioè il rapporto tra i due ritmi a monte e a
  valle delloperazione di codifica.
• Comè intuitivo, le tecniche lossy consentono di
  conseguire un maggior rapporto di compressione
  rispetto a quelle lossless, ma a spese di una
  minore qualità del risultato auditivo o visivo.

15
Compressione del segnale telefonico (1/5)

• Nelle reti mobili (ove è importante contenere i
  ritmi del segnale trasferito) la voce telefonica
  è codificata con una tecnica chiamata AMR
  (Adaptive MultiRate).
• Il codificatore AMR è un dispositivo integrato
  singolo con otto possibili velocità emesse i
  ritmi che ne risultano sono controllabili dalla
  rete di accesso radio e non dipendono dalla
  effettiva attività della sorgente.

16
Compressione del segnale telefonico (2/5)

• Tra i ritmi riportati nella Tab.VI.1 vanno
  segnalati quello di 12,2 kbit/s che è impiegato
  nel GSM e che, nella versione a pieno ritmo
  (EFR), è ulteriormente impiegato in UMTS, ove il
  codificatore è in grado di modificare il proprio
  ritmo binario ogni 20 ms.

17
Compressione del segnale telefonico (3/5)
Codec Ritmo binario (kbit/s)
AMR_12.20 12.20 (GSM- EFR)
AMR_10.20 10.20
AMR_7.95 7.95
AMR_7.40 7.40 (IS-641)
AMR_6.70 6.70 (PDC-EFR)
AMR_5.90 5.90
AMR_5.15 5.15
AMR_4.75 4.75
AMR_SID 1.80
Tab.VI.1
18
Compressione del segnale telefonico (4/5)

• Lo schema di codifica in AMR è il cosiddetto
  ACELP (Algebraic Code Excited Linear Prediction
  coder) ogni 20 ms (e quindi ogni 160 campioni
  estratti alla frequenza di 8kHz), il segnale
  vocale è analizzato per estrarne i parametri del
  modello CELP i bit dei parametri vocali emessi
  dal codificatore sono poi pesati in funzione
  della loro importanza soggettiva prima di essere
  emessi.

19
Compressione del segnale telefonico (5/5)

• Lato sorgente si impiega un rivelatore di tratti
  di voce attiva (VAD Voice Activity Detector) e
  si valuta il rumore acustico di sottofondo
  questo rumore (Comfort Noise) viene trasferito al
  lato ricevente, che provvede, con trame apposite
  ad intervalli regolari dette SID (Silence
  Descriptor), a riprodurlo nei periodi in cui non
  sono ricevute trame vocali.

20
Compressione dei dati audio (1/3)

• Nella compressione predittiva, detta anche
  differenziale, si codifica la differenza tra ogni
  campione e una predizione di questo effettuata
  sulla base dei campioni precedenti.
• Il vantaggio risiede nella minore dinamica dei
  campioni differenza e quindi nella possibilità di
  codificarli con un minore numero di bit rispetto
  alla codifica di ogni campione con ampiezza quale
  risulta dal campionamento del segnale di
  sorgente.

21
Compressione dei dati audio (2/3)

• Un esempio di questa tecnica è rappresentato dal
  DPCM (Differential PCM) che codifica
• un segnale telefonico al ritmo di 32 kbit/s
• un segnale vocale con banda lorda di 7kHz (e
  quindi con qualità migliore rispetto al segnale
  telefonico) al ritmo di 64 kbit/s.

22
Compressione dei dati audio (3/3)

• Nella compressione percettiva si sfruttano alcune
  caratteristiche del sistema uditivo alcuni
  suoni, in frequenza e nel tempo, non ci fanno
  percepire altri suoni.
• La codifica MP3 (MPEG-1 Audio Layer 3) utilizza
  queste caratteristiche producendo segnali audio
  digitali a velocità comprese tra 112 e 128 kbit/s
  con rapporti di compressione che
  corrispondentemente variano tra 12 1 e 101.
• Il ritmo di codifica cresce passando al Layer 2
  (tra 192 e 256 kbit/s) e al Layer 1 (384 kbit/s).
• Si tratta in ogni caso di codifiche di tipo
  lossy.

23
Compressione dei dati video immagini fisse (1/3)

• Nello standard JPEG (Joint Photographic Experts
  Group) la compressione, che è usualmente di tipo
  lossy, è attuata in tre passi
• limmagine è segmentata in blocchi di 8 x 8
  pixel e di ogni blocco di 64 pixel viene
  calcolato il contenuto spettrale nello spazio con
  una Discrete Cosine Transform (DCT)
  bidimensionale

24
Compressione dei dati video immagini fisse (2/3)

• segue una quantizzazione effettuata tramite
  opportune matrici che pesano i coefficienti di
  ordine più basso (che rappresentano le frequenze
  spaziali minori) con un passo di quantizzazione
  più piccolo e viceversa per i coefficienti di
  ordine più alto
• si conclude con una codifica entropica e con una
  eliminazione delle ridondanze di tipo statistico
  la componente continua della DCT è codificata in
  DPCM.

25
Compressione dei dati video immagini fisse (3/3)

• Il rapporto di compressione che si può
  raggiungere è determinato essenzialmente dal
  parametro di scalatura per la matrice di
  quantizzazione si può raggiungere un rapporto di
  compressione 151 senza alterare visibilmente la
  qualità dellimmagine

26
Compressione dei dati video immagini in
movimento (1/2)

• La compressione MPEG (Moving Picture Experts
  Group) è specifica per immagini in movimento
• Si attua riducendo la ridondanza delle singole
  immagini (codifica intraframe) e delle relazioni
  tra immagini successive (codifica interframe).
• Nella sua prima versione (MPEG-1) lo standard è
  stato predisposto per la memorizzazione di dati
  su CD e opera a una velocità di 1,5 Mbit/s.

27
Compressione dei dati video immagini in
movimento (2/2)

• La seconda versione (MPEG-2) è stata progettata
  per i DVD e opera a velocità più alte, da 3 a 6
  Mbit/s è impiegata nella formazione del segnale
  diffuso nella TV digitale terrestre e
  satellitare.
• Le compressioni effettuate nei due standard
  MPEG-1 e MPEG-2 sono di tipo lossy.

28
Multimedia

• VI.2 Loperazione di streaming

29
Classi di applicazioni multimediali

• Ci riferiamo alle operazioni di streaming di
  informazioni audio/video e, in questo ambito,
  distinguiamo tre classi a cui corrispondono
  modalità di attuazione ed esigenze prestazionali
  tra loro diverse.
• Le tre classi sono
• streaming audio/video memorizzato
• streaming audio/video in tempo reale
• streaming audio/video in tempo reale interattivo.

30
Perdite di pacchetti (1/5)

• Per ognuna di queste tre classi, occorre tenere
  conto che Internet offre un servizio di rete
  best-effort (a meno di interventi correttivi su
  cui si parlerà nel seguito) e che tale tipo di
  servizio può portare a mancanza di controllo su
• perdite di pacchetti
• ritardi di trasferimento dei pacchetti.

31
Perdite di pacchetti (2/5)

• Le perdite hanno origine nei buffer dei router
  attraversati dai pacchetti nel loro transito
  dallorigine alla destinazione sono
  sostanzialmente dovute allevento di trabocco di
  questi buffer e al conseguente scarto dei
  pacchetti che non possono essere inoltrati verso
  un collegamento in uscita.
• Altre cause di perdita sono dovute a disturbi di
  natura varia quali si presentano, ad esempio, in
  collegamenti wireless.

32
Perdite di pacchetti (3/5)

• Se lo streaming riguarda solo un flusso
  audio/video, il grado di perdita (quota parte dei
  pacchetti persi rispetto a quelli emessi
  allorigine) non è una prestazione critica, nel
  senso che possono essere tollerati gradi di
  perdita di valore contenuto, orientativamente non
  superiore al 10, ma in ogni caso con valore
  limite dipendente da ogni specifica applicazione.

33
Perdite di pacchetti (4/5)

• Quando lo si reputi necessario, si può contenere
  leffetto delle perdite
• in ricezione, con il mascheramento delle perdite
  attuato con linterpolazione dei dati mancanti
  con quelli ricevuti
• in trasmissione, con limpiego di codici
  correttori derrore (FEC), di schemi di
  interallacciamento (interleaving) e, in generale,
  di ridondanza a bassa velocità e a bassa
  risoluzione.

34
Perdite di pacchetti (5/5)

• I gradi di perdita possono essere fortemente
  contenuti con ladozione di TCP come protocollo
  di trasporto in luogo di UDP e compatibilmente
  con la prestazione di ritardo.

35
Ritardi di trasferimento (1/4)

• Il ritardo di trasferimento di un pacchetto da
  estremo a estremo è la somma dei tempi di
  trasmissione e dei ritardi di propagazione, di
  elaborazione e di accodamento nei router
  attraversati dal pacchetto sul suo percorso da
  estremo a estremo.

36
Ritardi di trasferimento (2/4)

• Il ritardo di un pacchetto ha in generale natura
  aleatoria dipende infatti da vari parametri
  legati alla trasmissione del pacchetto stesso e
  al collegamento che è di supporto alla
  trasmissione si manifesta quindi con
  realizzazioni che presentano
• un valor medio, che chiameremo ritardo di base e
  che dipende, a parità del collegamento, dal
  carico sui nodi e sui rami della rete
• fluttuazioni allintorno del ritardo di base, che
  sostanzialmente dipendono dalla variabilità delle
  durate di permanenza dei pacchetti nei buffer dei
  router e che sono denominate jitter di pacchetto.

37
Ritardi di trasferimento (3/4)

• I valori dei ritardi di base possono assumere
  valori non particolarmente stringenti nelle due
  classi di streaming con file memorizzati o in
  tempo reale, con un limite più stretto per la
  seconda classe rispetto alla prima, ma in ogni
  caso entro valori di qualche decina di secondi.
• Nel caso invece della classe di streaming
  interattivo, il ritardo di base deve avere un
  valore tale da non pregiudicare linterattività
  della comunicazione.

38
Ritardi di trasferimento (4/4)

• Ad esempio, nel caso di trasferimenti in campo
  telefonico, ritardi di base inferiori a 150 ms
  non sono percepiti dallorecchio umano.
• Se il ritardo cresce nellintervallo tra 150 e
  400 ms, la qualità della comunicazione, seppure
  peggiorata, è ancora accettabile.
• Tale qualità peggiora in modo da pregiudicare
  linterattività della comunicazione se il ritardo
  supera orientativamente il valore di 400 ms.

39
Jitter di pacchetto (1/4)

• Nel trasferimento di dati audio/video in tempo
  reale (interattivo o meno) assume importanza
  sulla qualità dellinformazione ricevuta il
  jitter di pacchetto, e cioè la variabilità del
  ritardo con cui arrivano i pacchetti che
  contengono i dati.
• Per una corretta riproduzione dei dati
  audio/video in tempo reale è necessario che il
  jitter sia di valore il più possibile contenuto.

40
Jitter di pacchetto (2/4)

• Gli effetti del jitter possono essere contenuti
• aggiungendo, in emissione, ad ogni pacchetto
  listante relativo di generazione
• scegliendo opportunamente, in ricezione, linizio
  della riproduzione
• memorizzando i dati ricevuti in un buffer di
  riproduzione, in attesa dellinizio della
  riproduzione
• prevedendo di dotare i pacchetti di numeri di
  sequenza, che consentano il riordino dei
  pacchetti in ricezione
• scartando i pacchetti che pervengono dopo
  linizio della riproduzione.

41
Jitter di pacchetto (3/4)

• In Fig.VI.1 è mostrato il trattamento in
  ricezione di pacchetti emessi a intervalli
  costanti e trasferiti con ritardi affetti da
  jitter sono considerati i tempi di permanenza
  nel buffer di riproduzione e, in particolare,
  viene mostrato il caso di scarto di un pacchetto.

42
Jitter di pacchetto (4/4)
Fig.VI.1
43
Multimedia

• VI.3 Streaming audio/video memorizzato

44
Streaming audio/video memorizzato (1/3)

• Il contenuto multimediale è memorizzato su un
  server e può essere trasferito a un client che ne
  fa richiesta.
• La riproduzione del file presso il client deve
  essere continua , e cioè deve poter essere in
  sincronia con i tempi di registrazione originali
  ciò impone limiti critici al ritardo dei dati,
  che devono essere ricevuti dal client in tempo
  utile per la loro riproduzione.

45
Streaming audio/video memorizzato (2/3)

• Questo vincolo di riproduzione continua non
  impedisce che, con una opportuna modalità di
  controllo, il client abbia la possibilità di
  interagire con il server per ottenere funzioni
  tipiche di un registratore audio/video operante
  in locale, quali il fermo-riproduzione e la
  possibilità di spostarsi in avanti o
  allindietro.
• Il trasferimento del file è usualmente di tipo
  unicast.

46
Streaming audio/video memorizzato (3/3)

• Nel modulo, che presso il client consente di
  riprodurre il file trasferito, devono essere
  previste varie funzioni quali
• la decompressione dei file audio/video durante la
  riproduzione
• la rimozione del jitter quando necessario per la
  qualità della riproduzione e con le modalità
  chiarite in precedenza
• il contenimento delle perdite quando necessario
  per la qualità della riproduzione la modalità
  più semplice è ottenuta mascherando le perdite
  con linterpolazione dei dati mancanti con quelli
  ricevuti.

47
Streaming con media player (1/3)

• Un file audio/video memorizzato potrebbe essere
  trasferito come un qualsiasi altro file.
• Ad esempio si potrebbe usare un browser e
  trasferire il file residente su un server web
  attraverso il protocollo HTTP.
• In questa ipotesi il server web potrebbe spedire
  il file in forma compressa al browser.
• Il browser, dopo aver memorizzato il file,
  potrebbe utilizzare un applicazione ausiliaria,
  chiamata media player , che permette di ascoltare
  laudio e di vedere il video e che quindi ne
  consente la riproduzione (Fig VI.2).

48
Streaming con media player (2/3)
Fig.VI.2
49
Streaming con media player (3/3)

• Il trasferimento del file audio/video effettuato
  in questo modo ha un grosso inconveniente dato
  che file di questo tipo hanno in generale grandi
  dimensioni anche se in forma compressa e dato che
  una loro riproduzione può avvenire solo dopo un
  loro trasferimento completo, lutente, in
  funzione del collegamento utilizzato con il
  server, deve aspettare tempi anche molto lunghi
  prima di usufruire del contenuto del file ciò
  può essere inaccettabile.

50
Streaming con metafile (1/3)

• Per risolvere questo problema, il media player si
  connette direttamente al server per ottenere da
  questo il file audio/video e per poterlo
  riprodurre durante la ricezione.
• Per questo scopo il server web memorizza due
  file
• il file audio/video
• un metafile , che contiene informazioni riguardo
  al file audio/video.

51
Streaming con metafile (2/3)

• In questa modalità il browser
• richiede al server web laccesso al file
  audio/video
• ottiene dal serve web il metafile che viene
  passato al media player
• il media player richiede al server web il vero
  file audio/video, utilizzando le informazioni del
  metafile
• Con tale procedura (Fig.VI.3) è possibile
  cominciare a riprodurre il file prima di
  completarne il trasferimento.

52
Streaming con metafile (3/3)
Fig.VI.3
53
Streaming con media server (1/4)

• La soluzione con metafile, in cui il media player
  interagisce con un server web, ha unulteriore
  inconveniente rispetto a quella in Fig.VI.2.
• Tale inconveniente è legato alluso del
  protocollo HTTP che, a sua volta, usa il
  protocollo TCP questo offre un trasferimento
  affidabile (con controllo degli errori), ma con
  possibili ritardi legati alla riemissione dei
  file rivelati errati.

54
Streaming con media server (2/4)

• Per uno streaming di dati audio/video è più
  importante avere il trasferimento dei dati con
  ritardo contenuto piuttosto che con bassi tassi
  di errore.
• Per superare linconveniente al server web si
  aggiunge un altro server, che viene detto media
  server.
• Il server web provvede, a richiesta, a fornire il
  metafile, mentre il trasferimento del file è a
  cura del media server.

55
Streaming con media server (3/4)

• Rispetto al caso precedente, è il metafile a
  specificare il media server dal quale si può
  ottenere il file audio/video.
• Con questa variante, illustrata in Fig.VI.4, il
  trasferimento del file dal media server al media
  player avviene con luso di UDP (invece di TCP)

56
Streaming con media server (4/4)
Fig.VI.4
57
RTSP (1/3)

• RTSP (Real-Time Streaming Protocol) è un
  protocollo di controllo predisposto per
  aggiungere funzionalità allo streaming di un file
  audio/video.
• In particolare RTSP controlla, come mostrato in
  Fig.VI.5, il trasferimento del file attraverso

58
RTSP (2/3)

• linstaurazione di una connessione dal media
  player al media server
• linoltro di comandi di riproduzione (comprensivi
  di inizio, pause, etc.) da parte del media
  player
• il successivo invio del flusso di dati
  audio/video da parte del media server
• la chiusura della connessione comandata dal media
  player.

59
RTSP (3/3)
Fig.VI.5
60
Multimedia

• VI.4 Servizi audio e video in tempo reale

61
Streaming dal vivo (1/2)

• Lo streaming di un evento dal vivo, detto anche
  streaming in tempo reale, non è sostanzialmente
  diverso da uno streaming di un file memorizzato
  quindi vale quanto già detto in VI.3.
• Le differenze sostanziali sono due
• il file da distribuire viene prodotto in tempo
  reale
• la distribuzione è multicast (a differenza di
  quella unicast che si adotta quando il file è
  memorizzato).

62
Streaming dal vivo (2/2)

• Valgono per il resto le stesse considerazioni
  svolte per un file memorizzato la riproduzione
  deve poter essere continua e nel modulo di
  ricezione devono essere previste la rimozione del
  jitter e il contenimento delle perdite.

63
Streaming audio/video in tempo reale interattivo

• Rispetto ai due precedenti casi di streaming,
  questa terza classe prevede, oltre allo scambio
  di dati audio/video, anche linterazione tra gli
  utenti coinvolti nella comunicazione.

64
Multicast

• Si ribadisce che i dati audio/video in tempo
  reale debbono essere diffusi in modalità
  multicast per meglio fronteggiare il carico sulla
  rete che si determina per effetto della grande
  quantità di dati da trasferire.

65
Mixing

• Quando più sorgenti spediscono dati, come ad es.
  in una video conferenza, il traffico in rete è
  composto da più flussi video.
• Per fare convergere il traffico in un unico
  flusso di dato video è necessario combinare i
  dati emessi dalle varie sorgenti tale operazione
  è chiamata mixing.
• Un mixer combina quindi i segnali audio/video di
  più sorgenti in un unico segnale.

66
Protocolli per streaming in tempo reale (1/2)

• Lo streaming di dati audio/video in tempo reale
  attraverso Internet richiede alcuni completamenti
  protocollari nello strato di trasporto.
• Un primo punto riguarda TCP, che presenta
  caratteristiche non adatte per questo tipo di
  comunicazione infatti
• non supporta il trasferimento multicast anche se
  offre la possibilità di numerare i pacchetti
• possiede un meccanismo di controllo derrore che
  non è compatibile con il carattere in tempo reale
  dello streaming.

67
Protocolli per streaming in tempo reale (2/2)

• UDP è invece più adatto in quanto supporta il
  trasferimento multicast e non prevede
  ritrasmissione a seguito di errori non prevede
  però alcun supporto per i tempi di riproduzione,
  per lordinamento dei pacchetti e per il mixing.
• Si è resa quindi necessaria lintroduzione di
  nuovi protocolli questi sono RTP e RTCP.

68
RTP (1/4)

• Il traffico di dati audio/video in tempo reale
  richiede lutilizzo del protocollo RTP (Real-time
  Transport Protocol) in aggiunta allUDP
• RTP porta a questultimo gli element mancanti per
  la gestione del traffico in tempo reale e
  interattivo, e cioè i tempi di riproduzione,
  lordinamento dei dati e il mixing.
• La collocazione di RTP nella pila protocollare di
  Internet è mostrata nella Fig.VI.6.
• Nelle Fig.VI.7 è mostrato il formato
  dellintestazione di un pacchetto RTP, mentre in
  Tab.VI.2 ne viene fornito il contenuto.

69
RTP (2/4)
Fig.VI.6
70
RTP (3/4)
Fig.VI.7
71
RTP (4/4)
Tab.VI.2
72
RTCP (1/2)

• RTCP (Real-time Transport Control Protocol) offre
  funzionalità di controllo per gestire il
  protocollo RTP.
• Prevede cinque tipi di messaggi come mostrato
  nella Fig.VI.8.

73
RTCP (2/2)
Fig.VI.8
74
Multimedia

• VI.5 Controllo della multimedialità

75
Multimedia protocol stack
76
SIP Aspetti generali (1/3)

• SIP (Session Initiation Protocol) è un protocollo
  di controllo (segnalazione) di strato
  applicativo.
• Consente di instaurare, modificare e terminare
  sessioni multimediali
• audio video conference
• Chiamate telefoniche.
• Consente il supporto della personal mobility
• ad un utente è associato unico identificatore,
  qualsiasi sia la sua localizzazione in rete

77
SIP Aspetti generali (2/3)

• SIP supporta le seguenti funzionalità
• Localizzazione degli utenti
• Individuazione degli end-system coinvolti nella
  sessione
• Controllo della disponibilità di un utente a
  partecipare a una sessione
• Negoziazione dei parametri di una sessione
• Determinazione dei media coinvolti nella sessione
  e dei relativi parametri (es. codec)
• Instaurazione della sessione
• Gestione della sessione
• Modifica dei parametri
• Attivazione di nuovi servizi
• Terminazione della sessione

78
SIP Aspetti generali (3/3)

• Modello transazionale Client/Server
• Il Client emette la richiesta di attivazione di
  una funzione (Metodo)
• Il Server invia immediatamente una risposta
  provvisoria e, al termine del processamento della
  richiesta, una risposta definitiva
• I messaggi SIP possono essere trasferiti mediante
  un qualsiasi protocollo di trasporto (TCP, UDP,
  TLS, ecc.)
• UDP e TCP sono i protocolli più utilizzati

79
SIP Formato di un messaggio

• Protocollo testuale
• Un messaggio è composto da
• Una Start Line
• Uno o più Message-Header
• Message-Body (opzionale)

80
SIP Entità logiche (1/4)

• User Agent (UA)
• User Agent Client (UAC)
• È lentità che emette una richiesta di
  attivazione di un metodo
• Il ruolo di client è limitato solo alla durata
  della transazione.
• User Agent Server (UAS)
• È lentità che emette le risposte ad una
  richiesta SIP
• Il ruolo di server è limitato solo alla durata
  della transazione.

81
SIP Entità logiche (2/4)

• Proxy Server
• È unentità intermedia che agisce per conto
  dellutente che richiede un metodo nella sua
  procedura di esecuzione
• Una funzionalità tipica di un proxy è
  linstradamento della richiesta verso lutente di
  destinazione
• Agisce sia come UAC che come UAS.
• Registrar
• Riceve le richieste di registrazione degli utenti
  SIP in un dominio
• Gestisce le informazioni di localizzazione degli
  utenti
• Agisce come un Location Server (es. GSM HLR).

82
SIP Entità logiche (3/4)

• Redirect Server
• E un UAS che ha il compito di comunicare ad un
  UA o a un proxy verso quale indirizzo deve essere
  inviata una richiesta in modo che questa
  raggiunga lutente finale
• Utilizza il servizio di localizzazione.
• Back-to-Back User Agent (B2BUA)
• E un entità di disaccoppiamento che riunisce il
  ruolo di UAS e UAC
• Riceve una richiesta, la processa (ruolo di UAS),
  determina le modalità di completamento della
  richiesta stessa e genera una nuova richiesta per
  completare la procedura (ruolo di UAC).

83
SIP Entità logiche (4/4)
84
Tipologie di Proxy SIP

• Stateless proxy
• Un proxy che non mantiene nessuna informazione di
  stato relativa ad una transazione.
• Si limita a rilanciare i messaggi di richiesta e
  di risposta.
• Stateful proxy
• Un proxy che mantiene informazioni di stato di
  una transazione.
• Call stateful proxy
• Un proxy che memorizza tutte le informazioni di
  stato associate ad una sessione durante tutto il
  suo svolgimento.

85
Architettura SIP
86
SIP Indirizzamento

• Lindirizzamento SIP è basato sul URI (Uniform
  Resource Identifier), che identifica una
  qualsiasi risorsa di comunicazione (es. un
  utente, una mailbox, un terminale telefonico
  PSTN, ecc.)
• Un SIP URI contiene tutte le informazioni
  necessarie a iniziare e mantenere una sessione
  con la risorsa associata
• host name (obbligatorio)
• user name, port number, parameters, ecc.
  (opzionali)
• Ad una URI è associato lindirizzo di rete della
  risorsa mediante loperazione di registrazione ad
  un SIP Registrar
• La spazio di indirizzamento è virtualmente
  infinito

87
SIP Forma generale di un SIP URI

• Sipuserpassword_at_hostporturi-parameters?header
• userpassword
• identifica la risorsa di comunicazione di un host
  a cui si riferisce lindirizzo
• la password è opzionale
• host
• identifica lhost che supporta la risorsa SIP
• contiene normalmente lindirizzo IP
• port
• numero della porta a cui deve essere indirizzata
  la richiesta

88
SIP Forma generale di un SIP URI

• uri-parameters
• parametri associati alla richiesta (separati da
  )
• es. transport, ttl, ecc.
• il formato di ciascun parametro è del tipo
  nomevalue
• header
• header fields associati alla richiesta (separati
  da )
• il formato di ciascun header è del tipo
  hnomehvalue

89
Esempi di indirizzi SIP

• sipalice_at_atlanta.com
• sipalicesecretword_at_atlanta.comtransporttcp
• sip1-212-555-12121234_at_gateway.comuserphone
• sipalice_at_192.0.2.4
• sipanother-proxy.biloxi.comtransportUDP
• Normalmente è utilizzata la forma semplificata
• sipuser_at_host

90
Metodi Base

• INVITE
• È utilizzato per iniziare una sessione
• Include nel body la descrizione dei parametri
  della sessione (SDP)
• Linvio successivo di un altro INVITE (RE-INVITE)
  è utilizzato per modificare i parametri di una
  sessione già instaurata
• ACK
• È utilizzato per confermare lavvenuta
  linstaurazione di una sessione
• E emesso solo in risposta ad un INVITE
• BYE
• È utilizzato per terminare una sessione

91
Metodi Base

• CANCEL
• È utilizzato per cancellare un richieta il cui
  processamento non è stato ancora completato
• OPTIONS
• È utilizzato per chiedere informazioni sulle
  funzionalità di un server
• REGISTER
• È utilizzato per effettuare la registrazione di
  un utente ad un Registrar
• Consente di creare lassociazione tra lutente e
  il suo attuale indirizzo di rete

92
Metodi Addizionali

• INFO
• È utilizzato per trasferire messaggi di
  segnalazione durante lo svolgimento di una
  sessione
• PRACK
• Riscontro provvisorio
• COMET
• Notifica di accettazione di una precondizione
• REFER
• Consente di richiedere linstaurazione di una
  sessione tra due specificate risorse (Third
  Party Call)

• SUBSCRIBE
• Iscrizione al servizio (instant messaging)
• UNBSCRIBE
• Cancellazione dal servizio (instant messaging)
• NOTIFY
• Notifica di messaggi entranti (instant messaging)
• MESSAGE
• Messaggio(instant messaging)

93
Risposte (1/2)

• Sono definite sei classi di risposte
• Le risposte sono codificate con un codice a 3
  digit
• Il primo digit codifica la classe della risposta
• Gli altri due digit indicano il tipo particolare
  di risposta
• 1xx - Provisional
• La richiesta è stata ricevuta ed è in corso di
  elaborazione
• 2xx Success
• La richiesta è stata completata con successo

• 3xx Redirection
• La richiesta deve essere inoltrata verso unaltra
  locazione
• 4xx Client error
• La richiesta contiene un errore e non può essere
  completata
• 5xx Server error
• La richiesta sebbene corretta non può essere
  completata dal server
• 6xx Global Failure
• La richiesta non può essere completata da nessun
  server

94
Risposte (2/2)
95
Esempio di Messaggio INVITE (1/4))
INVITE sipuserB_at_there.com SIP/2.0 Via
SIP/2.0/UDP pcA.here.com5060 branchz9hG4bk776as
dhds Max-Forwards 70 To User B
ltsipuserB_at_there.comgt From User A
ltsipuserA_at_here.comgt Call-ID 4598998103413_at_4.3.2.
1 CSeq 314159 INVITE Contact ltsipUserA_at_here.com
gt Content-Type application/sdp Content-Length
142 Message Body

• La prima linea contiene
• il nome del metodo (INVITE)
• LURI del estinatario della richiesta
• La versione corrente di SIP (2.0)
• Le linee che seguono sono una lista di
  header-fields

• Via
• Versione di SIP
• Protocollo di trasporto usato
• Indirizzo IP (o il nome) del richiedente
• Numero di porta
• Il parametro branch identifica la transazione

96
Esempio di Messaggio INVITE (2/4)
INVITE sipuserB_at_there.com SIP/2.0 Via
SIP/2.0/UDP pcA.here.com5060 branchz9hG4bk776as
dhds Max-Forwards 70 To User B
ltsipuserB_at_there.comgt From User A
ltsipuserA_at_here.comgt Call-ID 4598998103413_at_4.3.2.
1 CSeq 314159 INVITE Contact ltsipUserA_at_here.com
gt Content-Type application/sdp Content-Length
142 Message Body

• Max-Forwards
• Limita il numero di hop che la richiesta può
  compiere prima di arrivare a destinazione

• To
• Nome del destinatario
• URI del destinatario originale

• From
• Nome del richiedente
• URI del richiedente

97
Esempio di Messaggio INVITE (3/4)
INVITE sipuserB_at_there.com SIP/2.0 Via
SIP/2.0/UDP pcA.here.com5060 branchz9hG4bk776as
dhds Max-Forwards 70 To User B
ltsipuserB_at_there.comgt From User A
ltsipuserA_at_here.comgt Call-ID 4598998103413_at_4.3.2.
1 CSeq 314159 INVITE Contact ltsipUserA_at_here.com
gt Content-Type application/sdp Content-Length
142 Message Body

• Call-ID
• Identificatore unico della chiamata
• È lunione di una stringa random e del nome (o
  indirizzo) del richiedente

• Cseq (Command Sequence)
• Contiene un numero intero e il nome del metodo
• È un contatore sequenziale delle richieste
  inoltrate allinterno della chiamata

• Contact
• SIP URI che indica il modo (indirizzo IP o nome)
  per contattare direttamente il richiedente

98
Esempio di Messaggio INVITE (4/4)
INVITE sipuserB_at_there.com SIP/2.0 Via
SIP/2.0/UDP pcA.here.com5060 branchz9hG4bk776as
dhds Max-Forwards 70 To User B
ltsipuserB_at_there.comgt From User A
ltsipuserA_at_here.comgt Call-ID 4598998103413_at_4.3.2.
1 CSeq 314159 INVITE Contact ltsipUserA_at_here.com
gt Content-Type application/sdp Content-Length
142 Message Body

• Content-Type
• Descrizione the message body

• Content-Length
• Lunghezza in ottetti del message body

• Message Body
• Contiene la descrizione dei parametri di sessione
  richiesti
• Tipo di media (es. audio, video)
• Codec utilizzati
• Sampling rate
• Si utilizza il protocollo SDP

99
Esempio di Messaggio 200 OK (1/2)
SIP/2.0 200 OK Via SIP/2.0/UDP
proxyB.there.com5060 branchz9hG32k776aedfaa Via
SIP/2.0/UDP proxyA.here.com5060
branchz9hG4bk216efc66s Via SIP/2.0/UDP
pcA.here.com5060 branchz9hG4bk776asdhds Max-For
wards 70 To User B ltsipuserB_at_there.comgt From
User A ltsipuserA_at_here.comgt Call-ID
4598998103413_at_4.3.2.1 CSeq 314159
INVITE Contact ltsipUserB_at_there.comgt Content-Type
application/sdp Content-Length 131 Message
Body

• La prima linea contiene
• Codice della risposta (200)
• Una frase di illustrazione (OK)

• Gli header field Via, To, From, Call-ID e Cseq
  sono copiati dal messaggio INVITE ricevuto

• Nel campo Via sono indicati anche gli indirizzi
  dei proxy attraversati dal messaggio INVITE
• Il messaggio di risposta segue lo stesso percorso
  seguito dal messaggio INVITE

100
Esempio di Messaggio 200 OK (2/2)
SIP/2.0 200 OK Via SIP/2.0/UDP
proxyB.there.com5060 branchz9hG32k776aedfaa Via
SIP/2.0/UDP proxyA.here.com5060
branchz9hG4bk216efc66s Via SIP/2.0/UDP
pcA.here.com5060 branchz9hG4bk776asdhds Max-For
wards 70 To User B ltsipuserB_at_there.comgt From
User A ltsipuserA_at_here.comgt Call-ID
4598998103413_at_4.3.2.1 CSeq 314159
INVITE Contact ltsipUserB_at_there.comgt Content-Type
application/sdp Content-Length 131 Message
Body

• Contact
• SIP URI che indica il modo (indirizzo IP o nome)
  per contattare direttamente UserB

• Message Body
• Contiene la descrizione dei parametri di sessione
  accettati dal destinatario (UserB)
• Possono essere diversi da quelli richiesti dalla
  sorgente
• Si utilizza il protocollo SDP

101
Instaurazione di una sessione

• Sequenza di passi
• Registrazione, identificazione e localizzazione
  dellutente chiamato
• Determinazione dei media che caratterizzano la
  sessione e dei relativi parametri
• Determinazione della volontà dellutente
  chiamato a stabilire la sessione con lutente
  chiamante
• Instaurazione della sessione
• Eventuale modifica della sessione (es. call
  transfer)
• Terminazione della sessione

102
Esempio di instaurazione di una sessione
UserA
UserB
proxyA.here.com
proxyB.there.com
103
Osservazioni (1/2)

• Lindirizzo del SIP server proxyA.here.com deve
  essere configurato nel terminale dutente o può
  essere acquisito tramite DHCP.
• I proxy ricevono il messaggio di INVITE,
  individuano lhop successivo e rilanciano il
  messaggio aggiornando il campo Via
• Un proxy individua il destinatario dellhop
  successivo con una procedura di address
  resolution.
• Ogni proxy emette a ritroso un messaggio 100
  trying che indica che la procedura è in progress.
• Lindirizzo dello UserB è ottenuto dallultimo
  proxy mediante una query al location server del
  dominio a cui appartiene UserB (there.com).
• Il terminale di UserB avverte lutente finale
  dellarrivo di una chiamata e in attesa della
  risposta emette un messaggio 180 ringing che
  indica allutente chiamante che si è in attesa
  della risposta.

104
Osservazioni (2/2)

• Il percorso dei messaggi a ritroso è individuato
  dalla sequenza memorizzata nel campo Via
• Ogni proxy individua lelemento successivo e
  rimuove il proprio riferimento dal campo via.
• Quando lutente UserB risponde al segnale di
  chiamata viene emesso il messaggio 200 OK che
  indica lavvenuta risposta dellutente chiamato.
• Il messaggio 200 OK contiene i parametri della
  chiamata che lutente UserB accetta
• Negoziazione dei parametri in due fasi (offerta e
  risposta).
• La procedura si conclude con linvio da parte di
  UserA di un messaggio ACK che indica la
  conclusione positiva della fase di instaurazione
• Il messaggio ACK non è elaborato dai proxy perché
  entrambi gli utenti, mediante il campo Contact,
  hanno acquisito gli indirizzi del corrispondente.

105
Registrazione

• La procedura consente di registrare la presenza
  di un utente in un dominio e di individuare il
  suo indirizzo di rete.
• Esempio
• Registrazione della presenza dellutente
  jiri_at_iptel.org
• Associazione dellutente jiri_at_iptel.org
  allindirizzo di rete 195.37.78.173

106
Address resolution e location service
Location service
UserA
UserB
DNS Server
SIP Proxy
107
Location Service
Location Register
jiri
jiri_at_195.37.78.173
INVITE sipjiri_at_195.37.78.173 SIP/2.0 From
sipcaller_at_sip.com To sipjiri_at_iptel.org Call-ID
345678_at_sip.com
INVITE sipjiri_at_iptel.org SIP/2.0 From
sipcaller_at_sip.com To sipjiri_at_iptel.org Call-ID
345678_at_sip.com
OK 200 From sipCaller_at_sip.com To sip
jiri_at_iptel.org Call-ID 345678_at_sip.com
OK 200 From sipCaller_at_sip.com To sip
jiri_at_iptel.org Call-ID 345678_at_sip.com
Caller_at_sip.com
SIP Proxy
jiri_at_iptel.org
108
SDP

• La negoziazione dei media e dei parametri
  associati è realizzata mediante SDP (Session
  Description Protocol).
• SDP è un linguaggio testuale di descrizione.
• Il paradigma di negoziazione è di tipo
  offerta-risposta
• Lofferta è contenuta nel messaggi INVITE
• La risposta nel messaggio 200 OK
• Nellofferta uno UA dichiara per ogni media
• Tipo
• Insieme di Codec supportati
• IP address
• Port number
• Nella risposta laltro UA dichiara i media
  accettati e quelli rifiutati

109
Esempio di body SDP (offerta)

• mvideo 4004 RTP/AVP 14 26
• Media media type (video), port number, type
  (RTP/Audio Video Profile), number (profili 14 o
  26)
• artpmap14 MPA/90000
• Attributo lista attributi profilo 14 codec
  MPA sampling rate 90 kHz
• artpmap26 jbeg/90000
• Attributo lista attributi profilo 26 codec
  JBEG sampling rate 90 kHz

• maudio 4006 RTP/AVP 0 4
• Media media type (audio), port number, type
  (RTP/AVP profile), number (profili 0 o 4)
• artpmap0 PCMU/8000
• Attributo lista attributi profilo 0 codec PCM
  (µ law) sampling rate 8 kHz
• artpmap4 GSM/8000
• Attributo lista attributi profilo 4 codec GSM
  sampling rate 8 kHz

• v0
• versione corrente di SDP
• o s t
• Origine, Subject, Time (non usati da SIP)
• cIN IP4 128.3.2.1
• Connessione - Internet (IN), IP4, indirizzo

110
Esempio di body SDP (risposta)

• mvideo 0 RTP/AVP 14
• La destinazione declina lofferta del video
  (numero di porta 0)
• maudio 6002 RTP/AVP 4
• La destinazione accetta lofferta dellaudio
  (numero di porta diverso da 0 e sceglie il
  profilo 4)
• artpmap4 GSM/8000
• Attributo lista attributi profilo 4 codec GSM
  sampling rate 8 kHz

111
Modifica dei parametri di sessione

• Una delle due parti può richiedere la modifica
  dei parametri di sessione mediante linvio di un
  messaggio INVITE (RE-INVITE)
• Il nuovo messaggio di INVITE deve contenere il
  Call-ID della sessione che si vuole modificare
• La procedura di modifica segue lo stesso schema
  della procedura di instaurazione
• Una procedura di modifica non può iniziare fino a
  che non si è esaurita la fase di instaurazione o
  una richiesta di modifica precedente

112
Gestione della mobilità in SIP (1/2)

• Un utente in una rete visited si registra sul
  Foreign Proxy (FP) disponibile
• Il FP provvede ad avvertire lHome Proxy (HP)

113
Gestione della mobilità in SIP (2/2)

• LHP provvede a redirigere una chiamata entrante
  verso la rete visited

114
SIP verso Mobile IP (MIP)

• MIP è il protocollo utilizzato per le
  applicazioni mobile Internet
• Mobile-IPv4 è inefficiente a causa
  dellinstra-damento triangolare
• Mobile-IPv6 usa meccanismi simili a SIP
  registration and reinvitations per evitare il
  triangular routing
• SIP potrebbe essere la soluzione per gestire in
  modo unico la mobilità in Internet.

115
Telefonia in Internet (1/3)

• VoIP (Voice over IP) è una applicazione di
  telefonia su Internet.
• Una chiamata telefonica può essere gestita con
  limpiego di SIP.
• A titolo desempio, levoluzione di una chiamata
  con SIP è mostrata in Fig.VI.9, mentre la
  Fig.VI.10 illustra la procedura SIP per
  lidentificazione del chiamante.

116
Telefonia in Internet (2/3)
Fig.VI.9
117
Telefonia in Internet (3/3)
Fig.VI.10