ເສັ້ນທາງສື່ສຳລັບການໂທດ້ວຍວິດີໂອ
ພາບລວມຂອງເສັ້ນທາງເຄືອຂ່າຍສື່ທີ່ໃຊ້ໂດຍ Video Call - ສໍາລັບພະນັກງານໄອທີ
ທີ່ຢູ່ເຊີບເວີ Relay ໂທວິດີໂອ: vcct.healthdirect.org.au
ບັນລຸການເຊື່ອມຕໍ່ທີ່ມີຄຸນນະພາບດີທີ່ສຸດ
1. ສໍາລັບເສັ້ນທາງເຄືອຂ່າຍສ່ວນໃຫຍ່, ການເຈລະຈາອາດຈະເຮັດໃຫ້ການເຊື່ອມຕໍ່ສື່ທີ່ຖືກຕ້ອງ.
- ໂດຍກົງ peer-to-peer ຜ່ານ UDP ສະຫນອງການເຊື່ອມຕໍ່ທີ່ດີທີ່ສຸດ , ແຕ່ມັກຈະບໍ່ສາມາດໃຊ້ໄດ້ໃນທົ່ວເຄືອຂ່າຍສະຖາບັນ, ເນື່ອງຈາກຂໍ້ຈໍາກັດດ້ານຄວາມປອດໄພຂອງນະໂຍບາຍເຄືອຂ່າຍຂອງພວກເຂົາ.
- ການເຊື່ອມຕໍ່ TCP tunnelled ທີ່ປອດໄພແມ່ນທາງເລືອກທີ່ຄວາມປາຖະຫນາຫນ້ອຍທີ່ສຸດ ສໍາລັບການໂອນມີເດຍ, ແຕ່ສ່ວນຫຼາຍອາດຈະໄດ້ຮັບການສະຫນັບສະຫນູນໂດຍບໍ່ມີການປ່ຽນແປງຄວາມປອດໄພເຄືອຂ່າຍ.
ທາງເລືອກທີ່ແນະນໍາ: ສໍາລັບເຄືອຂ່າຍຈໍານວນຫຼາຍ, ການປ່ອຍໃຫ້ NAT egress ກັບ UDP port 3478 ກ່ຽວກັບເຄື່ອງແມ່ຂ່າຍ relay (ເສັ້ນທາງເຄືອຂ່າຍ 2, ຂ້າງເທິງ) ຈະໃຫ້ການ latency ຕ່ໍາທີ່ມີພຽງເລັກນ້ອຍ. ອັນນີ້ຄວນຮຽກຮ້ອງໃຫ້ມີການປ່ຽນແປງເລັກນ້ອຍ, ມີຄວາມສ່ຽງຕໍ່າຕໍ່ກັບການຕັ້ງຄ່າເຄືອຂ່າຍຂອງທ່ານ.
2. ເພື່ອໃຫ້ແນ່ໃຈວ່າການຈະລາຈອນການໂທວິດີໂອຖືກຈັດລໍາດັບຄວາມສໍາຄັນເປັນການສື່ສານໃນເວລາທີ່ແທ້ຈິງ, ກະລຸນາເບິ່ງທາງເລືອກຂ້າງລຸ່ມນີ້:
- ຖ້າ router ຂອງທ່ານສາມາດຈັດລໍາດັບຄວາມສໍາຄັນຂອງການຈະລາຈອນດ້ວຍຄ່າພາກສະຫນາມ DSCP ຂອງ 34 (aka Assured Forwarding 41 ຫຼື AF41) ທ່ານສາມາດຕັ້ງຄ່ານີ້. ການຈາລະຈອນ WebRTC ໃນເວລາຈິງທັງໝົດຖືກໝາຍດ້ວຍວິທີນີ້ ແລະນີ້ຈະປັບປຸງຄຸນນະພາບຂອງ Video Call ແລະວິທີແກ້ໄຂການປະຊຸມວິດີໂອອື່ນໆ.
- ຖ້າ router ຂອງເຈົ້າບໍ່ສາມາດເຮັດວຽກຂ້າງເທິງໄດ້, ທ່ານສາມາດຕັ້ງ QoS ເພື່ອຈັດລໍາດັບຄວາມສໍາຄັນຂອງແພັກເກັດ UDP ໃນລະດັບພອດ 5000-40000 ແລະນີ້ຈະຊ່ວຍໃຫ້ຈັດລໍາດັບຄວາມສໍາຄັນຂອງແພັກເກັດວິດີໂອແລະຫຼຸດຜ່ອນຄວາມຊັກຊ້າໃດໆ. WebRTC ໃຊ້ໂປຣໂຕຄໍ RTP ເພື່ອສົ່ງກະແສສື່ ແລະ RTP ໂດຍທົ່ວໄປແລ້ວໃຊ້ UDP 5000-40000. ການເຮັດສິ່ງນີ້ອາດຈະຈັດລໍາດັບຄວາມສໍາຄັນຂອງບາງແພັກເກັດທີ່ບໍ່ຕ້ອງການມັນແຕ່ສ່ວນໃຫຍ່ຈະເປັນແພັກເກັດ RTP. ການຕັ້ງຄ່າ QoS ໃນທາງນີ້ຈະຮັບປະກັນວ່າການຖ່າຍທອດວິດີໂອຈະມີການຂັດຂວາງແລະລົບກວນຫນ້ອຍທີ່ສຸດ.
ໂທວິດີໂອຈະພະຍາຍາມໃຊ້ເສັ້ນທາງເຄືອຂ່າຍທີ່ດີທີ່ສຸດທີ່ມັນສາມາດຊອກຫາໄດ້.
ຕາຕະລາງຕໍ່ໄປນີ້ລາຍຊື່ເສັ້ນທາງເຄືອຂ່າຍທີ່ມັນຈະຊອກຫາ, ຕາມລໍາດັບຄວາມຕ້ອງການ:
ເສັ້ນທາງເຄືອຂ່າຍ | ພອດເຊີບເວີ STUN/Relay |
---|---|
1: UDP peer-to-peer ໂດຍກົງ, ດ້ວຍ STUN server-assisted NAT traversal ແຕ່ລະຈຸດສິ້ນສຸດຈະຄົ້ນພົບທີ່ຢູ່ອິນເຕີເນັດພາຍນອກຂອງມັນໂດຍໃຊ້ STUN Server ທີ່ສະໜອງໃຫ້. ທີ່ຢູ່ນີ້ຖືກສະໜອງໃຫ້ປາຍທາງອື່ນ ແລະໃຊ້ເພື່ອຕັ້ງຄ່າການເຊື່ອມຕໍ່ຜ່ານການແປທີ່ຢູ່ເຄືອຂ່າຍ. ມີເດຍໄຫຼຜ່ານພອດທີ່ເລືອກແບບສຸ່ມໃນໄລຍະຂະຫນາດໃຫຍ່ຂອງພອດ UDP 49152 - 65535. |
3478 (UDP) |
2: ຜ່ານ Video Call relay server, ໂດຍໃຊ້ UDP-routed egress ຖ້າການເຊື່ອມຕໍ່ບໍ່ສາມາດຖືກສ້າງຂື້ນໂດຍໃຊ້ peer to peer ໂດຍກົງຂ້າງເທິງ, ຫຼັງຈາກນັ້ນ, ເຄື່ອງແມ່ຂ່າຍ TURN ທີ່ຖືກຕັ້ງຄ່າ UDP port 3478 ຈະຖືກພະຍາຍາມສ້າງການສົ່ງຕໍ່ໄປຫາຈຸດສິ້ນສຸດທາງໄກ. ທີ່ຢູ່ relay ນີ້ໄດ້ຖືກສະຫນອງໃຫ້ກັບຈຸດສິ້ນສຸດອື່ນໆແລະຖືກນໍາໃຊ້ເພື່ອຕັ້ງຄ່າການເຊື່ອມຕໍ່ໂດຍຜ່ານ relay, ກັບໄປໂດຍຜ່ານການເຊື່ອມຕໍ່ endpoint ທ້ອງຖິ່ນກັບເຄື່ອງແມ່ຂ່າຍຂອງ TURN. ມີເດຍໄຫລໄປຫາ UDP Port 3478 ໃນເຊີບເວີ TURN. |
3478 (UDP) |
3: ຜ່ານ Video Call relay server, ໂດຍໃຊ້ TCP-routed egress ຖ້າການເຊື່ອມຕໍ່ບໍ່ສາມາດຖືກສ້າງຂື້ນໂດຍໃຊ້ UDP ກັບ TURN Server, ການເຊື່ອມຕໍ່ກັບ TURN Server ແມ່ນຖືກສ້າງຕັ້ງຂຶ້ນຜ່ານ TCP 443 ບໍ່ແມ່ນ UDP 3478. ມີເດຍໄຫຼອອກໄປຂ້າງນອກໄປຫາພອດ TCP 443 ໃນ TURN Server. |
3478 (TCP) |
4: ຜ່ານ Video Call relay server, ໂດຍໃຊ້ TCP tunneling ຜ່ານ web proxy server ຖ້າເສັ້ນທາງເຊື່ອມຕໍ່ຜ່ານ NAT ບໍ່ສາມາດຕັ້ງໄປຫາ TURN Server ໄດ້, ການເຊື່ອມຕໍ່ tunnelled ກັບ TCP port 443 ຈະຖືກພະຍາຍາມຜ່ານຕົວທ່ອງເວັບທີ່ກໍາຫນົດຄ່າເວັບເຊີບເວີ. ມີເດຍໄຫຼອອກໄປຂ້າງນອກຜ່ານພຣັອກຊີເວັບ, ໄປຫາ TCP Port 443 ໃນ TURN Server. |
443 (TCP) |
5a, 5b: ຜ່ານ Video Call relay server, ໂດຍໃຊ້ Secure TCP ສໍາລັບ 3 ຫຼື 4 ຂ້າງເທິງ, ແຕ່ການນໍາໃຊ້ການເຊື່ອມຕໍ່ TLS TCP ກັບ TURN Server. |
443 (TCP/TLS) |
ສໍາລັບຂໍ້ມູນເພີ່ມເຕີມ, ເບິ່ງ Video Call Relay servers .