for data protocols in the context of the internet was generally defined as big endian and called simply network byte order, as stated (among others) by the deprecated RFC 1700, the deprecated RFC 1890 did not explicitly define the endianness of the predecessor of G.726, G.721, in RTP either. Instead of that, in the deprecated RFC 1890, the use of big endian by the term network byte order was generally stated for all mentioned codecs again: 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: 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 See also List of codecs Comparison of audio coding formats External links ITU-T G.726 page ITU-T G.191 software tools for speech and audio coding, including G.726 C code RFC 3551 - RTP Profile for Audio and Video