Lompat ke isi

Protokol Transpor Waktu Nyata

Dari Wikipedia bahasa Indonesia, ensiklopedia bebas
Protokol Transpor Waktu Nyata
Protokol komunikasi
SingkatanRTP
TujuanMengantarkan audio dan video
PengembangAudio-Video Transport Working Group dari IETF
DiperkenalkanJanuari 1996; 28 tahun lalu (1996-01)
BerdasarkanProtokol jaringan suara[1]
RFCRFC 1889, 3550, 3551

Real-time Transport Protocol (RTP) didefinisikan sebagai standardisasi paket untuk mengirimkan audio dan video pada jaringan IP.[2] 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.[3]

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.

RTP dikembangkan oleh Audio-Video Transport Working Group dari Internet Engineering Task Force (IETF) dan pertama kali dipublikasikan pada 1996 sebagai RFC 1889 yang kemudian digantikan oleh RFC 3550 pada 2003.[4]

Ikhtisar

[sunting | sunting sumber]

Penelitian pada audio dan video melalui jaringan packet-switched sudah ada sejak awal tahun 1970an. Internet Engineering Task Force (IETF) mempublikasikan RFC 741 pada 1977 dan memulai mengembangkan RTP pada 1992,[1] dan akan terus mengembangkan Session Announcement Protocol (SAP), Session Description Protocol (SDP), dan 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 (XMPP). Protokol ini dapat menggunakan Session Description Protocol untuk menentukan parameter sesi.[5]

RTP dikembangkan oleh Audio/Video Transport Working Group dari organisasi standar IETF. RTP digunakan bersama dengan protokol lain seperti H.323 dan RTSP.[6] 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.[7]

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}}

Desain dan format payload

[sunting | sunting sumber]

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.[8], RTCP and RTSP protocols".[9]:71

Contoh dari desain RTP termasuk:

Header paket

[sunting | sunting sumber]

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.

Header paket RTP
Offset Oktet 0 1 2 3
Oktet Bit [a] 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Versi P X CC M PT Nomor urut
4 32 Stempel waktu
8 64 Pengidentifikasi SSRC
12 96 Pengidentifikasi CSRC
...
12+4×CC 96+32×CC ID header ekstensi khusus profil Panjang header ekstensi
16+4×CC 128+32×CC Header ekstensi
...

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.[12] Bidang di header adalah sebagai berikut:

  • Versi: (2 bit) Menunjukkan versi protokol. Versi saat ini adalah 2.[13]
  • 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).[13][14]:12
  • X (Extensi): (1 bit) Menunjukkan adanya header Ekstensi antara header standar dan data payload. Ini khusus untuk aplikasi atau profil.[13]
  • CC (CSRC Count): (4 bit) Terdiri nomor-nomor dari pengidentifikasi CSRC (didefinisikan di bawah) yang mengikuti header tetap.[14]
  • M (Marker): (1 bit) Digunakan pada tingkat aplikasi dan ditentukan oleh profil. Jika ditentukan, berarti data terkini mempunyai relevansi khusus untuk aplikasi.[14]
  • PT (Payload Type): (7 bit) Mengidentifikasi format dari payload dan menentukan interpretasinya dengan aplikasi. Ini ditentukan oleh profil RTP. Misalnya, lihat RTP Profile for audio and video conferences with minimal control (RFC 3551).[15]
  • 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.[16] Menurut RFC 3550, nilai awal nomor urut harus acak untuk mempersulit serangan enkripsi teks diketahui pada Protokol Transportasi Waktu-nyata Aman lebih sulit.[3][14]
  • 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 clocknya. Granularitas clock adalah salah satu detail yang ditentukan dalam profil RTP untuk suatu aplikasi.[16]
  • SSRC: (32 bit) Pengidentifikasi sumber sinkronisasi secara unik mengidentifikasi sumber aliran. Sumber sinkronisasi dalam sesi RTP yang sama akan menjadi unik.[14]
  • CSRC: (setiap 32 bit) ID sumber yang berkontribusi menyebutkan sumber yang berkontribusi pada aliran yang dihasilkan dari berbagai sumber.[14]
  • 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.[14]

Desain aplikasi

[sunting | sunting sumber]

Sebuah aplikasi multimedia fungsional memerlukan protokol dan standar lainnya yang digunakan bersama dengan RTP. Protokol seperti SIP, 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.[17]

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).[butuh rujukan]

Dokumen standar

[sunting | sunting sumber]
  • 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

[sunting | sunting sumber]
  1. ^ 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.

Referensi

[sunting | sunting sumber]
  1. ^ a b Perkins 2003, hlm. 6.
  2. ^ Daniel Hardy (2002). Network. De Boeck Université. p. 298.
  3. ^ a b Daniel Hardy (2002). Network. De Boeck Université. hlm. 298. 
  4. ^ Wright, Gavin. "What is the Real-time Transport Protocol (RTP)?". TechTarget (dalam bahasa Inggris). Diakses tanggal 2022-11-10. 
  5. ^ RFC 4566: SDP: Session Description Protocol, M. Handley, V. Jacobson, C. Perkins, IETF (July 2006)
  6. ^ Perkins 2003, hlm. 55
  7. ^ Kesalahan pengutipan: Tag <ref> tidak sah; tidak ditemukan teks untuk ref bernama Peterson_430
  8. ^ Larry L. Peterson (2007). Computer Networks. Morgan Kaufmann. hlm. 430. ISBN 978-1-55860-832-0. 
  9. ^ RFC 3550
  10. ^ Perkins 2003, hlm. 367
  11. ^ Breese, Finley (2010). Serial Communication over RTP/CDP. BoD - Books on Demand. hlm. [1]. ISBN 978-3-8391-8460-8. 
  12. ^ Peterson 2007, hlm. 430
  13. ^ a b c Peterson 2007, hlm. 431
  14. ^ a b c d e f g Kesalahan pengutipan: Tag <ref> tidak sah; tidak ditemukan teks untuk ref bernama RFC3550
  15. ^ Perkins 2003, hlm. 59
  16. ^ a b Peterson, p.432[pranala nonaktif permanen]
  17. ^ Perkins 2003, hlm. 11–13

Bacaan lanjutan

[sunting | sunting sumber]

Pranala luar

[sunting | sunting sumber]
Diperoleh dari "https://id.wikipedia.org/w/index.php?title=Protokol_Transpor_Waktu_Nyata&oldid=26186895"