أستكشاف أخطاء إلغاء تسجيل هاتف IP وإصلاحها - دراسة حالة

المقدمة

يصف هذا المستند المعلومات التي يمكن إستخدامها لاستكشاف أخطاء التكوين وإصلاحها.

يستخدم هاتف Cisco IP آلية الإبقاء على قيد الحياة على مستوى التطبيق بالإضافة إلى آلية TCP للاحتفاظ على قيد الحياة على مستوى الشبكة. تضمن آلية Keep-Live لأجهزة بروتوكول التحكم في المكالمات Skinny (SCCP) وبروتوكول بدء الجلسات (SIP) إستمرار تسجيل الجهاز باستخدام التحكم في المكالمات. كما تهدف إلى إعادة إنشاء اتصال للأجهزة باستخدام ميزة التحكم في المكالمات.

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

المتطلبات

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

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

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

آلية الاحتفاظ بالأعطال والتغلب على الأعطال في SCCP

يستخدم SCCP بروتوكول TCP للنقل ويستخدم المنفذ 2000 و 2443 (للتأمين) لإجراء اتصال بمدير المكالمات. يجب أن تقوم هواتف SCCP بإجراء اتصال TCP مع مدير الاتصالات الموحدة (CUCM) من Cisco قبل التسجيل إليه. وبعد ذلك، ستتم مصافحة بطريقة TCP 3 على المنفذ 2000 لإنشاء قناة اتصال. يقوم الهاتف ببدء هذا الاتصال بإرسال SYN (مزامنة) إلى CUCM ويستجيب CUCM باستخدام SYN، ACK (إقرار). يستجيب الهاتف بدوره مع ACK ويتم إنشاء اتصال TCP.

أبق

هناك طريقتان للبقاء على قيد الحياة: مستوى التطبيق (الحفاظ على الحياة النحيف) ومستوى الشبكة (TCP الحفاظ على الحياة)

تجاوز الفشل

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

يستجيب CUCM الرئيسي باستخدام SCCP Keepalive ACK الذي يعترف بكل من اتصال SCCP و TCP. يرسل CUCM الاحتياطي فقط TCP ACK إلى "البقاء على قيد الحياة" الذي تم إرساله عبر الهاتف. عندما يفشل الهاتف في النسخ الاحتياطي ل CUCM لأن خدمة إدارة المكالمات غير متوفرة أو لأن اتصال TCP نفسه غير متوفر مع CUCM الأساسي، فإنه يستخدم نوعين من الآليات للكشف عن فشل CM الأساسي وهم طبيعيون ومتأخرون.

تجاوز الفشل العادي

تستخدم هذه الطريقة خوارزمية لحساب متوسط الوقت الذي تستغرقه CUCM للإقرار بفترات الحجز السابقة.

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

تجاوز الفشل المتأخر

في هذه الآلية، ينتظر الهاتف الفواصل الزمنية الثلاثة لتكتشف فشل CUCM الأساسي.

عائق

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

مثال لتقلب وقت العبور (لاحظ التأخير الزمني لاستجابة إختبار الاتصال):

64 bytes from 10.106.97.150: icmp_seq=1 ttl=63 time=0.100 ms
64 bytes from 10.106.97.150: icmp_seq=2 ttl=63 time=200 ms
64 bytes from 10.106.97.150: icmp_seq=3 ttl=63 time=0.180 ms
64 bytes from 10.106.97.150: icmp_seq=4 ttl=63 time=0.678 ms
64 bytes from 10.106.97.150: icmp_seq=5 ttl=63 time=590 ms
64 bytes from 10.106.97.150: icmp_seq=6 ttl=63 time=0.100 ms
64 bytes from 10.106.97.150: icmp_seq=7 ttl=63 time=345 ms
64 bytes from 10.106.97.150: icmp_seq=8 ttl=63 time=456 ms
64 bytes from 10.106.97.150: icmp_seq=9 ttl=63 time=0.345 ms

