Tesina di Sistemi Ipermediali - the

TESINA PER IL CORSO DI SISTEMI IPERMEDIALI
ANNO ACCADEMICO 2004/2005
Dott.sa Ombretta Gaggi
IL LINGUAGGIO SMIL
PER LA CREAZIONE DEGLI MMS
Rabbi Massimo 799761
INDICE DEL DOCUMENTO
CAPITOLO 1: Panoramica sulla tecnologia MMS .......................................................................... 3
CAPITOLO 2: Il protocollo MMS .................................................................................................. 5
CAPITOLO 3: Invio di un MMS..................................................................................................... 9
CAPITOLO 4: Struttura degli MMS ............................................................................................. 12
CAPITOLO 5: Profili SMIL per gli MMS..................................................................................... 14
CAPITOLO 6: Creare MMS d’esempio ........................................................................................ 24
CAPITOLO 7: Conclusioni finali.................................................................................................. 27
APPENDICE A ............................................................................................................................ 28
APPENDICE B............................................................................................................................. 29
APPENDICE C............................................................................................................................. 31
RIFERIMENTI E BIBLIOGRAFIA.............................................................................................. 32
2
CAPITOLO 1
Panoramica sulla tecnologia MMS
Gli mms possono essere visti come la naturale evoluzione del sistema di messaggistica SMS che
tutti siamo abituati ad utilizzare quotidianamente.
Volendo esemplificare, un mms è un messaggio multimediale che può assumere diverse forme, da
quella molto semplice di un classico messaggio testo fino ad una più complessa presentazione
composta di testo, immagini, audio e video.
Lo standard MMS, perché di standard possiamo parlare, è relativamente giovane: la prima
compagnia a lanciare il servizio in Europa è stata la norvegese Telenor nel marzo 2002.
In Italia il servizio è stato introdotto prima di tutti da Telecom Italia nel maggio 2002. Anche in
Asia (marzo 2002) e negli Usa (giugno 2002) il servizio è stato portato sul mercato nello stesso
periodo.
A partire quindi dall’inizio-metà del 2002 gli MMS hanno invaso il mercato della telefonia mobile
proponendosi subito come un grosso affare commerciale per le varie compagnie: come vedremo i
fattori che hanno portato al successo di questo tipo di messaggistica sono variegati e il suo successo
sembra essere solo all’inizio.
Tra i fattori che hanno portato (e che porteranno) al successo di questa tecnologia, possiamo
individuare i seguenti:
-
-
-
-
disponibilità sul mercato di telefoni “mms-enabled”: il target di devices degli mms è
sicuramente quello di cellulari piuttosto recenti, con schermo a colori, memoria flash interna
o addirittura espandibile, supporto gprs e wap. E’ chiaro che la diffusione della tecnologia
mms è strettamente correlata alla scelta da parte dell’utente di dispositivi di questo tipo.
Nonostante inizialmente il prezzo fosse la limitazione principale, oramai le tante promozioni
offerte dagli operatori e la comparsa sul mercato di un numero sempre crescente di modelli
di marche differenti ha portato ad un drastico abbassamento dei prezzi, rendendo di fatto
accessibile a tutti l’accesso a questa tecnologia.
interoperabilità tra devices e la rete di intercomunicazione: far funzionare dispositivi
diversi di vendor diversi è molto spesso un problema. E’ quindi necessario lo sviluppo di
standard che siano al tempo stesso “elastici e restrittivi”: l’idea è quella di stabilire un subset
di operazioni e elementi chiave che permettano di avere una solida base su cui costruire le
espansioni future, ma che al tempo stesso dia spazio all’integrazione delle tante soluzioni
proprietarie che a volte vengono scelte. Si è passati quindi da una fase iniziale in cui il
problema di interoperabilità era legato alle soluzioni adottate dai singoli MMS providers ad
una fase in cui la presenza di standard ben noti consente un dialogo tra le entità del sistema
in maniera chiara e efficiente.
facilità di utilizzo: si tratta di un aspetto molto importante. L’utente deve essere in grado di
inviare un mms in maniera semplice e veloce. Il motto “Snapshot and send!” rende bene
l’idea. L’utente deve poter ad esempio scattare una foto (con la fotocamera integrata o
accessoria) e con pochi semplici passaggi inviarla a chi vuole: non deve essere costretto a
navigare tra i tanti menu del cellulare prima di riuscire a comporre e inviare il messaggio
multimediale.
servizi multimediali dal valore aggiunto: è chiaro che la multimedialità ora disponibile su un
dispositivo che abbiamo sempre con noi per gran parte del giorno da’ la possibilità di
usufruire di servizi di informazioni e/o intrattenimento in tempo reale.
3
-
-
-
-
molteplicità di indirizzamento: come sappiamo i destinatari di un sms possono essere altri
utenti di telefonia mobile e numeri particolari corrispondenti a servizi dedicati offerti dagli
operatori. Con gli mms il range di destinari possibili viene espanso aggiungendo anche
indirizzi email: ovvero possiamo comporre un mms e inviarlo a chiunque possieda un
account di posta.
standard aperti e accettazione su larga scala: quando poco sopra parlavamo di
interoperabilità, accennavamo al fatto di come sia importante avere degli standard che
consentano di far comunicare fra loro dispositivi diversi di vendor diversi che si appoggiano
su reti di operatori differenti. Lo sviluppo dello standard MMS è stato sponsorizzato dalle
grandi compagnie di telecomunicazioni, ma il lavoro è stato portato avanti in forum di
discussione e sviluppo aperti (il WapForum1 prima e l’OMA2 poi) in maniera da consentire
un coinvolgimento globale della comunità di sviluppo.
meccanismi e protocolli di comunicazione efficienti: la tecnologia MMS si basa su protocolli
studiati prima di tutto per essere efficienti e sfruttare nel migliore dei modi la scarsa banda
di comunicazione dei canali radio (GPRS3 e in certi casi GSM4). A questo proposito per
esempio lo scambio di informazioni avviene in formato binario piuttosto che in formato
testo (come avviene invece su internet).
modalità di addebito flessibili: il costo degli mms viene calcolato a seconda della modalità
scelta dall’utente o comunque prevista dal piano telefonico stipulato con l’operatore o con il
provider del servizio multimediale.
Tipicamente le modalità di addebito previste sono tre:
 costo fisso per ogni mms inviato
 abbonamento mensile (con eventuali limitazioni sul numero dei messaggi totali)
 costo variabile legato alla dimensione e al contenuto del messaggio
