تكوين مجموعة تصحيح الأخطاء للبوابات TDM و CUBE

المقدمة

يصف هذا المستند بعض أفضل الممارسات لجمع تصحيح أخطاء الصوت في موجه صوت Cisco IOS®/IOS XE®.

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

المتطلبات

• معرفة أساسية بموجهات الخدمات المتكاملة (ISR) من Cisco IOS/IOS XE.
• الوصول المميز من أجل تنفيذ الأوامر في موجهات ISR.
• التجربة السابقة مع بروتوكولات نقل الصوت عبر بروتوكول الإنترنت (VoIP) مطلوبة.
• بالنسبة ل VoIP Trace Cisco IOS XE 17.4.1 أو 17.3.2 مطلوب.

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

لأغراض هذا المستند، تكون المكونات المستخدمة هي:

• Cisco ISR 3925
• Cisco ISR 4451
• بوتي

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.

معلومات أساسية

تواجه عملية تجميع تصحيح الأخطاء في هذه الأنظمة الأساسية تحديات وقد تؤثر على أداء الجهاز. تزداد التحديات والمخاطر عندما توجد العديد من المكالمات النشطة التي تم إنشاؤها في موجه الصوت. في بعض السيناريوهات، إذا لم يتم تجميع تصحيح الأخطاء بشكل صحيح، فقد يؤدي ذلك إلى وحدة معالجة مركزية (CPU) عالية قد تضر بقدرة الموجه بل وتتسبب في تعطيل البرنامج. يتحدث هذا المستند عن الفرق بين عنصر حدود موحد (CUBE) من Cisco وبوابة تجميع (TDM)/تناظرية لتقسيم الوقت.

بوابات الصوت TDM مقابل CUBE

يتم إستخدام بوابات الصوت الخاصة بإدارة قاعدة بيانات المحول (TDM) بشكل رئيسي لتوصيل نظام هاتف داخلي مع برنامج Private Branch Exchange (PBX) آخر أو الشبكة الهاتفية المحولة العامة (PSTN). نوع الاتصالات التي يتم إستخدامها في بوابات TDM هي وحدات التحكم T1/E1 (ISDN أو CAS) والدوائر التناظرية مثل منافذ FXS و FXO. يقوم معالج الإشارة الرقمي (DSP) بتحويل الصوت من شكله الأولي إلى حزم RTP. وبطريقة مماثلة، يتم تحويل حزم RTP إلى صوت خام بعد أن يقوم DSP بمعالجة حزم RTP وإرسال الصوت على الدائرة المحددة. يمكن أن تعمل هذه البوابات مع H323 أو MGCP أو Skinny Call Control Protocol (SCCP) على جانب VoIP، وعلى جانب TDM إما الدوائر ISDN PRI أو التناظرية كأكثر الاتصالات شيوعا مع PSTN أو نقاط النهاية.

كما هو موضح في الصورة، توفر بوابات TDM جسرا بين البنية الأساسية الداخلية ل VoIP ومزودي الخدمة التناظرية أو ISDN:

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

وقد تم إدخال CUBE لتوفير طريقة لربط أنظمة الصوت عبر بروتوكول الإنترنت الداخلية تلك بالعالم الخارجي من خلال ITSPs مع إعتبار SIP بروتوكول الصوت عبر بروتوكول الإنترنت (VoIP) الأساسي. CUBE هو عبارة عن عبارة IP-IP حيث لم يعد يحتاج إلى أي نوع من اتصال TDM مثل وحدات التحكم T1/E1 أو المنافذ التناظرية. يتم تشغيل المكعب على نفس الأنظمة الأساسية مثل بوابات TDM.

بروتوكول VoIP الأكثر شيوعا المستخدم هو SIP، لإنشاء المكالمات وإنهائها، و RTP لنقل الوسائط. لا توجد حاجة في CUBE إلى DSP ما لم يكن هناك حاجة إلى جهاز إرسال/إستقبال. ينتهي تدفق حركة مرور RTP من ITSP إلى نقطة النهاية، ويعمل CUBE كالرجل الأوسط الذي له عنوان يخفي كواحدة من الميزات الكثيرة التي تقدمها.

