Wikipedia

Protokol Transpor Waktu Nyata

Revisi sejak 8 Desember 2023 13.54 oleh PinkDash (bicara | kontrib)

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]

Real-time Transport Protocol
Protokol komunikasi
SingkatanRTP
TujuanMengantarkan audio dan video
PengembangAudio-Video Transport Working Group dari IETF
DiperkenalkanJanuari 1996; 28 tahun lalu (1996-01)
BerdasarkanNetwork Voice Protocol[1]
RFCRFC 1889, 3550, 3551

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]

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 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}} == 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. 28–7. ISBN 978-0-8493-1985-3.</ref>

Header paket

RTP packets are created at the application layer and handed to the transport layer for delivery. Each unit of RTP media data created by an application begins with the RTP packet header.

RTP packet header
Offsets Octet 0 1 2 3
Octet 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 Version P X CC M PT Sequence number
4 32 Timestamp
8 64 SSRC identifier
12 96 CSRC identifiers
...
12+4×CC 96+32×CC Profile-specific extension header ID Extension header length
16+4×CC 128+32×CC Extension header
...


The RTP header has a minimum size of 12 bytes. After the header, optional header extensions may be present. This is followed by the RTP payload, the format of which is determined by the particular class of application.[5] The fields in the header are as follows:

  • Version: (2 bits) Indicates the version of the protocol. Current version is 2.[6]
  • P (Padding): (1 bit) Used to indicate if there are extra padding bytes at the end of the RTP packet. A padding might be used to fill up a block of certain size, for example as required by an encryption algorithm. The last byte of the padding contains the number of padding bytes that were added (including itself).[6][7]:12
  • X (Extension): (1 bit) Indicates presence of an Extension header between standard header and payload data. This is application or profile specific.[6]
  • CC (CSRC Count): (4 bits) Contains the number of CSRC identifiers (defined below) that follow the fixed header.[7]:12
  • M (Marker): (1 bit) Used at the application level and defined by a profile. If it is set, it means that the current data has some special relevance for the application.[7]:13
  • 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).[8]
  • Sequence Number: (16 bits) The sequence number is incremented by one for each RTP data packet sent and is to be used by the receiver to detect packet loss and to restore packet sequence. The RTP does not specify any action on packet loss; it is left to the application to take appropriate action. For example, video applications may play the last known frame in place of the missing frame.[9] According to RFC 3550, the initial value of the sequence number should be random to make known-plaintext attacks on encryption more difficult.[7]:13 RTP provides no guarantee of delivery, but the presence of sequence numbers makes it possible to detect missing packets.[3]
  • Timestamp: (32 bits) Used to enable the receiver to play back the received samples at appropriate intervals. When several media streams are present, the timestamps are independent in each stream, and may not be relied upon for media synchronization. The granularity of the timing is application specific. For example, an audio application that samples data once every 125 µs (8 kHz, a common sample rate in digital telephony) would use that value as its clock resolution. The clock granularity is one of the details that is specified in the RTP profile for an application.[9]
  • SSRC: (32 bits) Synchronization source identifier uniquely identifies the source of a stream. The synchronization sources within the same RTP session will be unique.[7]:15
  • CSRC: (32 bits each) Contributing source IDs enumerate contributing sources to a stream which has been generated from multiple sources.[7]:15
  • Header extension: (optional) The first 32-bit word contains a profile-specific identifier (16 bits) and a length specifier (16 bits) that indicates the length of the extension (EHL=extension header length) in 32-bit units, excluding the 32 bits of the extension header.[7]:17

Aplikasi RTP

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).

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

  1. ^ 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.

Referensi

  1. ^ 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. ^ Peterson 2007, hlm. 430
  6. ^ a b c Peterson 2007, hlm. 431
  7. ^ a b c d e f g Kesalahan pengutipan: Tag <ref> tidak sah; tidak ditemukan teks untuk ref bernama RFC3550
  8. ^ Perkins 2003, hlm. 59
  9. ^ a b Peterson, p.432[pranala nonaktif permanen]

Bacaan lanjutan

Pranala luar

Diperoleh dari "https://wiki-indonesia.club/w/index.php?title=Protokol_Transpor_Waktu_Nyata&oldid=24968999"