Vediamo ora di dare uno sguardo a quelli che sono gli elementi che costituiscono il sistema e qual è
il funzionamento che sta alla base di questa tecnologia.
Prima di far ciò è utile comunque per il lettore consultare l’appendice A del documento onde
acquisire quelle nozioni necessarie per capire qual è la situazione attuale dal punto di vista degli
standard. La lettura dell’appendice sarà infatti utile per capire quali sono i vari enti di
standardizzazione che in un qualche modo contribuiscono o hanno contribuito allo sviluppo delle
specifiche.
Fare riferimento all’appendice A.
Acronimo per Open Mobile Alliance. Fare riferimento all’appendice A.
3
General Packet Radio Service. Standard di trasferimento dei dati per le comunicazioni wireless. La velocità di
trasmissione può arrivare fino a 115.000 bit/secondo.
4
Con l’acronimo del termine Global System Mobile si intende il popolare sistema di comunicazione mobile che viaggia
sui 900, 1800 e 1900 Mhz.
1
2
4
CAPITOLO 2
PROTOCOLLO MMS: architettura e elementi del sistema
Di seguito verrà data una doppia rappresentazione di come può essere vista un’infrastruttura di rete
tipo, che garantisce il corretto funzionamento del servizio MMS.
La prima sarà più semplice (visione WAP/OMA), mentre la seconda sarà un po’ più dettagliata
(visione 3GPP).
Figura 1: Infrastruttura della rete MMS
Le componenti fondamentali che possiamo isolare sono le seguenti:
-
-
-
MMS Client: è la componente che interagisce con l’utente. È tipicamente implementato
come un’applicazione residente sul device mobile.
MMS Proxy-Relay: è la componente che interagisce in maniera diretta con l’mms client
fornendogli accesso al servizio di messaggistica. Si occupa altresi’ di dialogare anche con
server di tipo differente. Tipicamente viene accorpato all’MMS Server.
MMS Server: è la componente che fornisce servizio di salvataggio “temporaneo” dei
messaggi. Come accennato poco sopra mms server e mms proxy-relay di solito costituisco
un’unica entità: questo è almeno quello che avviene nelle implementazioni classiche. E’ per
questo che molto spesso si sente utilizzare il termine generico MMSC ovvero MMS Center.
5
-
-
Email Server: il classico server di posta elettronica. E’ chiaro che poiché il destinatario di un
messaggio multimediale può essere specificato anche con un indirizzo email, è
indispensabile avere un server che dopo le opportune traduzioni da parte dell’MMSC faccia
pervenire correttamente la nuova email.
Legacy Wireless Messaging systems: questo elemento del sistema è rappresentato da tutti
quei meccanismi di comunicazione/messaggistica “alternativa”. Potrebbe quindi rendersi
necessaria una traduzione dell’MMS originale verso un formato differente.
Nella figura si nota chiaramente come i canali di comunicazione tra le varie componenti siano
etichettati in maniera differenti.
E’ una maniera molto semplice per nominare quelle che sono le interfacce di dialogo tra le entità
dell’infrastruttura di rete.
Abbiamo quindi rispettivamente:

MMS M : l’interfaccia tra MMS Client e MMS Proxy-Relay

MMS S : l’interfaccia tra l’MMS Proxy-Relay e l’MMS Server. Come dicevamo poco sopra
poiché spesso le due componenti sono “fuse”, non esiste una vera e propria specifica di
come questa interfaccia debba andare implementata. L’OMA infatti non dichiara in alcun
documento ufficiale linee guida da seguire.

MMS R : l’interfaccia di comunicazione tra l’MMS Proxy-Relay e eventuali altri sistemi
MMS esterni.

E : si tratta dell’interfaccia tra MMS Proxy-Relay e i server di posta. E’ chiaro per questo
tipo di comunicazione viene sfruttata l’infrastruttura internet mediante l’utilizzo di protocolli
standard come pop, smtp e imap.

