Protokol pemindahan data masa nyata selamat. Protokol RTP dan RTCP dalam VoIP

2. Konsep asas

3. Protokol pemindahan data RTP

Prinsip membina protokol RTP

Kaedah kawalan kerja

Format Pengepala Protokol RTP

Protokol Tempahan Sumber - RSVP

kesusasteraan

2.1. Persidangan audio kumpulan

2.2. Persidangan video

2.3. Konsep pengadun dan penterjemah

2.4. Format susunan bait, penjajaran dan cap masa

3.1. Medan Pengepala Tetap RTP

3.2. Sesi komunikasi RTP

3.3. Perubahan pengepala RTP yang ditentukan profil

3.4. Sambungan pengepala RTP

2.3.3. protokol TCP

2.3.4. Protokol UDP

2.3.5. Protokol RTP dan RTCP

protokol RTP dan RSVP,

Konsep asas

Persidangan audio kumpulan

Persidangan video

Konsep pengadun dan penterjemah

protokol kawalan RTCP

Kadar Penghantaran Paket RTCP

http://www.isuct.ru/~ivt/books/NETWORKING/NET10/269/pa.html

Masalah yang paling mendesak ialah semakin kekurangan ruang alamat, yang memerlukan perubahan format alamat.

Masalah lain ialah kekurangan skalabiliti prosedur penghalaan - asas rangkaian IP. Pertumbuhan rangkaian yang pesat membebankan penghala, yang sudah terpaksa mengekalkan jadual penghalaan dengan puluhan dan ratusan ribu entri, serta menangani masalah pemecahan paket. Anda boleh membuat kerja penghala lebih mudah, khususnya, dengan menaik taraf protokol IP.

Bersama dengan memperkenalkan fungsi baharu terus ke dalam protokol IP, adalah dinasihatkan untuk memastikan interaksi yang lebih rapat dengan protokol baharu dengan memperkenalkan medan baharu ke dalam pengepala paket.

Akibatnya, ia telah memutuskan untuk memodenkan protokol IP, mengejar matlamat utama berikut:

penciptaan skim pengalamatan lanjutan baharu;
meningkatkan kebolehskalaan rangkaian dengan mengurangkan fungsi penghala tulang belakang;
memastikan perlindungan data.

Alamat pengembangan ruang. Protokol IP menyelesaikan masalah potensi kekurangan alamat dengan mengembangkan panjang alamat kepada 128. Walau bagaimanapun, peningkatan ketara dalam panjang alamat ini dibuat sebahagian besarnya bukan untuk mengurangkan masalah kekurangan alamat, tetapi untuk meningkatkan kecekapan rangkaian berdasarkan protokol ini. Matlamat utama adalah untuk mengubah struktur sistem pengalamatan dan mengembangkan fungsinya.

Daripada dua tahap hierarki alamat sedia ada (nombor rangkaian dan nombor nod), IPv6 mencadangkan untuk menggunakan empat peringkat, yang membayangkan pengenalan tiga peringkat rangkaian dan satu tahap untuk mengenal pasti nod.

Alamat kini ditulis dalam perenambelasan, dengan setiap empat digit dipisahkan oleh titik bertindih, sebagai contoh:

FEDC:0A96:0:0:0:0:7733:567A.

Untuk rangkaian yang menyokong kedua-dua versi protokol IPv4 dan IPv6, adalah mungkin untuk menggunakan tatatanda perpuluhan tradisional untuk 4 bait yang lebih rendah dan notasi heksadesimal untuk bait yang lebih tinggi:

0:0:0:0:FFFF 194.135.75.104.

Dalam sistem pengalamatan IPv6, terdapat juga ruang alamat khusus untuk kegunaan tempatan, iaitu, untuk rangkaian bukan di Internet. Terdapat dua jenis alamat tempatan: untuk rangkaian "rata" yang tidak dibahagikan kepada subnet (Pautan-Setempat), dan untuk rangkaian yang dibahagikan kepada subnet (Site-Local), yang berbeza dalam nilai awalan.

Menukar format pengepala paket. Ini boleh dilaksanakan menggunakan skim baharu untuk mengatur "pengepala bersarang", yang memastikan pengepala dibahagikan kepada yang utama, yang mengandungi maklumat minimum yang diperlukan, dan yang tambahan, yang mungkin tiada. Pendekatan ini membuka banyak kemungkinan untuk melanjutkan protokol dengan mentakrifkan tajuk pilihan baharu, menjadikan protokol terbuka.

Pengepala utama datagram IPv6, 40 bait panjang, mempunyai format berikut (Gamb. 2.4).

Padang Kelas Trafik setara dalam tujuan untuk bidang Jenis Perkhidmatan, dan padang Had Hop- padang Masa untuk hidup protokol IPv4.

Padang Label Aliran membolehkan anda mengasingkan dan memproses secara khusus aliran data individu tanpa perlu menganalisis kandungan paket. Ini sangat penting dari sudut pandangan mengurangkan beban pada penghala.

Padang Tajuk Seterusnya adalah analog dengan medan IPv4 Protocol dan menentukan jenis pengepala mengikuti yang utama. Setiap pengepala tambahan seterusnya juga mengandungi medan Pengepala Seterusnya.

Protokol kawalan Protokol Kawalan Penghantaran (TCP) dibangunkan untuk menyokong komunikasi interaktif antara komputer. Protokol TCP memastikan kebolehpercayaan dan kebolehpercayaan pertukaran data antara proses pada komputer yang merupakan sebahagian daripada rangkaian biasa.

Malangnya, protokol TCP tidak sesuai untuk menghantar maklumat multimedia. Sebab utama ialah ketersediaan kawalan penghantaran. Pemantauan mengambil terlalu banyak masa untuk menghantar lebih banyak maklumat sensitif kependaman. Selain itu, TCP menyediakan mekanisme kawalan kadar untuk mengelakkan kesesakan rangkaian. Data audio dan video, walau bagaimanapun, memerlukan kadar penghantaran yang ditetapkan dengan ketat, yang tidak boleh diubah sewenang-wenangnya.

Di satu pihak, protokol TCP berinteraksi dengan protokol aplikasi pengguna, dan di pihak yang lain, dengan protokol yang menyediakan penghalaan "peringkat rendah" dan fungsi pengalamatan paket yang biasanya dilakukan oleh IP.

Struktur logik perisian rangkaian yang melaksanakan protokol keluarga TCP/IP dalam setiap nod Internet ditunjukkan dalam Rajah. 2.5.

Segi empat tepat mewakili modul yang memproses data, dan garisan yang menghubungkan segi empat tepat mewakili laluan pemindahan data. Garis mendatar di bahagian bawah rajah mewakili rangkaian Ethernet, yang digunakan sebagai contoh medium fizikal.

nasi. 2.5.

Untuk mewujudkan sambungan antara dua proses pada komputer yang berbeza pada rangkaian, anda perlu mengetahui bukan sahaja alamat Internet komputer, tetapi juga nombor port TCP (soket) yang digunakan oleh proses pada komputer ini. Sebarang sambungan TCP di Internet dikenal pasti secara unik oleh dua alamat IP dan dua nombor port TCP.

Protokol TCP boleh mengendalikan paket yang rosak, hilang, diduplikasi atau tidak mengikut pesanan. Ini dicapai melalui mekanisme untuk memberikan nombor urutan kepada setiap paket yang dihantar dan mekanisme untuk mengesahkan penerimaan paket.

Apabila TCP menghantar segmen data, salinan data tersebut diletakkan dalam baris gilir penghantaran semula dan pemasa pengakuan dimulakan.

Protokol Datagram Pengguna (UDP) bertujuan untuk pertukaran datagram antara proses komputer yang terletak dalam sistem rangkaian komputer bersepadu.

Protokol UDP adalah berdasarkan protokol IP dan menyediakan perkhidmatan pengangkutan ke proses aplikasi yang tidak jauh berbeza daripada protokol IP. Protokol UDP menyediakan penghantaran data yang tidak terjamin, iaitu ia tidak memerlukan pengesahan penerimaannya; Di samping itu, protokol ini tidak memerlukan mewujudkan sambungan antara sumber dan penerima maklumat, iaitu, antara modul UDP.

Protokol pengangkutan masa nyata RTP menyediakan penghantaran masa nyata dari hujung ke hujung data multimedia seperti audio dan video interaktif. Protokol ini melaksanakan pengecaman jenis trafik, penomboran jujukan paket, pengurusan cap masa dan kawalan penghantaran.

Protokol RTP berfungsi dengan memberikan cap masa kepada setiap paket keluar. Di bahagian penerima, cap masa paket menunjukkan dalam urutan dan dengan kelewatan yang perlu dimainkan. Sokongan untuk RTP dan RTCP membolehkan hos penerima mengatur paket yang diterima dalam susunan yang betul, mengurangkan kesan variasi kependaman rangkaian pada kualiti isyarat, dan memulihkan penyegerakan antara audio dan video supaya maklumat yang masuk dapat didengar dan dilihat dengan betul oleh pengguna.

Ambil perhatian bahawa RTP sendiri tidak mempunyai sebarang mekanisme untuk menjamin pemindahan data tepat pada masanya dan kualiti sesuatu servis, tetapi menggunakan perkhidmatan asas untuk menyediakan ini. Ia tidak menghalang paket yang tidak tertib, tetapi ia tidak menganggap bahawa rangkaian asas benar-benar boleh dipercayai dan menghantar paket dalam urutan yang betul. Nombor jujukan yang disertakan dalam RTP membolehkan penerima membina semula jujukan paket penghantar.

Protokol RTP menyokong komunikasi dua hala dan pemindahan data ke sekumpulan destinasi jika multicast disokong oleh rangkaian asas. RTP direka bentuk untuk menyediakan maklumat yang diperlukan oleh aplikasi individu, dan dalam kebanyakan kes disepadukan ke dalam pengendalian aplikasi.

Walaupun RTP dianggap sebagai protokol lapisan pengangkutan, ia biasanya beroperasi di atas protokol lapisan pengangkutan lain, UDP (User Datagram Protocol). Kedua-dua protokol menyumbang bahagian mereka dalam fungsi lapisan pengangkutan. Perlu diingatkan bahawa RTP dan RTCP adalah bebas daripada lapisan pengangkutan dan rangkaian asas, jadi RTP/RTCP boleh digunakan dengan protokol pengangkutan lain yang sesuai.

Blok data protokol RTP/RTCP dipanggil paket. Paket yang dijana mengikut protokol RTP dan digunakan untuk menghantar data multimedia dipanggil paket maklumat atau paket data, dan paket yang dihasilkan mengikut protokol RTCP dan digunakan untuk menghantar maklumat perkhidmatan yang diperlukan untuk operasi yang boleh dipercayai. telesidang, dipanggil paket kawalan atau paket kawalan. Paket RTP termasuk pengepala tetap, sambungan pengepala panjang pembolehubah pilihan dan medan data. Paket RTCP bermula dengan bahagian tetap (serupa dengan bahagian tetap paket maklumat RTP), diikuti dengan elemen struktur yang mempunyai panjang berubah-ubah.

Agar protokol RTP menjadi lebih fleksibel dan boleh digunakan untuk pelbagai aplikasi, beberapa parameternya dibuat dengan sengaja tidak jelas, tetapi ia termasuk konsep profil. Profil ialah satu set parameter protokol RTP dan RTCP untuk kelas aplikasi tertentu, yang menentukan ciri fungsinya. Profil mentakrifkan: penggunaan medan pengepala paket individu, jenis trafik, padding pengepala dan sambungan pengepala, jenis paket, perkhidmatan keselamatan komunikasi dan algoritma, penggunaan protokol asas, dll. Setiap aplikasi biasanya berfungsi dengan hanya satu profil dan Jenis profil ialah ditentukan dengan memilih aplikasi yang sesuai. Tiada petunjuk jelas tentang jenis profil mengikut nombor port, pengecam protokol, dsb.

Oleh itu, spesifikasi RTP yang lengkap untuk aplikasi tertentu mesti termasuk dokumen tambahan, yang termasuk perihalan profil, serta perihalan format trafik yang mentakrifkan cara jenis trafik tertentu, seperti audio atau video, akan diproses dalam RTP.

Persidangan audio kumpulan memerlukan alamat kumpulan berbilang pengguna dan dua port. Dalam kes ini, satu port diperlukan untuk pertukaran data audio, dan satu lagi digunakan untuk paket kawalan protokol RTCP. Alamat kumpulan dan maklumat pelabuhan dihantar kepada peserta yang dimaksudkan telesidang. Jika kerahsiaan diperlukan, maka maklumat dan paket kawalan boleh disulitkan, dalam hal ini kunci diedarkan penyulitan.

Aplikasi persidangan audio yang digunakan oleh setiap peserta persidangan menghantar data audio dalam ketulan kecil, seperti 20 ms. Setiap bahagian data audio didahului oleh pengepala RTP; Pengepala RTP dan data dibentuk secara bergilir-gilir (dikapsulkan) ke dalam paket UDP. Pengepala RTP menunjukkan jenis pengekodan audio (seperti PCM, ADPCM atau LPC) yang digunakan untuk menjana data dalam paket. Ini membolehkan anda menukar jenis pengekodan semasa persidangan, contohnya, apabila peserta baharu muncul yang menggunakan pautan lebar jalur rendah atau apabila terdapat kesesakan rangkaian.