كما هو موضح في الصورة، يوفر CUBE انقساما بين البنية الأساسية الداخلية ل VoIP و SIP ITSP:

مجموعة تصحيح أخطاء صوت Cisco IOS/IOS XE

تعمل الميزات الصوتية على قائمة مختلفة من الأنظمة الأساسية، مثل ISR و ASR و CAT8KS وغيرها؛ ومع ذلك، فهي تستخدم برنامجا مشتركا يكون إما Cisco IOS أو Cisco IOS XE (لا يتم تغطية الاختلافات بين Cisco IOS و Cisco IOS XE في هذه المقالة). هذه هي المبادئ الأساسية على كيفية الوصول إلى موجه Cisco IOS.

كيفية الوصول إلى موجه Cisco IOS/IOS XE عبر واجهة سطر الأوامر (CLI)

تتطلب الموجهات، مثل أي أجهزة أخرى تستند إلى واجهة سطر الأوامر، وجود شاشة طرفية للحصول على حق الوصول لتشغيل الأوامر من خلال طبقة الأمان (SSH) أو برنامج Telnet. SSH هو البروتوكول الأكثر شيوعا المستخدم في الوقت الحالي للوصول إلى الأجهزة المحددة. وهو يوفر اتصال آمن ومشفر بالجهاز. بعض شاشات المحطة الطرفية الشائعة المستخدمة للوصول إلى CLI الخاص بالموجهات هي:

كيفية تعيين جهاز العرض الطرفي لتجميع أوامر العرض أو تصحيح الأخطاء

هناك طرق مختلفة لجمع المخرجات من واجهة سطر الأوامر. تتمثل التوصية في تصدير المعلومات من واجهة سطر الأوامر (CLI) الخاصة بالموجه إلى ملف منفصل. وهذا يجعل من الأسهل تقاسم المعلومات مع أطراف خارجية.

هناك طريقتان لجمع المخرجات من الجهاز وهما:

• قم بتفريغ كافة المخرجات في المحطة الطرفية. تحتاج إلى التأكد من وجود خطوط كافية للتمرير إلى الخلف، وإلا، فإن التمرير إلى الخلف يفتقد الأقسام الأولى من الإخراج ويمكن أن تكون البيانات غير كاملة. لزيادة خطوط التمرير الخلفية في PuTTY، انتقل إلى PuTTY Configuration > نافذة > خطوط ScrollBack. بشكل طبيعي، يتم ضبط هذا إلى قيمة عالية جدا من أجل الحصول على ما يكفي من مخرجات تمرير للخلف:

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

• خيار آخر هو أن يقوم بتسجيل مخرجات الجلسة بأكملها إلى ملف .txt. باستخدام هذا الخيار، يتم تسجيل كل الأوامر التي تم إدخالها، والمخرجات التي تم تجميعها، على الفور في الملف النصي. هذه ممارسة شائعة لتسجيل كل المخرجات في جلسة عمل. لتسجيل كل مخرجات الجلسة إلى ملف في PuTTY، انتقل إلى PuTTY تشكيل > جلسة عمل > تسجيل الدخول ثم حدد كل مخرجات جلسة العمل كما يلي:

ملاحظة: يتم إستخدام اسم ملف السجل الافتراضي إذا لم يتم تحديد اسم آخر. انقر فوق الزر "إستعراض" لمعرفة مكان حفظ الملف بدقة للعثور عليه لاحقا. تأكد أيضا من عدم الكتابة فوق ملف ptty.log آخر في مسار الملف نفسه.

تجميع إخراج أمر العرض الأساسي من واجهة سطر الأوامر

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

بمجرد الاتصال بالموجه، يمكن تعيين طول المحطة الطرفية على 0. يمكن أن يؤدي ذلك إلى جعل المجموعة أسرع لعرض جميع المخرجات مرة واحدة، وتجنب إستخدام شريط المساحة. يكون الأمر الواحد الذي يجمع معلومات تفصيلية حول الموجه هو show tech، وبدلا من ذلك، يمكنك تجميع show tech voice الذي يعرض بيانات أكثر تحديدا لميزات الصوت الممكنة في الموجه:

Router# terminal length 0
Router# show tech
!or
Router# show tech voice
Router# terminal default length !This cmd restores the terminal length to default

