เพิ่มประสิทธิภาพเครือข่ายสำหรับ Voice

โครงสร้างพื้นฐานของเครือข่ายที่พร้อมรองรับระบบคลาวด์จะช่วยให้ระบบรับส่งข้อมูลของ Voice สื่อสารกับโครงสร้างพื้นฐานของ Google ได้อย่างมีประสิทธิภาพ โดยจะสร้างเครือข่ายได้ดังนี้

• การรับส่งข้อมูลของ Voice ต้องมีเส้นทางเชื่อมต่ออินเทอร์เน็ตที่สั้น จึงควรหลีกเลี่ยงสิ่งต่อไปนี้
  • พร็อกซี
  • การตรวจสอบแพ็กเก็ตหรือเครื่องมือวิเคราะห์โปรโตคอล
• การวัดและเพิ่มประสิทธิภาพ:
  • เวลาในการตอบสนอง: ความล่าช้าแบบทางเดียวสูงสุด 150 มิลลิวินาที (ITU G114)
  • แบนด์วิดท์: ค่าที่แนะนำคือ 50 kbps
  • เครือข่าย Wi-Fi: โปรดดูแนวทางปฏิบัติแนะนำสำหรับ Wi-Fi

ขอแนะนำว่าอย่าใช้พร็อกซีเซิร์ฟเวอร์ในเครือข่ายเพื่อรับส่งข้อมูลของ Voice

• ในการกำหนดค่าพร็อกซี ให้ใส่การรับส่งข้อมูล Voice ในรายการที่อนุญาต
• Voice จะไม่ใช้ TCP เป็นช่องทางสำรองเช่นเดียวกับ Google Meet แต่ Voice จะใช้เฉพาะ UDP ในการรับส่งข้อมูลเท่านั้น
• การรับส่งข้อมูลผ่านพร็อกซีจะเพิ่มเวลาในการตอบสนองซึ่งอาจทำให้คุณภาพเสียงของ Voice ลดลงโดยอัตโนมัติ Voice จะทำงานได้ดีที่สุดเมื่อเวลาในการตอบสนองระหว่างระบบของไคลเอ็นต์กับแบ็กเอนด์ของ Google มีค่าต่ำกว่า 100 มิลลิวินาที
• ไม่รองรับโปรโตคอลอินเทอร์เน็ตแบบ Socket Secure (SOCKS5)

หากเป็นไปได้ โปรดอย่าใช้การตรวจสอบแพ็กเก็ตหรือเครื่องมือวิเคราะห์โปรโตคอลสำหรับ Voice เนื่องจากเครื่องมือดังกล่าวอาจเป็นการเพิ่มเวลาในการตอบสนองซึ่งจะส่งผลให้โครงสร้างพื้นฐานของ Voice ต้องลดคุณภาพเสียงโดยอัตโนมัติ

นอกจากนี้ การตรวจสอบแพ็กเก็ตการรับส่งข้อมูลเสียงยังมีประโยชน์น้อยมาก เพราะเครื่องมือสแกนอัตโนมัติจะจัดโครงสร้างข้อมูลของสตรีมเสียงใหม่ไม่ได้

หากใช้เครื่องมือดังกล่าว ให้เพิ่มหมายเลขพอร์ตทั้งหมดที่ใช้รับส่งข้อมูล Voice ลงในรายการที่อนุญาตเพื่อหลีกเลี่ยงไม่ให้ข้อมูลผ่านเครื่องมือ

คำแนะนำต่อไปนี้ใช้สำหรับสภาพแวดล้อมของสำนักงานทั่วไป วิศวกรด้านระบบไร้สายควรประเมินสภาพแวดล้อมที่มีความซับซ้อนแยกเป็นรายกรณี เช่น พื้นที่การผลิต พื้นที่ที่มีระดับสัญญาณรบกวนคลื่นความถี่วิทยุ (RF) สูง หรือบริเวณที่มีสัญญาณไม่ครอบคลุม

