Diskussion:Real-Time Transport Protocol

Transportprotokoll

Das TCP rechts ist meiner Meinung nach Falsch! RTP braucht ein Transportprotokoll, dass Framing unterstützt! Also z.B. UDP, UDP-lite, DCCP. Kommentare? Gruß, Konrad (nicht signierter Beitrag von 84.56.224.239 (Diskussion) 14:20, 19.02.2007)

erledigt von Benutzer:Kgfleischmann mit Änderung [vom 28.02.2007] --Uweschwoebel (Diskussion) 22:14, 1. Okt. 2019 (CEST)

Portnummern

Port 5060 ist doch SIP, oder? Meinem Verständnis nach hat RTP keine festen Ports. Im RFC steht meines Wissen nach nur > 1024. Gruß Nico (nicht signierter Beitrag von 84.58.166.39 (Diskussion) 12:06, 24.04.2007)

erledigt von Benutzer:Kgfleischmann mit Änderung vom 24.04.2007 --Uweschwoebel (Diskussion) 22:16, 1. Okt. 2019 (CEST)

Multicast

Interessant(?), Multicast linkt hierhin (Artikel), hier finde ich aber "Multicast" nicht mal erwähnt. (Kann mir jemand weiterhelfen?) --Alien4 20:11, 22. Mai 2007 (CEST)

Ich habe in den RTP-Artikel jetzt einmal den Hinweis auf Uni- oder Multicast-Tauglichkeit eingefügt - was ist sonst noch unklar im Zusammenhang mit Multicast und RTP, welche Erklärungen könnten noch Sinn machen? Mitten 01:06, 23. Mai 2007 (CEST)

Weder in Multicast, noch in IP-Multicast verstehe ich, wie (IP-)Multicast funktioniert. Falls (IP fähige ->) Endgeräte das Multicast bewerkstelligen (gibt es IP-Multicast fähige Router usw.?), ist das effizient, vor allem für (Live-)(Video, usw.)-Streams? -> RTP? Oder sollte man MBone beachten? Heisst das, IP-Multicasting ist für den Endbenutzer per se nicht anwendbar (RTP, (P2P-)IPTV, usw.)? --Alien4 01:11, 13. Jun. 2007 (CEST)

Ungenauigkeiten im Abschnitt Timestamp

Ich finde es gibt da Ungenauigkeiten bei der Formulierung im Abschnitt Timestamp. Wenn ich mir RFC3550 so ansehe, dann steht auf Seite 13: "The sampling instant MUST be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations." Im Wiki steht jedoch: " der nicht kontinuierlich und linear, sondern als diskreter Wert zur Verfügung steht". Irgendwie paßt das für mich nicht so richtig zusammen, bin mir aber unsicher. Kann das mal jemand durchdenken, der sich damit etwas besser auskennt?, Danke, --Cyx 14:59, 18. Sep. 2007 (CEST)

Ich bin genau wie Du stutzig geworden. Ich glaube da liegt ein Missverständnis vor. Möglicherweise wg. diesem Satz aus dem RFC: "Consecutive RTP packets MAY contain timestamps that are not monotonic if the data is not transmitted in the order it was sampled, as in the case of MPEG interpolated video frames."

Allerdings steht da eben "may contain", also dass es passieren kann...

Ich nehm' das "nicht" mal da raus und ergänze das ein bisschen. --Lllf 12:09, 23. Jan. 2008 (CET)

Verlinkung zu anderen RFCs (z.B. RFC 3984)

Mit RTP verknüpft ist auch RFC 3984, welcher definiert wie die Videodaten von H.264 Videos in der Payload eingepackt wird. Vielleicht könnte man diesen RFC im Text erwähnen. Meinungen? --MichaelK-osm (Diskussion) 17:58, 20. Mär. 2013 (CET)

RTP und DLNA-Renderer

Es gibt von der DLNA eine Norm für Digital Media Renderer, welche Audio-Daten über das Netzwerk beziehen und analog ausgeben. Kann man diese mit dem RTP-Protokoll ansprechen? In den Artikeln von DLNA und Pulsaudio fehlt leider ein Hinweis auf RTP und deren Kompatibilität. --Dr Joerg Weule (Diskussion) 09:04, 18. Apr. 2013 (CEST)

