Mensagens Multimídia Do SMS ao MMS

Transcrição

1 Mensagens Multimídia Do SMS ao MMS Christiano Freitas de Souza, Rafael Oliveira Ribeiro Departamento de Engenharia de Telecomunicações Universidade Federal Fluminense (UFF) Rua Passo da Pátria, 156 São Domingos Niterói RJ - Brazil Abstract. The Multimedia Messaging Service (MMS) is a new, versatile messaging service that can carry multimedia content, including images, video and audio clips, maps, graphs, layouts, cartoons, animations, etc. Today's popular text-based Short Messaging services and Smart Messaging services can be enhanced with richer MMS content. MMS also offers a radically better enduser experience compared to text only-based short messaging services. For example, a weather service can be extended from text-based information to include animated weather maps and forecast graphs with MMS capable terminals. Resumo. O serviço de mensagem multimídia (MMS) é um novo e versátil serviço de envio de mensagem que leva conteúdo multimídia, incluindo imagens, vídeo e clips de áudio, mapas, gráficos, layouts, cartoons, animações, etc. Hoje, os serviços populares baseados em Short Message e Smart Message podem ser melhorados com conteúdo MMS mais rico. MMS também oferece uma melhor experiência ao usuário final comparado com os serviços de short messaging baseados somente em textos. Por exemplo, o serviço de meteorologia, além de informações com apenas texto, pode ser extendido para incluir mapas de tempo animados e gráficos de previsão com o uso de terminais MMS adequados. 1. Introdução ao Serviço de Mensagem Multimídia (MMS Multimedia Messaging Service) MMS é designado para redes de alta velocidade como as redes GSM com HSCSD (High Speed Circuit Switched Data), GPRS, TDMA, WCDMA e 3G. A primeira versão de um MMS Center é designada para redes GSM e GPRS. Um MMS Center funciona como uma central store and forward para o envio de mensagens MMS em uma rede celular. O termo store and forward indica que: quando o MMS Center recebe a mensagem ela a armazena em seu banco de dados; o MMS Center envia a mensagem quando a estação móvel (MS Móbile Station) pede; se a mensagem não puder ser 1

2 entregue com sucesso, ela é armazenada para ser enviada posteriormente; depois de uma entrega bem sucedida, a mensagem é apagada do banco de dados do MMS Center. Uma central MMS pode permitir três tipos de comunicação: celular-a-celular, celular- e celular-outras aplicações, onde a comunicação entre o MMS Center e a MS é baseada em protocolos definidos pelo WAP Fórum. 1.1 Padronização MMS Existem duas entidades à frente desta padronização: - WAP Fórum (Wireless Application Protocol Fórum) [4] que define os protocolos entre o celular e o MMS Center, bem como o formato de apresentação. - 3GPP (3rd Generation Partnership Project) [3] que define services e a arquitetura MMS. O escopo original do 3GPP era produzir Especificações Técnicas globalmente aplicáveis para um sistema móvel de 3ª geração baseado em redes GSM evoluídas. O escopo do projeto foi mais tarde ampliado para incluir a manutenção e o desenvolvimento de especificações técnicas para o padrão GSM e suas evoluções, como GPRS (General Packet Radio Service) e EDGE (Enhanced Data rates for GSM Evolution). 2. SMS O SMS (Short Message Service) é o serviço de troca de mensagens de texto curtas entre celulares mais bem sucedido. Isto se deve basicamente à grande penetração da tecnologia GSM em vários mercados do mundo. Serviços semelhantes também existem em outras redes, como a TDMA (IS-136), CDMA (IS-95) e PDC (Japão). O funcionamento do SMS é muito simples.[1] As mensagens são trocadas entre telefones celulares num esquema store-and-forward, ou seja, um aparelho envia uma mensagem para outro, sendo que esta mensagem será recebida por um centro de controle da operadora do serviço antes de ser transmitida ao seu destinatário final. O centro de controle citado é chamado de SMSC (Short Message Service Center) e é responsável por todas as tarefas relativas ao processamento das mensagens, como roteamento, bilhetagem (cobrança) e entrega das mensagens. 2

