Talk:Real-time Transport Protocol
![]() | Computing: Networking C‑class Mid‑importance | ||||||||||||
|
![]() | Real-time Transport Protocol is currently a good article nominee. Nominated by an unspecified nominator at 12:41, 19 March 2009 (UTC) An editor has indicated a willingness to review the article in accordance with the good article criteria and will decide whether or not to list it as a good article. Comments are welcome from any editor who has not nominated or contributed significantly to this article. This review will be closed by the first reviewer. To add comments to this review, click discuss review and edit the page.
|
This is the talk page for discussing improvements to the Real-time Transport Protocol article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives: 1 |
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)
- C-Class Computing articles
- Mid-importance Computing articles
- C-Class Computer networking articles
- Mid-importance Computer networking articles
- C-Class Computer networking articles of Mid-importance
- All Computer networking articles
- All Computing articles
- Good article nominees
- Good article nominees on review
- Good article nominees without a subtopic