Di Internet, seperti dalam rangkaian data bertukar paket lain, paket kadangkala hilang dan disusun semula, dan ditangguhkan untuk jumlah masa yang berbeza-beza. Untuk mengatasi peristiwa ini, pengepala RTP mengandungi cap masa dan nombor jujukan yang membolehkan penerima menetapkan semula pemasaan supaya, sebagai contoh, bahagian isyarat audio dimainkan secara berterusan oleh pembesar suara setiap 20 ms. Pembinaan semula masa ini dilakukan secara berasingan dan bebas untuk setiap sumber paket RTP masuk telesidang. Nombor jujukan juga boleh digunakan oleh penerima untuk menganggarkan jumlah paket yang hilang.

Sejak peserta telesidang boleh menyertai dan keluar semasa persidangan sedang berlangsung, adalah berguna untuk mengetahui siapa yang sedang mengambil bahagian dan sejauh mana peserta persidangan menerima data audio. Untuk tujuan ini, setiap contoh aplikasi audio semasa persidangan mengeluarkan mesej secara berkala kepada port kawalan (port RTCP) untuk aplikasi semua peserta lain tentang penerimaan paket yang menunjukkan nama penggunanya. Mesej terima menunjukkan seberapa baik pembesar suara semasa didengar dan boleh digunakan untuk mengawal pengekod suai. Sebagai tambahan kepada nama pengguna, maklumat pengenalan lain untuk kawalan lebar jalur mungkin juga disertakan. Apabila meninggalkan persidangan, tapak menghantar paket RTCP BYE.

Jika dalam telesidang Jika kedua-dua isyarat audio dan video digunakan, ia dihantar secara berasingan. Untuk menghantar setiap jenis trafik secara berasingan antara yang lain, spesifikasi protokol memperkenalkan konsep sesi komunikasi RTP. Sesi ditakrifkan oleh sepasang alamat pengangkutan destinasi tertentu (satu alamat rangkaian ditambah sepasang port untuk RTP dan RTCP). Paket untuk setiap jenis trafik dihantar menggunakan dua pasangan port UDP dan/atau alamat multicast yang berbeza. Tiada sambungan RTP langsung antara sesi audio dan video, kecuali pengguna yang mengambil bahagian dalam kedua-dua sesi mesti menggunakan nama kanonik yang sama dalam paket RTCP untuk kedua-dua sesi supaya sesi boleh dikaitkan.

Satu sebab untuk pemisahan ini ialah sesetengah peserta persidangan mesti dibenarkan menerima hanya satu jenis trafik jika mereka ingin berbuat demikian. Walaupun terdapat pemisahan, main balik segerak media sumber (audio dan video) boleh dicapai dengan menggunakan maklumat pemasaan yang dibawa dalam paket RTCP untuk kedua-dua sesi.

Tidak semua tapak sentiasa boleh menerima data multimedia dalam format yang sama. Pertimbangkan kes di mana peserta dari satu lokasi disambungkan melalui pautan berkelajuan rendah kepada majoriti peserta persidangan lain yang mempunyai akses jalur lebar ke rangkaian. Daripada memaksa semua orang menggunakan lebar jalur yang lebih rendah dan pengekodan audio berkualiti rendah, kemudahan komunikasi lapisan RTP yang dipanggil pengadun boleh diletakkan di kawasan lebar jalur rendah. Pengadun ini menyegerakkan semula paket audio yang masuk untuk memulihkan selang 20-ms asal, mencampurkan strim audio yang dibina semula ini ke dalam satu aliran, mengekod isyarat audio untuk lebar jalur yang sempit dan menghantar aliran paket melalui pautan berkelajuan rendah. Dalam kes ini, paket boleh dialamatkan kepada satu penerima atau sekumpulan penerima dengan alamat yang berbeza. Untuk memastikan petunjuk yang betul semasa menerima titik akhir sumber mesej, pengepala RTP termasuk cara untuk pengadun mengenal pasti sumber yang mengambil bahagian dalam pembentukan paket campuran.

Sesetengah peserta dalam persidangan audio mungkin disambungkan melalui pautan jalur lebar, tetapi mungkin tidak boleh dihubungi melalui persidangan kumpulan menggunakan protokol IP (IPM - IP multicast). Sebagai contoh, mereka mungkin berada di belakang tembok api lapisan aplikasi yang tidak akan membenarkan sebarang paket IP dihantar. Untuk kes sedemikian, anda tidak memerlukan pengadun, tetapi satu lagi jenis peralatan komunikasi peringkat RTP, dipanggil penterjemah. Daripada dua geganti, satu dipasang di luar tembok api dan secara luaran memajukan semua paket multicast yang diterima melalui sambungan selamat ke geganti lain yang dipasang di belakang tembok api. Geganti di belakang tembok api menghantarnya semula sebagai paket multicast kepada kumpulan berbilang pengguna terhad kepada rangkaian dalaman tapak.

Semua medan paket RTP/RTCP dihantar melalui rangkaian dalam bait (oktet); bait yang paling ketara dihantar dahulu. Semua data medan pengepala dijajarkan mengikut panjangnya. Oktet yang ditetapkan sebagai pilihan mempunyai nilai sifar.

Protokol kawalan RTCP (RTCP - Protokol Kawalan Masa Nyata) adalah berdasarkan penghantaran paket berkala pengurusan kepada semua peserta dalam sesi komunikasi menggunakan mekanisme pengedaran yang sama seperti protokol RTP. Protokol asas mesti menyediakan pemultipleksan maklumat dan paket kawalan, contohnya, menggunakan nombor port UDP yang berbeza. Protokol RTCP melaksanakan empat fungsi utama.

Fungsi utama adalah untuk memberi maklum balas untuk menilai kualiti pengedaran data. Ini adalah fungsi penting RTCP sebagai protokol pengangkutan dan berkaitan dengan kawalan aliran dan fungsi kesesakan protokol pengangkutan lain. Maklum balas boleh berguna secara langsung untuk mengawal pengekodan adaptif, tetapi eksperimen dengan multicasting IP telah menunjukkan bahawa maklum balas kepada penerima juga penting untuk mendiagnosis kecacatan dalam penyebaran maklumat. Menghantar laporan maklum balas tentang penerimaan data kepada semua peserta membolehkan anda menilai sama ada masalah adalah tempatan atau global apabila memerhati masalah. Dengan mekanisme pengedaran IPM, entiti seperti pembekal perkhidmatan rangkaian juga boleh menerima maklumat maklum balas dan bertindak sebagai pemantau pihak ketiga apabila mendiagnosis masalah rangkaian. Fungsi maklum balas ini disediakan oleh laporan penghantar dan penerima RTCP.
RTCP mengekalkan pengecam sumber data RTP lapisan pengangkutan yang berterusan yang dipanggil nama kanonik (CNAME). Oleh kerana ID SSRC boleh berubah jika konflik dikesan atau program dimulakan semula, penerima memerlukan CNAME kanonik untuk menjejaki setiap peserta. Penerima juga memerlukan CNAME untuk tetapkan paparan aliran maklumat daripada peserta tertentu kepada banyak sesi RTP yang berkaitan, contohnya apabila menyegerakkan isyarat audio dan video.
Dua fungsi pertama memerlukan semua peserta menghantar paket RTCP, oleh itu, untuk membolehkan penskalaan bilangan peserta, RTP mesti mengawal kekerapan penghantaran paket tersebut. Apabila dihantar oleh setiap peserta telesidang pakej kawalan kepada semua peserta lain, masing-masing boleh menganggarkan jumlah peserta secara bebas.
Fungsi RTCP pilihan keempat mesti menyediakan maklumat kawalan sesi (cth, pengenalan peserta) yang akan ditunjukkan dalam antara muka pengguna. Ini berkemungkinan besar berguna dalam sesi "diuruskan secara longgar", di mana peserta menyertai dan meninggalkan kumpulan tanpa mengawal keahlian atau bersetuju dengan parameter.

Fungsi satu hingga tiga diperlukan apabila RTP digunakan dalam multicasting IP dan disyorkan dalam semua kes lain. Pembangun aplikasi RTP digalakkan untuk mengelakkan mekanisme yang berfungsi hanya dua hala dan tidak berskala untuk meningkatkan bilangan pengguna.

Protokol RTP membolehkan aplikasi secara automatik menskalakan keterwakilan sesi komunikasi, daripada beberapa peserta hingga beberapa ribu. Sebagai contoh, dalam persidangan audio, trafik data pada asasnya mengehadkan diri kerana hanya satu atau dua orang boleh bercakap pada satu masa dan dengan pengedaran kumpulan, kadar data pada mana-mana pautan kekal secara relatif tetap, tanpa mengira bilangan peserta. Walau bagaimanapun, kawalan trafik tidak mengehadkan diri. Jika menerima laporan daripada setiap peserta dihantar pada kadar yang tetap, maka trafik kawalan akan berkembang secara linear apabila bilangan peserta bertambah. Oleh itu, mekanisme khas mesti disediakan untuk mengurangkan kekerapan penghantaran paket kawalan.

Untuk setiap sesi, trafik data diandaikan memenuhi had agregat yang dipanggil lebar jalur sesi, yang dikongsi oleh semua peserta. Jalur lebar ini boleh ditempah dan hadnya ditetapkan oleh rangkaian. Jalur lebar sesi adalah bebas daripada jenis pengekodan media, tetapi pilihan jenis pengekodan mungkin dihadkan oleh lebar jalur sesi. Tetapan jalur lebar sesi dijangka akan disediakan oleh aplikasi pengurusan sesi apabila ia memanggil aplikasi media, tetapi aplikasi media juga boleh menetapkan nilai lalai berdasarkan lebar jalur data penghantar tunggal untuk jenis pengekodan yang dipilih untuk sesi tertentu.

Pengiraan lebar jalur untuk kawalan dan trafik data dilakukan dengan mengambil kira pengangkutan asas dan protokol lapisan rangkaian (cth, UDP dan IP). Pengepala lapisan pautan data (DLC) tidak diambil kira dalam pengiraan kerana paket mungkin dikapsulkan dengan pengepala lapisan DLC yang berbeza semasa ia dihantar.

Kawalan trafik hendaklah dihadkan kepada sebahagian kecil dan diketahui lebar jalur sesi: cukup kecil sehingga fungsi utama protokol pengangkutan - penghantaran data - tidak terjejas; diketahui supaya trafik kawalan boleh dimasukkan dalam spesifikasi lebar jalur yang diberikan kepada protokol tempahan sumber, dan supaya setiap peserta boleh mengira bahagiannya secara bebas. Diandaikan bahawa bahagian lebar jalur sesi yang diperuntukkan kepada RTCP harus ditetapkan kepada 5%. Semua peserta sesi mesti menggunakan jumlah lebar jalur RTCP yang sama supaya nilai selang penghantaran paket kawalan yang dikira adalah sama. Oleh itu pemalar ini mesti ditetapkan untuk setiap profil.

Algoritma untuk mengira selang antara menghantar paket RTCP komposit untuk membahagikan lebar jalur yang diperuntukkan untuk trafik kawalan di kalangan peserta mempunyai ciri-ciri utama berikut:

penghantar secara kolektif menggunakan sekurang-kurangnya 1/4 daripada lebar jalur trafik kawalan seperti dalam sesi dengan banyak penerima tetapi sedikit pengirim; Setelah hampir tidak membuat sambungan, peserta menerima CNAME tapak penghantaran dalam tempoh yang singkat;
Selang yang dikira antara paket RTCP dikehendaki sekurang-kurangnya lebih daripada 5 saat untuk mengelakkan pecah paket RTCP melebihi lebar jalur yang dibenarkan apabila bilangan peserta adalah kecil dan trafik tidak lancar mengikut undang-undang bilangan besar;
Selang antara paket RTCP diubah secara rawak dalam satu setengah hingga satu setengah daripada selang yang dikira untuk mengelakkan penyegerakan semua peserta secara tidak sengaja. Paket RTCP pertama yang dihantar selepas kemasukan sesi juga ditangguhkan secara rawak (hingga separuh selang RTCP minimum) jika aplikasi dimulakan di berbilang tapak secara serentak, seperti semasa mengumumkan permulaan sesi;
untuk menyesuaikan diri secara automatik dengan perubahan dalam jumlah maklumat kawalan yang dihantar, anggaran dinamik saiz purata paket RTCP komposit dikira menggunakan semua paket yang diterima dan dihantar;
algoritma ini boleh digunakan untuk sesi di mana penghantaran paket boleh diterima untuk semua peserta. Dalam kes ini, parameter jalur lebar sesi ialah lebar jalur pengirim individu didarab dengan bilangan peserta dan lebar jalur RTP bergantung pada protokol asas untuk memberikan petunjuk panjang. Panjang maksimum paket RTP hanya dihadkan oleh protokol asas.
Beberapa paket protokol RTP boleh dibawa dalam satu blok data protokol lapisan bawah, seperti paket UDP. Ini mengurangkan redundansi pengepala dan memudahkan penyegerakan antara benang yang berbeza.