L : si tratta dell’interfaccia tra MMS Proxy-Relay e i sistemi di messaggistica alternativa.
Più che di una singola, possiamo parlare di un set di interfacce che si differenziano a
secondo del sistema controparte in questione.
Quello che dovrebbe essere oramai ben chiaro è il fatto che l’architettura MMS è composta da una
molteplicità di entità in parte software e in parte hardware.
Si va dal software presente sul dispositivo dell’utente (MMS Client) e che serve per comporre,
inviare e ricevere messaggi multimediali, fino ai vari server o dispositivi della rete intermedia
necessari per l’instradamento del traffico e per eventuali conversioni/adattamenti dei contenuti
multimediali.
L’immagine che presentiamo qui sotto, è una più approfondita analisi dell’architettura.
Vengono altresì adottate le “etichette” standard utilizzate per nominare le interfacce e che sono
impiegate all’interno dei documenti ufficiali prodotti dal 3GPP. Le definizioni che abbiamo
utilizzato poco sopra sono infatti derivanti dalle convenzioni WAP/OMA (WapForum e
OpenMobileAlliance).
6
Figura 2: visione in dettaglio dell’architettura MMS
La cosa che salta subito all’occhio è la comparsa delle sigle MM X per indicare le singole interfacce
interposte tra gli elementi. Non sorprende invece vedere l’MMS Proxy-Relay in accoppiata con
l’MMS Server a formare quello che anche sopra avevamo chiamato MMS center.
Le interfacce così come appaiono nello standard sono 8:
-
-
-
MM1: è quella che prima chiamavamo MMS M , ossia quell’interfaccia dedicata al dialogo tra
MMS Client e MMS Center.
MM2: è quella che prima chiamavamo MMS S , ossia quell’interfaccia dedicata al dialogo tra
le due componenti del classico MMSC. Vista l’accoppiata stretta che formano MMS ProxyRelay e MMS Server questa interfaccia è nella stragrande maggioranza dei casi
un’implementazione di tipo proprietaria.
MM3: volendo trovare il suo equivalente nel modello precedente potremmo dire che
l’interfaccia E rientra tra quelle di tipo MM3. Tipicamente si tratta di interfacce fra l’MMSC
e server esterni, con i quali la comunicazione avviene tipicamente mediante protocolli IPbased. Tuttavia sono interfacce di tipo MM3 anche le interfacce L che avevamo visto sopra,
visto che tra i sistemi di messaggistica alternativi ci sono per l’appunto anche gli SMS ed è
piuttosto frequente un collegamento tra l’MMSC e un SMSC esterno.
7
-
-
-
-
-
MM4: è quella che prima chiamavamo MMS R , ossia l’interfaccia fra diversi MMSC. Questa
interfaccia infatti si occupa dello scambio di messaggi fra ambienti MMS eterogenei: per
esempio reti mobili di operatori differenti. Tipicamente le transazioni attraverso l’interfaccia
avvengono mediante protocollo SMTP.
MM5: si tratta di un’interfaccia che non ha una controparte nel modello precedente.
Si occupa dell’interazione tra l’MMSC e server di supporto della rete interna quali ad
esempio server DNS (Domain Name Server) o server HLR (Home Location Registration).
MM6: questa interfaccia si preoccupa dell’interazione tra MMSC e database server
contenenti informazioni sugli utenti.
MM7: questa interfaccia si preoccupa dell’interazione tra MMSC e le cosiddette VAS
Applications. VAS è un acronimo Value Added Services, come dice il nome stesso quindi si
tratta di applicazioni che non sono strettamente legate all’infrastruttura di rete dell’operatore
ma a servizi comunque multimediali basati su MMS richiesti/forniti da terzi. Esemplificando
potremmo riferirci a servizi di segnalazione meteo o notizie multimediali in tempo reale
(esempio concreto: TGCOM), oppure ancora tutti quei classici servizi a pagamento che
permettono di ricevere suonerie o loghi animati, screensaver sul proprio cellulare. Si tratta
insomma di una vasta gamma di servizi che sfruttano la multimedialità degli MMS per
rendere più accattivante l’offerta al cliente finale.
MM8: questa interfaccia è dedicata a tutte quelle comunicazioni tra MMSC e i sistemi di
addebito. Poiché infatti i vari operatori prevedono modalità di addebito dei costi flessibili, i
messaggi scambiati potranno essere molti diversi tra loro. Basti pensare che nonostante la
tipica modalità di pagamento sia quella del “costo fisso per MMS”, in certi periodi
dell’anno, particolari promozioni consentono l’invio di MMS gratuitamente e in numero
limitato. Ecco quindi che nel calcolo dei costi entrano in gioco fattori che richiedono una
flessibilità tale da consigliare l’utilizzo di server dedicati, i cosiddetti Billing System.
Per concludere questa analisi sull’architettura MMS, è da segnalare come i devices utilizzino il
protocollo WAP per dialogare con l’MMSC.
Il WAP o anche Wireless Application Project è il risultato della collaborazione tra alcuni colossi nel
mondo della telefonia quali Nokia, Motorola, Ericsson e Phone.com (ora OpenWave).
Il lavoro (cominciato nel lontano 1997) è stato portato avanti tramite il Wap Forum e ha portato alla
definizione di specifiche tecniche che consentono di usufruire dei servizi, dei contenuti e delle
applicazioni Internet attraverso differenti piattaforme wireless come GSM, GPRS, UMTS5.
In pratica i terminali wireless, se supportano il WAP (ormai giunto alla versione 2.0), possono
mediante un microbrowser dedicato accedere a pagine WML, e navigare in forma “ridotta” su
Internet.
Come vedremo nonostante sia possibile inviare MMS sfruttando la rete GSM, la classica accoppiata
che viene proposta è GPRS-WAP, questo perché le capacità di banda offerte dal GPRS sono
nettamente superiori rispetto alla classica rete GSM.
Nel caso quindi che il device in possesso dell’utente non sia sufficientemente evoluto da riuscire a
sfruttare il protocollo HTTP per dialogare direttamente con l’MMSC, tipicamente quello che
avviene è che il terminale contatta un WAP Gateway che fa da intermediario con l’MMSC.
UMTS acronimo per Universal Mobile Telecommunications Service è la terza generazione di trasmissione di testo,
voce, video, multimedia e dati a banda larga basata sulla trasmissione a pachetti. Il trasferimento dei dati avviene ad una
velocità di 2 megabits al secondo e si basa sullo standard GSM Global System for Mobile.
5
8
CAPITOLO 3
INVIO DI UN MMS: un semplice esempio
Per comprendere come effettivamente sfruttare questa tecnologia vedremo qui di seguito prima di
tutto un esempio di configurazione di un classico terminale abilitato all’invio e alla ricezione di
messaggi multimediali.
Nella fattispecie farò riferimento al cellulare Sony Ericsson T610
e all’operatore di telefonia Vodafone Omnitel.
Qui di seguito presenterò i parametri di accesso alla rete in maniera tale da poter usufruire del
servizio invio/ricezione MMS, attraverso semplici passaggi.
1. Creazione di un apposito Account Dati.
Per fare questo bisogna selezionare il menu Connettività quindi
<Comunicazione Dati>\\<Account Dati>\\<Nuovo Account>.
A questo punto ci si trova a selezionare la tipologia di invio Dati: in questo caso Dati Gprs o Dati
Gsm. Ovviamente la scelta più consigliata è quella Dati Gprs.
Fatto questo diamo un nome al nostro profilo dati, per esempio Vodafone MMS GPRS.
Alla schermata successiva ci vengono richiesti tre parametri: Nome APN, ID utente, Password.
Quello di cui ci dobbiamo preoccupare è Nome APN6: nel nostro caso poiché siamo utenti Vodafone
Omnitel il parametro da inserire sarà mms.vodafone.it.
2. Creazione di un apposito Profilo MMS.
Per fare questo bisogna selezionare il menu Connettività quindi
APN è l’acronimo per Access Point Note ovvero una sorta di default gateway che fa da ponte tra la rete wireless GPRS e la rete Internet. Ogni
operatore ha il proprio APN specifico.
6
9
<Opzioni Wap>\\<Profili Wap>\\<Nuovo Profilo>
Diamo quindi un nome a scelta ad esempio Vodafone MMS.
Ora selezioniamo in <Connetti con:> l’account dati precedentemente creato.
Come indirizzo IP inseriamo: 010.128.224.010
3. Selezione del profilo
Ora l’ultima cosa che rimane da fare è impostare il profilo appena creato dal menu Messaggi.
Entriamo in MMS\\Opzioni.
In Centro Servizi impostiamo il valore http://mms.vodafone.it/servlets/mms
Infine in Profilo Wap selezioniamo il profilo precedentemente creato.
Come abbiamo potuto vedere oltre ai classici parametri accessori e secondari (qui non specificati),
come il tempo di validità dei messaggi o il rapporto consegna, le impostazioni fondamentali sono
sostanzialmente tre:
1. indirizzo del centro servizi: tipicamente nella forma http://mmsc.operator.com e nel nostro
caso http://mms.vodafone.it/servlets/mms
2. il profilo wap: con tutte le impostazioni per accedere al Wap Gateway
3. la tipologia di accesso alla rete: come abbiamo potuto vedere le possibilità proposte erano
GPRS e CSD7. Di default gli operatori consigliano l’uso di GPRS per la comunicazione
visto la maggiore banda disponibile e i tempi di latenza più bassi.
CSD è l’acronimo per Circuit Switched Data, in pratica è la tecnologia di trasmissione dati su normale rete GSM. Una
sua naturale evoluzione è rappresentata da HSCSD.
7
10
In questa breve sezione vedremo invece cosa “realmente voglia dire inviare un mms”.
Non verrà fatta un’analisi dettagliata di tutte le singole fasi onde evitare di scendere troppo nel
dettaglio, ma daremo una visione d’insieme dei singoli passi che tipicamente vengono seguiti
quando inviamo un mms.
Figura 3: Invio di un MMS
- Tabella 1: TABELLA DEI PASSAGGI A: L’originator mms client invia il messaggio multimediale
1)Il messaggio viene indirizzato al destinatario.
2)Il device stabilisce una connessione WAP (via GPRS/CSD) con l’MMS
e invia il contenuto del messaggio come contenuto di un WSP POST
request.
3)L’MMSC accetta il messaggio e risponde all’originator client attraverso
la connessione WAP già aperta (WSP POST response).
All’utente sullo schermo del device compare quindi la scritta
“Messaggio inviato”.
B: L’MMSC informa il recipient mms client
4)Mediante un WAP PUSH l’MMSC tenta di comunicare al destinatario
che c’è un nuovo messaggio.
C: Il ricevente recupera l’MMS
5)Posto che il device sia in grado di ricevere MMS, viene iniziata una
connessione WAP (via GPRS/CSD). Viene utilizzata una WSP GET
request per recuperare il messaggio multimediale dall’MMSC.
6)L’MMS viene inviato al destinatario come contenuto di una WSP GET
response.
All’utente sullo schermo del device compare quindi la scritta
“Messaggio ricevuto”.
7)Il terminale dell’utente infine invia un acknowledgment di avvenuta
ricezione con un messaggio WSP POST prima che la connessione venga
chiusa.
D: L’MMSC informa il mittente dell’avvenuta consegna (opzionale)
8)L’MMSC utilizza una WAP PUSH per indicare al mittente che il
messaggio è stato correttamente inviato.Quest’ultimo passaggio dipende
dalle impostazioni del terminale ovvero se è o meno abilitato il report di
ricezione.
11
CAPITOLO 4
STRUTTURA MMS: il formato dei messaggi
La struttura scelta dai progettisti per il formato interno dei messaggi mms è molto simile alla
struttura dei messaggi di posta elettronica.
Questa similarità è dovuta al fatto che così come le email, anche gli mms sono messaggi
multicontenuto che al loro interno possono avere testo, immagini, video, suoni e altri oggetti
multimediali.
Ogni mms include al suo interno una cosiddetta “scene description”, ovvero una descrizione di
quella che dovrà essere la “presentazione” del messaggio sul device dell’utente.
Le scene description, come vedremo nel capitolo successivo vengono codificate col linguaggio
SMIL. Questo linguaggio a tag derivato dall’XML come sappiamo è utilizzato per l’integrazione di
differenti media e la loro sincronizzazione, in maniera da ottenere presentazioni o più in generale
animazioni con contenuti multimediali.
Gli mms hanno il seguente formato: la prima parte è costituita da una sezione headers in cui sono
contenute tutte le informazioni fondamentali quali mittente (campo From), destinatario (campi To,
Cc, Bcc), priorità del messaggio, periodo di validità e tutti gli altri campi accessori (in maniera
speculare a quello che accade per le email).
Tipicamente i campi sono contrassegnati dal prefisso X-MMS.
La seconda parte è costituita dal contenuto vero e proprio del messaggio suddiviso in più parti
separate da opportuni delimitatori.
Ogni componente del corpo del messaggio è composta a sua volta da un header che indica la
tipologia di informazioni contenute (immagine/testo/audio etc. etc.) e poi dal contenuto vero e
proprio.
Un campo molto importante dell’header è Content-Type che indica come il corpo del messaggio
multimediale è organizzato.
12
I valori consentiti sono:
- Multipart/Mixed o application/vnd.wap.multipart.mixed: formato tipicamente adottato in
mancanza di contenuti multimediali veri e propri, ovvero quando manca una scene description.
- Multipart/Alternative o application/vnd.wap.multipart.alternative: si tratta di un formato utilizzato
raramente visto che comunque prevede che sia lasciato al dispositivo come rappresentare i contenuti
delle body parts.
- Multipart/Related o application/vnd.wap.multipart.related: è il formato più diffuso visto che
prevede la possibilità di aggregazione di più body parts in un’unica struttura. Di solito viene
utilizzato un parametro Start per indicare l’inizio di una scene description, che come accennato
viene rappresentata tramite il linguaggio SMIL.
13
CAPITOLO 5
PROFILI SMIL PER GLI MMS: MMS SMIL e 3GPP SMIL
Sopra abbiamo anticipato a come il linguaggio SMIL sia utilizzato per la descrizione della
presentazione dei contenuti multimediali sullo schermo dell’utente.
E’ chiaro che poiché potenza di calcolo e memoria disponibili sui cellulari non consentono di
sfruttare appieno tutte le caratteristiche di questo linguaggio, per realizzare la presentazione degli
MMS dovremmo limitarci ad utilizzare un subset di tag appartenenti al linguaggio.
Il linguaggio SMIL onde garantire la compatibilità e il supporto con player e browser differenti
prevede l’utilizzo dei cosiddetti “Smil Profiles”.
In particolare il profilo SMIL che a noi interessa è lo SMIL 2.0 Basic Language Profile che viene
tipicamente adottato sui PDA.
Tuttavia questo sottoinsieme di tag è ancora troppo esteso per essere completamente supportato dai
telefoni cellulari MMS- based: le risorse disponibili su questi devices sono infatti inferiori rispetto a
quelle disponibili sui PDA.
Ecco quindi che si è reso necessario elaborare un nuovo profilo che fosse adattato ad essere
supportato dai telefonini.
Questo nuovo profilo ha preso il nome di MMS SMIL profile e la sua standardizzazione è stata
portata avanti ed è tuttora curata da parte dell’OMA.
Tuttavia il fatto che questo insieme di tag fosse troppo limitato, ho convinto il consorzio 3GPP a
portare avanti il progetto di sviluppo di un profilo più sofisticato che viene identificato nei papers
ufficiali come 3GPP SMIL Profile.
L’MMS SMIL Profile è stato il primo ad essere introdotto e per questo motivo, svolgerà il ruolo di
“profilo di passaggio” nell’immediato futuro, visto che l’idea degli operatori e dei vari enti di
standardizzazione è quello di passare quanto prima ad un supporto completo del 3GPP SMIL
Profile.
E’ da notare come questo profilo sia al contrario un insieme allargato di tag, rispetto al profilo usato
per i PDA, è quindi chiaro che ora come ora, i dispositivi sul mercato in grado di supportarlo sono
veramente pochi.
L’idea è che comunque il profilo 3GPP diventi il futuro profilo standard per gli MMS.
Attualmente quindi possiamo dire che la maggioranza dei devices supporta il profilo base, più
eventuali aggiunte dipendenti dai differenti modelli e produttori.
Rivediamo brevemente qual è la struttura base di un documento SMIL.
<smil>
<head>
<layout>
</layout>
</head>
<body>
</smil>
</body>
<!-- informazioni sul contenuto -->
<!-- definizione delle regioni -->
<!-- sincronizzazione degli elementi della presentazione-->
14
L’idea che sta alla base delle presentazioni SMIL è la possibilità di definire delle regioni in cui
inserire dei contenuti che possono poi essere mostrati in parallelo o in sequenza, sui quali possono
essere definiti anche particolari effetti di fade-in e fade-out o altri tipi di transizioni.
Come vedremo una delle principali limitazioni del profilo SMIL per gli MMS sarà quello di non
poter definire più di due regioni all’interno del nostro layout: già da questo si intuisce come la
classe di presentazioni multimediali ottenibili sia piuttosto elementare.
Chiunque abbia mai aperto un MMS avrà potuto notare come in realtà non sia altro che una
sequenza di slides nelle quali viene appositamente posizionato il contenuto.
Le regioni che possono essere definite sono al massimo due: una regione testo (Text) e una regione
contenente un’immagine/video8 (Image). Ad ogni pagina/slide poi può venire associata un solo clip
audio, che può essere presente sottoforma di file AMR o MIDI, quindi come media indipendente
oppure incapsulato all’interno di un video-clip e quindi in formato 3GP.
Proprio per questo motivo lo standard impedisce la possibilità di includere nella medesima slide un
clip audio e un clip video.
Analogo discorso si può fare per quel che riguarda la regione Image: possiamo avere all’interno
della stessa slide o un’immagine o un video, ma non entrambi.
Quando utilizziamo entrambe le regioni (Text e Image) possiamo definire naturalmente due
tipologie di layout, ovvero decidere come le due regioni sia organizzate: orizzontalmente o
verticalmente.
Ecco quindi che i possibili layout sono i seguenti:
a)
c)
T
E
X
T
IMAGE
o
VIDEO
IMAGE
o
VIDEO
TEXT
b)
d)
IMAGE
o
VIDEO
T
E
X
T
TEXT
IMAGE
o
VIDEO
Può accadere che qualcuno di questi layout possa non essere adatto alla visualizzazione sul device
target, ecco quindi che il dispositivo si preoccupa di “sovrascrivere” il layout con uno proprio di
default, generalmente convertendo la disposizione orizzontale degli elementi in una disposizione
verticale o viceversa.
8
I video-clip non sono previsti dal normale standard OMA, ma sono previsti invece dallo standard 3GPP. Tuttavia
molti devices di ultima generazione sono in grado pur supportando per intero le specifiche OMA dell’MMS SMIL
Profile di aggiungere alcune funzionalità proprietarie tra cui il supporto appunto per video-clip.
15
Come sappiamo un file SMIL può contenere informazioni riguardanti la temporizzazione degli
elementi da visualizzare. Ecco quindi che le slide possono essere mostrate in sequenza, in maniera
automatica rispettando i parametri specificati.
Tuttavia il dispositivo consente di bypassare queste impostazioni semplicemente mediante l’utilizzo
di un apposito tasto (tipicamente le frecce direzionali): in questa maniera l’utente può saltare da una
slide/pagina all’altra senza necessità di attendere l’intera esecuzione dello slideshow.
Il tag utilizzato per la temporizzazione è <par> e come sappiamo il suo scopo è la riproduzione
parallela di più oggetti, non ritroviamo infatti i tag <seq> e <excl> presenti invece nel profilo
SMIL 2.0.
Lo standard OMA impone alcuni importanti regole che dovrebbero andare rispettate nella fase di
realizzazione del codice SMIL:
- le dimensioni delle regioni all’interno della root region dovrebbero essere espresse in
termini assoluti, ovvero come pixel o in termini relativi sotto forma percentuale rispetto alla
root region stessa. E’ altamente sconsigliato mescolare le due soluzioni
- l’attributo src deve riferirsi ad un media compatibile rispetto all’elemento specificato:
ovvero se ho utilizzato il tag <img> il valore di src deve essere una immagine valida e non
per esempio un audio clip
- le informazioni temporali vengono espresse unicamente in millisecondi
- la dimensione massima affinché un corretto livello di interoperabilità sia assicurato è di
160x120 pixel. Terminali più evoluti possono supportare una risoluzione fino a 640x480.
Vediamo un esempio di codice di un ipotetico MMS e analizziamolo brevemente.
<smil>
<head>
<meta name="title" content="ESEMPIO DI MMS"/>
<meta name="author" content="Massimo Rabbi"/>
<layout>
<root-layout width="128" height="128"/>
<region id="Image" width="128" height="72" left="0"
top="0"/>
<region id="Text" width="128" height="56" left="0"
top="72"/>
</layout>
</head>
<body>
<par dur="3000ms"><!—Prima slide -->
<img src="Image1.jpg" region="Image"/>
<text src="Text1.txt" region="Text"/>
<audio src="Sound1.amr" />
</par>
<par dur="8000ms"><!-- Seconda slide -->
<img src ="Image2.jpg" region="Image"/>
<text src ="Text2.txt" region="Text"/>
</par>
</body>
</smil>
16
La presentazione SMIL è naturalmente definita all’interno dei tag <smil>…</smil> ed è composta
al solito secondo lo schema visto a inizio capitolo da un header e dal corpo vero e proprio.
L’header di presentazione è delimitato dai tag <head>…</head> e contiene oltre alle informazioni
sul titolo e sull’autore anche il layout della presentazione.
Il layout della presentazione è definito all’interno dei tag <layout>…</layout>. Nel nostro caso la
presentazione multimediale è composta da due regioni organizzate in maniera verticale.
La region Image che occupa la parte superiore e la region Text che occupa la parte inferiore.
Che si tratti di un’organizzazione verticale degli elementi lo capiamo dagli attributi left e top dei tag
<region>. In effetti la region Image ha attributi left=0 e top=0, mentre la region Text ha attributi
left=0 e top=72.
I tag <body>…</body> contengono la definizione di ogni slide.
Le slide sono definite mediante l’uso dei tag <par>…</par> i quali specificano anche le
impostazioni di temporizzazione (per quanto una slide deve essere visualizzata).
Abbiamo poi i tag <img>, <text> e <audio> che indicano gli elementi multimediali da posizionare
all’interno della slide.
Approfondiamo ora alcune caratteristiche riguardanti la scene description del nostro mms.
 come sappiamo SMIL è un linguaggio derivato da XML, ecco perché in alcuni casi può
