عند صيانة هاتف SIP مقاوم للانفجار، فإن استجابة 200 OK لمعاملة REGISTER تؤكد فقط أن الطرفية أنشأت بنجاح ارتباط عنوان موثّق مع خادم التسجيل. ولا تضمن إمكانية توجيه INVITE بصورة صحيحة، أو قدرة SDP على التفاوض على برنامج ترميز متوافق، أو مرور وسائط RTP في الاتجاهين بين الهاتف المقاوم للانفجار والطرف البعيد. بعبارة أخرى، تصف حالة «مسجل» جزءاً واحداً فقط من إمكانية الوصول على مستوى تحكم SIP، وليس القدرة الكاملة على إجراء مكالمة من طرف إلى طرف.
ولهذا قد يظهر الهاتف المقاوم للانفجار مسجلاً بصورة سليمة ومع ذلك لا يرن، أو يتصل من دون صوت، أو يوفر صوتاً في اتجاه واحد فقط، أو يفصل فور الرد. وفي كثير من الحالات لا يكون خادم التسجيل هو مصدر العطل الحقيقي. بل تكون المشكلة في مسار الإشارات أو مسار الوسائط أو سلسلة الصوت المحلية التي تأتي بعد التسجيل. ويحوّل التشخيص عبر ثلاث طبقات — الإشارات والوسائط وصوت الطرفية — شكوى عامة مثل «مسجل لكنه لا يستطيع الاتصال» إلى مراحل يمكن اختبار كل منها بصورة مستقلة، ويمنع تكرار إعادة تشغيل الجهاز في اتجاه تشخيصي غير صحيح.
لماذا لا تعني حالة «مسجل» أن الهاتف يستطيع إجراء المكالمات بالتأكيد؟
ابدأ بفهم ما الذي ينجزه التسجيل فعلياً. يتضمن طلب REGISTER الذي ترسله الطرفية عادةً عدة حقول مهمة: Request-URI الذي يحدد نطاق التسجيل؛ وTo الذي يمثل الحساب الجاري تسجيله، أو Address-of-Record (AOR)؛ وContact الذي يحدد عنوان الوصول الحالي للطرفية، وغالباً ما يكون عنوان IP ومنفذاً؛ وExpires الذي يحدد مدة صلاحية التسجيل.
التسجيل ليس عملية تحدث مرة واحدة. تحتفظ المنصة في خدمة تحديد الموقع بعلاقة تشير إلى أن AOR معيناً يمكن الوصول إليه حالياً من خلال Contact محدد. ولهذا الارتباط مدة انتهاء، وغالباً ما تُضبط على نحو ساعة. ويجب على الطرفية تجديد التسجيل قبل انتهاء المدة، وإلا فقد تعتبر المنصة ذلك الامتداد غير متصل بعد فترة.
تتم المصادقة عادةً على مرحلتين. ترسل الطرفية أولاً REGISTER من دون بيانات اعتماد، فيرد الخادم بـ401 Unauthorized مع معلمات تحدٍ مثل realm وnonce. ثم تحسب الطرفية ملخص المصادقة باستخدام بيانات اعتماد الحساب وترسل REGISTER آخر مع ترويسة Authorization. وعندها فقط تتلقى عادةً 200 OK. لذلك، من منظور الإشارات، تعني عبارة «نجح التسجيل» أن الطرفية والخادم أنهيا للتو معاملة REGISTER موثّقة.
أما المكالمة الهاتفية الفعلية فتحتاج إلى أكثر من ذلك بكثير. فعندما يطلب المستخدم رقماً، يجب أن تنشئ الطرفية INVITE. ويجب على PBX أو خادم SIP أو منصة الإرسال توجيه الرقم المطلوب وفق قواعد الترقيم والصلاحيات. ثم يستخدم الطرفان SDP للتفاوض على برنامج الترميز وعنوان الوسائط ومنفذ RTP قبل أن يبدأ الصوت في التدفق فعلياً.
كما تسلك الإشارات والوسائط مسارات منفصلة. تستخدم إشارات SIP عادةً UDP/TCP 5060 أو TLS 5061، بينما يستخدم RTP عادةً نطاقاً منفصلاً من منافذ UDP الديناميكية. فإذا سمح الجدار الناري بالمنفذ 5060 لكنه حجب نطاق RTP، فقد يعمل التسجيل بصورة كاملة بينما تبقى المكالمة بلا صوت.
ينجح REGISTER
→ يظهر حساب SIP متصلاً
→ ما زال من الممكن رفض INVITE
→ حتى إذا أُعيد 200 OK
→ قد يظل RTP محجوباً بواسطة الجدار الناري أو NAT أو عنوان وسائط غير صحيح
→ حتى إذا وصل RTP إلى الطرفية
→ قد يظل الميكروفون أو مكبر الصوت المحلي معطلاً
النقطة الأساسية بسيطة: حالة التسجيل هي لقطة تُظهر أن معاملة واحدة نجحت في وقت محدد، وليست دليلاً على توافر الصوت من طرف إلى طرف. وهي لا تثبت حتى أن الشبكة قابلة للوصول في هذه اللحظة تحديداً، لأن التسجيل يُجدَّد دورياً، وقد تعكس حالة «مسجل» المعروضة آخر عملية تجديد ناجحة فقط.
حدد أولاً ما إذا كان العطل في إعداد المكالمة أم في وسائط الصوت
عندما يقال إن الهاتف «مسجل لكنه لا يستطيع إجراء مكالمات»، فلا ينبغي أن تكون الخطوة الأولى تغيير برامج الترميز أو إعدادات الشبكة. يجب أولاً تحديد ما المقصود بالضبط بعبارة «لا يستطيع الاتصال». ويمكن عادةً لعدد قليل من الأسئلة أن يحدد اتجاه التشخيص قبل استخدام أي أدوات.
يمكن تقسيم مكالمة SIP الكاملة إلى مرحلتين رئيسيتين. الأولى هي إعداد المكالمة، وتبدأ بـINVITE وتستمر حتى يرد الطرف المطلوب بـ200 OK ويرسل المتصل ACK. والثانية هي وسائط الصوت، حيث يكون تفاوض SDP قد اكتمل ويُفترض أن يتدفق RTP في الاتجاهين فعلياً. وأبسط حد فاصل بين المرحلتين هو ما إذا كانت واجهة المستخدم تعرض المكالمة على أنها متصلة.
إذا ظهر خطأ فور الطلب، أو لم يحدث رنين، أو لم يرَ المستخدم في الطرف البعيد مكالمة واردة مطلقاً، فمن الأرجح أن تكون المشكلة في إشارات SIP أو توجيه المكالمة. أما إذا أظهر الطرفان أن المكالمة متصلة وكان عداد المكالمة يعمل، لكن لا يوجد صوت أو يوجد صوت باتجاه واحد فقط، فيجب الانتقال إلى فحص مسار وسائط SDP وRTP.
| العَرَض | المرحلة المحتملة | أول ما يجب فحصه |
|---|---|---|
| خطأ فوري عند الطلب / لا رنين / الطرف البعيد لا يستقبل شيئاً | إعداد المكالمة | توجيه الأرقام، الصلاحيات، رموز استجابة SIP، إمكانية وصول الإشارات |
| تظهر المكالمة متصلة لكن لا يوجد صوت | وسائط الصوت | عنوان وسائط SDP، منافذ RTP، الجدار الناري، NAT، برنامج الترميز |
| المكالمة متصلة لكن الصوت باتجاه واحد | وسائط الصوت | مقارنة SDP وRTP وربط NAT وتدفقات الوسائط الملتقطة حسب الاتجاه |
| تنقطع المكالمة بعد عدة ثوانٍ | إعداد المكالمة + الوسائط | ACK، Session Timer، انتهاء NAT، سياسة إنهاء الجلسة في المنصة |
| الصوت متقطع أو غير مستقر | جودة نقل الوسائط | فقد الحزم، التذبذب، التأخير، عرض النطاق وتغيّر منافذ RTP |
هناك نمطان آخران مفيدان أيضاً. إذا كان الهاتف يستطيع إجراء مكالمات صادرة لكنه لا يستقبل المكالمات، فغالباً ما يتعلق السبب بتوجيه الرقم الوارد أو عنوان Contact أو NAT أو توجيه المنصة. وإذا كان يستقبل لكنه لا يستطيع الاتصال للخارج، فيجب فحص خطة الاتصال وصلاحيات الاتصال الصادر وتنسيق الرقم أو إعداد وصلة SIP.
إذا كانت امتدادات SIP العادية تتصل ببعضها، لكن المكالمات إلى وحدة التحكم في الإرسال أو نظام النداء أو PSTN تفشل، فإن نطاق العطل يصبح أضيق بكثير، ويرجح أن يرتبط بمسار أو واجهة نظام محددة.
لذلك ينبغي أن يجيب تقرير ميداني مفيد عن أربعة أسئلة:
هل العطل في المكالمات الصادرة أم الواردة؟
هل ترن المكالمة؟
هل تعرض الواجهة المكالمة على أنها متصلة؟
هل لا يوجد صوت، أم يوجد صوت باتجاه واحد، أم تنقطع المكالمة بعد عدة ثوانٍ؟
هذه الإجابات الأربع أكثر فائدة بكثير من مجرد القول «الهاتف لا يعمل».
عند فشل إعداد المكالمة، هل يجب فحص الرقم أم الصلاحيات أم استجابة SIP أولاً؟
إذا حدثت المشكلة أثناء إعداد المكالمة، فاتبع مسار إشارات SIP قبل الاشتباه في عتاد الهاتف المقاوم للانفجار. والترتيب العملي هو: الرقم → الصلاحيات → رمز الاستجابة → إمكانية وصول الإشارات.
ابدأ بـالرقم وخطة الاتصال. هل يتطابق Request-URI الذي ترسله الطرفية مع ما تتوقعه المنصة؟ هل يحتاج الامتداد إلى بادئة؟ هل يتطلب الاتصال بين الأنظمة رمز منطقة أو رمز وصول أو تحويل أرقام؟ كثير من حالات «مسجل لكنه لا يستطيع الاتصال للخارج» ترجع في النهاية إلى عدم تطابق تنسيق الرقم الذي يرسله الهاتف مع قواعد التوجيه المهيأة في PBX.
على سبيل المثال، قد يرسل الهاتف 8001 بينما يتوقع PBX الرقم 8#8001 أو رقماً كاملاً بتنسيق E.164. ويمكن لالتقاط الحزم الذي يعرض Request-URI في INVITE تأكيد ذلك فوراً.
بعد ذلك افحص صلاحيات الحساب. بعض الامتدادات مسموح لها بإجراء مكالمات داخلية فقط ولا تملك صلاحية PSTN. وقد تتمكن امتدادات أخرى من الاتصال بامتدادات SIP عادية، لكنها لا تستطيع الوصول إلى الخطوط الساخنة للطوارئ أو مجموعات الإرسال أو مناطق النداء. ومن السهل إغفال هذا النوع من إعدادات فئة الخدمة في المشاريع الصناعية، لأن التسجيل لا يختبر هذه الصلاحيات التشغيلية. يجيب REGISTER عن «هل هذا الحساب متصل؟»، بينما تجيب محاولة المكالمة عن «هل يُسمح لهذا الحساب بالاتصال بهذه الوجهة؟».
بعد ذلك تساعد رموز استجابة SIP في تضييق نطاق العطل أكثر:
| الفئة | الاستجابات الشائعة | اتجاه الفحص المعتاد |
|---|---|---|
| 1xx معلومات | 100 Trying, 180 Ringing, 183 Session Progress | إعداد المكالمة يتقدم؛ قد تكون المشكلة لاحقاً في المسار أو مرتبطة بالوسائط |
| 2xx نجاح | 200 OK | نجح إعداد المكالمة؛ انتقل إلى تشخيص الوسائط |
| 4xx فشل العميل | 401/407 مصادقة، 403 صلاحية، 404 غير موجود، 408 مهلة، 480 غير متاح، 486 مشغول، 488 عدم توافق برنامج الترميز | غالباً إعداد الطرفية أو التوجيه أو سياسة الخدمة |
| 5xx فشل الخادم | 500, 503 Service Unavailable | جهة PBX أو SBC أو منصة الإرسال |
| 6xx فشل عام | 603 Decline | الوجهة ترفض المكالمة صراحةً |
تظهر بعض الاستجابات كثيراً أثناء التشخيص. تشير 401/407 عادةً إلى معالجة تحدي المصادقة، مثل بيانات الاعتماد أو الخوارزمية أو ارتباط الحساب. أما 403 فيوجه الفحص إلى قواعد الصلاحيات أو سياسة الحساب أو سبب رفض المنصة للطلب. وقد يعني 404 أن الرقم غير موجود أو لا يوجد مسار مطابق. وتشير 408 و480 إلى انتهاء المهلة أو عدم توافر المستخدم. أما 488 فترتبط غالباً بعدم توافق قدرات الوسائط أو فشل تفاوض برنامج الترميز.
إذا بدا إعداد SIP صحيحاً لكن INVITE لا يصل إلى النظام الهدف، فارجع إلى مسار الشبكة. افحص VLAN والبوابة والجدار الناري وقواعد ACL وعنوان الوجهة الفعلي الذي يستخدمه الهاتف. وأسرع اختبار هو التقاط الحركة من جهة الخادم. إذا وصل INVITE ولم يُعاد توجيهه، فافحص توجيه PBX أو منصة الإرسال. وإذا لم يصل إطلاقاً، فركز على الطرفية أو مسار الشبكة بينها وبين الخادم.
إذا كانت المكالمة متصلة لكن لا يوجد صوت أو يوجد صوت في اتجاه واحد، فما الذي يجب فحصه؟
«يظهر الطرفان أنهما متصلان، لكن لا يوجد صوت» من أكثر أعطال SIP شيوعاً. عند هذه النقطة تكون إشارات المكالمة قد اكتملت بنجاح في الغالب. ومن المرجح أن تكون المشكلة في تفاوض SDP أو نقل RTP. لذلك يجب أن ينتقل التشخيص من مستوى الإشارات إلى مستوى الوسائط.
ابدأ بمعلومات الوسائط الموجودة في SDP. هناك عدة أسطر مهمة: c= يحدد عنوان الاتصال، وm= يحدد نوع الوسائط والمنفذ، وa=rtpmap يربط أنواع الحمولة ببرامج الترميز، وa=sendrecv/sendonly/recvonly يحدد اتجاه الوسائط.
يجب أن يكون عنوان الصوت الذي تعلن عنه الطرفية في INVITE أو 200 OK قابلاً للوصول من الطرف البعيد. فإذا وضعت الطرفية عنواناً خاصاً غير قابل للتوجيه مثل 192.168.x.x في SDP بينما يوجد الطرف المقابل في شبكة أخرى، فقد تُنشأ مكالمة SIP بصورة طبيعية مع أن تدفق RTP لا يصل أبداً إلى وجهته. وهذه حالة نموذجية لـ«متصل لكن بلا صوت».
بيئات NAT معرضة لهذا النوع من المشاكل بشكل خاص، وتعتمد المعالجة على بنية الشبكة. قد تعبر إشارات SIP عبر NAT بنجاح بينما يفشل مسار الوسائط بالكامل. ومن سلوكيات NAT الشائعة NAT كامل المخروط وNAT محدود المخروط وNAT محدود المنفذ وNAT متماثل، مع تزايد صعوبة العبور تدريجياً.
غالباً ما تعالج الشبكات الصناعية ذلك باستخدام SBC كوسيط للوسائط بحيث يمر RTP عبر نقطة معروفة. وقد تستخدم بيئات أخرى STUN لاكتشاف تعيينات العنوان العام، بينما تستخدم عمليات نشر أكثر تعقيداً TURN أو ICE. تعتمد الآلية الصحيحة على طوبولوجيا الشبكة الفعلية. نجاح REGISTER لا يثبت أن RTP قادر على عبور NAT.
الجدران النارية سبب شائع آخر. بعض المشاريع تسمح فقط بالمنفذين 5060 أو 5061 لأنهما منافذ SIP الواضحة، بينما يستخدم الصوت نطاق RTP منفصلاً تماماً. وتخصص أجهزة كثيرة منافذ RTP ديناميكياً من نطاقات مثل 10000–20000. فإذا سُمح لـSIP بينما حجبت ACL منافذ RTP، تكون النتيجة تماماً كما يصفها المستخدم: «المكالمة تتصل لكن لا يوجد صوت».
يجب فحص الصوت أحادي الاتجاه حسب الاتجاه. فإذا كانت غرفة التحكم تسمع هاتف الموقع، بينما لا يسمع مستخدم الموقع غرفة التحكم، فهذا يعني أن اتجاه RTP واحداً على الأقل أو مسار صوت محلياً واحداً يعمل. وبدلاً من إعادة فحص الشبكة كلها، قارن عنواني SDP ومنافذ RTP وتعيينات NAT وتدفقات الوسائط الملتقطة. وكثيراً ما تشير الفروق حسب الاتجاه مباشرةً إلى تعيين NAT أو قاعدة الجدار الناري أو عنوان SDP الخاطئ في أحد الطرفين.
بعد التحقق من الشبكة، افحص برنامج الترميز وسلسلة الصوت المحلية
وجود حزم RTP لا يضمن صوتاً مفهوماً. الخطوة التالية هي التأكد من أن الطرفين تفاوضا فعلياً على برنامج ترميز متوافق.
يتبع تفاوض برنامج الترميز نموذج العرض/الإجابة في SDP. تسرد الطرفية المتصلة برامج الترميز التي تدعمها في SDP الخاص بـINVITE، عادةً حسب ترتيب الأفضلية. وتختار الطرفية المطلوبة برنامج ترميز تدعمه أيضاً وتعيده في 200 OK. وإذا لم توجد أي قدرة مشتركة بين القائمتين، يفشل تفاوض الوسائط.
تشمل برامج الترميز الشائعة في الهواتف الصناعية المقاومة للانفجار G.711 (PCMU/PCMA، 64 kbps ومتوافق على نطاق واسع مع بيئات PSTN)، وG.729 للوصلات ذات عرض النطاق الأقل، وG.722 للصوت عريض النطاق، وOpus في بعض الأجهزة الأحدث. وإذا كان الهاتف يفعل مجموعة واحدة فقط من برامج الترميز بينما يدعم PBX أو نظام التسجيل أو منصة الإرسال مجموعة أخرى، فقد تكون النتيجة 488 Not Acceptable Here أو، في بعض التطبيقات، مكالمة متصلة بوسائط غير طبيعية.
الطريقة الصحيحة للتشخيص هي مقارنة أنواع حمولة RTP وقوائم برامج الترميز في رسالتي SDP بدلاً من الاكتفاء بالنظر إلى صفحة الإدارة التي تقول إن برنامج الترميز مفعّل.
بعد التأكد من تفاوض برنامج الترميز ونقل RTP، انتقل إلى المسار الصوتي المادي في الطرفية. تعمل الهواتف المقاومة للانفجار غالباً لفترات طويلة في بيئات مرتفعة الضوضاء أو رطبة أو مغبرة أو مسببة للتآكل. وقد يتعطل الميكروفون أو السماعة اليدوية أو مكبر الصوت أو وحدة التضخيم أو الموصل أو كابل الموقع حتى لو كانت حزمة SIP تعمل بصورة سليمة تماماً.
من الطرق العملية مقارنة إحصاءات RTP بما يمكن سماعه فعلياً في الموقع. فإذا أظهر التقاط الحزم RTP ثنائي الاتجاه بصورة مستمرة، مع عدد حزم وتوقيت طبيعيين، لكن أحد الطرفين لا يزال بلا صوت، فتحقق من حالة الكتم ومستوى الصوت والميكروفون أو مكبر الصوت المادي. وإذا كان RTP يُرسل لكن محتوى الصوت نفسه صامت فعلياً، فيجب أيضاً فحص التقاط الميكروفون أو مسار التقاط الصوت.
عند توافر تحليل كمي للوسائط، تكون ثلاثة مؤشرات مفيدة بشكل خاص: فقد الحزم والتذبذب وزمن التأخير أحادي الاتجاه. يزداد تدهور الصوت مع زيادة فقد الحزم، وقد يتطلب التذبذب المرتفع مخزن jitter أكبر، كما تجعل زيادة التأخير أحادي الاتجاه المحادثة الطبيعية أكثر صعوبة. وإذا تركز الفقد عند قفزة شبكية محددة، فقد يكون ازدحام الوصلة أو النقل اللاسلكي سبباً محتملاً.
بالنسبة إلى محطات النداء المقاومة للانفجار ذات الخرج المضخم، يجب أيضاً التمييز بين مسار مكبر الصوت المدمج في الهاتف وبين أي بوق خارجي أو خرج مضخم. فهما لا يستخدمان بالضرورة المسار الصوتي نفسه تماماً. ونجاح المكالمة عبر السماعة اليدوية أو الوضع الحر لا يثبت أن صوت النداء الخارجي يعمل، والعكس صحيح. لذلك يجب أثناء التشغيل التجريبي والتشخيص فحص كل مسار صوت مطلوب على حدة، بدلاً من اعتبار كل شكوى «لا يوجد صوت نداء» عطلاً في SIP.
كيف يضيّق التقاط الحزم نطاق العطل بسرعة؟
في أعطال SIP المعقدة، يكون تغيير المعلمات مراراً أقل فاعلية عادةً من التقاط مكالمة فاشلة كاملة ومتابعتها زمنياً من REGISTER حتى BYE. ويكفي Wireshark لمعظم الحالات. ومن نقاط الالتقاط المفيدة جهة الهاتف، ومنفذ مرآة في المحول، وجهة SBC أو PBX.
يحدد موضع الالتقاط ما يمكن إثباته. فالالتقاط عند الطرفية يوضح بدقة ما أرسله الهاتف وما استلمه، ما يساعد على تحديد ما إذا كان العطل محلياً. أما الالتقاط عند SBC أو PBX فيوضح ما إذا كانت المنصة قد استلمت الإشارات وأعادت توجيهها بصورة صحيحة. وفي البيئات التي تعبر VLAN أو مواقع متعددة أو SBC، تكون عمليات الالتقاط في عدة نقاط أفضل، لأن نقطة واحدة تثبت فقط مرور الرسالة من ذلك الموضع ولا تثبت سلامة الجزء التالي من الشبكة.
بعد توافر الالتقاط، تابع المكالمة بهذا الترتيب:
1. هل نجح REGISTER؟
→ 2. هل أُرسل INVITE فعلياً؟
→ 3. هل استلمه PBX ووجّهه بصورة صحيحة؟
→ 4. هل أعاد الطرف البعيد 18x / 200 OK؟
→ 5. هل تفاوض SDP على برنامج ترميز مشترك؟
→ 6. هل يوجد RTP ثنائي الاتجاه فعلياً؟
→ 7. هل عناوين IP ومنافذ وجهة RTP صحيحة؟
→ 8. هل ينقل ميكروفون ومكبر صوت الموقع الصوت فعلياً؟
يوفر Wireshark أدوات مفيدة لذلك. يمكن تصفية رسائل SIP بتعبيرات مثل sip أو sip.CSeq. ومن خلال Telephony → VoIP Calls يمكن مراجعة المكالمة مع تسلسل الإشارات وتدفقات RTP المرتبطة بها. كما يساعد تحليل RTP على إظهار فقد الحزم والتذبذب ومؤشرات أخرى لجودة الوسائط.
يجب أن يبقى ترتيب التشخيص الإشارات أولاً، ثم الوسائط. فإذا فشلت الإشارات، تكون المشكلة في إعداد المكالمة. وإذا اكتملت الإشارات لكن الوسائط غائبة، فيجب البحث في مسار الوسائط.
في حالة «الصادر يعمل والوارد لا يعمل»، تحقق مما إذا كان INVITE الوارد يصل فعلياً إلى الهاتف المقاوم للانفجار. وإذا انقطعت المكالمة باستمرار بعد بضع ثوانٍ أو عشرات الثواني، فافحص ACK وSession Timer وتعيين NAT، وما إذا كانت المنصة تنهي الجلسة لعدم استلام رسالة متوقعة.
هناك حالة أقل وضوحاً هي إعادة تفاوض الوسائط أثناء المكالمة. قد يغير re-INVITE عنوان RTP أو المنفذ. وإذا فشل تعيين NAT أثناء إعادة التفاوض، فقد يكون العَرَض «عملت المكالمة لعدة ثوانٍ ثم اختفى الصوت».
الهدف ليس حفظ كل رموز استجابة SIP. واصل طرح سؤال واحد: ما آخر طبقة اجتازتها المكالمة بنجاح، وأين ظهر أول سلوك غير طبيعي؟ بمجرد تحديد أول نقطة فشل يكون جزء كبير من التشخيص قد اكتمل.
الأسئلة الشائعة
إذا أظهر هاتف SIP أنه مسجل، فهل يثبت ذلك على الأقل أن الشبكة تعمل؟
لا. حالة «مسجل» تعني فقط أن الطرفية استطاعت إكمال معاملة تسجيل SIP مع Registrar في وقت معين. ولا تثبت أن توجيه المكالمات أو إمكانية الوصول إلى الوجهة أو وسائط RTP أو NAT أو قواعد الجدار الناري أو عتاد الصوت في الطرفية تعمل كلها بصورة صحيحة. كما لا تثبت أن الشبكة ستبقى خالية من فقد الحزم أو التأخير المرتفع أثناء مكالمة فعلية. وبما أن التسجيل دوري، فقد تعكس الحالة المعروضة آخر تجديد ناجح فقط.
يظهر الطرفان أنهما متصلان لكن لا يوجد صوت. ما الذي يجب فحصه أولاً؟
افحص أولاً عناوين IP الخاصة بالوسائط ومنافذ RTP وتفاوض برامج الترميز في SDP. ثم تأكد من أن الجدار الناري أو جهاز NAT أو SBC يسمح بـRTP ثنائي الاتجاه. وإذا كان RTP ثنائي الاتجاه يصل فعلياً إلى الطرفين، فانتقل إلى الميكروفون ومكبر الصوت وحالة الكتم وإعدادات خرج الصوت المحلي. والترتيب العملي هو مسار الوسائط أولاً ثم العتاد المحلي.
لماذا يستطيع الهاتف المقاوم للانفجار نفسه إجراء مكالمات داخلية بينما تفشل مكالمات PSTN؟
تستخدم المكالمات بين الامتدادات الداخلية ومكالمات PSTN عادةً مسارات توجيه مختلفة. كما تتطلب المكالمات الخارجية صلاحيات صادرة وتحويل أرقام وإعداد وصلة SIP وتوجيه المشغل وقواعد إظهار هوية المتصل. ونجاح الاتصال بين الامتدادات يثبت فقط أن جزءاً من مسار SIP والوسائط يعمل. أما مكالمات PSTN فلا تزال بحاجة إلى المرور عبر وصلة SIP وشبكة المشغل، ما يضيف متطلبات إضافية للتوجيه والسياسة.
التسجيل طبيعي، لكن الصوت متقطع أو تنقطع المكالمة أثناء الحديث. ما السبب المحتمل؟
غالباً ما تكون المشكلة في جودة نقل الوسائط: فقد الحزم أو التذبذب الزائد أو نقص عرض النطاق أو انتهاء تعيين NAT قد يقطع RTP أثناء المكالمة. افحص أولاً فقد RTP والتذبذب، ثم سعة الوصلة وتغطية الراديو عند الحاجة. وإذا كانت المكالمات تنقطع باستمرار بعد مدة متوقعة، فافحص أيضاً إعادة تفاوض الوسائط عبر re-INVITE وسلوك Session Timer.
لماذا يؤدي استبدال الهاتف إلى حل المشكلة بينما تستمر الوحدة الأصلية في الفشل؟
يشير ذلك غالباً إلى إعداد الهاتف الأصلي أو برمجته الثابتة أو عتاده المحلي بدلاً من الشبكة. وقد تشمل الأسباب مشكلة في البرمجيات الثابتة، أو معلمات SIP غير صحيحة مثل انتهاء التسجيل أو معالجة NAT أو نطاق منافذ RTP، أو عطلاً في DSP أو وحدة الصوت. قارن الجهازين إعداداً بإعداد، ولا سيما قوائم برامج الترميز ومنافذ SIP وإعدادات NAT، بدلاً من نسبة الفرق مباشرةً إلى شبكة غير مستقرة.
هل يمكن اعتبار إعادة تشغيل هاتف SIP مقاوم للانفجار أسلوباً صحيحاً للتشخيص؟
قد تعيد إعادة التشغيل التسجيل مؤقتاً أو تجدّد تعيين NAT أو تزيل عملية معلقة، لكنها لا ينبغي أن تحل محل عزل العطل. فإذا كان السبب في إعداد خطة الاتصال أو صلاحيات SIP أو قواعد الجدار الناري أو تفاوض برامج الترميز أو توجيه الوسائط، فقد تخفي إعادة التشغيل المشكلة لفترة قصيرة فقط أو لا يكون لها تأثير. والأسلوب الأفضل هو تسجيل أعراض العطل وحفظ لقطات الإشارات والسجلات ثم تحديد ما إذا كان أول فشل في الطرفية أو الشبكة أو منصة الاتصالات.
يمكن لـBecke Telcom المساعدة في التشخيص استناداً إلى البنية الفعلية للطرفية وIP PBX ووصلة SIP ومبدلات الشبكة وSBC ونظام الإرسال. كما توفر Becke Telcom هواتف مقاومة للانفجار، وهواتف نداء مقاومة للانفجار، وبوابات SIP، وأنظمة نداء IP، ومعدات إرسال موحدة لبيئات البتروكيماويات والطاقة والتعدين والأنفاق وغيرها من البيئات الصناعية.
