Atividades do grupo de Transporte de Áudio e Vídeo do IETF

Transcrição

1 Atividades do grupo de Transporte de Áudio e Vídeo do IETF Domenico Sávio G. de Araújo e Solon Antônio Andrade dos Santos Mestrado em Telecomunicações Universidade Federal Fluminense (UFF) Rua Passos da Pátria 156- Niteroi RJ Brasil {solon}solon@midiacom.uff.br, domenico@midiacom.uff.br Resumo. Este trabalho mostra uma visão básica do SRTP(Secure Real-time Protocol), o protocolo AVPF(Audio Visual Profile Feedback) e o ilbc(internet Low Bit Code), que são os mais recentes trabalhos em andamento do grupo AVT(Audio/Video Transport) do IETF(The Internet Engineering Task Force) 1. Introdução O grupo de Trabalho de transporte de Áudio/Vídeo da IETF foi formado para especificar um protocolo para a transmissão em tempo real de áudio e de vídeo sobre protocolos UDP/IP em redes unicast e multicast. O objetivo deste documento é mostrar os mais recentes trabalhos em andamento do grupo de trabalho AVT do IETF. Dentro da proposta de trabalho apresentada foram destacados três trabalhos desenvolvidos pelo grupo. Na primeira parte, é apresentado o SRTP (Secure Real-time Protocol), protocolo que garante a segurança e a integridade dos pacotes RTP(Real-time Protocol). Na segunda parte, será mostrado o protocolo AVPF, que é uma extensão do AVP. Na terceira parte, será apresentado o Internet Low Bit Codec (ilbc), que descreve o formato do payload do RTP. 2. SRTP Secure Real-Time Protocol O SRTP (Secure Real-time Transport Protocol) provê segurança para o RTP(Real-time Transport Protocol) e RTCP(the Real-time Transport Control Protocol). O SRTP insere no cabeçalho das mensagens RTP e RTCP campos para serviços de criptografia e mensagens de autenticação. Além disso, define um conjunto básico de transformações criptográficas, permitindo futuras transformações. Através do gerenciamento de chave, o SRTP é estável tanto para aplicações RTP em redes unicast quanto para aplicações em redes multicast. O SRTP pode atingir uma alta vazão de dados e baixa utilização computacional, em função do tamanho reduzido do pacote, e mostrou ser uma proteção apropriada para ambientes heterogêneos (Redes com e sem fio).

2 A segurança no SRTP garante: - Sigilo no Payload do RTP e RTCP(Criptografia); - Integridade dos pacotes RTP e RTCP(Mensagens de Autenticação); Os serviços de criptografia e autenticação são opcionais e independentes um do outro. Além do mostrado acima, SRTP e o SRTCP têm outros objetivos funcionais: - Estrutura que permite atualizações de novas transformações criptográficas; - Um baixo custo computacional (footprint), obtido pelo através do tamanho reduzido do pacote garantindo economia de Largura de Banda. - Independência das camadas inferiores de Transporte, Rede e Física usadas pelo RTP, e alta tolerância a perda e reordenação de pacote. Essas propriedades garantem ao SRTP um conveniente plano de proteção para o RTP/RTCP nos cenários wired e wireless. Quanto ao esquema de criptografia, SRTP provê alguns recursos adicionais: - Uma única Chave Máster para criptografia e autenticação, tanto para a o SRTP quanto para ao SRTCP. Isso foi possível graças a função de Chave de Derivação, fornecendo Chaves de Sessão que são utilizadas diretamente na transformação criptográfica. A Chave Máster garante a segurança das chaves de sessão. - Além disso, a Chave de Derivação pode ser configurada para atualizar as Chaves de Sessão periodicamente. 2.1 Cabeçalho do SRTP O cabeçalho SRTP é uma extensão cabeçalho RTP 1. Exceto onde é explicitamente notificado, todos os aspectos aplicáveis ao RTP são válidos, para os recursos de segurança do SRTP. Conceitualmente o SRTP é considerado como um choque na pilha de implementação, pois o SRTP reside entre o RTP e a camada de transporte. No lado transmissor, o SRTP 2 intercepta os pacotes RTP e envia o pacote SRTP equivalente. No lado do receptor, o 1 [RFC 1889/3550] RTP: A transport Protocol for Real-Time Applications IETF Network Group; 2 [RFC 3711] SRTP: The Secure Real-time Transport Protocol (SRTP)

