Кіріспе
ITU T G.726 ұсынысы – 16, 24, 32 және 40 кбит/с жылдамдықпен дауыс беруді қамтитын ITU T ADPCM сөйлеу кодегі стандарты. Ол 32 кбит/с жылдамдықпен ADPCM-ді қамтитын G.721 және 24 және 40 кбит/с жылдамдықпен ADPCM-ді сипаттайтын G.723-ті ығыстыру үшін енгізілді. G.726 сонымен қатар 16 кбит/с жаңа жылдамдықты енгізді. G.726-ға қатысты төрт бит жылдамдығы көбінесе үлгінің биттік өлшемі ретінде аталады, олар тиісінше 2, 3, 4 және 5 бит. Осы технологияға негізделген сәйкес кең жолақты кодек – G.722. Ең көп қолданылатын режим – 32 кбит/с, ол G.711 жылдамдығының жартысын пайдалану арқылы желілік сыйымдылықты екі есеге арттырады. Ол негізінен телефон желісінің халықаралық магистральдарында қолданылады және DECT сымсыз телефон жүйелерінде қолданылатын стандартты кодек болып табылады. 24 және 16 кбит/с арналардың басты қолданысы – цифрлық схемаларды көбейту жабдығында (DCME) дауысты жеткізетін жүктеме арналары. 40 кбит/с арналардың басты қолданысы – DCME-де дерек модем сигналдарын жеткізу, әсіресе 4800 бит/с жоғары жылдамдықпен жұмыс істейтін модемдер үшін.
G.726 is an ITU T ADPCM speech codec standard covering the transmission of voice at rates of 16, 24, 32, and 40 kbit/s. It was introduced to supersede both G.721, which covered ADPCM at 32 kbit/s, and G.723, which described ADPCM for 24 and 40 kbit/s. G.726 also introduced a new 16 kbit/s rate. The four bit rates associated with G.726 are often referred to by the bit size of a sample, which are 2, 3, 4, and 5 bits respectively. The corresponding wide band codec based on the same technology is G.722. The most commonly used mode is 32 kbit/s, which doubles the usable network capacity by using half the rate of G.711. It is primarily used on international trunks in the phone network and is the standard codec used in DECT wireless phone systems. The principal application of 24 and 16 kbit/s channels is for overload channels carrying voice in digital circuit multiplication equipment (DCME). The principal application of 40 kbit/s channels is to carry data modem signals in DCME, especially for modems operating at greater than 4800 bit/s.
Тарих
G.721 1984 жылы, ал G.723 1988 жылы енгізілді. Олар 1990 жылы G.726 стандартына біріктірілді. G.727 G.726 стандартына бір уақытта енгізілді және сол бит жылдамдықтарын қолдайды, бірақ пакеттік контурлы мультиплекстеу жабдықтары (PCME) үшін оңтайландырылған. Бұл 2 биттік кванттаушыны 3 биттік кванттаушыға және жоғары режимдер үшін де солай енгізу арқылы іске асырылады. Осылайша, сөйлеу сигналына зиян келтірмей, биттік ағыннан ең кіші маңызды биттерді жоюға болады.
Жүктілік және пайдалы жүктеме түрі
Интернет контекстіндегі деректер протоколдарының байт реті әдетте үлкен эндиан ретінде анықталып, жай ғана желілік байт реті деп аталатындықтан, (басқалармен қатар) ескірген RFC 1700 мәлімдегендей, ескірген RFC 1890 RTP-де G.726 және G.721 протоколдарының алдыңғы нұсқасының эндиандығын нақты анықтаған жоқ. Оның орнына, ескірген RFC 1890-да, желілік байт реті терминінің үлкен эндианды қолдануы барлық аталған кодектер үшін қайтадан айтылды: G.721 үшін жүктеме түрі ескірген RFC 1890-да 2-ге сәйкес анықталды, сондықтан a=rtpmap:2 G721/8000. Осы RFC-нің жаңа нұсқаларының жобаларында ол G.726 үшін де қолданылды, яғни a=rtpmap:2 G726 32/8000. Осыған қарамастан, ITU G.726 немесе тиісінше ADPCM протоколдарына қатысты ұсынымдарында байт ретін екі түрлі жолмен анықтап берді. Х.420 ұсынымы кіші эндианды қолдануды, ал I.366.2 ұсынымының Е қосымшасы үлкен эндианды қолдануды талап етеді. Бұл әртүрлі жүзеге асыруларда қарама-қайшы шешімдерге әкелді, себебі кейбір өндірушілер кіші эндианды, ал басқалары үлкен эндианды таңдады. Нәтижесінде, осы жүзеге асырулар үйлесімсіз болды, өйткені дұрыс емес байт ретімен кодтау қатты бұрмаланған дыбыс сигналын тудырады. Сондықтан, бұл анық емес анықтама RFC 1890-ды алмастырған RFC 3551 арқылы түзетілді. RFC 3551-нің 4.5.4 бөлімінде G726 16, 24, 32 және 40 классикалық MIME типтері кіші эндиан ретінде анықталады және bis endian үшін жаңа MIME типтері енгізіледі, олар AAL2 G726 16, 24, 32 және 40 болып табылады. Сандардың шатасуын болдырмау үшін жүктеме түрі динамикалыққа өзгертілді.
The payload type for G.721 was defined by the deprecated RFC 1890 as 2, thus a=rtpmap:2 G721/8000. In drafts for newer version of this RFC, it was reused for G.726, i. e. a=rtpmap:2 G726 32/8000. Contrary to that the ITU explicitly defined the byte order in its recommendations regarding G.726 or respectively ADPCM, but in two different ways. Recommendation X.420 states, that it shall be little endian, respecting recommendation I.366.2 Annex E it should be big endian. This led to contradicting decisions in various implementations, as some manufacturers opted for little endian and others for big endian. The consequence was, that these implementations were incompatible, as decoding using the wrong byte order results in a heavily distorted audio signal. Therefore the unclear definition was fixed by the RFC 3551, which replaces RFC 1890. Section 4.5.4 in RFC 3551 defines the classical MIME types G726 16, 24, 32 and 40 as little endian and introduces new MIME types for bis endian, which are AAL2 G726 16, 24, 32 and 40. The payload type was changed to dynamic, in order to prevent confusion. Instead of payload type 2 a dynamic payload in the range from 96 to 127 shall be used:
little endian(X.420 and RFC 3551) big endian(I.366.2 Annex E and RFC 3551) deprecated 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
Newer implementations respect the RFC 3551 and clearly distinct between G726 xx (little endian) and AAL2 G726 xx (big endian). The Gigaset C610 IP DECT phone, e. g., generates the following code in its SIP INVITE:
a=rtpmap:96 G726 32/8000 → dynamic payload type 96 and G.726 according to X.420, thus little endian, as defined in RFC 3551
a=rtpmap:97 AAL2 G726 32/8000 → dynamic payload type 97 and G.726 according to I.366.2 Annex E, thus big endian, as defined in RFC 3551
a=rtpmap:2 G726 32/8000 → static payload type 2 and G.726 with unpredictable endianness, like G.721 according to the deprecated RFC 1890
Мысалы, Gigaset C610 IP DECT телефоны өзінің SIP INVITE хабарламасында келесі кодты жасайды:
The payload type for G.721 was defined by the deprecated RFC 1890 as 2, thus a=rtpmap:2 G721/8000. In drafts for newer version of this RFC, it was reused for G.726, i. e. a=rtpmap:2 G726 32/8000. Contrary to that the ITU explicitly defined the byte order in its recommendations regarding G.726 or respectively ADPCM, but in two different ways. Recommendation X.420 states, that it shall be little endian, respecting recommendation I.366.2 Annex E it should be big endian. This led to contradicting decisions in various implementations, as some manufacturers opted for little endian and others for big endian. The consequence was, that these implementations were incompatible, as decoding using the wrong byte order results in a heavily distorted audio signal. Therefore the unclear definition was fixed by the RFC 3551, which replaces RFC 1890. Section 4.5.4 in RFC 3551 defines the classical MIME types G726 16, 24, 32 and 40 as little endian and introduces new MIME types for bis endian, which are AAL2 G726 16, 24, 32 and 40. The payload type was changed to dynamic, in order to prevent confusion. Instead of payload type 2 a dynamic payload in the range from 96 to 127 shall be used:
little endian(X.420 and RFC 3551) big endian(I.366.2 Annex E and RFC 3551) deprecated 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
Newer implementations respect the RFC 3551 and clearly distinct between G726 xx (little endian) and AAL2 G726 xx (big endian). The Gigaset C610 IP DECT phone, e. g., generates the following code in its SIP INVITE:
a=rtpmap:96 G726 32/8000 → dynamic payload type 96 and G.726 according to X.420, thus little endian, as defined in RFC 3551
a=rtpmap:97 AAL2 G726 32/8000 → dynamic payload type 97 and G.726 according to I.366.2 Annex E, thus big endian, as defined in RFC 3551
a=rtpmap:2 G726 32/8000 → static payload type 2 and G.726 with unpredictable endianness, like G.721 according to the deprecated RFC 1890
a=rtpmap:96 G726 32/8000 → динамикалық жүктеме түрі 96 және X.420 стандартына сәйкес G.726, демек RFC 3551 бойынша кіші эндиан.
a=rtpmap:97 AAL2 G726 32/8000 → динамикалық жүктеме түрі 97 және I.366.2 қосымшасына сәйкес G.726, демек RFC 3551 бойынша үлкен эндиан.
a=rtpmap:2 G726 32/8000 → статикалық жүктеме түрі 2 және ескірген RFC 1890 стандартына сәйкес G.721 сияқты болжауға болмайтын эндианмен.
The payload type for G.721 was defined by the deprecated RFC 1890 as 2, thus a=rtpmap:2 G721/8000. In drafts for newer version of this RFC, it was reused for G.726, i. e. a=rtpmap:2 G726 32/8000. Contrary to that the ITU explicitly defined the byte order in its recommendations regarding G.726 or respectively ADPCM, but in two different ways. Recommendation X.420 states, that it shall be little endian, respecting recommendation I.366.2 Annex E it should be big endian. This led to contradicting decisions in various implementations, as some manufacturers opted for little endian and others for big endian. The consequence was, that these implementations were incompatible, as decoding using the wrong byte order results in a heavily distorted audio signal. Therefore the unclear definition was fixed by the RFC 3551, which replaces RFC 1890. Section 4.5.4 in RFC 3551 defines the classical MIME types G726 16, 24, 32 and 40 as little endian and introduces new MIME types for bis endian, which are AAL2 G726 16, 24, 32 and 40. The payload type was changed to dynamic, in order to prevent confusion. Instead of payload type 2 a dynamic payload in the range from 96 to 127 shall be used:
little endian(X.420 and RFC 3551) big endian(I.366.2 Annex E and RFC 3551) deprecated 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
Newer implementations respect the RFC 3551 and clearly distinct between G726 xx (little endian) and AAL2 G726 xx (big endian). The Gigaset C610 IP DECT phone, e. g., generates the following code in its SIP INVITE:
a=rtpmap:96 G726 32/8000 → dynamic payload type 96 and G.726 according to X.420, thus little endian, as defined in RFC 3551
a=rtpmap:97 AAL2 G726 32/8000 → dynamic payload type 97 and G.726 according to I.366.2 Annex E, thus big endian, as defined in RFC 3551
a=rtpmap:2 G726 32/8000 → static payload type 2 and G.726 with unpredictable endianness, like G.721 according to the deprecated RFC 1890