Protokol Pengangkut Masa Sebenar

Protokol Pengangkut Masa Sebenar ("Real-time Transport Protocol-RTP") mentakrifkan format paket piwai bagi menghantar video dan bunyi melalui Internet. Ia dimajukan oleh Audio-Video Transport Working Group dari IETF dan pertama kali diterbitkan pada tahun 1996 sebagai RFC 1889, menggantikan RFC 3550 pada tahun 2003.

RTP digunakan secara meluas dalam sistem komunikasi dan hiburan yang membabitkan media aliran (penstriman) seperti panggilan telefon, aplikasi telesidang dan ciri tekan cakap berasaskan web. Untuk tujuan ini, ia membawa aliran media dikawal oleh H.323, MGCP, Megaco, Protokol Kawal Panggil Kurus ("Skinny Call Control Protocol-SCCP"), atau protokol pengisyaratan Protokol Permulaan Sidang ("Session Initiation Protocol-SIP"), menjadikannya salah satu asas teknikal bagi industri Suara melalui IP ("Voice over IP").

RTP biasanya digunakan bersama dengan Protokol Kawalan RTP ("RTP Control Protocol-RTCP"). Ketika RTP membawa aliran media (contoh., bunyi dan video) atau peristiwa di luar jalur pengisyaratan (DTMF dalam jenis beban bayar), RTCP digunakan bagi memantau pemancaran maklumat kualiti perkhidmatan (QoS) dan statistik. Apabila kedua protokol digunakan bersama, RTP biasanya memulakan dan menerima pada nombor port genap, sementara RTCP menggunakan nombor port ganjil tinggi berikutnya.

Gambaran Keseluruhan sunting

RTP dikembangkan oleh kumpulan petugas Audio/Video Transport dari organisasi piwai IETF. RTP digunakan bersama dengan protokol lain seperti H.323 dan RTSP.[1] Piwaian RTP menetapkan sepasang protokol, RTP dan Protokol Kawalan Pengangkut Masa Sebenar ("Real-time Transport Control Protocol-RTCP"). RTP digunakan bagi penghantaran data multimedia, dan RTCP digunakan bagi menghantar maklumat kawalan dan parameter QoS secara berkala.[2]

RTP direka bagi pemindahan data multimedia, masa nyata, prinsip hujung ke hujung. Protokol memberikan kemudahan bagi pampasan ketaran dan pengesanan penerimaan data di luar aturan, yang merupakan perkara biasa semasa pancaran melalui rangkaian IP. RTP menyokong pemindahan data kepada pelbagai destinasi melalui multisiar.[3] RTP dianggap piwai utama bagi pengangkutan bunyi/video melalui rangkaian IP dan digunakan bersama profil berkait dan format beban bayar.[1]