3 pacote SRTP é interceptado, processado e o equivalente pacote RTP enviado para o Bloco RTP da pilha. O SRTCP (Secure RTCP) provê os mesmos serviços de segurança para o RTCP como o SRTP faz para o RTP. A mensagem de autenticação SRTCP é obrigatória e com isso, protege os campos do RTCP, garantindo a realimentação/resposta para o emissor, ou mantendo os contadores de seqüência de pacotes. O cabeçalho do SRTP é mostrado na figura 1. Figura 1- Cabeçalho SRTP A parte de criptografia de um pacote SRTP consiste da criptografia do Payload (Dados) do Pacote RTP incluindo os bits de comprimento (Padding) quando presentes. A parte de criptografia pode ser exatamente do mesmo tamanho de mensagem não criptografada ou pode ser maior. A figura 1 mostra o cabeçalho RTP incluindo uma possível quantidade de bits de enchimento para o RTP. Nenhuma das transformações Cripitográficas pré-definidas usa Padding, logo o tamanho do Payload é o mesmo do texto não criptografado. O Padding é utilizado quando o esquema de criptografia necessita de um tamanho mínimo do pacote, e a sua presença é informada no cabeçalho do pacote RTP (Campo P). O último octeto do preenchimento indica quantos octetos de enchimento serão ignorados. Novas transformações criptográficas podem usar Padding, gerando um aumento no tamanho do cabeçalho. No cabeçalho SRTP são encontrados dois outros campos que não estão presentes no cabeçalho RTP. São eles o MKI(Master Key Identifier) e o Authentication tag. O MKI é de tamanho configurável e é opcional. O MKI é definido e usado pelo Gerenciador de Chave, e identifica a Chave Máster de cada Chave de Sessão que é criptografada/autenticada em um pacote a parte. É importante notar que O MKI não identifica o contexto criptográfico. No processo de descriptografia, o MKI pode ser usado

4 pelo Gerenciador de Chave para identificar uma Chave Máster dentro de um contexto Criptográfico. O campo Authentication tag(etiqueta de autenticação) tem comprimento configurável e é recomendado. O Autentication Tag é usado para transportar os dados de autenticação da mensagem. A parte de autenticação do pacote SRTP consiste de um cabeçalho RTP seguido da parte criptografada do pacote SRTP. Desta forma, se a criptografia e autenticação são aplicadas, a criptografia deve ser aplicada antes da autenticação do lado do transmissor e entendido do lado do receptor. A Autentication Tag provê a autenticação do cabeçalho e do payload do RTP, e indiretamente provê a Replay Protection através da autenticação do número de seqüência. Note que o MKI não garante a integridade e nenhuma proteção extra. Como contexto criptográfico, cada fluxo SRTP requer que um remetente e um receptor mantenham informações de estado criptográfico. O SRTP usa dois tipos de chave: Chave Máster e Chaves de Sessão. As Chaves de Sessão são utilizadas diretamente na transformação criptográfica, e a Chave Máster, é um string randômico de bits (dado pelo Protocolo Gerenciador de chave) com o qual as Chaves de Sessão são enviadas em caminho criptograficamente seguro. A Chave Máster e outros parâmetros no contexto criptográfico são providos através de mecanismos externos ao SRTP. As figuras 2 e 3 ilustram o processo de criptografia do lado do remetente e receptor respectivamente. Dado Definição do contexto Criptográfico Definição da Chave Master Chave Master Definição de Chaves de Sessão Chaves Sessão Dado Cripitografado Envio do Dado Figura 2 - Remetente

5 Figura 3 Receptor Dado Cripitografado Algorítimo para decodificar a Chave Master MKI Chave Master Algorítimo para decodificar as Chaves de Sessão Chave de Sessão Dado

6 3. AVPF RTCP Audio and Video Payload Format Os mecanismos atuais disponíveis com o RTP para melhorar a resiliência a erro incluem codificação redundante de áudio, a codificação redundante de vídeo, o RTP-Level FEC, e considerações gerais na transmissão mais robusta dos fluxos de mídia (formato genérico de payload para FEC). Estes mecanismos podem ser proativamente aplicados desse modo aumentando a largura de banda de um dado fluxo de mídia. Alternativamente, em grupos suficientemente pequenos com RTTs curtos, os remetentes podem executar o reparo ad-hoc (on-demand), usando os mecanismos acima e/ou estratégias mídia-codificação específicas(p.ex. RTP Payload Format for H.261 Video Streams). Observe que "pequenos grupos e "o RTT suficientemente curtos" são ambos altamente dependentes da aplicação. O AVPF especifica um tipo modificado de RTP para conferências de áudio e vídeo com o controle mínimo baseado em Protocolo para Aplicações Real Time e por meio de duas modificações/adições. Para conseguir o feedback rápido, o conceito de mensagens antecipadas de RTCP, assim como os algoritmos que permitem o baixo atraso de feedback em grupos multicast pequenos (e em impedir a implosão de feedbacks nos grandes), é introduzido. A consideração especial é dada aos cenários ponto-a-ponto. Um número pequeno de mensagens de feedback de propósito geral, assim como um formato para o codec e a informação de feedback específica da aplicação são definidos para a transmissão nos payloads do RTCP Definições Aplicam-se as definições de RTP/RTCP e o perfil de RTP para conferências de áudio e vídeo com controle mínimo, as seguintes definições são usadas. Modalidade antecipada de RTCP: A modalidade de operação em que um receptor do fluxo de mídia é freqüentemente (mas não sempre) capaz de relatar eventos de interesse, próximo de sua ocorrência de volta ao remetente. Na modalidade antecipada de RTCP, os pacotes de RTCP são transmitidos de acordo com as regras de sincronismo definidas neste documento. Pacote Antecipado de RTCP: Um pacote adiantado de RTCP é um pacote que seja transmitido tão rápido quanto seja permitido, seguindo a programação do algoritmo, sendo a razão um "evento" observado por um receptor. Os pacotes antecipados de RTCP podem ser emitidos no feedback imediato e na modalidade antecipada de RTCP.

