![]()
|
RTP Tools (Version 1.17)The authors cannot provide support for compiling or running the rtptools. We will gladly accept bug fixes, but all other email regarding the rtptools will be ignored.DescriptionThe rtptools distribution consists of a number of small applications that can be used for processing RTP data.
InstallationSources for a variety of platforms and binaries for Windows NT are available from http://www.cs.columbia.edu/~hgs/rtptools/software/src. The RTP tools should compile on any Posix-compliant platform supporting sockets, as well as Windows/NT/95/98/2000 (Win32). They have been tested on SunOS 4.1, SunOS 5.x (Solaris), Linux, NT 4.0, SGI Irix, and HP-UX. Edit the directories and libraries at the top of Makefile and type make. The compiler must support ANSI C: gcc does, Sun's old /usr/ucb/cc does not. Note: You must use the General Usage HintsNetwork addresses can be either multicast or unicast addresses, unless stated otherwise. They may be specified in dotted-decimal notation (e.g., 224.2.0.1) or as a host name (e.g., lupus.fokus.gmd.de). Port numbers must be given as decimal numbers in the range of 1 to 65535. Network addresses are specified as destination/port/ttl. The time-to-live (ttl) value is optional and only applies to multicast. For all commands, the flag -h or -? will print a short usage summary. Unless otherwise noted, input is taken from stdin, and output sent to
stdout. The extension rtpplayrtpplay [-T] [-v] [-f file] [-p profile] [-b begin] [-e end] destination/port/[ttl]rtpplay reads RTP session data, recorded by
rtpdump -F dump from either the file or stdin,
if file is not specified, sending it to network address
destination and port port with a time-to-live
value of ttl. If the flag The whole file is played unless the begin or end times are specified. Times are measured in seconds and fractions from the beginning of the recording. The RTP clock frequency is read from the profile file if
given; the default profile (RFC 1890) is used if not. The profile file
contains lines with two fields each: the first is the numeric payload
type, the second the clock frequency. The values read from the profile
file are silently ignored if the If you want to loop a particular file, it is easiest to put the
The -v flag has rtpplay display the packets generated on stdout.
rtpdumprtpdump -F format -t duration -x bytes -f file -o outputfile address/portIf file is specified, the file is used instead of the
network address. If no network address is given, file input is expected
from stdin. The file must have been recorded using the rtpdump
The duration is measured in minutes. From each packet, only the first bytes of the payload are dumped (only applicable for "dump" and "hex" formats). rtpsendrtpsend sends an RTP packet stream with configurable parameters. This is intended to test RTP features. The RTP or RTCP headers are read from a file, generated by hand, a test program or rtpdump (format "ascii"). rtpsend [-a] [-l] [-ssourceport] [-tttl] [-f file] destination/port Packets are sent with a time-to-live value ttl. If data is read from a file instead of stdin, the -l (loop) flag resends the same sequence of packets again and again. The source port for outgoing packets can be set with the -s flag. A random port is chosen if this flag is not specified. If the -a flag is specified, rtpsend includes a router alert IP option in RTCP packets. This is used by the YESSIR resource reservation protoccol. The file file contains the description of the packets to be sent. Within the file, each entry starts with a time value, in seconds, relative to the beginning of the trace. The time value must appear at the beginning of a line, without white space. Within an RTP or RTCP packet description, parameters may appear in any order, without white space around the equal sign. Lines are continued with initial white space on the next line. Comment lines start with #. Strings are enclosed in quotation marks. <time> RTP v=<version> m=<marker> pt=<payload type> ts=<time stamp> seq=<sequence number> cc=<CSRC count> data=<hex payload> ssrc=<SSRC> x=<extension?> ext_type=<type of extension> ext_len=<length of extension header> ext_data=<hex extension data> <time> RTCP (SDES v=<version> (src=<source> cname="..." name="...") (src=<source> ...) ) (SR v=<version> ssrc=<SSRC of data source> p=<padding> count=<number of sources> len=<length> ntp=<NTP timestamp> psent=<packet sent> osent=<octets sent> (ssrc=<SSRC of source> fraction=<loss fraction> lost=<number lost> last_seq=<last sequence number> jit=<jitter> lsr=<last SR received> dlsr=<delay since last SR> ) ) rtptransrtptrans host/port[/ttl] host/port[/ttl] [...]rtptrans RTP/RTCP packets arriving from one of the addresses to all other addresses. Addresses can be a multicast or unicast. TTL values for unicast addresses are ignored. (Actually, doesn't check whether packets are RTP or not.) Additionally, the translator can translate VAT packets into RTP packets. VAT control packets are translated into RTCP SDES packets with a CNAME and a NAME entry. However, this is only intended to be used in the following configuration: VAT packets arriving on a multicast connection are translated into RTP and sent over a unicast link. RTP packets are not (yet) translated into VAT packets and and all packets arriving on unicast links are not changed at all. Therefore, currently mainly the following topology is supported: multicast VAT -> translator -> unicast RTP; and on the way back it should lokk like this multicast VAT <- translator <- unicast VAT. This means that the audio agent on the unicast link should be able use both VAT and RTP. AuthorsThe rtptools were written by Henning Schulzrinne, with enhancements by Ping Pan. rtptrans was written by Dorgham Sisalem and enhanced by Steve Casner. Program history Last updated 09/08/2008 15:06:23 by Henning Schulzrinne |