G.726
G.726 é um codec de fala baseado em Modulação por Código de Pulso Adaptivo e Diferencial (ADPCM) padronizado pela Setor de Normatização das Telecomunicações (ITU-T), capaz de transmitir sinais de voz nas taxas de 16, 24, 32 e 40 kbit/s. Foi introduzido para substituir o G.721, que cobria ADPCM em 32 kbit/s, e o G.723, que descrevia ADPCM para 24 e 40 kbit/s. O G.726 também introduziu uma nova taxa de 16 kbit/s. As quatro taxas de transferência associadas ao G.726 são frequentemente referidas pelo tamanho de bit de uma amostra, que são 2, 3, 4 e 5 bits, respectivamente. O codec de banda larga correspondente baseado na mesma tecnologia é G.722 .
O modo mais comumente utilizado é o de 32 kbit/s, que dobra a capacidade de rede utilizável usando metade da taxa do G.711. É usado principalmente em troncos internacionais na rede telefônica e é o codec padrão usado nos sistemas de telefonia sem fio DECT. A principal aplicação dos canais de 24 e 16 kbit/s é em canais de sobrecarga que transmitem voz em equipamentos de multiplicação de circuitos digitais (DCME). A principal aplicação dos canais de 40 kbit/s é transportar sinais de modem de dados no DCME, especialmente para modems que operam a mais de 4.8 kbits/s.
História
[editar | editar código-fonte]O G.726 foi introduzido em 1990 para unificar os codecs G.721 (1984) e G.723 (1988) em uma única especificação.
O G.727 foi introduzido ao mesmo tempo que o G.726 e inclui as mesmas taxas de bits, porém é otimizado para o ambientes com equipamentos multiplexadores de circuitos de pacotes (PCME).
Características
[editar | editar código-fonte]- Frequências de amostragem: 8 kHz
- Taxas de transmissão: 8, 16, 24, 32 ou 40 kbit/s
- Gera um fluxo de bits; portanto, o comprimento do quadro é determinado pelo tempo de empacotamento (geralmente 80 amostras por quadro de 10 ms)
- O atraso algorítmico típico é 0,125 ms, sem atraso antecipado
- Baseado em ADPCM
- O teste de medição perceptual da qualidade de fala (PSQM) em condições ideais produz pontuação média de opinião (MOS) de 4,30 para G.726 (32 kbit/s), comparado a 4,45 para G.711 (μ-law) [carece de fontes]
- O teste de PSQM sob estresse de rede gera pontuação média de 3,79 para G.726 (32 kbit/s), comparado a 4.13 para G.711 (μ-law)
Endianness e tipo de carga
[editar | editar código-fonte]Como a ordem de bytes para protocolos de dados no contexto da Internet era geralmente definida como big endian e denominada simplesmente ordem de bytes de rede, como declarado pela RFC 1700, a RFC 1890 não definiu explicitamente a endianidade da predecessor de G.726, G.721, no protocolo de transmissão em tempo real (RTP) também. Em vez disso, a RFC 1890 define o uso de big endian pelo termo ordem de bytes de rede foi geralmente indicado para todos os codecs mencionados novamente:
Para codificações de múltiplos octetos, estes serão transmitidos em ordem de bytes de rede (iniciando pelo octeto mais significante).Original (em inglês): For multi-octet encodings, octets are transmitted in network byte order (i.e., most significant octet first).— H. SchulzrinneIETF, RFC1890, Seção 4.2 (em inglês)
O tipo de carga para G.721 foi definido pelo RFC 1890 como 2, portanto, a=rtpmap:2 G721/8000 . Nos rascunhos da versão mais recente deste RFC, o mesmo tipo de carga foi reutilizado para o G.726, ou seja, a=rtpmap:2 G726-32/8000.
Contradições nas recomendações produzidas pela ITU para o G.726, ou para o ADPCM, resultaram em diferenças de implementação entre os vários fabricantes, pois alguns optaram por seguir a Recomendação X.420 (little endian) e outros por seguir a Recomendação I.366.2 Anexo E (big endian). Por conseqüência essas implementações eram incompatíveis, pois a decodificação usando a ordem de bytes incorreta resulta em um sinal de áudio altamente distorcido. Eventualmente, esta contradição foi removida pela RFC 3551, que substitui a RFC 1890. A Seção 4.5.4 na RFC 3551 define os tipos MIME clássicos G726-16, 24, 32 e 40 como little endian e introduz novos tipos MIME para as variações big endian, que são AAL2-G726-16, 24, 32 e 40. O tipo de carga foi alterado para dinâmico, a fim de evitar confusão. Em vez da carga útil tipo 2, deve ser utilizada uma carga dinâmica na faixa de 96 a 127:
Note que a direção onde amostras são empacotadas em octetos "little-endian" em formatos G726-16, -24, -32 e -40 são consistentes com a Recomendação ITU-T X.420, mas o oposto é especificado pela Recomendação ITU-T I.366.2 Anexo E para o transporte em ATM AAL2. Um segundo grupo de formatos de carga compatível com o empacotamento definido em I.366.2 Anexo E e identificado pelos subtipos MIMES AAL2-G726-16, -24, -32 e -40 serão especificados em um documento à parte.Original (em inglês): Note that the "little-endian" direction in which samples are packed into octets in the G726-16, -24, -32 and -40 payload formats specified here is consistent with ITU-T Recommendation X.420, but is the opposite of what is specified in ITU-T Recommendation I.366.2 Annex E for ATM AAL2 transport. A second set of RTP payload formats matching the packetization of I.366.2 Annex E and identified by MIME subtypes AAL2-G726-16, -24, -32 and -40 will be specified in a separate document.— H. SchulzrinneIETF, RFC3551, Seção 4.5.4 (em inglês)
O tipo de carga 2 foi alocado para G721 na RFC1890 e seu sucessor G726-32 em rascunhos desta especificação, mas seu uso agora é considerado obsoleto e o uso deste tipo de carga estático é agora considerado reservado, devido ao seu uso conflitante em cargas com o formato G726-32 e AAL2-G726-32 (vide Seção 4.5.4)Original (em inglês): Payload type 2 was assigned to G721 in RFC 1890 and to its equivalent successor G726-32 in draft versions of this specification, but its use is now deprecated and that static payload type is marked reserved due to conflicting use for the payload formats G726-32 and AAL2-G726-32 (see Section 4.5.4)— H. SchulzrinneIETF, RFC3551, Seção 6 (em inglês)
| little endian (X.420 e RFC 3551 ) |
big endian
(Anexo I.366.2 E e RFC 3551 ) |
RFC 1890 |
|---|---|---|
G726-16 a=rtpmap:{from 96 to 127} G726-16/8000
|
AAL2-G726-16 a=rtpmap:{from 96 to 127} AAL2-G726-16/8000
|
a=rtpmap:2 G726-16/8000
|
G726-24 a=rtpmap:{from 96 to 127} G726-24/8000
|
AAL2-G726-24 a=rtpmap:{from 96 to 127} AAL2-G726-24/8000
|
a=rtpmap:2 G726-24/8000
|
G726-32 a=rtpmap:{from 96 to 127} G726-32/8000
|
AAL2-G726-32 a=rtpmap:{from 96 to 127} AAL2-G726-32/8000
|
a=rtpmap:2 G726-32/8000
|
G726-40 a=rtpmap:{from 96 to 127} G726-40/8000
|
AAL2-G726-40 a=rtpmap:{from 96 to 127} AAL2-G726-40/8000
|
a=rtpmap:2 G726-40/8000
|
As implementações mais recentes respeitam a RFC 3551 e fazem claras distinções entre G726-xx (little endian) e AAL2-G726-xx (big endian). O telefone Gigaset C610 IP DECT, por exemplo, gera o seguinte código em seu SIP INVITE:
a=rtpmap:96 G726-32/8000 → carga útil dinâmica tipo 96 e G.726 de acordo com X.420, portanto, pouco endian, conforme definido na RFC 3551
a=rtpmap:97 AAL2-G726-32/8000 → carga dinâmica tipo 97 e G.726 de acordo com I.366.2 Anexo E, portanto, big endian, conforme definido na RFC 3551
a=rtpmap:2 G726-32/8000 → carga útil estática tipo 2 e G.726 com resistência imprevisível, como G.721 de acordo com a RFC 1890 obsoleta