Pertumbuhan pesat Internet meletakkan permintaan baharu pada kelajuan dan jumlah pemindahan data. Dan untuk memenuhi semua permintaan ini, hanya meningkatkan kapasiti rangkaian tidak mencukupi; kaedah yang munasabah dan berkesan untuk menguruskan trafik dan kesesakan talian penghantaran diperlukan.

Dalam aplikasi masa nyata, penghantar menjana aliran data pada kadar yang tetap, dan penerima (atau penerima) mesti memberikan data tersebut kepada aplikasi pada kadar yang sama. Aplikasi sedemikian termasuk, contohnya, persidangan audio dan video, video langsung, diagnostik jauh dalam bidang perubatan, telefon komputer, simulasi interaktif teragih, permainan, pemantauan masa nyata, dsb.

Protokol lapisan pengangkutan yang paling banyak digunakan ialah TCP. Walaupun TCP boleh menyokong pelbagai jenis aplikasi yang diedarkan, ia tidak sesuai untuk aplikasi masa nyata.

Protokol pengangkutan masa nyata baharu direka untuk menyelesaikan masalah ini - RTP(Protokol Pengangkutan Masa Nyata), yang menjamin penghantaran data kepada satu atau lebih penerima dengan kelewatan dalam had yang ditentukan, iaitu data boleh diterbitkan semula dalam masa nyata.

RTP tidak menyokong sebarang mekanisme untuk penghantaran paket, integriti penghantaran atau kebolehpercayaan sambungan. Semua fungsi ini diberikan kepada protokol pengangkutan. RTP berjalan di atas UDP dan boleh menyokong pemindahan data masa nyata antara berbilang peserta dalam sesi RTP.

Catatan

Bagi setiap peserta RTP, satu sesi ditentukan oleh sepasang alamat pengangkutan destinasi paket (satu alamat rangkaian - IP dan sepasang port: RTP dan RTCP).

Paket RTP mengandungi medan berikut: ID pengirim yang menunjukkan pihak mana yang menjana data, setem masa apabila paket dijana supaya data boleh dimainkan semula pada selang masa yang betul oleh pihak penerima, maklumat tentang susunan penghantaran dan maklumat tentang sifat kandungan paket, cth. jenis pengekodan data video (MPEG, Indeo, dsb.). Kehadiran maklumat sedemikian membolehkan kami menganggarkan nilai kelewatan awal dan saiz penimbal penghantaran.

Catatan

Dalam persekitaran masa nyata yang biasa, pengirim menjana paket pada kadar yang tetap. Mereka dihantar pada selang masa yang tetap, melalui rangkaian dan diterima oleh penerima, yang memainkan semula data dalam masa nyata semasa ia diterima. Walau bagaimanapun, disebabkan oleh perubahan dalam kependaman semasa paket bergerak melalui rangkaian, ia mungkin tiba pada selang masa yang tidak teratur. Untuk mengimbangi kesan ini, paket masuk ditimbal, disimpan untuk satu tempoh masa, dan kemudian diberikan pada kadar tetap kepada perisian penjanaan output. Oleh itu, untuk protokol masa nyata berfungsi, setiap paket perlu mengandungi cap masa supaya penerima boleh mengeluarkan semula data masuk pada kelajuan yang sama seperti pengirim.

Oleh kerana RTP mentakrifkan (dan mengawal) format muatan data yang dihantar, yang berkaitan secara langsung dengan ini ialah konsep penyegerakan, yang sebahagiannya bertanggungjawab untuk mekanisme terjemahan RTP - pengadun. Dengan menerima aliran paket RTP daripada satu atau lebih sumber, pengadun menggabungkannya dan menghantar aliran baharu paket RTP kepada satu atau lebih penerima. Pengadun hanya boleh menggabungkan data dan juga menukar formatnya, sebagai contoh, apabila menggabungkan berbilang sumber audio. Katakan sistem baharu ingin mengambil bahagian dalam sesi, tetapi pautannya ke rangkaian tidak mempunyai kapasiti yang mencukupi untuk menyokong semua aliran RTP, maka pengadun menerima semua aliran ini, menggabungkannya menjadi satu, dan menyerahkan yang terakhir kepada aliran baharu ahli sesi. Apabila menerima berbilang aliran, pengadun hanya menambah nilai modulasi kod nadi. Pengepala RTP yang dijana oleh pengadun termasuk identiti pengirim yang datanya terdapat dalam paket.

Peranti yang lebih ringkas, penterjemah, mencipta satu paket RTP keluar untuk setiap paket RTP yang masuk. Mekanisme ini mungkin mengubah format data dalam paket atau menggunakan set protokol peringkat rendah yang berbeza untuk memindahkan data dari satu domain ke domain yang lain. Sebagai contoh, bakal penerima mungkin tidak dapat memproses isyarat video berkelajuan tinggi yang digunakan oleh peserta lain dalam sesi tersebut. Penterjemah menukar video kepada format kualiti yang lebih rendah yang tidak memerlukan kadar pemindahan data yang tinggi.

Protokol RTP digunakan hanya untuk menghantar data pengguna - biasanya multicast - kepada semua peserta dalam sesi. Protokol RTCP (Protokol Kawalan Pengangkutan Masa Nyata) berfungsi bersama-sama dengan RTP, tugas utamanya adalah untuk menyediakan kawalan ke atas penghantaran RTP. RTCP menggunakan protokol pengangkutan asas yang sama seperti RTP (biasanya UDP), tetapi nombor port yang berbeza.

RTCP melaksanakan beberapa fungsi:

Memastikan dan memantau kualiti perkhidmatan dan maklum balas sekiranya berlaku lebihan beban. Oleh kerana paket RTCP adalah multicast, semua peserta dalam sesi boleh menilai prestasi dan penerimaan peserta lain. Mesej penghantar membolehkan penerima menilai kelajuan data dan kualiti penghantaran. Mesej penerima mengandungi maklumat tentang masalah yang mereka alami, termasuk kehilangan paket dan kegelisahan yang berlebihan. Maklum balas daripada penerima juga penting untuk mendiagnosis ralat dalam pengedaran. Dengan menganalisis mesej daripada semua peserta dalam sesi, pentadbir rangkaian boleh menentukan sama ada masalah yang diberikan melibatkan seorang peserta atau bersifat umum. Jika aplikasi penghantaran menyimpulkan bahawa masalah adalah ciri sistem secara keseluruhan, contohnya, disebabkan oleh kegagalan salah satu saluran komunikasi, maka ia boleh meningkatkan tahap pemampatan data dengan mengorbankan mengurangkan kualiti atau menolak untuk menghantar video sama sekali - ini membolehkan data dihantar melalui sambungan kapasiti rendah.
Pengenalan penghantar. Paket RTCP mengandungi perihalan teks standard penghantar. Mereka memberikan lebih banyak maklumat tentang pengirim paket data daripada ID sumber penyegerakan yang dipilih secara rawak. Mereka juga membantu pengguna mengenal pasti urutan kepunyaan sesi yang berbeza.
Anggaran saiz sesi dan penskalaan. Bagi memastikan kualiti perkhidmatan dan maklum balas bagi tujuan pengurusan kesesakan, serta untuk tujuan mengenal pasti pengirim, semua peserta menghantar paket RTCP secara berkala. Kekerapan penghantaran paket ini berkurangan apabila bilangan peserta bertambah. Dengan bilangan peserta yang kecil, satu paket RTCP dihantar paling banyak setiap 5 saat. RFC-1889 menerangkan algoritma di mana peserta mengehadkan kadar paket RTCP berdasarkan jumlah bilangan peserta. Matlamatnya adalah untuk memastikan trafik RTCP tidak melebihi 5% daripada jumlah trafik sesi.

RTP ialah protokol berorientasikan aliran. Pengepala paket RTP telah dibuat dengan mengambil kira keperluan penghantaran masa nyata. Ia mengandungi maklumat tentang susunan paket supaya strim data dipasang dengan betul pada bahagian penerima, dan cap masa untuk jujukan bingkai yang betul semasa main semula dan untuk menyegerakkan berbilang aliran data, seperti video dan audio.

Setiap paket RTP mempunyai pengepala utama, dan mungkin medan khusus aplikasi tambahan.

Menggunakan TCP sebagai protokol pengangkutan untuk aplikasi ini tidak boleh dilakukan atas beberapa sebab:

Protokol ini hanya membenarkan sambungan diwujudkan antara dua titik akhir, oleh itu ia tidak sesuai untuk penghantaran multicast.
TCP membenarkan penghantaran semula segmen yang hilang yang tiba apabila aplikasi masa nyata tidak lagi menunggunya.
TCP tidak mempunyai mekanisme yang mudah untuk mengaitkan maklumat pemasaan dengan segmen, keperluan tambahan untuk aplikasi masa nyata.

Satu lagi protokol lapisan pengangkutan yang digunakan secara meluas, LJDP tidak mempunyai beberapa batasan TCP, tetapi ia tidak memberikan maklumat pemasaan kritikal.

Walaupun setiap aplikasi masa nyata mungkin mempunyai mekanisme tersendiri untuk menyokong penghantaran masa nyata, ia mempunyai banyak persamaan yang menjadikan penentuan satu protokol sangat diingini.

Masalah ini ialah apa yang direka bentuk untuk diselesaikan oleh protokol pengangkutan masa nyata baharu - RTP (Protokol Pengangkutan Masa Nyata), yang menjamin penghantaran data kepada satu atau lebih penerima dengan kelewatan dalam had yang ditentukan, iaitu data boleh diterbitkan semula dalam masa sebenar.

Dalam Rajah. 1 menunjukkan pengepala RTP tetap yang mengandungi beberapa medan mengenal pasti elemen seperti format paket, nombor urutan, sumber, sempadan dan jenis muatan. Pengepala tetap mungkin diikuti oleh medan lain yang mengandungi maklumat tambahan tentang data.

nasi. 1. Pengepala RTP tetap.

V(2 bit). Medan versi. Versi semasa adalah yang kedua.
R(1 bit). Isi medan. Medan ini menandakan kehadiran oktet padding pada penghujung muatan. Padding digunakan apabila aplikasi memerlukan saiz muatan menjadi gandaan, sebagai contoh, 32 bit. Dalam kes ini, oktet terakhir menunjukkan bilangan oktet padding.
X(1 bit). Medan sambungan pengepala. Apabila medan ini ditetapkan, pengepala utama diikuti dengan pengepala tambahan yang digunakan dalam sambungan RTP percubaan.
SS(4 bit). Medan bilangan pengirim. Medan ini mengandungi bilangan ID pengirim yang datanya berada dalam paket, dengan ID itu sendiri mengikuti pengepala utama.
M(1 bit). Medan penanda. Maksud bit penanda bergantung pada jenis muatan. Bit penanda biasanya digunakan untuk menunjukkan sempadan aliran data. Dalam kes video, ia menentukan hujung bingkai. Dalam kes suara, ia menentukan permulaan pertuturan selepas tempoh senyap.
RT(7 bit). Medan jenis muatan. Medan ini mengenal pasti jenis muatan dan format data, termasuk pemampatan dan penyulitan. Dalam keadaan mantap, pengirim hanya menggunakan satu jenis muatan semasa sesi, tetapi ia boleh mengubahnya sebagai tindak balas kepada keadaan yang berubah jika diisyaratkan oleh Protokol Kawalan Pengangkutan Masa Nyata.
Nombor Urutan(16 bit). Medan nombor urutan. Setiap sumber mula menomborkan paket dengan nombor arbitrari, yang kemudiannya meningkat satu dengan setiap paket data RTP dihantar. Ini membolehkan anda mengesan kehilangan paket dan menentukan susunan paket dengan cap masa yang sama. Berbilang paket berturut-turut mungkin mempunyai cap masa yang sama jika ia secara logik berasal pada masa yang sama, seperti paket yang dimiliki oleh bingkai video yang sama.
Cap masa(32 bit). Medan cap masa. Medan ini mengandungi titik masa di mana oktet data muatan pertama dicipta. Unit di mana masa dilaporkan dalam medan ini bergantung pada jenis muatan. Nilai ditentukan oleh jam tempatan pengirim.
Sumber Penyegerakan (SSRC) Pengecam(32 bit). Medan ID Sumber Segerak: Nombor yang dijana secara rawak yang mengenal pasti sumber secara unik semasa sesi, bebas daripada alamat rangkaian. Nombor ini memainkan peranan penting apabila memproses sekeping data masuk daripada satu sumber.
Pengecam sumber penyumbang (CSRC).(32 bit). Senarai medan pengecam sumber "bercampur" ke dalam strim utama, contohnya, menggunakan pengadun. Pengadun memasukkan senarai keseluruhan pengecam sumber SSRC yang mengambil bahagian dalam pembinaan paket RTP ini. Senarai ini dipanggil CSRC. Bilangan elemen dalam senarai: dari 0 hingga 15. Jika bilangan peserta lebih daripada 15, 15 yang pertama dipilih. Contohnya ialah persidangan audio, paket RTP yang mengandungi ucapan semua peserta, setiap satu dengan SSRC mereka sendiri - mereka membentuk senarai CSRC. Selain itu, keseluruhan persidangan mempunyai SSRC yang sama.

