المحتويات

المقدمة

المتطلبات الأساسية

المتطلبات

المكونات المستخدمة

الاصطلاحات

إرشادات تصميم جودة الخدمة ل VoIP عبر إرتباطات PPP

أولوية صارمة لحركة مرور البيانات الصوتية (أولوية IP RTP أو LLQ)

إرشادات تكوين LLQ

إرشادات تكوين أولوية IP RTP

تجزئة ودمج الارتباط (LFI): Multilink PPP

بروتوكول الوقت الحقيقي المضغوط (cRTP)

تلميحات أخرى لخفض النطاق الترددي

الرسم التخطيطي للشبكة

التكوينات

أوامر التحقق من الصحة واستكشاف الأخطاء وإصلاحها

إخراج العرض والتصحيح للعينة

معلومات ذات صلة

المقدمة

ويدرس هذا النموذج من التكوين نقل الصوت عبر بروتوكول VoIP مع بروتوكول نقطة إلى نقطة (PPP) عبر تكوين الخط المؤجر بنطاق ترددي منخفض. يتضمن هذا المستند معلومات فنية أساسية حول الميزات التي تم تكوينها وإرشادات التصميم واستراتيجيات التحقق واستكشاف الأخطاء وإصلاحها الأساسية.

ملاحظة: من المهم ملاحظة أنه في التكوين أدناه، يتم توصيل الموجهين من الخلف إلى الخلف عبر خط مستأجر. ومع ذلك، في معظم المخططات، يمكن أن توجد الموجهات التي تدعم ميزة الصوت في أي مكان. عادة، تستخدم الموجهات الصوتية اتصال LAN بموجهات أخرى متصلة بشبكة WAN (بمعنى آخر، خط PPP المؤجر). وهذا مهم لأنه إذا لم تكن الموجهات الصوتية متصلة مباشرة عبر PPP عبر خط مستأجر، فيجب تكوين جميع أوامر تكوين WAN على الموجهات المتصلة بشبكة WAN، وليس على الموجهات الصوتية، كما هو موضح في التكوينات أدناه.

المتطلبات الأساسية

المتطلبات

لا توجد متطلبات خاصة لهذا المستند.

المكونات المستخدمة

تم إختبار التكوينات المقدمة في هذا المستند باستخدام هذا الجهاز:

- إصدارا Cisco 3640s مع برنامج Cisco IOS® الإصدار 12.2.6a (IP Plus)

- تم إدخال أولوية IP RTP في الإصدار 12.0(5)T من Cisco IOS.

- تم تقديم LLQ في الإصدار 12.0(7)T من Cisco IOS.

- تم تقديم LFI في الإصدار 11.3 من Cisco IOS.

- تحتوي إصدارات Cisco IOS التي تتجاوز 12.0.5T على تحسينات كبيرة في الأداء ل cRTP.

الاصطلاحات

للحصول على مزيد من المعلومات حول اصطلاحات المستندات، ارجع إلى اصطلاحات تلميحات Cisco التقنية.

إرشادات تصميم جودة الخدمة ل VoIP عبر إرتباطات PPP

يوفر هذا القسم إرشادات التصميم لتكوين خطوط VoIP عبر بروتوكول الاتصال من نقطة إلى نقطة (PPP) المؤجرة (مع التركيز على الارتباطات منخفضة السرعة). هناك متطلبان أساسيان للحصول على جودة صوت جيدة:

- الحد الأدنى للتأخير من نهاية إلى نهاية وتجنب الرجفان (تباين التأخير).

- تم تحسين متطلبات النطاق الترددي للرابط وإنشاطها بشكل صحيح.

ولضمان المتطلبات المذكورة أعلاه، ينبغي اتباع عدة مبادئ توجيهية هامة:

توجيهية

الوصف

أولوية صارمة لحركة مرور البيانات الصوتية (أولوية IP RTP أو LLQ)

طريقة لتوفير أولوية صارمة لحركة المرور الصوتية.

تجزئة ودمج الارتباط (LFI)

قد يكون شرطا إلزاميا للروابط منخفضة السرعة.

ضغط RTP

غير مطلوب لتوفير جودة صوت جيدة، ولكنه يقلل من إستهلاك عرض النطاق الترددي للمكالمات. النصيحة العامة المتعلقة بضغط RTP هي تطبيقه بعد الحصول على تكوين عامل بجودة صوت جيدة (تبسيط أستكشاف الأخطاء وإصلاحها).

التحكم في الدخول إلى المكالمة (CAC)

غير مضمن في هذا المستند. يتم إستخدام CAC للتحكم في عدد المكالمات التي يمكن إنشاؤها عبر الارتباط. على سبيل المثال، إذا كان إرتباط شبكة WAN بين البوابتين يحتوي على النطاق الترددي لحمل مكالمتين من خلال بروتوكول VoIP فقط، فقد يؤدي قبول مكالمة ثالثة إلى إضعاف جودة الصوت لجميع المكالمات الثلاثة. لمزيد من المعلومات، ارجع إلى: التحكم بإذن الدخول عبر بروتوكول VoIP .

للتلخيص، بالنسبة لارتباط PPP المنخفض السرعة مع الموجهات/البوابات كمصادر فقط لحركة مرور الصوت، تكون ميزتان إلزاميتان:

1. أولوية صارمة لحركة المرور الصوتية

2. تجزئة ودمج الارتباط (LFI)

أولوية صارمة لحركة مرور البيانات الصوتية (أولوية IP RTP أو LLQ)

اعتبارا من الإصدار 12.2 من برنامج Cisco IOS Software، هناك طريقتان رئيسيتان لتوفير أولوية صارمة لحركة المرور الصوتية:

- أولوية IP RTP (تسمى أيضا PQ/WFQ: قائمة الانتظار ذات الأولوية / قوائم الانتظار العادلة المرجحة)

- قوائم انتظار تقليل التأخير (تسمى أيضا PQ/CBWFQ: قائمة الانتظار ذات الأولوية / قوائم الانتظار العادلة والمقدرة المعتمدة على الفئة).

أولوية IP RTP

تقوم أولوية IP RTP بإنشاء قائمة انتظار أولوية صارمة لمجموعة من تدفقات حزم RTP التي تنتمي إلى نطاق من منافذ وجهة بروتوكول مخطط بيانات المستخدم (UDP). بينما يتم التفاوض بشكل ديناميكي على المنافذ الفعلية المستخدمة بين الأجهزة الطرفية أو البوابات، تستخدم جميع منتجات Cisco VoIP نفس نطاق منفذ UDP (16384-32767). بمجرد أن يتعرف الموجه على حركة مرور VoIP، فإنه يضعها في قائمة الانتظار ذات الأولوية الصارمة. عندما تكون قائمة الانتظار ذات الأولوية فارغة، تتم معالجة قوائم الانتظار الأخرى وفقا لقائمة الانتظار العادلة والمقدرة القياسية (WFQ). لا تصبح أولوية IP RTP نشطة حتى يكون هناك إزدحام في الواجهة. يوضح هذا الصورة عملية أولوية IP RTP:

ملاحظة: تسمح أولوية IP RTP بتقييد قائمة الانتظار ذات الأولوية (PQ) عند وجود نطاق ترددي متاح على قائمة الانتظار الافتراضية (WFQ)، ولكن تقوم بشكل صارم بتغيير محتويات قائمة الانتظار ذات الأولوية عندما يكون هناك إزدحام على الواجهة.

قوائم انتظار تقليل التأخير

LLQ هي ميزة توفر PQ صارم لقوائم الانتظار العادلة والمقدرة (CBWFQ) المستندة إلى الفئة. يعمل LLQ على تمكين PQ واحد صارم داخل CBWFQ على مستوى الفئة. باستخدام LLQ، يتم إلغاء قوائم انتظار البيانات الحساسة للتأخير (في PQ) وإرسالها أولا. في بروتوكول VoIP مع تطبيق LLQ، يتم وضع حركة مرور الصوت في PQ المقيد.

يتم تنظيم PQ لضمان عدم تعرض قوائم الانتظار العادلة للنطاق الترددي. عندما تقوم بتكوين PQ، فإنك تحدد في كيلوبت في الثانية الحد الأقصى لمقدار عرض النطاق الترددي المتاح ل PQ. عندما تكون الواجهة مزدحمة، تتم خدمة PQ حتى يصل الحمل إلى قيمة Kbps التي تم تكوينها في بيان الأولوية. يتم بعد ذلك إسقاط حركة المرور الزائدة لتجنب المشكلة مع ميزة مجموعة الأولوية القديمة من Cisco المتمثلة في تجويع قوائم الانتظار ذات الأولوية المنخفضة.

هذا الأسلوب أكثر تعقيدا ومرونة من أولوية IP RTP. يجب أن يعتمد الاختيار بين الطريقتين على أنماط حركة المرور في شبكتك الحقيقية واحتياجاتك الفعلية.

أولوية LLQ مقابل IP RTP

يلخص هذا الجدول الفروق الرئيسية بين أولوية LLQ و IP RTP ويقدم بعض الإرشادات حول متى يمكن إستخدام كل طريقة.

قوائم انتظار تقليل التأخير (LLQ)

أولوية IP RTP

مطابقة حركة المرور الصوتية استنادا إلى:

- قوائم الوصول (لنطاق منفذ UDP وعناوين الأجهزة المضيفة ورأس IP إلى الحقول: أسبقية IP و DSCP والمزيد)

- نطاق منفذ IP RTP

- حقول IP إلى (نوع الخدمة): أسبقية DCSP و/أو IP

- البروتوكولات وواجهات الإدخال

- كافة معايير المطابقة الصالحة المستخدمة في CBWFQ

الفوائد:

- المزيد من المرونة حول كيفية مطابقة حركة المرور وتوجيهها إلى PQ و CBWFQ الصارمة

- يمكن تكوين فئات إضافية لضمان النطاق الترددي لحركة المرور الأخرى مثل: إرسال إشارات VoIP والفيديو.

مساوئ:

- تهيئة معقدة

مطابقة حركة المرور الصوتية استنادا إلى:

- استنادا إلى نطاق منفذ RTP UDP: 16384-32767

الفوائد:

- تهيئة بسيطة

مساوئ:

- تتم خدمة حركة مرور RTCP (إرسال إشارات VoIP) في قائمة انتظار WFQ
ملاحظة: يستخدم بروتوكول RTP بروتوكول RTCP (بروتوكول التحكم في الوقت الفعلي) للتحكم في تسليم حزم RTP. بينما تستخدم منافذ RTP أرقاما زوجية، تستخدم منافذ RTCP أرقاما فردية في النطاق 16384-32767. تضع أولوية IP RTP منافذ RTP في PQ، بينما يتم خدمة منافذ RTCP في قائمة الانتظار الافتراضية العادلة والمقدرة.

- يخدم حركة مرور الصوت عبر بروتوكول الإنترنت (VoIP) في قاعدة بيانات العمليات، ولكن أي حركة مرور أخرى تحتاج إلى معاملة تفضيلية وضمان عرض النطاق الترددي يتم تقديمها في WFQ. في حين يمكن أن يفرق WFQ بين التدفقات والأوزان (بناء على أسبقية IP)، إلا أنه لا يمكنه ضمان ضمان النطاق الترددي لأي تدفق.

إرشادات

- يجب أن يكون الاختيار بينها قائما على أنماط حركة المرور في شبكتك الحقيقية واحتياجاتك الفعلية.

- إذا كنت بحاجة إلى توفير أولوية صارمة لحركة المرور الصوتية الخاصة بك، ويمكن التعامل مع حركة المرور الأخرى كنوع واحد (بيانات)، فعندئذ تقوم أولوية IP RTP بوظيفة جيدة لشبكتك باستخدام تكوين بسيط.

- إذا كنت تخطط لتحديد أولوية حركة مرور البيانات الصوتية استنادا إلى معايير أخرى غير منافذ UDP (على سبيل المثال DiffServ PHB)، فمن الضروري وجود LLQ.

لمزيد من المعلومات حول إرتباط أساليب قوائم الانتظار واختلافاتها، ارجع إلى نظرة عامة على إدارة الازدحام.

إرشادات تكوين LLQ

اتبع الإرشادات التالية لتكوين LLQ:

1. قم بإنشاء خريطة فئة لحركة مرور بيانات VoIP وحدد معايير المطابقة

توضح هذه الأوامر كيفية إكمال هذه المهمة:

maui-voip-sj(config)#class-map ?

WORD  class-map name

match-all  Logical-AND all matching statements under this classmap

match-any  Logical-OR all matching statements under this classmap

maui-voip-sj(config)#class-map match-all voice-traffic

!-- Choose a descriptive class_name.

maui-voip-sj(config-cmap)#match ?

access-group         Access group

any                  Any packets

class-map            Class map

cos                  IEEE 802.1Q/ISL class of service/user priority values

destination-address  Destination address

input-interface      Select an input interface to match

ip                   IP specific values

mpls                 Multi Protocol Label Switching specific values

not                  Negate this match result

protocol             Protocol

qos-group            Qos-group

source-address       Source address

!-- In this example, the access-group matching option is used for its !-- flexibility (it uses an access-list)

maui-voip-sj(config-cmap)#match access-group ?

<1-2699>  Access list index  name      Named Access List

maui-voip-sj(config-cmap)#match access-group 102

!-- Now, create the access-list to match the class-map access-group:

maui-voip-sj(config)#access-list 102 permit udp any any range 16384 32776

!-- Safest and easiest way is to match with UDP port range 16384-32767 !-- This is the port range Cisco IOS H.323 products utilize to transmit !-- VoIP packets.

كما يمكن إستخدام قوائم الوصول هذه لمطابقة حركة المرور الصوتية باستخدام الأمر match access-group:

access-list 102 permit udp any any precedence critical

!-- This list filters traffic based on the IP packet TOS: Precedence field.

!-- Note: Ensure that other non-voice traffic does NOT uses the

!-- same precedence value.

access-list 102 permit udp any any dscp ef

!-- In order for this list to work, ensure that VoIP packets are tagged with

!-- the dscp ef code before they exit on the LLQ WAN interface.

!-- For more information on DSCP refer to:

!-- Implementing Quality of Service Policies with DSCP

!-- Note: If endpoints are not trusted on their packet marking, you can mark

!-- incoming traffic by applying an inbound service policy on an inbound

!-- interface. This procedure is out of the scope of this doc.

Access-list 102 permit udp host 192.10.1.1 host 192.20.1.1

!-- This access-list can be used in cases where the VoIP devices cannot !-- do precedence or dscp marking and you cannot determine the !-- VoIP UDP port range.

وهذه هي طرق مطابقة أخرى يمكن إستخدامها بدلا من مجموعات الوصول:

- بدءا من الإصدار 12.1.2.T من Cisco IOS، يتم تنفيذ وظيفة أولوية IP RTP ل LLQ. تطابق هذه الميزة محتويات فئة الأولوية التي تنظر إلى منافذ UDP التي تم تكوينها وتخضع لقيود خدمة المنافذ الزوجية فقط في PQ.

class-map voice

match ip rtp 16384 16383

- تعمل هاتان الطريقتان بموجب الافتراض بأن حزم VoIP يتم تمييزها عند البيئات المضيفة الأصلية، أو تتطابق مع الموجه وتمييزه قبل تطبيق عملية LLQ الصادرة.

class-map voice

match ip precedence 5

أو

class-map voice

match ip dscp ef

ملاحظة: بدءا من الإصدار 12.2.2T من IOS، يمكن لنظراء الطلب عبر بروتوكول VoIP وضع علامة على حامل الصوت وحزم إرسال الإشارات قبل عملية LLQ. وهذا يسمح بطريقة قابلة للتطوير لوضع العلامات على حزم بروتوكول VoIP ومطابقتها من خلال قيم رموز DSCP الخاصة ببروتوكول LLQ.

2. إنشاء خريطة فئة لإرسال إشارات VoIP وتحديد معايير المطابقة (إختياري)

توضح هذه الأوامر كيفية إكمال هذه المهمة:

class-map voice-signaling

match access-group 103

!

access-list 103 permit tcp any eq 1720 any

access-list 103 permit tcp any any eq 1720

ملاحظة: يمكن إنشاء مكالمات VoIP باستخدام H.323 أو SIP أو MGCP أو Skinny (بروتوكول خاص يستخدم بواسطة Cisco Call Manager). افترض المثال أعلاه وجود اتصال H.323 السريع. تعمل هذه القائمة كمرجع للمنافذ المستخدمة من قبل قنوات التحكم/إرسال إشارات VoIP:

- H.323/H.225 = TCP 1720

- H.323/H.245 = TCP 11xxx (توصيل قياسي)

- H.323/H.245 = TCP 1720 (اتصال سريع)

- H.323/H.225 RAS = TCP 1719

- Skinny = TCP 2000-2002 (CM Encore)

- ICCP = TCP 8001-8002 (CM Encore)

- MGCP = UDP 2427، TCP 2428 (CM Encore)

- SIP= UDP 5060 و TCP 5060 (قابل للتكوين)

3. إنشاء خريطة سياسة والاقتران بخرائط فئة VoIP

الغرض من خريطة السياسة هو تحديد كيفية مشاركة موارد الارتباط أو تعيينها لفئات الخريطة المختلفة. توضح هذه الأوامر كيفية إكمال هذه المهمة:

maui-voip-sj(config)#policy-map VOICE-POLICY

!-- Choose a descriptive policy_map_name.

maui-voip-sj(config-pmap)#class voice-traffic

maui-voip-sj(config-pmap-c)#priority ?

<8-2000000>  Kilo Bits per second

!-- Configure the voice-traffic class to the strict priority !-- Queue (priority command) and assign the bandwidth.

maui-voip-sj(config-pmap)#class voice-signaling

maui-voip-sj(config-pmap-c)#bandwidth 8

!-- Assign 8 Kbps to the voice-signaling class

maui-voip-sj(config-pmap)#class class-default

maui-voip-sj(config-pmap-c)#fair-queue

!-- The remaining data traffic is treated as Weighted Fair Queue

ملاحظة: على الرغم من أنه من الممكن وضع أنواع مختلفة من حركة المرور في الوقت الفعلي في قائمة الانتظار إلى PQ، إلا أن Cisco توصيك بتوجيه حركة مرور الصوت فقط إليها. يمكن لحركة المرور في الوقت الفعلي، مثل الفيديو، تقديم تباين في التأخير (PQ هو FIFO - أول من يخرج - قائمة انتظار). تتطلب حركة المرور الصوتية أن يكون التأخير غير متغير لتجنب الرجفان.

ملاحظة: يجب أن يكون مجموع القيم لجمل الأولوية وعرض النطاق الترددي أقل من أو يساوي 75 بالمائة من عرض النطاق الترددي للارتباط. وإلا يتعذر تعيين service-policy إلى الارتباط (للاطلاع على رسائل الخطأ، تأكد من تمكين وحدة تحكم التسجيل للوصول إلى وحدة التحكم ومن تمكين terminal monitor للوصول إلى برنامج Telnet).

ملاحظة: عند تكوين VoIP عبر إرتباط بسرعة 64 كيلوبت في الثانية لدعم مكالمتين صوتيتين، من الشائع تخصيص أكثر من 75 بالمائة (48 كيلوبت في الثانية) من النطاق الترددي للارتباط إلى PQ. في مثل هذه الحالات، يمكنك إستخدام الأمر max-reserved-bandwidth 80 لزيادة النطاق الترددي المتاح إلى 80 في المائة (51 كيلوبت/ثانية).

لمزيد من المعلومات حول أوامر النطاق الترددي والأولوية، ارجع إلى مقارنة أوامر النطاق الترددي والأولوية لنهج خدمة جودة الخدمة (QoS).

4. تمكين LLQ: تطبيق خريطة السياسة على واجهة WAN الصادرة

توضح هذه الأوامر كيفية إكمال هذه المهمة:

maui-voip-sj(config)#interface multilink 1