7 Evento: Uma observação feita pelo receptor do fluxo de mídia que é do interesse (potencial) do remetente -- tal como uma perda de pacote -- e assim útil ser relatado de volta para o remetente por meio de uma mensagem de feedback. Mensagem de feedback (FB): Uma mensagem de RTCP é usada para conduzir a informação sobre os eventos observados em um receptor -- além da informação de status de longo prazo do receptor que é carregado no RTCP RRs (receiver report) - de volta ao remetente do fluxo de mídia. Por questão de clareza, a mensagem de feedback é referenciada como a mensagem de FB. Threshold do feedback (FB): O Threshold do FB indica a transição entre o feedback imediato e a modalidade antecipada de RTCP. Para um cenário multipartes, o Threshold do FB indica o tamanho máximo do grupo em que, na média, cada receptor pode relatar imediatamente cada evento de retorno ao remetente(s), isto é feito por meio de um pacote Antecipado de RTCP sem ter que esperar seu intervalo regularmente programado de RTCP. Este Threshold é altamente dependente do tipo de feedback a ser fornecido, QoS da rede (por exemplo probabilidade e distribuição da perda do pacote), esquema do codec e do empacotamento em uso, a largura de banda da sessão e exigências da aplicação. Percebe-se que os algoritmos não dependem de todos os remetentes e receptores que concordam com o mesmo valor para este Threshold. Pretende-se fornecer a orientação conceitual aos projetistas de aplicação e não é usado em nenhum cálculo. Modalidade imediata do feedback: Uma modalidade de operação em que cada receptor do fluxo de mídia é, estatisticamente, capaz de relatar cada evento do interesse imediatamente de volta ao remetente do fluxo de mídia. Na modalidade imediata do feedback, as mensagens de RTCP FB são transmitidas de acordo com as regras de sincronismo definidas. Pacote da mídia: Um pacote de mídia é um pacote de RTP.

8 Modalidade regular de RTCP: Modalidade de operação em que nenhuma transmissão de mensagens preferenciais de FB é permitida. Entretanto, as mensagens de RTCP são emitidas depois das regras do RTP. Não obstante, tais mensagens de RTCP podem conter a informação do feedback como definida no AVPF. Pacote regular de RTCP: Um pacote de RTCP que não seja emitido como um pacote antecipado de RTCP. Remetente RTP: Um remetente RTP é uma entidade RTP que transmite pacotes de mídia tanto quanto os pacotes RTCP e recebe regularmente tanto quanto pacotes antecipados de RTCP (isto é feedback). Perceba que o remetente RTP é um papel lógico e que a mesma entidade RTP pode ao mesmo tempo agir como um receptor RTP. Receptor RTP: Um receptor RTP é uma entidade RTP que receba pacotes de mídia tanto quanto pacotes RTCP e transmita regularmente pacotes antecipados de RTCP (isto é feedback). Note que o receptor RTP é um papel lógico e que a mesma entidade RTP pode ao mesmo tempo agir como um remetente RTP Formatos de pacotes RTP e de RTCP e comportamento do protocolo RTP As regras definidas para formatos de pacotes dentro do RTP 3 aplicam-se também ao AVPF à exceção daquelas regras mencionadas a seguir: Tipos do pacote RTCP: Dois tipos adicionais do pacote RTCP são registrados e as mensagens correspondentes do FB para fazer saber à informação do feedback são definidas a seguir. 3 H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control," RFC 3551 (STD0065), July 2003.