3 Além da troca de mensagens entre aparelhos celulares, outras entidades também podem enviar e receber mensagens através deste sistema. Por exemplo, pode ser enviada uma mensagem de um computador para um aparelho celular e vice-versa. Neste sistema, as mensagens são enviadas utilizando-se o canal de controle do sistema celular, não ocupando, assim, canais que são utilizados para o tráfego de voz. Ao ser enviada a mensagem, pode ser que o destinatário não esteja disponível naquele instante. Neste caso, a mensagem será armazenada no banco de dados do SMSC e será feita uma solicitação ao HLR (Home Location Register) para que este avise ao SMSC assim que o usuário esteja disponível para receber a mensagem. Caso seja ultrapassado um determinado tempo sem que a mensagem seja entregue esta será descartada e, opcionalmente, uma mensagem notificando o remetente poderá ser enviada a este. Na figura abaixo podemos identificar os componentes principais de uma rede que dão suporte ao serviço SMS: Figura 1 Podemos identificar as aplicações externas, como , web e voic , que podem tanto enviar como receber SMS para / de aparelhos celulares. Os aparelhos celulares estão logicamente conectados ao MSC (Master Station Controller), que transfere todas as mensagens ao SMSC através dos Pontos de Transferência do Sinal (STP Signal Transfer Point). Como já foi dito, o SMSC é a entidade responsável por processar a mensagem recebida. Uma característica muito importante deste sistema é a o tamanho de cada mensagem, que é limitado a 160 caracteres, se usado o alfabeto ocidental ou 80 caracteres, 3

4 no caso dos alfabetos árabe ou chinês. Este é um fator que limita as funcionalidades do SMS, mas que, ao mesmo tempo, possibilita que sejam criados serviços a um baixo custo, principalmente do ponto de vista da aquisição de equipamentos na rede celular. O formato da mensagem consiste basicamente de um cabeçalho, contendo informações de controle, como endereço de destino, de origem, tamanho da mensagem, entre outras, e do corpo da mensagem propriamente dito. Este formato é muito semelhante ao formato das mensagens de e assim é possível o intercâmbio de mensagens entre celular e . Header Message Body Figura 2 Um detalhamento maior não será abordado, dado que o enfoque deste trabalho é o assunto MMS (Multimedia Message Service). 3. EMS Nesta seção iremos explicar o serviço EMS (Enhanced Message Service) apresentando-o como uma extensão do serviço SMS [1]. Ou seja, o EMS não é uma forma radicalmente nova de troca de mensagens, como é o MMS. Na figura abaixo podemos ver um exemplo de uma mensagem EMS, contendo um texto seguido de uma imagem simples e novamente outro segmento de texto. Hello World!!! I'm happy : ) Figura 3 O grande segredo sobre como é possível transmitir imagens como esta são dois tipos diferentes de cabeçalhos. A mensagem, como toda mensagem SMS, possui um 4

5 cabeçalho que contém informações que são em sua maioria invisíveis ao usuário final e um campo de dados do usuário, que contém o corpo da mensagem. Ou seja, uma mensagem é composta por um cabeçalho com informações de controle e um campo de dados. O cabeçalho traz informações como o endereço de destino, tamanho da mensagem, etc. No caso do EMS, um campo muito importante é o TP UDHI (Transport Protocol User Data Header Information), informando que no campo de dados da mensagem há também um outro cabeçalho (UDH User Data Header). A mensagem EMS terá, então, o seguinte formato: Header 1 User Data Header Message Body Figura 4 O campo preenchido com o valor 1 é o TP UDHI, indicando ao aparelho celular que recebe a mensagem que dentro do corpo da mensagem existem mais informações de cabeçalho, além da própria mensagem. O primeiro byte do UDH indica o comprimento deste cabeçalho, chamado de UDHL (UDH Length). O restante da mensagem é o corpo da mensagem usual do sistema SMS. O User Data Header é composto pelo campo UDHL e outros elementos. Cada elemento é composto por: - Information Element Identifier (IEI) - Information Element Identifier Length - O deslocamento do objeto EMS, dentro do texto SMS - O valor do objeto EMS Vários tipos de objetos EMS são definidos. Abaixo temos uma lista com vários exemplos: - Texto formatado; - Som predefinido, similar ao padrão MIDI; - Som definido pelo usuário (melodias); - Animações predefinidas; - Animação em tamanho grande (16x16); 5

