Emmanuel Wauters
2007-Mar-02 02:48 UTC
[Speex-dev] "Redundant audio data" header in speex payload
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 -- ------------------------------------------------------------- Emmanuel Wauters Tel : (+32) 11 30 13 30 mailto:emmanuel.wauters@androme.com http://www.androme.be ANDROME NV Wetenschapspark 4 B-3590 Diepenbeek, Belgium
Jean-Marc Valin
2007-Mar-02 02:52 UTC
[Speex-dev] "Redundant audio data" header in speex payload
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 >
Emmanuel Wauters
2007-Mar-02 03:23 UTC
[Speex-dev] "Redundant audio data" header in speex payload
In attachement two messages 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
First packet:
--------------
No. Time Source
Destination Protocol Info
1 2007-03-02 10:11:02.135207 172.17.10.16
172.17.21.31 RTP Payload type=Unknown (99),
SSRC=1061405506, Seq=54956, Time=3107650972
Frame 1 (92 bytes on wire, 92 bytes captured)
Arrival Time: Mar 2, 2007 10:11:02.135207000
[Time delta from previous packet: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Packet Length: 92 bytes
Capture Length: 92 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:udp:rtp:rtp]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: 3Com_d2:51:74 (00:04:76:d2:51:74), Dst: Intel_eb:49:49
(00:0c:f1:eb:49:49)
Destination: Intel_eb:49:49 (00:0c:f1:eb:49:49)
Address: Intel_eb:49:49 (00:0c:f1:eb:49:49)
.... ...0 .... .... .... .... = Multicast: This is a UNICAST frame
.... ..0. .... .... .... .... = Locally Administrated Address:
This is a FACTORY DEFAULT address
Source: 3Com_d2:51:74 (00:04:76:d2:51:74)
Address: 3Com_d2:51:74 (00:04:76:d2:51:74)
.... ...0 .... .... .... .... = Multicast: This is a UNICAST frame
.... ..0. .... .... .... .... = Locally Administrated Address:
This is a FACTORY DEFAULT address
Type: IP (0x0800)
Internet Protocol, Src: 172.17.10.16 (172.17.10.16), Dst: 172.17.21.31
(172.17.21.31)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 78
Identification: 0x6672 (26226)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: UDP (0x11)
Header checksum: 0x5cdb [correct]
[Good: True]
[Bad : False]
Source: 172.17.10.16 (172.17.10.16)
Destination: 172.17.21.31 (172.17.21.31)
User Datagram Protocol, Src Port: 23010 (23010), Dst Port: 40632 (40632)
Source port: 23010 (23010)
Destination port: 40632 (40632)
Length: 58
Checksum: 0x8447 [correct]
Real-Time Transport Protocol
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 .... = Extension: False
.... 0000 = Contributing source identifiers count: 0
0... .... = Marker: False
Payload type: Unknown (99)
Sequence number: 54956
Timestamp: 3107650972
Synchronization Source identifier: 1061405506
RFC2198: Redundant Audio Data
Header 1: PT=Unknown (41)
0... .... = Follow: Not set
.010 1001 = Payload type: 41
Payload: D9C99D8F2EC774B445B9BD5318A33790B7079BE5E042A59F...
No. Time Source
Destination Protocol Info
3 2007-03-02 10:11:02.136042 172.17.21.31
172.17.10.16 RTP Payload type=Unknown (99),
SSRC=1238454564, Seq=979, Time=300591171
Second packet:
----------------
Frame 3 (92 bytes on wire, 92 bytes captured)
Arrival Time: Mar 2, 2007 10:11:02.136042000
[Time delta from previous packet: 0.000274000 seconds]
[Time since reference or first frame: 0.000835000 seconds]
Frame Number: 3
Packet Length: 92 bytes
Capture Length: 92 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:udp:rtp:rtp]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: Intel_eb:49:49 (00:0c:f1:eb:49:49), Dst: 3Com_d2:51:74
(00:04:76:d2:51:74)
Destination: 3Com_d2:51:74 (00:04:76:d2:51:74)
Address: 3Com_d2:51:74 (00:04:76:d2:51:74)
.... ...0 .... .... .... .... = Multicast: This is a UNICAST frame
.... ..0. .... .... .... .... = Locally Administrated Address:
This is a FACTORY DEFAULT address
Source: Intel_eb:49:49 (00:0c:f1:eb:49:49)
Address: Intel_eb:49:49 (00:0c:f1:eb:49:49)
.... ...0 .... .... .... .... = Multicast: This is a UNICAST frame
.... ..0. .... .... .... .... = Locally Administrated Address:
This is a FACTORY DEFAULT address
Type: IP (0x0800)
Internet Protocol, Src: 172.17.21.31 (172.17.21.31), Dst: 172.17.10.16
(172.17.10.16)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 78
Identification: 0x09a8 (2472)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (0x11)
Header checksum: 0xf9a5 [correct]
[Good: True]
[Bad : False]
Source: 172.17.21.31 (172.17.21.31)
Destination: 172.17.10.16 (172.17.10.16)
User Datagram Protocol, Src Port: 40632 (40632), Dst Port: 23010 (23010)
Source port: 40632 (40632)
Destination port: 23010 (23010)
Length: 58
Checksum: 0xe820 [correct]
Real-Time Transport Protocol
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 .... = Extension: False
.... 0000 = Contributing source identifiers count: 0
0... .... = Marker: False
Payload type: Unknown (99)
Sequence number: 979
Timestamp: 300591171
Synchronization Source identifier: 1238454564
RFC2198: Redundant Audio Data
Header 1: PT=Unknown (46)
0... .... = Follow: Not set
.010 1110 = Payload type: 46
Payload: 8E701C7FEE8F9B92D60A329AA71BF8CB20C0F07DFF9BDC05...
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
>>
>>
>>
>
>
>
--
-------------------------------------------------------------
Emmanuel Wauters Tel : (+32) 11 30 13 30
mailto:emmanuel.wauters@androme.com http://www.androme.be
ANDROME NV
Wetenschapspark 4
B-3590 Diepenbeek, Belgium
Jean-Marc Valin
2007-Mar-02 03:29 UTC
[Speex-dev] "Redundant audio data" header in speex payload
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 >>> >>> >> >> >> > >
Emmanuel Wauters
2007-Mar-02 03:47 UTC
[Speex-dev] "Redundant audio data" header in speex payload
Yes, it is possible that the audio is stationary.
But I want to point out here that it's not me who is doing the
interpretation, but the parser in wireshark.
Here is a snippet of its message output:
Real-Time Transport Protocol
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 .... = Extension: False
.... 0000 = Contributing source identifiers count: 0
0... .... = Marker: False
Payload type: Unknown (99)
Sequence number: 54956
Timestamp: 3107650972
Synchronization Source identifier: 1061405506
RFC2198: Redundant Audio Data
Header 1: PT=Unknown (41)
0... .... = Follow: Not set
.010 1001 = Payload type: 41
Payload: D9C99D8F2EC774B445B9BD5318A33790B7079BE5E042A59F...
Emmanuel
Jean-Marc Valin wrote:
>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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
--
-------------------------------------------------------------
Emmanuel Wauters Tel : (+32) 11 30 13 30
mailto:emmanuel.wauters@androme.com http://www.androme.be
ANDROME NV
Wetenschapspark 4
B-3590 Diepenbeek, Belgium