تجميع إخراج تصحيح الأخطاء من واجهة سطر الأوامر

يمكن أن تكون مجموعة مخرجات تصحيح الأخطاء في Cisco IOS/IOS XE في بعض الأحيان تحديا نظرا لوجود خطر تعطل الموجه. ومع ذلك، يتم شرح بعض أفضل الممارسات في الأقسام التالية لتجنب أي قضايا.

فحص الذاكرة

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

قم بتشغيل الأمر show process memory لمعرفة مقدار الذاكرة التي يمكنك تخصيصها لتسجيل كل المخرجات في المخزن المؤقت:

تلميح: أستخدم الأمر terminal length default أو terminal length <num_lines> للعودة إلى مقدار محدود من الخطوط المعروضة في المحطة الطرفية.

Router# show process memory
Processor Pool Total: 8122836952 Used: 456568400 Free: 7666268552
lsmpi_io Pool Total: 6295128 Used: 6294296 Free: 832

في المثال، هناك 7666268552 بايت (7.6 جيجابايت) مجاني ليتم إستخدامه من قبل الموجه. تتم مشاركة هذه الذاكرة بواسطة الموجه بين جميع عمليات النظام. وهذا يعني أنه لا يمكنك إستخدام الذاكرة الحرة بالكامل لتسجيل المخرجات في المخزن المؤقت، ولكن يمكنك إستخدام مقدار كبير من ذاكرة النظام حسب الحاجة.

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

إذا كانت الذاكرة الحرة منخفضة، فمن المحتمل أن تكون هناك مشكلة في تسريب الذاكرة. إذا كان هذا هو الحال، فاشترك مع فريق TAC الخاص بالبنية لمراجعة ما يمكن أن يكون السبب في ضعف الذاكرة.

فحص وحدة المعالجة المركزية (CPU)

تتأثر وحدة المعالجة المركزية (CPU) بمقدار العمليات والميزات والاستدعاءات النشطة في النظام. كلما زاد نشاط الميزات أو المكالمات في النظام، زادت انشغال وحدة المعالجة المركزية.

تتمثل النقطة المرجعية الجيدة في التأكد من أن الموجه يحتوي على وحدة المعالجة المركزية (CPU) بنسبة 30٪ أو أقل، مما يعني أنه يمكنك تمكين تصحيح الأخطاء بأمان من المستويات الأساسية إلى المتقدمة (أحرص دائما على مراقبة وحدة المعالجة المركزية (CPU) عند إستخدام تصحيحات متقدمة). إذا كانت وحدة المعالجة المركزية للموجه تبلغ نسبة 50٪ تقريبا، يمكن تشغيل عمليات تصحيح الأخطاء الأساسية، ومراقبة وحدة المعالجة المركزية (CPU) بعناية. إذا وصلت وحدة المعالجة المركزية إلى نسبة أعلى من 80٪، فقم بإيقاف تصحيح الأخطاء على الفور (كما هو موضح لاحقا في هذه المقالة) وقم بتوجيه TAC للمساعدة.

أستخدم show process cpu التي تم فرزها | إستثناء الأمر 0.00 للتحقق من قيم وحدة المعالجة المركزية (CPU) الخمس و 60s و 5mins الأخيرة إلى جانب العمليات العليا.

Router# show processes cpu sorted | exclude 0.00
CPU utilization for five seconds: 1%/0%; one minute: 0%; five minutes: 0%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
211 4852758 228862580 21 0.15% 0.06% 0.07% 0 IPAM Manager
84 3410372 32046994 106 0.07% 0.04% 0.05% 0 IOSD ipc task
202 3856334 114790390 33 0.07% 0.05% 0.05% 0 VRRS Main thread

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

تحذير: امنح المزيد من الاهتمام للعمليات العليا لوحدة المعالجة المركزية (CPU) النشطة. إذا كانت وحدة المعالجة المركزية بنسبة 50٪ أو أعلى، وكانت العملية العليا هي عملية صوتية فقط، يمكن تمكين تصحيح الأخطاء الأساسية. مراقبة وحدة المعالجة المركزية باستمرار باستخدام الأمر لضمان عدم تأثر الأداء الإجمالي للموجه.