[an error occurred while processing this directive]

الميزة

يمكن إستخدام هذه الآلية في الشبكات الحساسة للتأخير.

  

SIP Keep-Alive

يقوم هاتف SIP بالتسجيل إلى CUCM ويرسل رسائل حية كل 120 ثانية وفقا للإعدادات في CUCM. عندما يرسل الهاتف السجل الأولي إلى CUCM الأساسي، فإنه يضبط مؤقت انتهاء الصلاحية إلى 3600 ثاني (المجموعة الافتراضية في ملف تعريف SIP المطبق على الهاتف). يرسل CUCM ACK عن طريق تعديل المؤقت إلى 120 ثانية حسب القيمة المعينة في معلمة الخدمة.

لذلك، يرسل الهاتف رسائل إبقاء حية كل 120 ثانية (في الواقع 115 ثانية أي 120 ناقص قيمة دلتا المكونة في ملف تعريف SIP، أي 5 ثوان بشكل افتراضي). في هذه الحالة، يرسل الهاتف إبقاء على قيد الحياة كل 115 ثانية.

يقوم هاتف SIP بتبادل رسالة السجل إلى نسخ CUCM إحتياطيا مع تعيين حقل انتهاء الصلاحية على 0.

إلى أساسي

REGISTER sip:10.106.114.161 SIP/2.0

Via: SIP/2.0/TCP 10.106.114.185:53006;branch=z9hG4bKd451a4fa

From: <sip:5678@10.106.114.161>;tag=0024142ddf242c6644b6e5d2-f01c795a

To: <sip:5678@10.106.114.161>

Call-ID: 0024142d-df24000a-44da4e09-0de51424@10.106.114.185

Max-Forwards: 70

Date: Wed, 15 Jul 2015 12:42:56 GMT

CSeq: 11435 REGISTER

User-Agent: Cisco-CP7975G/9.3.1

Contact: <sip:9e9e1ffb-0206-4ea1-6d77-ba04a72017f7@10.106.114.185:53006;transport=tcp>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0024142ddf24>";+u.sip!devicename.ccm.cisco.com="SEP0024142DDF24";+u.sip!model.ccm.cisco.com="437"

Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-6.0.0,X-cisco-xsi-8.5.1

Content-Length: 0

Expires: 3600



SIP/2.0 100 Trying

Via: SIP/2.0/TCP 10.106.114.185:53006;branch=z9hG4bKd451a4fa

From: <sip:5678@10.106.114.161>;tag=0024142ddf242c6644b6e5d2-f01c795a

To: <sip:5678@10.106.114.161>

Date: Wed, 15 Jul 2015 12:42:59 GMT

Call-ID: 0024142d-df24000a-44da4e09-0de51424@10.106.114.185

CSeq: 11435 REGISTER

Content-Length: 0



SIP/2.0 200 OK

Via: SIP/2.0/TCP 10.106.114.185:53006;branch=z9hG4bKd451a4fa

From: <sip:5678@10.106.114.161>;tag=0024142ddf242c6644b6e5d2-f01c795a

To: <sip:5678@10.106.114.161>;tag=1708299782

Date: Wed, 15 Jul 2015 12:42:59 GMT

Call-ID: 0024142d-df24000a-44da4e09-0de51424@10.106.114.185

CSeq: 11435 REGISTER

Expires: 120

Contact: <sip:9e9e1ffb-0206-4ea1-6d77-ba04a72017f7@10.106.114.185:53006;transport=tcp>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0024142ddf24>";+u.sip!devicename.ccm.cisco.com="SEP0024142DDF24";+u.sip!model.ccm.cisco.com="437"

Supported: X-cisco-srtp-fallback,X-cisco-sis-6.0.0

Content-Length: 0

[an error occurred while processing this directive]

إلى الثانوي

REGISTER sip:10.60.1.12:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.60.63.21:3784;rport;branch=z9hG4bKPjdcJ819aZtTCtmvr0VBheV6p0uL8aC.pG

