ผลการทดสอบคุณภาพเสียง

เกตเวย์ BS1200E จาก Oki Network Technologies มีประสิทธิภาพเหนือกว่าคู่แข่ง ผลลัพธ์นี้ไม่ชัดเจน แม้ว่าบริษัทจะครองตำแหน่งผู้นำในตลาดโทรศัพท์ IP ของญี่ปุ่นก็ตาม เพื่อให้ได้การบีบอัดเสียงที่มีคุณภาพและลดเวลาแฝง ผู้ผลิตรายนี้ใช้ตัวแปลงสัญญาณ G.729 แต่ต้องใช้แบนด์วิดท์ที่มากขึ้น

ตัดกับเกตเวย์บางอย่าง

อย่างไรก็ตาม สตรีมวิดีโอที่ส่งผ่านลิงก์ WAN (128 kbit/s) เพื่อขัดขวางนั้นมีอัตราบิตเฉลี่ยอยู่ที่ 113 kbit/s การจราจรพุ่งสูงขึ้นและอุดตันลิงก์เป็นประจำ ส่งผลให้การสื่อสารด้วยเสียงหยุดชะงัก อันดับที่ 2 ได้แก่ MAX 6000 จาก Lucent ที่ทำผลงานได้อย่างมีเกียรติ การสื่อสารเป็นสิ่งที่เข้าใจได้แม้จะไม่ได้ยินคำพูดก็ตาม ขนาดของแพ็กเก็ต RTP (โปรโตคอลแบบเรียลไทม์) จะเหมือนกับขนาดของแพ็กเก็ต BS1200E (80 ไบต์) MAX 6000 ควรได้รับประโยชน์จากตัวแปลงสัญญาณ G.723 (การบีบอัดที่ 6 kbit/s) เนื่องจากต้องใช้แบนด์วิธเกือบครึ่งหนึ่งในการสื่อสาร ในการป้องกันของ Lucent ควรสังเกตว่าตัวแปลงสัญญาณ G.723 ผลิตยากกว่าและใช้เวลาในการเขียนโค้ดนานกว่า นอกจากนี้ การสร้างเสียงเริ่มต้นยังต่ำกว่า G.729 เล็กน้อยมาก โซลูชันของ Oki และ Lucent แซงหน้า MultiVOIP MVP 800 จาก MultiTech Systems และ IP Telephony Gateway จาก Nokia อย่างมาก สะพานเหล่านี้ฟื้นฟูวาทกรรมอย่างเจ็บปวด การตัดทอนที่สำคัญทำให้บางข้อความไม่ได้ยิน ในความเป็นจริง MultiTech มีแต้มต่อสองแต้ม ประการแรก ขนาดของแพ็กเก็ต RTP ไม่สามารถเปลี่ยนแปลงได้ ผู้ผลิตเลือกใช้แพ็กเก็ตขนาด 48 ไบต์ ดังนั้นจึงจำเป็นต้องใช้แพ็กเก็ต RTP มากเป็นสองเท่าสำหรับแพ็กเก็ต 80 ไบต์ และดังนั้นจึงมีแบนด์วิธเป็นสองเท่า จากนั้นกลไกการตรวจสอบข้อผิดพลาดที่เรียกว่าการแก้ไขข้อผิดพลาดแบบส่งต่อจะทำงานอยู่ ซึ่งสร้างการรับส่งข้อมูลเพิ่มขึ้นเล็กน้อย สิ่งนี้อธิบายว่าทำไมแบนด์วิดท์ที่จำเป็นสำหรับการสื่อสารด้วยเสียงเดียวถึง 23 kbit/s เมื่อปิดใช้งานระบบตรวจสอบข้อผิดพลาด ความเร็ว 17 กิโลบิต/วินาทีก็เพียงพอที่จะบรรลุภารกิจนี้ ในทางกลับกันคำพูดที่เกิดขึ้นจะไม่สามารถเข้าใจได้ ในส่วนของ Nokia นั้นมีปัญหาด้านตัวแปลงสัญญาณ ผู้ผลิตชาวฟินแลนด์ใช้ SX7300 ซึ่งเป็นตัวแปลงสัญญาณที่เป็นกรรมสิทธิ์ของ Lucent Technologies ควรจัดเตรียมตัวแปลงสัญญาณแบบคลาสสิกตามคำแนะนำ H.323 ให้กับเกตเวย์ถัดไป

Cisco พิการจากนโยบายที่เป็นกรรมสิทธิ์ของตน

ในที่สุด สำหรับ Cisco คะแนนที่ได้รับก็ต่ำมาก! นี่เป็นเพราะความจริงที่ว่าในนโยบายการรวมข้อมูลเสียงและข้อมูลของ Cisco เอนเอียงไปทางห่วงโซ่การส่งข้อมูลที่ประกอบด้วยอุปกรณ์ทั้งหมดที่ผลิต ซึ่งช่วยให้สามารถใช้กลไกการจัดสรรลำดับความสำคัญตามความสำคัญของโฟลว์ โดยเฉพาะอย่างยิ่งต้องขอบคุณการจัดคิวแบบถ่วงน้ำหนักที่ยุติธรรม กลไกนี้จะใช้ลำดับความสำคัญสูงกับการรับส่งข้อมูลมัลติมีเดียโดยอัตโนมัติ มันถูกเปิดใช้งานตามค่าเริ่มต้นในเราเตอร์ของผู้ผลิตชาวแคลิฟอร์เนีย ด้วยการเชื่อมต่อเราเตอร์ Cisco โดยตรงผ่านลิงค์ WAN วิธีการแยกความแตกต่างของการรับส่งข้อมูลเหล่านี้ทำงานได้ดีดังที่เราได้เห็นไปแล้ว ในกรณีนี้ แม้ว่าสตรีมวิดีโอ 113 กิโลบิต/วินาทีจะผ่านช่อง B สองช่องของลิงก์ ISDN แต่คำพูดก็ยังได้รับการทำซ้ำได้อย่างสมบูรณ์แบบ เสียงมีความชัดเจนและคมชัด คะแนนของ Cisco ในเงื่อนไขเหล่านี้คือ 8.3 จาก 10 และเราเตอร์ 2600 และ 3640 ก็นำหน้าอยู่มาก ในทางกลับกัน ด้วยการใส่เราเตอร์ของบริษัทอื่นซึ่งไม่ได้เปิดใช้งานกลไกลำดับความสำคัญ (Access Node จาก Nortel Networks) เพื่อให้แน่ใจว่าลิงก์ WAN ผลลัพธ์ที่ได้คือหายนะ การเปิดใช้งานการจัดคิวแบบถ่วงน้ำหนักบนอุปกรณ์ Cisco จะไม่เปลี่ยนแปลงอะไร ช่องว่างขนาดใหญ่ (1 ถึง 5 วินาที) ทำให้คำพูดไม่สามารถเข้าใจได้อย่างสมบูรณ์ ไม่ต้องพูดถึงเสียงฟู่ระหว่างกรีด ซึ่งทำให้การฟังเจ็บปวดมาก

🔴 เพื่อไม่ให้พลาดข่าวสารจาก 01net ติดตามเราได้ที่Google ข่าวสารetวอทส์แอพพ์-