6 - Animação em tamanho pequeno (8x8); - Figura em tamanho grande (32x32); - Figura em tamanho pequeno(16x16); Apesar do significativo avanço em relação ao SMS, o serviço de EMS não suporta conteúdo multimídia tão bem quanto MMS. Explicaremos com mais detalhes, a seguir, o funcionamento desta tecnologia, abordando desde a arquitetura do sistema celular com suporte a MMS até os protocolos e linguagens para definição do conteúdo multimídia das mensagens. 4. MMS - Multimedia Massaging Services O MMS inclui quatro tipos básicos de serviços [2]: mensagens multimídia originadas no celular; mensagens multimídia terminadas no celular; mensagens multimídia originadas em uma aplicação; mensagens multimídia terminadas em uma aplicação. Em uma mensagem multimídia originada no celular quem envia é o celular. A mensagem pode ter três destinos diferentes: ela pode ser diretamente direcionada para outro celular; ela pode ser enviada para uma aplicação (como um ); e ela pode ser processada em uma aplicação antes de ser enviada para o celular de destino (neste caso, a mensagem é primeiramente devolvida a MMS Center, como por exemplo se uma figura tiver que ser convertida em outro formato, como de JPEG para GIF) Em uma mensagem multimídia terminada no celular o destino da mensagem é um celular, onde a origem pode ser outro celular ou uma aplicação (como em um serviço de aplicação de imagens ou quando do envio de um para o celular). Em uma mensagem multimídia originada em uma aplicação quem envia é uma aplicação e a mensagem pode ser enviada diretamente a um celular ou para outra aplicação. Em uma mensagem multimídia terminada em uma aplicação quem vai receber esta mensagem é uma aplicação, onde a origem de tal mensagem pode ser um celular ou outra aplicação. 6

7 4.1 Características de uma Mensagem Multimídia As características de uma central de mensagens multimídia dizem respeito ao endereçamento, ao período de validade da mensagem e a notificações e reconhecimentos MMS, como confirmação de mensagem, indicação de mensagem e relatório de entrega Endereçamento: Quanto ao endereçamento, a MSISDN (Móbile Subscriber ISDN number) é o primeiro método para endereçar um usuário final entre uma mensagem originada e terminada. O MSISDN deve testar em um formato internacional. O usuário pode digitar o número em formato internacional ou nacional, sendo que este é convertido no formato internacional quando a mensagem chega ao MMS Center. Cada aplicação tem seu próprio número. Toda vez que um MMS Center recebe uma mensagem, ele checa as regras de roteamento, caso a mensagem deva ser direcionada para uma aplicação externa. No endereçamento entre um MMS Center e um celular, cada celular de origem contata seu MMS Center, definido como default, cujo endereço é configurado no próprio celular. O endereçamento com s é usado para mensagens terminadas e, neste caso, roteamento padrão de mensagem da internet é usado Período de validade da mensagem São dois os modos de se definir o período de validade da mensagem: definição pelo próprio usuário, assinante da linha, ou pela operadora. Período de validade define o tempo em que a mensagem permanece válida. Por exemplo, se uma entrega de mensagem falhar, ela é armazenada para que outra tentativa de entrega possa ocorre futuramente, sendo que tais tentativas ocorrem dentro do tempo definido pelo período de validade. Quando a mensagem chega ao MMS Center, este vai determinar uma etiqueta de tempo para ela, a ser usado no calculo do período de validade. Depois que o período de validade se expira (no caso de entregas mal sucedidas), a mensagem será descartada e removida do banco de dados do MMS Center. Como dito, o usuário pode definir o período de validade diretamente de seu aparelho e existe um período de validade default configurado no MMS Center, o qual pode 7

8 ser modificado. Contudo, se o usuário definir um valor maior que o do operador, o sistema irá usar o seu período de validade estabelecido Notificações e reconhecimentos MMS Compreendem basicamente três tipos, visíveis ao usuário final: Message Confirmation Quando uma mensagem de um celular é recebida pelo MMS Center, este notifica o celular de origem se o MMS Center aceitou a mensagem para ser entregue ou não. Logo, a mensagem de confirmação pode ser positiva ou negativa, informado sobre o sucesso ou falha na submissão do pedido Message Notification Quando uma mensagem chega ao MMS Center, ele notifica o celular de destino sobre a mensagem que está aguardando para ser vista. Depois de receber a notificação de mensagem, o celular destino pode busca-la (fetch), adiar a entrega ou descartar a mensagem enviando uma resposta apropriada de volta ao MMS Center. Lembrando que, na primeira edição, alguns celulares suportavam somente a busca automática da mensagem Delivery Report O relatório de entrega pode ser visto como um relatório de status, informando a origem da mensagem se esta foi entregue com sucesso ou não e tem um período de validade associado. (Message Confirmation só diz se a mensagem chegou ao MMS Center, não garantindo nada quanto à entrega ao destino). O relatório de entrega pode conter informações, como por exemplo, se o destino rejeitou a mensagem. O relatório de entrega não é enviado automaticamente. É o originador da mensagem quem deve requerê-la separadamente quando envia sua mensagem, a qual só é armazenada no MMS Center quando ocorre falha na entrega. 4.2 Arquitetura e funcionalidade da rede Uma breve apresentação sobre a arquitetura num sistema celular GSM com suporte para MMS. 8