Protokol RTCP, seperti mana-mana protokol kawalan, jauh lebih kompleks dalam struktur dan dalam fungsi yang dilakukan (bandingkan, sebagai contoh, protokol IP dan TCP). Walaupun protokol RTCP adalah berdasarkan RTP, ia mengandungi banyak medan tambahan yang digunakan untuk melaksanakan fungsinya.

Protokol Tempahan Sumber, RSVP, yang sedang disemak oleh Pasukan Petugas Kejuruteraan Internet (IETF), direka bentuk untuk menyelesaikan masalah mengutamakan data sensitif kependaman berbanding data tradisional, yang kependamannya tidak begitu kritikal. RSVP membenarkan sistem akhir untuk menempah sumber rangkaian untuk mendapatkan kualiti perkhidmatan yang diperlukan, terutamanya sumber untuk jadual masa nyata melalui protokol RTP. RSVP terutamanya berkenaan dengan penghala, walaupun aplikasi pada nod akhir juga mesti tahu cara menggunakan RSVP untuk menempah lebar jalur yang diperlukan untuk kelas perkhidmatan atau tahap keutamaan tertentu.

RTP, bersama-sama dengan piawaian lain yang diterangkan, membolehkan anda berjaya menghantar video dan audio melalui rangkaian IP biasa. RTP/RTCP/RSVP - penyelesaian piawai untuk rangkaian dengan penghantaran data masa nyata. Satu-satunya kelemahannya ialah ia hanya bertujuan untuk rangkaian IP. Walau bagaimanapun, had ini adalah sementara: rangkaian akan berkembang ke arah ini satu cara atau yang lain. Penyelesaian ini menjanjikan untuk menyelesaikan masalah penghantaran data sensitif kelewatan melalui Internet.

Penerangan mengenai protokol RTP boleh didapati dalam RFC-1889.

2. Dalam relativisme, "cahaya" adalah fenomena mitos itu sendiri, dan bukan gelombang fizikal, yang merupakan gangguan medium fizikal tertentu. "Cahaya" relativistik ialah keterujaan ketiadaan dalam ketiadaan. Ia tidak mempunyai medium pembawa untuk getaran.

3. Dalam relativisme, manipulasi dengan masa (perlahan) adalah mungkin, oleh itu prinsip kausalitas dan prinsip logik yang ketat, asas kepada mana-mana sains, dilanggar. Dalam relativisme, pada kelajuan cahaya, masa berhenti (oleh itu, adalah tidak masuk akal untuk bercakap tentang kekerapan foton). Dalam relativisme, keganasan terhadap minda sedemikian adalah mungkin, seperti pernyataan tentang kelebihan bersama usia kembar yang bergerak pada kelajuan cahaya, dan ejekan logik lain yang wujud dalam mana-mana agama.

Protokol RTP dan RTCP dalam VoIP

RTP ialah protokol pengangkutan utama dalam rangkaian telefon IP. RTP (Protokol Masa Nyata) ialah protokol masa nyata yang dicipta untuk menghantar maklumat multimedia (audio, video), dikodkan dan dibungkus melalui rangkaian IP dalam had masa yang ketat. Penghantaran segmen RTP berlaku melalui protokol UDP dan IP, masing-masing, pada tahap model OSI yang berbeza. Penggunaan UDP, yang tidak menjamin penghantaran, adalah disebabkan oleh pemasaan penghantaran media masa nyata yang ketat, serta ketidakupayaan TCP untuk beroperasi dalam masa nyata. Oleh itu, walaupun kehilangan beberapa data, penghantaran tepat pada masanya adalah lebih penting dalam kes ini.
Secara umum, pengedaran protokol merentasi lapisan model OSI adalah seperti berikut:
Lapisan pengangkutan: RTP atas UDP
Rangkaian: IP
Saluran: Ethernet
Fizikal: Ethernet
Apabila menghantar maklumat multimedia menggunakan protokol RTP, enkapsulasi berikut digunakan:

Saiz minimum segmen RTP ialah 12 bait. Dua bit pertama menentukan versi protokol. Hari ini RTPv.2 digunakan. Medan P seterusnya juga adalah 2 bit panjang dan menunjukkan kehadiran aksara padding dalam medan data apabila menggunakan segmen yang sama panjang. Medan X menentukan sama ada pengepala lanjutan digunakan. Medan CC 4-bit kemudiannya mentakrifkan bilangan medan CSRC pada penghujung pengepala RTP, iaitu bilangan sumber yang membentuk aliran. Seterusnya datang medan M, bit penanda yang digunakan untuk menyerlahkan data penting. Medan PT seterusnya bersaiz 7 bit. Direka bentuk untuk menentukan jenis muatan - data yang diperlukan untuk aplikasi. Menggunakan kod yang ditentukan, aplikasi menentukan jenis maklumat multimedia dan kaedah penyahkodan.
Pengepala selebihnya terdiri daripada medan SequenceNumber - nombor jujukan segmen, yang menjejaki susunan paket dan kehilangannya; Medan Setem Masa - kod penyegerakan yang menunjukkan masa sampel dikodkan pertama dalam muatan, setem ini digunakan oleh penimbal pemulihan penyegerakan untuk menghapuskan kehilangan kualiti yang disebabkan oleh variasi kelewatan; medan sumber penyegerakan SSRC - nombor arbitrari yang membezakan satu sesi RTP daripada yang lain, untuk mencipta keupayaan pemultipleksan. Selepas bahagian tetap tetap pengepala RTP, sehingga 15 medan CSRC tiga puluh dua bit boleh ditambah yang mengenal pasti sumber data.
Mari kita terangkan prosedur untuk mewujudkan sesi RTP. Protokol menetapkan bahawa trafik pelbagai jenis dihantar dalam sesi komunikasi yang berasingan. Untuk menubuhkan sesi, adalah perlu untuk menentukan sepasang alamat pengangkutan destinasi i.e. satu alamat rangkaian dan dua port untuk RTP dan RTCP. Jadi, untuk persidangan video, adalah perlu untuk menghantar audio dan video dalam sesi yang berbeza dengan port destinasi yang berbeza. Mengangkut jenis trafik yang berbeza menggunakan persimpangan dalam sesi yang sama boleh menyebabkan masalah berikut:
- apabila menukar salah satu jenis trafik, adalah mustahil untuk menentukan parameter mana dalam sesi yang perlu diganti dengan nilai baharu;
- untuk menubuhkan sesi, hanya satu selang masa digunakan, dan apabila menghantar trafik heterogen, setiap jenis akan mempunyai selang sendiri, dan mereka akan berbeza;
- pengadun RTP tidak boleh menggabungkan aliran berjalin pelbagai jenis trafik ke dalam satu aliran;
- penghantaran beberapa jenis trafik dalam satu sesi RTP adalah mustahil atas sebab berikut: penggunaan laluan rangkaian yang berbeza atau pengagihan sumber rangkaian; menerima subset data multimedia apabila diperlukan, sebagai contoh, hanya audio jika isyarat video melebihi lebar jalur yang tersedia; pelaksanaan pendengar yang menggunakan proses berasingan untuk jenis trafik yang berbeza, manakala penggunaan sesi RTP berasingan membolehkan pelaksanaan tunggal dan berbilang proses.

Walau bagaimanapun, RTP (Protokol Pengangkutan Masa Nyata) dan UDP (Protokol Datagram Pengguna) tidak menjamin kualiti, iaitu, ia tidak berfungsi dengan QoS (Kualiti Perkhidmatan). Oleh itu, protokol RTP disokong oleh Protokol Kawalan Pengangkutan Masa Nyata (RTCP), yang menyediakan maklumat tambahan tentang keadaan sesi komunikasi RTP.
Protokol RTCP melaksanakan empat fungsi utama:
I. Tugas utama protokol RTCP adalah untuk menyediakan maklum balas bagi menjamin kualiti penghantaran data. Maklum balas boleh berguna secara langsung apabila digunakan pada penghantaran pengekodan adaptif. Selain itu, apabila menggunakan multicasting IP, amat penting bagi penerima untuk mendiagnosis ralat semasa menghantar mesej (paket). Menghantar mesej dengan laporan penerimaan membenarkan pihak penghantar untuk menentukan sebab penghantaran mesej yang tidak berjaya, jika itu berlaku.
II. RTCP mengandungi pengecam lapisan pengangkutan yang tidak boleh diubah untuk sumber RTP, yang dipanggil "nama kanonik" atau "Cname". Memandangkan pengecam SSRC mungkin berubah jika perlanggaran ditemui, penerima memerlukan nilai Cname untuk menjejaki setiap peserta. Penerima juga menggunakan Cname untuk memetakan berbilang aliran data daripada peserta tunggal apabila mewujudkan berbilang sesi serentak, contohnya, untuk menyegerakkan saluran audio dan video apabila menghantar video dengan audio.
III. Kedua-dua fungsi di atas menganggap bahawa semua peserta dalam sesi telah menghantar paket RTCP, jadi kadar penghantaran mesti dikawal supaya RTP boleh mewujudkan sesi dengan bilangan pengguna yang ramai. Apabila setiap peserta menghantar paket kawalannya kepada orang lain, mana-mana rakan kongsi boleh menentukan secara bebas jumlah bilangan peserta dalam sesi itu. Ini adalah perlu untuk pengiraan kadar penghantaran mesej RTCP.
IV. Fungsi ini digunakan untuk menghantar maklumat kawalan minimum yang diperlukan, seperti ID peserta, yang digunakan oleh GUI. Ciri ini digunakan untuk sesi yang dikawal secara longgar di mana pengguna log masuk dan keluar tanpa rundingan parameter dan ciri yang betul. RTCP berfungsi sebagai saluran mudah untuk menghubungi semua peserta, tetapi ia tidak semestinya menyokong semua keperluan komunikasi aplikasi.
Dalam rangkaian IP menggunakan multicasting, fungsi satu, dua dan tiga adalah wajib apabila menggunakan sesi RTP. Penggunaannya juga disyorkan untuk penghantaran dalam rangkaian dan persekitaran lain. Hari ini, adalah disyorkan bahawa pembangun aplikasi RTP menggunakan alat yang membolehkan mereka berfungsi dalam mod multicast, dan bukan hanya dalam mod unicast.
Mari kita pertimbangkan format paket RTCP.
Piawaian protokol mentakrifkan beberapa jenis paket RTCP. RTCP direka untuk menghantar maklumat perkhidmatan:
sr: Laporan pengirim. Diperlukan untuk statistik penerimaan dan penghantaran peserta sesi yang merupakan penghantar aktif secara langsung;
rr: Laporan penerima. Diperlukan untuk statistik daripada peserta yang bukan penerima;
sdes: Menerangkan sumber, termasuk Cname;
bye: Berfungsi untuk menunjukkan tamat (keluar) sesi;
apl: Fungsi khusus aplikasi;
Setiap paket RTCP terdiri daripada bahagian tetap, seperti untuk protokol RTP, yang digunakan oleh paket RTP, diikuti dengan medan yang boleh berbeza-beza panjang bergantung pada jenis paket, tetapi merupakan gandaan 32 bit. Keperluan penjajaran dan medan panjang dalam bahagian tetap pengepala diperkenalkan untuk menjadikan paket RTCP boleh digabungkan. Berbilang paket RTCP boleh digabungkan bersama tanpa memperkenalkan sebarang pemisah untuk menghasilkan paket RTCP komposit yang dihantar melalui protokol pengangkutan peringkat rendah seperti UDP. Tiada kaunter khas untuk paket RTCP individu, kerana protokol peringkat rendah akan menentukan jumlah panjang dan menentukan penghujung paket komposit.

Format paket mesej penghantar RTCP adalah seperti berikut, seperti yang ditunjukkan dalam rajah di atas.

Paket RTCP tertakluk kepada semakan kewarasan berikut.
- Medan versi RTP mestilah sama dengan 2.
- Medan jenis data bagi paket RTCP pertama dalam paket komposit mestilah SR atau RR.
- Bit padding (P) mestilah sifar untuk paket pertama paket RTCP komposit, kerana padding hanya boleh hadir dalam paket terakhir.
- Panjang medan bagi paket RTCP individu mesti ditambah dengan jumlah panjang paket komposit.

Aplikasi moden tidak mampu untuk mendapatkan paket mereka lewat. Dua protokol (RTP dan PSVP) memastikan penghantaran tepat pada masanya sambil mengekalkan kualiti perkhidmatan.