9 Formatos de mensagens do feedback de RTCP Esta seção define o formato das mensagens do feedback RTCP antecipado. Estas mensagens são classificadas em três categorias como segue: - mensagens do FB da camada de transporte - mensagens Payload-específicas do FB - mensagens do FB da camada de aplicação As mensagens do FB da camada de transporte tem o objetivo de transmitir a informação do feedback de uso geral, isto é independente da informação do codec particular ou a aplicação em uso. A espera-se que a informação seja gerada e processada na camada de transporte RTP. Atualmente, somente uma mensagem genérica negativa de reconhecimento da mensagem (NACK) é definida. Payloads específicos de FB transportam a informação que é específica a algum tipo de payload e será gerada e inferida sobre a "camada" do codec. As mensagens do FB da camada de aplicação fornecem meios fazer transparente ao feedback do receptor à aplicação do remetente. A informação contida em tal mensagem não se espera atuar sobre a camada de transporte/rtp ou na do codec. Os dados a serem trocados entre duas instâncias da aplicação geralmente são definidos na especificação do protocolo de aplicação e assim podem ser identificados pela aplicação de modo que não haja nenhuma necessidade de informação externa adicional. Do ponto de vista do protocolo, uma mensagem do FB da camada de aplicação é tratada como um caso especial de uma mensagem FB com payload específico. Intervalos do relatório de RTCP: O AVPF descreve três modalidades de operação que influenciam os intervalos do relatório de RTCP. Na modalidade regular de RTCP, todas as regras de Protocolo para Aplicações Real Time aplicam-se, à exceção do intervalo mínimo recomendado de cinco segundos entre dois relatórios RTCP da mesma entidade RTP. Em ambos o feedback imediato e as modalidades antecipadas de RTCP, os intervalos mínimos de cinco segundos entre dois relatórios RTCP são ignorados. Adicionalmente, as regras especificadas para o feedback de RTCP 3.1 aplicam-se se os pacotes de RTCP que contêm as mensagens do FB que forem transmitidos. As regras determinam o intervalo no RTP 4 podem ser sobrepostas pelas descrições de sessão que especificam parâmetros diferentes (por exemplo, para a parte da largura de 4 H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP

10 banda atribuída a RTCP para remetentes e receptores, respectivamente). Para as sessões definidas usando o protocolo da descrição da sessão (SDP) 5 aplicam-se às regras de modificação de banda do SDP para o RTCP 6. Controle de congestionamento: Aplicam-se mesmas regras básicas detalhadas dentro do RTCP. Esboço do Algoritmo As mensagens do FB são parte dos fluxos do controle de RTCP e se sujeitam assim às limitações de largura de banda de RTCP. Quer dizer, em particular, que não pode ser possível relatar um evento observado em um receptor imediatamente de volta ao remetente. Entretanto, geralmente o valor da informação de feedback dado a um remetente diminui com o tempo que ocorreu o evento em termos da qualidade da mídia como percebida pelo usuário na extremidade da recepção e/ou no custo requerido para conseguir o reparo do fluxo da mídia. RTP (Protocolo para Aplicações Real Time) e o tipo geralmente usado RTP (áudio e vídeo) especificam regras de quando aos pacotes que compõem o RTCP devem ser emitidos. O AVPF modifica as regras a fim permitir aplicações a emitir relatórios dos eventos rapidamente (por exemplo, perda ou recepção de pacotes RTP) e acomodar os algoritmos que usam mensagens do FB. O algoritmo modificado da transmissão de RTCP pode ser apresentado como segue: Tão logo nenhuma mensagem de FB tenha que ser emitida, os pacotes compostos RTCP são emitidos depois das regras RTP (Protocolo para Aplicações Real Time) -- a não ser que intervalo mínimo de cinco segundos entre relatórios RTCP não for cumprido. Então, o intervalo entre relatórios RTCP é somente derivado da média do tamanho do pacote RTCP e da parte da largura de banda de RTCP disponível à entidade RTP/RTCP. Opcionalmente, um intervalo mínimo entre pacotes regulares RTCP pode ser imposto. Se um receptor detectar a necessidade emitir uma mensagem de FB, pode fazer mais rápido do que o próximo intervalo de reporte regular RTCP (o qual seria programado seguindo o algoritmo regular do RTCP). A supressão do feedback é usada para evitar a implosão de feedbacks em sessões multipartes: O receptor espera por um intervalo (curto) aleatório - A Transport Protocol for Real-time Applications," RFC 3550 (STD0064), July M. Handley, V. Jacobson, and Colin Perkins, "SDP: Session Description Protocol", Internet Draft draft-ietf-mmusic-sdpnew-18.txt, June S. Casner, "SDP Bandwidth Modifiers for RTCP Bandwidth", RFC 3556, July 2003.