9 Um Gb BSS SGSN GPRS BB GGSN SMS- IWMSC SMS- GMSC SMSC MS BTS BSC A NSS MSC HLR VLR PPG WAP GW MMSC Ext. Appl. Figura 4 Existem três subsistemas em uma rede: a BSS (Base Station Subsystem), a NSS (Network Switching Subsystem) e o GPRS (Global Packet Radio Subsystem). A BSS é responsável pelo controle no caminho rádio. Cada chamada (e, também, chamada de dados) é conectada através da BSS e NSS, que toma conta das funções de controle de chamada. A parte do GPRS destina-se as informações comutadas por pacote, tendo o SGSN E GGSN conectados a si. Observa-se, também, três interfaces: a interface Um, entre o celular e a BSS, a Gb, entre a BSS e SGSN a interface A, entre a BSS a NSS. Vamos dar um enfoque na parte da arquitetura mais afim com o assunto MMS. Sendo assim, temos: SGSN (Serving GPRS Support Node): é a parte mais importante do sistema GPRS. Suas responsabilidades incluem: a conversão de protocolos usados no backbone IP e os usados na BSS e no celular; codificação e compressão; autenticação; gerenciamento de mobilidade; roteamento de informação para o GGSN apropriado quando uma conexão com uma rede externa for solicitada; interação com o MSC/VLR e o HLR; um resumo da bilhetagem e de tráfego estatístico; busca de informação do HLR do assinante. 9

10 GGSN (Gateway GPRS Support Node): suas responsabilidades incluem: roteamento de pacotes destinados a um celular vindos de uma rede externa para o SGSN; roteamento de pacotes originados do celular para a rede externa correta; interfaces com redes IP externas; um resumo da bilhetagem e de tráfego estatístico; alocação dinâmica ou estática de endereços IP para os celulares, seja por ele mesmo ou com a ajuda de um DHCP ou um servidor RADIUS. MSC (Mobile Switching Center): transmite mensagens multimídia entre a BSS e a MMS Center. HLR (Home Location Register): armazena as seguintes informações do assinante: MSISDN; IMSI; VLR e endereço SGSN; informações do assinante (como serviços permitidos...) VLR (Visitor Location Register): armazena informação temporariamente dos celulares dentro da área de cobertura de uma MSC, a qual ele está ligado. A informação é armazenada pelo tempo em que o celular estiver na área controlada pelo este registrador. O VLR, também, busca informação do HLR do assinante e notifica o HLR sempre que o celular se mover de uma MSC para outra área de cobertura. SMS-GMSC: (SMS-Gateway Mobile Switching Center): recebe mensagens curtas da SMSC, interroga o HLR para a informação de roteamento e da mensagem curta, e envia a mensagem curta para o MSC (Mobile Switching Centre) apropriado ou para o SGSN e reporta o resultado da operação ao SMSC. Em mensagens multimídia o SMSC só é usado com relatórios de entrega e notificações, que usam SMS como suporte. WAP Push Proxy ou PPG (Push Proxy Gateway): enviam relatórios de entrega e notificações para o celular que esta usando serviços SMSC. WAP GW (WAP Gateway): transfere a mensagem multimídia entre o celular e a MMSC, onde o protocolo WAP é usado para a comunicação com o celular. O Fórum WAP especificou duas diferentes funções, mas na prática eles ficam fisicamente no mesmo dispositivos. MMSC (Multimedia Messaging Center): é o que podemos chamar de "evolução natural" para a plataforma SMSC. Enquanto o SMSC é responsável pelo tratamento de mensagens de texto (com comprimento limitado) a plataforma MMSC permite agregar 10

11 valor ao tráfego de mensagens, possibilitando o uso de combinações de formatos de mídia, tais como: imagem, som e vídeo entre outros. Ext Appl (External Application): refere-se a aplicações de próprio operador, a aplicações de 3G, a conectividade com (Mail GW é um exemplo de aplicação externa), a conexões inter-mmsc (IMMSC é um exemplo de aplicação externa). Tal aplicação pode se localizar na rede do operador, na Internet ou em alguma outra rede Tipos de PDU MMS São cinco os tipos de PDU, conforme observamos na tabela abaixo. Tipo de PDU M-Send.req M-Send.conf M-Notification.ind M-NotifyResp.req WSP GET.req M-Retrive.conf Descrição Envia a mensagem para o MMS Center Reconhecimento do MMSC para a mensagem Notificação MMS sobre a nova mensagem Resposta do receptor sobre a ação a ser tomada Busca a mensagem no MMC Center Recebe a mensagem do MMS Center M-Acknowledge.ind Reconhecimento da entrega da mensagem M-Delivery.ind Relatório de entrega sobre a mensagem enviada M-Send.req mensagem enviada pelo celular para ao MMS Center. M-Send.conf quando o MMS Center recebe o pedido de enviar (Send Request) ele envia uma mensagem resposta de volta ao celular indicando o status da operação, que pode ser positivo ou negativo. M-Notification.ind notificações MMS informam ao celular sobre o conteúdo (URI Uniform Resource Identifier, que é o endereço do MMS Center, tamanho, tempo de validade) da mensagem que está esperando. 11