maui-voip-sj(config-if)#service-policy output VOICE-POLICY

!-- In this scenario (MLPPP LFI), the service policy is applied to !-- the Multilink interface.

إرشادات تكوين أولوية IP RTP

لتكوين أولوية IP RTP أستخدم الإرشادات التالية:

- Router(config-if)#ip rtp priority starting-rtp-port-#port-#-rangebandwidth

الوصف

starting-rtp-port-number

الحد الأدنى لمنفذ UDP. أقل رقم منفذ يتم إرسال الحزم إليه. بالنسبة ل VoIP، قم بتعيين هذه القيمة على 16384.

port-number-range

نطاق منافذ وجهة UDP. ينتج الرقم، الذي تتم إضافته إلى start-rtp-port-number، أعلى رقم منفذ UDP. بالنسبة ل VoIP، قم بتعيين هذه القيمة على 16383 (32767 - 16384 = 16383)

bandwidth

الحد الأقصى للنطاق الترددي المسموح به (كيلوبت/ثانية) في قائمة انتظار الأولوية. قم بتعيين هذا الرقم وفقا لعدد الاستدعاءات المتزامنة التي يدعمها النظام.

عينة من التكوين:

interface Multilink1

!--- Some output omitted

bandwidth 64

ip address 172.22.130.2 255.255.255.252

ip tcp header-compression

fair-queue

no cdp enable

ppp multilink

ppp multilink fragment-delay 10

ppp multilink interleave

multilink-group 1

ip rtp header-compression iphc-format

ip rtp priority 16384 16383 45

تجزئة ودمج الارتباط (LFI): Multilink PPP

في حين أن 1500 بايت هي حجم شائع لحزم البيانات، فإن حزمة نقل الصوت عبر بروتوكول الإنترنت (VoIP) النموذجية (التي تحمل إطارات الصوت G.729) يمكن أن تكون حول 66 بايت (حمولة الصوت 20 بايت، وحمولة الصوت 6 بايت من الطبقة 2، وحزمة RTP و UDP ذات 20 بايت، ورؤية IP ذات 20 بايت).

الآن، تخيل رابط خط مؤجر بسرعة 56 كيلوبت في الثانية حيث تتعايش حركة مرور البيانات والصوت. إذا كانت الحزمة الصوتية جاهزة لإجراء تسلسل بمجرد بدء إرسال حزمة بيانات عبر الارتباط، فهذا يعني أن هناك مشكلة. يجب أن تنتظر الحزمة الصوتية الحساسة للتأخير 214 ثانية قبل إرسالها (يستغرق تسلسل الحزمة 1500 بايت عبر إرتباط 56 كيلوبت/ثانية 214 ثانية).

كما ترى، يمكن لحزم البيانات الكبيرة أن تؤخر بشكل ضار تسليم الحزم الصوتية الصغيرة، مما يقلل من جودة الكلام. كما يعمل تجزئة حزم البيانات الكبيرة هذه إلى حزم أصغر حجما والتداخل بين الحزم الصوتية بين الأجزاء على تقليل التشويش والتأخير. تساعد ميزة تجزئة ودمج إرتباط Cisco IOS (LFI) في تلبية متطلبات التسليم في الوقت الفعلي ل VoIP. توضح هذه الصورة تشغيل LFI:

وكما هو موضح في الجدول 1، يمكن أن يكون مقدار تأخير التسلسل (الوقت اللازم لوضع وحدات بت بالفعل على واجهة) الذي تم تقديمه على إرتباطات WAN منخفضة السرعة كبيرا، نظرا لأن مدة التأخير من نهاية إلى نهاية في إتجاه واحد لا ينبغي أن تتجاوز 150 مللي ثانية. (تحدد توصية ITU-T G.114 150 مللي ثانية كحد أقصى من نهاية إلى نهاية في إتجاه واحد.)

الجدول 1. تأخير تسلسل أحجام مختلفة للإطارات على تأخر تسلسل الروابط منخفضة السرعة = حجم الإطار (وحدات بت)/عرض النطاق الترددي للارتباط (بت في الثانية)

1 بايت

64 بايت

128 بايت

256 بايت

512 بايت

1024 بايت

1500 بايت

56 كيلوبت في الثانية

143 الولايات المتحدة

9 مللي ثانية

18 مللي ثانية

36 مللي ثانية

72 مللي ثانية

144 مللي ثانية

214 مللي ثانية

64 كيلوبت/ثانية

وحدة تخزين داخلية

8 مللي ثانية

16 مللي ثانية

32 مللي ثانية

64 مللي ثانية

126 مللي ثانية

187 مللي ثانية

128 كيلوبت في الثانية

62.5 دولار

4 مللي ثانية

8 مللي ثانية

16 مللي ثانية

32 مللي ثانية

64 مللي ثانية

93 مللي ثانية

256 كيلوبت في الثانية

31 الولايات المتحدة

2 مللي ثانية

4 مللي ثانية

8 مللي ثانية

16 مللي ثانية

32 مللي ثانية

46 مللي ثانية

512 كيلوبت في الثانية

15.5 دولار

1 مللي ثانية

2 مللي ثانية

4 مللي ثانية

8 مللي ثانية

16 مللي ثانية

32 مللي ثانية

768 كيلوبت في الثانية

10

640 دولارا أمريكيا

1٫28 مللي ثانية

2٫56 مللي ثانية

5٫12 مللي ثانية

10٫24 مللي ثانية

15 مللي ثانية

1536 كيلوبت في الثانية

5 الولايات المتحدة

320 دولارا أمريكيا

640 دولارا أمريكيا

1٫28 مللي ثانية

2٫56 مللي ثانية

5٫12 مللي ثانية

7٫5 مللي ثانية

ملاحظة: بالنسبة للتطبيقات الصوتية، يبلغ التأخير الموصى بتسلسله (على أساس كل خطوة) 10 مللي ثانية ويجب ألا يتجاوز 20 مللي ثانية.

يكون حجم جزء الارتباط قابلا للتكوين في قياسات الوقت بالمللي ثانية (msec) باستخدام الأمر ppp multilink fragment-delay. يتطلب LFI تكوين إرتباط PPP متعدد على الواجهة مع تشغيل واجهة PPP متعددة الارتباطات. لمزيد من المعلومات حول تكوين LFI، ارجع إلى قسم هذا المستند.

ملاحظة: في الحالات التي يكون لديك فيها أكثر من اتصال مخصص نصف T1 (بسرعة 768 كيلوبت في الثانية)، لا تحتاج إلى ميزة تجزئة. (ومع ذلك، ما زلت بحاجة إلى آلية جودة الخدمة، مثل أولوية LLQ أو IP RTP). يوفر نصف T1 عرض نطاق ترددي كاف للسماح للحزم الصوتية بالدخول إلى قائمة الانتظار والخروج منها دون تأخير. أيضا، قد لا تحتاج ضغط لبروتوكول الوقت الفعلي (cRTP)، والذي يساعد على الحفاظ على النطاق الترددي من خلال ضغط رؤوس IP RTP، في حالة نصف T1.

