ການສຳຫຼວດເຄື່ອງຈັກ Mediastreamer2 VoIP. ພາກທີ 8

ເອກະສານຂອງບົດຄວາມແມ່ນເອົາມາຈາກຂອງຂ້ອຍ ຊ່ອງ zen.

ໂຄງສ້າງແພັກເກັດ RTP

ໃນທີ່ສຸດ ບົດຄວາມ ພວກເຮົາກໍາລັງໃຊ້ TShark packets RTP ທີ່ຈັບໄດ້ແລກປ່ຽນລະຫວ່າງຕົວຮັບແລະເຄື່ອງສົ່ງຂອງພວກເຮົາ. ດີ, ໃນຫນຶ່ງນີ້ພວກເຮົາຈະທາສີອົງປະກອບຂອງຊຸດໃນສີທີ່ແຕກຕ່າງກັນແລະສົນທະນາກ່ຽວກັບຈຸດປະສົງຂອງເຂົາເຈົ້າ.

ລອງເບິ່ງຊຸດດຽວກັນ, ແຕ່ມີທົ່ງນາທີ່ມີສີແລະບັນທຶກຄໍາອະທິບາຍ:

ຢູ່ດ້ານລຸ່ມຂອງລາຍຊື່ແມ່ນ bytes ທີ່ປະກອບເປັນແພັກເກັດ RTP, ເຊິ່ງໃນນັ້ນແມ່ນ payload ຂອງແພັກເກັດ UDP (ສ່ວນຫົວຂອງມັນຖືກລະບຸໄວ້ໃນສີດໍາ). ພື້ນຫຼັງສີຊີ້ໃຫ້ເຫັນເຖິງໄບຕ໌ຫົວ RTP, ແລະສີຂຽວສະແດງເຖິງບລັອກຂໍ້ມູນທີ່ມີ payload ຂອງແພັກເກັດ RTP. ຂໍ້ມູນມີຢູ່ໃນຮູບແບບເລກຖານສິບຫົກ. ໃນກໍລະນີຂອງພວກເຮົາ, ນີ້ແມ່ນສັນຍານສຽງທີ່ຖືກບີບອັດຕາມກົດຫມາຍ u-law (mu-law), i.e. ຕົວຢ່າງຫນຶ່ງແມ່ນ 1 byte ໃນຂະຫນາດ. ເນື່ອງຈາກພວກເຮົາໃຊ້ອັດຕາການເກັບຕົວຢ່າງເລີ່ມຕົ້ນ (8000 Hz), ໃນອັດຕາແພັກເກັດ 50 Hz, ແຕ່ລະແພັກເກັດ RTP ຄວນມີ 160 ໄບຕ໌ຂອງ payload. ພວກເຮົາຈະເຫັນນີ້ໂດຍການນັບ bytes ໃນພື້ນທີ່ສີຂຽວ, ຄວນມີ 10 ເສັ້ນ.

ອີງຕາມມາດຕະຖານ, ຈໍານວນຂໍ້ມູນໃນ payload ຈະຕ້ອງເປັນຕົວຄູນຂອງສີ່, ຫຼືໃນຄໍາສັບຕ່າງໆອື່ນໆຕ້ອງມີຈໍານວນເຕັມຂອງຄໍາສັບສີ່ໄບ. ຖ້າມັນເກີດຂື້ນວ່າ payload ຂອງເຈົ້າບໍ່ປະຕິບັດຕາມກົດລະບຽບນີ້, ຫຼັງຈາກນັ້ນທ່ານຈໍາເປັນຕ້ອງເພີ່ມ bytes ທີ່ມີຄ່າສູນໃສ່ໃນຕອນທ້າຍຂອງ payload ແລະກໍານົດ Padding bit. ບິດນີ້ແມ່ນຢູ່ໃນ byte ທໍາອິດຂອງ RTP header ແລະເປັນ turquoise ສີ. ໃຫ້ສັງເກດວ່າ payload bytes ທັງຫມົດມີມູນຄ່າ 0xFF - ນີ້ແມ່ນສິ່ງທີ່ silence ຄ້າຍຄືໃນຮູບແບບ u-law.

ສ່ວນຫົວຂອງແພັກເກັດ RTP ປະກອບດ້ວຍ 12 ໄບຕ໌ທີ່ຕ້ອງການ, ແຕ່ໃນສອງກໍລະນີມັນສາມາດດົນກວ່ານີ້:

• ເມື່ອແພັກເກັດປະຕິບັດສັນຍານສຽງທີ່ໄດ້ຮັບໂດຍການປະສົມສັນຍານຈາກຫຼາຍແຫຼ່ງ (RTP streams), ຫຼັງຈາກນັ້ນຫຼັງຈາກ 12 bytes ທໍາອິດຂອງ header ມີຕາຕະລາງທີ່ມີບັນຊີລາຍຊື່ຂອງຕົວລະບຸແຫຼ່ງທີ່ payloads ຖືກນໍາໃຊ້ເພື່ອສ້າງ payload ຂອງແພັກເກັດນີ້. ໃນກໍລະນີນີ້, ໃນສີ່ບິດຕ່ໍາຂອງ byte ທໍາອິດຂອງ header (ພາກສະຫນາມ ການປະກອບສ່ວນຂອງຕົວລະບຸແຫຼ່ງທີ່ມາ) ຈໍານວນຂອງແຫຼ່ງຂໍ້ມູນແມ່ນຊີ້ໃຫ້ເຫັນ. ຂະໜາດຊ່ອງຂໍ້ມູນແມ່ນ 4 ບິດ, ດັ່ງນັ້ນຕາຕະລາງສາມາດບັນຈຸໄດ້ເຖິງ 15 ຕົວລະບຸແຫຼ່ງ. ແຕ່ລະຄົນໃຊ້ເວລາ 4 bytes. ຕາຕະລາງນີ້ຖືກນໍາໃຊ້ໃນເວລາຈັດກອງປະຊຸມ.

• ເມື່ອຫົວຂໍ້ມີການຂະຫຍາຍ. ໃນກໍລະນີນີ້, bit ໃນ byte ທໍາອິດຂອງ header ຖືກກໍານົດ X. ໃນສ່ວນຫົວຂະຫຍາຍ, ຫຼັງຈາກຕາຕະລາງຂອງຜູ້ເຂົ້າຮ່ວມ (ຖ້າມີ), ມີສ່ວນຫົວການຂະຫຍາຍຫນຶ່ງຄໍາ, ຕິດຕາມດ້ວຍຄໍາສັບຂອງສ່ວນຂະຫຍາຍ. ສ່ວນຂະຫຍາຍແມ່ນຊຸດຂອງ bytes ທີ່ທ່ານສາມາດນໍາໃຊ້ເພື່ອໂອນຂໍ້ມູນເພີ່ມເຕີມ. ມາດຕະຖານບໍ່ໄດ້ລະບຸຮູບແບບຂອງຂໍ້ມູນນີ້ - ມັນສາມາດເປັນອັນໃດກໍ່ໄດ້. ຕົວຢ່າງ, ເຫຼົ່ານີ້ອາດຈະເປັນບາງການຕັ້ງຄ່າເພີ່ມເຕີມສໍາລັບອຸປະກອນທີ່ໄດ້ຮັບແພັກເກັດ RTP. ຢ່າງໃດກໍຕາມ, ສໍາລັບບາງຄໍາຮ້ອງສະຫມັກ, ມາດຕະຖານ header ຂະຫຍາຍໄດ້ຖືກພັດທະນາ. ນີ້ແມ່ນເຮັດ, ສໍາລັບການຍົກຕົວຢ່າງ, ສໍາລັບອຸປະກອນການສື່ສານໃນມາດຕະຖານ ED-137 (ມາດຕະຖານການເຮັດວຽກຮ່ວມກັນສຳລັບອົງປະກອບເຄື່ອງ ATM VoIP).

ຕອນນີ້ໃຫ້ເຮົາມາເບິ່ງຊ່ອງ header ໃນລາຍລະອຽດເພີ່ມເຕີມ. ຂ້າງລຸ່ມນີ້ແມ່ນຮູບ canonical ທີ່ມີໂຄງສ້າງຂອງຫົວ RTP, ເຊິ່ງຂ້ອຍກໍ່ບໍ່ສາມາດຕ້ານທານແລະທາສີໃນສີດຽວກັນ.

VER — ເລກ​ສະ​ບັບ​ໂປຣ​ໂຕ​ຄໍ (ສະ​ບັບ​ປະ​ຈຸ​ບັນ 2);

