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

ต่อไปนี้คือแนวทางปฏิบัติแนะนำในการตั้งค่าเครือข่ายสำหรับการโทรผ่าน Google Voice

สร้างเครือข่ายที่พร้อมรองรับระบบคลาวด์

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

  • การรับส่งข้อมูลของ Voice ต้องมีเส้นทางเชื่อมต่ออินเทอร์เน็ตที่สั้น จึงควรหลีกเลี่ยงสิ่งต่อไปนี้
    • พร็อกซี
    • การตรวจสอบแพ็กเก็ตหรือเครื่องมือวิเคราะห์โปรโตคอล
  • การวัดและเพิ่มประสิทธิภาพ:

แนวทางปฏิบัติที่ดีที่สุดสำหรับพร็อกซี

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

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

การตรวจสอบแพ็กเก็ตหรือเครื่องมือวิเคราะห์โปรโตคอล

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

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

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

แนวทางปฏิบัติที่ดีที่สุดสำหรับ Wi-Fi

คำแนะนำต่อไปนี้ใช้กับสภาพแวดล้อมของสำนักงานทั่วไป วิศวกรด้านระบบไร้สายควรประเมินสภาพแวดล้อมที่มีความซับซ้อนแยกเป็นรายกรณี เช่น พื้นที่การผลิต พื้นที่ที่มีระดับสัญญาณรบกวนคลื่นความถี่วิทยุ (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

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

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

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

ช่วงที่อยู่ IP ของเสียง

การรับส่งข้อมูลของ 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

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