Fabiana moreno wrote:
yes i was in indeed refering to the following sequence number (the one
in bold red) and it is from the rtp protocol. I am confused; because it
seems like a packet identifiers; it starts with a random number and then
goes on adding 1 for every packet.
Somebody earlier in this thread quoted RFC 1889, "RTP: A Transport
Protocol for Real-Time Applications", which is the specification for RTP:
sequence number: 16 bits
The sequence number increments by one for each RTP data packet
sent, and may be used by the receiver to detect packet loss and to
restore packet sequence. The initial value of the sequence number is
random (unpredictable) to make known-plaintext attacks on encryption
more difficult, even if the source itself does not encrypt, because the
packets may flow through a translator that does. Techniques for choosing
unpredictable numbers are discussed in [7].
So, yes, the RTP sequence number starts with a random number and then is
increased by 1 for each packet, because that's what the RTP
specification says should happen.
It is unrelated to the IP packet identifier.
My other email is that i have noticed something very weird while taking
the captures with tcpdump instead of wireshark. The packets id�s are
always 0; which is not correct;
Why is it not correct? There is *NOTHING* in RFC 791 that requires the
IP ID to be unique in non-fragmented packets, and there's nothing I
found in the Host Requirements RFC 1122 about it, either, as per my
other mail:
http://www.wireshark.org/lists/wireshark-users/200804/msg00194.html
ive been reading about and apparently
theres is bug in the kernel 2.6...but i dont really know why i am
getting those captures with packet id=0 ....
At least some pages I found with Google seem to suggest that this is a
*feature* of the Linux kernel, introduced in the 2.4.8 kernel or earlier.