التحقق الحالي من المكالمات النشطة

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

أستخدم الأمر show call total-calls النشط للحصول على فكرة حول عدد المكالمات النشطة في النظام:

Router# show call active total-calls
Total Number of Active Calls : 0

أستخدم الأمر show call active voice summary للحصول على معلومات أكثر تفصيلا حول أنواع المكالمات المحددة النشطة:

Router# show call active voice summary
Telephony call-legs: 0
SIP call-legs: 0
H323 call-legs: 0
Call agent controlled call-legs: 0
SCCP call-legs: 0
STCAPP call-legs: 0
Multicast call-legs: 0
Total call-legs: 0

بعض القيم المشتركة هي:

• أجهزة الإتصال الهاتفية: مكالمات عبارة TDM، وهذا يتضمن مكالمات PRI/ISDN التناظرية
• نظام SIP للاتصال بالأرجل: إجمالي مكالمات SIP. إذا كان هذا هو موجه المكعب، فهذا يعرض أرجل اتصال لكل مكالمة. تقسيم إجمالي المكالمات المعروضة هنا على 2 للحصول على رقم دقيق
• ساق اتصال H323: إجمالي مكالمات H323
• أجهزة اتصال SCCP: موارد الوسائط التي يتم التحكم فيها بواسطة مدير الاتصالات الموحدة (CUCM) من Cisco المستخدمة في الموجه مثل Transcoder و MTPs

إعدادات المخزن المؤقت للتسجيل

لتكوين الموجه لتخزين إخراج تصحيح الأخطاء في المخزن المؤقت، يتم إدخال وضع تكوين المحطة الطرفية لضبط الإعدادات يدويا في واجهة سطر الأوامر. لا يؤثر هذا التكوين على الموجه، ومع ذلك، كما هو موضح في الأقسام السابقة، يلزم الأمر show tech أو show running-config من الموجه في حالة إحتياج التكوين إلى التراجع.

التالي مثال تكوين، وهو أساس مشترك مستخدم من قبل مهندسي TAC. يخصص المثال 10 ميجابايت من ذاكرة التخزين المؤقت ولكن يمكن زيادتها حسب الحاجة: 

# configure terminal
service timestamps debug datetime msec localtime show-timezone year
service timestamps log datetime msec localtime show-timezone year
service sequence-numbers
logging buffered 10000000
no logging console
no logging monitor
logging queue-limit 10000
logging rate-limit 10000
voice iec syslog

تنجز هذه الأوامر المهام التالية:

• تصحيح أو سجل الطوابع الزمنية للخدمة: يضمن كتابة وقت الموجه المحلي على كل رسالة تم تسجيلها، بدقة المللي ثانية. وهذا مفيد للعثور على المكالمات استنادا إلى الوقت. تتيح لك الطوابع الزمنية بالمللي ثانية تجميع خطوط تصحيح الأخطاء في أحداث منطقية ذات صلة عندما يقع سطران ضمن نفس المللي ثانية.
• أرقام تسلسل الخدمة: يكتب الرقم التسلسلي للتصحيح في السطر. وهذا مفيد (مطلوب أساسا) عند إعادة توجيه السجلات إلى خادم syslog. وهذا مفيد جدا لتحديد ما إذا كان قد تم إسقاط أي رسائل تصحيح أخطاء إلى خادم syslog في الشبكة. الرقم التسلسلي هو أول عنصر في تصحيح الأخطاء، قبل الطابع الزمني ورسالة السجل الفعلية. لاحظ أن هذا مختلف عن خوادم syslog للرقم التسلسلي/الطابع الزمني التي يمكن كتابتها محليا في ملفاتها.
• المخزن المؤقت للتسجيل: يطلب من الموجه إرسال تصحيح الأخطاء إلى ذاكرة المخزن المؤقت المحلية الخاصة به. تم تعيين حجم المخزن المؤقت بالبايت. في التكوين، تم تعيين حجم المخزن المؤقت على 10 ميجابت.
• لا توجد وحدة تحكم في التسجيل ولا مراقبة تسجيل: لا تتم طباعة أي رسائل سجل في وحدة التحكم أو جهاز العرض الطرفي. إذا لم يتم تكوين هذه الأوامر، فقد تكون ضارة بأداء الموجه ودقة إخراج تصحيح الأخطاء.
• بروتوكول Syslog لمعرف فئة المورد (IEC) الصوتي: تمكين رسائل رموز الأخطاء الداخلية الصوتية لتحديد أسباب قطع الاتصال.

