Protokol Transpor Waktu Nyata: Perbedaan antara revisi

Konten dihapus Konten ditambahkan
k bentuk baku using AWB
k →‎Header paket: clean up
 
(24 revisi perantara oleh 9 pengguna tidak ditampilkan)
Baris 1:
{{Terjemahan buruk}}
{{Infobox networking protocol
|title=Real-time Transport Protocol
|logo=
|logo alt=
|image=
|image alt=
|caption=
|is stack=No
|abbreviation=RTP
|purpose= Mengantarkan audio dan video
|developer=Audio-Video Transport Working Group dari [[Internet Engineering Task Force|IETF]]
|date={{Start date and age|1996|01}}
|based on=[[Protokol jaringan suara]]{{sfn|Perkins|2003|p=6}}
|influenced=
|osilayer=
|ports=
|rfcs={{IETF RFC|1889|3550|3551}}
|hardware=
}}
 
'''Real-time Transport Protocol''' ('''RTP''') didefinisikan sebagai standardisasi paket untuk mengirimkan audio dan video pada jaringan IP.<ref>Daniel Hardy (2002). ''Network''. De Boeck Université. p.&nbsp;298.</ref> RTP digunakan untuk komunikasi dan sistem entertain yang termasuk didalamnya streaming media seperti telepony, aplikasi video teleconfrence dan web yang memiliki fitur berbasis push-to-talk.<ref name="Hardy_298">{{Cite book|author=Daniel Hardy|title=Network|page= [http://books.google.com/books?id=Oq8SEUW1wdQC&pg=PT320 298]|publisher= De Boeck Université|year= 2002}}</ref>
 
RTP biasanya berjalan melalui [[User Datagram Protocol]] (UDP). RTP digunakan bersama dengan [[RTP Control Protocol]] (RTCP). Sedangkan RTP membawa aliran media (misalnya audio dan video), RTCP digunakan untuk memonitor statistik transmisi dan [[quality of service]] (QoS) dan membantu sinkronisasi beberapa aliran. RTP adalah salah satu landasan teknis Voice over IP dan dalam konteks ini sering digunakan bersama dengan protokol pensinyalan seperti [[Session Initiation Protocol]] (SIP) yang membangun koneksi di seluruh jaringan.
== Penggunaan RTP ==
RTP digunakan sebagai penghubung dengan RTP Control Protocol (RTCP). Ketika RTP membawa media stream (cth: audio dan video), RTCP berfungsi untuk memonitor statistik dari transmisi dan Quality of Service (QoS) dan membantu sinkronisasi multiple stream- Ketika kedua protokol digunakan dalam conjunction, RTP dihasilkan dan diterima pada nomor port genap dan komunikasi RTCP yang menghubungkannya memggunakan nomor port ganjil yang lebih tinggi. Protokol RTP ini adalah salah satu pondasi penting untuk komunikasi Voice over IP (VoIP) dan pada konteks ini biasa digunakan pada hubungan dengan protokol signaling yang membantu untuk pengaturan koneksi diseluruh jaringan. RTP dikembangkan oleh Audio Video Transport Working Group dari Internet Engineering Task Force (IETF) dan pertama dipublish pada tahun 1996 <nowiki>dikenal dengan RFC 1889, lalu digantikan dengan RFC 3550 pada tahun 2003. RTP digunakan sebagai penghubung dengan protokol Iainnya seperti H323 dan RTSP. Pada dasamya, RTP didefinisikan sebagai pasangan protocol, RTP dan RTCP- RTP digunakan untuk media transfer data multimedia dan RTCP digunakan secara periodik untuk mengirimkan informasi kontrol dan juga parameter QoS.<ref name=RFC3550>RFC 3550</ref>{{rp|71}}
 
RTP dikembangkan oleh Audio-Video Transport Working Group dari [[Internet Engineering Task Force]] (IETF) dan pertama kali dipublikasikan pada 1996 sebagai {{IETF RFC|1889}} yang kemudian digantikan oleh {{IETF RFC|3550}} pada 2003.<ref>{{Cite web|last=Wright|first=Gavin|title=What is the Real-time Transport Protocol (RTP)?|url=https://www.techtarget.com/searchnetworking/definition/Real-Time-Transport-Protocol|website=TechTarget|language=en|access-date=2022-11-10}}</ref>
== Desain RTP ==
RTP didesain sebagai end-to-end, realtime, dan transfer stream data. Protokol ini dilengkapi dengan jitter sebagai kompensasi dan sebagai deteksi dari urutan kedatangan dalam data yang biasa ditemukan dalam transmisi di jaringan IP- RTP mendukung transfer data ke beberapa tujuan secara multicast. RTP dianggap sebagai standar utama untuk transportasi audio/video pada jaringan IP dan digunakan profil yang terkait dan format payload.<ref>Zurawski, Richard (2004). "RTP, RTCP and RTSP protocols". ''The industrial information technology handbook''<nowiki>. CRC Press. pp.&nbsp;28–7. ISBN 978-0-8493-1985-3.</nowiki></ref>
 
== Packet Header RTPIkhtisar ==
Penelitian pada audio dan video melalui jaringan ''packet-switched'' sudah ada sejak awal tahun 1970an. [[Internet Engineering Task Force]] (IETF) mempublikasikan {{IETF RFC|741}} pada 1977 dan memulai mengembangkan RTP pada 1992,{{sfn|Perkins|2003|p=6}} dan akan terus mengembangkan [[Protokol Pengumuman Sesi|Session Announcement Protocol]] (SAP), [[Protokol Deskripsi Sesi|Session Description Protocol]] (SDP), dan [[Protokol Inisiasi Sesi|Session Initiation Protocol]] (SIP).
 
RTP digunakan sebagai penghubung dengan RTP Control Protocol (RTCP). Ketika RTP membawa media stream (cth: audio dan video), RTCP berfungsi untuk memonitor statistik dari transmisi dan Quality of Service (QoS) dan membantu sinkronisasi multiple stream- Ketika kedua protokol digunakan dalam conjunction, RTP dihasilkan dan diterima pada nomor port genap dan komunikasi RTCP yang menghubungkannya memggunakan nomor port ganjil yang lebih tinggi.
 
Sebuah sesi RTP biasanya dimulai antara rekan-rekan yang berkomunikasi menggunakan protokol pensinyalan, seperti H.323, [[Session Initiation Protocol]] (SIP), RTSP, atau [[Jingle (protocol)|Jingle]] ([[XMPP]]). Protokol ini dapat menggunakan [[Session Description Protocol]] untuk menentukan parameter sesi.<ref>{{IETF RFC|4566}}: ''SDP: Session Description Protocol'', M. Handley, V. Jacobson, C. Perkins, IETF (July 2006)</ref>
 
RTP dikembangkan oleh Audio/Video Transport Working Group dari organisasi standar IETF. RTP digunakan bersama dengan protokol lain seperti [[H.323]] dan [[RTSP]].<ref name="Perkins_55">{{harvnb|Perkins|2003|p=55}}</ref> Spesifikasi RTP menjelaskan dua protokol: RTP dan RTCP. RTP digunakan untuk mentransfer data multimedia, dan RTCP digunakan untuk mengirimkan informasi kontrol dan parameter QoS secara berkala.<ref name="Peterson_430" />
 
Pada dasamya, RTP didefinisikan sebagai pasangan protocol, RTP dan RTCP- RTP digunakan untuk media transfer data multimedia dan RTCP digunakan secara periodik untuk mengirimkan informasi kontrol dan juga parameter QoS.<nowiki><ref name=RFC3550>RFC 3550</ref></nowiki><nowiki>{{rp|71}}</nowiki>
 
== Desain dan format payload ==
RTP didesain sebagai ''end-to-end'', waktu nyata, dan transfer stream data. Protokol ini dilengkapi dengan jitter sebagai kompensasi dan sebagai deteksi dari urutan kedatangan dalam data yang biasa ditemukan dalam transmisi di jaringan IP- RTP mendukung transfer data ke beberapa tujuan secara multicast. RTP dianggap sebagai standar utama untuk transportasi audio/video pada jaringan IP dan digunakan profil yang terkait dan format payload.<ref name="Peterson_4302">{{Cite book|author=Larry L. Peterson|year=2007|title=Computer Networks|publisher=Morgan Kaufmann|isbn=978-1-55860-832-0|page=[https://books.google.com/books?id=zGVVuO-6w3IC&pg=PA430 430]}}</ref>, RTCP and RTSP protocols".<ref name="RFC35502">{{IETF RFC|3550}}</ref>{{rp|71}}
 
Contoh dari desain RTP termasuk:
 
* ''Desain RTP untuk Audio dan konferensi video dengan kontrol minimal'' ({{IETF RFC|3551}}) mendefinisikan sekumpulan penetapan jenis muatan statis, dan sebuah mekanisme dinamis untuk pemetaan a antara format muatan, dan nilai PT menggunakan [[Session Description Protocol]] (SDP).
* [[Secure Real-time Transport Protocol]] (SRTP) ({{IETF RFC|3711}}) mendefinisikan desain RTP yang menyediakan layanan [[Cryptography|kriptografi]] untuk transfer data muatan.<ref>{{harvnb|Perkins|2003|p=367}}</ref>
* ''Control Data Profile untuk RTP'' (RTP/CDP) eksperimental untuk komunikasi [[Mesin ke mesin|mesin-ke-mesin]].<ref name="Breese2010">{{Cite book|last=Breese|first=Finley|year=2010|title=Serial Communication over RTP/CDP|publisher=BoD - Books on Demand|isbn=978-3-8391-8460-8|pages=[https://books.google.com/books?id=t18ehd_vM6wC&lpg=PP1&pg=PA9]}}</ref>
 
== Header paket ==
Paket RTP dibuat pada lapisan aplikasi dan diberikan ke lapisan pengiriman untuk dikirim. Setiap unit data media RTP yang dibuat oleh aplikasi dimulai dengan header paket RTP.
{| class="wikitable" style="text-align:center"
|+Header paket RTP
|+RTP packet header
!''Offset''
!Oktet
! colspan="8" |0
! colspan="8" |1
! colspan="8" |2
! colspan="8" |3
|-
!Oktet
! Bit offset{{efn|Bits are ordered most significant to least significant; bit offset 0 is the most significant bit of the first octet. Octets are transmitted in [[network order]]. Bit transmission order is medium dependent.}}
! Bit {{efn|Bit diurutkan dari yang paling signifikan hingga yang paling tidak signifikan; bit offset 0 adalah bit paling signifikan dari oktet pertama. Oktet ditransmisikan dalam [[urutan jaringan]]. Urutan transmisi bit bergantung pada medium.}}
! colspan="2"| 0-1
! 0
!1
! colspan="1" | 2
! colspan="1" | 3
!4
! colspan="4"| 4-7
!5
!6
!7
! colspan="1" | 8
!9
! colspan="6" | 9-15
!10
! colspan="15" | 16-31
!11
!12
!13
!14
!15
!16
!17
!18
!19
!20
!21
!22
!23
!24
!25
!26
!27
!28
!29
!30
!31
|- align="center"
!0
! 0
| colspan="2" |VersionVersi
| colspan="1" |P
| colspan="1" |X
| colspan="4" |CC
| colspan="1" |M
| colspan="67" |PT
| colspan="1516" |Sequence''Nomor Numberurut''
|- align="center"
!4
! colspan="1"|32
|! colspan="321" |Timestamp32
| colspan="34" |Stempel waktu
|- align="center"
!8
! 64
| colspan="3234" |SSRCPengidentifikasi identifierSSRC
|- align="center"
!12
! 96
| colspan="3234" bgcolor="#FFBBBB" |CSRCPengidentifikasi identifiersCSRC<br />...
|- align="center"
!12+4×CC
! 96+32×CC
| colspan="16" bgcolor="#FFBBBB" |Profile-specific extensionID header IDekstensi khusus profil
| colspan="16" bgcolor="#FFBBBB" |ExtensionPanjang header lengthekstensi
|-
!16+4×CC
! 128+32×CC
| colspan="3234" bgcolor="#FFBBBB" |ExtensionHeader headerekstensi<br />...
|}
 
TheHeader RTP headermempunyai has akapasitas minimum size of 12 bytesbita. After theSetelah header, optionalekstensi header extensionsopsional maymungkin be presentada. ThisIni isdiikuti followedoleh by thepayload RTP payload, theyang formatformatnya ofditentukan whicholeh iskelas determinedaplikasi by the particular class of applicationtertentu.<ref>{{harvnb|Peterson|2007|p=430}}</ref> The fields inBidang thedi header areadalah assebagai followsberikut:
* '''VersionVersi''': (2 bitsbit) IndicatesMenunjukkan theversi versionprotokol. of the protocol.Versi Currentsaat versionini isadalah 2.<ref name="peterson_431">{{harvnb|Peterson|2007|p=431}}</ref>
* '''P (Padding)''': (1 bit) UsedDigunakan tountuk indicatemengidentifikasikan ifjika thereterdapat are extrabita padding bytestambahan atpada theakhir end of thepaket RTP packet. ASebuah padding mightdapat bedigunakan useduntuk tomengisi fillsebuah upblok adari blockukuran of certain sizetertentu, forseabgai examplecontoh asseperti requiredyang bydisyaratkan anoleh encryptionalgoritma algorithmenkripsi. TheBita lastterakhir byte of thedari padding containsberisi thejumlah number ofbita padding bytesyang thatditambahkan were(termasuk addedbita (includingitu itselfsendiri).<ref name="peterson_431"/><ref name=RFC3550/>{{rp|12}}
* '''X (ExtensionExtensi)''': (1 bit) IndicatesMenunjukkan presence of anadanya ''Extensionheader headerEkstensi'' between standardantara header andstandar payloaddan data payload. ThisIni iskhusus applicationuntuk oraplikasi profileatau specificprofil.<ref name="peterson_431"/>
* '''CC (CSRC Count)''': (4 bitsbit) ContainsTerdiri thenomor-nomor numberdari ofpengidentifikasi CSRC identifiers (defineddidefinisikan belowdi bawah) thatyang followmengikuti theheader fixed headertetap.<ref name=RFC3550/>{{rp|12}}
* '''M (Marker)''': (1 bit) UsedDigunakan atpada thetingkat applicationaplikasi leveldan andditentukan definedoleh by a profileprofil. IfJika it is setditentukan, it means that the currentberarti data has someterkini specialmempunyai relevancerelevansi forkhusus theuntuk applicationaplikasi.<ref name=RFC3550/>{{rp|13}}
* '''PT (Payload Type)''': (7 bitsbit) Indicates theMengidentifikasi format of thedari payload anddan determinesmenentukan itsinterpretasinya interpretationdengan by the applicationaplikasi. ThisIni isditentukan specifiedoleh by anprofil RTP profile. For exampleMisalnya, seelihat ''RTP Profile for audio and video conferences with minimal control'' (RFC 3551).<ref>{{harvnb|Perkins|2003|p=59}}</ref>
* '''SequenceNomor NumberUrut''': (16 bitsbit) TheNomor sequenceurut numberbertambah issatu incrementeduntuk bysetiap onepaket for eachdata RTP datayang packetdikirim sentdan anddigunakan isoleh topenerima beuntuk usedmendeteksi bypaket thehilang receiverdan tomemulihkan detecturutan packet loss and to restore packet sequencepaket. The RTP doestidak notmenentukan specifytindakan anyapa actionpun onterhadap packetkehilangan losspaket; itini isdiserahkan leftkepada toaplikasi theuntuk applicationmengambil totindakan takeyang appropriate actionsesuai. ForSebagai examplecontoh, aplikasi video applicationsdapat maymemutar play''frame'' theterakhir lastyang knowndiketahui menggantikan ''frame'' inyang place of the missing framehilang.<ref name="peterson_432">Peterson, p.[http://books.google.com/books?id=zGVVuO-6w3IC&pg=PA432 432]{{Pranala mati|date=Februari 2023 |bot=InternetArchiveBot |fix-attempted=yes }}</ref> According toMenurut RFC 3550, thenilai initialawal valuenomor ofurut theharus sequenceacak numberuntuk shouldmempersulit beserangan randomenkripsi toteks makediketahui [[known-plaintextpada attack]]sProtokol onTransportasi [[encryption]]Waktu-nyata moreAman difficultlebih sulit.<ref name=RFC3550"Hardy_298"/>{{rp|13}} RTP provides no guarantee of delivery, but the presence of sequence numbers makes it possible to detect missing packets.<ref name="Hardy_298"RFC3550/>
* '''TimestampStempel waktu''': (32 bitsbit) UsedDigunakan tountuk enablememungkinkan thepenerima receivermemutar toulang playsampel backyang thediterima receivedpada samplesinterval atyang appropriate intervalstepat. WhenJika severalada mediabeberapa streamsaliran are presentmedia, thestempel timestampswaktunya arebersifat independentindependen indi eachsetiap streamaliran, anddan maymungkin nottidak bedapat relieddiandalkan uponuntuk forsinkronisasi media synchronization. The granularityGranularitas ofdari thewaktunya timingbergantung ispada applicationaplikasi specifictertentu. ForSebagai examplecontoh, ansebuah aplikasi audio applicationyang thatmengambil samplessampel data once every 125setiap125&nbsp;µs (8&nbsp;kHz, asebuah commonlaju samplesampel rateumum indalam digitaltelepon telephonydigital) wouldkali usedapat thatmenggunakan valuenilainya assebagai itsresolusi ''clock resolution''nya. TheGranularitas ''clock'' granularityadalah issalah onesatu ofdetail theyang detailsditentukan thatdalam is specified in theprofil RTP profile foruntuk ansuatu applicationaplikasi.<ref name="peterson_432"/>
* '''SSRC''': (32 bitsbit) SynchronizationPengidentifikasi sourcesumber identifiersinkronisasi uniquelysecara identifiesunik themengidentifikasi sourcesumber of a streamaliran. TheSumber synchronizationsinkronisasi sourcesdalam withinsesi theRTP same RTPyang sessionsama willakan bemenjadi uniqueunik.<ref name=RFC3550/>{{rp|15}}
* '''CSRC''': (setiap 32 bits eachbit) Contributing sourceID IDssumber enumerateyang contributingberkontribusi sourcesmenyebutkan tosumber ayang streamberkontribusi whichpada hasaliran beenyang generateddihasilkan fromdari multipleberbagai sourcessumber.<ref name=RFC3550/>{{rp|15}}
* '''Header extensionekstensi''': (optionalopsional) The firstKata 32-bit wordpertama containsterdiri asebuah profile-specificpengidentifikasi identifierkhusus profil (16 bitsbit) anddan apenentu length specifierpanjang (16 bitsbit) thatyang indicatesmenunjukkan thepanjang length of the extensionekstensi (EHL=extensionpanjang header lengthekstensi) indalam unit 32-bit units, excludingtidak thetermasuk 32 bitsbit of the extensiondari header ekstensi.<ref name=RFC3550/>{{rp|17}}
 
== AplikasiDesain RTPaplikasi ==
Sebuah aplikasi multimedia fungsional memerlukan protokol dan standar lainnya yang digunakan bersama dengan RTP. Protokol seperti SIP, [[Jingle (protokol)|Jingle]], RTSP, [[H.225]] and [[H.245]] digunakan untuk inisiasi, kontrol, dan penghentian sesi. Standar lainnya, seperti H.264, MPEG dan H.263, digunakan untuk menyandikan data payload seperti yang ditentukan oleh profil RTP yang berlaku.<ref name="perkins_11">{{harvnb|Perkins|2003|pp=11–13}}</ref>
Aplikasi multimedia real-time streaming memerlukan pengiriman informasi secara tepat waktu
 
dan dapat mentolerir hilangnya beberapa paket (packet loss) untuk mencapai tujuan/destination. Sebagai contoh, kehilangan paket pada aplikasi audio dapat mengakibatkan kehilangan sepersekian detik data audio yang dapat dibuat tidak diketahui dengan suatu algoritme penyembunyian kesalahan yang cocok. Transport Control Protocol (TCP), walaupun suatu standar untuk penggunaan RTP, biasanya tidak digunakan pada aplikasi RTP karena TCP menuntut keandalan atas ketepatan waktu. Alih-alih, mayoritas implementasi RTP dibangun pada User Datagram Protocol (UDP).
Aplikasi multimedia real-time streaming memerlukan pengiriman informasi secara tepat waktu dan dapat mentolerir hilangnya beberapa paket (packet loss) untuk mencapai tujuan/destination. Sebagai contoh, kehilangan paket pada aplikasi audio dapat mengakibatkan kehilangan sepersekian detik data audio yang dapat dibuat tidak diketahui dengan suatu algoritme penyembunyian kesalahan yang cocok. Transport Control Protocol (TCP), walaupun suatu standar untuk penggunaan RTP, biasanya tidak digunakan pada aplikasi RTP karena TCP menuntut keandalan atas ketepatan waktu. Alih-alih, mayoritas implementasi RTP dibangun pada User Datagram Protocol (UDP).{{Citation-needed}}
 
== Dokumen standar ==
* RFC 1889, ''RTP: Protokol Transportasi untuk Aplikasi Real-Time'', Usang oleh RFC 3550.
* RFC 3550, Standar 64, ''RTP: Protokol Transportasi untuk Aplikasi Real-Time''
* RFC 3551, Standar 65, ''Profil RTP untuk Konferensi Audio dan Video dengan Kontrol Minimal''
* RFC 3190, ''Format Payload RTP untuk Audio DAT 12-bit dan Audio Sampel Linier 20- dan 24-bit''
* RFC 6184, ''Format Muatan RTP untuk Video H.264''
* RFC 4103, ''Format Payload RTP untuk Percakapan Teks''
* RFC 3640, ''Format Payload RTP untuk Pengantaran Aliran Dasar MPEG-4''
* RFC 6416, ''Format Payload RTP untuk Aliran Audio/Visual MPEG-4''
* RFC 2250, ''Format Payload RTP untuk Video MPEG1/MPEG2''
* RFC 4175, ''Format Payload RTP untuk Video Tidak Terkompresi''
* RFC 6295, ''Format Payload RTP untuk MIDI''
* RFC 4696, ''Panduan Implementasi untuk RTP MIDI''
* RFC 7587, ''Format Payload RTP untuk Pidato Opus dan Codec Audio''
 
== Catatan ==
{{Notelist}}
 
== Acuan Standar Dokumen ==
* RFC 1889, ''RTP: A Transport Protocol for Real-Time Applications'', Obsoleted by RFC 3550.
* RFC 3550, Standard 64, ''RTP: A Transport Protocol for Real-Time Applications''
* RFC 3551, Standard 65, ''RTP Profile for Audio and Video Conferences with Minimal Control''
* RFC 3190, ''RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio''
* RFC 6184, ''RTP Payload Format for H.264 Video''
* RFC 4103, ''RTP Payload Format for Text Conversation''
* RFC 3640, ''RTP Payload Format for Transport of MPEG-4 Elementary Streams''
* RFC 6416, ''RTP Payload Format for MPEG-4 Audio/Visual Streams''
* RFC 2250, ''RTP Payload Format for MPEG1/MPEG2 Video''
* RFC 4175, ''RTP Payload Format for Uncompressed Video''
* RFC 6295, ''RTP Payload Format for MIDI''
* RFC 4696, ''An Implementation Guide for RTP MIDI''
* RFC 7587, ''RTP Payload Format for the Opus Speech and Audio Codec''
== Pranala luar ==
# http://www.networksorcery.com/enp/protocol/rtp.htm
== Referensi ==
{{Reflist}}{{refbegin}}
{{reflist}}
* {{Cite book|last=Perkins|first=Colin|year=2003|url=https://books.google.com/books?id=OM7YJAy9_m8C|title=RTP: Audio and Video for the Internet|publisher=Addison-Wesley|isbn=978-0-672-32249-5}}
* {{Cite book|last1=Peterson|first1=Larry L.|last2=Davie|first2=Bruce S.|year=2007|title=Computer Networks|publisher=Morgan Kaufmann|isbn=978-0-12-374013-7|edition=4}}
{{refend}}
 
== Bacaan lanjutan ==
 
* {{Cite book|year=2005|title=Network Protocols Handbook|publisher=Javvin Technologies|isbn=978-0-9740945-2-6|chapter=RTP|chapter-url=https://books.google.com/books?id=D_GrQa2ZcLwC&pg=PA144}}
 
== Pranala luar ==
 
* [https://www.cs.columbia.edu/~hgs/rtp Halaman RTP Henning Schulzrinne] (termasuk [https://www.cs.columbia.edu/~hgs/rtp/faq.html FAQ])
* [https://www.gnu.org/software/ccrtp/ GNU ccRTP]
* [http://research.edm.uhasselt.be/~jori/page/index.php?n=CS.Jrtplib JRTPLIB, sebuah pustaka RTP C++]
* [http://net7mma.codeplex.com Managed Media Aggregation] {{Webarchive|url=https://web.archive.org/web/20180109033607/http://net7mma.codeplex.com/|date=2018-01-09}}: [[.NET Framework|.NET]] [[C Sharp (bahasa pemrograman)|C#]] Implementasi RTP / RTCP yang sesuai dengan RFC ditulis dalam kode yang dikelola sepenuhnya.
* {{Citation|publisher=Ministry of Human resources, India|title=Broadband Networks|chapter=RTP|chapter-url=https://www.youtube.com/watch?v=OaL2vVFbCG4&feature=channel_page|archive-url=https://ghostarchive.org/varchive/youtube/20211118/OaL2vVFbCG4|archive-date=2021-11-18|url-status=live|year=2008}}{{cbignore}}
<references group="lower-alpha"/>
 
[[Kategori:Internet]]
[[Kategori:Protokol jaringan audio]]
[[Kategori:Protokol VoIP]]