12 M-NotifyResp.req confirmação da notificação. O propósito desta confirmação é reconhecer a transação (deferindo, apagando,encaminhando posteriormente) para o MMS Center. Se for para recuperar a mensagem imediatamente, um comando de GET request é o deve ser usado. WSP GET.req o celular recupera a mensagem enviando um WSP GET request para o MMS Center. M-Retrive.conf quando o comando GET é bem sucedido, a resposta irá conter cabeçalhos e o corpo da mensagem que estiver chegando (incoming message). M-Acknowledge.ind confirma a entrega da mensagem do terminal receptor para o MMS Center. Trata-se de um comando opcional de acordo com especificações (é sempre usado nas soluções Nokia). Se um GET tiver sido usado no lugar de um M- NotifyResp.req, este é usado no lugar de M-Acknowledge.ind. M-Delivery.ind um relatório de entrega MMS pode ser enviado do MMS Center do receptor para o celular que está originando a mensagem quando o receptor tiver reagido ao MMS Notification. O relatório de entrega pode incluir informações sobre busca, rejeição e expiração. Há um relatório de entrega separado para cada receptor e não existe mensagem de resposta ao relatório de entrega Estrutura do PDU A estrutura do Protocol Data Unit (PDU) MMS é especificada pelo Wap Forum na especificação WAP-209-MMSEncapsulation. Um PDU consiste de um cabeçalho e um corpo, ou somente de um cabeçalho. O corpo está presente somente nos PDU s dos comandos M-Send.req e M-Retrive.conf. Também existem PDU s formadas só de cabeçalhos. As mensagens MMS são submetidas para a entrega em uma PDU M-Send.req. Ela consiste de cabeçalhos e corpo de mensagem, o qual contém o conteúdo da mensagem MMS encapsulado com MIME (O MIME vai ser explicado mais adiante). Para M- Send.req, os seguintes cabeçalhos são mandatórios: 12

13 Nome Valor em Hex Conteúdo Comentários X-Mms- Message-type- Especifica o tipo da 8c Message-Type Value= m-send.req mensagem Um identificador único para a X-Mms- mensagem. Identifica tanto a 98 Transaction-id-value Transaction-ID mensagem enviada quanto a mensagem de confirmação. X-Mms- Version 8d MMS-version-value O número da versão MMS From 89 From-value Endereço do originador da mensagem. Este campo precisa ser mostrado ao destinatário da mensagem. A completa lista de PDUs MMS e cabeçalhos M-Send.req, bem como os cabeçalhos opcionais, são apresentados no Wap Forum na especificação WAP-209- MMSEncapsulation. A tabela seguinte mostra um exemplo de um cabeçalho de uma mensagem MMS (PDU M-Send.req) antes da codificação em binário. X-Mms-Message-Type: m-send-req X-Mms-Transaction-ID: X-Mms-Version: 1.0 To: /TYPE=PLMN From: /TYPE=PLMN Subject: Test MMS message Date: Wed Oct 24 09:55: Content-Type: application/vnd.wap.multipart.mixed O corpo da mensagem de múltiplas seções (multipart) do exemplo consiste de duas partes. A primeira é um texto sem formatação (This is an example MMS message with plain text and image.) e a segunda é uma imagem. A mesma mensagem (cabeçalhos + corpo) no formato binário codificado é apresentada no formato hexadecimal na tabela a seguir, onde se nota que a imagem não foi inteiramente apresentada na tabela. 13