تكوين إعدادات syslog

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

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

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

بشكل افتراضي، تستخدم خوادم syslog بروتوكول UDP كبروتوكول النقل على المنفذ 514.

#configure terminal
service timestamps debug datetime msec localtime show-timezone year
service timestamps log datetime msec localtime show-timezone year
service sequence-numbers

!Optional in case you still want to store debug output in the buffer.
logging buffered 10000000

no logging console
no logging monitor

logging trap debugging

!Replace the 192.168.1.2 with the actual Syslog Server IP Address
logging host 192.168.1.2 transport [tcp|udp] port 

ما إن شكلت الأمر، المسحاج تخديد فورا يرسل الرسالة إلى ال syslog نادل عنوان.

مجموعة تصحيح الأخطاء

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

Router# clear log
Clear logging buffer [confirm]
Router#

بعد إعادة إنشاء المشكلة، قم بتعطيل تصحيح الأخطاء فورا لإيقاف المزيد من المخرجات في المخزن المؤقت. بعد ذلك، قم بتجميع السجلات. أنت يستطيع تفريغ all the إنتاج في المحطة الطرفية مع الأمر:

Router# undebug all
Router# terminal length 0
Router# show log

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

Router# show log | redirect ftp://username:password@192.168.1.2/debugs.txt

ينسخ الأمر إخراج المخزن المؤقت بالكامل إلى FTP بعنوان IP 192.168.1.2 باستخدام اسم الملف debug.txt. يجب تحديد اسم الملف دائما. الوجهات الأخرى المتاحة لتصدير تلك البيانات هي:

Router# sh log | redirect ?
bootflash: Uniform Resource Locator
flash: Uniform Resource Locator
ftp: Uniform Resource Locator
harddisk: Uniform Resource Locator
http: Uniform Resource Locator
https: Uniform Resource Locator
nvram: Uniform Resource Locator
tftp: Uniform Resource Locator

ما هي عمليات تصحيح الأخطاء التي يمكن تمكينها في الموجهات الصوتية

يختلف كل تدفق مكالمات ونوع الميزات (موارد وسائط TDM أو CUBE أو SCCP)، وهناك أخطاء معينة يمكنك تمكينها. يجب تمكين جميع تصحيح الأخطاء المطلوبة في نفس الوقت. عندما يتم التقاط تصحيح واحد فقط في المرة الواحدة، يكون غير فعال، ويوفر المزيد من الارتباك عند تحليل البيانات.

يتم تمكين تصحيح الأخطاء داخل موجه أمر CLI EXEC من المستوى Router# الذي يتطلب أن يكون لديك أذونات وضع تنفيذ ذي امتيازات.

هناك تصحيح أخطاء أساسي ومتقدم. يتم إستخدام تصحيح الأخطاء الأساسية لجمع معلومات إرسال الإشارات إما في SIP أو H323 أو MGCP، والتي تظهر المحادثات التي يجريها الموجه مع الأجهزة النظيرة له.

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

تلميح: بعد تمكين تصحيح الأخطاء، تذكر أن تقوم بتشغيل الأمر clear logging . يضمن هذا الأمر مسح المخزن المؤقت من أجل التقاط أكثر نظافة للتصحيح.

تصحيح أخطاء واجهة برمجة التطبيقات (CCAPI) للتحكم في المكالمات الداخلية

وداخل كل موجه من موجهات Cisco IOS/IOS XE، هناك واجهة برمجة تطبيقات التحكم في المكالمات المسؤولة عن الاتصال بين تطبيقات VoIP المختلفة، أو البروتوكولات، ومكونات مستوى البيانات، مثل RTP و DSP وبطاقات الصوت، من بين أشياء أخرى. لالتقاط بيانات من هذه الطبقة، هناك تصحيح واحد محدد يمكن إستخدامه:

debug voip ccapi inout

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

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

تدفقات مكالمات SIP