Applikasi penyaliran multimedia masa nyata memerlukan penghantaran maklumat tepat pada waktunya dan mampu sabar dengan kehilangan sedikit paket untuk mencapai matlamat ini. Sebagai contoh, kehilangan satu paket dalam applikasi bunyi mungkin menyebabkan kehilangan sebahagian sesaat data bunyi, yang boleh dijadikan tidak kelihatan dengan algoritma penyamar ralat yang bersesuaian.[4] Protokol Kawalan Penghantaran ("Transmission Control Protocol-TCP"), sungguhpun piwai bagi RTP menggunakan (RFC 4571), jarang digunakan oleh RTP kerana pendam diwarisi akinat penetapan hubungan dan pembetulan rawak, sebaliknya kebanyakan perlaksanaan RTP dibina berdasarkan Protokol Datagram Pengguna ("User Datagram Protocol-UDP").[4] Protokol pengangkut lain direka khusus bagi sesi multimedia adalah SCTP dan DCCP, sungguhpun ia belum lagi digunakan secara meluas(2009.[5][6]

Komponen protokol sunting

Spesifikasi RTP menjelaskan dua protokol kecil:

  • Protokol pemindahan data, yang berkenaan dangan pemindahan data multimedia masa nyata. Maklumat diberikan oleh protokol ini termasuk cop masa (bagi penyelarasan), nombor tututan (bagi pengesanan kehilangan paket) dan format muatan yang menunjukkan format dikod bagi data.[7]
  • The Real Time Control Protocol (RTCP) digunakan untuk menetapkan suap balas kualiti perkhidmatan (QoS) dan penyelarasan antara aliran media. Luas jalur trafik RTCP dibanding dengan RTP adalah kecil, biasanya sekitar 5%.[7][8]

Sesi sunting

Sesi RTP disiapkan bagi setiap aliran multimedia. Satu sesi terdiri daripada alamat IP dengan pasangan port bagi RTP dan RTCP. Sebagai contoh, aliran bunyi dan video akan memiliki sesi RTP berasingan, membolehkan penerima untuk mengenepikan aliran tertentu.[9] Port yang membentuk sesi dirundingkan menggunakan protokol lain seperti RTSP (menggunakan Protokol Pemerian Sesi ("Session Description Protocol-SDP") dalam kaedah penyediaan)[10] dan Protokol Pemulaan Sesi ("Session Initiation Protocol-SIP"). Menurut spesifikasi, port RTP perlu genap dan port RTCP adalah yang ganjil berikutnya. RTP dan RTCP biasanya menggunakan port UDP tanpa keistimewaan (1024 to 65535),[11] tetapi mungkin menggunakan protokol pengangkut lain (terutamanya, SCTP dan DCCP) juga, kerana reka bentuk protokol adalah bebas pengangkut.

Profil dan format Muatan sunting

Salah satu pertimbangan bagi RTP adalah untuk menyokong julat format multimedia (seperti H.264, MPEG-4, MJPEG, MPEG, dll.) dan membenarkan format baru ditambah tanpa semak kembali piwai RTP. Reka bentuk RTP berdasarkan prinsip reka bentuk yang dikenali sebagai Pembingkaian Tahap Applikasi ("Application Level Framing-ALF"). Maklumat yang diperlukan oleh applikasi khusus tidak perlu wujud dalam kepala RTP generik dan dikhaskan oleh Profil RTP dan format Muatan.[2] Bagi setiap kelas applikasi (contoh., bunyi, video), RTP menetapkan satu profil dan satu atau lebih "format muatan" yang berkait.[2]

Profil menetapkan kodak digunakan bagi mengkod data muatan dan memetakannya kepada kod format muatan dalam medan "Jenis Muatan" di kepala ( Lihat di bawah). Setiap profil diiringi dengan beberapa spesifikasi format muatan, setiap satu menggambarkan pengangkutan data terkod khusus.[1] Sesetengah format muatan bunyi termasuk: G.711, G.723, G.726, G.729, GSM, QCELP, MP3, DTMF dll., dan sesetengah format muatan video termasuk: H.261, H.263, H.264, MPEG dll.[12][13]

Contoh Profil RTP Profiles termasuk:

  • Profil RTP bagi Bunyi dan sidang video dengan kawalan minima (RFC 3551) mentakrifkan satu set ugasan jenis muatan statik, dan mekanisma bagi memeta antara format muatan, dan pengenalpasti jenis muatan (pada kelapa) menggunakan Protokol Pemerian Sesi ("Session Description Protocol-SDP").
  • Protokol Pengangkutan Masa Nyata Selamat ("Secure Real-time Transport Protocol-SRTP") (RFC 3711) menetapkan profil RTP yang memberikan perkhidmatan kriptografi bagi pemindahan data muatan.[14]

Spesifikasi lengkap RTP bagi applikasi tertentu memerlukan profil dan/atau spesifikasi format muatan.[15]

Pengepala Paket sunting

bit offset 0-1 2 3 4-7 8 9-15 16-31
0 Ver. P X CC M PT Nombor Turutan
32 Cop Masa
64 Pengenal SSRC
96 pengenal CSRC (pilihan)
...

Pengepala RTP memiliki saiz minima 12 byte. Selepas pengepala, tambahan pengepala pilihan mungkin hadir. Ini diikuti oleh muatan RTP, formatnya ditentukan oleh kelas tertentu applikasi.[16] Medan pada pengepala adalah seperti berikut:

  • Ver.: (2 bit) menunjukkan versi protokol. Versi terkini adalah 2.[17]
  • P (Tambahan/Padding): (1 bit) Digunakan bagi menunjukkan sekiranya terdapat tambahan bytes pada akhir paket RTP. Pengisi mungkin digunakn bagi memenuhi blok saiz tertentu, sebagi contoh yang diperlukan oleh encryption algorithm.[17]
  • X (Tambahan): (1 bit) Menunjukkan kehadiran Pengepala tambahan antara pengepala piwai dan data bebanan. Ini adalah khusus applikasi atau profil.[17]
  • CC (kira CSRC): (4 bits) Mengandungi nombor pengenalpasti CSRC (ditakrif di bawah) yang menurut pengepala tetap.[18]
  • M (Penanda): (1 bit) Digunakan pada tahap applikasi dan ditetapkan oleh profil. Sekiranya ia di set, ia bererti bahawa data kini memiliki kaitan khusus bagi applikasi.[18]
  • PT (Jenis Beban): (7 bit) Menunjukkan format beban dan menentukan penafsirannya oleh applikasi. Ini ditetapkan oleh profil RTP. Sebagai contoh, lihat Profil RTP bagi sidang video dan bunyi dengan kawalan minima (RFC 3551).[19]
  • Nombor Turutan : (16 bit) Nombor turutan meningkat dengan satu bagi setiap paket data RTP di hantar dan ia akan digunakan oleh penerima bagi mengesan kehilangan data dan memulihkan turutan paket. RTP tidak mengambil sebarang tindakan jika ia melihat kehilangan paket, tetapi ia membiarkan applikasi mengambil tindakan yang diingini. Sebagai contoh applikasi video mungkin memainkan bingkai terakhir diketahui bagi menggantikan bingkai yang hilang.[20] Menurut RFC 3550, nilai awal nombor turutan perlu rawak untuk menjadikan serangan teks biasa diketahui pada penyulitan data lebih sukar.[18] RTP tidak menjamin penghantaran, tetapi kehadiran nombor turutan menjadikan ia mungkin bagi mengesan kehilangan paket.[3]
  • Cop masa: (32 bit) Digunakan bagi membolehkan penerima memainkan semula contoh yang diterima pada tahap bersesuaian. Apabila beberapa aliran media hadir, cop masa adalah bebas bagi setiap aliran, dan tidak patut diharap bagi penyelarasan media. Kebutiran/Granulariti masa adalah khusus applikasi. Sebagai contoh, applikasi bunyi yang menguji data sekali setiap 125 µs (8 kHz, kadar contoh biasa dalam telefon digital) boleh menggunakan nilai tersebut sebagai resolusi jamnya. Kebutiran jam adalah satu perincian yang ditetapkan dalam profil RTP atau format bebanan bagi applikasi.[20]
  • SSRC : (32 bit) Pengenal sumber penyelaras secara unik mengenal pasti sumber aliran. Sumber penyelaras dalam sesi RTP yang sama adalah unik.[18]
  • CSRC: ID sumber penyumbang menomborkan sumber penyumbang kepada aliran yang telah dihasilkan dari pelbagai sumber.[18]
  • Pengepala tambahan: (pilihan) perkataan 32-bit pertama mengandungi pengenal khusus-profil (16 bit) dan penetap panjang (16 bit) yang menunjukkan panjang tambahan (panjang pengepala tambahan ("extension header length-EHL") dalam unit 32-bit, tidak termasuk 32 bit pengepala tambahan.[18]

Sistem berasaskan RTP sunting

Sistem berdasarkan rangkaian penuh akan memasukkan protokol dan piwai lain bersama dengan RTP. Protokol seperti Protokol Pemula Sesi ("Session Initiation Protocol-SIP"), Protokol Penstriman Masa Nyata ("Real Time Streaming Protocol-RTSP"), H.225 dan H.245 digunakan bagi pemula sesi, kawalan dan menamatkan. Piwai lain seperti H.264, MPEG, H.263 dll., digunakan bagi mengkod data muatan (khususnya melalui Profil RTP).[21]

Penghantar RTP menangkap data multimedia, yang kemudian dikod sebagai bingkai dan dipancar sebagai paket RTP, dengan cop masa yang bersesuaian dan nombor turutan meningkat. Bergantung kepada Profil RTP digunakan, medan Jenis Muatandi set. Penerima RTP, menangkap paket RTP, dan mungkin menyusun paket, yang mungkin terhasil kerana rangkaian IP asas dan bingkai dinyahkod bergantung kepada format muatan dan ditunjukkan kepada pengguna.[21]

Rujukan RFC sunting

  • RFC 4103, RTP Payload Format for Text Conversation
  • RFC 3984, RTP Payload Format for H.264 Video
  • RFC 3640, RTP Payload Format for Transport of MPEG-4 Elementary Streams
  • RFC 3016, RTP Payload Format for MPEG-4 Audio/Visual Streams
  • RFC 3551, Standard 65, RTP Profile for Audio and Video Conferences with Minimal Control
  • RFC 3550, Standard 64, RTP: A Transport Protocol for Real-Time Applications
  • RFC 2250, Proposed Standard, RTP Payload Format for MPEG1/MPEG2 Video

Lihat juga sunting

Pautan luar sunting

Nota sunting

  1. ^ a b c Colin Perkins, p.55
  2. ^ a b c Larry L. Peterson (2007). Computer Networks. Morgan Kaufmann. m/s. 430. ISBN 155860832X.
  3. ^ a b Daniel Hardy (2002). Network. De Boeck Université. m/s. 298.
  4. ^ a b Colin Perkins, p.46
  5. ^ Farrel, Adrian (2004). The Internet and its protocols. Morgan Kaufmann. m/s. 363. ISBN 9781558609136.
  6. ^ Ozaktas, Haldun M. (2007). THREE-DIMENSIONAL TELEVISION. Springer. m/s. 366. ISBN 9783540725312. Unknown parameter |coauthors= ignored (|author= suggested) (bantuan)
  7. ^ a b Colin Perkins, p.56
  8. ^ Peterson, p.435
  9. ^ Zurawski, Richard (2004). "RTP, RTCP and RTSP protocols". The industrial information technology handbook. CRC Press. m/s. 28–7. ISBN 9780849319853.
  10. ^ RFC 4566: SDP: Session Description Protocol, M. Handley, V. Jacobson, C. Perkins, IETF (July 2006)
  11. ^ Collins, Daniel (2002). "Transporting Voice by using IP". Carrier grade voice over IP. McGraw-Hill Professional. m/s. 47. ISBN 0071363262.
  12. ^ Perkins, p.60
  13. ^ For examples of H.263, MPEG-4 packet formats see, Chou, Philip A. (2007). Multimedia over IP and wireless networks. Academic Press. m/s. 514. ISBN 0120884801. Unknown parameter |coauthors= ignored (|author= suggested) (bantuan)
  14. ^ Collin Perkins, p.367
  15. ^ RFC 3550, p.71
  16. ^ Peterson, p. 430
  17. ^ a b c Peterson, p.431
  18. ^ a b c d e f "RTP Data Transfer Protocol". RFC-Ref. Dicapai pada 2009-03-18.
  19. ^ Colin Perkins, p.59
  20. ^ a b Peterson, p.432
  21. ^ a b Perkins, pp.11-13

Rujukan sunting