P — ທຸງທີ່ຕັ້ງໄວ້ໃນກໍລະນີທີ່ແພັກເກັດ RTP ຖືກເສີມດ້ວຍໄບຕ໌ຫວ່າງຢູ່ທ້າຍ;

X - ທຸງວ່າສ່ວນຫົວຖືກຂະຫຍາຍອອກ;

CC — ປະ​ກອບ​ດ້ວຍ​ຈໍາ​ນວນ​ຂອງ​ຕົວ​ລະ​ບຸ CSRC ຕໍ່​ໄປ​ນີ້​ສ່ວນ​ຫົວ​ຄົງ​ທີ່ (ຫຼັງ​ຈາກ​ຄໍາ​ສັບ​ຕ່າງໆ 1..3​)​, ຕາ​ຕະ​ລາງ​ບໍ່​ໄດ້​ສະ​ແດງ​ໃຫ້​ເຫັນ​ໃນ​ຮູບ​ພາບ​;

M — ເຄື່ອງ​ຫມາຍ​ການ​ເລີ່ມ​ຕົ້ນ​ຂອງ​ພາ​ຫຼື​ການ​ມີ​ສຽງ​ເວົ້າ​ຢູ່​ໃນ​ຊ່ອງ​ທາງ (ຖ້າ​ຫາກ​ວ່າ​ເຄື່ອງ​ກວດ​ສອບ​ການ​ຢຸດ​ການ​ປາກ​ເວົ້າ​ແມ່ນ​ຖືກ​ນໍາ​ໃຊ້​)​. ຖ້າຕົວຮັບບໍ່ມີເຄື່ອງກວດຈັບສຽງເວົ້າຊົ່ວຄາວ, ຫຼັງຈາກນັ້ນບິດນີ້ຕ້ອງຖືກຕັ້ງຖາວອນ;

PTYPE — ຊີ້ບອກຮູບແບບ payload;

ເລກ ລຳ ດັບ — ໝາຍເລກແພັກເກັດ, ໃຊ້ເພື່ອຟື້ນຟູລຳດັບການຫຼິ້ນແພັກເກັດ, ເນື່ອງຈາກສະຖານະການຕົວຈິງແມ່ນເວລາທີ່ແພັກເກັດສາມາດເຂົ້າຫາຜູ້ຮັບໄດ້ຕາມລຳດັບທີ່ແຕກຕ່າງຈາກທີ່ພວກມັນຖືກສົ່ງໄປ. ຄ່າເບື້ອງຕົ້ນຈະຕ້ອງເປັນແບບສຸ່ມ; ອັນນີ້ແມ່ນເຮັດເພື່ອວ່າຖ້າໃຊ້ການເຂົ້າລະຫັດສະຕຣີມ RTP, ມັນຈະຍາກທີ່ຈະແຕກ. ພາກສະຫນາມນີ້ຍັງຊ່ວຍໃຫ້ທ່ານສາມາດກວດພົບການຫຼຸດລົງຂອງຊອງ;

Timestamp — ສະ​ແຕມ​ທີ່​ໃຊ້​ເວ​ລາ​. ເວລາຖືກວັດແທກໃນຕົວຢ່າງສັນຍານ, i.e. ຖ້າແພັກເກັດມີ 160 ຕົວຢ່າງ, ເວລາຂອງແພັກເກັດຕໍ່ໄປຈະໃຫຍ່ກວ່າ 160. ຄ່າເບື້ອງຕົ້ນຂອງການສະແຕມເວລາຕ້ອງເປັນແບບສຸ່ມ;

SSRC — ຕົວລະບຸແຫຼ່ງຊຸດ, ມັນຕ້ອງເປັນເອກະລັກ. ມັນດີກວ່າທີ່ຈະສ້າງມັນແບບສຸ່ມກ່ອນທີ່ຈະເລີ່ມການຖ່າຍທອດ RTP.