11 hesitando enviar, para verificar se capta uma mensagem correspondente de FB de qualquer outro receptor que relate o mesmo evento. Note que para sessões ponto-a-ponto não há nenhum atraso. Se uma mensagem correspondente de FB de um outro membro for recebida, este receptor declina de emitir a mensagem de FB e continua a seguir a programação regular da transmissão RTCP. No caso que o receptor não captou ainda uma mensagem correspondente de FB de nenhum outro membro, verifica se é habilitado a emitir o feedback adiantado. Se emitir o Feedback Adiantado é permitido, o receptor emite a mensagem de FB como a parte de um pacote mínimo composto do RTCP. A permissão de emitir o feedback adiantado depende do tipo do pacote precedente de RTCP emitido por este receptor e o tempo em que a mensagem feedback Antecipada precedente foi emitida. As mensagens do FB podem também ser emitidas enquanto parte dos pacotes completos compostos do RTCP que são transmitidos tanto pelo RTP (à exceção do segundo limite inferior a cinco segundos) em intervalos regulares. Modalidades de operação O feedback baseado no RTCP pode operar em uma de três modalidades - Figura 4: Modos de operação - como descrito a seguir. A modalidade de operação é apenas uma indicação de que um dos dois o receptor poderá, na média, relatar todos os eventos ao remetente em uma forma oportuna; a modalidade não influencia o algoritmo usado para a programação da transmissão de mensagens de FB. E, dependendo da qualidade da recepção e do estado localmente monitorado da sessão RTP, os receptores individuais poderão não (e não têm que) concordar com uma percepção comum na modalidade de operação corrente. a) Modalidade imediata do feedback: o tamanho do grupo é abaixo do Threshold do FB que é dado a cada parte receptor (largura de banda suficiente para transmitir os pacotes de feedback de RTCP) para a finalidade pretendida. Isto significa que, para cada receptor, há bastante largura de banda para relatar cada evento por meio de um pacote virtualmente "imediato" do feedback de RTCP. O Threshold do tamanho do grupo é uma função de um número de parâmetros incluído (mas não necessariamente limitando a eles): o tipo de feedback usado (por exemplo ACK versus NACK), largura de banda, de taxa de pacote, de probabilidade da perda e de distribuição do pacote, tipo de mídia, codec, e de (no pior caso ou observado) freqüência dos eventos para reporte (p.ex. frame recebido, pacote perdido). Como uma estimativa grosseira, deixe N ser o número médio dos eventos a serem relatados pelo intervalo T por um receptor, B a fração da largura de banda de RTCP para este receptor particular e R o tamanho médio do pacote RTCP, então o receptor opera na modalidade imediata do feedback durante um tempo N<=B*T/R.

12 b) Modalidade antecipada de RTCP: Nesta modalidade, o tamanho do grupo e outros parâmetros permitem não mais que cada receptor reaja a cada evento que valeria a pena (ou necessário) para relatar. Mas o feedback pode ainda ser dado suficientemente freqüentemente de modo que permita que o remetente adapte a transmissão do fluxo de mídia conforme e desse modo aumente de modo geral a qualidade do playback da mídia. Usando a notação acima, a modalidade antecipada de RTCP pode aproximadamente ser caracterizada por N > B*T/R como "um limite mais baixo". Uma estimativa para um limite superior é mais difícil. Ajustando N=1, nós obtemos para um R e um B dados o intervalo T = R/B como o intervalo médio entre os eventos a serem relatados. Esta informação pode ser usada como uma sugestão para determinar quando ou não a transmissão antecipada de pacotes de RTCP é útil. c) Modalidade regular de RTCP: De muitos grupos de tamanho elevados, não é útil mais fornecer o feedback para eventos individuais dos receptores para todos -- por causa da escala de tempo em que o feedback poderia ser fornecido e/ou porque em grupos grandes o remetente(s) não tem nenhuma possibilidade para reagir mais ao feedback individual. (Nenhum tamanho preciso de Threshold de grupo pode ser especificado para que esta modalidade comece, mas, obviamente, este limite combina o limite superior da modalidade antecipada de RTCP como especificado no item b). Como o algoritmo do feedback descreveu superficialmente, não há nenhuma necessidade para um acordo entre os participantes sobre valores precisos dos respectivos Threshold de FB dentro do grupo. Daqui as margens entre todas estas modalidades são sutis.