تعد عمليات تصحيح الأخطاء هذه الأكثر إستخداما لتدفق مكالمات SIP، ويمكن تمكينها داخل بوابات CUBE و TDM باستخدام SIP Leg بين الموجه و CUCM أو أي خادم SIP أو وكيل آخر.

تصحيح أخطاء SIP الأساسية

debug ccsip messages
debug ccsip error
debug ccsip non-call !Optional, applies for SIP OPTIONS and SIP REGISTER Messages.

تصحيحات SIP المتقدمة

debug ccsip all
debug ccsip verbose
debug voice ccapi inout

تدفقات المكالمات الرقمية (PRI، BRI)

تنطبق هذه الأخطاء على interf المعدل الأولي (PRI) T1/E1 أو واجهات المعدل الأساسي (BRI):

تصحيح الأخطاء الرقمي الأساسي

debug isdn q931

تصحيح الأخطاء الرقمي المتقدم

debug isdn q921

تدفقات المكالمات التناظرية

يتم إستخدام هذه الأخطاء عند وجود دوائر تناظرية معنية مثل منافذ المشترك في eXchange الخارجية (FXS) أو منافذ FXO الخارجية في Office:

debug vpm signal
debug voip vtsp all

تدفقات مكالمات MGCP

يتم إستخدام هذه الأخطاء عند إستخدام MGCP كبروتوكول الصوت بين عبارة الصوت و CUCM.

تصحيح الأخطاء الأساسي

debug mgcp packets
debug mgcp errors

تصحيح أخطاء CCM-Manager

يتم إستخدام تصحيح الأخطاء CCM-manager لتعقب تنزيل التكوين، ورسائل نقل حركة شبكة MoH و PRI/BRI بين CUCM وبوابة الصوت. يتم إستخدام هذه الأخطاء على أساس الحاجة وتعتمد على سيناريو الفشل.

debug ccm-manager backhaul !For PRI and BRI Deployments
debug ccm-manager errors
debug ccm-manager events
debug ccm-manager config-download !Troubleshoot Configuration download issues from CUCM TFTP
debug ccm-mananger music-on-hold !Troubleshoot internal MoH Process

تصحيح أخطاء MGCP المتقدمة

debug mgcp all

تدفق مكالمات H323

على الرغم من أن الطراز H323 غير مستخدم على نطاق واسع، إلا أنه لا تزال هناك بعض عمليات النشر التي تم تكوين الطراز H323 بها:

تصحيح أخطاء H323 الأساسية

debug h225 asn1
debug h245 asn1
debug h225 events
debug h245 events

عمليات تصحيح أخطاء H323 المتقدمة

debug cch323 h225
debug cch323 h245
debug cch323 all

موارد وسائط SCCP

يتم إستخدام عمليات تصحيح الأخطاء هذه لاستكشاف أخطاء موارد وسائط SCCP وإصلاحها والتي تتضمن نقطة نهاية الوسائط (MTP) أو المحولات المسجلة إلى خادم CUCM:

تصحيح أخطاء SCCP الأساسية

debug sccp messages
debug sccp events
debug sccp errors

تصحيح أخطاء SCCP المتقدم

debug sccp all

تتبع بروتوكول VoIP

مع إدخال Cisco IOS XE 17.4.1 و 17.3.2، هناك خيار جديد لالتقاط سجلات الصوت داخل عنصر الحدود الموحدة (CUBE) من Cisco. تسمى هذه الميزة الجديدة تتبع VoIP. هذا إطار عمل خدمة جديد تم إنشاؤه لتسجيل إشارات SIP والأحداث دون الحاجة إلى تمكين أي تصحيح أخطاء. 

يتم تمكين تتبع بروتوكول VoIP بشكل افتراضي ويمكن تعطيله في أي وقت حسب الحاجة. يلتقط تتبع VoIP معلومات محددة لمكالمات SIP فقط:

• رسائل SIP لمكالمات خط اتصال SIP إلى خط الاتصال
• الأحداث واستدعاءات API من طبقة SIP إلى طبقات أخرى في CUBE
• أخطاء SIP
• التحكم في المكالمات (تدفقات مكالمات الاتصالات الموحدة التي تتم معالجتها بواسطة CUBE)
• حالات وأحداث أجهزة الحالة المحدودة (FSM)
• نظير الطلب المتطابق
• منافذ RTP المخصصة
• إرتباط أخطاء IEC بإشارات SIP