14 The above M-Send.req in binary encoded format displayed in hex mode : 8c d : 972b f /TY : d50 4c4d 4e b PE=PLMN : f d50 4c4d /TYPE=PLM : 4e d4d d N..Test MMS mess : bd6 65f8 84a age...;.e : e d70 This is an examp : 6c65 204d 4d53 206d le MMS message w : c e ith plain text a : 6e d e1d 83c e81 nd image...d a0: 83ae a JFIF bo: ffed 0de O cabeçalho contém principalmente informações de como transferir a mensagem do terminal de origem para o de destino. Cada campo de cabeçalho consiste de um campo de nome seguido de um campo de valor. Uma mensagem MMS pode conter um ou mais dos tipos de conteúdo abaixo: Texto: pode ser texto plano ou formatado Gráficos: suporte a tabelas, diagramas e gráficos animados (GIFs) entre outros Imagens: suporte ao envio/recebimento/edição de imagens, como por exemplo capturadas com câmeras integradas ao celular Áudio: suporte para música, voz e streaming de áudio Vídeo: suporte a clipes curtos (30 segundos) de vídeo. Futuramente poderá ser aumentada esta capacidade. Pode ser de seção única, contendo somente um objeto ou pode ser de múltiplas seções relacionadas (Multipart/related) [RFC2387]. Neste caso, o corpo contém vários objetos multimídia, cada qual em uma seção separada e a seção de apresentação. A seção principal (part root) é apontada pelo parâmetro Start. Um exemplo de técnica de apresentação no MMS e é conseguida com o SMIL (Synchronized Multimedia Integration Language). A ordem dos objetos não tem importância, mas a seção de apresentação deve ser a primeira no corpo com múltiplas seções. 14

15 Figura 5 A apresentação MMS contém instruções de como o conteúdo multimídia deve ser reproduzido no display e auto-falantes do terminal. Uma seção de apresentação é necessária para cada representação em uma mensagem. Lembrando que, nas primeiras versões, os terminais suportavam somente uma seção de apresentação. Cada uma das multparts consiste de conteúdo e informação de identificação da multipart. Os cabeçalhos de cada parte contêm os seguintes campos: Tipo de conteúdo: indicando o conteúdo na multipart, como image/jpeg ou text/plain; Localização de conteúdo: identificando o conteúdo, como image.jpeg ou hello.txt. O corpo, também, pode ser de múltiplas seções misturadas (Multipart/mixed). Neste caso, contém vários objetos multimídia, cuja ordem não tem importância e não há, no corpo informação de apresentação. Desta forma, depende da implementação do terminal de como o conteúdo multimídia era apresentado. A figura abaixo mostra o modelo conceitual e um exemplo de encapsulamento. 15

16 Figura SMIL Mensagens MMS são baseadas no SMIL (Synchronized Multimidia Integration Language).O SMIL é similar ao HTML [5] na sintaxe e construções e é essencialmente uma maneira de sincronizar conteúdos multimídia ricos e interativos para a entrega em tempo real na web e, também, sobre conexões de banda estreita. No SMIL, a informação de apresentação é codificada em um arquivo de apresentação. A intenção é apresentar um conteúdo multimídia em uma ordem específica em um intervalo de tempo predeterminado. As apresentações de multimídia do SMIL consistem de elementos tais como vídeo, voz, imagens, texto, vídeo e gráficos todos sincronizados por meio de uma linha de tempo comum (isto é, não são entregues com anexos). Um exemplo de uma apresentação multimídia com SMIL são vídeos jornalísticos que enfatizam as manchetes das notícias, sendo também apresentado um quadro com informações da bolsa de valores na base da tela. Mensagens usando SMIL podem ser vistas como se tivessem um estilo PowerPoint no dispositivo móvel. Usando um simples editor de mídia, um usuário pode incorporar áudio e vídeo com imagens, animações e texto para criar uma apresentação multimídia completa. 16

17 por: As mensagens baseadas no SMIL são do tipo slide show e são caracterizadas Ter um ou mais slides; Cada slide deveria ser entendido como um quadro que incorpora o conteúdo, o qual será mantido separado; Inicialmente, cada slide terá duas seções, uma para o texto e outra para a imagem. Slides podem ter somente texto ou somente imagem; SMIL especifica o layout, a ordena e apresenta cada slide; Os conteúdos do slide devem ser criados em um formato aprovado; Os slides e os arquivos são empacotados em uma única mensagem. 4.4 Tratamento da mensagem na rede O terminal solicita uma operação de WAP POST com a mensagem M-Send.req incluída como conteúdo do corpo. O terminal compõe uma ID da transação para a mensagem submetida. O ID é usado pelo terminal e pelo MMS Center para prover um elo entre a mensagem originada M-Send.req e a resposta M-Send.conf. O valor usado para a transação ID é determinado pelo terminal e nenhuma interpretação é esperada do MMS Center. A mensagem é submetida usando uma URI que endereça o MMS Center que dá suporte ao terminal especificado. A mensagem é transferida através do BSS para o SGSN, que a envia para o correto GGSN. O MMS Center atribui uma mensagem ID à mensagem quando recebida com sucesso para a entrega. Este ID é usado em atividades seguintes que necessitam se referenciar a mensagem específica enviada, como por exemplo, no envio posterior de um relatório de entrega. No receptor da mensagem de M-Send.req, o MMS Center responde ao WAP POST com uma resposta, que prove um código de status para a operação solicitada. Se o MMS Center aceitar o pedido para enviar a mensagem, o status é accepted e a mensagem inclui o ID da mensagem que o MMS Center havia fornecido. A mensagem de confirmação é roteada pelo mesmo caminho feito pelo M-Send.req Enviando uma notificação de mensagem deferida Os cabeçalhos do PDU (aqueles que o MMS Center adicionaram ao PDU original) são usados para gerar uma notificação para o receptor, e são entregues com o corpo da mensagem para o receptor na recuperação. 17

