Tutorial de Qualidade de Serviço (QOS - Video Quality of Service)

Introduction

Este documento revisa o assunto da qualidade da chamada de vídeo e fornece um tutorial sobre as coisas a serem lembradas enquanto a Qualidade de Serviço (QoS) está configurada em um Cisco Unified Border Element(CUBE) ou em um gateway de Multiplexação por Divisão de Tempo (TDM).

Contribuído por Baktha Muralidharan, engenheiro do TAC da Cisco, editado por Anoop Kumar.

Prerequisites

Requirements

Este documento é mais benéfico para os engenheiros familiarizados com voz sobre IP (VoIP), embora outros possam considerá-lo útil.

Componentes Utilizados

Não há hardware ou software específico usado para gravar este documento.

Informações de Apoio

O áudio digitalizado em sua forma mais simples é um conjunto de amostras de áudio, cada uma descrevendo a pressão sonora durante esse período.  O áudio de conversação pode ser capturado e reproduzido com um alto grau de precisão, com apenas 8000 amostras por segundo[1].  Isso significa que, enquanto a rede for capaz de transportar as amostras sem atraso excessivo, instabilidade e perda de pacotes, o áudio poderá ser reproduzido fielmente na outra extremidade.

Em contrapartida, a apresentação, o processamento e o transporte de vídeo são muito mais complexos. Brilho, contraste, saturação de cor, agilidade (para movimento) e sincronização labial são apenas alguns dos atributos que determinam a qualidade do vídeo. As amostras de vídeo geralmente exigem um espaço muito maior. Não é de se surpreender que o vídeo coloque uma demanda muito maior na largura de banda da rede, na rede de transporte. A qualidade do áudio é determinada por: Microphone Speaker (Alto-falante de microfone) no headset Codec - a qualidade da chamada de vídeo da rede de transporte de compactação é afetada por: Dispositivo de vídeo Codec de vídeo Compatibilidade/Interoperabilidade de rede de transporte

Observação: é importante entender que, ao contrário do áudio, um pouco se passa em endpoints de vídeo quando se trata de qualidade de ajuste.

Objetivo

A QoS em geral é um assunto vasto e complexo que requer consideração dos requisitos gerais de tráfego (em vez de apenas o tráfego que você deseja melhorar a qualidade do tráfego) e precisa ser verificado em cada componente da rede ao longo do caminho do fluxo de mídia. Alcançar a qualidade de vídeo em uma videoconferência é ainda mais complexo, pois envolve, além dos componentes de rede, revisão e exame da configuração e ajuste nos endpoints. Em termos gerais, a qualidade do vídeo implica o seguinte:

• Ajuste de ponto final- Otimização da configuração de endpoints (por exemplo, resolução, quadro por segundo)
• Otimização de transporte - Otimizando a rede para transportar o tráfego de vídeo por SLA de rede.
• Considerações sobre interoperabilidade - As chamadas de vídeo envolvem frequentemente endpoints de vários recursos. Projetar e configurar os sistemas para maximizar a interoperabilidade pode afetar a qualidade do vídeo.

O foco específico neste documento serão as considerações de QoS no gateway do IOS ou no CUBE ao tratar chamadas de vídeo.

O ajuste nos endpoints envolveria o ajuste de um conjunto de parâmetros nos endpoints de vídeo. Isso, claro, depende do produto, mas aqui estão alguns "botões" gerais:

• Resolução (ou seja, tamanho da imagem)
• Taxa de quadros (ou seja, sensibilidade do movimento/realidade)
• Marcação (isto é, marcação ToS)

O ajuste da rede para vídeo geralmente envolve o seguinte:

• Entendendo a composição do tráfego que flui através do CUBE - por exemplo, pico [call] volume etc.
• Revisando a capacidade do link/pipe da rede
• Projetar políticas de QoS apropriadas para garantir que o SLA seja atendido para cada classe de tráfego

