BAI513 - PROTOCOLS

1. BAIST – Network Management BAI513 - PROTOCOLS RTP - RTCP

2. Real-Time Transport Protocols • RTP • End-to-end network transport functions for real-time data • Suitable framework for any encoding • Complete Protocol : RTP framework + payload format • Used with RTCP optionally • RTCP • Monitoring of data delivery • Minimal control and identification functionality

3. Introduction • Services • Payload type identification • Sequence numbering • Timestamping • Delivery monitoring • RTP over UDP/IP • Multiplexing • Checksum • Multicasting • RTP does not provide • Timely delivery • Guaranteed QoS delivery • Out-of-order delivery prevention

4. RTP – A Transport Protocol

5. Real-Time Traffic After receiving complete video, client begins playback Entire video transferred to client Video Client Video Client Stored Video Server Individual video frames transferred to client as they occur Client plays back each video frame as it arrives Video Conference Server • Not all multimedia data is real time There are no tight constraints There are tight constraints

6. Definitions • RTP Payload • data transported by RTP in a packet • RTP Packet • fixed RTP header + (list of contributing sources) + payload data • Transport address • (network address, port) • e.g) IP address + UDP port • need not to have a well-known port(default is 5004) • RTP session • association among a set of participants communicating with RTP • defined by a pair of transport address

7. Definitions(cont’d) • Synchronization Source(SSRC) • source of a stream of RTP packets • identified by a 32-bit ID(SSRC) in RTP header • globally unique in a RTP session • SSRC ID is randomly chosen • all packets from a SSRC form a part of the same timing & seq. # space • receiver groups packets by SSRC to playback • Contributing Source(CCRC) • a source of a stream of RTP packets that has contributed to the combined stream produced by RTP mixer • Mixer inserts a list of the SSRC ids (CSRC list)

8. Mixer & Translator • A Mixer is an intermediate system • receives RTP packets from one or more sources • possibly changes the data format • combines the packets in some manner • forwards a new RTP packet • timing adjustment among several streams and generate its own timing • mixer becomes SSRC for the new combined packet Each source generates 64Kbit/s of Audio traffic SSRC : A SSRC : E CSRC : A, B, C combines all three into a single 64Kbit/s stream SSRC : B SSRC : C Mixer E

9. Translator • A Translator is an intermediate system • forwards RTP packets with their SSRC id intact • e.g) • convert encoding without mixing • replicator from multicast to unicast • application-level filters in firewalls Frame Relay Each source generates 1Mbit/s of Video traffic SSRC : A SSRC : A SSRC : B SSRC : C converts each to a lower quality, 256Kbit/s stream SSRC : B SSRC : C

10. Example of Translator & Mixer E6 E1 E6 : 15 E1 : 17 E6 : 15 M1 : 48 (1, 17) M1 : 48 (1, 17) M1 E7 M1 : 48 (1, 17) T1 T2 E4 : 47 E4 : 47 M3 : 89 (64, 45) E2 E2 : 1 E4 : 47 M3 : 89 (64, 45) E4 M3 E : End system M2 : 12 (64) M : Mixer E3 : 64 E5 : 45 E3 M2 T : Translator E5 source : SSRC (CSRCs)

11. Timing is Everything

12. Jj i tt tt er

13. Jitter • Jitter is introduced in real-time data by the delay between packets • It is the differing propagation delays of different packets • A major issue in real time and streaming • To prevent jitter, we can timestamp the packets and separate the arrival time from the playback time

14. Timestamping

15. Buffering • Creates a queue of pending packets • All delayed by some amount in order to compensate for maximum jitter • Basically required for audio and video streams

16. Buffer Picture

17. Sequencing • A sequence number on each packet is required for real-time traffic • Because packets may arrive out of order • If subsequent packet already displayed, drop

18. Multicasting • Real-time traffic needs the support of multicasting • In order to scale to multiple senders and receivers • Can’t use TCP, must use UDP • Also: TCP heavier weight • Also: can’t have retransmissions

19. Translation • Translation means changing the encoding of a payload to a lower quality to match the bandwidth of the receiving network

20. RTP Header

21. Fields • Version (2 bits)  2 • P (1 bit)  if there is padding at the end • X (1 bit)  if there is an extension header • Contributor Count (4 bits)  how many • M (1 bit)  generic marker • Payload Type (7 bits)  audio, video, etc. • Sequence number  16 bits