ຖ້າທ່ານພັດທະນາຕົວສົ່ງຫຼືຕົວຮັບຂອງແພັກເກັດ RTP ຂອງທ່ານເອງ, ທ່ານຈະຕ້ອງເບິ່ງແພັກເກັດຂອງເຈົ້າຫຼາຍກວ່າຫນຶ່ງຄັ້ງ, ດັ່ງນັ້ນເພື່ອເພີ່ມຜົນຜະລິດ, ຂ້ອຍແນະນໍາໃຫ້ເຈົ້າໃຊ້ການກັ່ນຕອງແພັກເກັດໃນ TShark, ມັນຊ່ວຍໃຫ້ທ່ານສາມາດເກັບເອົາແພັກເກັດເຫຼົ່ານັ້ນເທົ່ານັ້ນ. ທີ່ມີຄວາມສົນໃຈກັບທ່ານ. ໃນເງື່ອນໄຂທີ່ອຸປະກອນ RTP ຫລາຍສິບປະຕິບັດງານຢູ່ໃນເຄືອຂ່າຍ, ນີ້ແມ່ນມີຄຸນຄ່າຫຼາຍ. ໃນແຖວຄໍາສັ່ງ TShark, ຕົວກໍານົດການກັ່ນຕອງແມ່ນຖືກກໍານົດດ້ວຍທາງເລືອກ "-f". ພວກເຮົາໃຊ້ຕົວເລືອກນີ້ເມື່ອພວກເຮົາຕ້ອງການຈັບແພັກເກັດຈາກພອດ 8010:
-f "udp port 8010"
ຕົວກໍານົດການການກັ່ນຕອງເປັນສິ່ງຈໍາເປັນທີ່ກໍານົດໄວ້ຂອງເງື່ອນໄຂທີ່ຊຸດ "ຈັບໄດ້" ຕ້ອງຕອບສະຫນອງ. ເງື່ອນໄຂສາມາດກວດສອບທີ່ຢູ່, ພອດ, ຫຼືມູນຄ່າຂອງ byte ສະເພາະໃນແພັກເກັດ. ເງື່ອນໄຂສາມາດຖືກລວມເຂົ້າກັນໂດຍໃຊ້ການດໍາເນີນການຢ່າງມີເຫດຜົນ "AND", "OR", ແລະອື່ນໆ. ເຄື່ອງມືທີ່ມີປະສິດທິພາບຫຼາຍ.

ຖ້າທ່ານຕ້ອງການເບິ່ງນະໂຍບາຍດ້ານຂອງການປ່ຽນແປງພາກສະຫນາມໃນ batches, ທ່ານຈະຕ້ອງເຮັດຊ້ໍາຜົນຜະລິດ TShark ກັບໄຟລ໌, ດັ່ງທີ່ໄດ້ສະແດງຢູ່ໃນບົດຄວາມທີ່ຜ່ານມາ, ການນໍາໃຊ້ການໂອນຜົນຜະລິດ TShark ຢູ່ທາງເຂົ້າ tee. ຕໍ່ໄປ, ເປີດໄຟລ໌ບັນທຶກໂດຍໃຊ້ ຫນ້ອຍ, vim ຫຼືເຄື່ອງມືອື່ນທີ່ສາມາດເຮັດວຽກໄດ້ໄວກັບໄຟລ໌ຂໍ້ຄວາມຂະຫນາດໃຫຍ່ແລະຊອກຫາສາຍ, ທ່ານສາມາດຊອກຫາ nuances ທັງຫມົດຂອງພຶດຕິກໍາຂອງ packet fields ໃນ RTP stream.

ຖ້າທ່ານຕ້ອງການຟັງສັນຍານທີ່ຖ່າຍທອດໂດຍກະແສ RTP, ຫຼັງຈາກນັ້ນທ່ານຈໍາເປັນຕ້ອງໃຊ້ສະບັບ TShark ມີການໂຕ້ຕອບສາຍຕາ Wireshark. ໂດຍການຫມູນໃຊ້ທີ່ງ່າຍດາຍດ້ວຍຫນູ, ທ່ານສາມາດຟັງແລະເບິ່ງ oscillogram ສັນຍານ. ແຕ່ໃນເງື່ອນໄຂຫນຶ່ງ - ຖ້າມັນຖືກເຂົ້າລະຫັດໃນຮູບແບບ u-law ຫຼື a-low.

ຕໍ່ໄປ ບົດຄວາມ ພວກເຮົາຈະສ້າງສອງ intercom ກັບທ່ານ. ຫຼັກຊັບໃສ່ຊຸດຫູຟັງສອງສາມຊຸດແລະຕົວໂຕ້ຕອບຫນຶ່ງ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com