https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3368
Summary: The timestamp line in a RTP or RTCP packet display's
"Not Representable"
Product: Wireshark
Version: 1.0.5
Platform: x86
OS/Version: Windows XP
Status: NEW
Severity: Trivial
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: leroy.forsberg@xxxxxxxxxxxx
Created an attachment (id=2889)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=2889)
Includes pcap of rtcp packet & word doc with different examples
Build Information:
wireshark 1.0.5 (SVN Rev 26954)
Copyright 1998-2008 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled with GTK+ 2.12.8, with GLib 2.14.6, with WinPcap (version unknown),
with libz 1.2.3, without POSIX capabilities, with libpcre 7.0, with SMI 0.4.8,
with ADNS, with Lua 5.1, with GnuTLS 2.3.8, with Gcrypt 1.4.1, with MIT
Kerberos, with PortAudio V19-devel, with AirPcap.
Running on Windows XP Service Pack 3, build 2600, with WinPcap version 4.0.2
(packet.dll version 4.0.0.1040), based on libpcap version 0.9.5, without
AirPcap.
Built using Microsoft Visual C++ 6.0 build 8804
--
The timestamp line in a RTP or RTCP packet display's "Not Representable".
>From RFC 3550:
"
NTP timestamp: 64 bits
Indicates the wallclock time (see Section 4) when this report was sent so
that it may be used in combination with timestamps returned in reception
reports from other receivers to measure round-trip propagation to those
receivers. Receivers should expect that the measurement ac-curacy of the
timestamp may be limited to far less than the resolution of the NTP timestamp.
The measurement uncertainty of the timestamp is not indicated as it may not be
known. On a system that has no notion of wallclock time but does have some
system-specific clock such as \system uptime", a sender may use that clock as a
reference to calculate relative NTP timestamps. It is important to choose a
commonly used clock so that if separate implementa- tions are used to produce
the individual streams of a multimedia session, all implementations will use
the same clock. Until the year 2036, relative and absolute timestamps will
differ in the high bit so (invalid) comparisons will show a large difference;
by then one hopes relative timestamps will no longer be needed. A sender that
has no notion of wallclock or elapsed time may set the NTP timestamp to zero.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header | V=2|P| RC | PT=SR=200 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
sender | NTP timestamp, most significant word |
info +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