essere utile specificare il namespace per la scene description. Per fare questo è sufficiente
inserire l’apposito attributo xmlns=“…” all’interno del tag <smil>.
Tipicamente il namespace scelto è uno tra i seguenti:
 <smil xmlns = “http://www.w3.org/2000/SMIL20/CR/Language”>
 <smil xmlns = “http://www.w3.org/2001/SMIL20/Language”>
Se da un lato il namespace è utile affinché il linguaggio sia correttamente interpretato dal
parser SMIL, dall’altro a volte la sua presenza viene ignorata laddove il client MMS non sia
così evoluto. In questo caso è come avere un semplice <smil>. Questo vuol dire che il
parser assumerà che la scene description rispetti le regole definite in SMIL 1.0.
 poiché la scene description è incapsulata all’interno del message body, sono necessari
particolari meccanismi per far riferimento alle risorse multimediali che si intende
visualizzare sul device target.
Ecco quindi che sono previste due tipi di identificatori per gli oggetti:
 Content-Id: il metodo più immediato per far riferimento ad una particolare body part
e quindi ad un particolare elemento è il content-identifier ovvero un identificatore
univoco per una body part del messaggio.
Questa tipologia di riferimento viene impiegata in questa maniera all’interno del
codice SMIL: <img src = “cid:body_part_006” region = “Image”>
 Content-Location: si tratta dell’altra tipologia di linking dei contenuti. A differenza