بروتوكول الوقت الحقيقي المضغوط (cRTP)

ملاحظة: لا يلزم توفر بروتوكول cRTP لضمان جودة الصوت. فهي ميزة تقلل من إستهلاك عرض النطاق الترددي. قم بتكوين cRTP بعد تلبية جميع الشروط الأخرى وتكون جودة الصوت جيدة. يمكن أن يوفر هذا الإجراء وقت أستكشاف الأخطاء وإصلاحها من خلال عزل مشكلات cRTP المحتملة.

استنادا إلى RFC 2508، تقوم ميزة ضغط رأس RTP بضغط رأس IP/UDP/RTP من 40 بايت إلى 2 أو 4 بايت، مما يقلل الاستهلاك غير الضروري للنطاق الترددي العريض. هو مخطط ضغط خطوة بخطوة؛ لذلك، يجب تكوين cRTP على كلا طرفي الارتباط (ما لم يتم تكوين الخيار passive). لتكوين cRTP، أستخدم هذا الأمر على مستوى الواجهة:

- Router(config-if)#ip rtp header-compression [passive]

بما أن عملية الضغط يمكن أن تكون كثيفة المعالجة المركزية، فإن ضغط رأس RTP يتم تنفيذه في التحويل السريع ومسارات تحويل CEF على هيئة إطلاق 12.0.(7)T من IOS. في بعض الأحيان يتم تعطيل عمليات التنفيذ هذه، ومن ثم يتم تحويل الطريقة الوحيدة التي تعمل بها. توصي Cisco فقط باستخدام cRTP مع إرتباطات أقل من 768 كيلوبت/ثانية، ما لم يكن الموجه يعمل بمعدل إستخدام منخفض لوحدة المعالجة المركزية. مراقبة إستخدام وحدة المعالجة المركزية (CPU) الخاصة بالموجه وتعطيل cRTP إذا كان أعلى من 75 بالمائة.

ملاحظة: عند تكوين الأمر ip rtp header-compression، يضيف الموجه الأمر ip tcp header-compression إلى التكوين بشكل افتراضي. يتم إستخدام هذا لضغط حزم TCP/IP الخاصة بالرؤوس. يكون ضغط الرأس مفيدا بشكل خاص على الشبكات ذات نسبة كبيرة من الحزم الصغيرة، مثل تلك التي تدعم العديد من إتصالات Telnet. يتم دعم تقنية ضغط رأس TCP، الموضحة بالكامل في RFC 1144، على الخطوط التسلسلية باستخدام تضمين HDLC أو PPP.

لضغط رؤوس TCP دون تمكين cRTP، أستخدم هذا الأمر:

- Router(config-if)#ip tcp header-compression [passive]

لمزيد من المعلومات: بروتوكول نقل الوقت الفعلي المضغوط

تلميحات أخرى لخفض النطاق الترددي

- أستخدم أجهزة فك الترميز/فك الترميز ذات معدل البت المنخفض (Codec) على أرجل اتصال VoIP، حيث يوصى باستخدام G.729 (8 كيلوبت/ثانية). (هذا هو برنامج الترميز الافتراضي على جهات اتصال VoIP). لتكوين برامج فك تشفير مختلفة أستخدم الأمر router(config-dial-peer)#codec تحت الطلب الهاتفي المطلوب.

- على الرغم من أن التردد المتعدد للطنين المزدوج (DTMF) يتم نقله عادة بدقة عند إستخدام برامج فك تشفير الصوت ذات معدل البت العالي مثل G.711، إلا أن برامج فك التشفير ذات معدل البت المنخفض (مثل G.729 و G.723.1) يتم تحسينها بدرجة عالية للأنماط الصوتية وتميل إلى تشويه نغمات DTMF. قد يؤدي هذا النهج إلى حدوث مشاكل في الوصول إلى أنظمة الاستجابة الصوتية التفاعلية (IVR). يحل أمر ترحيل DTMF مشكلة تشوه DTMF بنقل نغمات DTMF "خارج النطاق" أو منفصلة من تدفق الصوت المرمز. إذا تم إستخدام برامج الترميز بمعدل البت المنخفض (G.729، G.723)، فقم بتشغيل ترحيل DTMF أسفل نظير اتصال VoIP.

- قد تحتوي المحادثة النموذجية على صمت بنسبة 35 إلى 50 في المئة. باستخدام اكتشاف نشاط الصوت (VAD)، يتم منع الحزم الصامتة. بالنسبة لتخطيط النطاق الترددي لبروتوكول VoIP، إفترض أن التصميم البصري (VAD) يعمل على تقليل النطاق الترددي بنسبة 35 بالمائة. يتم تكوين VAD بشكل افتراضي تحت نظائر طلب VoIP. لتمكين أو تعطيل VAD، أستخدم الأوامر Router(config-dial-peer)#vad وrouter(config-dial-peer)# no vad ضمن نظائر الطلب voip المطلوبة.

الرسم التخطيطي للشبكة

التكوينات

maui-voip-sj (Cisco 3640)

version 12.2service timestamps debug datetime msec

!-- < Some output omitted >

!

hostname maui-voip-sj

!

ip subnet-zero

!

no ip domain-lookup

!

!-- Definition of the voice signaling and traffic class maps !-- "voice-traffic" class uses access-list 102 for its matching criteria. !-- "voice-signaling" class uses access-list 103 for its matching criteria.

Class-map match-all voice-signaling

match access-group 103

class-map match-all voice-traffic

match access-group 102

!

!-- The policy-map defines how the link resources are assigned !-- to the different map classes. In this configuration, strict priority !-- queue is assigned to "voice-traffic" class with (based on ACL in !-- class voice) with max bandwidth = 45 Kbps.

policy-map VOICE-POLICY

class voice-traffic

priority 48

class voice-signaling

bandwidth 8

!-- Assigns a queue for "voice-signaling" traffic that ensures 8 Kbps. !-- Note that this is optional and has nothing to do with good voice !-- quality, but rather a way to secure signaling.

class class-default

fair-queue

!-- The class-default class is used to classify traffic that does !-- not fall into one of the defined classes. !-- The fair-queue command associates the default class WFQ queueing.

!

call rsvp-sync

!

!-- Note that MLPPP is strictly an LFI mechanism. It does not !-- bundle multiple serial interfaces to the same virtual interface as !-- the name stands (This bundling is done for data and NOT recommended !-- for voice). The end result may manifest itself as jitter and no audio.

interface Multilink1

ip address 172.22.130.1 255.255.255.252