Max-Forwards: 70

From: <sip:6836@10.60.1.12>;tag=5oI-ew53.DGjTDu5LB9orkdDpZlccNbv

To: <sip:6836@10.60.1.12>

Call-ID: HxTK.m6BH9qxjstVwexTbhVnUxNeuxle

CSeq: 18800 REGISTER

Expires: 0

Contact: <sip:e2b0f175-feae-d664-befa-b7cd0837fcc6@10.60.63.21:5060;transport=TCP>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-e0d1730ac1b1>";+u.sip!devicename.ccm.cisco.com="SEPE0D1730AC1B1";+u.sip!model.ccm.cisco.com="592";expires=0;cisco-keep-alive

Content-Length:  0

[an error occurred while processing this directive]

السجلات المطلوبة

من أجل تحديد سبب إلغاء تسجيل الهاتف، قم بجمع المعلومات الموضحة:

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

• يساعد التقاط الحزمة من الهاتف و CUCM (كلا من الأساسي والنسخ الاحتياطي) في نفس الوقت في عزل منظور شبكة المشكلة.

• مسارات Cisco Call Manager.

روابط ذات صلة

تجميع حزم من CUCM

تجميع التقاط من هاتف بروتوكول الإنترنت

تجميع مسارات CUCM

تحليل السجلات وملحقات الحزم

• يطبع سجل تطبيق عارض الأحداث رسالة EndPointUnregistered وكذلك رموز أسباب ذات صلة.

Example: 31 uc-ucm-01 local7 3 : 41679: uc-ucm-01.pcce.local Jul 02 2015 06:22:31 UTC :   %UC_CALLMANAGER-3-EndPointUnregistered: %[DeviceName=SEPE0D1730A8137][IPAddress=10.60.98.210][Protocol=SIP][DeviceType=592][Description=Phone][Reason=13][IPAddrAttributes=0][LastSignalReceived=SIPStationDPrimaryLineTimeout][AppID=Cisco CallManager][ClusterID=StandAloneCluster][NodeID=uc-ucm-01]: An endpoint has unregistered

[an error occurred while processing this directive]

يمكن العثور على رموز السبب ل EndPointUnregister في وثائق رسائل خطأ النظام.

قراءة سجلات Wireshark

عندما يتم تجميع التقاط من كلا الطرفين، للتحقق من أن رسائل تنشيط الاتصال المرسلة عبر الهاتف تصل بالفعل إلى CUCM أو لا.

سيساعد الرقم التسلسلي لحزمة TCP بسهولة على تعقب حركة مرور TCP بين الهاتف و CUCM في التقاط sniffer.

التقاط من الهاتف

يرسل الهاتف حزمة برقم تسلسلي 2991996107، تحقق من أن هذه الحزمة تصل إلى CUCM.

التقاط من CUCM

يجب رؤية الرقم التسلسلي الذي يظهر في التقاط sniffer للهاتف في التقاط CUCM.

دراسة حالة إفرادية 1-2

وصف المشكلة

تستمر هواتف SCCP في إعادة التشغيل على فواصل زمنية منتظمة.

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

يشير سجل تطبيق "عارض الأحداث" إلى أن الهواتف إستمرت في إعادة التشغيل بسبب عدم وجود أسماء مستعارة مع رمز خطأ 13.

Event Viewer Message.

[an error occurred while processing this directive]

تجميع التقاط الحزم من هاتف IP و CUCM.  في هذا السيناريو، لم تصل آخر مرة تم إرسالها من هاتف IP إلى CUCM.

Image.

[an error occurred while processing this directive]

الحفاظ على الحياة يسقط بسبب هذا السبب:

عندما أرسل الهاتف ARP للحصول على عنوان MAC ل CUCM، جاءت الاستجابة من وكيل ARP مع عنوان ASA MAC. ومن الواضح أن الاستجابة الأولى لم تكن من إدارة الاتصالات المختلطة. ومع ذلك، فنظرا لأن الهاتف يستلمه أولا، فإنه يرسل الإطار إلى المحول باستخدام عنوان MAC الخاص بالجهاز الآخر.

يحدث هذا غالبا عندما يتم تمكين وكيل ARP على ASA.

قرار

قم بتعطيل وكيل ARP على ASA لمعالجة المشكلة.

دراسة حالة 2.

وصف المشكلة

إعادة ضبط هواتف Cisco IP طراز 8961 كل 16 دقيقة والسجلات إلى CUCM الثانوي. بعد دقيقتين يعود الهاتف إلى CUCM الأساسي وتستمر هذه الدورة.

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

قم بتجميع التقاط الحزم من هواتف عمليات تتبع CUCM. يرجع إلغاء التسجيل إلى عدم تمكن هاتف بروتوكول الإنترنت (IP) من البقاء على قيد الحياة.

تحليل

يسجل هاتف SIP إلى CUCM ويرسل CUCM كل 120 ثانية حسب الإعدادات في CUCM.

عندما يرسل الهاتف السجل الأولي فإنه يضبط وقت انتهاء الصلاحية إلى 3600 ثانية (المجموعة الافتراضية في ملف تعريف SIP المطبق على الهاتف). يتعرف CUCM عليه من خلال تعديل المؤقت إلى 120 ثانية وفقا للقيمة المحددة في معلمة الخدمة.

يرسل الهاتف Keepalive كل 120 ثانية ( الفاصل الزمني للبقاء على قيد الحياة هو 115 ثانية أي 120 ناقص قيمة دلتا المكونة في ملف تعريف SIP، أي 5 ثوان بشكل افتراضي). في هذه الحالة يرسل الهاتف keepalive كل 115 ثانية.

في سيناريو هذه المشكلة يرسل الهاتف أول رسالة تنشيط في 115 ثانية ويتم إسقاطه في الشبكة. وينتج عن ذلك إرسال رسالة تنشيط الاتصال عبر الهاتف في 0.01 ثانية (100 مللي ثانية). ويحصل على إستجابة من CUCM لطلب التسجيل.

الآن يرسل الهاتف رسالة تنشيط ثانية في 115 ثانية ويتم إسقاطه في الشبكة. يزيد الهاتف الآن من الفاصل الزمني لإعادة محاولة التسجيل الخاص به إلى 0.02 ثانية (200 مللي ثانية).

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

يرسل الهاتف بعد 14 ثانية ويحصل على أكلة من ال CUCM.

في المرة التالية التي يرسل فيها الهاتف "إبقاء على قيد الحياة"، يتم فقدانه ثم يرسل الهاتف طلب "تسجيل" بعد 28 ثانية. يتعذر على CUCM الانتظار لمدة 28 ثانية، ولكنه ينتظر لمدة 15 ثانية فقط (بعد 115s) ثم يرسل إشارة إلغاء التسجيل.

يبلغ وقت البقاء على قيد الحياة و RTO ما يصل إلى 16 دقيقة وبضعة ثوان.

بعد 16 دقيقة بسبب إشارة عدم التسجيل من CUCM، يتم تسجيل الهواتف في CUCM الثانوي، وبعد دقيقتين يتم تسجيلهم في الأساسي، ويستمر هذا الأمر.

سبب الهبوط المستمر

عندما شكلت المفتاح ميناء كان مع أمن أيسر، الميناء شيخوخة شكلت مع مؤقت غير نشط. تم تعيين وحدة التوقيت على دقيقة واحدة وهي أقل من مؤقت SIP Keep-Alive. وقد أدى ذلك إلى قيام منفذ المحول بإفراغ MAC للهاتف كل دقيقة. يستمر إسقاط الحزم حيث تكون فترة الاحتفاظ بالحزم ل SIP كل دقيقتين.