RTP: A Transport Protocol for Real-Time Applications

Publisher

IETF / RFC Editor

URL

https://www.rfc-editor.org/rfc/rfc3550.html

Published

2003-07-01

Updated

unknown

Accessed

2026-09-24

HTTP status

200

License

IETF Trust Legal Provisions; no-redistribution; short excerpts and locators only

Source notes citing this source

• The RTCP cumulative number of packets lost is a 24-bit signed field that can be negative when more packets arrive than expected, for example because of duplicates. in context
• The RTCP fraction lost field is an 8-bit fixed-point value giving the proportion of packets lost since the previous report, not since the start of the call. in context
• RTP interarrival jitter is a running estimate updated per packet as J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16, where D is the difference in relative transit time between consecutive packets. in context
• The RTCP interarrival jitter field is expressed in RTP timestamp units, not milliseconds, so converting it to time requires the payload's clock rate. in context
• An RTCP reception report block carries the fraction of RTP packets lost since the previous SR or RR and the cumulative number of packets lost since reception began. in context
• RTCP interarrival jitter is expressed in RTP timestamp units, not milliseconds. in context
• RTCP reception reports carry LSR (middle 32 bits of the NTP timestamp from the last sender report) and DLSR (delay since that report in units of 1/65536 second). in context
• The RTCP cumulative number of packets lost is a 24-bit field that can be negative because duplicate packets are counted as received. in context
• The RTCP report block fraction lost field is an 8-bit fixed-point fraction of packets lost since the previous SR or RR. in context
• RFC 3550 computes interarrival jitter as a running estimate updated with a gain of 1/16 on the absolute difference in transit time between consecutive packets. in context
• To express RTCP jitter in milliseconds, divide the timestamp-unit value by the payload clock rate in kHz; for G.711, G.729 and G.722 that divisor is 8, so 160 units equals 20 ms. inferred in context
• The RTCP interarrival jitter field is expressed in RTP timestamp units, not milliseconds. in context
• RFC 3550 (RTP) is a Standards Track RFC dated July 2003 that obsoletes RFC 1889 without changing packet formats on the wire. in context
• RFC 3550 recommends that RTCP bandwidth be fixed at 5% of the session bandwidth. in context
• The RECOMMENDED fixed minimum RTCP reporting interval in RFC 3550 is 5 seconds. in context
• RFC 3550 recommends that one quarter of the RTCP bandwidth be dedicated to participants that are sending data. in context
• An RTP sender computes round-trip time from a received report block as arrival time A minus LSR minus DLSR. in context
• RTCP Sender Report uses packet type 200 and Receiver Report uses packet type 201. in context
• The RTP sequence number increments by one for each RTP data packet sent and may be used by the receiver to detect packet loss and restore order. in context
• The RTP SSRC is a 32-bit identifier of a stream's source carried in the RTP header so that it does not depend on the network address. in context

Cite this source record

APA

WarmTransfer. (2003, July 1). RTP: A Transport Protocol for Real-Time Applications. WarmTransfer. https://warmtransfer.net/knowledge/sources/rfc-3550-rtp

BibTeX

@misc{warmtransfer-rfc-3550-rtp,
  title  = {RTP: A Transport Protocol for Real-Time Applications},
  author = {{WarmTransfer}},
  year   = {2003},
  url    = {https://warmtransfer.net/knowledge/sources/rfc-3550-rtp},
  note   = {IETF / RFC Editor, accessed 2026-09-24}
}