Войти
G.726 - это ITU-T ADPCM речевой кодек стандарт, охватывающий передачу голоса со скоростью 16, 24, 32 и 40 кбит / с. Он был введен вместо G.721, который охватывал ADPCM на 32 кбит / с, и G.723, который описывал ADPCM на 24 и 40 кбит / с. G.726 также представил новую скорость 16 кбит / с. Четыре скорости передачи, связанные с G.726, часто упоминаются размером в битах выборки, которые составляют 2, 3, 4 и 5 битов соответственно. Соответствующий широкополосный кодек, основанный на той же технологии, - G.722.
. Наиболее часто используемый режим - 32 кбит / с, что удваивает полезную пропускную способность сети за счет использования вдвое меньшей скорости G.711.. Он в основном используется в международных соединительных линиях в телефонной сети и является стандартным кодеком, используемым в беспроводных телефонных системах DECT. Основное применение каналов со скоростью 24 и 16 кбит / с - это перегрузка каналов, несущих голос, в оборудовании умножения цифровых цепей (DCME) . Основное применение каналов 40 кбит / с заключается в передаче сигналов модема данных в DCME, особенно для модемов , работающих со скоростью более 4800 бит / с.
G.721 был представлен в 1984, тогда как G.723 был представлен в 1988 году. Они были свернуты в G.726 в 1990 году.
G.727 был представлен одновременно с G.726 и включает в себя такая же скорость передачи данных, но оптимизирована для среды (PCME). Это достигается путем встраивания 2-битного квантователя в 3-битный квантователь и то же самое для более высоких режимов. Это позволяет отбрасывать младший значащий бит из потока битов без отрицательного воздействия на речевой сигнал.
Поскольку порядок байтов для протоколов данных в контексте Интернета был обычно определяется как прямой порядок байтов и называется просто сетевым порядком байтов, как указано (среди прочего) в устаревшем RFC 1700, устаревший RFC 1890 не определял явно порядок байтов предшественника G.726, G.721, также в RTP. Вместо этого в устаревшем RFC 1890 для всех упомянутых кодеков в общем случае снова было указано использование прямого порядка байтов в термине сетевой порядок байтов:
«Для многооктетных кодировок октеты передаются в сетевой порядок байтов (т. е. наиболее значимый октет первым). ". - IETF, устаревший RFC 1890, раздел 4.2
Тип полезной нагрузки для G.721 был определен устаревшим RFC 1890 как 2, поэтому a = rtpmap: 2 G721 / 8000. В черновиках новой версии этого RFC он был повторно использован для G.726, т.е. a = rtpmap: 2 G726-32 / 8000.
В отличие от этого ITU явно определил порядок байтов в своих рекомендациях относительно G. 726 или соответственно ADPCM, но двумя разными способами. В Рекомендации X.420 указано, что он должен быть прямым порядком байтов, в соответствии с рекомендацией I.366.2 Приложение E он должен быть прямым порядком байтов. Это привело к противоречивым решениям в различных реализациях, поскольку некоторые производители выбрали прямой порядок байтов, а другие - большой. Следствием этого было то, что эти реализации были несовместимы, поскольку декодирование с использованием неправильного порядка байтов приводит к сильно искаженному звуковому сигналу. Поэтому нечеткое определение было исправлено в RFC 3551, который заменяет RFC 1890. Раздел 4.5.4 в RFC 3551 определяет классические MIME-типы G726-16, 24, 32 и 40 как little endian и вводит новые типы MIME для bis endian, которыми являются AAL2-G726-16, 24, 32 и 40. Тип полезной нагрузки был изменен на динамический, чтобы избежать путаницы. Вместо полезной нагрузки типа 2 должна использоваться динамическая полезная нагрузка в диапазоне от 96 до 127:
«Обратите внимание, что в направлении« little-endian »выборки упаковываются в октеты в G726-16, -24, -32 Указанные здесь форматы полезной нагрузки и -40 соответствуют Рекомендации МСЭ-Т X.420, но являются противоположностью тому, что указано в Приложении E Рекомендации МСЭ-Т I.366.2 для транспорта AAL2 ATM. Второй набор форматов полезной нагрузки RTP, соответствующий пакетирование согласно Приложению E I.366.2 и идентифицированное подтипами MIME AAL2-G726-16, -24, -32 и -40 будет определено в отдельном документе. ". - IETF, RFC 3551, раздел 4.5. 4
"Тип полезной нагрузки 2 был назначен G721 в RFC 1890 и его эквивалентному преемнику G726-32 в черновых версиях этой спецификации, но его использование теперь не рекомендуется, и этот статический тип полезной нагрузки помечен как зарезервированный из-за конфликтующего использования форматов полезной нагрузки G726-32 и AAL2-G726-32 (см. раздел 4.5.4) «. - IETF, RFC 3551, раздел 6
| little endian. (X. 420 и RFC 3551 ) | big endian. (I.366.2 Приложение E и RFC 3551 ) | устарело RFC 1890 |
|---|---|---|
G726-16 a = rtpmap: {от 96 до 127} G726 -16/8000 | AAL2-G726-16 a = rtpmap: {от 96 до 127} AAL2-G726-16 / 8000 | a = rtpmap: 2 G726-16 / 8000 |
G726- 24 a = rtpmap: {от 96 до 127} G726-24 / 8000 | AAL2-G726-24 a = rtpmap: {от 96 до 127} AAL2-G726-24 / 8000 | a = rtpmap: 2 G726-24 / 8000 |
G726-32 a = rtpmap: {от 96 до 127} G726-32 / 8000 | AAL2-G726-32 a = rtpmap: { от 96 до 127} AAL2-G726-32 / 8000 | a = rtpmap: 2 G726-32 / 8000 |
G726-40 a = rtpmap: {от 96 до 127} G726-40 / 8000 | AAL2-G726-40 a = rtpmap: {от 96 до 127} AAL2-G726-40 / 8000 | a = rtpmap: 2 G726-40 / 8000 |
Более новые реализации учитывают RFC 3551 и четко различаются между G726-xx (прямой порядок байтов) и AAL2-G726-xx (прямой порядок байтов). Телефон Gigaset C610 IP DECT, например, генерирует следующий код в своем SIP INVITE:
a = rtpmap: 96 G726-32 / 8000→ тип динамической полезной нагрузки 96 и G.726 в соответствии с X.420, таким образом с прямым порядком байтов, как определено в RFC 3551. a = rtpmap: 97 AAL2-G726-32 / 8000→ тип динамической полезной нагрузки 97 и G.726 в соответствии с I.366.2 Приложение E, таким образом, с прямым порядком байтов, как определено в RFC 3551. a = rtpmap: 2 G726-32 / 8000→ статическая полезная нагрузка типа 2 и G.726 с непредсказуемым порядком байтов, как G.721 в соответствии с устаревшим RFC 1890