18 Uma transação identificadora é criada pelo MMS Center antes de enviar a notificação e é única dependendo somente do M-NotifyResp seguinte. Se o cliente MMS solicitar adiar a entrega com M-NotifyResp, o MMS Center pode criar um novo identificador de transação. A notificação usa SMS como transportador: O MMS Center envia o M- Notification.ind para o SMS Center, que posteriormente, envia a mensagem para o SMS- GMSC. Este, por sua vez, pede informações de roteamento ao HLR, isto é, a localização do MSC com o qual o celular receptor estava conectado pela última vez. O SMS-GMSC, então, encaminha a mensagem para o MSC, que checa o VLR para se certificar que o celular não foi bloqueado ou alguma outra restrição para o uso da rede. O MSC, então, encaminha a mensagem através da BSS para o celular receptor. A informação no o M-Notification.ind inclui a URI que será usada para realmente recuperar a mensagem em uma operação subsequente pelo terminal receptor. Informações adicionais sobre a mensagem (como tamanho, e expiração) podem ser usadas pelo terminal para determinar seu comportamento. Por exemplo: o terminal pode atrasar a recuperação da mensagem se ela exceder o tamanho definido. O receptor de um M-Notification.ind informa a ação a ser tomada pelo MMS Center com o M-NotifyResp.req, que é roteado para o MMS Center da mesma forma que o M-Notification.ind Mensagem de busca Se o receptor quiser buscar uma mensagem, ele envia o WSP GET.req para o MMS Center. A URI (endereço da MMS Center) requerida para a recuperação, enviada na mensagem M-notification.ind anterior, é usado no GET request. A informação que retorna (M-Retrieve.conf) do MMS Center para o celular receptor inclui a mensagem multimídia. Outros tipos de tratamento de mensagens na rede: Alerta de assinante ausente Relatório de entrega Assinante em roaming Mensagem originada e terminada em uma aplicação 18

19 O roteamento de M-Send.req e M-Send.conf entre o celular que envia e a MMS Center acontece exatamente da mesma forma que com mensagens originadas e terminadas no celular. O MMS Center encaminha a PDU para uma aplicação externa que pode estar na mesma rede IP que o próprio MMS Center, ou em outra rede. Reconhecimentos entre o MMS Center e a aplicação externa depende do tipo desta aplicação externa. A ligação entre o MMS Center e a aplicação externa é feita pelo M-Send.req. Figura 7 19

20 Figura Interface de Aplicação Externa A Interface de Aplicação Externa (EAIF) dá à operadora a possibilidade de introduzir uma variedade de aplicações externas e serviços de valor adicionado. É esta interface que seré usada na comunicação com aplicações externas, como e www. O protocolo utilizado para este fim é o HTTP 1.1. Este é um protocolo de comunicação muito utilizado na Internet e é baseado num esquema de requisições/respostas envolvendo um servidor e um cliente. No contexto de MMS, o servidor é a parte que recebe a mensagem e o cliente é a parte que envia a mensagem. Em se tratando de EAIF, tanto o MMSC quanto a aplicação podem fazer o papel de cliente ou servidor. Existem três operações que podem ser realizadas através da EAIF: - Aplicações podem enviar mensagens; - Aplicações podem receber mensagens; - Aplicações podem receber avisos de entrega de mensagens. As mensagens MMS são enviadas através da PDU M-Send.req e na transmissão de avisos de entrega de mensagens, a PDU M-Delivery.ind é utilizada. As PDUs são entregues através da interface de aplicação externa (EAIF) através do corpo das mensagens HTTP. 20