Pertumbuhan berterusan Internet dan rangkaian persendirian meletakkan permintaan baharu pada lebar jalur. Aplikasi pelanggan-pelayan jauh lebih baik daripada Telnet dari segi jumlah data yang dipindahkan. World Wide Web telah membawa kepada peningkatan besar dalam graf maklumat grafik. Hari ini, sebagai tambahan, aplikasi suara dan video meletakkan permintaan khusus mereka sendiri pada rangkaian yang sudah terlebih beban.

Untuk memenuhi semua permintaan ini, meningkatkan kapasiti rangkaian sahaja tidak mencukupi. Apa yang benar-benar diperlukan ialah pengurusan jadual yang bijak, berkesan dan kawalan beban kerja.

Dari segi sejarah, rangkaian berasaskan IP telah menyediakan semua aplikasi dengan hanya perkhidmatan yang paling mudah untuk menyampaikan data apabila boleh. Walau bagaimanapun, keperluan telah berubah dari semasa ke semasa. Organisasi yang telah membelanjakan berjuta-juta dolar memasang rangkaian berasaskan IP untuk mengangkut data antara LAN kini mendapati bahawa konfigurasi sedemikian tidak dapat menyokong aplikasi multimedia multicast masa nyata baharu dengan berkesan.

ATM ialah satu-satunya teknologi rangkaian yang pada asalnya direka untuk menyokong trafik TCP dan UDP biasa bersama dengan trafik masa nyata. Walau bagaimanapun, memfokuskan pada ATM bermakna sama ada mewujudkan infrastruktur rangkaian baharu untuk trafik masa nyata atau menggantikan konfigurasi berasaskan IP sedia ada, yang kedua-duanya akan menjadi agak mahal.

Oleh itu, keperluan untuk menyokong pelbagai jenis trafik dengan kualiti keperluan perkhidmatan yang berbeza dalam seni bina TCP/IP adalah sangat mendesak. Dua alatan utama direka untuk menyelesaikan masalah ini: Protokol Pengangkutan Masa Nyata (RTP) dan Protokol Tempahan Sumber (RSVP).

RTP menjamin penghantaran data kepada satu atau lebih penerima dengan kelewatan dalam had yang ditentukan. Ini bermakna data boleh dimainkan semula dalam masa nyata. RSVP membenarkan sistem akhir untuk menempah sumber rangkaian untuk mendapatkan kualiti perkhidmatan yang diperlukan, terutamanya sumber untuk trafik masa nyata melalui protokol RTP.

Protokol lapisan pengangkutan yang paling banyak digunakan ialah TCP. Walaupun TCP boleh menyokong pelbagai jenis aplikasi yang diedarkan, ia tidak sesuai untuk aplikasi masa nyata.

Dalam aplikasi masa nyata, penghantar menjana aliran data pada kadar yang tetap, dan penerima mesti memberikan data tersebut kepada aplikasi pada kadar yang sama. Aplikasi sedemikian termasuk persidangan audio dan video, pengedaran video langsung (untuk main balik segera), ruang kerja kongsi, diagnostik perubatan jauh, telefon komputer, simulasi interaktif teragih, permainan dan pemantauan masa nyata.

Menggunakan TCP sebagai protokol pengangkutan untuk aplikasi ini tidak boleh dilakukan atas beberapa sebab. Pertama, protokol ini hanya membenarkan sambungan diwujudkan antara dua titik akhir dan oleh itu tidak sesuai untuk penghantaran multicast. Ia membolehkan penghantaran semula segmen yang hilang yang tiba apabila aplikasi masa nyata tidak lagi mengharapkannya. Selain itu, TCP tidak mempunyai mekanisme yang mudah untuk mengaitkan maklumat pemasaan dengan segmen, yang juga merupakan keperluan bagi aplikasi masa nyata.

Satu lagi protokol lapisan pengangkutan yang digunakan secara meluas, UDP tidak mempunyai dua yang pertama

had (sambungan titik ke titik dan penghantaran segmen yang hilang), tetapi ia tidak memberikan maklumat penyegerakan kritikal. Oleh itu, UDP sendiri tidak mempunyai sebarang alat tujuan umum untuk aplikasi masa nyata.

Dalam persekitaran masa nyata yang biasa, pengirim menjana paket pada kadar yang tetap. Mereka dihantar kepada mereka pada selang masa yang tetap, melalui rangkaian dan diterima oleh penerima, yang mengeluarkan semula data dalam masa nyata setelah diterima.

Walau bagaimanapun, disebabkan oleh variasi dalam kependaman semasa paket bergerak melalui rangkaian, ia tiba pada selang masa yang tidak teratur. Untuk mengimbangi kesan ini, paket masuk ditimbal, disimpan untuk satu tempoh masa, dan kemudian diberikan pada kadar tetap kepada perisian penjanaan output. Untuk skim ini berfungsi, setiap paket dicap masa supaya penerima boleh memainkan semula data masuk pada kelajuan yang sama seperti pengirim.

RTP menyokong pemindahan data masa nyata antara berbilang peserta sesi. (Sesi ialah sambungan logik antara dua atau lebih pengguna RTP yang dikekalkan untuk tempoh pemindahan data. Proses membuka sesi adalah di luar skop RTP.)

Walaupun RTP boleh digunakan untuk penghantaran unicast masa nyata, kekuatannya terletak pada sokongannya untuk penghantaran multicast. Untuk mencapai matlamat ini, setiap blok data RTP mengandungi pengecam penghantar yang menunjukkan peserta mana yang menjana data. Blok data RTP juga mengandungi cap masa supaya data boleh dimainkan semula pada selang masa yang betul oleh hujung penerima.

Selain itu, RTP mentakrifkan format muatan bagi data yang dihantar. Secara langsung berkaitan dengan ini ialah konsep penyegerakan, yang mana pengadun, mekanisme penyiaran RTP, bertanggungjawab sebahagiannya. Dengan menerima aliran paket RTP daripada satu atau lebih sumber, ia menggabungkannya dan menghantar aliran baharu paket RTP kepada satu atau lebih penerima. Pengadun hanya boleh menggabungkan data dan juga menukar formatnya.

Contoh aplikasi untuk pengadun adalah menggabungkan berbilang sumber audio. Sebagai contoh, katakan bahawa sebahagian daripada sistem dalam sesi audio tertentu masing-masing menghasilkan strim RTP sendiri. Selalunya, hanya satu sumber yang aktif, walaupun kadangkala beberapa sumber "bercakap" pada masa yang sama.

Jika sistem baharu ingin mengambil bahagian dalam sesi, tetapi pautannya ke rangkaian tidak mempunyai kapasiti tepat yang mencukupi untuk menyokong semua aliran RTP, maka pengadun menerima semua aliran tersebut, menggabungkannya menjadi satu, dan menyerahkan yang terakhir kepada aliran ahli sesi baru. Apabila menerima berbilang aliran, pengadun menambah nilai modulasi kod nadi. Pengepala RTP yang dijana oleh pengadun termasuk pengecam pengirim yang datanya terdapat dalam paket.

Peranti yang lebih ringkas menghasilkan satu paket RTP keluar untuk setiap paket RTP yang masuk. Mekanisme ini, dipanggil penterjemah, boleh menukar format data dalam paket atau menggunakan set protokol peringkat rendah yang berbeza untuk memindahkan data dari satu domain ke domain yang lain. Sebagai contoh, bakal penerima mungkin tidak dapat memproses isyarat video berkelajuan tinggi yang digunakan oleh peserta lain dalam sesi tersebut. Kemudian penterjemah menukar video kepada format kualiti yang lebih rendah yang tidak memerlukan kadar pemindahan data yang begitu tinggi.

Setiap paket RTP mempunyai pengepala utama, dan mungkin medan khusus aplikasi tambahan. nasi. 4 menggambarkan struktur tajuk utama. 12 oktet pertama terdiri daripada medan berikut:

medan versi (2 bit): versi semasa - kedua;
medan padding (1 bit): Medan ini menandakan kehadiran oktet padding pada penghujung muatan. (Padding digunakan apabila aplikasi memerlukan saiz muatan menjadi gandaan, sebagai contoh, 32 bit.) Dalam kes ini, oktet terakhir menentukan bilangan oktet padding;
medan sambungan pengepala (1 bit): apabila medan ini ditetapkan, pengepala utama diikuti oleh satu pengepala tambahan yang digunakan dalam sambungan RTP percubaan;
medan bilangan penghantar (4 bit): medan ini mengandungi bilangan pengecam penghantar yang datanya berada dalam paket, dengan pengecam itu sendiri mengikuti pengepala utama;
medan penanda (1 bit): Maksud bit penanda bergantung pada jenis muatan. Bit penanda biasanya digunakan untuk menunjukkan sempadan aliran data. Dalam kes video, ia menentukan hujung bingkai. Dalam kes suara, ia menentukan permulaan pertuturan selepas tempoh senyap;
Medan Jenis Muatan (7 bit): Medan ini mengenal pasti jenis muatan dan format data, termasuk pemampatan dan penyulitan. Dalam keadaan mantap, pengirim hanya menggunakan satu jenis muatan semasa sesi, tetapi ia boleh mengubahnya sebagai tindak balas kepada perubahan keadaan jika diisyaratkan oleh Protokol Kawalan Pengangkutan Masa Nyata;
medan nombor jujukan (16 bit): setiap sumber mula menomborkan paket dengan nombor rawak, yang kemudiannya ditambah dengan satu dengan setiap paket data RTP dihantar. Ini membolehkan anda mengesan kehilangan paket dan menentukan susunan paket dengan cap masa yang sama. Berbilang paket berturut-turut mungkin mempunyai cap masa yang sama jika ia secara logik berasal pada saat yang sama (contohnya, paket kepunyaan bingkai video yang sama);
medan cap waktu (32 bit): Ini merekodkan titik masa di mana oktet data muatan pertama dijana. Unit di mana masa dinyatakan dalam medan ini bergantung pada jenis muatan. Nilai ditentukan oleh jam tempatan pengirim;
Medan ID Sumber Segerak: Nombor yang dijana secara rawak yang mengenal pasti sumber secara unik dalam sesi.

Pengepala utama mungkin diikuti oleh satu atau lebih medan yang mengenal pasti pengirim yang datanya terdapat dalam muatan. ID ini dimasukkan oleh pengadun.

Protokol RTP digunakan hanya untuk menghantar data pengguna - biasanya multicast - kepada semua peserta dalam sesi. Protokol Kawalan Pengangkutan Masa Nyata (RTCP) yang berasingan berfungsi dengan berbilang destinasi untuk memberikan maklum balas kepada pengirim RTP dan peserta sesi lain.

RTCP menggunakan protokol pengangkutan asas yang sama seperti RTP (biasanya UDP), tetapi nombor port yang berbeza. Setiap peserta sesi menghantar paket RTCP secara berkala kepada semua peserta sesi lain. RFC 1889 menerangkan tiga fungsi yang dilakukan oleh RTCP.

Fungsi pertama adalah untuk menyediakan kualiti perkhidmatan dan maklum balas sekiranya berlaku lebihan beban. Oleh kerana paket RTCP adalah multicast, semua peserta dalam sesi boleh menilai prestasi dan penerimaan peserta lain. Mesej penghantar membolehkan penerima menilai kelajuan data dan kualiti penghantaran. Mesej penerima mengandungi maklumat tentang masalah yang mereka alami, termasuk kehilangan paket dan kegelisahan yang berlebihan. Sebagai contoh, kadar bit untuk aplikasi audio/video mungkin dikurangkan jika talian tidak memberikan kualiti perkhidmatan yang diingini pada kadar bit tertentu.

Maklum balas daripada penerima juga penting untuk mendiagnosis ralat dalam pengedaran.

Dengan menganalisis mesej daripada semua peserta dalam sesi, pentadbir rangkaian boleh menentukan sama ada masalah yang diberikan melibatkan seorang peserta atau bersifat umum.

Fungsi utama kedua RTCP ialah pengenalan penghantar. Paket RTCP mengandungi perihalan teks standard penghantar. Mereka memberikan lebih banyak maklumat tentang pengirim paket data daripada ID sumber penyegerakan yang dipilih secara rawak. Mereka juga membantu pengguna mengenal pasti urutan kepunyaan sesi yang berbeza. Oleh itu, mereka membenarkan pengguna menentukan bahawa sesi berasingan untuk audio dan video dibuka pada masa yang sama.

Fungsi ketiga adalah untuk menganggar saiz dan skala sesi. Bagi memastikan kualiti perkhidmatan dan maklum balas bagi tujuan pengurusan kesesakan, serta untuk tujuan mengenal pasti pengirim, semua peserta menghantar paket RTCP secara berkala. Kekerapan penghantaran paket ini berkurangan apabila bilangan peserta bertambah.

Dengan bilangan peserta yang kecil, satu paket RTCP dihantar paling banyak setiap lima saat. RFC 1889 menerangkan algoritma di mana peserta mengehadkan kadar paket RTCP berdasarkan jumlah bilangan peserta. Matlamatnya adalah untuk memastikan trafik RTCP tidak melebihi 5% daripada jumlah trafik sesi.

