Assignment 2: udp2rtsp ---------------------- This assignment is based on udpspy and shall extend the udpspy in various directions: like before, it shall listen to UDP addresses for incoming data streams; however, these shall be denoted as RTP-based audio and/or video streams. The TCP "control" connection shall no longer just be used to dump packet contents. Instead, it shall be used by an RTSP client to control the udp2rtsp program and direct a media stream to the respective client. That is, instead of just dumping (summaries) of the received UDP packets (dumping the contents into a file is maintained for debugging purposes), these shall be forwarded to the client (both RTP and RTCP packets). RTCP packets from the client shall be fowarded back to the media sender. udp2rtsp shall be controlled via a set of command line parameters and support at least the following options with the respective syntax: udpspy -a -v -i -s -l -r -f -a: used to specify an audio transport address that shall be used for listening for incoming UDP packets. Option -a may be given exactly once and requires two UDP listeing sockets to be created (for one RTP and one for RTCP). The may use any of the following formats: a.b.c.d/p1[-p2] with a.b.c.d being an IPv4 address in dotted decimal notation. hostname/p1[-p2] with hostname being an hostname that can be resolved into an IPv4 (or IPv6) address by using the name resolution mechanisms offered by the operating system /p1-[p2] only specifies a port number so that INADDR_ANY is used as IP address; this implies unicast reception. In this case, assume IPv4. a:b:c:d:e:f:g:h/p1-[p2] (voluntary) with a:...:h representing an IPv6 address. Note: RFC2732 contains numerous examples for valid textual notations for IPv6 addresses. p1 and p2 indicate the port number for RTP and RTCP, respective. If p2 is not specified, p2=p1+1 is assumed. As a simplification, an optional / may be appended to provide the audio payload type (e.g. a.b.c.d/p1-p2/pt). You do not have to support this parameter; if you don't you just have to extract the payload type from the RTP headers. For the IP addresses, the assumptions from assignment 1 hold: All addresses and hostnames may be or resolve to unicast as well as multicast addresses. Remember: multicast addresses are class D IP addresses and are in the range 224.0.0.0 to 239.255.255.255. Just determine the address type and then handle the address accordingly. Note: Resolving IP address using getaddrinfo() or gethostbyname (), etc. may return multiple IP addresses. You only need to process one of these but you need to make sure that the address family is the "right" one. The IP unicast address and the port number (or just the port number) but _not_ the IP multicast address need to be handed to the bind() system call in the data structure struct sockaddr_in (for IPv4). For multicast reception, do not forget the setsockopt() with IP_ADD_MEMBERSHIP. -v: same as -a but for video -i: Used in conjunction with multicasting only and allowed to be specified at most once, this option provides the local IP address of the interface that shall be used for joining all multicast groups. This information needs to go along with IP_ADD_MEMBERSHIP in "struct ip_mreq". -f: Dump contents and/or summary of the received packets into a file. The filename is specified as argument . If consists of the character '-' stdout is used. If the option -f is not specified no output will be produced. -s: Short form: turns off the hexdump output and thus creates a single line of output per packet containing a timestamp with microsecond resolution, source and destination IP address and port number and the packet size. For RTP packets, it also shows the SSRC, sequence number, RTP timestamp, payload type and the value of the M bit. For RTCP packets, the SSRC and the CNAME of the sender are printed. If -s is not given, the output will also have the hexdump. -l: Limits the hexdump output length to the specified number of bytes per packet (otherwise, the full packet contents shall be dumped). -r: Open a listening socket for incoming TCP-based RTSP control connections. A media player client shall be able to connect to the respective
and pair by specifying the following RTSP URI: rtsp://
:/ udp2rtsp must receive, parse, process RTSP 1.0 commands from the client and generate proper responses. The commands to be understood include DESCRIBE, SETUP, PLAY, PAUSE, and TEARDOWN. OPTIONS should be understood (and it easy to respond to anyway). SET_PARAMETER and GET_PARAMETER may be understood and dealt with by means of a minimal response. You do not have to support all of the RTSP headers but remember that responses need to have matching sequence numbers and that the Session: header needs to be filled in properly. The Transport: header is key to session setup in both requests and responses. The DESCRIBE method needs to return an SDP-encoded session description (Content-Type: application/sdp, don't forget to set Content-Length: accordingly). The SDP description shall contain m= lines depending on the command line parameters -a and -v and the of the RTSP URI. If -a is specified, m=audio should be included, if -v is specified, m=video should be included. If both are present, we get two m= lines. The parameter may -- voluntarily -- be used to select just one out of two media streams: if -a and -v are specified on the command line, may choose just one of the streams if present: rtsp://
:/audio for audio and rtsp://
:/video for video. rtsp://
:/all will select both streams. As soon as a PLAY command is received, media packets from the respective addresses (-a and/or -v) shall be forwarded to the media client. Whenever PAUSE is received, the forwarding shall be suspended. TEARDOWN terminates the media session and the udp2rtsp process. Note that this is an exercise to get some feeling for parsing text-based protocols and that you do not have to implement a full RTSP state machine (otherwise this will just grow too large). So, you may make simplifying assumptions. Consult RFC 2326 for details on RTSP operation. Also note that, as stated in the exercise, different players behave differently. Find out which one works best for you (should be one of RealPlayer, MS Media Player, Apple Quicktime, mplayer). This may involve some fine tuning to be able to cope with the peculiarities of the respective player. That is to say, some "debugging" will be needed even if you implement RTSP properly. The program shall be orderly terminated when the user sends a SIGINT (equivalent to pressing Control-C) and then print, as a final action, the time elapsed since its invocation, the number of received packets, and the total number of bytes received. Furthermore, per RTP stream (not for RTCP), the absolute number of received and missed packets and the fraction of lost packets shall be printed. This could look like: Duration: 123.123456 seconds, received 57 packets, 4530 bytes total SSRC: 0x1234aabb received: 19345 lost: 123 fraction: 0.63% This information shall also be output if the program terminates after the media session was closed with a TEARDOWN command via the control connection. Output ------ Example for short form output: 14:09:00.123456 134.102.218.59:40000 -> 134.102.218.58:47000 [79] 0x1234AACC pt=00 T=00122000 #23456 M