ip tcp header-compression iphc-format

service-policy output VOICE-POLICY

!-- LLQ is an outbound operation and applied to the outbound WAN !-- interface.

no cdp enable

ppp multilink

ppp multilink fragment-delay 10

!-- The configured value of 10 sets the fragment size such that !-- all fragments have a 10 ms maximum serialization delay.

ppp multilink interleave

multilink-group 1

ip rtp header-compression iphc-format

!

interface Ethernet0/0

ip address 172.22.113.3 255.255.255.0

no keepalive

half-duplex

!

interface Serial0/0

bandwidth 128

!-- the bandwidth command needs to be set correctly for the !-- right fragment size to be calculated.

no ip address

encapsulation ppp

clockrate 128000

ppp multilink

multilink-group 1

!-- This command links the multilink interface to the physical !-- serial interface.

!

router eigrp 69

network 172.22.0.0

auto-summary

no eigrp log-neighbor-changes

!

!-- access-list 102 matches VoIP traffic based on the UDP port range. !-- Both odd and even ports are put into the PQ. !-- access-list 103 is used to match VoIP signaling protocol. In this !-- case, H.323 V2 with fast start feature is used.

access-list 102 permit udp any any range 16384 32767

access-list 103 permit tcp any eq 1720 any

access-list 103 permit tcp any any eq 1720

!

voice-port 1/0/0

!

voice-port 1/0/1

!

voice-port 1/1/0

!

voice-port 1/1/1

!

dial-peer cor custom

!

dial-peer voice 1 pots

destination-pattern 5000

port 1/0/0

!

dial-peer voice 2 voip

destination-pattern 6000

session target ipv4:172.22.130.2

MAUI-voip-austin (Cisco 3640)

version 12.2

service timestamps debug datetime msec

!

hostname maui-voip-austin

!

boot system flash slot1:c3640-is-mz.122-6a.bin

!

ip subnet-zero

!

class-map match-all voice-signaling

match access-group 103

class-map match-all voice-traffic

match access-group 102

!

policy-map voice-policy

class voice-signaling

bandwidth 8

class voice-traffic

priority 48

class class-default

fair-queue

!

interface Multilink1

bandwidth 128

ip address 172.22.130.2 255.255.255.252

ip tcp header-compression iphc-format

service-policy output voice-policy

no cdp enable

ppp multilink

ppp multilink fragment-delay 10

ppp multilink interleave

multilink-group 1

ip rtp header-compression iphc-format

!-- Configure cRTP after you have a working configuration. !-- This helps isolate potential cRTP issues.

!

Interface Ethernet0/0

ip address 172.22.112.3 255.255.255.0

no keepalive

half-duplex

!

interface Serial0/0

bandwidth 128

no ip address

encapsulation ppp

no ip mroute-cache

ppp multilink

multilink-group 1

!

router eigrp 69

network 172.22.0.0

auto-summary

no eigrp log-neighbor-changes

!

access-list 102 permit udp any any range 16384 32767

access-list 103 permit tcp any eq 1720 any

access-list 103 permit tcp any any eq 1720

!

voice-port 1/0/0

!

voice-port 1/0/1

!

voice-port 1/1/0

!

voice-port 1/1/1

!

dial-peer cor custom

!

dial-peer voice 1 pots

destination-pattern 6000

port 1/0/0

!

dial-peer voice 2 voip

destination-pattern 5000

session target ipv4:172.22.130.1

أوامر التحقق من الصحة واستكشاف الأخطاء وإصلاحها

قبل محاولة أي أوامر تصحيح أخطاء، ارجع إلى معلومات مهمة حول أوامر تصحيح الأخطاء. للحصول على مزيد من المعلومات حول الأوامر المدرجة هنا، راجع قسم نموذج العرض وتصحيح الأخطاء في هذا المستند.

أوامر الواجهة:

- عرض الواجهة [تسلسلي | multilink]—أستخدم هذا الأمر للتحقق من حالة الواجهة التسلسلية. تأكد من أن الواجهة التسلسلية والواجهة متعددة الارتباطات نشطة ومفتوحة.

- أستكشاف أخطاء الخطوط التسلسلية وإصلاحها

أوامر LFI:

- show ppp multilink— يعرض هذا الأمر معلومات الحزمة لمجموعات PPP متعددة الارتباطات.

- debug ppp multilink parts—يعرض أمر تصحيح الأخطاء هذا معلومات حول الأجزاء الفردية متعددة الارتباطات والأحداث المتداخلة. يحدد إخراج الأمر هذا أيضا الرقم التسلسلي للحزمة وأحجام الأجزاء.

أوامر أولوية LLQ/IP RTP:

- show policy-map interface multilink interface# — يكون هذا الأمر مفيدا جدا لعرض عملية LLQ ورؤية أي حالات إسقاط في PQ. لمزيد من المعلومات حول الحقول المختلفة لهذا الأمر، ارجع إلى فهم عدادات الحزم في إخراج واجهة show policy-map.

- show policy-map policy_map_name — يعرض هذا الأمر معلومات حول تكوين خريطة السياسة.

- show queue interface-type interface-number — يسرد هذا الأمر تكوين قوائم الانتظار العادلة والإحصائيات الخاصة بواجهة معينة.

- debug priority—يعرض أمر تصحيح الأخطاء هذا أحداث قائمة الانتظار ذات الأولوية ويظهر ما إذا كان الإسقاط يحدث في قائمة الانتظار هذه. ارجع أيضا إلى أستكشاف أخطاء الإخراج وإصلاحها باستخدام قائمة الانتظار ذات الأولوية.

- show class-map class_name — يعرض هذا الأمر معلومات حول تكوين خريطة الفئة.

- show call active voice—يعد هذا الأمر مفيدا للتحقق من الحزم المفقودة في مستوى DSP.

أوامر/مراجع أخرى:

- show ip rtp header-compression— يعرض هذا الأمر إحصائيات ضغط رأس RTP.

- أستكشاف أخطاء الاتصال عبر بروتوكول VoIP وإصلاحها وتصحيح أخطائها

- أوامر تصحيح أخطاء VoIP

المشكلات المعروفة:

- CSCds43465: "LLQ، Policy، Shaper ينبغي أن يأخذ CRTP ضغط الملاحظات" لعرض ملاحظات الإصدار، راجع Bug ToolKit (العملاء المسجلون فقط).

إرشادات:

فيما يلي بعض الخطوات الأساسية لاستكشاف الأخطاء وإصلاحها، بمجرد تشغيل إرتباط PPP (MLPPP، والتجزئة، والتداخل):

1. show call active voice — أستخدم للتحقق من الحزم المفقودة في مستوى DSP.