Tujuan mana-mana rangkaian adalah untuk menghantar data kepada penerima dengan kualiti perkhidmatan yang terjamin, termasuk pemprosesan, kependaman dan toleransi untuk variasi kependaman. Apabila bilangan pengguna dan aplikasi bertambah, ia menjadi semakin sukar untuk memastikan perkhidmatan berkualiti.

Hanya bertindak balas terhadap beban berlebihan tidak lagi mencukupi. Apa yang diperlukan ialah alat yang boleh membantu mengelakkan kesesakan sama sekali, iaitu membolehkan aplikasi menempah sumber rangkaian mengikut kualiti perkhidmatan yang diperlukan.

Langkah-langkah pencegahan berguna untuk penghantaran unicast dan multicast. Dalam unicast, dua aplikasi merundingkan tahap kualiti perkhidmatan tertentu untuk sesi tertentu. Jika rangkaian banyak dimuatkan, ia mungkin tidak dapat memberikan kualiti perkhidmatan yang diperlukan. Dalam keadaan ini, permohonan perlu menangguhkan sesi sehingga masa yang lebih baik atau cuba mengurangkan kualiti keperluan perkhidmatan, jika boleh.

Penyelesaian dalam kes ini adalah untuk aplikasi unicast untuk menempah sumber untuk menyediakan tahap perkhidmatan yang diperlukan. Penghala di sepanjang laluan yang dimaksudkan kemudian memperuntukkan sumber (contohnya, ruang baris gilir dan beberapa kapasiti pautan keluar). Jika penghala tidak dapat memperuntukkan sumber disebabkan komitmen sebelumnya, ia memberitahu aplikasi. Dalam kes ini, aplikasi mungkin cuba memulakan sesi lain dengan kualiti keperluan perkhidmatan yang lebih rendah atau menjadualkannya semula ke tarikh yang akan datang.

Multicast membentangkan cabaran tempahan sumber yang lebih kompleks. Ia membawa kepada penjanaan sejumlah besar graf rangkaian - dalam kes aplikasi seperti video, sebagai contoh, atau apabila terdapat kumpulan penerima yang besar dan tersebar. Walau bagaimanapun, trafik daripada sumber multicast pada dasarnya boleh dikurangkan dengan ketara.

Terdapat dua sebab untuk ini. Pertama, sesetengah ahli kumpulan mungkin tidak memerlukan data untuk dihantar daripada sumber tertentu dalam tempoh masa tertentu. Oleh itu, ahli satu kumpulan boleh menerima maklumat secara serentak melalui dua saluran (dari dua sumber), tetapi penerima mungkin berminat untuk menerima hanya satu saluran.

Kedua, sesetengah ahli kumpulan hanya boleh memproses sebahagian daripada maklumat yang dihantar oleh pengirim. Sebagai contoh, strim video mungkin terdiri daripada dua komponen: satu dengan kualiti gambar yang rendah dan satu lagi dengan kualiti gambar yang tinggi. Format ini mempunyai beberapa algoritma pemampatan video: ia menghasilkan komponen asas dengan imej berkualiti rendah dan komponen tambahan dengan resolusi yang lebih tinggi.

Sesetengah penerima mungkin tidak mempunyai kuasa pemprosesan yang mencukupi untuk memproses komponen resolusi tinggi, atau mungkin disambungkan ke rangkaian melalui subnet atau pautan yang tidak mempunyai kapasiti yang mencukupi untuk membawa isyarat penuh.

Tempahan sumber membolehkan penghala menentukan terlebih dahulu sama ada mereka boleh menghantar trafik multicast kepada semua penerima.

Dalam percubaan sebelumnya untuk melaksanakan tempahan sumber dan dalam geganti bingkai dan pendekatan ATM, sumber yang diperlukan diminta oleh sumber aliran data. Kaedah ini mencukupi dalam kes penghantaran unicast kerana aplikasi penghantaran menghantar data pada kadar tertentu, dan tahap kualiti perkhidmatan yang diperlukan terbina dalam reka bentuk penghantaran.

Walau bagaimanapun, pendekatan ini tidak boleh digunakan untuk multicast. Ahli pasukan yang berbeza mungkin mempunyai keperluan sumber yang berbeza. Jika aliran asal boleh dibahagikan kepada substrim, maka sesetengah ahli kumpulan mungkin ingin menerima hanya satu daripadanya. Khususnya, sesetengah penerima hanya akan dapat memproses komponen video resolusi rendah. Atau jika beberapa pengirim disiarkan ke satu kumpulan, maka penerima boleh memilih hanya satu pengirim atau beberapa subset daripada mereka. Akhir sekali, kualiti keperluan perkhidmatan bagi penerima yang berbeza mungkin berbeza-beza bergantung pada peralatan output, kuasa pemproses dan kelajuan pautan.

Atas sebab ini, tempahan sumber oleh penerima dilihat sebagai lebih baik. Pengirim boleh menyediakan penghala dengan ciri trafik umum (seperti kadar data dan kebolehubahan), tetapi penerima mesti menentukan tahap kualiti perkhidmatan yang mereka perlukan. Penghala kemudian mengagregatkan permintaan peruntukan sumber ke bahagian biasa pokok pengedaran.

RSVP adalah berdasarkan tiga konsep yang berkaitan dengan aliran data: sesi, spesifikasi aliran dan spesifikasi penapis. Sesi ialah aliran data yang dikenal pasti mengikut destinasinya. Ambil perhatian bahawa konsep ini berbeza daripada sesi RTP, walaupun sesi RSVP dan RTP boleh mempunyai surat-menyurat satu dengan satu. Setelah penghala menyimpan sumber untuk destinasi tertentu, ia menganggap ini sebagai permulaan sesi dan memperuntukkan sumber untuk tempoh sesi tersebut.

Permintaan tempahan daripada sistem akhir penerima, dipanggil deskriptor aliran, terdiri daripada spesifikasi aliran dan penapis. Spesifikasi Aliran menentukan kualiti perkhidmatan yang diperlukan dan digunakan oleh nod untuk menetapkan parameter penjadual paket. Penghala memajukan paket dengan satu set keutamaan berdasarkan spesifikasi aliran semasa.

Spesifikasi Penapis mentakrifkan set pakej untuk sumber yang diminta. Bersama-sama dengan sesi, ia mentakrifkan satu set paket (atau aliran) yang mana kualiti perkhidmatan yang diperlukan mesti disediakan. Sebarang paket lain yang dihantar ke destinasi ini diproses sehingga rangkaian dapat berbuat demikian.

RSVP tidak mentakrifkan kandungan spesifikasi aliran, ia hanya menghantar permintaan. Spesifikasi aliran biasanya termasuk kelas perkhidmatan, Rspec (R bermaksud rizab) dan Tspec (T bermaksud trafik). Dua parameter lain ialah satu set nombor. Parameter Rspec mentakrifkan kualiti perkhidmatan yang diperlukan, dan parameter Tspec menerangkan aliran data. Kandungan Rspec dan Tspec adalah telus kepada RSVP.

Pada dasarnya, spesifikasi penapis menerangkan subset paket yang sewenang-wenangnya daripada satu sesi (iaitu, paket tersebut yang destinasinya ditentukan oleh sesi itu). Sebagai contoh, spesifikasi penapis mungkin mengenal pasti hanya penghantar tertentu, atau mungkin mengenal pasti protokol atau paket yang medan pengepala protokolnya sepadan dengan yang ditentukan.

nasi. 3 menggambarkan hubungan antara sesi, spesifikasi aliran dan spesifikasi penapis. Setiap paket masuk tergolong dalam sekurang-kurangnya satu sesi dan dianggap mengikut aliran logik untuk sesi tersebut. Jika paket itu bukan milik mana-mana sesi, maka ia dihantar selagi ada sumber percuma.

Kesukaran utama dengan RSVP ialah multicast. Contoh konfigurasi multicast ditunjukkan dalam Rajah. 6. Konfigurasi ini terdiri daripada empat penghala. Pautan antara mana-mana dua penghala, yang diwakili oleh garis, boleh sama ada pautan langsung atau subnet. Tiga hos - Gl, G2 dan G3 - tergolong dalam kumpulan yang sama dan menerima datagram dengan alamat kumpulan yang sepadan. Data ke alamat ini dihantar oleh dua hos - S1 dan S2. Garis merah sepadan dengan pepohon penghalaan untuk S1 dan kumpulan ini, dan garis biru untuk S2 dan kumpulan ini. Garisan dengan anak panah menunjukkan arah penghantaran paket dari S1 (merah) dan dari S2 (biru).

Angka tersebut menunjukkan bahawa keempat-empat penghala mesti mengetahui tempahan sumber setiap penerima. Oleh itu, permintaan peruntukan sumber merambat ke belakang melalui pepohon penghalaan.

RSVP menggunakan dua jenis mesej utama: Resv dan Path. Mesej Resv dijana oleh penerima dan disebarkan ke atas pokok, dengan setiap nod di sepanjang jalan menggabungkan dan memasang semula paket daripada penerima yang berbeza apabila boleh. Mesej ini menyebabkan penghala memasuki keadaan tempahan sumber untuk sesi tersebut (alamat berbilang siaran). Akhirnya, semua mesej Resv agregat sampai ke hos penghantaran. Berdasarkan maklumat yang diterima, mereka menetapkan parameter kawalan jadual yang sesuai untuk lompatan pertama.

nasi. 7 menunjukkan aliran mesej Resv. Sila ambil perhatian: mesej digabungkan; oleh itu, hanya satu mesej dihantar ke mana-mana cawangan pokok penghantaran gabungan. Walau bagaimanapun, mesej ini mesti dihantar semula secara berkala untuk melanjutkan tempoh tempahan sumber.

Mesej Path digunakan untuk menyebarkan maklumat tentang laluan pulang. Semua protokol penghalaan multicast moden hanya menyokong laluan langsung dalam bentuk pokok penyebaran (turun dari pengirim). Tetapi mesej Resv mesti dihantar ke arah sebaliknya melalui semua penghala perantaraan kepada semua hos penghantaran.

Memandangkan protokol penghalaan tidak memberikan maklumat laluan terbalik, ia dibawa oleh RSVP dalam mesej Laluan. Mana-mana hos yang ingin menjadi pengirim menghantar mesej Laluan kepada semua ahli kumpulan. Sepanjang perjalanan, setiap penghala dan setiap hos destinasi memasuki keadaan laluan yang menunjukkan bahawa paket untuk pengirim itu harus dimajukan ke nod transit dari mana paket itu diterima. nasi. 5 menunjukkan bahawa paket Path dihantar sepanjang laluan yang sama seperti paket data.

Mari lihat cara protokol RSVP berfungsi. Dari sudut pandangan hos, pengendalian protokol terdiri daripada peringkat berikut (dua peringkat pertama dalam urutan ini kadangkala dalam susunan terbalik).

Penerima menyertai kumpulan multicast dengan menghantar mesej IGMP ke penghala jiran.
Pengirim berpotensi menghantar mesej ke alamat kumpulan.
Penerima menerima mesej Path yang mengenal pasti pengirim.
Kini setelah penerima mempunyai maklumat laluan terbalik, ia boleh menghantar mesej Resv dengan deskriptor aliran.
Mesej Resv dihantar melalui rangkaian kepada penghantar.
Pengirim memulakan penghantaran data.
Penerima mula menerima paket data.

Kaedah semalam bekerja dengan jumlah grafik yang besar sama sekali tidak sesuai untuk sistem moden. Tanpa alat baharu, adalah mustahil untuk memenuhi permintaan yang semakin meningkat untuk penghantaran data disebabkan oleh pertumbuhan volum data, penyebaran aplikasi masa nyata dan pengedaran multicast. RTP dan RSVP menyediakan asas yang kukuh untuk generasi LAN seterusnya.

Contoh aplikasi sebenar protokol ini ialah model VoIP (Voice over IP) - penghantaran suara melalui rangkaian IP, yang diterangkan dalam standard H.232 dan menyediakan penghantaran audio, maklumat video dan data melalui rangkaian IP . Dalam kes ini, protokol masa nyata RTP digunakan untuk mewujudkan sambungan, dan protokol RSVP digunakan untuk menempah sumber rangkaian.

Salah satu trend terpenting dalam evolusi telekomunikasi moden ialah pembangunan telefon IP - pelbagai teknologi baharu yang memastikan penghantaran mesej multimedia (pertuturan, data, video) melalui maklumat dan rangkaian komputer (ICN), dibina di atas asas IP (Internet Protocol), termasuk tempatan, korporat, rangkaian komputer global dan Internet. Konsep telefon IP merangkumi telefon Internet, yang membolehkan penganjuran komunikasi telefon antara pelanggan Internet, antara pelanggan rangkaian telefon awam (PSTN) melalui Internet, serta komunikasi telefon antara PSTN dan pelanggan Internet antara satu sama lain.

