Bahan artikel diambil dari saya .
Struktur paket RTP
Pada masa lalu kita gunakan TShark melakukan penangkapan paket RTP yang ditukar antara penerima dan pemancar kami. Nah, dalam satu ini kita akan melukis unsur-unsur pakej dalam warna yang berbeza dan bercakap tentang tujuan mereka.
Mari kita lihat pada pakej yang sama, tetapi dengan margin berwarna dan label penjelasan:
Di bahagian bawah penyenaraian, bait yang membentuk paket RTP diwarnakan, dan ini pula ialah muatan paket UDP (tajuknya dibulatkan dengan warna hitam). Latar belakang berwarna menunjukkan bait pengepala RTP dan blok data yang mengandungi muatan paket RTP diserlahkan dalam warna hijau. Data dibentangkan dalam format heksadesimal. Dalam kes kami, ini adalah isyarat audio yang dimampatkan mengikut u-law (mu-law), i.e. satu sampel mempunyai saiz 1 bait. Memandangkan kami menggunakan kadar pensampelan lalai (8000 Hz), pada kadar paket 50 Hz, setiap paket RTP harus mengandungi 160 bait muatan. Kita akan melihat ini dengan mengira bait di kawasan hijau, sepatutnya terdapat 10 baris daripadanya.
Menurut standard, jumlah data dalam muatan mestilah gandaan empat, atau dengan kata lain, ia mesti mengandungi nombor integer perkataan empat bait. Jika berlaku muatan anda tidak sepadan dengan peraturan ini, maka anda perlu menambah bait bernilai sifar pada penghujung muatan dan tetapkan bit Padding. Bit ini terletak dalam bait pertama pengepala RTP dan berwarna biru. Ambil perhatian bahawa semua bait muatan ialah 0xFF, iaitu rupa senyap u-law.
Pengepala paket RTP terdiri daripada 12 bait mandatori, tetapi dalam dua kes ia boleh lebih panjang:
-
Apabila paket membawa isyarat audio yang diperoleh dengan mencampurkan isyarat daripada beberapa sumber (strim RTP), maka selepas 12 bait pertama pengepala terdapat jadual dengan senarai pengecam sumber yang muatannya digunakan untuk mencipta muatan paket ini. Dalam kes ini, dalam empat bit bawah bait pertama pengepala (medan Kiraan pengecam sumber menyumbang) menunjukkan bilangan sumber. Saiz medan ialah 4 bit, jadi jadual boleh mengandungi sehingga 15 pengecam sumber. Setiap satunya menduduki 4 bait. Jadual ini digunakan semasa menyediakan panggilan persidangan.
-
Apabila tajuk mempunyai sambungan . Dalam kes ini, bit ditetapkan dalam bait pertama pengepala X. Dalam pengepala lanjutan, selepas jadual peserta (jika ada), terdapat pengepala sambungan satu perkataan, diikuti dengan perkataan sambungan. Sambungan ialah koleksi bait yang boleh anda gunakan untuk memindahkan data tambahan. Piawaian tidak menyatakan format data ini - ia boleh menjadi apa sahaja. Sebagai contoh, ia mungkin beberapa tetapan tambahan untuk peranti yang menerima paket RTP. Walau bagaimanapun, bagi sesetengah aplikasi, piawaian pengepala lanjutan telah dibangunkan. Ini dilakukan, sebagai contoh, untuk komunikasi dalam standard ED-137 (Standard Kebolehoperasian untuk Komponen ATM VoIP).
Sekarang mari kita lihat medan pengepala dengan lebih terperinci. Di bawah adalah gambar kanonik dengan struktur pengepala RTP, yang saya juga tidak dapat menolak dan dicat dalam warna yang sama.
VER β nombor versi protokol (versi semasa 2);
P - bendera yang ditetapkan dalam kes di mana paket RTP ditambah dengan bait kosong pada penghujungnya;
X - bendera bahawa pengepala dilanjutkan;
CC β mengandungi bilangan pengecam CSRC mengikut pengepala malar (selepas perkataan 1..3), jadual tidak ditunjukkan dalam rajah;
M β penanda permulaan bingkai atau kehadiran pertuturan dalam saluran (jika pengesan jeda pertuturan digunakan). Jika penerima tidak mengandungi pengesan jeda pertuturan, maka bit ini hendaklah ditetapkan secara kekal;
PTYPE - menentukan format muatan;
Nombor urutan - nombor paket, digunakan untuk memulihkan susunan paket dimainkan, kerana keadaan sebenar adalah apabila paket boleh sampai ke penerima dalam susunan yang salah di mana ia dihantar. Nilai awal mestilah rawak, ini dilakukan supaya jika aliran RTP disulitkan, sukar untuk menggodamnya. Juga, medan ini membolehkan anda mengesan paket yang terlepas;
Timestamp - cap masa. Masa diukur dalam sampel isyarat, i.e. jika letusan mengandungi 160 sampel, maka cap masa letusan seterusnya ialah 160 lagi. Nilai awal cap masa mestilah rawak;
SSRC β pengecam sumber pakej, ia mestilah unik. Adalah lebih baik untuk menjananya secara rawak sebelum memulakan aliran RTP.
Jika anda membangunkan pemancar atau penerima RTP anda sendiri, anda perlu menyemak paket anda lebih daripada sekali untuk meningkatkan produktiviti, saya syorkan anda belajar cara menggunakan penapisan paket dalam TShark, ia membolehkan anda menangkap hanya paket yang minat kepada anda. Dalam persekitaran di mana berpuluh-puluh peranti RTP beroperasi pada rangkaian, ini sangat berharga. Dalam baris arahan TShark, pilihan penapisan ditentukan dengan pilihan "-f". Kami menggunakan pilihan ini apabila kami ingin menangkap paket dari port 8010:
-f "udp port 8010"
Parameter penapisan pada asasnya adalah satu set kriteria yang mesti dipenuhi oleh paket "tangkap". Keadaan ini boleh menyemak alamat, port, nilai bait tertentu dalam paket. Keadaan boleh digabungkan dengan operasi logik "DAN", "ATAU", dsb. Alat yang sangat berkuasa.
Jika anda ingin melihat dinamik perubahan medan dalam kelompok, anda perlu menduplikasi output TShark ke fail, seperti yang ditunjukkan dalam artikel terakhir, dengan menghantar output TShark di pintu masuk tee. Seterusnya, buka fail log dengan kurang, vim atau alat lain yang boleh berfungsi dengan cepat dengan fail teks yang besar dan mencari rentetan, anda boleh mengetahui semua nuansa kelakuan medan paket dalam aliran RTP.
Jika anda perlu mendengar isyarat yang dihantar oleh aliran RTP, maka anda perlu menggunakan versi tersebut TShark dengan antara muka visual Wireshark. Dengan manipulasi tetikus mudah, anda boleh mendengar dan melihat bentuk gelombang isyarat. Tetapi dengan satu syarat - jika ia dikodkan dalam format u-law atau a-low.
Seterusnya kami akan membuat interkom dupleks dengan anda. Bekalkan sepasang set kepala dan seorang teman bicara.
Sumber: www.habr.com