13 ACK feedback V :< NACK feedback >// : : Immediate : Feedback mode Early RTCP mode Regular RTCP mode :<=============> <=============>//<=================> : // > group size 2 Application-specific FB Threshold = f(data rate, packet loss, codec,...) Figura 4: Modos de operação Como indicado antes, os respectivos Threshold de FB dependem de um número de parâmetros técnicos (do codec, do transporte, do tipo de feedback usado, etc..) mas também nos respectivos cenários da aplicação. 3.3 Considerações Gerais Antes mesmo de considerar ou não emitir a informação do feedback de RTCP uma aplicação tem que determinar se este mecanismo é aplicável: 1) uma aplicação tem que se decidir se -- para a relação atual da taxa do pacote com o atraso máximo feedback associado (específico da aplicação) e o tempo round-trip(rtt) atualmente observado (se disponível) -- os mecanismos do feedback podem ser aplicados para todos. Esta decisão pode ser baseada (e dinamicamente ser revisada seguindo) em estatísticas da recepção do RTCP tanto quanto mecanismos out-of-band. 2) a aplicação tem que se decidir -- para uma determinada taxa de erro observado, atribuído a largura de banda, a taxa de frame/pacote e tamanho do grupo -- se (e quais) mecanismos do feedback podem ser aplicados. A estatística da recepção de RTCP regular fornece um valioso input para esta etapa.

14 3) se a aplicação decidir emitir o feedback, a aplicação tem que seguir as regras para transmitir os pacotes adiantados RTCP ou os pacotes regulares RTCP que contêm mensagens de FB. 4) o tipo de feedback de RTCP emitido não deve duplicar a informação disponível ao remetente de um protocolo de transporte de camada mais baixa. Isto é, se o protocolo do transporte fornecer reconhecimentos negativo ou positivo sobre a recepção do pacote (tal como DCCP - Datagram Congestion Control Protocol), o receptor deve evitar repetir a mesma informação na camada de RTCP (isto é abster-se de emitir NACKs genérico). 4. ILBC Descreve como a voz comprimida pelo codec ilbc, pode ser formatado para o uso como um tipo do payload RTP. Os métodos são fornecidos para empacotar os frames de dados do codec em pacotes RTP. O remetente pode emitir um ou mais frames de dados do codec por pacote, dependendo do cenário da aplicação ou baseado na condição da rede de transporte, limitação da largura de Banda, quesitos de atraso e tolerância a perda de pacote. 4.1 Fundamentos O Global IP Sound (GIPS) desenvolveu um algoritmo da compressão de voz para o uso nas comunicações IP. O codec do ilbc permite a degradação suave da qualidade do voz no caso de frames perdidos, que ocorre em relação aos pacotes perdidos ou atrasados do IP. Este codec é apropriado para comunicações real time como, o telefonia e vídeo conferência, streaming de áudio, arquivamento e mensagens. O codec ilbc é um algoritmo que comprime cada frame básico (20 ms ou 30 ms) de 8000 hertz, amostra de 16-bit de entrada voz, em frames da saída com taxa de 400 bits para o tamanho básico do frame de 30 ms e de 304 bits para o tamanho básico do frame de 20 ms. O codec suporta dois comprimentos básicos do frame: 30 ms em kbit/s e 20 em 15.2 kbit/s, usando um algoritmo linear-preditivo independente de codificação de bloco (LPC). Quando o codec opera em comprimentos do bloco de 20 ms, produz 304 bits por bloco, que deve ser empacotado em 38 bytes. Do mesmo modo, para comprimentos de bloco de 30 ms produz 400 bits por bloco, que deve ser empacotado em 50 bytes. Este algoritmo resulta em um sistema de codificação de voz com uma resposta controlada às perdas de pacotes, similar a conhecida PCM com algoritmo de cancelamento de perda do pacote (PLC), como o padrão de ITU-T G.711, que opera em uma taxa de bit fixa de 64 kbit/s. Ao mesmo tempo, este algoritmo permite codificação fixa da taxa de bits com uma relação taxa de qualidade vs. taxa de bit próxima da obtida pela CELP.

15 4.2 Formato do Payload RTP O codec ilbc usa frames de 20 ou 30 ms do e uma taxa de amostragem de relógio de 8 khz, assim o timestamp RTP deve estar em unidades de 1/8000 por segundo. O payload RTP para o ilbc tem o formato mostrado na figura 4. Nenhum cabeçalho específico é adicionado a este formato de payload. Este formato foi concebido para as situações onde o remetente e o receptor emitem um ou mais frames do codec de dados por pacote RTP Header [3] +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + one or more frames of ilbc [1] Figure 5, Diagrama de Formato de pacote. O cabeçalho RTP do pacote de voz codificado do ilbc tem os valores previstos como descritos dentro do RTP. O uso do bit de M deve ser como especificado no tipo aplicável de RTP. Para o exemplo, RFC 3551 especifica se o remetente não suprimir o silêncio (isto é, emite um frame em cada intervalo do frame), o bit de M será sempre zero. Quando mais um frame de dados do codec está presente em um único pacote RTP, o timestamp é, como sempre, o frame o mais antigo dos dados representado no pacote RTP. 4.3 Definição de Bitstream Como dito anteriormente, o número total de bits usados para descrever um frame de voz de 20 ms é 304, que cabe em 38 bytes e resulta em uma taxa de bit de kbit/s. Para o caso com um comprimento do frame de um voz de 30 ms o número total dos bits usados é 400, que cabe em 50 bytes e resulta em uma taxa de bit de kbit/s. Na definição do bitstream, os bits são distribuídos em três classes de acordo com sua sensibilidade de erro da perda de bit. Os mais sensíveis bits (a classe 1) são colocados primeiro dentro do bitstream para cada frame. Os bits menos sensíveis (a classe 2) são colocados após os bits da classe 1. Os bits menos sensíveis de todos (a classe 3) são colocados na extremidade do bitstream para cada frame.

