About Opentopia
Opentopia Directory Encyclopedia Tools

Real-time Transport Protocol

Encyclopedia : R : RE : REA : Real-time Transport Protocol

 Internet protocol suite
Layer Protocols
Application DNS, TLS/SSL, TFTP, FTP, HTTP, IMAP, IRC, NNTP, POP3, SIP, SMTP, SNMP, SSH, TELNET, BitTorrent, RTP, rlogin, …
Transport TCP, UDP, DCCP, SCTP, IL, RUDP,
Network IP (IPv4, IPv6), ICMP, IGMP, ARP, RARP, …
Link Ethernet, Wi-Fi, Token ring, Point-to-Point Protocol>PPP, SLIP, FDDI, ATM, DTM, Frame Relay, SMDS, …

The Real-time Transport Protocol (or RTP) defines a standardized packet format for delivering audio and video over the Internet. It was developed by the Audio-Video Transport Working Group of the IETF and first published in 1996 as RFC 1889 which was obsoleted in 2003 by RFC 3550.

RTP does not have a standard TCP or UDP port that it communicates on. The only standard that it obeys is that UDP communications are done via an even port and the next higher odd port is used for RTP Control Protocol (RTCP) communications. Although there are no standards assigned, RTP is generally configured to use ports 16384-32767. RTP only carries voice/video data. Call setup and tear-down is usually performed by the SIP protocol. The fact that RTP uses a dynamic port range makes it difficult for it to traverse firewalls. In order to get around this problem, it is often necessary to set up a STUN server. 

It was originally designed as a multicast protocol, but has since been applied in many unicast applications.  It is frequently used in streaming media systems (in conjunction with RTSP) as well as videoconferencing and push to talk systems (in conjunction with H.323 or SIP), making it the technical foundation of the Voice over IP industry.
It goes along with the RTCP and it's built on top of the User Datagram Protocol (UDP). Applications using RTP are less sensitive to packet loss, but typically very sensitive to delays, so UDP is a better choice than TCP for such applications.


According to RFC 1889, the services provided by RTP include:


The protocols themselves do not provide mechanisms to ensure timely delivery. They also do not give any Quality of Service (QoS) guarantees. These things have to be provided by some other mechanism. 


Also, out of order delivery is still possible, and flow and congestion control are not directly supported. However, the protocols do deliver the necessary data to the application to make sure it can put the received packets in the correct order. Also, RTCP provides information about reception quality which the application can use to make local adjustments. For example if a congestion is forming, the application could decide to lower the data rate. [Voice over IP in networked virtual environments]


RTP was also published by the ITU-T as H.225.0, but later removed once the IETF had a stable standards-track RFC published. It exists as an Internet Standard (STD 64) defined in RFC 3550 (which obsoletes RFC 1889). RFC 3551 (STD 65) (which obsoletes RFC 1890) defines a specific profile for Audio and Video Conferences with Minimal Control. RFC 3711 defines the Secure Real-time Transport Protocol (SRTP) profile (actually an extension to RTP Profile for Audio and Video Conferences) which can be used (optionally) to provide confidentiality, message authentication, and replay protection for audio and video streams being delivered.





Contents





See also



References





External links


RFCs







































 





From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.














Search Titles









0123456789
ABCDEFGHIJ
KLMNOPQRST
UVWXYZ?










E-mail this article to:



Personal Message: