Talk:Real-time Transport Protocol
|This is the talk page for discussing improvements to the Real-time Transport Protocol article.|
|Real-time Transport Protocol was one of the Engineering and technology good articles, but it has been removed from the list. There are suggestions below for improving the article to meet the good article criteria. Once these issues have been addressed, the article can be renominated. Editors may also seek a reassessment of the decision if they believe there was a mistake.|
|Current status: Delisted good article|
|This article is of interest to the following WikiProjects:|
On the layer
On Wiki-Page: http://en.wikipedia.org/wiki/OSI_Model die RTP-Protocol is located on OSI-layer 4 (Transport) --> DoD-Layer 3 (together with UDP, TCP, DCCP, SCTP).
On this Wiki-Page the RTP is located in DoD-Layer 4 (Application Process).
In my opinion the latter is the correct one.
"RTP relies on the underlying protocol(s) to provide demultiplexing of RTP data and RTCP control streams." (RFC3550 67)
Since RTP itself does not supply any kind of multiplexing and it tranports RTCP (Monitoring and control QoS-paramters) it should not be assigned to layer 3.
How do you think about this?
A. Yes, I think you are right, definetely RTP, RTSP and RTCP do not belong to the transport level.
- I have changed the category of these three protocols to category:application layer protocols. What OSI layer does the RSVP protocol have? Mange01 22:45, 20 November 2006 (UTC)
I do not agree with the change at all. IP goes over ARP, and it does not make a 3rd layer protocol. RTP is obviously a Transport protocol (it is even its name!), but since it belongs to a new generation, it subdivides the 3rd layer in 2. But if you don't believe me, believe the RFC 3550 self in its 1.Introduccion:
Applications typically run RTP on top of UDP to make use of its multiplexing and checksum services; both protocols contribute parts of the transport protocol functionality.
Wikipedia does not "think", just know. Please revert the changes. 22-2-07
- someone should really fix this,it made me look stupid in front of my employees and i have no idea how to fix this myself18.104.22.168 23:04, 28 June 2007 (UTC)
I agree. No speculation on what layer it operates is required when the RFC is quite explicit. There are many examples of multiple protocols operating at the same layer, 802.2 LLC or SNAP are layer 2 operating with 802.3 or 802.5 etc. Do not confuse the encapsulation with layer of functionality.
- Probably not, since the capitalisation of the page matches RTP, the common initialism (a.k.a. acronym). --AlastairIrvine 04:18, 9 May 2007 (UTC)
What softwares and services are really using RTP? I suggest a section called Usage. Mange01 21:45, 3 December 2006 (UTC)
Perhaps this section should be split up using 3rd-level headings.
Also, I think the format for the timestamp should be given. Comments? --AlastairIrvine 04:20, 9 May 2007 (UTC)
Is this paper really realavent? Sabalon 23:44, 20 June 2007 (UTC)
"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."
Should it read "Applications using RTCP are less sensitive to packet loss"? This seems more typical to TCP. RTP over UDP seems to be less sensitive to delays. --Eric (talk) 00:39, 11 December 2007 (UTC)
I think the port range specified in this article needs to be updated. The article states "Although there are no standards assigned, RTP is generally configured to use ports 16384-32767." This statement bit me in the behind a couple of weeks ago when I ran a packet capture for a customer during a voice call and the RTP was coming in using ports in the 39000 range. I had initially told the customer that as long as he opened up 16384-32767 for RTP, he would be ok, but on his VoIP calls he could not hear the person on the other end. He had his ISP open up ports all the way to 40000 and the problem was solved, no thanks to Wiki. I understand that the article states that RTP is "generally configured" to use that port range, which means that it is possible that the RTP will use ports outside of that range, but I thought that the range could at least be updated to be a bit more accurate if at all possible. I'm assuming that there is more information out there now to further increase the accuracy of the "general" range of RTP ports? —Preceding unsigned comment added by 22.214.171.124 (talk) 23:03, 26 June 2008 (UTC)
I agree that the port range 16384-32767 should come out unless somebody can provide a citation. I've searched the web looking for something to back it up and found nothing. I did find this, "IETF recommend ports 6970 to 6999", at the Wireshark wiki but I couldn't back that up either. --Exaudio (talk) 21:59, 30 July 2008 (UTC)
Good article nomination
I am happy to pass this article as a good article. It offers concise coverage of the topic in a way that is likely to be helpful to the technical reader not familiar with RTP. It also meets all six requirements of the good article criteria. Yhe article provides an excellent overview of what RTP is but its coverage of where and how the protocol is used could be improved. Cedars (talk) 02:00, 21 March 2009 (UTC)
Abandoned GA reassessment (July 2009)
- Delisted per obvious consensus. (The stub on Real Data Transport is better written than this, in terms of clarity.) Someone not using his real name (talk) 04:01, 17 December 2013 (UTC)
Merge from RTP audio video profile
I'll kick it off then. I've jumped here with no knowledge of either RTP of of RTP audio/video. Looking at the suggested merge article, I would suggest that it not be merged. This is a protocol, and as such is of interest to someone researching it with a view to support. The other article goes into great detail about the media streams. Completely different topic, IMO. It seems entirely appropriate to have an article about RTP, which may have uses other than supporting media streams, at which point, the articles would presumably have to be de-merged. Merging the articles would seem to me to defeat the purpose of hyperlinks. — Preceding unsigned comment added by 126.96.36.199 (talk) 09:05, 31 January 2014 (UTC)
- I don't see any support for this merge. I have taken down the banners. ~KvnG 14:47, 17 February 2014 (UTC)