Reihenfolge der Bits

Also ich bin der Meinung, dass die Bits in der Tabelle zum Header gedreht werden müssen. Ich kann leider keine Belege dazu finden. Aber ich programmiere das hier gerade nach und sehe ja, wie die Bits ankommen. Und nur gedreht ergibt das hier Sinn. (nicht signierter Beitrag von Zislu (Diskussion | Beiträge) 13:34, 26.11.2018)

Die Darstellung ist schon richtig so, siehe RFC3550 Abschnitt 5.1. In Abschnitt 4 steht drin, warum bei die Bits andersrum ankommen: "All integer fields are carried in network byte order, that is, most significant byte (octet) first.". --Uweschwoebel (Diskussion) 10:26, 27. Nov. 2018 (CET)

Ich meine ja auch die Bits und nicht die Bytes. z.B. ist die Version (die immer als 2 daherkommt) in den Bits 7 und 6 des Byte 0 und nicht wie hier dargestellt in den Bits 0 und 1. (nicht signierter Beitrag von Zislu (Diskussion | Beiträge) 14:27, 27.11.2018)

Ich kann Deine Angaben nicht nachvollziehen.

In RFC 3550 ist unter 5.1 Fixed Header Fields der Header-Aufbau beschrieben und unter 4. Byte-Order, Alignment and Time Format wird im ersten Abschnitt auf RFC 791 Appendix B: Data Transmission Order in der die Byte-Reihenfolge und die Bit-Reihenfolge festgelegt ist: Fig. 10 und Fig. 11. Daraus ergibt sich m. E., dass die Darstellung wie sie im Artikel gezeigt ist, korrekt ist, was auch der in Literatur und Netzanalysesoftware (WireShark) üblichen Darstellung entspricht. Also lassen wir das erstmal so. --Uweschwoebel (Diskussion) 23:43, 1. Okt. 2019 (CEST)

Falls Du auf Ethernet-Ebene arbeitest, musst Du berücksichtigen, dass Ethernet das niedrigwertigste Bit eines Bytes zuerst überträgt, siehe Ethernet#Aufbau. --Uweschwoebel (Diskussion) 11:23, 17. Mär. 2024 (CET)

Auf welcher OSI-Schicht?

Mir hat jemand einen Link gegeben (Tabelle "Voice over IP im OSI-Schichtenmodell" in der Mitte des Texts) und auch glaubhaft versichert, dass RTP in der Transportschicht (Schicht 3 im OSI-Modell) arbeitet und nicht in der Anwendungsschicht (Schicht 7 im OSI-, Schicht 4 im TCP/IP-Modell). Ich bin verunsichert, stimmt das? Denn außer dieser Quelle wird es immer in der Anwendungsschicht/Sitzungsschicht angeordnet. Hier ja auch. (Edit: Hier ein weiterer Link, der RTP in der Transportschicht anordnet) --Heronils (Diskussion) 13:00, 14. Mär. 2024 (CET)

In RFC 3550 "RTP: A Transport Protocol for Real-Time Applications" steht, Zitat: "Applications typically run RTP on top of UDP to make use of its multiplexing and checksum services, ...", ist also meistens oberhalb der Transportschicht angesiedelt. Ich hab's jedenfalls (in D) noch nicht anders gesehen; was auch bei Untersuchung von Paketmitschnitten leicht festgestellt werden kann. RTP kann statt über Transportprotokolle aber auch, wie in Abschnitt 11 beschrieben, über Netzwerkprotokolle übertragen werden, Zitat: "... to carrying RTP packets within particular network and transport protocols." Wer das so kennt, kann mir das gerne mal zeigen; bin da sehr interessiert dazu zu lernen. --Uweschwoebel (Diskussion) 12:39, 16. Mär. 2024 (CET)

Ich stelle mir das mittlerweile so vor, dass RTP UDP kapselt, aber das geschieht innerhalb der Transportschicht. Ist wohl so ähnlich wie in der Sicherungsschicht, die auch in LLC und MAC unterteilt ist. --Heronils (Diskussion) 09:01, 20. Mär. 2024 (CET)