22. RTP Payload Types PT Payload PT Payload 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 PCMU audio 1016 audio G721 audio GSM audio Unassigned audio DV14 audio(8Khz) DV14 audio(16Khz) LPC audio PCMA audio G722 audio L16 audio(stereo) L16 audio(mono) TPS0 audio VSC audio MPA audio G728 audio 16-22 23 24 25 26 27 28 29 30 31 32 33 34-71 72-76 77-95 96-127 unassigned audio RGB8 video HDCC video CelB video JPEG video CUSM video nv video PicW video CPV video H261 video MPV video MP2T video unassigned video reserved unassigned dynamic

23. Fields Continued • Timestamp  time differences between this and prior packet • Synchronization Source  sender who synchronizes all other sources (mixer) • Contributor Identifier(s)  others who are contributing source

24. RTP Data Transfer Protocol • Multiplexing RTP sessions • by the destination transport address • In a teleconference • The audio and video are transported in each separate session • Profile specific modifications to the RTP header • The marker bit and payload type field has profile-specific info. • If particular application needs additional functionality independent of payload format • define additional fixed fields to follow immediately after the SSRC field of header

25. RTP Header Extension • if X bit is set • variable-length header extension is appended to the RTP header • first 16-bits of header extension are left open for distinguishing ID or parameters for profile • length counts the # of 32-bit words in the extension 15 31 0 defined by profile length Header extension

26. RTCP • Periodically transmitted to all participants of the session. • Uses same distribution mechanism as RTP • such as multicasted UDP • RTP port # must be even number • RTCP port # must be odd (RTP + 1) • Stackable RTCP messages

27. RTCP • Feedback on the quality of the data distribution. • Carries a persistent identifier (CNAME). • Can count the number of session members. • Provides minimum session control.

28. RTCP Message Types • SR : Sender Report • RR : Receiver Report • SDES : Source DEScription • BYE : End of participation • APP : Application specific functions

29. SR V P RC PT=SR=200 length SSRC of packet sender NTP timestamp NTP timestamp RTP timestamp Sender’s packet count Sender’s octet count SSRC_1 Fraction lost Cumulative number of packet lost Extend highest sequence number received Interarrival jitter Last SR (LSR) Delay since last SR(DLSR) SSRC_2 ... Profile-specific extensions

30. RR V P RC PT=RR=201 length SSRC of sender SSRC_1 Fraction lost Cumulative number of packet lost Extend highest sequence number received Interarrival jitter Last SR (LSR) Delay since last SR(DLSR) SSRC_2 ... Profile-specific extensions

31. SDES V P SC PT=RR=202 length SSRC/CSRC_1 SDES items SSRC/CSRC_2 SDES items

32. SDES Items • CNAME : Canonical NAME • “user@host” or • “host” • NAME : User name • EMAIL : Email address • PHONE : Phone number • LOC : Geographical location

33. BYE V P SC PT=BYE=203 length SSRC/CSRC ... length Reason for leaving

34. APP V P subtype PT=APP=204 length SSRC/CSRC Name(ASCII) Application-dependent data

35. RTCP Transmission Interval • For scalability, the interval must be increased as the group grows. • Suggested control traffic fraction is 5%. • Minimum interval is 5 seconds. (for the case of small group) • The instant intervals are varied randomly to avoid synch. • The more important, the more often.

36. RTCP Processing in Translators and Mixers • If RTP data is modified, RTCP must be modified. • Aggregation of SDES • Modification of SR, RR • It is advisable to combine RTCP packets from many sources to reduce overhead.

37. In Translators • Without modification of data, without modification of RTCP • With any transformation, it should reflect the characteristic & receiving quality.

38. SR sender info in Translators • If data encoding is changed, sender’s byte count must be changed. • If data packets are combined, sender’s packet count must be changed. • If timestamp frequency is changed, RTP timestamp field must be changed. RTP T RTCP

39. SR/RR reception report in Translators • Because of combination of several data packets, several fields must be changed. • This may be complex. • It can filter all reception reports, and generate new ones originating from itself. RTP T RTCP

40. SDES, BYE, APP in Translators • SDES : Filters non-CNAME info if bandwidth is limited • BYE, APP : Forwarded unchanged.

41. SR sender info in Mixer • Does not forward at all. • Generate new one of its own for both sides. RTCP RTCP M RTCP

42. SR/RR reception report info in Mixer • Does not forward at all. • Generate new one of its own for sender. RTCP M RTCP

43. Security Support in RTP • Support confidentiality through encryption • use profile to specify security services and algorithms • DES in CBC mode as the default encryption algorithm • May define additional payload types for encrypted encodings. • Expect support for authentication and message integrity from lower layers.