[Speex-dev] "Redundant audio data" header in speex payload

[Jean-Marc Valin]

Keep in mind that Speex doesn't know about RTP, networks, files or
anything like that. So the byte you're seeing is either added by the
client, or else it happens that Speex produces a byte that you're
misinterpreting as to mean something else. A normal Speex CBR Speex
stream always has the first 5 bits set to the same value (indicating the
mode), so maybe the audio is stationary enough for the next three bits
to be constant as well?

	Jean-Marc

Emmanuel Wauters a écrit :
> In attachement a trace of two speex streams, one going from my machine
> (172.17.10.16) to a transcode process (172.17.21.31) and another one
> going vice versa (ssrc 1238454564). The aim for the transcode process is
> to decode the speex packets, encode the data back again and send it back
> to the origin.
> 
> I noticed that the payload data of a stream (in either direction) always
> had the same first byte,
> and in the wireshark packet grabber, this byte is parsed as a "Redundant
> Audio Data" (rfc 2198) header with values 41 (first stream) and 46
> (reverse stream).
> What I want to know is if this header must be the same in both
> directions, so that this header might be handled wrongly now in the
> transcode process. If it is wrong, then I want to know if I can change
> the value of it through the speex api.
> 
> 
> Thanks,
> Emmanuel
> 
> Jean-Marc Valin wrote:
> 
>> Can you explain a bit more what you mean and what you want to know?
>>
>>     Jean-Marc
>>
>> Emmanuel Wauters a écrit :
>>  
>>
>>> Hi,
>>>
>>> Has anybody some information on on the "Redundant audio data" header in
>>> the speex rtp payload?
>>> Is this header always present? Is its value always the same?
>>> Can it be modified through some speex_*_ctl function?
>>>
>>> Thanks,
>>> Emmanuel
>>>
>>>   
>>
>>  
>>
> 
>