di sopra in questo caso si fa riferimento all’attributo Content-Location della
particolare body-part.
Nel codice SMIL il suo utilizzo è il seguente:
<img src = “Immagine1.jpg” region = “Image”>
E’ da notare che il valore di Content-Location, viene utilizzato come filename di
default nel caso l’utente desideri salvare nella memoria interna del proprio
dispositivo il contenuto in questione (sia esso immagine o file audio o altro).
Ciò che abbiamo visto finora non è altro che il cosiddetto MMS SMIL Profile, il profilo che come
dicevamo è stato curato ed è curato tuttora dall’Open Mobile Alliance.
17
Nella seguente tabella cercheremo di riassumere quali sono i tag previsti, in base a quanto visto
finora per il profilo MMS SMIL.
Tabella 2: Attributi di riferimento per MMS SMIL profile
Elementi/Tag
Attributi
STRUTTURA BASE DEL DOCUMENTO
smil
Xmlns
head
body
META INFORMATIONS
meta
name, content
LAYOUT
layout
region
left, top, height, width, fit, id
root-layout
width, height
ELEMENTI MULTIMEDIALI
text
src, region, alt, begin, end
img
src, region, alt, begin, end
audio
src, alt, begin, end
ref
src, region, alt, begin, end
TEMPO
par
Dur
Vediamo ora quali sono i formati supportati negli mms secondo lo standard OMA.
Immagini:
- base line JPEG
- GIF87a
- GIF89a
- WBMP
Testo:
- codifica UTF-8
- codifica US-ASCII
- codifica UTF-16
Audio:
- AMR
- MIDI
Pim:
- vCalendar9 version 1.0 (mime-type: text/x-vCalendar)
- vCard10 version 2.1 (mime-type: text/x-vCard)
9
Si tratta di un formato platform-indipendent riguardante lo scambio di informazioni su eventi, appuntamenti, progetti
pianificati a particolari scadenze. E’ il formato che sta alla base delle agende appuntamenti che ritroviamo in tanti
devices come cellulari e PDA (ma non solo). Per maggiori informazioni: http://www.imc.org/pdi/vcaloverview.html
10
Si tratta di un analogo a vCalendar solamente che questa volta il formato riguarda informazioni personali su persone,
come per esempio numero di telefono, fax, email, indirizzo.
Per maggiori informazioni: http://www.imc.org/pdi/vcardoverview.html
18
Ora che abbiamo visto il profilo MMS SMIL possiamo focalizzarci sul profilo 3GPP SMIL che
come accennavamo alcune pagine fa, diventerà ben presto il profilo di default su tutti i nuovi
cellulari di prossima generazione.
A differenza del profilo già analizzato questo porta in sé numerose novità, il più delle quali
derivanti dal fatto che non abbiamo più a che fare con un sottoinsieme dello Smil 2.0 Basic
Language Profile ma bensì con un superinsieme di regole e elementi previsti per questo profilo.
Cerchiamo di analizzare e vedere da vicino cosa c’è quindi di nuovo.
1. Presentation Layout:
 nel nuovo profilo c’è la possibilità di definire il colore di background per una
generica regione. Ecco quindi che viene aggiunto l’attributo backgroundColor per
l’elemento <region>.
Il seguente è un esempio di come può essere scritto il “nuovo” codice per una
generica regione:
<regioni id = “regionA” height = “10” top = “10” backgroundColor = “blue”>

c’è la possibilità di effettuare l’overlapping delle regioni mediante l’utilizzo
dell’attributo z-index. Una regione può essere quindi portata in primo o secondo
piano rispetto ad un’altra semplicemente sfruttando questa nuova funzionalità.