16 Verificando os casos de comprimento de frame de 20/30 ms para cada classe: Os bits da classe 1 ocupam um total de 6/8 bytes (48/64 bits), os bits da classe 2 que ocupam os 8/12 bytes (64/96 dos bits), e os bits da classe 3 ocupam os 24/30 bytes (191/239 bits). Esta distribuição dos bits permite o uso da proteção nivelada desigual (ULP). A alocação detalhada de bit é mostrada na tabela 1 (em anexo). Quando um índice de quantização é distribuído entre mais classes os bits mais significativos pertencem a classe mais baixa. Quando empacotamos no payload, todos os bits da classe 1 têm que ser ordenados de modo (de cima para baixo) como foi especificado na tabela. Adicionalmente, todos os bits da classe 2 têm que ser ordenados (de cima para baixo) e todos bits da classe 3 têm que ser ordenados na mesma ordem seqüencial. 4.4 Frames múltiplos do ilbc em um pacote RTP Mais de um frame do ilbc pode ser incluído em um único pacote RTP por um remetente. É importante observar que os remetentes têm as seguintes limitações adicionais: - Não devem incluir mais frames ilbc em um único pacote RTP do que caberá na MTU do protocolo do transporte RTP. - os quadros não devem ser quebrados entre pacotes RTP. - os quadros de diferentes modalidades (20 ms e 30 ms) não devem ser incluídos dentro do mesmo pacote. É recomendado que o número de frames contidos dentro de um pacote RTP seja consistente com a aplicação. Por exemplo, em telefonia e em outras aplicações de tempo real onde o atraso é importante, o atraso é baixo dependendo da quantidade de frames por pacote (isto é, poucos frames por pacote, menor é o atraso). Visto que para links com largura de banda limitada ou aplicação de fluxo de mensagem não sensíveis a atraso, um ou o mais frames por pacote seria aceitável. A informação que descreve o número dos frames contidos em um pacote RTP não é transmitida como uma parte do payload RTP. A maneira determinar o número de frames ilbc é contar o número total dos octetos dentro do pacote RTP, e dividir a contagem de octetos pelo número de octetos previstos por frame (32/50 por frame). Quando empacotado no payload, todos os bits da classe 1 DEVEM ser classificados em ordem (do alto e para baixo) como foram especificados na tabela. Adicionalmente, todos os bits da classe 2 DEVEM ser classificados (do alto e para baixo) e todos os bits da classe 3 DEVEM ser classificados na mesma ordem seqüencial.

17 4.5 Modalidade de Armazenamento A modalidade do armazenamento é usada armazenando frames de voz (por exemplo, como padronizado para um arquivo ou o anexo do ) Header Speech frame : : Speech frame n Figure 6- Diagrama de formato de memória A arquivo começa com um cabeçalho que inclui somente um número mágico para identificar que é um arquivo do ilbc. O número mágico para o arquivo do ilbc deve corresponder ao string de caracteres ASCII: - para o tamanho do frame de modo 30 ms:"#!ilbc30\n ", ou "0x23 0x21 0x69 0x4C 0x42 0x43 0x33 0x30 0x0A" no formato hexadecimal, - para o tamanho do frame de modo 20 ms:"#!ilbc20\n ", ou "0x23 0x21 0x69 0x4C 0x42 0x43 0x32 0x30 0x0A" no formato hexadecimal. Após o cabeçalho, seguem os frames do voz na ordem consecutiva. Os frames do voz perdidos na transmissão devem ser armazenados como "frames vazios", como definidos dentro do RTP. Devido ao seu uso e robustez em 2002 o IETF 7 se tornou IBLC um padrão e atualmente o AVT esta terminando seu processo de especificação. 5. Conclusão Este trabalho mostrou que o SRTP com seu formato de cabeçalho reduzido, baixo custo computacional e tratamento de autenticação e criptografia, mostrou ser uma proteção apropriada para o RTP e RTCP em ambientes heterogêneos (Redes wired and wireless); 7 [Site IETF] - (grupo avt)