Telefoni IP mempunyai beberapa kelebihan yang tidak diragukan lagi yang memastikan perkembangan pesat dan pengembangan pasaran telefon komputer. Ia memberi manfaat kepada pengguna akhir, yang disediakan dengan perkhidmatan telefon pada caj seminit yang agak rendah. Bagi syarikat yang mempunyai cawangan terpencil, teknologi IP membolehkan mereka mengatur komunikasi suara menggunakan rangkaian IP korporat sedia ada. Daripada beberapa rangkaian komunikasi, satu digunakan. Kelebihan telefon IP yang tidak dapat dinafikan berbanding telefon biasa ialah keupayaan untuk menyediakan perkhidmatan tambahan melalui penggunaan komputer multimedia dan pelbagai aplikasi Internet. Oleh itu, dengan telefon IP, perniagaan dan individu boleh mengembangkan keupayaan komunikasi mereka untuk memasukkan persidangan video lanjutan, perkongsian aplikasi, alat jenis papan putih dan seumpamanya.

Apakah piawaian dan protokol antarabangsa yang mengawal parameter asas dan algoritma untuk fungsi komunikasi perkakasan dan perisian yang digunakan dalam telefon IP? Jelas sekali, seperti namanya, teknologi ini berdasarkan protokol IP, yang, bagaimanapun, digunakan bukan sahaja untuk telefon: ia pada asalnya dibangunkan untuk menghantar data digital ke sistem maklumat bertukar paket.

Dalam rangkaian yang tidak menyediakan kualiti perkhidmatan yang terjamin (ini termasuk rangkaian yang dibina pada protokol IP), paket mungkin hilang, susunan ketibaannya mungkin berubah, dan data yang dihantar dalam paket mungkin diherotkan. Untuk memastikan penghantaran maklumat yang dihantar yang boleh dipercayai di bawah keadaan ini, pelbagai prosedur lapisan pengangkutan digunakan. Apabila menghantar data digital, protokol TCP (Transmission Control Protocol) digunakan untuk tujuan ini. Protokol ini memastikan penghantaran data yang boleh dipercayai dan memulihkan susunan asal paket. Jika ralat dikesan dalam paket atau paket hilang, prosedur TCP menghantar permintaan untuk penghantaran semula.

Untuk aplikasi persidangan audio dan video, kelewatan paket mempunyai kesan yang lebih besar terhadap kualiti isyarat daripada rasuah data individu. Perbezaan dalam kelewatan boleh mengakibatkan jeda. Aplikasi sedemikian memerlukan protokol lapisan pengangkutan lain yang menyediakan pemulihan urutan asal paket, penghantarannya dengan kelewatan yang minimum, main balik masa nyata pada momen yang ditentukan dengan tepat, pengecaman jenis trafik, komunikasi kumpulan atau dua hala. Protokol ini ialah protokol pengangkutan masa nyata RTP (Protokol Pengangkutan Masa Nyata). Protokol ini mengawal selia pemindahan data multimedia dalam paket melalui IVS pada tahap pengangkutan dan dilengkapi dengan protokol kawalan pemindahan data masa nyata RTCP (Protokol Kawalan Masa Nyata). Protokol RTCP pula menyediakan kawalan penghantaran media, kawalan kualiti perkhidmatan, komunikasi tentang peserta dalam sesi komunikasi semasa, pengurusan dan pengenalan, dan kadangkala dianggap sebahagian daripada protokol RTP.

Banyak penerbitan yang dikhaskan untuk telefon IP menyatakan bahawa kebanyakan peralatan rangkaian dan perisian khas untuk teknologi ini dibangunkan berdasarkan Pengesyoran Sektor Standardisasi Telekomunikasi Kesatuan Telekomunikasi Antarabangsa (ITU-T) H.323 (termasuk TAPI 3.0, NetMeeting 2.0, dsb. .). Bagaimanakah H.323 berkaitan dengan protokol RTP dan RTCP? H.323 ialah rangka kerja konsep yang luas yang merangkumi banyak piawaian lain, setiap satu merangkumi aspek pemindahan maklumat yang berbeza. Kebanyakan piawaian ini, seperti piawaian codec audio dan video, digunakan secara meluas bukan sahaja dalam telefon IP. Bagi protokol RTP/RTCP, ia menjadi asas kepada piawaian H.323, memberi tumpuan kepada penyediaan teknologi IP, dan mendasari organisasi telefon IP. Artikel ini ditumpukan kepada pertimbangan protokol ini.

Ambil perhatian bahawa RTP sendiri tidak mempunyai sebarang mekanisme untuk menjamin penghantaran data tepat pada masanya dan kualiti perkhidmatan, tetapi menggunakan perkhidmatan asas untuk memastikan ini. Ia tidak menghalang paket yang tidak tertib, tetapi ia tidak menganggap bahawa rangkaian asas benar-benar boleh dipercayai dan menghantar paket dalam urutan yang betul. Nombor jujukan yang disertakan dalam RTP membolehkan penerima membina semula jujukan paket penghantar.

Unit data protokol RTP/RTCP dipanggil paket. Paket yang dijana mengikut protokol RTP dan digunakan untuk menghantar data multimedia dipanggil paket maklumat atau paket data, dan paket yang dihasilkan mengikut protokol RTCP dan digunakan untuk menghantar maklumat perkhidmatan yang diperlukan untuk operasi telesidang yang boleh dipercayai dipanggil kawalan paket atau paket kawalan. Paket RTP termasuk pengepala tetap, sambungan pengepala panjang pembolehubah pilihan dan medan data. Paket RTCP bermula dengan bahagian tetap (serupa dengan bahagian tetap paket maklumat RTP), diikuti dengan elemen struktur yang mempunyai panjang berubah-ubah.

Agar protokol RTP menjadi lebih fleksibel dan boleh digunakan untuk pelbagai aplikasi, beberapa parameternya dibuat dengan sengaja tidak ditentukan, tetapi ia menyediakan konsep profil. Profil ialah satu set parameter protokol RTP dan RTCP untuk kelas aplikasi tertentu, yang menentukan ciri fungsinya. Profil mentakrifkan penggunaan medan pengepala paket individu, jenis trafik, penambahan pengepala dan sambungan pengepala, jenis paket, perkhidmatan dan algoritma untuk memastikan keselamatan komunikasi, ciri penggunaan protokol asas, dsb. (sebagai contoh, seksyen 11 mempertimbangkan yang dicadangkan dalam profil RFC 1890 RTP untuk persidangan audio dan video dengan kawalan minimum). Setiap aplikasi biasanya berfungsi dengan hanya satu profil, dan jenis profil ditetapkan dengan memilih aplikasi yang sesuai. Tiada petunjuk jelas tentang jenis profil mengikut nombor port, pengecam protokol, dsb. tidak disediakan.

Ciri-ciri pemindahan data multimedia semasa persidangan audio dan video dibincangkan dalam bahagian berikut.

Persidangan audio kumpulan memerlukan alamat kumpulan berbilang pengguna dan dua port. Dalam kes ini, satu port diperlukan untuk pertukaran data audio, dan satu lagi digunakan untuk paket kawalan protokol RTCP. Alamat kumpulan dan maklumat pelabuhan dihantar kepada peserta yang dimaksudkan dalam telesidang. Jika privasi diperlukan, maklumat dan paket kawalan mungkin disulitkan seperti yang ditakrifkan dalam Bahagian 7.1, dalam hal ini kunci penyulitan juga mesti dijana dan diedarkan.

Di Internet, seperti pada rangkaian data bertukar paket lain, paket kadangkala hilang dan disusun semula, dan ditangguhkan untuk jumlah masa yang berbeza-beza. Untuk mengatasi peristiwa ini, pengepala RTP mengandungi cap masa dan nombor jujukan yang membolehkan penerima menetapkan semula pemasaan supaya, sebagai contoh, bahagian isyarat audio dimainkan secara berterusan oleh pembesar suara setiap 20 ms. Pembinaan semula masa ini dilakukan secara berasingan dan bebas untuk setiap sumber paket RTP dalam kumpulan berita. Nombor jujukan juga boleh digunakan oleh penerima untuk menganggarkan jumlah paket yang hilang.

Memandangkan peserta dalam telesidang boleh menyertai dan meninggalkan persidangan semasa sedang berlangsung, adalah berguna untuk mengetahui siapa yang sedang mengambil bahagian dalam persidangan itu dan sejauh mana peserta persidangan menerima data audio. Untuk tujuan ini, setiap contoh aplikasi audio semasa persidangan secara berkala mengeluarkan mesej pada port kawalan (port RTCP) untuk aplikasi semua peserta lain tentang penerimaan paket yang menunjukkan nama penggunanya. Mesej terima menunjukkan seberapa baik pembesar suara semasa didengar dan boleh digunakan untuk mengawal pengekod suai. Sebagai tambahan kepada nama pengguna, maklumat pengenalan lain untuk kawalan lebar jalur mungkin juga disertakan. Apabila meninggalkan persidangan, tapak menghantar paket RTCP BYE.

Jika kedua-dua isyarat audio dan video digunakan dalam telesidang, ia dihantar secara berasingan. Untuk menghantar setiap jenis trafik secara bebas daripada yang lain, spesifikasi protokol memperkenalkan konsep sesi komunikasi RTP (lihat senarai singkatan dan istilah yang digunakan). Sesi ditakrifkan oleh sepasang alamat pengangkutan destinasi tertentu (satu alamat rangkaian ditambah sepasang port untuk RTP dan RTCP). Paket untuk setiap jenis trafik dihantar menggunakan dua pasangan port UDP dan/atau alamat multicast yang berbeza. Tiada sambungan RTP langsung antara sesi audio dan video, kecuali pengguna yang mengambil bahagian dalam kedua-dua sesi mesti menggunakan nama kanonik yang sama dalam paket RTCP untuk kedua-dua sesi supaya sesi boleh dipautkan.

Tidak semua tapak sentiasa boleh menerima data multimedia dalam format yang sama. Pertimbangkan kes di mana peserta dari satu lokasi disambungkan melalui pautan berkelajuan rendah kepada majoriti peserta persidangan lain yang mempunyai akses jalur lebar ke rangkaian. Daripada memaksa semua orang menggunakan lebar jalur yang lebih rendah dan pengekodan audio berkualiti rendah, kemudahan komunikasi lapisan RTP, yang dipanggil pengadun, boleh diletakkan di kawasan lebar jalur yang rendah. Pengadun ini menyegerakkan semula paket audio yang masuk untuk memulihkan selang 20-ms asal, mencampurkan strim audio yang dibina semula ini ke dalam satu aliran, mengekod isyarat audio untuk lebar jalur yang sempit dan menghantar aliran paket melalui pautan berkelajuan rendah. Dalam kes ini, paket boleh dialamatkan kepada satu penerima atau sekumpulan penerima dengan alamat yang berbeza. Untuk membolehkan titik akhir menerima memberikan petunjuk yang betul tentang sumber mesej, pengepala RTP termasuk cara untuk pengadun mengenal pasti sumber yang menyumbang kepada komposisi paket campuran.

Sesetengah peserta persidangan audio mungkin disambungkan melalui pautan jalur lebar, tetapi mungkin tidak boleh dihubungi melalui persidangan kumpulan berbilang siaran IP (IPM). Sebagai contoh, mereka mungkin berada di belakang tembok api lapisan aplikasi yang tidak akan membenarkan sebarang paket IP dihantar. Untuk kes sedemikian, anda tidak memerlukan pengadun, tetapi satu lagi jenis peralatan komunikasi peringkat RTP, dipanggil penterjemah. Daripada dua geganti, satu dipasang di luar tembok api dan secara luaran memajukan semua paket multicast yang diterima melalui sambungan selamat ke geganti lain yang dipasang di belakang tembok api. Geganti di belakang tembok api menghantarnya semula sebagai paket multicast kepada kumpulan berbilang pengguna terhad kepada rangkaian dalaman tapak.

Pengadun dan penterjemah boleh direka bentuk untuk beberapa tujuan. Contoh: Pengadun video yang menskalakan imej video individu pada strim video bebas dan menyusunnya menjadi satu strim video, mensimulasikan adegan kumpulan. Contoh terjemahan: menyambungkan kumpulan hos IP/UDP sahaja kepada kumpulan hos ST-II sahaja, atau transkod paket video mengikut paket daripada sumber individu tanpa penyegerakan semula atau pencampuran. Perincian operasi pengadun dan penterjemah dibincangkan dalam bahagian 5.

Semua medan paket RTP/RTCP dihantar melalui rangkaian dalam bait (oktet); bait yang paling ketara dihantar dahulu. Semua data medan pengepala dijajarkan mengikut panjangnya . Oktet yang ditetapkan sebagai pilihan mempunyai nilai sifar.

Masa mutlak (Wallclock time) dalam RTP diwakili menggunakan format cap waktu Network Time Protocol (NTP), yang merupakan rujukan masa dalam saat berbanding sifar jam pada 1 Januari 1900. Format penuh cap waktu NTP ialah nombor titik tetap 64-bit yang tidak ditandatangani dengan bahagian integer dalam 32 bit pertama dan bahagian pecahan dalam 32 bit terakhir. Sesetengah medan dengan perwakilan yang lebih padat hanya menggunakan 32 bit tengah - 16 bit yang lebih rendah daripada bahagian integer dan 16 bit yang paling ketara bagi bahagian pecahan.