2. show interface— أستخدم للتحقق من وجود مشاكل عامة في الخط التسلسلي أو الواجهة. لا تعني عمليات الإسقاط على الواجهة مشكلة بعد، ولكن من المفضل إسقاط الحزمة من قائمة الانتظار ذات الأولوية المنخفضة قبل وصولها إلى قائمة انتظار الواجهة.

3. show policy-map interface—use للتحقق من تكوين عمليات إسقاط LLQ والانتظار. لا يجب الإبلاغ عن أي عمليات إسقاط تنتهك السياسة.

4. show ip rtp header-compression— أستخدم للتحقق من وجود مشاكل خاصة ب cRTP.

إخراج العرض والتصحيح للعينة

!----------------------------------------------- !-----------------------------------------------  !---- To capture sections of this output, the LLQ PQ bandwidth !---- was lowered and large data traffic was placed !---- on the link to force some packets drops. !----------------------------------------------- !----------------------------------------------- !---- Packet Drop Verification (During an Active Call) !--- Assuming your ppp link is up and running, the first step of voice !--- quality problems verification is to check for lost packets !--- at the DSP. Note: Use the show call active voice command !--- NOT show call active voice brief

maui-voip-austin#show call active voice

Total call-legs: 2

!--- Indicates that the connection is established and both legs exist

GENERIC:

SetupTime=155218260 ms

Index=1

PeerAddress=5000

PeerSubAddress=

PeerId=2

PeerIfIndex=13

LogicalIfIndex=0

ConnectTime=155218364

CallDuration=00:00:27

CallState=4