18 que AVPF com o conceito de feedback antecipado, pode aumentar a qualidade percebida pelo usuário pois permite ao transmissor receber informações de eventos de transmissão mais rapidamente que o originalmente previsto no RTCP; que o payload criado para dados codificados pelo codec ilbc serve de suporte a inúmeras aplicações hoje amplamente difundidas como a telefonia sobre Internet. Os projetos desenvolvidos pelo Grupo AVT têm como objetivo desenvolver nos protocolos RTP / RTCP, na medida da necessidade, novos formatos de payload para novos codecs de mídia projetando-as usando as melhores práticas. Índice de Figuras Figura 1- Cabeçalho SRTP...3 Figura 2 - Remetente...4 Figura 3 - Receptor...5 Figura 4 - Modos de operação...13 Figure 5 - Diagrama de Formato de pacote Figure 6 - Diagrama de formato de memória...17 Referencias [RFC 3551]. Schulzrinne and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control," (STD0065), July [RFC 1889/3550]: Internet Low Bit Rate Codec (ilbc) [RFC 3952] RTP: Payload Format for internet Low Bit Rate Codec (ilbc) Speech [RFC 1889/3550] RTP: A transport Protocol for Real-Time Applications IETF Network Group; [RFC 3711] SRTP: The Secure Real-time Transport Protocol (SRTP) [Site IETF] - (grupo avt)

19 Bitstream structure: ANEXO Parameter Bits Class <1,2,3> 20 ms frame 30 ms frame Split 1 6 <6,0,0> 6 <6,0,0> LSF 1 Split 2 7 <7,0,0> 7 <7,0,0> LSF Split 3 7 <7,0,0> 7 <7,0,0> Split 1 NA (Not Appl.) 6 <6,0,0> LSF 2 Split 2 NA 7 <7,0,0> Split 3 NA 7 <7,0,0> Sum 20 <20,0,0> 40 <40,0,0> Block Class. 2 <2,0,0> 3 <3,0,0> Position 22 sample segment 1 <1,0,0> 1 <1,0,0> Scale Factor State Coder 6 <6,0,0> 6 <6,0,0> Sample 0 3 <0,1,2> 3 <0,1,2> Quantized Sample 1 3 <0,1,2> 3 <0,1,2> Residual : : : : : State : : : : : Samples : : : : : Sample 56 3 <0,1,2> 3 <0,1,2> Sample 57 NA 3 <0,1,2> Sum 171 <0,57,114> 174 <0,58,116> Stage 1 7 <6,0,1> 7 <4,2,1>

20 CB for 22/23 Stage 2 7 <0,0,7> 7 <0,0,7> sample block Stage 3 7 <0,0,7> 7 <0,0,7> Sum 21 <6,0,15> 21 <4,2,15> Stage 1 5 <2,0,3> 5 <1,1,3> Gain for 22/23 Stage 2 4 <1,1,2> 4 <1,1,2> sample block Stage 3 3 <0,0,3> 3 <0,0,3> Sum 12 <3,1,8> 12 <2,2,8> Stage 1 8 <7,0,1> 8 <6,1,1> sub-block 1 Stage 2 7 <0,0,7> 7 <0,0,7> Stage 3 7 <0,0,7> 7 <0,0,7> Stage 1 8 <0,0,8> 8 <0,7,1> sub-block 2 Stage 2 8 <0,0,8> 8 <0,0,8> Indices Stage 3 8 <0,0,8> 8 <0,0,8> for CB sub-blocks Stage 1 NA 8 <0,7,1> sub-block 3 Stage 2 NA 8 <0,0,8> Stage 3 NA 8 <0,0,8> Stage 1 NA 8 <0,7,1> sub-block 4 Stage 2 NA 8 <0,0,8> Stage 3 NA 8 <0,0,8> Sum 46 <7,0,39> 94 <6,22,66> Stage 1 5 <1,2,2> 5 <1,2,2> sub-block 1 Stage 2 4 <1,1,2> 4 <1,2,1> Stage 3 3 <0,0,3> 3 <0,0,3> Stage 1 5 <1,1,3> 5 <0,2,3> sub-block 2 Stage 2 4 <0,2,2> 4 <0,2,2> Stage 3 3 <0,0,3> 3 <0,0,3> Gains for

21 sub-blocks Stage 1 NA 5 <0,1,4> sub-block 3 Stage 2 NA 4 <0,1,3> Stage 3 NA 3 <0,0,3> Stage 1 NA 5 <0,1,4> sub-block 4 Stage 2 NA 4 <0,1,3> Stage 3 NA 3 <0,0,3> Sum 24 <3,6,15> 48 <2,12,34> Empty frame indicator 1 <0,0,1> 1 <0,0,1> SUM 304 <48,64,192> 400 <64,96,240> Tabela 1 The bitstream definition for ilbc.