การใช้งานแอปพลิเคชันแบบเรียลไทม์ผ่านเครือข่ายไร้สายอาจมีปัญหาได้ เนื่องจากมีคลื่นความถี่ RF และแบนด์วิดท์ที่อุปกรณ์ต่างๆ ใช้งานร่วมกันอยู่

โปรดตรวจสอบข้อควรพิจารณาต่อไปนี้อย่างละเอียดในระหว่างการออกแบบ การนำไปใช้งาน และการทำงานของเครือข่ายไร้สายที่ใช้กับ Voice

ย่านความถี่วิทยุ 2.4 GHz กับ 5 GHz

เราขอแนะนำไม่ให้นำแอปพลิเคชันแบบเรียลไทม์ไปใช้งานบนคลื่นความถี่ 2.4 GHz ในเครือข่ายไร้สาย (ซึ่งมักจะมีการใช้งานอย่างหนาแน่น) คำแนะนำนี้รวมถึงแอปพลิเคชันที่ให้บริการเชื่อมต่อในสภาพแวดล้อมของสำนักงานทั่วไป

คลื่นความถี่ในช่วง 2.4 GHz มักจะมีปัญหาเนื่องจากมีช่องสัญญาณที่ไม่ซ้อนทับกันเพียง 3 ช่อง และมักจะมีระดับสัญญาณรบกวนจากเครือข่ายใกล้เคียงสูง นอกจากนั้นยังได้รับผลกระทบจากอุปกรณ์อื่นๆ (เช่น ไมโครเวฟ) ซึ่งส่งผลให้เกิดสภาพแวดล้อมของคลื่น RF ที่มีสัญญาณรบกวนและซ้อนทับกันมากเกินไป

แอปพลิเคชันแบบเรียลไทม์อย่าง Voice จะทำงานได้ดีเมื่อมีกำลังของสัญญาณ ความล่าช้าของสัญญาณ เสียงรบกวน และการสูญหายของแพ็กเก็ตในปริมาณที่เหมาะสม ซึ่งสิ่งเหล่านี้แทบจะเป็นไปไม่ได้หากใช้งานบนคลื่นความถี่ 2.4 GHz

ข้อพิจารณาเกี่ยวกับการออกแบบหรือการนำไปใช้

หากคุณออกแบบเครือข่ายไร้สายที่รองรับแอปพลิเคชันแบบเรียลไทม์ ให้พิจารณากำลังของสัญญาณให้มากกว่าการครอบคลุม

• จัดการขนาดพื้นที่ที่สัญญาณครอบคลุมซึ่งควบคุมโดยกำลังส่งของอุปกรณ์ Access Point (AP) ปรับใช้พื้นที่สัญญาณที่มีขนาดเล็กลงเพื่อเพิ่มกำลังของสัญญาณในกรณีที่คาดว่าจะต้องมีการใช้งานอุปกรณ์เพิ่มมากขึ้น เช่น ห้องประชุมและหอประชุม ส่วนพื้นที่สัญญาณขนาดใหญ่นั้นเหมาะสำหรับการสร้างสัญญาณให้ครอบคลุมชั้นของสำนักงานมากกว่า
• ปิดใช้อัตราต่ำเพื่อปรับปรุงประสิทธิภาพการใช้งาน RF ซึ่งจะเป็นการบังคับให้ไคลเอ็นต์ไปจับสัญญาณกับ AP ที่ใกล้เคียงที่สุดขณะที่มีการโรมมิ่งระหว่าง AP

หาก SSID ของเครือข่ายไร้สายรองรับได้ทั้ง 2 คลื่นความถี่ (2.4 GHz และ 5 GHz) ควรใช้ฟีเจอร์ที่บังคับให้ไคลเอ็นต์จับกับคลื่นความถี่ 5 GHz