قيود

لا يقوم تتبع بروتوكول VoIP بتسجيل المعلومات المتعلقة برسائل SIP خارج مربع الحوار:

• التسجيل
• خيارات
• الاشتراك/الإعلام
• معلومات

يتم دعم تتبع بروتوكول VoIP في HA، ومع ذلك، يتم تطبيق هذه التنبيهات:

• يحتوي الموجه الاحتياطي على تتبع VoIP ممكن بشكل افتراضي. يتم عرض المسارات القابلة للتطبيق فقط لعملية الاستعداد حتى تصبح نشطة.
• بمجرد أن تكون "الاستعداد" نشطة، لا تحتوي على تتبع كامل من المكالمات المحددة، ولا تحتوي إلا على مكالمات جديدة.
• لا يزال show voip trace <key>يعمل على الموجه الاحتياطي ويعرض بيانات تغطية المخزن المؤقت ودفق الوسائط للمكالمات.

كيفية تمكين تتبع الصوت عبر بروتوكول الإنترنت (VoIP)

وكما ذكرنا، يتم تمكين هذه الميزة بشكل افتراضي. الأمر لتمكين هذه الميزة هو:

Router# configuration terminal
Router(config)# voice service voip
Router(conf-voi-serv)# trace
Router(conf-serv-trace)#

كيفية تعطيل تتبع الصوت عبر بروتوكول الإنترنت (VoIP)

لتعطيل هذه الميزة، تكون الأوامر:

Router(conf-serv-trace)# no trace
!or
Router(conf-serv-trace)# shutdown

تحذير: بعد تعطيل تتبع VoIP، يتم مسح جميع الذاكرة وفقدان المعلومات.

الأوامر المتوفرة داخل وضع تكوين التتبع هي:

Router(conf-serv-trace)# ?
default       Set a command to its defaults
  exit          Exit from voice service voip trace mode
  memory-limit  Set limit based on memory used
  no            Negate a command or set its defaults
  shutdown      Shut Voip Trace debugging

تكوين حد الذاكرة

يحدد حد الذاكرة مقدار الذاكرة المستخدمة بواسطة تتبع VoIP لتخزين البيانات. بشكل افتراضي، تكون 10٪ من الذاكرة المتوفرة في النظام الأساسي، ولكن يمكن تغيير هذا إلى الحد الأقصى 1 جيجابايت والحد الأدنى 10 ميجابايت. يتم تخصيص الذاكرة بشكل ديناميكي، مما يعني أن الميزة تستخدم الذاكرة فقط حسب الحاجة وتعتمد على وحدة تخزين المكالمات. بمجرد أن تصل إلى الحد الأقصى للذاكرة المتاحة، فإنها تقوم بالدوران حول وحذف المدخلات القديمة.

عندما يتم تعديل حد الذاكرة لتكون أكبر من الذاكرة المتوفرة بنسبة 10٪، يتم عرض رسالة في واجهة سطر الأوامر:

Router(conf-serv-trace)# memory-limit 1000
Warning: Setting memory limit more than 10% of available platform memory (166 MB) will affect system performance.

لتعيين الافتراضي على إستخدام ذاكرة بنسبة 10٪، يمكن إستخدام الأمر memory-limit platform :

Router(conf-serv-trace)# memory-limit platform
 Reducing the memory-limit clears all VoIP Trace statistics and data.
 If you wish to copy this data first, enter 'no' to cancel,
 otherwise enter 'yes' to proceed. Continue? [no]: 

تحذير: عند تقليل حد الذاكرة، يتم فقد جميع بيانات تتبع بروتوكول VoIP. يجب تجميع نسخة إحتياطية من البيانات قبل خفض الذاكرة.

كيفية عرض بيانات تتبع بروتوكول VoIP

لعرض البيانات من تتبع VoIP، يلزمك إستخدام أوامر show معينة. يمكن عرض البيانات في جلسة عمل المحطة الطرفية نفسها أو يمكن أيضا إرسالها عبر syslog إلى خادم syslog خارج المربع.

