Talk:Real-time Transport Protocol

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 myself89.1.24.220 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.

capitals?

shouldn't this page be at real-time transport protocol? --MarSch 10:40, 30 March 2006 (UTC)

Probably not, since the capitalisation of the page matches RTP, the common initialism (a.k.a. acronym). --AlastairIrvine 04:18, 9 May 2007 (UTC)

Usage?

What softwares and services are really using RTP? I suggest a section called Usage. Mange01 21:45, 3 December 2006 (UTC)

Packet structure

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)

mathmatecial section?

Is this paper really realavent? Sabalon 23:44, 20 June 2007 (UTC)

RTP...RTCP?

"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)

Port Range

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 207.47.34.74 (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)

GA Reassessment

This discussion is transcluded from Talk:Real-time Transport Protocol/GA1. The edit link for this section can be used to add comments to the reassessment.

A large portion of this article is a copyright violation of text from its two main sources, Peterson & Davie and Perkins. Text is copied verbatim. TwilligToves (talk) 04:51, 29 July 2009 (UTC)

I see that the article is interspersed with refs from several sources, except the last section on "RTP-based systems"--"If the compressed frames are large, they may be fragmented into several RTP packets, and if small, several frames may be bundled into a single RTP packet.[22] The sender may make changes to the transmission, depending on the quality feedback received on RTCP.[22]" and of course the diagram, for which a ref has been provided. Apart from this, pls list down other sections that you see, so that they can be addressed. Thanks. --Nvineeth (talk) 05:20, 29 July 2009 (UTC)

I'm not sure I understand what the request for me is here. Could you be specific on what you mean by "list down other sections"? Much of the text is taken verbatim in violation of copyright. The best bet would probably be to start a draft of a new article from scratch in a temporary space (not edit the main article). Once an admin examines the article and deletes the copyright violations from history, the new article can be incorporated into the mainspace. Cheers, TwilligToves (talk) 05:31, 29 July 2009 (UTC)

Nope, I dont think "list down other sections" is necessary, I did a manual check myself and clearly see your point now in at least 3 sections--Protocol components, Sessions, RTP-based systems and will start working on them. --Nvineeth (talk) 05:50, 29 July 2009 (UTC)

I have tried to rewrite major parts of the article, but having done so, I am of the opinion that the article may not meet GA status. I would request the reviewers to give a thorough review and take appropriate action. --Nvineeth (talk) 08:47, 29 July 2009 (UTC)

I am also not convinced that the article meets Wikipedia:Good article criteria.

• Much in the lead is repeated in the Overview section
• Profiles and sessions are not well explained
• There's a disorienting alphabet soup of protocol names
• Some of the material is technical without sufficient introduction or context for the non-technical reader.
• I fixed some basic grammar and readability problems. There are probably others remaining.

It doesn't look like this reassesment was ever concluded. What needs to be done to get it restarted? --Kvng (talk) 00:40, 30 October 2010 (UTC)

• I agree with the above and I have my own concerns, like this article not explaining for the average reader who and when promoted this protocol and how it fits in the other Real* constellation. Quickfailing GAR per WP:IAR and broad consensus. We don't need a wikiform filled triplicate to enact the obvious conclusion here. Someone not using his real name (talk) 03:57, 17 December 2013 (UTC)