[Speex-dev] "Redundant audio data" header in speex payload
Emmanuel Wauters
emmanuel.wauters at androme.com
Fri Mar 2 03:23:20 PST 2007
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 at androme.com http://www.androme.be
ANDROME NV
Wetenschapspark 4
B-3590 Diepenbeek, Belgium
More information about the Speex-dev
mailing list