ملاحظة: يتم تفريغ الآثار بعد 32 ثانية من وقت تلقي "وداعا" لإجراء مكالمة.

ملاحظة: يتم عرض إرسال إشارات SIP لكل ساق، ولا يتم دمجها مثل تصحيح الأخطاء العادية. عمليات تصحيح الأخطاء العادية مثل رسائل CCSIP، قم بعرض إشارات SIP لمكالمة بالترتيب الدقيق لوقوع الأحداث. في تتبع بروتوكول VoIP، تكون كل ساق منفصلة. لتحديد الترتيب الصحيح، يتم إستخدام الطوابع الزمنية.

الأوامر المتوفرة لإظهار البيانات هي:

Router# show voip trace ?
  all            Display all VoIP Traces
  call-id        Filter traces based on Internal Call Id
  correlator     Filter traces based on FPI Correlator
  cover-buffers  Display the summary of all cover buffers
  session-id     Filter traces based on SIP Session ID
  sip-call-id    Filter traces based on SIP Call Id
  statistics     Display statistics for VoIP Trace

إظهار تتبع VoIP الكل

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

Router# show voip trace all
 Displaying 11858 cover buffers
 This may severely impact system performance.
 Continue? [yes/no] no 

إظهار مخازن الغطاء المؤقتة لتتبع بروتوكول VoIP

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

Router# show voip trace cover-buffers
------------------ Cover Buffer ---------------
Search-key = 8845:3002:659
Timestamp = *Sep 30 01:17:33.615
Buffer-Id = 1
CallID = 659
Peer-CallID = 661
Correlator = 4
Called-Number = 3002
Calling-Number = 8845
SIP CallID = 20857880-1ec12085-13b930-411b300a@10.48.27.65
SIP Session ID = 2b1289c400105000a0002c3ecf872659
GUID = 208578800000
-----------------------------------------------

------------------ Cover Buffer ---------------
Search-key = 8845:3002:661
Timestamp = *Sep 30 01:17:33.634
Buffer-Id = 2
CallID = 661
Peer-CallID = 659
Correlator = 4
Called-Number = 3002
Calling-Number = 8845
SIP CallID = 8D6DEC28-1F111EB-829FD797-1B22F6DB@10.48.55.11
SIP Session ID = 0927767800105000a0005006ab805584
GUID = 208578800000
-----------------------------------------------

لمزيد من المعلومات حول كل حقل، ارجع إلى الجدول التالي:

لتصفية المخازن المؤقتة للغطاء، يمكنك إستخدام أوامر include وsection:

Router# show voip trace cover-buffers | include Search-key | 8845 | 3002
Search-key = 8845:3002:661
!or
Router# show voip trace cover-buffers | section Search-key | 8845 | 3002
Search-key = 8845:3002:661

إظهار معرف الاستدعاء لتتبع بروتوكول VoIP

بالجمع مع مع الأمر السابق، يمكن إستخدام show voIP trace call-id للعثور على المكالمات. بعد تحديد معرف المكالمة، يمكن إستخدام هذا الأمر لعرض جميع المعلومات حول جهة الاتصال المحددة:

Router# show voip trace cover-buffers | include Search-key | 8845 | 3002
Search-key = 8845:3002:661
Router# show voip trace call-id 661

إظهار إحصائيات تتبع بروتوكول VoIP

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

Router# show voip trace statistics
VoIP Trace Statistics
Tracing status             : ENABLED at *Sep 12 06:44:02.349
Memory limit configured    : 803209216 bytes
Memory consumed            : 254550928 bytes (31%)
Total call legs dumped     : 2
Oldest trace dumped        : *Sep 12 07:29:21.077 Search-key: 9898:30000:64
Latest trace dumped        : *Sep 12 07:29:21.010 Search-key: 9898:30000:63
Total call legs captured   : 11858
Total call legs available  : 11858
Oldest trace available     : *Sep 12 06:57:23.923, Search-key: 5250001:4720001:11
Latest trace available     : *Sep 13 05:08:25.353, Search-key: 19074502232:30000:13177
Total traces missed        : 0

لمزيد من المعلومات حول كل حقل، راجع الجدول التالي:

أوامر show الإضافية