!--- indicates that it is the active call !--- (#define D_callActiveCallState_active 4).

CallOrigin=2

ChargedUnits=0

InfoType=2

TransmitPackets=365

TransmitBytes=7300

ReceivePackets=229

ReceiveBytes=4580

VOIP:

!--- For this call, this was the terminating gateway. !--- At this gateway, the call started at the VoIP leg.

ConnectionId[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]

IncomingConnectionId[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]

RemoteIPAddress=172.22.130.1

!--- Indicates from which IP address the RTP stream is originating.

RemoteUDPPort=18778

RemoteSignallingIPAddress=172.22.130.1

!--- Indicates from which IP address signaling messages are coming.

RemoteSignallingPort=11010

RemoteMediaIPAddress=172.22.130.1

RemoteMediaPort=18778

RoundTripDelay=50 ms

SelectedQoS=best-effort

tx_DtmfRelay=inband-voice

FastConnect=TRUE

Separate H245 Connection=FALSE

H245 Tunneling=FALSE

SessionProtocol=cisco

SessionTarget=

OnTimeRvPlayout=4570

GapFillWithSilence=20 ms

GapFillWithPrediction=1840 ms

GapFillWithInterpolation=0 ms

GapFillWithRedundancy=0 ms

HiWaterPlayoutDelay=70 ms

LoWaterPlayoutDelay=51 ms

ReceiveDelay=51 ms

LostPackets=90

EarlyPackets=1

LatePackets=0

!--- Indicates the precense of jitter, lost packets, or !--- corrupted packets.

VAD = enabled

CoderTypeRate=g729r8

CodecBytes=20

GENERIC:

SetupTime=155218260 ms

Index=2

PeerAddress=6000

PeerSubAddress=

PeerId=1

PeerIfIndex=12

LogicalIfIndex=6

ConnectTime=155218364

CallDuration=00:00:34

CallState=4

CallOrigin=1

ChargedUnits=0

InfoType=2

TransmitPackets=229

TransmitBytes=4580

ReceivePackets=365

ReceiveBytes=7300

TELE:

ConnectionId=[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]

IncomingConnectionId=[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]

TxDuration=35360 ms

VoiceTxDuration=730 ms

FaxTxDuration=0 ms

CoderTypeRate=g729r8

NoiseLevel=-46

ACOMLevel=2

OutSignalLevel=-58

InSignalLevel=-42

InfoActivity=2

ERLLevel=7

SessionTarget=

ImgPages=0Total call-legs: 2

!---------------------------------------------------------- !--- Interface Verification !--- Make sure you see this: !--- LCP Open, multilink Open: Link control protocol (LCP) open statement !--- indicates that the connection is establish. !--- Open:IPCP. Indicates that IP traffic can be transmitted via the PPP link.

maui-voip-sj#show interface multilink 1

Multilink1 is up, line protocol is up

Hardware is multilink group interface

Internet address is 172.22.130.1/30

MTU 1500 bytes, BW 128 Kbit, DLY 100000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation PPP, loopback not set

Keepalive set (10 sec)

DTR is pulsed for 2 seconds on reset

LCP Open, multilink Open

Open: IPCP

Last input 00:00:01, output never, output hang never

Last clearing of "show interface" counters 00:25:20

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 91

Queueing strategy: weighted fair

Output queue: 0/1000/64/37/383 (size/max total/threshold/drops/interleaves)

Conversations  0/3/32 (active/max active/max total)

Reserved Conversations 1/1 (allocated/max allocated)

Available Bandwidth 38 kilobits/sec

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

8217 packets input, 967680 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

13091 packets output, 1254194 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

----------------------------------------------------------------

!-- Note: There are no drops at the interface level. !-- All traffic that is dropped due to policing, is !-- dropped before it gets to the interface queue.

maui-voip-austin#show interface

serial 0/0Serial0/0 is up, line protocol is up

Hardware is QUICC Serial

MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec,

reliability 255/255, txload 49/255, rxload 47/255

Encapsulation PPP, loopback not set

Keepalive set (10 sec)

LCP Open, multilink Open

Last input 00:00:00, output 00:00:00, output hang never

Last clearing of "show interface" counters 00:22:08

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: weighted fair  [suspended, using FIFO]

FIFO output queue 0/40, 0 drops

5 minute input rate 24000 bits/sec, 20 packets/sec

5 minute output rate 25000 bits/sec, 20 packets/sec     4851 packets input, 668983 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

4586 packets output, 657902 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

!----------------------------------- !--- LLQ Verification

maui-voip-austin#show policy-map int multilink 1

Multilink1

Service-policy output: voice-policy

Class-map: voice-signaling (match-all)

!--- This is the class for the voice signaling traffic.

10 packets, 744 bytes

5 minute offered rate 0 BPS, drop rate 0 BPS

Match: access-group 103

Weighted Fair Queueing

Output Queue: Conversation 42

Bandwidth 8 (kbps) Max Threshold 64 (packets)

(pkts matched/bytes matched) 10/744

(depth/total drops/no-buffer drops) 0/0/0

Class-map: voice-traffic (match-all)

!--- This is PQ class for the voice traffic.

458 packets, 32064 bytes

5 minute offered rate 0 BPS, drop rate 0 BPS

Match: access-group 102

Weighted Fair Queueing

Strict Priority

Output Queue: Conversation 40

Bandwidth 15 (kbps) Burst 375 (Bytes)

!--- Notice that the PQ bandwidth was lowered to force packet drops.

(pkts matched/bytes matched) 458/29647

(total drops/bytes drops) 91/5890

!--- Some packets were dropped. In a well designed link,

!--- there should be no (or few) drops of the PQ class.

Class-map: class-default (match-any)

814 packets, 731341 bytes

5 minute offered rate 27000 BPS, drop rate 0 BPSMatch: any

Weighted Fair Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 32

(total queued/total drops/no-buffer drops) 0/0/0

!---------------------------------------------

!--- Verify the class-map configuration

maui-voip-austin#show class-map

Class Map match-all voice-signaling (id 2)

Match access-group  103

Class Map match-any class-default (id 0)

Match any

Class Map match-all voice-traffic(id 3)

Match access-group 102

!--- Verify the access-lists of the class-maps

maui-voip-austin#show access-lists

Extended IP access list 102

permit udp any any range 16384 32767 (34947 matches)

Extended IP access list 103

permit tcp any eq 1720 any (187 matches)

permit tcp any any eq 1720 (86 matches)

!--- Verify the policy-pap configuration

maui-voip-austin#show policy-map voice-policy

Policy Map voice-policy

Class voice-signaling

Weighted Fair Queueing

Bandwidth 8 (kbps) Max Threshold 64 (packets)

Class voice-traffic

Weighted Fair Queueing

Strict Priority

Bandwidth 50 (kbps) Burst 1250 (Bytes)

Class class-default

Weighted Fair Queueing

Flow based Fair Queueing Max Threshold 64 (packets)

---------------------------

!--- Debug priority command provides immediate feedback in case !--- of VoIP packet drops. !--- The output below shows the error message when VoIP packets !--- are being dropped from the strict priority queue.

maui-voip-sj#debug priority

priority output queueing debugging is on

maui-voip-sj#

Mar 17 19:47:09.947: WFQ: dropping a packet from the priority queue 0

Mar 17 19:47:09.967: WFQ: dropping a packet from the priority queue 0

Mar 17 19:47:09.987: WFQ: dropping a packet from the priority queue 0

-------------------------------------------------------------------

!--- Link Fragmentation and Interleaving (LFI) Verification

maui-voip-sj#show ppp multilink

!--- Verify the fragmentation size and multilink

Multilink1, bundle name is maui-voip-austin

Bundle up for 00:08:04

0 lost fragments, 0 reordered, 0 unassigned

0 discarded, 0 lost received, 1/255 load

0x6D received sequence, 0x6E sent sequence

Member links: 1 active, 0 inactive (max not set, min not set)

Serial0/0, since 00:08:09, last rcvd seq 00006C 160 weight

!--- Notice the fragmentation size is 160 Bytes. The link is configured with a !--- bandwidth of 128 kbps and a serialization delay of 10 msec. !--- Fragment Size (in bits) = bandwidth * serialization delay. !--- Note: There are 8 bits in one byte.

-------------------------------------------------------

!--- Link Fragmentation and Interleaving (LFI) Verification !--- Testing Multilink PPP Link LFI !--- This output displays fragmentation and interleaving information !--- when the the 128kbps PPP link is loaded with big data and VoIP packets.

maui-voip-sj#debug ppp multilink fragments

Multilink fragments debugging is on

1w3d: Se0/0 MLP: O frag 800004CF size 160

1w3d: Se0/0 MLP: O frag 000004D0 size 160

1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct

1w3d: Mu1 MLP: Packet interleaved from queue 40

1w3d: Se0/0 MLP: O ppp IP (0021) size 64

1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct

1w3d: Se0/0 MLP: O frag 400004D1 size 106

1w3d: Se0/0 MLP: O ppp IP (0021) size 64

1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct

1w3d: Se0/0 MLP: O ppp IP (0021) size 64 direct

1w3d: Se0/0 MLP: I frag 800004E0 size 160 direct

1w3d: Se0/0 MLP: I frag 000004E1 size 160 direct

1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct

-------------------------------------------------------------------

!--- Sample output of show ip rtp header-compression command

maui-voip-sj#show ip tcp header-compression

TCP/IP header compression statistics:  Interface Multilink1:

Rcvd:    10 total, 6 compressed, 0 errors

0 dropped, 0 buffer copies, 0 buffer failures

Sent:    10 total, 7 compressed,

230 bytes saved, 99 bytes sent

3.32 efficiency improvement factor

Connect: 16 rx slots, 16 tx slots,

2 long searches, 1 misses 0 collisions, 0 negative cache hits

90% hit ratio, five minute miss rate 0 misses/sec, 0 max

----------------------------------------------------------------------

!--- This command displays information of the voip dial-peers command.

maui-voip-sj#show dial-peer voice 2

VoiceOverIpPeer2

information type = voice,

tag = 2, destination-pattern = `6000',

answer-address = `', preference=0,

group = 2, Admin state is up, Operation state is up,

incoming called-number = `', connections/maximum = 0/unlimited,

application associated:

type = voip, session-tMarget = `ipv4:172.22.130.2',

technology prefix:

ip precedence = 0, UDP checksum = disabled,

session-protocol = cisco, req-qos = best-effort,

acc-qos = best-effort,

fax-rate = voice,   payload size =  20 bytes

codec = g729r8,   payload size =  20 bytes,

Expect factor = 10, Icpif = 30,signaling-type = cas,

VAD = enabled, Poor QOV Trap = disabled,

Connect Time = 283, Charged Units = 0,

Successful Calls = 1, Failed Calls = 0,

Accepted Calls = 1, Refused Calls = 0,

Last Disconnect Cause is "10  ",

Last Disconnect Text is "normal call clearing.",

Last Setup Time = 93793451.

-------------------------------------------------------------------------

!---The CPU utilization of the router should not exceed the 50-60 percent !--- during any five-minute interval.

maui-voip-austin#show processes cpu

CPU utilization for five seconds: 12%/8%; one minute: 11%; five minutes: 9%

PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process

1         148    310794          0  0.00%  0.00%  0.00%   0 Load Meter

2          76        23       3304  0.81%  0.07%  0.01%   0 Exec

معلومات ذات صلة

- قوائم انتظار المهلة المنخفضة

- نظرة عامة على إدارة الازدحام

- تنفيذ جودة الخدمة (QoS)

- استهلاك النطاق الترددي للصوت عبر IP - لكل مكالمة

- جودة الخدمة ل Voice عبر IP

- تكوين الصوت عبر IP

- دعم تقنية الصوت

- دعم منتجات الاتصالات الصوتية واتصالات IP

- استكشاف أخطاء خدمة IP الهاتفية من Cisco وإصلاحها

- الدعم الفني - Cisco Systems