aggiunta la possibilità di usare l’attributo fit. Spesso può succedere che le dimensioni
del media non corrispondano esattamente a quelle della regione nella quale dovrebbe
essere posizionato. Mediante l’uso di questo attributo è possibile gestire situazioni di
questo tipo.
I valori possibili sono:
- hidden: si tratta del valore di default. In pratica scegliendo questa soluzione il
media viene automaticamente tagliato nelle sue parti che non rientrano
nella regione corrispondente.
- meet: è tipicamente la scelta più consigliata per le immagini. Questa soluzione
infatti fa in maniera che il media venga scalato in orizzontale e verticale
(qualora fosse necessario) onde garantire il suo completo e corretto
posizionamento all’interno della regione.
La scelta di questo valore fa in modo di non alterare in alcun modo le
proporzioni del media in questione, facendolo risultare interamente visibile
- slice: come sopra anche questo attributo fa in modo di non alterare le proporzioni
del media, tuttavia lo scopo in questo caso è coprire in maniera totale la
region interessata. Le eventuali parti di media (tipicamente immagini) che
non rientrano nella region vengono ancora una volta “tagliate fuori”.
- fill: questa soluzione se da un lato come sopra fa in modo di coprire tutta la region,
dall’altro fa in modo che le proporzioni non siano rispettate, ed ecco quindi che
il media può apparire piuttosto differente dall’originale, assumendo
quindi una forma più schiacciata o allungata a seconda dei casi.
- scroll: il suo uso è strettamente consigliato col testo visto che fa in modo di
posizionare il media all’interno della region e di aggiungere una barra di
scorrimento verticale accanto alla region qualora il contenuto non sia
perfettamente contenuto dentro gli spazi prestabiliti. Lo scrolling della
region è controllato mediante le frecce presenti sul dispositivo o un
eventuale joystick.
19

backgroundColor anche per il <root-layout>: di default la regione di background è
considerata trasparente. Mediante l’uso di questo attributo invece è possibile
assegnare alla regione principale un colore particolare tra i seguenti:
Tabella 3: colori validi per l’attributo backgroundColor
Il colore di background prescelto ricopre l’intera area e resta visibile a meno che
durante la presentazione qualche media non copra la regione.
L’uso del particolare attributo showBackground = “whenActive” fa in modo che lo
sfondo scompaia quando non è presente alcun tipo di media all’interno della regione.
2. Elementi di temporizzazione:

aggiunta dell’elemento <seq>…</seq>: in questa maniera è possibile riprodurre in
sequenza gli elementi che sono contenuti all’interno di questi tag.
Sparisce in questo modo la semplice limitazione al solo tag <par> che avevamo nel
profilo MMS SMIL semplice.

il tag <body> diventa un esso stesso un contenitore a temporizzazione sequenziale.
In mancanza infatti di elementi indicanti la temporizzazione da implementare il
parser SMIL si comporta come se i media fossero contenuti tra i tag <seq>…</seq>

possibilità di annidare in maniera libera i tag di temporizzazione: una più ampia
libertà di composizione dell’mms viene lasciata all’utente facendo in modo che
possano essere specificate temporizzazioni anche piuttosto sofisticate.
Nell’esempio seguente abbiamo un messaggio multimediale in cui lo slideshow
viene mostrato con una musica di sottofondo che resta sempre la stessa.
20
<body>
<par>
</par>
</body>

<audio src="background_music.wav"/>
<seq>
<par dur="5s">
<img src="slide1.gif" . . . />
<text src="slide1.txt" . . . />
</par>
<par dur="5s">
<img src="slide2.gif" . . . />
<text src="slide2.txt" . . . />
</par>
<par dur="5s">
<img src="slide3.gif" . . . />
<text src="slide3.txt" . . . />
</par>
</seq>
nuovi valori temporali: è ora possibile definire in maniere differenti il valore
dell’attributo dur. Avevamo visto come nel profilo MMS SMIL il tempo fosse
esprimibile unicamente in millisecondi.
Esempi di formati consentiti:
Tabella 4: Esempi di valori temporali ammessi

Esempio
Descrizione
“20ms”
“20s” o “20”
“0.1s”
“5min”
“2h”
“04:20”
“1:15:30”
“indefinite”
20 millisecondi
20 secondi
100 millisecondi
5 minuti
2 ore
4 minuti e 20 secondi
1 ora, 15 minuti e 30 secondi
Valore speciale che indica una durata infinita.
uso dell’attributo endsync: questo attributo (che appartiene alle specifiche SMIL 1.0)
permette di regolare la terminazione di un gruppo di oggetti all’interno di un timecontainer.
I possibili valori per endsync sono:
- “last”: termina l’esecuzione del time-container solamente dopo che tutti
gli elementi contenuti (con tempo valido specificato) sono terminati
- “first”: termina l’esecuzione del time-container alla terminazione del
primo elemento
- “all”: termina l’esecuzione del time-container quando tutti gli elementi
sono terminati
- “id(element)”: termina l’esecuzione del time-container quando l’elemento
specificato ha terminato la sua esecuzione
21

uso dell’attributo fill: questo attributo permette di controllare il comportamento
dell’oggetto una volta terminata la sua riproduzione.
I possibili valori per l’attributo sono i seguenti:
- “remove”: il media una volta terminato scompare
- “freeze”: elementi inseriti all’interno dei tag <par>…</par>
scompaiono unicamente alla chiusura del blocco <par>. Per elementi
invece inseriti all’interno del blocco <seq>, un elemento scompare
quando l’elemento successivo inizia.
- “hold”: l’elemento scompare unicamente alla terminazione del timecontainer.
- “transition”: l’elemento rimane visualizzato fino alla terminazione della
transizione.