21 Os aspectos de segurança são tratados utilizando-se SSL (Secure Sockets Layer), que oferece métodos confiáveis de encriptação e autenticação entre a interface de aplicação externa e as aplicações externas. Para maiores informações sobre HTTP, veja [3], [7] 4.6 Mensagens HTTP As PDUs MMS usadas na EAIF (M-Send.req e M-Delivery.ind) são entregues para /de aplicações no corpo do HTTP POST request. Um HTTP POST request consiste simplesmente de: Cabeçalhos de extensão http (opcional) Cabeçalhos http mandatórios Corpo da mensagem A seguinte figura apresenta a estrutura de um HTTP request contendo os cabeçalhos de extensão e os mandatórios e a PDU MMS no corpo da mensagem. Figura 9 Podemos examinar um pouco mais a fundo [6] uma requisição http para identificarmos os campos referentes ao cabeçalho http e o conteúdo da mensagem http, que neste caso é uma PDU MMS. A figura abaixo ilustra este detalhamento, mostrando a PDU MMS em formato texto, mas na verdade, ela é encapsulada na requisição HTTP em formato binário: 21

22 Figura Exemplo de uma mensagem MMS encapsulada numa requisição http: A tabela a seguir exemplifica o uso do encapsulamento da PDU MMS dentro da requisição HTTP. Requisição http de uma mensagem originada por aplicação contendo a M-Send.req POST / HTTP /1.1 Host: mmsc.operator.com:80 Content-Type: application/vnd.wap.mms-message Content-Length: 188 m-send.req 22

23 A M-Send.req no corpo da requisição HTTP do exemplo acima contém os seguintes cabeçalhos e os valores correspondentes: X-Mms-Message-Type: m-send-req X-Mms-Transaction-ID: X-Mms-Version: 1.1 From: /TYPE=PLMN To: /TYPE=PLMN Subject: This is a Multimedia Message Content-Type: application/vnd.wap.multipart.mixed O corpo da mensagem contém somente um texto plano: This message contains only this text Conectividade com O roteamento do M-Send.conf entre o aparelho que está enviando uma mensagem e o MMS Center acontece exatamente da mesma forma que com mensagens originadas e terminadas no aparelho. O MMS Center converte a mensagem multimídia para uma mensagem de normal e a envia para o servidor de . Este servidor reconhece a mensagem recebida usando o protocolo SMTP, o qual é usado na comunicação entre o MMS Center e o servidor de . SMTP entende apenas informação de texto puro e é usado efetivamente para a transferência de dados. MIME (Multipurpose Internet Mail Extension) é usado para dar suporte à transmissão de dados em formatos diferentes de ASCII (por exemplo arquivos gif, jpeg, wav, etc) como anexos de uma mensagem. 23

24 4.7 Celulares para MMS O dispositivo a seguir é um exemplo de um celular da Nokia com capacidade para MMS. Series 40 Terminals MMS send and receive (45kB) Supported formats: Basics from Conf. Doc. (baseline JPEG, GIF87a, GIF89a, WBMP) - animated GIF89a, PNG, Windows BMP - SP-MIDI 43 instruments, 4 at a time - Nokia wallpaper (image/vnd.nok-wallpaper) file format is JPEG, GIF87a, GIF89a, PNG, BMP - Nokia ringing tone (application/vnd.okia.ringing-tone) 128x128 display In MMS Viewer, available display size is 122x96 Using COD: Nokia color operator logo (image/vnd.nok-oplogo-color) 100x50 JPEG, GIF87a, or GIF89a image 4.8 Vídeo em MMS Figura 11 Nokia 3650, 6650, 6220 e 6600 são capazes de tocar e gravar clipes de vídeo O tamanho máximo em uma mensagem MMS é de 100 Kb. Não há limite quando se grava um clipe local Figura 12 24

25 4.9 Criando mensagens MMS Adobe GoLive w/nokia Developers Suite for MMS [6] - criação baseada no SMIL e não há controle sobre os tipos MIME Nokia Mobile Internet Toolkit criação baseada no conteúdo, controle sobre tipos MIME e suporte a SMIL baseado em texto Nokia MMS Java Library tem um controle detalhado e requer um conhecimento mais profundo para ser operado Nokia Mobile Server Services API and Library também tem um controle detalhado e requer muito conhecimento Figura Conclusão Depois de toda a apresentação das características do serviço MMS, fazemos uma analogia que ilustra nossa visão sobre o assunto: A evolução do SMS para MMS representa, para o mundo das comunicações móveis, o que representou para o mundo da informática a mudança do DOS para o Windows. 25

26 6. Referências [1] Flying Boat < [2] Mobile MMS < [3] 3GPP < [4] WAP Forum < [5] W3C < [6] Nokia Developer s Guide to MMS [7] Nokia - MMS Center Application Development Guide Version