jlibrtp – RTP Java Library

jlibrtp –RTP Java Library Arne Kepp, Vaishnav Janardhan COMS 4995: VoIP Security Course Advisor: Prof. Schulzrinne

Overview • Scope • Overview of library • API • RTCP • Status of implementation • Packet buffering / reordering • Bugs • Demo and minor details

Scope of Project • Goals, in chronological order: • RFC 3550 – Real-Time Protocol • Tools for testing / demonstration • Frame reconstruction • RFC 3551 – RTP Profile for Audio and Video Conferences with Minimal Control • Left out due to lack of resources: • Secure RTP • Fancy data recovery attempts

Overview of Dataflow and Threads Changes since midterm:RTP Session does no work by itselfNo threads associated with individual participants

API • Session object: • RTPSession(ssrc, payload, profile) • RtpSession.addParticipant(Participant p) • RtpSession.removeParticipant(cname, ip, port) • RtpSession.participantFor(cname) -> Participant • RtpSession.endSession() • Callback RtpAppIntf: • RtpAppIntf.receiveData(data, type, cname, time) • [ RtpAppIntf.sessionEvent(int type, data) ]

RTCP • RTCPSession is the manager class, which spawns one receiver thread and different thread for sending out the packets • RTCP first sends a SDES message and updates the participant database with the new participants • RTCP Resource Receiver will collect the statistics at the RTP receiver thread for each participant • RTCP Bye message will maintain the session between the participants

RTCP Messages • RR: Receiver report, for reception statistics from participants that are not active senders • SDES: Source description items, including CNAME • BYE: Indicates end of participation • SR: Sender report, for transmission and reception statistics from participants that are active senders - Not implemented • APP: Application-specific functions .

RTCP Packets - Header • Version: Identifies the RTP version which is the same in RTCP packets as in RTP data packets. The version defined by RFC 3550 is two (2). • P – Padding: When set, this RTCP packet contains some additional padding octets at the end which are not part of the control information.In a compound RTCP packet, padding should only be required on the last individual packet because the compound packet is encrypted as a whole. • RC- Reception report count: the number of reception report blocks contained in this packet. A value of zero is valid. • Length: The length of this RTCP packet in 32-bit words minus one, including the header and any padding. Src: RTP Presentation by Zacharias Kapellakis

RTCP Receiver Report • Receiver Report Message • The statistics for RR are collected at the RTPReceiverThread. • Array of RR Type objects is maintained for all the participants in the database. And the stats are updated based on the SSRC of the packet received • SDES Packet • SDES packet conveys the SSRC for each participant that have been negotiated during the SIP Session establishment • It could also convey other details like the e-mail, phone number which can be stored in the participant database

Implemented [ToDo] • RFC 3550 RTP • RTP packet parser [Extension, Padding] • Packet buffering, reordering • RTCP [Statistics] • Participant database • [NTP timestamp data before returning] • Tools for Testing / Demonstration • Basic demonstration application • Small programs to test particular classes

Implemented [ToDo] • RFC 3551 RTP w/min control • We don’t really touch the data [improve] • No real jitter control, built into JMF Audio • Frame Reconstruction • Reconstruct frames directly in packet buffer • Return null for incomplete frames • Need to think more about how this can be utilized by the application through an easy interface.

Packet reordering / Reconstruction

Known bugs • Some issues with counters • TimeStamp • Sequence Number • SSRC is not negotiated • Uses properly initialized Random() These will be fixed.

Performance and Security • Performance: • ~ 2.8 = Mbyte/s with 1024 byte packet • ~50% CPU, Loopback, 2.13 GHz Pentium M, Linux 2.6.17, Java 1.5.0.9 • Limited security features: • Check ip and port against participant database before parsing. • Testing packet for valid values • No payload-specific checks :(

Sample Flood-Application Import jlibrtp.*; public AnExample implements RTPAppIntf { RTPSession session = null; Public void receiveData(byte[] data, String cname, long time) { System.out.println(“I received “ + (new String(data)) + “from “+ cname); } Public AnExample() { } public static void main(String [] args) { AnExample example = new AnExample(); example.session = new RTPSession(); example.session.RTPSessionRegister(4545,4546,”MyCname”,111); Participant p = new Participant(“Cname”,”127.0.0.1”,4545); example.session.addParticipant(p); String str = “123”; while(true) { session.sendData(str.getBytes()) } }

Demonstration • Streaming 8 kHz sound

Java Media Framework • List of supported formats • http://java.sun.com/products/java-media/jmf/2.1.1/formats.html • Almost(?) every format described in RFC 3551 • But can be tricky: “No line matching interface SourceDataLine supporting format ULAW 8000.0 Hz, 8 bit, mono, 1 bytes/frame” • Listed: Sun Audio (.au) : 8 bits mono/stereo linear, G.711 (U-law),encode/decode

A Word of Caution: Java • No C structures to use for packets • No unsigned integers • Makes parsing difficult • Have to use 64 bit Long • Counters do not roll over • Sometimes Longs are cast to int and you don’t notice. • Concurrency and sound are difficult

Get The Code: jlibrtp

jlibrtp – RTP Java Library