possibilità di far ripetere i time-container e gli elementi all’interno di essi: questa
funzionalità è controllata tramite gli attributi repeatDur e repeatCount.
Il primo specifica la durata temporale per cui deve protrarsi la ripetizione (vedi
valori in tabella 4), mentre il secondo specifica quante volte un elemento debba
essere ripetuto.
3. Effetti di transizione: l’aggiunta degli effetti di transizione attuabili sugli elementi
rappresenta sicuramente un passo importante. In questa maniera si aggiunge molta più
dinamicità ai contenuti del messaggio multimediale, rendendo la presentazione più
accattivante e quindi più interessante agli occhi dell’utente finale.
Gli elementi di tipo <transition> vengono definiti all’interno dei tag <head>…</head>.
Gli attributi sono type e subtype indispensabili per indicare la tipologia di effetto che si
desidera realizzare; dur indica la durata dell’effetto; id è necessario per assegnare un
identificatore alla particolare transizione in maniera che poi questa possa essere sfruttata
dagli elementi all’interno di <body>.
Le transizioni è bene ricordarlo non hanno in alcun modo effetto sui tempi di presentazione,
ovvero non modificano i tempi della normale visualizzazione degli elementi.
Gli attributi transIn e transOut utilizzati da <img> sono indispensabili per indicare se
l’effetto di transizione è desiderato in fase di “entrata” o caricamento dell’immagine o in
fase di chiusura della stessa. Il valore di questi attributi è chiaramente l’id di una delle
transizioni precedentemente definite nella sezione <head>.
Le transizioni supportate sono le più comunemente utilizzate, come BarWipe, ClockWipe,
Fade, PushWipe,SlideWipe,TriangleWipe e così via.
E’ naturale che il supporto delle differenti tipologie di transizioni influisce decisamente sulle
prestazioni del device: è buona norma quindi qualora si decida di farne uso di limitarne
l’impiego solamente allo stretto necessario onde evitare di incorrere in problemi e ritardi di
caricamento/visualizzazione.
22
Analogamente a quanto avevamo fatto per il profilo MMS SMIL diamo uno sguardo a quelli che
sono i tipi di media supportati dal profilo 3GPP SMIL.
Immagini:
- BMP (.bmp)
- GIF (.gif)
- JPG (.jpeg, .jpg)
- Multi Bitmap (.mbm)
- PNG (.png)
- WBMP (.wbmp)
Audio:
- AMR (.amr)
- AU (.au)
- MIDI (.mid)
- WAV (.wav)
Video:
- H.263 (.3gp)
- MPEG4 Visual Simple Profile 0 (.3gp)
23
CAPITOLO 6
COME CREARE ESEMPI DI MMS
Per poter testare sul proprio pc come effettivamente SMIL consente di realizzare gli MMS, la scelta
migliore è quella di optare per i tools e vari sdk reperibili gratuitamente (previa iscrizione) sul sito
internet http://forum.nokia.com.
Per effettuare alcune prove personali, ho fatto uso nello specifico dei seguenti tools:
- Nokia Developer’s Suite for MMS 1.1
- Nokia Mobile Internet Toolkit 4.1
- 3510i Content Authoring SDK
- 7210 Content Authoring SDK
- Series 60 Content Authoring SDK 2.0 for Symbian OS
Il primo tool è fondamentalmente un programma per la gestione dei differenti sdk installati nel
sistema (ad esempio gli ultimi tre in elenco), che permette di simulare l’invio verso gli emulatori di
MMS opportunamente caricati e precedentemente creati.
Figura 4: Schermata principale dell’ NDS 1.1
24
Il programma consente anche di creare in maniera molto basica un file .mms partendo da un file
smil precedentemente creato, ma in realtà è molto più comodo utilizzare il Nokia Internet Mobile
Toolkit.
Questo tool infatti offre funzionalità decisamente comode per la realizzazione semplice e veloce di
mms, oltre a fornire informazioni dettagliate su eventuali file mms caricati.
Come si può osservare dallo screenshot sottostante il tool consente la visualizzazione di tutti i
dettagli di un mms: si va dai file che costituiscono le body parts del document body, fino ai vari
campi presenti negli headers.
Figura 5: Schermata principale del NMIT 4.1. Un snapshot di un semplice mms.
L’altra funzionalità a cui accennavamo è quella di creazione guidata degli mms che consente una
volta raggruppati i file necessari per la presentazione SMIL di creare il messaggio multimediale
impostandone i vari campi negli header ottenendo così un vero messaggio funzionante.
Questi esempi una volta creati possono essere inviati verso gli emulatori di cellulari mediante il tool
visto in precedenza.
25
Dovendo spendere due parole sugli emulatori di terminale potremmo dire che il migliore di tutti
risulta essere il simulatore per Symbian OS.
In base a quanto riportato nelle specifiche infatti è l’unico in grado di supportare il nuovo profilo
3GPP SMIL già visto nel capitolo precedente.
Gli altri emulatori soffrono infatti delle limitazioni derivanti dall’adozione dello SMIL Profile e
cosa non da poco dal display relativamente piccolo che non consente di visualizzare in maniera
soddisfacente in un’unica schermata del display un immagine e un testo.
Ciò tipicamente accade anche con i normali messaggi mms che vengono ricevuti su numerosi
terminali mobili attualmente in commercio.
Una cosa analoga succede ad esempio col Sony Ericsson T610 del quale abbiamo visto la fase di
configurazione dei parametri WAP/MMS.
In questo cellulare infatti si deve ricorrere il più delle volte all’uso del joystick per scorrere tra
l’immagine e testo presenti nella stessa slide.
Ecco quindi che l’esempio 11 che verrà presentato di seguito è pensato appositamente per
l’emulatore Symbian Os in modo da ottenere i risultati migliori.
<?xml version="1.0"?>
<smil xmlns="http://www.w3.org/2001/SMIL20/Language">
<head>
<meta name="title" content="ESEMPIO DI MMS"/>
<meta name="author" content="Massimo Rabbi"/>
<transition id="tr_star" type="starWipe" subtype="fivePoint" dur="3s" />
<transition id="tr_slide1" type="slideWipe" subtype="fromLeft" dur="3s" />
<transition id="tr_slide2" type="slideWipe" subtype="fromRight" dur="3s" />
<layout>
<root-layout width="176" height="208" />
<region id="Image" width="128" height="127" top="0" left="20"/>
<region id="Text" width="150" height="70" top="128" left="20"/>
</layout>
</head>
<body>
<seq>
<img src="intro.jpg" dur="5s" transIn="tr_slide1" region="Image" fill="hold"/>
<text src="sparatutto.txt" dur="5s" transIn="tr_slide2" region="Text" />
<par dur="5000ms">
<img src="halflife.jpg" region="Image" />
<text src="halflife.txt" region="Text" />
</par>
<par dur="5000ms">
<img src="doom3.jpg" region="Image" />
<text src="doom3.txt" region="Text" />
</par>
<par dur="5000ms">
<img src="halo.jpg" region="Image" />
<text src="halo.txt" region="Text" />
</par>
<img src="theend.gif" dur="4s" transOut="tr_star" region="Image" fit="fill"/>
<text src="autore.txt" dur="indefinite" region="Text" />
</seq>
</body>
</smil>
11
Per una migliore comprensione dell’esempio si veda la file compresso allegato alla tesina, contenente tutto il
necessario.
26
CAPITOLO 7
Conclusioni finali
In questo ampio lavoro di analisi del protocollo MMS e di come il linguaggio SMIL si integri in
esso attraverso i vari profili, si è potuto vedere come il lavoro che i vari forum e enti di
standardizzazione stanno portando avanti sia in continua crescita.
Come si è più volte detto, l’iniziale profilo SMIL per gli MMS sta ormai piuttosto “stretto” a molti
device in commercio tanto che alcuni già adottano con successo il nuovo profilo 3GPP SMIL
progettato appositamente per rendere ancora più multimediali e godibili le presentazioni degli mms
sul proprio cellulare.
La presenza di un mercato variegato di dispositivi e produttori che spesso implementano soluzioni
proprietarie a volte porta a leggere incompatibilità. Non di rado infatti capita che non sia possibile
visualizzare particolari mms inviati da un cellulare di ultima generazione verso uno dei primi
dispositivi mms-enabled.
Le problematiche di interoperabilità sono per lo più inesistenti se ci si attiene allo standard OMA
MMS SMIL Profile. E’ vero altresì che come abbiamo fatto notare più volte la capacità di
presentazione è però ridotta all’uso di un numero ristretto di tag.
Il fatto che i lavori di standardizzazione siano ora passati in mano al 3GPP ente che lavora molto
per lo sviluppo delle reti di terza generazione, fa capire come ci sia la seria intenzione di proseguire
sul sentiero tracciato di un supporto sempre più ampio al linguaggio SMIL. Sicuramente il lavoro
sui profili degli MMS proseguirà di pari passo con i lavori sul linguaggio SMIL stesso.
Avendo a disposizione infatti devices sempre più potenti, il supporto a funzionalità avanzate del
linguaggio SMIL sarà sicuramente un aspetto da considerare.
Resta da vedere se non riusciranno ad uscire allo scoperto standard come WML e XHTML nel
campo delle presentazioni degli MMS.
Queste soluzioni seppure poche diffuse vengono adottate con successo da alcuni dispositivi, in
implementazioni però proprietarie.
Bisognerà vedere se questi standard anch’essi aperti potranno in qualche maniera scalzare SMIL dal
ruolo di protagonista che ora ha nella realizzazione degli MMS.
La cosa sembra alquanto improbabile visto che i vari enti di standardizzazione si sono focalizzati su
questo linguaggio e sembrano non aver preso in molta considerazione altre soluzioni alternative.
Quel che è certo è che nei prossimi anni uno dei fattori trainanti della tecnologia MMS saranno le
potenzialità tutte da scoprire dei dispositivi che verranno, e che permetteranno di implementare
presentazioni sempre più complesse e elaborate.
27
APPENDICE A
Gli standard nel mondo MMS
E’ chiaro che in un contesto così variegato come quello degli MMS gli standard sono necessari e
importanti per garantire la possibilità di interoperabilità tra devices e elementi di rete altamente
variegati tra loro.
Quando si è deciso di creare “uno standard per gli mms” non si è partiti da zero, anzi si è cercato di
sfruttare il più possibile tecnologie e soluzioni già ampiamente testate e collaudate, onde disporre in
breve di una tecnologia performante e competitiva che avesse solide basi.
Cercheremo ora di individuare quelli che sono stati gli enti principali che in un qualche modo hanno
contribuito o contribuiscono al processo di standardizzazione:
-
-
-
-
-
-
Third Generation Partnership Project (3GPP): non si tratta di un ente di standardizzazione
vero e proprio ma più semplicemente di un’associazione tra diversi enti di standardizzazione
regionali appartenenti a paesi come Europa, Nord America, Corea, Giappone e Cina.
L’obbiettivo primario del 3GPP è lo sviluppo di specifiche per la tecnologia UMTS, tuttavia
essa mantiene anche le specifiche GSM e quelle relative a tecnologie successive come per
esempio GPRS.
Il 3GPP è fortemente coinvolto nello sviluppo degli standard per gli MMS: rilascia papers e
articoli tecnici contenenti specifiche per i formati, i codecs, l’architettura generale di sistema
e caratteristiche tecniche di vario genere.
Third Generation Partnership Project 2 (3GPP2): anche se la sigla può richiamare quella
vista poco sopra, questa associazione svolge una attività diversa.
Essa infatti si occupa delle reti di terza generazione con un focus particolare su CDMA e
CDMA2000. Tra gli scopi del progetto c’è quindi quello della realizzazione di servizi e
interfacce per gli MMS, alternative a quelle tipicamente previste dagli standard OMA e
3GPP.
WAP Forum: si tratta di un progetto nato per la creazione delle specifiche riguardanti lo
stack di protocolli WAP (Wireless Application Project). L’idea base era come dice il nome
stesso la creazione di un framework che permettesse lo sviluppo di applicazioni in grado di
essere eseguite su differenti piattaforme wireless.
E’ stato proprio il WAP Forum a produrre le prime specifiche per il supporto degli MMS in
ambiente WAP.
Open Mobile Alliance (OMA): si tratta di un’associazione piuttosto recente nata nel 2002.
Riassumendo potremmo dire che questo forum ha inglobato in sé vari progetti di
standardizzazione tra cui il lavoro precedentemente svolto dal Wap Forum sugli MMS.
Internet Engineering Task Force (IETF): questa estesa comunità di ricercatori accademici e
industriali ha definito standard e specifiche di gran parte dei protocolli che siamo abituati ad
utilizzare su Internet. Per capire perchè i protocolli IP-based siano importanti nel seguente
contesto si faccia riferimento al capitolo sull’architettura di rete e gli elementi del sistema
(CAPITOLO 2).
World Wide Web Consortium (W3C): questo ente di ricerca rilascia e ha rilasciato
importantissimi documenti sotto forma di Recommendation inerenti protocolli e formati per
il World Wide Web. Per gli standard e le specifiche MMS ci si è basati su lavori del W3C
quali XML, SMIL e anche HTTP, tanto per citarne alcuni.
28
APPENDICE B
MMS e EMAIL
In questa appendice verrà presentato un esempio reale in cui vedremo come appare un mms dopo la
conversione in mail. Sappiamo infatti che i destinatari di un mms possono essere anche i normali
utenti di posta: sarà compito dell’MMSC dopo un’apposita conversione infatti inviare la “nuova
mail” al mail server dell’utente destinatario.
Diamo quindi un’occhiata agli headers della mail.
Return-Path:<[email protected]>
Delivered-To:[email protected]
Received:from oink.dsi.unive.it (oink.dsi.unive.it [157.138.20.12])
by squit.dsi.unive.it (Postfix) with ESMTP id B1815BA8FD
for <[email protected]>; Tue, 7 Dec 2004 11:33:47 +0100 (CET)
Received: from gmoblmail2.net.vodafone.it ([83.224.67.1])
by oink.dsi.unive.it (8.12.11/8.12.11) with ESMTP id iB7AXlCT001435
for <[email protected]>; Tue, 7 Dec 2004 11:33:47 +0100
Received: from gmipl5lmail7.mipl5.vas.omnitel.it
(gmipl5mail143.mipl5.vas.omnitel.it [10.128.223.143])
by gmoblmail2.net.vodafone.it (Switch-3.1.6/Switch-3.1.6) with ESMTP id
iB7AXfCO004113
for <[email protected]>; Tue, 7 Dec 2004 11:33:41 +0100
Received: from gmipl5lmail1.mipl5.vas.omnitel.it
(gmipl5mail142.mipl5.vas.omnitel.it [10.128.223.142])
by gmipl5lmail7.mipl5.vas.omnitel.it (8.12.9-20030924/8.12.9) with ESMTP id
iB7AXeBa008079
for <[email protected]>; Tue, 7 Dec 2004 11:33:40 +0100
Received: from gmihmms2.mipl5.vas.omnitel.it ([10.128.221.133])
by gmipl5lmail1.mipl5.vas.omnitel.it (8.12.9-20030924/8.12.9) with ESMTP id
iB7AXe1R002019
for <[email protected]>; Tue, 7 Dec 2004 11:33:40 +0100
Received: from gmihmms2 (gmihmms2 [10.128.221.133])
by gmihmms2.mipl5.vas.omnitel.it (8.11.1/8.11.1) with ESMTP id iB7AXe226305
for <[email protected]>; Tue, 7 Dec 2004 11:33:40 +0100 (MET)
Message-Id: <[email protected]>
X-Mms-Message-Type: m-send-req
X-Mms-Transaction-Id: b-c7a0
X-Mms-MMS-Version: 1.0
Date: Tue, 07 Dec 2004 09:31:48 +0000
To: [email protected]
Subject: FW:
X-Mms-Message-Class: Personal
X-Mms-Priority: Normal
X-Mms-Sender-Visibility: Show
X-Mms-Delivery-Report: No
X-Mms-Read-Reply: No
From: "393495102812" <[email protected]>
Content-Type: multipart/mixed; Type="application/smil"; Start="<AAAA>";
boundary="Nokia-mm-messageHandler-BoUnDaRy-=_-21705839"
MIME-Version: 1.0
Reply-To: [email protected]
29
Come possiamo vedere il campo Return-Path ha come valore un indirizzo di posta fittizio che pero’
permette di risalire al mittente. Come sappiamo il classico formato di un indirizzo di posta e’ del
tipo nomeutente@dominio e nel nostro caso il nome utente e’ rappresentato dal numero di cellulare
del mittente.
Il messaggio effettua piu’ hop prima di arrivare al mail server di destinazione: nella fattispecie
passa per vari server locali appartenenti alla Intranet di Vodafone, e infine l’ultimo server (con ip
pubblico) forwarda il messaggio al server di posta dell’utente.
I campi seguenti che compaiono nell’header sono in tutto e per tutto simili a quelli che ritroviamo
nella classica struttura degli mms e hanno lo stesso significato.
30
APPENDICE C
Esempio reale di MMS
Rappresentazione in formato testuale di un vero MMS
31
RIFERIMENTI E BIBLIOGRAFIA:
[1] Mobile Messaging Technologies And Services: SMS, EMS and MMS.
[2] Multimedia Messaging Service: an Engineering Approach to MMS
[3] http://www.wapforum.org
[4] http://www.3gpp.org
[5] http://www.forum.nokia.com
[6] http://www.w3.org/AudioVideo/
[7] http://www.openmobilealliance.org
[8] http://www.imc.org/pdi/
32