Dua bahagian seterusnya artikel ini (3 dan 4) membincangkan format paket dan ciri pengendalian protokol RTP dan RTCP, masing-masing.

Seperti yang dinyatakan di atas, paket RTP termasuk pengepala tetap, sambungan pengepala panjang pembolehubah pilihan dan medan data. Pengepala tetap paket protokol RTP mempunyai format berikut: .

Dua belas oktet pertama terdapat dalam setiap paket RTP, manakala medan CSRC (sumber penyumbang) hadir hanya apabila dimasukkan oleh pengadun. Medan mempunyai tujuan berikut.

Versi (V): 2 bit. Medan ini mengenal pasti versi RTP. Artikel ini merangkumi versi 2 protokol RTP (nilai 1 telah digunakan dalam draf pertama RTP).

Padding (P): 1 bit. Jika bit padding ditetapkan kepada satu, maka paket pada penghujungnya mengandungi satu atau lebih oktet padding yang bukan sebahagian daripada trafik. Oktet terakhir pelapik mengandungi petunjuk bilangan oktet sedemikian yang kemudiannya harus diabaikan. Padding mungkin diperlukan oleh sesetengah algoritma penyulitan dengan saiz blok tetap atau untuk membawa berbilang paket RTP dalam satu blok data protokol asas.

Sambungan (X): 1 bit. Jika bit sambungan ditetapkan, maka pengepala tetap diikuti oleh sambungan pengepala dengan format yang ditakrifkan dalam .

CSRC Counter (CC): 4 bit. Kaunter CSRC mengandungi bilangan pengecam sumber CSRC yang disertakan (lihat senarai singkatan dan istilah yang digunakan) yang mengikuti pengepala tetap.

Penanda (M): 1 bit. Tafsiran penanda ditentukan oleh profil. Ia bertujuan untuk membenarkan peristiwa penting (seperti sempadan bingkai video) ditanda dalam aliran paket. Profil boleh memperkenalkan bit penanda tambahan atau menentukan bahawa tiada bit penanda hadir dengan menukar bilangan bit dalam medan jenis trafik (lihat ).

Jenis trafik (PT): 7 bit. Medan ini mengenal pasti format trafik RTP dan menentukan cara aplikasi mentafsirnya. Profil mentakrifkan pemetaan statik lalai antara nilai PT dan format trafik. Kod jenis trafik tambahan boleh ditakrifkan secara dinamik melalui cara bukan RTP. Pengirim paket RTP menghasilkan satu nilai jenis trafik RTP pada bila-bila masa; Medan ini tidak bertujuan untuk memultiplekskan aliran media individu (lihat ).

Nombor urutan: 16 bit. Nilai nombor jujukan meningkat satu dengan setiap paket maklumat RTP dihantar dan boleh digunakan oleh penerima untuk mengesan kehilangan paket dan memulihkan urutan asalnya. Nilai awal nombor jujukan dipilih secara rawak untuk menyukarkan untuk memecahkan kunci berdasarkan nilai yang diketahui medan ini (walaupun penyulitan tidak digunakan oleh sumber, kerana paket mungkin melalui penterjemah yang menggunakan penyulitan) . Cap masa: 32 bit. Cap masa mencerminkan titik pensampelan untuk oktet pertama dalam paket maklumat RTP. Titik pensampelan mesti diperoleh daripada pemasa yang meningkatkan nilainya secara monoton dan linear dalam masa untuk menyediakan penyegerakan dan mengesan jitter (lihat bahagian 4.3.1). Resolusi pemasa mestilah mencukupi untuk ketepatan pemasaan yang diingini dan ukuran jitter ketibaan paket (laporan satu pemasa bagi setiap bingkai video biasanya tidak mencukupi). Kekerapan masa bergantung pada format trafik yang dihantar dan ditetapkan secara statik dalam profil atau spesifikasi format trafik, atau boleh ditetapkan secara dinamik untuk format trafik yang ditakrifkan melalui "cara bukan RTP". Jika paket RTP dijana secara berkala, masa pensampelan nominal yang ditentukan oleh pemasa pensampelan mesti digunakan, bukannya nilai pemasa sistem. Sebagai contoh, untuk isyarat audio kadar tetap, penderia cap masa adalah wajar ditambah satu untuk setiap tempoh pensampelan. Jika aplikasi audio daripada peranti input membaca blok yang mengandungi 160 sampel, maka cap masa mesti ditambah sebanyak 160 untuk setiap blok tersebut, tidak kira sama ada blok itu dihantar dalam paket atau set semula sebagai jeda. Nilai awal cap masa, seperti nilai awal nombor jujukan, ialah pembolehubah rawak. Berbilang paket RTP berturut-turut mungkin mempunyai cap masa yang sama jika ia dijana secara logik pada masa yang sama, contohnya jika ia tergolong dalam bingkai video yang sama. Paket RTP berturut-turut mungkin mengandungi cap waktu bukan monotonik jika data tidak dihantar dalam susunan pensampelan, seperti halnya dengan bingkai video MPEG yang diinterpolasi (bagaimanapun, nombor jujukan paket masih akan menjadi monoton apabila dihantar).

SSRC: 32 bit. Medan SSRC (sumber penyegerakan) mengenal pasti sumber penyegerakan (lihat senarai singkatan dan istilah yang digunakan). Pengecam ini dipilih secara rawak supaya tiada dua sumber penyegerakan dalam sesi RTP yang sama mempunyai pengecam SSRC yang sama. Walaupun kemungkinan berbilang sumber memilih pengecam yang sama adalah rendah, semua pelaksanaan RTP mesti bersedia untuk mengesan dan menyelesaikan perlanggaran tersebut. Bahagian 6 membincangkan kebarangkalian perlanggaran bersama-sama dengan mekanisme untuk menyelesaikannya dan mengesan gelung lapisan RTP berdasarkan keunikan pengecam SSRC. Jika sumber menukar alamat pengangkutan sumbernya, ia juga mesti memilih pengecam SSRC baharu untuk mengelak daripada ditafsirkan sebagai sumber gelung balik.

Senarai CSRC: 0 hingga 15 item, 32 bit setiap satu. Senarai CSRC (sumber penyumbang) mengenal pasti sumber trafik yang disertakan yang terkandung dalam paket. Bilangan pengecam ditentukan oleh medan CC. Jika terdapat lebih daripada lima belas sumber yang disertakan, maka hanya 15 daripadanya boleh dikenal pasti. ID CSRC dimasukkan oleh pengadun apabila menggunakan ID SSRC untuk sumber ditukar. Sebagai contoh, untuk paket audio, ID SSRC semua sumber yang dicampur semasa paket dibuat disenaraikan dalam senarai CSRC, memberikan petunjuk yang betul tentang sumber mesej kepada penerima.

Seperti yang dinyatakan di atas, mengikut protokol RTP, jenis trafik yang berbeza mesti dihantar secara berasingan, dalam sesi komunikasi RTP yang berbeza. Sesi ditakrifkan oleh sepasang alamat pengangkutan destinasi tertentu (satu alamat rangkaian ditambah sepasang port untuk RTP dan RTCP). Contohnya, dalam telesidang yang terdiri daripada audio dan video yang dikodkan secara berasingan, setiap jenis trafik mesti dihantar dalam sesi RTP berasingan dengan alamat pengangkutan destinasinya sendiri. Ia tidak bertujuan bahawa audio dan video akan dihantar dalam sesi RTP yang sama dan dipisahkan berdasarkan jenis trafik atau medan SSRC. Interleaving paket yang mempunyai jenis trafik yang berbeza tetapi menggunakan SSRC yang sama akan menyebabkan beberapa masalah:

Jika salah satu jenis trafik berubah semasa sesi, tidak akan ada cara umum untuk menentukan nilai lama yang mana telah digantikan dengan yang baharu.
SSRC mengenal pasti nilai selang masa tunggal dan ruang nombor urutan. Menyilang berbilang jenis trafik memerlukan selang penyegerakan yang berbeza jika kadar jam aliran berbeza adalah berbeza, dan ruang nombor jujukan yang berbeza untuk menunjukkan jenis trafik yang berkaitan dengan kehilangan paket.
Mesej penghantar dan penerima RTCP (lihat Bahagian 4.3) menerangkan hanya satu nilai selang masa dan ruang nombor urutan untuk SSRC dan tidak membawa medan jenis trafik.
Pengadun RTP tidak mampu menggabungkan strim bersilang pelbagai jenis trafik ke dalam satu aliran.
Faktor berikut menghalang penghantaran berbilang jenis trafik dalam satu sesi RTP: penggunaan laluan rangkaian yang berbeza atau peruntukan sumber rangkaian; menerima subset data multimedia apabila diperlukan, sebagai contoh, hanya audio jika isyarat video melebihi lebar jalur yang tersedia; pelaksanaan pendengar yang menggunakan proses berasingan untuk jenis trafik yang berbeza, manakala penggunaan sesi RTP berasingan membolehkan pelaksanaan tunggal dan berbilang proses.

Dengan menggunakan SSRC yang berbeza untuk setiap jenis trafik, tetapi menghantarnya dalam sesi RTP yang sama, anda boleh mengelakkan tiga masalah pertama, tetapi anda tidak boleh mengelakkan dua yang terakhir. Oleh itu, spesifikasi protokol RTP memerlukan setiap jenis trafik menggunakan sesi RTPnya sendiri.

Pengepala paket maklumat RTP sedia ada lengkap untuk set fungsi yang diperlukan secara umum untuk semua kelas aplikasi yang boleh menyokong RTP. Walau bagaimanapun, untuk lebih sesuai dengan tujuan tertentu, pengepala boleh diubah suai melalui pengubahsuaian atau penambahan yang ditakrifkan dalam spesifikasi profil.

Bit penanda dan medan jenis trafik membawa maklumat khusus profil, tetapi ia terletak dalam pengepala tetap memandangkan banyak aplikasi dijangka memerlukannya. Oktet yang mengandungi medan ini boleh ditakrifkan semula oleh profil untuk memenuhi keperluan yang berbeza, contohnya dengan lebih atau kurang bit penanda. Jika terdapat sebarang bit penanda, ia harus diletakkan dalam bit yang paling penting bagi oktet, kerana monitor bebas profil mungkin dapat melihat korelasi antara corak kehilangan paket dan bit penanda.

Maklumat tambahan yang diperlukan untuk format trafik tertentu (contohnya, jenis pengekodan video) mesti dibawa dalam medan data paket. Ia boleh diletakkan di lokasi tertentu pada permulaan atau di dalam tatasusunan data.

Jika kelas aplikasi tertentu memerlukan kefungsian tambahan yang bebas daripada format trafik, maka profil yang digunakan oleh aplikasi tersebut mesti menentukan medan tetap tambahan yang terletak sejurus selepas medan SSRC pengepala tetap sedia ada. Aplikasi ini akan dapat mengakses medan tambahan secara langsung dengan pantas, manakala pemantau atau pembalak bebas profil masih boleh memproses paket RTP dengan hanya mentafsir dua belas oktet pertama.

Jika dianggap bahawa fungsi tambahan diperlukan secara umum merentas semua profil, maka versi RTP baharu mesti ditakrifkan untuk membuat perubahan kekal pada pengepala tetap.

Pengecam Sumber Penyegerakan (SSRC).

Pengecam Sumber Penyumbang (CSRC).

Untuk membenarkan pelaksanaan individu bereksperimen dengan fungsi bebas format baharu yang memerlukan maklumat tambahan untuk dibawa dalam pengepala paket data, RTP menyediakan mekanisme sambungan pengepala paket. Mekanisme ini direka bentuk supaya sambungan pengepala boleh diabaikan oleh aplikasi berkomunikasi lain yang tidak memerlukannya.

Jika bit X dalam pengepala RTP ditetapkan kepada satu, maka sambungan pengepala panjang berubah-ubah dilampirkan pada pengepala RTP tetap (mengikut senarai CSRC, jika ada). Ambil perhatian bahawa sambungan pengepala ini adalah untuk kegunaan terhad sahaja. Sambungan pengepala paket RTP mempunyai format berikut:

Sambungan mengandungi medan panjang 16-bit yang menunjukkan bilangan perkataan 32-bit di dalamnya, tidak termasuk pengepala sambungan empat oktet (oleh itu panjangnya boleh menjadi sifar). Hanya satu sambungan boleh ditambah pada pengepala paket maklumat RTP tetap. Untuk membenarkan setiap daripada berbilang pelaksanaan saling kendali bereksperimen secara bebas dengan sambungan pengepala yang berbeza, atau untuk membenarkan pelaksanaan tertentu bereksperimen dengan lebih daripada satu jenis sambungan pengepala, penggunaan 16 bit pertama sambungan itu tidak ditentukan, dikhaskan untuk membezakan pengecam atau parameter. Format 16 bit ini mesti ditentukan oleh spesifikasi profil yang mana aplikasi beroperasi.