Jump to content

Talk:Real-time Transport Protocol

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Kvng (talk | contribs) at 21:41, 25 March 2020 (→Port Range: resolved). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
Former good articleReal-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.
Article milestones
DateProcessResult
March 21, 2009Good article nomineeListed
December 17, 2013Good article reassessmentDelisted
Current status: Delisted good article

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)[reply]

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)[reply]

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.

We are still describing this as an application layer protocol. This is consistent with RFC 3550. It is important to be clear that the application layer we're talking about is per the Internet protocol suite. It looks like someone over at OSI model has decided that RTP is a session layer protocol. There's going to be some controversy about that because RTP is an IETF protocol so, strictly speaking, the OSI model does not apply. ~Kvng (talk) 21:27, 25 March 2020 (UTC)[reply]

capitals?

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

Probably not, since the capitalisation of the page matches RTP, the common initialism (a.k.a. acronym). --AlastairIrvine 04:18, 9 May 2007 (UTC)[reply]
MOS:CAPS doesn't call for caps just because an acronym is associated with the phrase. Reat-time Transport Protocol is capitalized because it is deemed to be a proper noun. ~KvnG 05:11, 14 July 2014 (UTC)[reply]

Usage?

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

I have added a sentence to the Overview section. ~Kvng (talk) 21:35, 25 March 2020 (UTC)[reply]

Packet structure

Packet structure has been pared to Packet header and Timestamp has a detailed description. ~Kvng (talk) 21:38, 25 March 2020 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

mathmatecial section?

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

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)[reply]

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)[reply]

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)[reply]

This appears to have been resolved with a book citation: ports 1024-65535. ~Kvng (talk) 21:41, 25 March 2020 (UTC)[reply]

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)[reply]

Abandoned GA reassessment (July 2009)

See: Talk:Real-time Transport Protocol/GA1 — Preceding unsigned comment added by [[User:{{{1}}}|{{{1}}}]] ([[User talk:{{{1}}}|talk]] • [[Special:Contributions/{{{1}}}|contribs]])

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)[reply]

Merge from RTP audio video profile

There's bee a merge banner on RTP audio video profile for a couple years. There has not been any discussion. ~KvnG 14:16, 27 January 2014 (UTC)[reply]

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 86.173.248.226 (talk) 09:05, 31 January 2014 (UTC)[reply]

I don't see any support for this merge. I have taken down the banners. ~KvnG 14:47, 17 February 2014 (UTC)[reply]

Closing GA nomination

I'm closing the GA nomination. The article is an incomplete and poorly organized collection of factoids that's of limited use the expert, let alone the layman. It would need a substantial rewrite to even pass for a mediocre article, let alone a good one.

Clogging up the already backlogged queue of GA nominations is unfair to the articles that actually stand a chance of passing the review. —Ruud 22:36, 3 September 2015 (UTC)[reply]

It is not your decision to make, it is the reviewers. I think it stands a chance because it makes sense in my opinion, it is a b class article already, and was good article two years ago. I agree that there is a backlog but I believe that this article stands a chance and you are not allowed to undo my nomination. Thanks Tortle (talk) 00:23, 6 September 2015 (UTC)[reply]
Tortle, your judgment in the GA space was shown to be faulty a week and a half ago, when you reviewed five articles and nominated seventeen in a matter of hours, all of which had to be reverted. I thought you would take plenty of time to become more acquainted with GA criteria and standards. Instead, you're now persisting in nominating an article that was delisted due to major deficiencies and has had little in the way of significant improvements since it was delisted. (Ruud notes that it is still incomplete, failing the "Broad in its coverage" criterion, and needs a substantial rewrite.) As I did with the others, I'm reverting your nomination. Please be patient, wait for the Lego review to continue, and learn what you can from the process there. If you do make additional nominations, please only do so to articles where you have been a major contributor, which is definitely not the case here. Thank you. BlueMoonset (talk) 01:18, 6 September 2015 (UTC)[reply]

Hello fellow Wikipedians,

I have just added archive links to one external link on Real-time Transport Protocol. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—cyberbot IITalk to my owner:Online 13:43, 27 February 2016 (UTC)[reply]

Hello fellow Wikipedians,

I have just added archive links to one external link on Real-time Transport Protocol. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—cyberbot IITalk to my owner:Online 17:03, 3 March 2016 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Real-time_Transport_Protocol&oldid=947367707"