Protokol Transpor Waktu Nyata: Perbedaan antara revisi
Konten dihapus Konten ditambahkan
Tidak ada ringkasan suntingan |
k →Header paket: clean up |
||
| (16 revisi perantara oleh 4 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. 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>
Baris 6 ⟶ 26:
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>
==
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>
RTP didesain sebagai ''end-to-end'',
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).
▲== Desain RTP ==
* [[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>
▲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. 28–7. ISBN 978-0-8493-1985-3.</nowiki></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
!''
!Oktet
! colspan="8" |0
! colspan="8" |1
Baris 23 ⟶ 57:
! colspan="8" |3
|-
!Oktet
! Bit {{efn|
! 0
!1
Baris 60 ⟶ 94:
!0
! 0
| colspan="2" |
| colspan="1" |P
| colspan="1" |X
Baris 66 ⟶ 100:
| colspan="1" |M
| colspan="7" |PT
| colspan="16" |
|- align="center"
!4
! colspan="1" |32
| colspan="34" |
|- align="center"
!8
! 64
| colspan="34" |
|- align="center"
!12
! 96
| colspan="34" bgcolor="#FFBBBB" |
|- align="center"
!12+4×CC
! 96+32×CC
| colspan="16" bgcolor="#FFBBBB" |
| colspan="16" bgcolor="#FFBBBB" |
|-
!16+4×CC
! 128+32×CC
| colspan="34" bgcolor="#FFBBBB" |
|}
Header RTP mempunyai kapasitas minimum 12 bita. Setelah header, ekstensi header opsional mungkin ada. Ini diikuti oleh payload RTP, yang formatnya ditentukan oleh kelas aplikasi tertentu.<ref>{{harvnb|Peterson|2007|p=430}}</ref> Bidang di header adalah sebagai berikut:
* '''
* '''P (Padding)''': (1 bit) Digunakan untuk mengidentifikasikan jika terdapat bita padding tambahan pada akhir paket RTP. Sebuah padding dapat digunakan untuk mengisi sebuah blok dari ukuran tertentu, seabgai contoh seperti yang disyaratkan oleh algoritma enkripsi. Bita terakhir dari padding berisi jumlah bita padding yang ditambahkan (termasuk bita itu sendiri).<ref name="peterson_431"/><ref name=RFC3550/>{{rp|12}}
* '''X (Extensi)''': (1 bit) Menunjukkan adanya ''header Ekstensi'' antara header standar dan data payload. Ini khusus untuk aplikasi atau profil.<ref name="peterson_431"/>
* '''CC (CSRC Count)''': (4 bit) Terdiri nomor-nomor dari pengidentifikasi CSRC (didefinisikan di bawah) yang mengikuti header tetap.<ref name=RFC3550/>
* '''M (Marker)''': (1 bit) Digunakan pada tingkat aplikasi dan ditentukan oleh profil. Jika ditentukan, berarti data terkini mempunyai relevansi khusus untuk aplikasi.<ref name=RFC3550/>
* '''PT (Payload Type)''': (7
* '''Nomor Urut''': (16 bit) Nomor urut bertambah satu untuk setiap paket data RTP yang dikirim dan digunakan oleh penerima untuk mendeteksi paket hilang dan memulihkan urutan paket. RTP tidak menentukan tindakan apa pun terhadap kehilangan paket; ini diserahkan kepada aplikasi untuk mengambil tindakan yang sesuai. Sebagai contoh, aplikasi video dapat memutar ''frame'' terakhir yang diketahui menggantikan ''frame'' yang hilang.<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> Menurut RFC 3550, nilai awal nomor urut harus acak untuk mempersulit serangan enkripsi teks diketahui pada Protokol Transportasi Waktu-nyata Aman lebih sulit.<ref name="Hardy_298"/><ref name=RFC3550/>
* '''Stempel waktu''': (32 bit) Digunakan untuk memungkinkan penerima memutar ulang sampel yang diterima pada interval yang tepat. Jika ada beberapa aliran media, stempel waktunya bersifat independen di setiap aliran, dan mungkin tidak dapat diandalkan untuk sinkronisasi media. Granularitas dari waktunya bergantung pada aplikasi tertentu. Sebagai contoh, sebuah aplikasi audio yang mengambil sampel data setiap125 µs (8 kHz, sebuah laju sampel umum dalam telepon digital) kali dapat menggunakan nilainya sebagai resolusi ''clock''nya. Granularitas ''clock'' adalah salah satu detail yang ditentukan dalam profil RTP untuk suatu aplikasi.<ref name="peterson_432"/>
* '''SSRC''': (32 bit) Pengidentifikasi sumber sinkronisasi secara unik mengidentifikasi sumber aliran. Sumber sinkronisasi dalam sesi RTP yang sama akan menjadi unik.<ref name=RFC3550/>
* '''CSRC''': (setiap 32 bit) ID sumber yang berkontribusi menyebutkan sumber yang berkontribusi pada aliran yang dihasilkan dari berbagai sumber.<ref name=RFC3550/>
* '''Header ekstensi''': (opsional) Kata 32-bit pertama terdiri sebuah pengidentifikasi khusus profil (16 bit) dan penentu panjang (16 bit) yang menunjukkan panjang ekstensi (EHL=panjang header ekstensi) dalam unit 32-bit, tidak termasuk 32 bit dari header ekstensi.<ref name=RFC3550/>
== Desain aplikasi ==
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>
▲* '''Version''': (2 bits) Indicates the version of the protocol. Current version is 2.<ref name="peterson_431">{{harvnb|Peterson|2007|p=431}}</ref>
▲* '''PT (Payload Type)''': (7 bits) Indicates the format of the payload and determines its interpretation by the application. This is specified by an RTP profile. For example, see ''RTP Profile for audio and video conferences with minimal control'' (RFC 3551).<ref>{{harvnb|Perkins|2003|p=59}}</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).{{Citation-needed}}▼
▲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).
== Dokumen standar ==
Baris 146 ⟶ 180:
[[Kategori:Internet]]
[[Kategori:Protokol jaringan audio]]
[[Kategori:Protokol VoIP]]
| |||