A interoperabilidade entra em ação quando sistemas heterogêneos (telefonia de vídeo e telepresença (TP) participam de uma chamada de conferência. A experiência oferecida por um sistema de telefonia TP e de vídeo é fundamentalmente diferente. A interoperabilidade entre eles é geralmente alcançada através da ligação entre eles usando um processo conhecido como cascata.

O que isso não cobre

Este não é um documento de projeto e também não é um documento de QoS de vídeo abrangente. Especificamente, este documento não aborda estes tópicos:

• Sinalização [protocolos] de chamadas de vídeo, além do necessário para ilustrar aspectos relacionados ao qos.
• Configuração/configuração do terminal de vídeo
• Revisão abrangente dos mecanismos de QoS, incluindo políticas, enfileiramento, modelagem e intermitência
• Revisão da configuração de QoS em switches de Camada 2 ou considerações de limite de confiança.

Características de tráfego de rede do vídeo

Vídeo, como o áudio é em tempo real.  As transmissões de áudio são CBR (Constant-Bit-Rate). Em contrapartida, o tráfego de vídeo tende a ser intermitente e é chamado de taxa de bits variável (VBR). Consequentemente, a taxa de bits para transmissão de vídeo não será necessariamente constante, se precisarmos manter uma certa qualidade[2].

Imagem 1

A determinação da largura de banda e a intermitência necessárias para o vídeo também estão mais envolvidas. Isso será discutido posteriormente neste documento.

• O tráfego de vídeo está intermitente.
• Os pacotes de vídeo podem ser bastante grandes.
• O áudio é sempre CBR. O vídeo é tipicamente VBR. 

Por que o vídeo está intermitente?

A resposta está na forma como o vídeo é compactado. Lembre-se de que o vídeo é uma sequência de imagens (quadros) reproduzidas para fornecer um efeito de movimento visual. As técnicas de compactação usadas pelos codecs de vídeo usam uma abordagem chamada codificação Delta[3], que funciona armazenando valores de bytes como diferenças (deltas) entre os valores sequenciais (amostras) em vez dos próprios valores. Assim, o vídeo é codificado (e transmitido) como quadros consecutivos que transportam apenas as "partes móveis" em vez de quadros inteiros.

Você provavelmente está se perguntando Por que o áudio também muda gradualmente? Bem, é verdade, mas "movimento" (ou dinâmica) não afeta o áudio tanto quanto o vídeo. Os exemplos de áudio de 8 bits não são compactados melhor quando o delta codificado, os exemplos de vídeo (quadros) são. A alteração relativa de amostra (quadro a quadro) para amostra é que o vídeo é muito menor do que o áudio. Dependendo da natureza e do grau de movimento, as amostras de vídeo podem variar muito de tamanho. A Imagem 2 ilustra a compactação de vídeo-

Imagem 2

Um I-frame é uma imagem Intra-codificada, na verdade uma imagem totalmente especificada, como um arquivo de imagem estática convencional.

Um quadro P (Imagem prevista) contém somente as alterações na imagem do quadro anterior. O codificador não precisa armazenar os pixels de fundo inalteráveis no quadro P, salvando espaço. Os quadros P também são conhecidos como quadros delta.

Um quadro B (imagem Bi-preditiva) economiza ainda mais espaço usando diferenças entre o quadro atual e os quadros anteriores e seguintes para especificar seu conteúdo.

Medição da qualidade do vídeo

Os equipamentos de vídeo da Cisco não medem ou relatam a qualidade do vídeo como tal, portanto, a qualidade do vídeo é percebida em vez de medida. Existem algoritmos padronizados que medem a qualidade por meio de um MOS (Mean Opinion Score). No entanto, se os problemas relatados na qualidade de áudio forem uma indicação, os casos de qualidade de vídeo (TAC) serão mais prováveis de serem abertos porque o usuário percebeu problemas de qualidade em vez de relatórios por uma ferramenta.

Controles em endpoints

Os fatores que afetam a qualidade do vídeo incluem:

• o codec de vídeo (MPEG4, H261, H263, H264 e H265)
• tamanho (tela 1/8, tela 1/4, tela inteira)
• taxa de quadros (1 a 30 quadros por segundo, 6 padrão)
• a configuração de qualidade de compactação (baixa, média, alta)

Geralmente, cada um dos itens acima é selecionável/controlável em endpoints.

Artefatos visíveis

A filtragem, a composição e a marca se acostumam com estes termos, parte da taxonomia de comprometimento de vídeo. Consulte este documento para obter detalhes sobre os defeitos de vídeo comuns:

Referência: 

http://www.estadistica.cl/public_disk/Programas/DeTodo/Manejo y pegado de subtitulos/VirtualDub-1.6.14/help/p-artifacts.html

  

SLAs de rede de transporte para qualidade de vídeo

O SLA de rede recomendado para vídeo[4] é o seguinte:

• Latência ≤ 150-300 ms
• Instabilidade ≤ 10 ms-50 ms
• Perda ≤ 0,5%

A propósito, o SLA de rede recomendado para transportar áudio é:

• Latência ≤ 150-300 ms
• Instabilidade ≤ 20 ms-50 ms
• Perda ≤ 1%

Observação: o vídeo é mais sensível à perda de pacotes do que à voz.  Isso deve ser esperado quando você entender que os quadros interframes exigem informações de quadros anteriores, o que significa que a perda de quadros interframes pode ser devastadora para o processo de reconstrução da imagem de vídeo.

Controlos na rede de transporte

Geralmente, o SLA para transporte de vídeo pode ser fornecido usando políticas de QoS muito semelhantes às usadas para transporte de áudio. No entanto, há algumas diferenças devido à natureza do tráfego de vídeo.

  

Observação: embora o escopo deste documento seja limitado ao componente CUBE, lembre-se de que QoS é de ponta a ponta.

Variantes de vídeo

Todos os vídeos são iguais? Bem, não exatamente. As variações do vídeo como um meio incluem:

• Telefonia por vídeo/videoconferência
• Interativo em tempo real
• Largura de banda relativamente mais baixa. Até aproximadamente 1 Mbps
• TelePresence
• Interativo em tempo real
• Experiência imersiva
• Requer largura de banda muito alta
• Transmissão
• Em tempo real, unidirecional
• Pode ser unicast ou multicast
• Alta largura de banda
• Sem sensibilidade para retardo (o vídeo pode levar vários segundos para ser colocado na fila)
• Largamente insensível ao jitter (devido ao buffer de aplicativos)
• A perda não deve ser superior a 5%.
• A latência não deve ser superior a 4 a 5 segundos (dependendo dos recursos de buffer do aplicativo de vídeo)
• Alguns vídeos (por exemplo, entretenimento) podem ser considerados para o serviço Scavenger.

Observação: por uma questão de brevidade, as ilustrações não são fornecidas extensivamente para cada tipo de vídeo listado acima.

Codecs de tráfego de vídeo

• • H.261- Codec foi originalmente projetado para transmissão através de linhas ISDN. Com o uso de vinculação de vídeo, as taxas de bits de vídeo são múltiplos de 64 Kbit/s.
  • H.263 - Codec é usado em videoconferência baseada em IP, bem como em redes ISDN. O H.263 requer metade da largura de banda para alcançar a mesma qualidade de vídeo do H.261. Como resultado, o H.263 substituiu em grande parte o H.261. O H.263 foi otimizado para uma grande faixa de taxas de bits e não apenas 64K bits/s como o H.261.
  • H.264/MPEG-4 - Cs atualmente um dos formatos mais usados e usa metade ou menos da taxa de bits de MPEG-2, H.263 ou MPEG-4 Parte 2.
  • H265 - Um dos vários sucessores potenciais do H.264 amplamente utilizado e baseado na extensão dos mesmos conceitos. Suporta resoluções de até 8192×4320, incluindo 8K UHD.

Observação: o vídeo, assim como o áudio, é transportado no Protocolo de Tempo Real (RTP)

Mecanismos de QoS para vídeo

Em princípio, os mecanismos de QoS empregados para fornecer os SLAs para uma rede de transporte de vídeo são basicamente os mesmos para áudio. No entanto, há algumas diferenças, principalmente devido à natureza intermitente da transmissão de vídeo e VBR.

Há duas abordagens de QoS, nomeadamente Interated Services (intserv) e Differentiated Services (diffserv).

Pense no Intserv como operando no nível de sinalização e no diffserv no nível de mídia. Em outras palavras, o modelo intserv garante qualidade operando no plano de controle. o diffserv visa garantir a qualidade operando a nível do plano de data.

Na arquitetura IntServ, os dispositivos de rede solicitam reservas de largura de banda estática e mantêm o estado de todos os fluxos reservados enquanto executam serviços de classificação, marcação e enfileiramento desses fluxos; a arquitetura do IntServ opera-e integra-se, tanto o plano de controle quanto o plano de dados, e como tal foi largamente abandonada devido às limitações de dimensionamento inerentes. O protocolo usado para fazer as reservas de largura de banda é o RSVP (Resource Reservation Protocol).

Há também o modelo IntServ/DiffServ, que é uma mistura. Esse modelo separa as operações do plano de controle das operações do plano de dados. A operação de RSVP é limitada apenas ao controle de admissão; com mecanismos de DiffServ tratando operações de classificação, marcação, vigilância e agendamento. Como tal, o modelo IntServ/DiffServ é altamente escalável e flexível.

Observação: este documento focaliza apenas na abordagem diffserv (esquema de priorização viz-a-viz, LLQ).

Garantia de largura de banda

A largura de banda é obviamente o parâmetro qos mais fundamental.  Isso depende de vários parâmetros, principalmente:

• Codec usado
• Taxa de quadros
• Tamanho da imagem
• Volume da chamada (pico e média)

O velho truque de jogar largura de banda no problema nem sempre é a solução. Isso é especialmente verdadeiro para a qualidade do vídeo. Por exemplo, com o CUVA (Cisco Unified Video Advantage), não há mecanismo de sincronização entre os dois dispositivos (telefone e PC) envolvidos. Assim, a QoS deve ser configurada para minimizar o jitter, a latência, os pacotes fragmentados e os pacotes fora de ordem.

Observação: o Vídeo Interativo tem os mesmos requisitos de nível de serviço do VoIP porque uma chamada de voz está incorporada ao fluxo de vídeo.O Vídeo de Transmissão em Fluxo tem requisitos muito mais laxistas, devido à grande quantidade de buffering que foi incorporada aos aplicativos.

Finalmente, é importante entender que, ao contrário do VoIP, não há fórmulas limpas para calcular a largura de banda incremental necessária. Isso ocorre porque os tamanhos dos pacotes de vídeo e as taxas dos pacotes variam significativamente e são em grande parte uma função do grau de movimento nas imagens de vídeo transmitidas. Mais sobre isso depois.

Enfileiramento

LLQ (Low Latency Queuing, Enfileiramento de baixa latência) é a política de enfileiramento preferencial para áudio VoIP. Considerando os rigorosos requisitos sensíveis a retardo/jitter do TP e a necessidade de sincronizar áudio e vídeo para CUVA, o enfileiramento de prioridade (LLQ) é recomendado para todo o tráfego de vídeo também. Observe que, para vídeo, a largura de banda prioritária é geralmente dividida em 20% para contabilizar a sobrecarga.

Compactação de cabeçalho

Não recomendado para vídeo.

Fragmentação e intercalação de links

O LFI é um mecanismo popular para garantir que o jitter não fique fora de controle em links lentos, onde os atrasos de serialização podem ser altos.

Mas, novamente, o Interative-Video não é recomendado para links lentos. Isso ocorre porque o LLQ ao qual o tráfego de vídeo está atribuído não está sujeito à fragmentação. Isso significa que os grandes pacotes de Interative-Video (como quadros I de 1500 bytes em movimento completo) podem causar atrasos de serialização para pacotes menores de Interative-Video.

Evitando congestionamento

Descarte seletivo baseado em RTCP

Intermitência

Esse mecanismo de QoS é importante para o tráfego de vídeo, que, como mencionado anteriormente, está intermitente.

O parâmetro de intermitência opcional pode ser configurado como parte do comando priority[6].

Com o H.264, a pior explosão seria a tela inteira de vídeo (espacialmente compactado). Baseado em testes extensos em sistemas TP, descobriu-se que esse número é de 64 KB. Portanto, o parâmetro de intermitência LLQ deve ser configurado para permitir até 64 KB de intermitência por quadro por tela. Assim, o sistema CTS-1000 em execução em 1080p-Best (com o suporte opcional de um fluxo de vídeo auxiliar[7]) seria configurado com um LLQ com um parâmetro de intermitência ideal de 128 (2x64) KB.

Quanta largura de banda?

Então, quanta largura de banda é necessária para transportar uma chamada de vídeo com fidelidade? Antes de fazer os cálculos, é importante entender os seguintes conceitos, que são exclusivos do vídeo.

Resolução

Isso se refere basicamente ao tamanho da imagem.  Outros termos comumente usados para isso incluem formato de vídeo e tamanho de tela.  Os formatos de vídeo mais usados são mostrados abaixo.

Formato	Resolução de vídeo (pixels)
SQCIF	128 x 96
QCIF	176 x 144
SCIF	256 x 192
SIF	352 x 240
CIF	352 x 288
DCIF	528 x 384
4CIF	704 x 576
16CIF	1408x1152

Grande parte do equipamento de videoconferência opera nos formatos CIF ou 4CIF.

Referência: http://en.wikipedia.org/wiki/Common_Intermediate_Format

Observação: não há equivalência para resolução (vídeo) no mundo do áudio

Taxa de quadros

Isso se refere à taxa na qual um dispositivo de imagem produz imagens consecutivas exclusivas chamadas quadros. A taxa de quadros é expressa como quadros por segundo (fps).

Observação: a métrica equivalente no mundo do áudio é o tempo de amostragem. Por exemplo, 8000 para g.711ulaw.

Cálculo da largura de banda

Os cálculos de largura de banda para sistemas de telefonia por vídeo e outros sistemas de videoconferência tradicionais tendem a ser mais simples.

Como exemplo, considere uma chamada TP com resolução de 1080 x1920.  A largura de banda necessária é calculada da seguinte forma:

     2.073.600 pixels por quadro

        x3 cores por pixel

        x1 byte (8 bits) por cor

        x 30 quadros por segundo

        = 1,5 Gbps por tela. Descomprimido!

Com a compactação, uma largura de banda de 4 Mbps por tela ( > 99% comprimida) é suficiente para transportar o quadro acima!

A tabela a seguir lista algumas das combinações-

Imagem formato	Luminância pixels	Luminância linhas	Descompactado taxa de bits (Mbit/s)
			10 quadros/s		30 quadros/s
			Cinza	Cor	Cinza	Cor
SQCIF	128	96	1.0	1,5	3.0	4.4
QCIF	176	144	2.0	3.0	6.1	9.1
CIF	352	288	8.1	12.2	24.3	36.5
4CIF	704	576	32.4	48.7	97.3	146.0
16CIF	1408	1152	129.8	194.6	389.3	583.9

Observe que os cálculos acima são para uma única tela. Uma chamada TP pode envolver várias telas e, portanto, a largura de banda total para a chamada seria um múltiplo da largura de banda por tela.

Consulte https://supportforums.cisco.com/thread/311604 para obter uma boa calculadora de largura de banda para sistemas Cisco TP.

Classificando/marcando o tráfego de vídeo

Como o tráfego de vídeo é identificado/diferenciado? Uma maneira de classificar pacotes no CUBE é usando marcas de DSCP.

A tabela a seguir ilustra as marcas de DSCP por linha de base de QoS da Cisco e também RFC 4594.

Tráfego	PHB de Camada 3	DSCP de camada 3
Sinalização de chamada	CS3	24
Voz	EF	46
Videoconferência	AF41	34
TelePresence	CS4	32
Multimedia Streaming	AF31	26
Vídeo de transmissão	CS5	40

PHB - Comportamento por salto. Refere-se ao que o roteador faz em relação às funções de classificação de pacotes e condicionamento de tráfego, como medição, marcação, modelagem e vigilância.

Por padrão, antes da versão 9.0, o CUCM (Cisco Unified Call Manager) marcava todo e qualquer tráfego de vídeo (incluindo TelePresence) para AF41. A partir da versão 9.0, o CUCM pré-configura os seguintes valores de DSCP:

• Chamadas de telepresença (vídeo imersivo) no CS4 e
• Chamadas de vídeo (telefonia por vídeo IP) em AF41

Configuração

Configurar para ajustar a qualidade do áudio implica calcular a largura de banda prioritária e implementar a política LLQ em um link de WAN. Geralmente, isso se baseia no volume de chamadas antecipado e no codec de áudio usados.

Embora os princípios sejam os mesmos, a largura de banda de vídeo através de um CUBE não é tão fácil de calcular. Isso se deve a vários fatores, incluindo:

• Como se calcula a largura de banda total necessária em função de diferentes chamadas TP (fluindo pelo CUBE) que podem envolver um número diferente de telas e de diferentes resoluções?
• A natureza intermitente e o VBR
• Outra dimensão da complexidade [na computação da largura de banda] tem a ver com "chamadas de interoperabilidade"? As chamadas de interoperabilidade usam TIP. TIP significa Telepresence Interoperability Protocol (Protocolo de interoperabilidade de telepresença). O TIP é usado para multiplexar várias telas, vários fluxos de áudio, bem como uma tela de dados auxiliares em dois fluxos de RTP, um para vídeo e áudio. Ele permite sessões ponto-a-ponto e multiponto, bem como uma combinação de endpoints com várias telas e tela única. O TIP é um protocolo proprietário da Cisco. A TIP é baseada em RTCP.

Portanto, o provisionamento de largura de banda para sistemas de vídeo às vezes acontece na ordem inversa - ou seja, a quantidade de largura de banda que uma rede de transporte pode fornecer, com a política de LLQ, é determinada primeiro e, com base nisso, o endpoint é configurado. Os sistemas de vídeo de endpoint são inteligentes o suficiente para ajustar os vários parâmetros de vídeo para o tamanho do pipe! Assim, os endpoints sinalizam a chamada.

manipulação de largura de banda do CUBE

Então, como o CUBE lida com a largura de banda em sua oferta (SIP)/respostas ao sinalizar chamadas de vídeo? O CUBE preenche os campos de largura de banda de vídeo no SDP da seguinte maneira-

  1. Do atributo de largura de banda no SDP recebido. No SDP, existe um atributo de largura de banda, que tem um modificador usado para especificar a que tipo de taxa de bits o valor se refere.  O atributo tem o seguinte formato: b=<modificador>:<valor>

  2. Da largura de banda de vídeo configurada no CUBE. Por exemplo, a largura de banda máxima estimada é calculada com base nos recursos usados pelo usuário CTS e a largura de banda estimada é pré-configurada no CUBE, usando o CLI-

• <bandwidth video tias-modificfier> ou
• <bandwidth video as-modificfier>

  3. Largura de banda de vídeo padrão (384 Kbps)

O fluxo de chamada mostrado abaixo ilustra como o CUBE preenche a largura de banda em mensagens de sinalização de chamada-

Especificamente, o CUBE usa a seguinte lógica:

• Nas ofertas (para fazer chamadas), o CUBE usa a largura de banda configurada.
• Em (respostas aos EOs), o CUBE envia largura de banda cujo valor é o mínimo de configuração local e de oferta.

No nível de sessão SDP, o valor TIAS é a quantidade máxima de largura de banda necessária quando todos os fluxos de mídia declarados são usados[8].

Tipos de payload do codec de vídeo

Essa é outra área em que o vídeo difere do áudio.  Os codecs de áudio usam tipos de payload estático. Os codecs de vídeo, em contraste, usam tipos de payload RTP dinâmico, que usam o intervalo de 96 a 127.

O motivo para o uso do tipo de payload dinâmico tem a ver com a ampla aplicabilidade dos codecs de vídeo. Os codecs de vídeo têm parâmetros que fornecem ao receptor as propriedades do fluxo que será enviado. Os tipos de payload de vídeo são definidos no SDP, usando o parâmetro a=rtpmap. Além disso, o atributo "a=fmtp:" PODE ser usado para especificar parâmetros de formato. A string fmtp é opaca e apenas passa para o outro lado.

Aqui está um exemplo-

m=video 2338 RTP/AVP 97 98 99 100
c=IN IP4 192.168.90.237
b=TIAS:768000
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42800d;max-mbps=40500;max-fs=1344;max-smbps=40500
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42800d;max-mbps=40500;max-fs=1344;max-smbps=40500;packetiza tion-mode=1
a=rtpmap:99 H263-1998/90000
a=fmtp:99 custom=1024,768,4;custom=1024,576,4;custom=800,600,4;cif4=2;custom=720,480,2 ;custom=640,480,2;custom=512,288,1;cif=1;custom=352,240,1;qcif=1;maxbr=7680
a=rtpmap:100 H263/90000
a=fmtp:100 cif=1;qcif=1;maxbr=7680

Observe que os dois endpoints envolvidos em uma chamada podem usar diferentes tipos de payload para o mesmo codec. O CUBE responde a cada lado com a linha a=rtpmap recebida no outro segmento. Isso significa que o "payload assimétrico completo" da configuração é necessário para que as chamadas de vídeo funcionem.

Largura de banda L2

Ao contrário da voz, o tráfego de vídeo IP em tempo real em geral é um fluxo de taxa de bits variável e intermitente. Portanto, o vídeo, diferentemente da voz, não tem fórmulas claras para calcular a sobrecarga da rede, pois os tamanhos e as taxas dos pacotes de vídeo variam proporcionalmente ao grau de movimento na própria imagem de vídeo. Do ponto de vista de um administrador de rede, a largura de banda é sempre provisionada na Camada 2, mas a variabilidade nos tamanhos dos pacotes e a variedade de meios da Camada 2 que os pacotes podem atravessar de ponta a ponta dificultam o cálculo da largura de banda real que deve ser provisionada na Camada 2. No entanto, a regra conservadora que foi testada minuciosamente e amplamente usada é o excesso de provisionamento da largura de banda de vídeo em 20%. Isso acomoda a intermitência de 10% e a sobrecarga de rede da Camada 2 à Camada 4.

Monitorização/medição

Como mencionado anteriormente, os endpoints de vídeo não relatam um MOS como tal. No entanto, as seguintes ferramentas podem ser usadas para medir/monitorar o desempenho da rede de transporte e monitorar a qualidade do vídeo.

Vídeo de SLAs IP

Um recurso incorporado no IOS, SLAs IP (Service Level Agreements, contratos de nível de serviço) executa o monitoramento ativo do desempenho da rede. A operação de vídeo de SLAs IP difere de outras operações de SLA IP porque todo o tráfego é unidirecional, com um respondente necessário para processar os números de sequência e os datadores de hora localmente e para aguardar uma solicitação da origem antes de enviar os dados calculados de volta.

A origem envia uma solicitação ao respondente quando a operação de vídeo atual é concluída. Essa solicitação sinaliza ao respondente que nenhum pacote mais chegará e que a função do dissipador de vídeo na operação de vídeo pode ser desativada. Quando a resposta do respondente chega à origem, as estatísticas são lidas da mensagem e os campos relevantes na operação são atualizados.

O CiscoWorks IPM (IOS Performance Monitor) usa a sonda SLA IP e o MediaTrace[9] para medir o desempenho e os relatórios do tráfego do usuário.

CUBE VQM

O recurso VQM (Video Quality Monitor), disponível no CUBE, é uma excelente ferramenta para monitorar a qualidade do vídeo entre dois pontos de interesse. Os resultados são apresentados como MOS.

Isso está disponível no IOS 15.2(1)T e superior. Observe que o VQM usa recursos DSP.

Referência

• http://www.cisco.com/en/US/partner/tech/tk1077/technologies_configuration_example09186a00807ca099.shtml
• http://www.cisco.com/en/US/partner/docs/video/milticomm/h320Bonding.html
• http://www.cisco.com/en/US/docs/solutions/TelePresence_Network_Systems_1.1_DG.pdf
• http://www.cisco.com/en/US/docs/voice_ip_comm/uc_system/design/guides/videodg/qos.html
• http://www.cisco.com/en/US/docs/voice_ip_comm/uc_system/design/guides/videodg/basics.html
• SRND de telefonia por vídeo IP -
• http://www.cisco.com/en/US/tech/tk1077/technologies_configuration_example09186a0080111c1b.shtml
• http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/TP_InterOp_v2.html
• http://www.encoding.com/do_you_have_any_information_on_h.264_levels
• http://www.cisco.com/en/US/partner/tech/tk1077/technologies_configuration_example09186a0080111c1b.shtml
• http://www.watchpointvideo.com/pdf/Measuring%20Video%20Quality%20in%20Videoconferencing%20Systems.pdf
• http://www.broadcastpapers.com/whitepapers/Why_IPTV_is_different_from_IP_data_and_VoIP.pdf?CFID=25762102&CFTOKEN=60dc627518f1a19b-3F4F563D-FC97-8A61-6169D8F641750255
• http://en.wikipedia.org/wiki/Video_compression_picture_types
• http://inst.eecs.berkeley.edu/~ee290t/sp04/lectures/coding_standards.pdf
• http://www.cs.jhu.edu/~yairamir/cs667/Multimedia/compress.gif
• http://www.wireshark.org/lists/wireshark-users/201003/msg00125.html
• http://www.networkworld.com/news/tech/2002/0923tech.html
• http://www.javvin.com/protocolH263.html
• http://www.cisco.com/en/US/docs/ios-xml/ios/ipsla/configuration/12-2se/sla_video.html#GUID-29B155B6-AFC3-4F8B-AC1D-C127C9D797F0

 IniciarSeleção:0000000199 Seleção Final:0000000538