• ในความเป็นจริงไม่ควรมีโทรศัพท์ตั้งโต๊ะเกิน 10 เครื่องที่เชื่อมต่ออยู่กับ AP ตัวเดียวกัน ยิ่งมีจำนวนโทรศัพท์มากเท่าไหร่ก็จะยิ่งทำให้การใช้งานแย่ลงเท่านั้น
• ไม่ควรใช้โทรศัพท์ตั้งโต๊ะแบบไร้สายกับทีมที่มีปริมาณการโทรหนาแน่น เช่น ตัวแทนหรือทีมสนับสนุน ตัวอย่างเช่น เว็บไซต์ GOVO หรือศูนย์บริการที่ให้บริการทุกวันตลอด 24 ชั่วโมง
• อาการที่เสียงขาดหายไปเป็นเวลาไม่เกิน 10 วินาทีอาจเกิดขึ้นได้และจะแก้ไขในระดับเครือข่ายสำหรับโทรศัพท์ตั้งโต๊ะแบบไร้สายไม่ได้ เราไม่แนะนำให้ใช้เครือข่ายไร้สายสำหรับการโทรที่มีความสำคัญ เช่น การประชุม การแถลงข่าว หรือการโทรของผู้บริหาร
• แม้ว่ากฎในแต่ละประเทศ/ภูมิภาคจะแตกต่างกันไป แต่ข้อกำหนดโดยทั่วไปของอุปกรณ์ Wi-Fi ที่ใช้ช่องสัญญาณ DFS จะเหมือนกัน เช่น ต้องไม่รบกวนเรดาร์ของระบบพยากรณ์อากาศในท้องถิ่น ดังนั้น AP ที่มีการรบกวนเรดาร์จะทำให้สัญญาณหลุด และไคลเอ็นต์ทั้งหมดจะต้องเชื่อมต่อใหม่กับ AP คนละตัวที่ใช้ช่องสัญญาณที่แตกต่างกัน

หากต้องการใช้งานฟีเจอร์ขั้นสูง เช่น การโรมมิ่งอย่างไม่ติดขัดระหว่าง AP ต่างๆ และการจัดการคลื่น RF ให้เหมาะสม เครือข่ายไร้สายจะต้องได้รับการจัดการและดำเนินการจากส่วนกลาง ไม่ใช่เครื่องสแตนด์อโลนหลายๆ เครื่องรวมกัน

และสุดท้ายให้สำรวจเครือข่ายไร้สายหลังจากที่มีการปรับใช้แล้ว เพื่อให้แน่ใจว่ามีสัญญาณครอบคลุมทั่วพื้นที่ที่มีมักมีการใช้งาน Voice

การรับส่งข้อมูลของ Voice มีการรักษาความปลอดภัยและเข้ารหัสไว้ คุณจึงไม่ต้องจำกัดการรับส่งข้อมูลไปยังที่อยู่ IP ของ Google

ทั้งนี้หากมีข้อจํากัดของเครือข่ายที่ทําให้ต้องจํากัดการรับส่งข้อมูล ให้ใส่ช่วง IP ต่อไปนี้ในรายการที่อนุญาต เพื่ออนุญาตให้เซิร์ฟเวอร์สื่อของ Voice ทำงาน IP ดังกล่าวใช้สําหรับ Voice for Google Workspace โดยเฉพาะเพื่อให้คุณระบุการรับส่งข้อมูลเสียงที่ใช้ใน Google Workspace และลดความสําคัญของการรับส่งข้อมูล Voice จากบัญชีผู้ใช้ทั่วไปได้ ดังนั้น คุณจึงตั้งค่าและเพิ่มประสิทธิภาพการเข้าถึงเครือข่ายและไฟร์วอลล์ได้ดียิ่งขึ้น

• IPv4: 74.125.39.0/24
• IPv6: 2001:4860:4864:2::0/64

โปรดตั้งค่าเครือข่ายให้พอร์ตต่อไปนี้อนุญาตให้มีการรับส่งข้อมูลเสียงผ่านเข้าและออกจากองค์กรได้

• พอร์ต UDP ขาออก 19302 ถึง 19309
• TCP ขาออกในพอร์ต 443

หมายเหตุ: ช่วงพอร์ต 19302 ถึง 19309 ของ Voice ใช้การตั้งค่าพอร์ต UDP ของ Chrome WebRTC ดูข้อมูลเพิ่มเติมได้ที่หัวข้อตั้งค่านโยบาย Chrome สำหรับผู้ใช้หรือเบราว์เซอร์