RTP Tools

Description

The rtptools distribution consists of a number of small applications that can be used for processing RTP data.

rtpplay: Play back RTP sessions recorded by rtpdump
rtpsend: Generate RTP packets from textual description, generated by hand or rtpdump
rtpdump: Parse and print RTP packets, generating output files suitable for rtpplay and rtpsend
rtptrans: RTP translator between unicast and multicast networks

Installation

The RTP tools should compile on any Posix-compliant platform supporting sockets. Edit the directories and libraries at the top of Makefile and type make. The compiler must support ANSI C: gcc does, Sun cc does not.

General Usage Hints

Network 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.

rtpplay

rtpplay destination/port

rtpplay reads RTP session data, recorded by rtpdump -f dump from stdin, sending it to network address destination and port port. The timing between packets corresponds to the arrival timing rather than the RTP timestamps (as rtpplay does not know the timestamp frequency for the payload types).

rtpdump

rtpdump -f format -t duration -x bytes address/port

rtpdump listens on the address and port pair for RTP and RTCP packets and dumps a processed version to stdout. Supported formats are:

format description
dump dump in binary format, suitable for rtpplay
header like "dump", but don't save audio/video payload
ascii parsed packets (default)
hex like "ascii", but with hex dump of payload
rtcp like "ascii", but only RTCP packets
short RTP or vat data in tabular form: [-]time ts [seq], where the [-] indicates a set marker bit
payload only audio/video payload
The duration is measured minutes. From each packet, only the first bytes are dumped (only applicable for "dump" and "hex" formats).

`format`	description
`dump`	dump in binary format, suitable for rtpplay
`header`	like "dump", but don't save audio/video payload
`ascii`	parsed packets (default)
`hex`	like "ascii", but with hex dump of payload
`rtcp`	like "ascii", but only RTCP packets
`short`	RTP or vat data in tabular form: [-]time ts [seq], where the [-] indicates a set marker bit
payload	only audio/video payload

rtpsend

rtpsend 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 "header").

rtpsend [-l] [-tttl] [-f file] destination/port

Packets are sent with a time-to-live value ttl. If data is read from a file, the -l (loop) flag resends the same sequence of packets again and again.

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.

 RTP v=<version> m=<marker> pt=<payload type> ts=<time stamp>
   seq=<sequence number> cc=<CSRC count> data=<hex payload>
 RTCP (SDES v=<version> 
              (src=<source> cname="..." name="...")
              (src=<source> ...)
            )
            (RR v=<version>
            )

rtptrans

rtptrans 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.

Henning Schulzrinne
schulzrinne@fokus.gmd.de