المحتويات

المقدمة

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

المتطلبات

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

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

مشاكل إعداد المكالمات

حالات فشل مصافحة TLS المتبادلة

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

المسألة 1. Expressway-E لا يثق في مرجع الشهادة (CA) الذي وقع شهادة Cisco Webex

المسألة 2. اسم غير صحيح لموضوع TLS التحقق من الاسم على Expressway-E Cisco Webex Hybrid DNS Zone

المسألة 3. لا يرسل Expressway-E سلسلة الشهادات الكاملة إلى Cisco Webex

المسألة 4. جدار الحماية ينهي تأكيد اتصال TLS المتبادل

المسألة 5. يتم توقيع Expressway-E من قبل CA العام ولكن يتم تحميل شهادات بديلة من Cisco Webex Control Hub

المسألة 6. لا يقوم Expressway بتعيين المكالمة الواردة لمنطقة DNS المختلطة ل Cisco Webex

المسألة 7. يستخدم Expressway-E شهادة ذاتية التوقيع افتراضية

الوارد: Cisco Webex إلى محلي

المسألة 1. يتعذر على Cisco Webex حل Expressway-E DNS SRV/hostname

المسألة 2. فشل المأخذ: تم حظر المنفذ 5062 داخل Expressway

المسألة 3. فشل المقبس: لا يصغي Expressway-E على المنفذ 5062

المسألة 4. لا يدعم Expressway-E أو C رؤوس مسار SIP المحملة مسبقا

المسألة 5. يتلقى تطبيق Cisco Webex إخطارين لاتصالات (أجهزة)

الصادر: محلي إلى Cisco Webex

المسألة 1. يتعذر على Expressway حل عنوان callservice.ciscospark.com

المسألة 2. تم حظر المنفذ 5062 خارج نطاق Cisco Webex

المسألة 3. تكوين قاعدة بحث Expressway غير صحيح

المسألة 4. تكوين CPL غير صحيح في Expressway

ثنائي الإتجاه: من Cisco Webex إلى محلي أو محلي إلى Cisco Webex

المسألة 1. توفر نقطة نهاية التعاون/هاتف IP برنامج ترميز صوت بخلاف G.711 أو G.722 أو AAC-LD.

المسألة 2. تم تجاوز الحد الأقصى لحجم الرسائل الواردة الواردة ل Unified CM

الملحق

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

فحص الأداة المساعدة للنمط

تحديد موقع الأداة المساعدة

التسجيل التشخيص

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

المقدمة

يصف هذا المستند حل Cisco Webex Hybrid Call Service Connect الذي يسمح لبنية Cisco الأساسية الحالية للتحكم في المكالمات بالاتصال بسحابة Cisco Collaboration Cloud حتى يمكنها العمل معا.

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

المتطلبات

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

- معرفة عرض Cisco Webex

- معرفة حل Expressway (B2B)

- معرفة مدير الاتصالات الموحدة من Cisco (Unified CM) وتكامله مع Expressway

- Unified CM 10. 5(2) SU5 أو إصدار أحدث.

- Expressway (B2B) إصدار X8.7.1 أو إصدار أحدث (يوصى ب X8.9.1)

- Expressway (مضيف الموصل) — راجع دعم مضيف Expressway Connector لخدمات Cisco Webex المختلطة للإصدارات المدعومة حاليا

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

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

- مدير الاتصالات الموحدة من Cisco

- طرق سريعة

- Webex ل Windows

- Webexfor Mac

- Webexfor iOS

- Webex ل Android

- نقاط النهاية للعمل الجماعي من Cisco

- نقاط نهاية مكتب التعاون

- هواتف بروتوكول الإنترنت

- البرامج العميلة

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

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

يوفر الحل هذه الإمكانات:

- إستخدام تطبيق Webex كعميل لين للهاتف المحمول لمكالمات الصوت والفيديو

- أستخدم التطبيق لإجراء المكالمات وتلقيها من أي مكان، كما لو كانت في المكتب

- إستخدام Webex أو Cisco Jabber أو هاتف المكتب للاتصال، دون الحاجة إلى القلق بشأن الخيار الذي يستخدمونه

- إلغاء تأمين محفوظات المكالمات في الهواتف المحلية ودمج ذلك التاريخ في Webex

يغطي نطاق هذا الدليل المشاكل الفريدة الخاصة ب "اتصال خدمة المكالمات المختلطة". ونظرا لأن اتصال خدمة المكالمات المختلطة يعمل عبر نفس زوج Expressway E & C مثل الحلول الأخرى مثل الوصول عن بعد والجوال واتصال الأعمال، فإن المشاكل مع الحلول الأخرى يمكن أن تؤثر على اتصال خدمة المكالمات المختلطة. بالنسبة للعملاء والشركاء الذين يقومون بنشر زوج Expressway للاستخدام مع Call Service Connect، يجب الإشارة إلى دليل تكوين Cisco VCS Expressway و VCS Control Basic قبل محاولة نشر اتصال خدمة Call Hybrid. يغطي دليل أستكشاف الأخطاء وإصلاحها هذا اعتبارات جدار الحماية/بطاقة واجهة الشبكة (NAT) إلى جانب تصميم Expressway في كل من الملحق 3 و 4. راجع هذه الوثائق بشكل شامل. وبالإضافة إلى ذلك، يفترض هذا المستند أنه تم إكمال مضيف Expressway Connector وتنشيط خدمة المكالمات المختلطة.

مشاكل إعداد المكالمات

حالات فشل مصافحة TLS المتبادلة

يستخدم اتصال خدمة المكالمات المختلطة أمان طبقة النقل المتبادل (TLS المتبادل) للمصادقة بين Cisco Webex و Expressway-E. وهذا يعني أن كلا من Expressway-E و Cisco Webex يفحصان الشهادة التي يحضر كل منهما الآخر ويفحصانها. ونظرا لتفشي مشاكل TLS المتبادلة خلال عمليات النشر الجديدة لخوادم Expressway وتمكين الحلول مثل Hybrid Call Service Connect، يوفر هذا القسم معلومات ونصائح مفيدة لاستكشاف المشكلات القائمة على الشهادات وإصلاحها بين Expressway و Cisco Webex.

ماذا يتحقق Expressway-E؟

- هل تم توقيع شهادة Cisco Webex من قبل مرجع مصدق عام مدرج في قائمة مرجع مصدق ثقة Expressway-E؟

- هل callservice.ciscospark.com موجود في حقل الاسم البديل للموضوع من شهادة Cisco Webex؟

ماذا يتحقق Cisco Webex؟

- هل تم توقيع شهادة Expressway-E من قبل إحدى وكالات CA العامة التي تثق في Webex؟ (قائمة Cisco Webex Trusted CA)

- إذا لم يستخدم Expressway-E شهادة موقعة بشكل عام، هل تم تحميل شهادة Expressway مع أي شهادات جذر أو متوسط إلى محور التحكم في Cisco Webex (https://admin.ciscospark.com)؟

وهذا موضح كما هو موضح في الصورة.

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

1. فك ترميز مصافحة TLS المتبادلة

بشكل افتراضي، يضع Wireshark علامة حركة مرور SIP TLS كمنفذ 5061. ما يعنيه هذا هو أنه في أي وقت تريد تحليل مصافحة TLS (متبادلة) تحدث عبر المنفذ 5062، لن يعرف Wireshark كيفية فك تشفير حركة المرور بشكل صحيح. هنا مثال على مصافحة TLS المتبادلة التي تحدث عبر المنفذ 5062 كما هو موضح في الصورة.

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

1 أ. تحديد الدفق ك SSL

أ. عندما تقوم بتحليل مصافحة TLS المتبادلة، قم أولا بتصفية الالتقاط بواسطة tcp.port==5062. بعد ذلك، انقر بزر الماوس الأيمن على الحزمة الأولى في الدفق وحدد فك الترميز ك... كما هو موضح في الصورة.

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

1 مليا. ضبط منفذ SIP TLS

عندما تقوم بضبط منفذ SIP TLS إلى 5062 في تفضيلات Wireshark، يمكنك عندئذ رؤية كل التفاصيل التي تحيط بالمصافحة، والتي تتضمن التراخيص. لإجراء هذا التغيير:

- فتح السلك

- انتقل إلى تحرير > تفضيلات

- قم بتوسيع البروتوكولات وحدد SIP

- ثبتت ال SIP TLS ميناء إلى 5062 وطقطقة يطبق

- قم بتعيين القيمة مرة أخرى إلى 5061 عند اكتمال التحليل كما هو موضح في الصورة.

إذا قمت بتحليل نفس الالتقاط الآن، سترى الحزم من 169 إلى 175 مفكوزة. تعرض الحزمة 175 شهادة Expressway-E وإذا قمت بالتوصيل لأسفل على الحزمة، يمكنك أن ترى جميع تفاصيل الشهادة كما هو موضح في الصورة.

2. تصفية Wireshark

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

- tcp.port==5062

- ssl & tcp.port==5062

- ssl.handshake.certificate & tcp.port==5062

3. إستخراج شهادة من PCAP

من وقت لآخر، قد تحتاج للحصول على نسخة من شهادة (خادم أو جذر أو وسيط). إذا لم تكن تعرف أين تجد الشهادة التي تبحث عنها، يمكنك إستخراجها مباشرة من التقاط الحزمة. فيما يلي الخطوات الخاصة بكيفية سحب شهادة Cisco Webex المقدمة عند مصافحة TLS متبادلة.

1. تصفية التقاط الحزمة باستخدام ssl.handshake.certificate & tcp.port==5062

2. حدد موقع الحزمة التي يتم الحصول عليها من عنوان خادم Webex وتتم طباعة الشهادة فيها في قسم المعلومات.

3. في الحزمة توسع طبقة مأخذ التوصيل الآمنة > شهادة TLS > بروتوكول المصافحة > الشهادات.
ملاحظة: الشهادة الأدنى/الأخيرة في السلسلة هي المرجع المصدق الجذر.

4. انقر بزر الماوس الأيمن فوق شهادة الفائدة وحدد تصدير وحدات بايت الحزم المحددة... كما هو موضح في الصورة.

5. احفظ الملف ك .cer.

6. انقر نقرا مزدوجا على الملف المحفوظ لفتح الشهادة كما هو موضح في الصورة.

4. تعديل مستويات تسجيل الدخول إلى Expressway

تتوفر وحدتا تسجيل على Expressway مما يساعدك على فهم المنطق الذي تقوم به Expressway بشكل أفضل عند تحليل الشهادات:

- مطور.ssl

- developer.zone.zonemg

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

مثال على Expressway-E الذي يقوم بإجراء فحص SAN لشهادة خادم Cisco Webex.

2017-09-22T11:11:19.485-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,485" Module="developer.ssl" Level="INFO" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1974)" Method="::ttssl_continueHandshake" Thread="0x7f576cbee700":  Detail="Handshake in progress" Reason="want read/write"

2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1960)" Method="::ttssl_continueHandshake" Thread="0x7f576cbee700":  Detail="Handshake succeeded"

2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1629)" Method="::TTSSL_retrieveCommonName" Thread="0x7f576cbee700":  Detail="Found common name in peer certificate" CommonName="l2sip-cfa-01.ciscospark.com"

2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1654)" Method="::TTSSL_retrieveAltNames" Thread="0x7f576cbee700":  Detail="Found DNS alt-name in peer certificate" AltName="l2sip-cfa-01.ciscospark.com"

2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1654)" Method="::TTSSL_retrieveAltNames" Thread="0x7f576cbee700":  Detail="Found DNS alt-name in peer certificate" AltName="l2sip-cfa-01.wbx2.com"

2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1654)" Method="::TTSSL_retrieveAltNames" Thread="0x7f576cbee700":  Detail="Found DNS alt-name in peer certificate" AltName="l2sip-cfa-01-web.wbx2.com"

2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1654)" Method="::TTSSL_retrieveAltNames" Thread="0x7f576cbee700":  Detail="Found DNS alt-name in peer certificate" AltName="l2sip-cfa-web.wbx2.com"

2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1654)" Method="::TTSSL_retrieveAltNames" Thread="0x7f576cbee700":  Detail="Found DNS alt-name in peer certificate" AltName="callservice.ciscospark.com"

2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1654)" Method="::TTSSL_retrieveAltNames" Thread="0x7f576cbee700":  Detail="Found DNS alt-name in peer certificate" AltName="callservice.call.ciscospark.com"

مثال على تخطيط Expressway-E لاتصال MTLS بمنطقة DNS المختلطة من Cisco Webex:

2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.zone.zonemgr" Level="DEBUG" CodeLocation="ppcmains/oak/zones/ZoneManager.cpp(1226)" Method="ZoneManager::getDNSZoneByTLSVerifySubjectName" Thread="0x7f577f0a0700":  this="0x56408ff81220" getDNSZoneByTLSVerifySubjectName classified subject name callservice.ciscospark.com into DNS zone Hybrid Call Services DNS

2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.zone.zonemgr" Level="DEBUG" CodeLocation="ppcmains/oak/zones/ZoneManager.cpp(1183)" Method="ZoneManager::getDNSZoneByTLSVerifySubjectNameList" Thread="0x7f577f0a0700":  this="0x56408ff81220"  Detail="Searched for DNS Zones by Subject Name" Found="True" Candidates="l2sip-cfa-01.ciscospark.coml2sip-cfa-01.ciscospark.coml2sip-cfa-01.wbx2.coml2sip-cfa-01-web.wbx2.coml2sip-cfa-web.wbx2.comcallservice.ciscospark.com" MatchedZone="Hybrid Call Services DNS" MatchedIdentity="callservice.ciscospark.com"

2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.zone.zonemgr" Level="DEBUG" CodeLocation="ppcmains/oak/zones/ZoneManager.cpp(1054)" Method="ZoneManager::getZoneByIdentities" Thread="0x7f577f0a0700":  this="0x56408ff81220"  Detail="getZoneByIdentities, match complete" Identitites="{CN: l2sip-cfa-01.ciscospark.com, Alt-DNS: l2sip-cfa-01.ciscospark.com, Alt-DNS: l2sip-cfa-01.wbx2.com, Alt-DNS: l2sip-cfa-01-web.wbx2.com, Alt-DNS: l2sip-cfa-web.wbx2.com, Alt-DNS: callservice.ciscospark.com, Alt-DNS: callservice.call.ciscospark.com, Alt-DNS: l2sip-a-Webexcall.ciscospark.com, Alt-DNS: l2sip-prod-11-dfw-public.wbx2.com, Alt-DNS: l2sip-prod-12-dfw-public.wbx2.com, Alt-DNS: l2sip-l2sipproda1-294-riad-public.wbx2.com, Alt-DNS: l2sip-l2sipproda1-817-riad-public.wbx2.com, Alt-DNS: l2sip-l2sip-prod-wpsjc-web.ciscospark.com, Alt-DNS: l2sip-l2sip-prod-wpsjc-web.wbx2.com, Alt-DNS: l2sip-l2sip-prod-wpdfw-web.ciscospark.com, Alt-DNS: l2sip-l2sip-prod-wpdfw-web.wbx2.com, Alt-DNS: l2sip-cfa-02.wbx2.com, Alt-DNS: Webexcmr-wpa.ciscospark.com, Alt-DNS: Webexcmr-wpb.ciscospark.com, Alt-DNS: Webexcmr-wpc.ciscospark.com, Alt-DNS: l2sip-wpa-01.wbx2.com, Alt-DNS: l2sip-wpa-02.wbx2.com, Alt-DNS: l2sip-wpb-01.wbx2.com, Alt-DNS: l2sip-wpb-02.wbx2.com, Alt-DNS: l2sip-wpc-01.wbx2.com, Alt-DNS: l2sip-wpc-02.wbx2.com}" MatchMechanism="DNSZoneMatch" MatchedZone="Hybrid Call Services DNS"

فيما يلي قائمة بالمشكلات الأكثر شيوعا التي ترتبط بفشل TLS المتبادل بين Expressway-E و Cisco Webex.

المسألة 1. Expressway-E لا يثق في مرجع الشهادة (CA) الذي وقع شهادة Cisco Webex

يسمى خادم Cisco Webex الذي يكون على اتصال مباشر مع Expressway-E خادم L2SIP. يجب توقيع خادم L2SIP هذا بواسطة خادم وسيط باسم شائع هو Hydrant SSL ICA G2. يتم توقيع الوسيط من قبل سلطة شهادة الجذر التي لها اسم مشترك ل QuoVadis root CA 2 كما هو موضح في الصورة.

ملاحظة: قد يكون هذا عرضة للتغيير.

تتمثل الخطوة الأولى لتحليل حركة المرور هذه من منظور تشخيص Expressway في البحث عن اتصال TCP. بعد البحث في اتصال TCP، ستبحث عن قيمة Dst-port=5062. بمجرد تحديد المنطقة في السجلات التي تم فيها محاولة هذا الاتصال وتأسيسه، يمكنك بعد ذلك البحث عن مصافحة TLS التي يتم الإشارة إليها بشكل عام بواسطة إدخالات السجل التي تشير إلى مصافحة قيد التقدم.

2017-09-20T10:49:18.427-04:00 amer-expressway01 tvcs: UTCTime="2017-09-20 14:49:18,426" Module="developer.ssl" Level="INFO" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1974)" Method="::ttssl_continueHandshake" Thread="0x7f29ddefa700":  Detail="Handshake in progress" Reason="want read/write"

إذا لم يكن Expressway-E يثق في شهادات Cisco Webex الموقعة، فيمكنك توقع أن يقوم Expressway-E برفض الشهادة مباشرة بعد اكتمال المصافحة. يمكن ملاحظة ذلك في تسجيل Expressway-E من خلال إدخالات السجل هذه:

2017-09-20T10:49:18.724-04:00 amer-expressway01 tvcs: Event="Inbound TLS Negotiation Error" Service="SIP" Src-ip="146.20.193.73" Src-port="58531" Dst-ip="172.16.2.2" Dst-port="5062" Detail="self signed certificate in certificate chain" Protocol="TLS" Level="1" UTCTime="2017-09-20 14:49:18,724"

2017-09-20T10:49:18.724-04:00 amer-expressway01 tvcs: UTCTime="2017-09-20 14:49:18,724" Module="developer.ssl" Level="ERROR" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(68)" Method="::TTSSLErrorOutput" Thread="0x7f29ddefa700": TTSSL_continueHandshake: Failed to establish SSL connection iResult="-1" error="1" bServer="true" localAddress="['IPv4''TCP''172.16.2.2:5062']" remoteAddress="['IPv4''TCP''146.20.193.73:58531']" ssl_error_reason="error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed"

2017-09-20T10:49:18.724-04:00 amer-expressway01 tvcs: UTCTime="2017-09-20 14:49:18,724" Module="network.tcp" Level="DEBUG": Src-ip="146.20.193.73" Src-port="58531" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connection Closed" Reason="self signed certificate in certificate chain"

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

الحل:

لحل هذه الحالة، يجب أن تتأكد من أن Expressway-E يثق في سلطات شهادة Cisco Webex. بينما يمكنك ببساطة إستخراج هذه الشهادات من تتبع Wireshark وتحميلها إلى مخزن شهادات CA الموثوق به على Expressway، توفر Expressway طريقة أبسط:

- تسجيل الدخول إلى Expressway-E

- انتقل إلى تطبيقات > إدارة شهادات الشبكة

- حدد خيار الحصول على الشهادات كما هو موضح في الصورة.

عند هذه النقطة، يتم تحميل مراجع شهادات Cisco Webex إلى مخزن Expressway-E الموثوق CA (الصيانة > الأمان > شهادة CA الموثوق بها).

المسألة 2. اسم غير صحيح لموضوع TLS التحقق من الاسم على Expressway-E Cisco Webex Hybrid DNS Zone

كجزء من مصافحة TLS المتبادلة، يستخدم اتصال خدمة المكالمات المختلطة التحقق من TLS. وهذا يعني أنه بالإضافة إلى الثقة في شهادات Cisco Webex CA، يتحقق Expressway من الشهادة من خلال التحقق من حقل "الاسم البديل للموضوع (SAN)" في الشهادة المقدمة للتأكد من أنها تحتوي على قيمة مثل callService.ciscospark.com الموجود. إذا لم تكن هذه القيمة موجودة، فسيفشل إستدعاء الوارد.

في هذا السيناريو الخاص، يقدم خادم Cisco Webex شهادته إلى Expressway-E. تحتوي الشهادة بالفعل على 25 شبكة تخزين (SAN) مختلفة. ضع في الاعتبار الحالة التي يقوم فيها Expressway-E بالتحقق من الشهادة الخاصة بشبكة التخزين (SAN) الخاصة ب callservice.ciscospark.com ولكنه لا يجد ذلك. عند الوفاء بهذا الشرط، يمكنك مشاهدة خطأ مماثل لهذا داخل التسجيل التشخيصي:

2017-09-20T11:17:42.701-04:00 amer-expressway01 tvcs: Event="Inbound TLS Negotiation Error" Service="SIP" Src-ip="146.20.193.45" Src-port="46049" Dst-ip="172.16.2.2" Dst-port="5062" Detail="Peer's TLS certificate identity was unacceptable" Protocol="TLS" Level="1" UTCTime="2017-09-20 15:17:42,700"

2017-09-20T11:17:42.701-04:00 amer-expressway01 tvcs: UTCTime="2017-09-20 15:17:42,700" Module="network.tcp" Level="DEBUG":  Src-ip="146.20.193.45" Src-port="46049" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connection Closed" Reason="Peer's TLS certificate identity was unacceptable"

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

لتأكيد تكوين هذه القيمة، يمكنك الانتقال إلى منطقة Webex Hybrid DNS التي تم تكوينها للحل. إذا كان لديك التكوين Expressway-E xConfiguration، فيمكنك البحث عن قسم تكوين المنطقة لتحديد كيفية تكوين اسم الموضوع الذي يتحقق TLS منه. بالنسبة إلى xConfiguration، لاحظ أن المناطق يتم طلبها بحيث تكون المنطقة 1 هي الأولى. فيما يلي xConfiguration من بيئة المشاكل التي تم تحليلها أعلاه.

*c xConfiguration Zones Zone 6 DNS SIP TLS Verify Mode: "On"

*c xConfiguration Zones Zone 6 DNS SIP TLS Verify Subject Name: "calllservice.ciscospark.com"

وكما يمكنك أن ترى في المثال، فإن TLS Verify Subject Name تم تعيينه على callService.ciscospark.com بدلا من callService.ciscospark.com. (لاحظ الحرف "l" الإضافي).

الحل:

لحل هذه المشكلة، يجب تعديل TLS Verify Subject Name:

- تسجيل الدخول إلى Expressway-E

- انتقل إلى التكوين > مناطق > مناطق

- تحديد منطقة DNS للخدمات المختلطة ل Webex

- تعيين اسم موضوع التحقق من TLS على callservice.ciscospark.com

- حدد حفظ

ملاحظة: راجع سلوك تسجيل الخط الأساسي. يعرض هذا القسم التحقق من صحة شهادة Expressway والتعيين لمنطقة Webex Hybrid DNS.

ملاحظة: اعتبارا من رمز Expressway x12.5 وفيما بعد تم إصدار منطقة "webex" جديدة. تقوم منطقة Webex هذه بملء تكوين المنطقة المطلوبة للاتصال ب Webex. هذا يعني أنك لم تعد مضطرة لتعيين موضوع TLS "التحقق من الوضع" و TLS "التحقق من اسم الموضوع". لتبسيط التكوين، يوصى بالاستفادة من منطقة Webex إذا كنت تشغل x12.5 أو إصدارا أحدث من رمز Expressway.

المسألة 3. لا يرسل Expressway-E سلسلة الشهادات الكاملة إلى Cisco Webex

كجزء من مصافحة TLS المتبادلة، يجب أن يثق Cisco Webex في شهادة Expressway-E. تحتوي Cisco Webex على قائمة كاملة من CA العام التي تثق فيها. بشكل نموذجي، ينجح مصافحة TLS عندما يتم توقيع شهادة Expressway-E من قبل مرجع مصدق عام يدعمه Cisco Webex. وفقا للتصميم، ترسل Expressway-E شهادتها فقط أثناء مصافحة TLS بالرغم من توقيعها من قبل مرجع مصدق عام. لإرسال سلسلة الشهادات الكاملة (الجذر والوسيط)، يجب إضافة تلك الشهادات إلى مخزن شهادات CA الموثوق به على Expressway-E نفسه.

إذا لم يتم الوفاء بهذا الشرط، فإن Cisco Webex يرفض شهادة Expressway-E. عند أستكشاف أخطاء حالة تطابق هذه المشكلة وإصلاحها، يمكنك إستخدام سجلات التشخيص و tcpdump من Expressway-E. عند تحليل سجلات تشخيص Expressway-E، سترى خطأ مماثلا لهذا الخطأ هنا:

2017-09-19T11:12:09.721-04:00 amer-expressway01 tvcs: Event="Inbound TLS Negotiation Error" Service="SIP" Src-ip="146.20.193.45" Src-port="33441" Dst-ip="172.16.2.2" Dst-port="5062" Detail="sslv3 alert certificate unknown" Protocol="TLS" Level="1" UTCTime="2017-09-19 15:12:09,721"

2017-09-19T11:12:09.721-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 15:12:09,721" Module="developer.ssl" Level="ERROR" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(68)" Method="::TTSSLErrorOutput" Thread="0x7fc67c6ec700": TTSSL_continueHandshake: Failed to establish SSL connection iResult="0" error="1" bServer="true" localAddress="['IPv4''TCP''172.16.2.2:5062']" remoteAddress="['IPv4''TCP''146.20.193.45:33441']" ssl_error_reason="error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown"

2017-09-19T11:12:09.721-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 15:12:09,721" Module="network.tcp" Level="DEBUG": Src-ip="146.20.193.45" Src-port="33441" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connection Closed" Reason="Got EOF on socket"

إذا حللتم هذا الأمر من منظور Wireshark، سترون أن Expressway-E يقدم ترخيصه. إذا قمت بتوسيع الحزمة، يمكنك أن ترى أن شهادة الخادم فقط أرسلت. ثم يرفض Cisco Webex مصافحة TLS هذه برسالة خطأ CA غير معروفة كما هو موضح في الصورة.

الحل:

in order to عالجت المشكلة في هذا سيناريو، أنت ينبغي upload ال CAs متوسط وجذري أن يكون تضمنت في توقيع من Expressway-E شهادة إلى ال موثوق CA مستودع:

الخطوة 1. سجل الدخول إلى Expressway-E.

الخطوة 2. انتقل إلى الصيانة > التأمين > شهادة المرجع المصدق الموثوق به.

الخطوة 3. حدد إختيار ملف تحت قائمة التحميل بالقرب من أسفل واجهة المستخدم.

الخطوة 4. أختر شهادة المرجع المصدق التي شاركت في توقيع Expressway-E.

الخطوة 5. حدد إضافة شهادة مرجع مصدق.

الخطوة 6. كرر الخطوات لجميع شهادات المرجع المصدق المتعلقة بتوقيع شهادة Expressway-E (الوسيطة، الجذر).

الخطوة 7. حدد إضافة شهادة مرجع مصدق.

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

المسألة 4. جدار الحماية ينهي تأكيد اتصال TLS المتبادل

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

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

Thread="0x7f6496669700": TTSSL_continueHandshake: Failed to establish SSL connection iResult="-1" error="5" bServer="false" localAddress="['IPv4''TCP''172.17.31.10:28351']"

2017-06-13T13:31:38.760-05:00 vcse tvcs: Event="Outbound TLS Negotiation Error" Service="SIP" Src-ip="172.17.31.10" Src-port="28351" Dst-ip="198.101.251.5" Dst-port="5062" Detail="No SSL error available, probably remote disconnect" Protocol="TLS" Common-name="callservice.ciscospark.com" Level="1" UTCTime="2017-06-13 18:31:38,758"

2017-06-13T13:31:38.760-05:00 vcse tvcs: UTCTime="2017-06-13 18:31:38,758" Module="network.tcp" Level="DEBUG":  Src-ip="172.17.31.10" Src-port="28351" Dst-ip="198.101.251.5" Dst-port="5062" Detail="TCP Connection Closed" Reason="Got EOF on socket"

من منظور التقاط الحزمة، سترى أن Expressway-E يقدم مرفقه إلى Cisco Webex. ترى TCP RST يأتي في إتجاه Cisco Webex كما هو موضح في الصورة.

للوهلة الأولى، قد تعتقد أن هناك خطأ ما في شهادة Expressway-E. لاستكشاف أخطاء هذه المشكلة وإصلاحها، يجب عليك أولا تحديد الإجابات على هذه الأسئلة:

- هل تم توقيع Expressway-E بواسطة مرجع مصدق عام يثق فيه Cisco Webex؟

- هل يتم تحميل شهادة Expressway-E وأي شهادات متعلقة بتوقيع شهادة Expressway-E يدويا إلى محور التحكم في Cisco Webex (https://admin.ciscospark.com)؟

في هذه الحالة الخاصة، لم يكن الحل هو إستخدام لوحة تحكم Cisco Webex لإدارة شهادات Expressway-E. وهذا يعني أنه يجب توقيع شهادة Expressway-E من قبل مرجع مصدق عام يثق فيه Cisco Webex. بتحديد على حزمة الشهادة في التقاط Wireshark (كما هو موضح أعلاه)، يمكنك أن ترى أن الشهادة تم توقيعها من مرجع مصدق عام وأن السلسلة الكاملة تم إرسالها إلى Cisco Webex. لذلك، لا ينبغي أن تكون المسألة مرتبطة بشهادة Expressway-E.

عند هذه النقطة، إذا كانت هناك حاجة إلى مزيد من العزل، فيمكنك التقاط حزمة من الواجهة الخارجية لجدار الحماية. ومع ذلك، يعد عدم وجود خطأ SSL في سجل التشخيص نقطة بيانات مهمة. إذا استرجعت أعلاه (الإصدار 3.)، إذا لم يكن Cisco Webex يثق في شهادة Expressway-E، فيجب أن ترى نوع ما من سبب انقطاع SSL. في هذه الحالة، لم يتوفر خطأ SSL.

ملاحظة: إذا كنت تريد الحصول على التقاط حزمة من جدار الحماية خارج الواجهة، فلن ترى TCP RST يأتي في من بيئة Cisco Webex.

الحل

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

المسألة 5. يتم توقيع Expressway-E من قبل CA العام ولكن يتم تحميل شهادات بديلة من Cisco Webex Control Hub

قد يحدث هذا الشرط المحدد غالبا عند نشر حل Expressway من البداية وليس لديك شهادة Expressway-E موقعة من مرجع مصدق عام في البداية. ما يحدث في هذا السيناريو هو أن تقوم بتحميل شهادة خادم Expressway-E (التي تم توقيعها داخليا) إلى محور التحكم في Cisco Webex حتى يمكنك إكمال مفاوضات TLS المتبادلة بنجاح. بعد ذلك، ينتهي بك الأمر بالحصول على شهادة Expressway-E الموقعة من مرجع مصدق عام، ومع ذلك تنسى إزالة شهادة الخادم من محور التحكم في Cisco Webex. من المهم معرفة أنه عند تحميل شهادة إلى محور التحكم في Cisco Webex، فإن تلك الشهادة تأخذ الأولوية على الشهادة والسلسلة التي يقدمها Expressway أثناء مصافحة TLS.

من منظور تسجيل تشخيصي ل Expressway-E، قد تبدو هذه المشكلة مماثلة لتوقيع التسجيل الذي يتم تلقيه عندما لا يثق Cisco Webex في شهادة Expressway-E — على سبيل المثال، حالة عدم إرسال Expressway-E سلسلسلتها الكاملة أو عدم توقيع شهادة Expressway-E بواسطة مرجع مصدق عام تثق فيه Cisco Webex. في ما يلي عينة مما يمكنك توقعه في تسجيل الدخول إلى موقع Expressway-E أثناء مصافحة TLS:

2017-09-20T10:22:13.669-04:00 amer-expressway01 tvcs: Event="Inbound TLS Negotiation Error" Service="SIP" Src-ip="146.20.193.45" Src-port="48520" Dst-ip="172.16.2.2" Dst-port="5062" Detail="sslv3 alert certificate unknown" Protocol="TLS" Level="1" UTCTime="2017-09-20 14:22:13,668"

2017-09-20T10:22:13.669-04:00 amer-expressway01 tvcs: UTCTime="2017-09-20 14:22:13,668" Module="developer.ssl" Level="ERROR" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(68)" Method="::TTSSLErrorOutput" Thread="0x7f4a2c16f700": TTSSL_continueHandshake: Failed to establish SSL connection iResult="0" error="1" bServer="true" localAddress="['IPv4''TCP''172.16.2.2:5062']" remoteAddress="['IPv4''TCP''146.20.193.45:48520']" ssl_error_reason="error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown"

2017-09-20T10:22:13.669-04:00 amer-expressway01 tvcs: UTCTime="2017-09-20 14:22:13,668" Module="network.tcp" Level="DEBUG":  Src-ip="146.20.193.45" Src-port="48520" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connection Closed" Reason="Got EOF on socket"

ألق نظرة على هذا من منظور Wireshark يمكنك أن ترى هنا أن Expressway-E يقدم شهادته في البند 175 من السطر. بعد بضعة عناصر سطر، ترفض بيئة Cisco WebEx الشهادة التي تحتوي على خطأ "شهادة غير معروفة" كما هو موضح في الصورة.

إذا حددت حزمة الشهادة التي يرسلها Expressway-E، يمكنك توسيع معلومات الشهادة لتحديد ما إذا كان Expressway-E

1. موقع بواسطة مرجع مصدق عام يثق Cisco Webex، و

2 - يشمل كامل سلسلته المشمولة بالتوقيع.

وفي هذه الحالة، يتم الوفاء بهذين الشرطين. وهذا يشير إلى أنه لا يوجد خطأ في شهادة Expressway-E.

الحل

الخطوة 1. قم بتسجيل الدخول إلى Cisco Webex Control Hub.

الخطوة 2. حدد الخدمات من الجزء الأيسر.

الخطوة 3. أختر الإعدادات ضمن بطاقة الاتصال المختلطة.

الخطوة 4. قم بالتمرير إلى قسم "الاتصال بخدمة الاتصال" وانظر أسفل "الشهادات" لمكالمات SIP المشفرة لمعرفة ما إذا كانت الشهادات غير المرغوب فيها مدرجة. إذا كان الأمر كذلك، انقر أيقونة سلة المهملات الموجودة بجوار الشهادة.

الخطوة 5. حدد إزالة.

ملاحظة: من المهم إجراء التحليل وتحديد أن العميل لا يستخدم الشهادات التي تم تحميلها إلى Webex Control Hub قبل إزالتها.

لمزيد من المعلومات حول تحميل شهادة Expressway-E في لوحة التحكم Cisco Webex، تحقق من هذا القسم من دليل نشر المكالمات المختلطة.

المسألة 6. لا يقوم Expressway بتعيين المكالمة الواردة لمنطقة DNS المختلطة ل Cisco Webex

تعمل ميزة تعيين TLS الواردة بالاقتران مع اسم الموضوع للتحقق من صحة TLS، والذي تم تكوين كليهما على منطقة DNS للمكالمة المختلطة. ويبين هذا السيناريو القضايا والتحديات التي لوحظت في الطريق السريع قبل x12.5. في x12 وفيما بعد تم تنفيذ نوع منطقة جديد يسمى منطقة "Webex". تقوم هذه المنطقة بملء جميع التكوين المطلوب مسبقا للتكامل مع Webex. إذا كنت تقوم بتشغيل X12.5 ونشر مكالمة Webex المختلطة، فمن المستحسن إستخدام نوع منطقة Webex بحيث يتم تكوين مجال خدمات المكالمات المختلطة (callservice.webex.com) تلقائيا لك. تتطابق هذه القيمة مع الاسم البديل للموضوع لشهادة Webex التي يتم تقديمها أثناء مصافحة TLS المتبادلة وتسمح بنجاح الاتصال والتعيين الوارد إلى Expressway.

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

تنقسم الميزة إلى عملية من ثلاث خطوات:

1. يقبل Expressway-E شهادة Cisco Webex.

2. يفحص ExpressWay-E شهادة Cisco Webex لتحديد ما إذا كان هناك اسم موضوع بديل يطابق اسم موضوع التحقق من TLS: callservice.ciscospark.com.

3. يقوم Expressway-E بتعيين الاتصال الوارد من خلال منطقة Cisco Webex Hybrid DNS Zone.

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

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

2017-09-22T10:09:56.471-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 14:09:56,471" Module="network.tcp" Level="DEBUG":  Src-ip="148.62.40.52" Src-port="44205" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connecting"

2017-09-22T10:09:56.471-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 14:09:56,471" Module="network.tcp" Level="DEBUG":  Src-ip="148.62.40.52" Src-port="44205" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connection Established"

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

2017-09-22T10:09:57.044-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 14:09:57,044" Module="developer.ssl" Level="INFO" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1974)" Method="::ttssl_continueHandshake" Thread="0x7f044e7cc700":  Detail="Handshake in progress" Reason="want read/write"

2017-09-22T10:09:57.123-04:00 amer-expressway01 tvcs: Event="Inbound TLS Negotiation Error" Service="SIP" Src-ip="148.62.40.52" Src-port="44205" Dst-ip="172.16.2.2" Dst-port="5062" Detail="Peer's TLS certificate identity was unacceptable" Protocol="TLS" Level="1" UTCTime="2017-09-22 14:09:57,123"

2017-09-22T10:09:57.123-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 14:09:57,123" Module="network.tcp" Level="DEBUG":  Src-ip="148.62.40.52" Src-port="44205" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connection Closed" Reason="Peer's TLS certificate identity was unacceptable"

انظر إلى هذا الوضع من منظور PCAP، يمكنك الحصول على إحساس أفضل

- الذي يرسل RST، و

- ما هي الشهادات التي يتم تمريرها لتحديد ما إذا كانت صحيحة.

عندما تقوم بتحليل هذا الالتقاط المعين، يمكنك أن ترى أن Expressway-E يرسل RST. عندما تنظر إلى شهادة Cisco Webex التي تم تمريرها، يمكنك أن ترى أنها ترسل السلسلة الكاملة. وبالإضافة إلى ذلك، يمكنك إستنتاج أنه استنادا إلى رسالة الخطأ في سجل التشخيص، يمكنك إستبعاد السيناريو الذي لا يثق فيه Expressway-E في بطاقات CA العامة من Cisco Webex. وإلا، سترى خطأ مثل الشهادة الموقعة ذاتيا في سلسلة الشهادات". يمكنك التنقيب في تفاصيل الحزمة كما هو موضح في الصورة.

بالنقر على شهادة خادم Webex وتوسيعها لترى موضوع الأسماء البديلة (dnsName) يمكنك التحقق للتأكد من أنها مدرجة في callService.ciscospark.com.

انتقل إلى Wireshark: شهادة > امتداد > أسماء عامة > GeneralName > dNSNname: callservice.ciscospark.com

هذا يؤكد تماما أن شهادة Webex تبدو جيدة.

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

*c xConfiguration Zones Zone 6 DNS SIP TLS Verify Mode: "On"

*c xConfiguration Zones Zone 6 DNS SIP TLS Verify Subject Name: "callservice.ciscospark.com"

الشيء التالي الذي يجب التحقيق فيه هو قيام TLS بالتحقق من التعيين الوارد. وهذا يؤكد ما إذا كنت تقوم بتعيين اتصال TLS بشكل صحيح بمنطقة DNS المختلطة ل Webex. ويمكن الاستفادة من xConfiguration لتحليل هذا أيضا. في التكوين x يسمى TLS التحقق من التعيين الوارد ب DNS ZIP TLS التحقق من التصنيف الوارد. كما ترى في هذا المثال، يتم تعيين القيمة على إيقاف.

*c xConfiguration Zones Zone 6 DNS SIP TLS Verify InboundClassification: "Off"

*c xConfiguration Zones Zone 6 Name: "Hybrid Call Services DNS"

بافتراض تعيين هذه القيمة إلى "إيقاف"، فإن ما يعنيه هذا هو منع VCS من محاولة تعيين إتصالات TLS الواردة إلى هذه المنطقة. ومن ثم تدخل المكالمة إلى المنطقة الافتراضية ويتم فحصها وتوجيهها وفقا لقواعد البحث المتوفرة لسيناريوهات الاتصال بين الشركات، إذا تم تكوين الاتصال بين الشركات على Expressway-E.

الحل

يجب تعيين تعيين تعيين TLS للتحقق من صحة التعيين الوارد على منطقة DNS الخاصة بالمكالمة المختلطة إلى "تشغيل". وإليكم الخطوات اللازمة لإكمال ذلك.

1. تسجيل الدخول إلى Expressway-E

2. انتقل إلى التكوين > مناطق > مناطق

3. تحديد منطقة DNS للاستدعاء المختلط

4. للتحقق من تعيين TLS الوارد، أختر تشغيل

5. حدد حفظ

ملاحظة: راجع سلوك تسجيل الخط الأساسي. يعرض هذا القسم التحقق من صحة شهادة Expressway والتعيين لمنطقة Webex Hybrid DNS.

المسألة 7. يستخدم Expressway-E شهادة ذاتية التوقيع افتراضية

في بعض عمليات النشر الجديدة ل Hybrid Call Service Connect، يتم تجاهل توقيع شهادة Expressway-E أو يعتقد أنه يمكن إستخدام شهادة الخادم الافتراضية. يعتقد بعض الأشخاص أن هذا ممكن لأن لوحة وصل التحكم في Cisco Webex تتيح لك تحميل شهادة مخصصة في البوابة. (خدمات > إعدادات (ضمن بطاقة الاتصال المختلطة) > تحميل (تحت شهادات المكالمات المشفرة)

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

عندما تقوم باستكشاف مشكلة تطابق هذه الحالة وإصلاحها، تذكر أن العرض سيعتمد على إتجاه المكالمة. إذا تم إنشاء المكالمة بواسطة هاتف محلي، فيمكنك توقع عدم اتصال تطبيق Cisco Webex. أيضا، إذا حاولت تتبع المكالمة من "محفوظات البحث في Expressway"، فستجد أن المكالمة ستنجح في الوصول إلى Expressway-E وتتوقف هناك. إذا كان المكالمة قد نشأت من تطبيق Cisco Webex وكانت موجهة إلى المباني، فإن الهاتف المحلي لا يرن. في هذه الحالة، فإن تاريخ سلسلة Expressway-E و Expressway-C لن يظهر أي شيء.

في هذا السيناريو الخاص، تم إنشاء المكالمة من هاتف محلي. باستخدام "محفوظات البحث" في Expressway-E، يمكنك تحديد أن المكالمة وصلت إلى الخادم. عند هذه النقطة، يمكنك الغوص في تسجيل التشخيص لتحديد ما حدث. لبدء هذا التحليل، ابحث أولا لمعرفة ما إذا تم محاولة اتصال TCP وإنشائه عبر المنفذ 5062. بالبحث في سجلات تشخيص Expressway-E ل "TCP يربط" والبحث في عنصر الخط مع العلامة "dst-port=5062"، يمكنك تحديد ما إذا كان الاتصال يؤسس.

2017-09-26T08:18:08.428-04:00 amer-expressway01 tvcs: UTCTime="2017-09-26 12:18:08,426" Module="network.tcp" Level="DEBUG":  Src-ip="146.20.193.45" Src-port="59720" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connecting"

2017-09-26T08:18:08.428-04:00 amer-expressway01 tvcs: UTCTime="2017-09-26 12:18:08,426" Module="network.tcp" Level="DEBUG":  Src-ip="146.20.193.45" Src-port="59720" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connection Established"

الآن بعد تأكيد اتصال TCP الذي تم إنشاؤه، يمكنك تحليل مصافحة TLS المتبادلة التي تحدث بعد ذلك مباشرة. كما ترى في القصاصة هنا، يفشل المصافحة والشهادة غير معروفة (تفصيل="sslv3 تنبيه شهادة غير معروفة")

2017-09-26T08:18:08.441-04:00 amer-expressway01 tvcs: UTCTime="2017-09-26 12:18:08,441" Module="developer.ssl" Level="INFO" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1974)" Method="::ttssl_continueHandshake" Thread="0x7f930adab700":  Detail="Handshake in progress" Reason="want read/write"

2017-09-26T08:18:08.455-04:00 amer-expressway01 tvcs: Event="Inbound TLS Negotiation Error" Service="SIP" Src-ip="146.20.193.45" Src-port="59720" Dst-ip="172.16.2.2" Dst-port="5062" Detail="sslv3 alert certificate unknown" Protocol="TLS" Level="1" UTCTime="2017-09-26 12:18:08,455"

2017-09-26T08:18:08.455-04:00 amer-expressway01 tvcs: UTCTime="2017-09-26 12:18:08,455" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1997)" Method="::ttssl_continueHandshake" Thread="0x7f930adab700":  Detail="Handshake Failed" Reason="want error ssl"

2017-09-26T08:18:08.455-04:00 amer-expressway01 tvcs: UTCTime="2017-09-26 12:18:08,455" Module="developer.ssl" Level="ERROR" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(68)" Method="::TTSSLErrorOutput" Thread="0x7f930adab700": TTSSL_continueHandshake: Failed to establish SSL connection iResult="0" error="1" bServer="true" localAddress="['IPv4''TCP''172.16.2.2:5062']" remoteAddress="['IPv4''TCP''146.20.193.45:59720']" ssl_error_reason="error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown"

2017-09-26T08:18:08.455-04:00 amer-expressway01 tvcs: UTCTime="2017-09-26 12:18:08,455" Module="network.tcp" Level="DEBUG":  Src-ip="146.20.193.45" Src-port="59720" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connection Closed" Reason="Got EOF on socket"

راجع التقاط الحزمة المزود بتسجيل تشخيص Expressway-E عن كثب، يمكنك أن ترى أن خطأ "الشهادة غير المعروفة" يتم الحصول على مصدر منه من إتجاه Cisco Webex كما هو موضح في الصورة.

إذا قمت بفحص شهادة الخادم الافتراضية من Expressway-E، يمكنك أن ترى أن 'الاسم الشائع' و'موضوع الأسماء البديلة' لا تحتوي على 'المجال الذي تم التحقق منه' (rtp.ciscotac.net). ثم لديك أدلة حول أسباب هذه المشكلة كما هو موضح في الصورة.

عند هذه النقطة، قررت أنه يجب توقيع شهادة خادم Expressway-E إما من مرجع مصدق عام أو مرجع مصدق داخلي.

الحل

in order to حللت هذا إصدار، أنت تتلقى إثنان خيار:

1. اطلب توقيع شهادة Expressway-E بواسطة مرجع مصدق عام يثق فيه Cisco Webex.

1. قم بتسجيل الدخول إلى Expressway.

2. انتقل إلى الصيانة > التأمين > شهادة الخادم.

3. حدد إنشاء CSR.

4. أدخل معلومات الشهادة المطلوبة وتأكد من أن حقل الأسماء البديلة الإضافية يحتوي على المجال الذي تم التحقق منه المدرج في Webex Control Hub.

5. انقر فوق إنشاء CSR.

6. تقديم CSR إلى مرجع مصدق عام من جهة خارجية للتوقيع.

7. عند إرجاع الشهادة، انتقل إلى الصيانة > التأمين > شهادات الخادم.

8. في قسم تحميل شهادة جديدة بجوار تحديد ملف شهادة الخادم، حدد إختيار ملف وحدد الشهادة الموقعة.

9. حدد تحميل بيانات شهادة الخادم.

10. انتقل إلى الصيانة > التأمين > شهادة المرجع المصدق الموثوق به.

11. في قسم التحميل الموجود بجوار تحديد الملف الذي يحتوي على شهادات CA الموثوق بها حدد إختيار الملف.

12. حدد أي شهادات CA جذرية أو متوسطة مقدمة من المرجع المصدق العام.

13. حدد إضافة شهادة مرجع مصدق.

14. قم بإعادة تشغيل Expressway-E.

2. اطلب توقيع شهادة Expressway-E من قبل CA داخلي ثم تحميل CA الداخلي و Expressway-E إلى Cisco Webex Control Hub.

1. تسجيل الدخول إلى Expressway

2. انتقل إلى الصيانة > التأمين > شهادة الخادم.

3. حدد إنشاء CSR

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

5. انقر إنشاء CSR

6. تقديم CSR إلى مرجع مصدق عام من جهة خارجية للتوقيع

7. عند إرجاع الشهادة، انتقل إلى الصيانة > التأمين > شهادات الخادم

8. في قسم تحميل شهادة جديدة بجوار تحديد ملف شهادة الخادم، حدد إختيار ملف وحدد الشهادة الموقعة

9. تحديد تحميل بيانات شهادة الخادم

10. انتقل إلى الصيانة > التأمين > شهادة المرجع المصدق الثقة

11. في قسم التحميل المجاور حدد الملف الذي يحتوي على شهادات CA حدد إختيار ملف.

12. حدد أي شهادات CA جذرية أو متوسطة مقدمة من المرجع المصدق العام.

13. حدد إضافة شهادة مرجع مصدق.

14. قم بإعادة تشغيل Expressway-E.

2 أ. تحميل شهادة CA و Expressway-E الداخلية إلى محور التحكم في Cisco Webex

1. سجل الدخول إلى محور التحكم في Cisco Webex كمسؤول.

2. حدد الخدمات.

3. حدد الإعدادات ضمن بطاقة خدمة المكالمات المختلطة.

4. في قسم شهادات مكالمات SIP المشفرة، حدد تحميل.

5. أختر شهادتي CA و Expressway-E الداخليتين.

الوارد: Cisco Webex إلى محلي

ينتج عن كل إخفاق Cisco Webex وارد إلى محلي تقريبا نفس العرض الذي تم الإبلاغ عنه: "عندما أتصل من تطبيق Cisco Webex الخاص بي إلى تطبيق زميل آخر، يرن تطبيق الزميل ولكن الهاتف المحلي لا." لاستكشاف أخطاء هذا السيناريو وإصلاحها، ستجد من المفيد فهم كل من تدفق المكالمات والمنطق الذي يحدث عند وضع هذا النوع من المكالمات.

تدفق منطقي عالي المستوى

1. يقوم الطرف المتصل بتطبيق Cisco Webex بتهيئة المكالمة

2. تم إستدعاء حلقات تطبيق الحزب

3. يتم إرسال المكالمة إلى بيئة Cisco Webex

4. يجب أن تقوم بيئة Cisco Webex بإجراء بحث DNS استنادا إلى وجهة SIP التي تم تكوينها للعميل في لوحة التحكم Cisco Webex

5. تحاول بيئة Cisco Webex الاتصال ب Expressway over Port 5062

6. تحاول بيئة Cisco Webex إجراء مصافحة TLS متبادلة

7. ترسل بيئة Cisco Webex دعوة SIP إلى Expressway والتي يتم تمريرها إلى نقطة نهاية التعاون المحلية/هاتف بروتوكول الإنترنت

8. أكمل Cisco Webex والمؤسسة تفاوض SIP

9. تبدأ Cisco Webex والمؤسسة في إرسال الوسائط واستقبالها.

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

انتقل إلى تطبيق Cisco Webex > بيئة Cisco Webex > Expressway-E > Expressway-C > نقطة نهاية التعاون/هاتف بروتوكول الإنترنت (IP) المحلي كما هو موضح في الصورة.

فيما يلي بعض القضايا المشتركة التي تمت ملاحظتها مع المكالمات الواردة من Webex إلى البنية الأساسية المحلية.

المسألة 1. يتعذر على Cisco Webex حل Expressway-E DNS SRV/hostname

عند التفكير في تدفق المكالمات محليا إلى Cisco Webex، فإن الخطوة المنطقية الأولى ل Cisco Webex هي كيفية الاتصال ب Expressway المحلي. وكما تمت الإشارة إليه أعلاه، سيحاول Cisco Webex الاتصال ب ExpressWay المحلي من خلال إجراء بحث SRV استنادا إلى وجهة SIP التي تم تكوينها والمدرجة في صفحة إعدادات خدمة المكالمات المختلطة في Cisco Webex Control Hub.

إذا حاولت أستكشاف أخطاء هذه الحالة وإصلاحها من منظور سجل تشخيص Expressway-E، فلن ترى أي حركة مرور من Cisco Webex. إذا حاولت البحث عن اتصال TCP، فلن ترى DST-port=5062، ولن ترى أي مصافحة MTLS أو دعوة SIP لاحقة من Cisco Webex.

إذا كان هذا هو الموقف، فيجب عليك التحقق من كيفية تكوين وجهة SIP في Cisco Webex Control Hub. يمكنك أيضا إستخدام أداة إختبار الاتصال المختلط للمساعدة في أستكشاف الأخطاء وإصلاحها. تتحقق "أداة إختبار الاتصال المختلط" من ما إذا كان هناك عنوان DNS صالح، وما إذا كان يمكن ل Cisco Webex الاتصال بالمنفذ الذي تم إرجاعه في البحث عن SRV، وما إذا كان Expressway المحلي لديه شهادة صالحة يثق فيها Cisco Webex.

1. تسجيل الدخول إلى Cisco Webex Control Hub

2. SelectServices

3. حدد Settingslink في بطاقة المكالمات المختلطة.

4. في قسم "اتصال خدمة الاتصال"، تحقق من المجال المستخدم للعنوان SIP DestinationField العام ل SIP.

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

6. كما هو موضح أدناه، يمكنك أن ترى بوضوح أن المجال العام لا يحتوي على سجل SIP SRV مطابق مرتبط به كما هو موضح في الصورة.

حدد عرض نتائج الاختبار ويمكنك رؤية المزيد من التفاصيل حول ما فشل كما هو موضح في الصورة.

وكنهج آخر، يمكنك أيضا البحث عن سجل SRV باستخدام NSLOOKUP. هنا الأوامر التي يمكنك تشغيلها للتحقق من وجود وجهة SIP.

C:\Users\pstojano>nslookup

> server 8.8.8.8

Default Server: google-public-dns-a.google.com

Address: 8.8.8.8

> set type=SRV

> _sips._tcp.mtls.rtp.ciscotac.net

Server: google-public-dns-a.google.com

Address: 8.8.8.8

DNS request timed out.

timeout was 2 seconds.

DNS request timed out.

timeout was 2 seconds.

*** Request to google-public-dns-a.google.com timed-out

كما يمكنك أن ترى في كتلة الرمز أعلاه، تم بدء الأمر nslookup ثم تم تعيين الخادم على 8.8.8.8 وهو خادم Google DNS عام. أخيرا، أنت تقوم بتعيين أنواع السجلات للبحث عن سجلات SRV. عند تلك النقطة، يمكنك عندئذ إصدار سجل SRV الكامل الذي تريد البحث عنه. والنتيجة النهائية هي أن الطلبات تنتهي في نهاية المطاف.

الحل

1. قم بتكوين عنوان SIP SRV عام ل Expressway-E على الموقع الذي يستخدمه لاستضافة أسماء المجالات العامة.

2. تكوين اسم مضيف سيتم الحل إلى عنوان IP العام الخاص ب Expressway-E

3. قم بتكوين وجهة SIP لسرد المجال المستخدم لعنوان SIP SRV الذي تم إنشاؤه في الخطوة 1.

1. تسجيل الدخول إلى Cisco Webex Control Hub

2. تحديد الخدمات

3. حدد إرتباط الإعدادات في بطاقة الاتصال المختلطة

4. في قسم "اتصال خدمة الاتصال"، أدخل المجال المستخدم لعنوان SIP SRV العام في حقل وجهة SIP.

5. تحديد حفظ

ملاحظة: إذا كان سجل SIP SRV الذي ترغب في إستخدامه يتم الاستفادة منه بالفعل للاتصالات من عمل إلى عمل، فإننا نوصي بتحديد مجال فرعي لمجال الشركة كعنوان اكتشاف SIP في محور التحكم من Cisco Webex، وبالتالي سجل DNS SRV عام، على النحو التالي:

الخدمة والبروتوكول: _sips._tcp.mtls.example.com

الأولوية: 1

الوزن: 10

رقم المنفذ: 5062

الهدف: us-expe1.example.com

تم سحب التوصية المذكورة أعلاه مباشرة من دليل التصميم المختلط من Cisco Webex.

حل بديل

إذا لم يكن لدى العميل سجل SIP SRV موجود (ولا يخطط لإنشاء سجل)، فيمكنه بدلا من ذلك سرد عنوان IP العام من Expressway المحدد ب ":5062". ومن خلال القيام بذلك، لن تحاول بيئة Webex البحث عن SRV ولكنها ستتصل مباشرة ب ٪Expressway_pub_ip٪:5062. (على سبيل المثال: 64.102.241.236:5062)

1. قم بتكوين وجهة SIP ليتم تنسيقها على أنها ٪Expressway_Pub_IP٪:5062. (مثال: 64.102.241.236:5062)

1. تسجيل الدخول إلى Cisco Webex Control Hub

2. تحديد الخدمات

3. حدد إرتباط الإعدادات في بطاقة الاتصال المختلطة

4. في قسم "اتصال خدمة الاتصال"، أدخل ٪Expressway_PUB_IP٪:5062 في حقل وجهة SIP.

5. تحديد حفظ

للحصول على مزيد من المعلومات حول عنوان وجهة SIP و/أو سجل SRV الذي يجب إعداده. ارجع إلى قسم enable Hybrid Call Service Connect لمؤسستك من دليل نشر خدمة المكالمات المختلطة من Cisco WebEx أو دليل التصميم المختلط من Cisco Webex.

المسألة 2. فشل المأخذ: تم حظر المنفذ 5062 داخل Expressway

بعد اكتمال تحليل DNS، تحاول بيئة Cisco Webex إنشاء اتصال TCP عبر المنفذ 5062 إلى عنوان IP الذي تم إرجاعه أثناء البحث عن DNS. سيكون عنوان IP هذا هو عنوان IP العام الخاص ب Expressway-E المحلي. إذا كانت بيئة Cisco Webex غير قادرة على إنشاء اتصال TCP هذا، فسيفشل الاتصال الوارد إلى البنية لاحقا. عرض هذه الحالة الخاصة هو نفس عرض كل فشل مكالمات Cisco Webex الواردة الأخرى تقريبا: الهاتف الداخلي لا يرن.

إذا كنت تقوم باستكشاف أخطاء هذه المشكلة وإصلاحها باستخدام سجلات تشخيص Expressway، فلن ترى أي حركة مرور من Cisco Webex. إذا حاولت البحث عن اتصال TCP، فلن ترى أي محاولات اتصال ل Dst-port=5062، ولن ترى أي مصافحة MTLS أو دعوة SIP لاحقة من Cisco Webex. نظرا لأن تسجيل الدخول التشخيصي ل Expressway-E غير مستخدم في هذه الحالة، فلديك عدد قليل من الطرق الممكنة للتحقق:

1. الحصول على التقاط حزمة من الواجهة الخارجية لجدار الحماية

2. الاستفادة من أداة فحص المنفذ

3. إستخدام أداة إختبار الاتصال المختلطة

ونظرا لأنه يتم دمج أداة إختبار الاتصال المختلط مباشرة في لوحة التحكم Cisco Webex Control Hub ومحاكاة بيئة Cisco WebEx في محاولة الاتصال بمسار Expressway المحلي، فإنها طريقة التحقق الأكثر مثالية المتاحة. لاختبار اتصال TCP في المؤسسة:

1. تسجيل الدخول إلى Cisco Webex Control Hub

2. SelectServices

3. حدد Settingslink في بطاقة المكالمات المختلطة

4. في قسم "اتصال خدمة الاتصال"، تأكد من أن القيمة التي تم إدخالها في وجهة SIP صحيحة

5. انقر إختبار كما هو موضح في الصورة.

6. نظرا لفشل الاختبار، يمكنك النقر فوق إرتباط عرض نتائج الاختبار للتحقق من التفاصيل كما هو موضح في الصورة.

كما هو موضح في الصورة أعلاه، يمكنك أن ترى أن إختبار المقبس فشل عند محاولة الاتصال ب 64.102.241.236:5062. مع عدم إظهار هذه البيانات بالإضافة إلى سجلات تشخيص/حروف PCAP الخاصة ب Expressway أي محاولات اتصال، لديك الآن دليل كاف للتحقيق في تكوين قائمة التحكم في الوصول (ACL)/NAT/التوجيه لجدار الحماية.

الحل

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

المسألة 3. فشل المقبس: لا يصغي Expressway-E على المنفذ 5062

وغالبا ما تشخص هذه الحالة على نحو غير صحيح. مرات عديدة، يفترض أن جدار الحماية هو السبب في منع حركة مرور البيانات عبر المنفذ 5062. لاستكشاف أخطاء هذه الحالة الخاصة وإصلاحها، يمكنك إستخدام التقنيات الموجودة في سيناريو "منع المنفذ 5062 الوارد إلى Expressway" أعلاه. ستجد أن أداة إختبار الاتصال المختلط وأي أداة أخرى تستخدم للتحقق من اتصال المنفذ ستفشل. أول إفتراض هو أن الجدار الناري يعطل حركة المرور. بعد ذلك، سيقوم معظم الأشخاص بالتحقق مرتين من التسجيل التشخيصي من Expressway-E لتحديد ما إذا كان بإمكانهم رؤية اتصال TCP الذي يحاول إنشاء. سيبحثون بشكل عام عن عنصر سطر سجل مثل هذا كما هو موضح في الصورة.

2017-09-19T14:01:46.462-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 18:01:46,461" Module="network.tcp" Level="DEBUG":  Src-ip="146.20.193.73" Src-port="40342" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connecting"

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

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

كما ترى في التقاط الحزمة الذي تم الحصول عليه من Expressway-E، لا يتم حظر حركة مرور البيانات عبر منفذ TCP رقم 5062 بواسطة جدار الحماية ولكنها تصل في الواقع. في الحزمة رقم 56، يمكنك أن ترى أن Expressway-E يرسل RST مباشرة بعد وصول حزمة TCP syn الأولية. مع هذه المعلومات، يمكنك إستنتاج أن المشكلة معزولة إلى Expressway-E الذي يتلقى الحزمة، يجب عليك أستكشاف المشكلة وإصلاحها من منظور Expressway-E. ونظرا للدليل، تأمل في الأسباب المحتملة التي قد تدفع Expressway-E إلى إرسال الحزمة. هناك احتمالان يمكن أن ينسبوا إلى هذا السلوك وهما:

1. يحتوي Expressway-E على نوع ما من قواعد جدار الحماية التي يمكن أن تمنع حركة المرور

2. لا ينصت Expressway-E لحركة مرور TLS المتبادلة و/أو لا ينصت لحركة المرور عبر المنفذ 5062.

توجد وظائف جدار الحماية الخاصة ب Expressway-E ضمن النظام > الحماية > قواعد جدار الحماية > التكوين. عند التحقق من هذا في هذه البيئة، لم يكن هناك تكوين جدار حماية موجود.

هناك عدة طرق للتحقق مما إذا كان Expressway-E يستمع لحركة مرور TLS المتبادلة عبر المنفذ 5062. يمكنك تنفيذ هذا الإجراء إما من خلال واجهة الويب أو واجهة سطر الأوامر كمستخدم جذري.

من جذر الطريق السريع، إذا قمت بإصدار netstat -an | جرو ':5062'، يجب أن تحصل على بعض المخرجات مشابهة لما تراه أدناه.

~ # netstat -an | grep ':5062'

tcp        0      0 172.16.2.2:5062         0.0.0.0:*               LISTEN  <-- Outside Interface

tcp        0      0 192.168.1.6:5062        0.0.0.0:*               LISTEN  <-- Inside Interface

tcp        0      0 127.0.0.1:5062          0.0.0.0:*               LISTEN

tcp        0      0 ::1:5062                :::*                    LISTEN

كما يمكن التقاط هذه المعلومات من خلال واجهة الويب الخاصة ب Expressway-E. راجع الخطوات التالية لتجميع هذه المعلومات

1. سجل الدخول إلى Expressway-E

2. انتقل إلى أدوات الصيانة > إستخدام المنفذ > المنافذ الداخلية المحلية

3. البحث عن نوع SIP ومنفذ IP 5062. (مبرزة باللون الأحمر كما هو موضح في الصورة)

الآن بعد أن عرفت ما ينبغي عليك رؤيته، يمكنك مقارنة ذلك بالبيئة الحالية. من منظور واجهة سطر الأوامر (CLI)، عند تشغيل netstat | GREP ':5062'، يبدو المخرج بهذا الشكل:

~ # netstat -an | grep ':5062'

tcp        0      0 127.0.0.1:5062          0.0.0.0:*               LISTEN

tcp        0      0 ::1:5062                :::*                    LISTEN

~ #

بالإضافة إلى ذلك، لا تظهر وحدة التحكم في الإنترنت منفذ TLS المتبادل المدرج تحت المنافذ الواردة المحلية

باستخدام هذه البيانات، يمكنك الاستنتاج بأن Expressway-E لا يصغي لحركة مرور TLS المتبادلة.

الحل

لحل هذه المشكلة، يجب عليك التأكد من تمكين وضع TLS المتبادل ومن تعيين منفذ TLS المتبادل على 5062 على Expressway-E:

1. تسجيل الدخول إلى Expressway-E

2. انتقل إلى التكوين > البروتوكولات > SIP

3. تأكد من تعيين وضع TLS المتبادل على تشغيل

4. تأكد من تعيين المنفذ المشترك TLS على 5062

5. انقر على حفظ كما هو موضح في الصورة.

المسألة 4. لا يدعم Expressway-E أو C رؤوس مسار SIP المحملة مسبقا

باستخدام اتصال خدمة المكالمات المختلطة، يتم توجيه المكالمات استنادا إلى رأس المسار. يتم تعبئة رأس المسار استنادا إلى المعلومات التي يقدمها جزء "إدراك خدمة الاتصال" (Expressway Connector) من الحل إلى Cisco Webex. يستعلم المضيف الخاص بموصل Expressway عن "تنسيق CM الموحد" للمستخدمين الذين تم تمكينهم لخدمة المكالمات ويسحب كلا من URI الخاص بدليلهم وFQDN الخاص بمجموعة CM Home الموحدة الخاصة بهم. انظروا إلى هذا المثال، باستخدام أليس وبوب:

URI للدليل

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

bob@example.com

emea-cucm.example.com

alice@example.com

us-cucm.example.com

إذا قامت أليس أو بوب بإجراء مكالمة، يتم توجيه المكالمة إلى CM المحلي الموحد حتى يمكن إرساؤها إلى Cisco WebexRD قبل التوجيه إلى المستخدم المتصل.

إذا اتصلت أليس ببوب، سيتم توجيه المكالمة إلى مجموعة Unified CM Home FQDN لأليس (us-cucm.example.com). إذا قمت بتحليل دعوة SIP التي يرسلها Cisco Webex واردة إلى Expressway-E، فستجد المعلومات التالية داخل رأس SIP

طلب URI

SIP: bob@example.com

رأس المسار

sip:us-cucm.example.com؛lr

من منظور Expressway، يتم تكوين قواعد البحث لتوجيه المكالمة ليس بواسطة URI الخاص بالطلب بل بواسطة رأس المسار (us-cucm.example.com) — في هذه الحالة مجموعة CM الرئيسية الموحدة الخاصة بأليس.

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

قبل تحليل سجلات التشخيص على Expressway، ضع في الاعتبار كيفية تحديد هذه المكالمة:

1. سيكون URI الخاص بطلب SIP هو URI للدليل الخاص بالطرف المستدعى.

2. سيتم تنسيق حقل SIP FROM باستخدام جهة الاتصال المدرجة ك "الاسم الأول لاسم العائلة" <sip:WebexDisplayName@subdomain.call.ciscospark.com>

باستخدام هذه المعلومات، يمكنك البحث في سجلات التشخيص بواسطة URI للدليل الخاص بالطرف المتصل، أو الاسم الأول واسم العائلة للطرف المتصل، أو عنوان SIP ل Cisco Webex. إذا لم يكن لديك أي من هذه المعلومات، فيمكنك البحث في دعوة SIP:" الذي يحدد موقع جميع مكالمات SIP التي تعمل عبر Expressway. بمجرد تحديد دعوة SIP للاتصال الوارد، يمكنك بعد ذلك تحديد موقع معرف مكالمة SIP ونسخه. بعد الحصول على هذه القيمة، يمكنك ببساطة البحث في سجلات التشخيص المستندة إلى معرف المكالمة للاطلاع على جميع الرسائل المرتبطة بجهة الاتصال هذه.

هناك شيء آخر للمساعدة في عزل مشكلة التوجيه وهو تحديد مدى دخول المكالمة إلى المؤسسة. يمكنك محاولة البحث عن المعلومات المشار إليها أعلاه على Expressway-C لمعرفة ما إذا كان قد تم توجيه المكالمة إلى هذا الحد. إذا كان الامر كذلك، فمن المرجح انكم ترغبون في الابتداء بتحقيقكم هناك.

في هذا السيناريو، يمكنك أن ترى أن Expressway-C قد تلقت الدعوة من Expressway-E.

2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-19 18:16:15,830" Module="network.sip" Level="DEBUG": Action="Received" Local-ip="192.168.1.5" Local-port="26847" Src-ip="192.168.1.6" Src-port="7003" Msg-Hash="11449260850208794722"

SIPMSG:

|INVITE sip:jorobb@rtp.ciscotac.net SIP/2.0

Via: SIP/2.0/TLS 192.168.1.6:7003;egress-zone=HybridCallServiceTraversal;branch=z9hG4bKc81c6c4dddef7ed6be5bdce9868fb019913;proxy-call-id=a82052ef-6fd7-4506-8173-e73af6655b5d;rport

Via: SIP/2.0/TLS 192.168.1.6:5073;branch=z9hG4bKb0eba6d700dfdf761a8ad97fff3c240124;x-cisco-local-service=nettle;received=192.168.1.6;rport=43119;ingress-zone=DefaultZone

Via: SIP/2.0/TLS 64.102.241.236:5061;egress-zone=DefaultZone;branch=z9hG4bK6fe399bae58fb0d70c9d69b8e37e13e5912.4248943487bff4af6f649b586c7696bb;proxy-call-id=f2d15853-c81f-462f-b3e5-c08124f344a3;received=172.16.2.2;rport=25016

Via: SIP/2.0/TLS 192.168.5.66:5062;branch=z9hG4bK0f455ca79cf1b0af5637333aa5286436;received=146.20.193.45;rport=35464;ingress-zone=HybridCallServicesDNS

Via: SIP/2.0/TLS 127.0.0.1:5070;branch=z9hG4bK-383039-8f0d64025c04d23b6d5e1d5142db46ec;rport=52706

Call-ID: 9062bca7eca2afe71b4a225048ed5101@127.0.0.1

CSeq: 1 INVITE

Contact: <sip:192.168.1.6:5073;transport=tls>;call-type=squared

From: "pstojano test"

;tag=872524918

To: <sip:jorobb@rtp.ciscotac.net>

Max-Forwards: 15

Route:

Record-Route: <sip:proxy-call-id=a82052ef-6fd7-4506-8173-e73af6655b5d@192.168.1.6:7003;transport=tls;lr>

Record-Route: <sip:proxy-call-id=a82052ef-6fd7-4506-8173-e73af6655b5d@192.168.1.6:5061;transport=tls;lr>

الأمر المهم هو أن رأس المسار (Cluster FQDN) لا يزال سليما. ومع ذلك، لا يوجد منطق بحث يتم إجراؤه استنادا إلى رأس المسار (مجموعة FQDN) cucm.rtp.ciscotac.net. بدلا من ذلك، ترى الرسالة يتم رفضها على الفور مع 404 لم يتم العثور عليها.

2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: Event="Call Attempted" Service="SIP" Src-ip="192.168.1.6" Src-port="7003" Src-alias-type="SIP" Src-alias="sip:pstojano-test@dmzlab.call.ciscospark.com" Dst-alias-type="SIP" Dst-alias="sip:jorobb@rtp.ciscotac.net" Call-serial-number="a3e44231-f62a-4e95-a70e-253701a89515" Tag="73c276e2-3917-4a0c-9fc5-ddde83b49fd0" Protocol="TLS" Auth="NO" Level="1" UTCTime="2017-09-19 18:16:15,832"

2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: Event="Search Attempted" Service="SIP" Src-alias-type="SIP" Src-alias="pstojano-test@dmzlab.call.ciscospark.com" Dst-alias-type="SIP" Dst-alias="sip:jorobb@rtp.ciscotac.net" Call-serial-number="a3e44231-f62a-4e95-a70e-253701a89515" Tag="73c276e2-3917-4a0c-9fc5-ddde83b49fd0" Detail="searchtype:INVITE" Level="1" UTCTime="2017-09-19 18:16:15,834"

2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: Event="Search Completed" Reason="Not Found" Service="SIP" Src-alias-type="SIP" Src-alias="pstojano-test@dmzlab.call.ciscospark.com" Dst-alias-type="SIP" Dst-alias="sip:jorobb@rtp.ciscotac.net" Call-serial-number="a3e44231-f62a-4e95-a70e-253701a89515" Tag="73c276e2-3917-4a0c-9fc5-ddde83b49fd0" Detail="found:false, searchtype:INVITE, Info:Policy Response" Level="1" UTCTime="2017-09-19 18:16:15,835"

2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: Event="Call Rejected" Service="SIP" Src-ip="192.168.1.6" Src-port="7003" Src-alias-type="SIP" Src-alias="sip:pstojano-test@dmzlab.call.ciscospark.com" Dst-alias-type="SIP" Dst-alias="sip:jorobb@rtp.ciscotac.net" Call-serial-number="a3e44231-f62a-4e95-a70e-253701a89515" Tag="73c276e2-3917-4a0c-9fc5-ddde83b49fd0" Detail="Not Found" Protocol="TLS" Response-code="404" Level="1" UTCTime="2017-09-19 18:16:15,835"

2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-19 18:16:15,830" Module="network.sip" Level="INFO": Action="Received" Local-ip="192.168.1.5" Local-port="26847" Src-ip="192.168.1.6" Src-port="7003" Detail="Receive Request Method=INVITE, CSeq=1, Request-URI=sip:jorobb@rtp.ciscotac.net, Call-ID=9062bca7eca2afe71b4a225048ed5101@127.0.0.1, From-Tag=872524918, To-Tag=, Msg-Hash=11449260850208794722, Local-SessionID=daf7c278732bb5a557fb57925dffcbf7, Remote-SessionID=00000000000000000000000000000000"

2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-19 18:16:15,836" Module="network.sip" Level="INFO": Action="Sent" Local-ip="192.168.1.5" Local-port="26847" Dst-ip="192.168.1.6" Dst-port="7003" Detail="Sending Response Code=404, Method=INVITE, CSeq=1, To=sip:jorobb@rtp.ciscotac.net, Call-ID=9062bca7eca2afe71b4a225048ed5101@127.0.0.1, From-Tag=872524918, To-Tag=96b9a0eaf669a590, Msg-Hash=254718822158415175, Local-SessionID=00000000000000000000000000000000, Remote-SessionID=daf7c278732bb5a557fb57925dffcbf7"

2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-19 18:16:15,836" Module="network.sip" Level="DEBUG": Action="Sent" Local-ip="192.168.1.5" Local-port="26847" Dst-ip="192.168.1.6" Dst-port="7003" Msg-Hash="254718822158415175"

SIPMSG:

|SIP/2.0 404 Not Found

Via: SIP/2.0/TLS 192.168.1.6:7003;egress-zone=HybridCallServiceTraversal;branch=z9hG4bKc81c6c4dddef7ed6be5bdce9868fb019913;proxy-call-id=a82052ef-6fd7-4506-8173-e73af6655b5d;received=192.168.1.6;rport=7003;ingress-zone=HybridCallServiceTraversal

Via: SIP/2.0/TLS 192.168.1.6:5073;branch=z9hG4bKb0eba6d700dfdf761a8ad97fff3c240124;x-cisco-local-service=nettle;received=192.168.1.6;rport=43119;ingress-zone=DefaultZone

Via: SIP/2.0/TLS 64.102.241.236:5061;egress-zone=DefaultZone;branch=z9hG4bK6fe399bae58fb0d70c9d69b8e37e13e5912.4248943487bff4af6f649b586c7696bb;proxy-call-id=f2d15853-c81f-462f-b3e5-c08124f344a3;received=172.16.2.2;rport=25016

Via: SIP/2.0/TLS 192.168.5.66:5062;branch=z9hG4bK0f455ca79cf1b0af5637333aa5286436;received=146.20.193.45;rport=35464;ingress-zone=HybridCallServicesDNS

Via: SIP/2.0/TLS 127.0.0.1:5070;branch=z9hG4bK-383039-8f0d64025c04d23b6d5e1d5142db46ec;rport=52706

Call-ID: 9062bca7eca2afe71b4a225048ed5101@127.0.0.1

CSeq: 1 INVITE

From: "pstojano test"

;tag=872524918

To: <sip:jorobb@rtp.ciscotac.net>;tag=96b9a0eaf669a590

Server: TANDBERG/4135 (X8.10.2)

Warning: 399 192.168.1.5:5061 "Policy Response"

Session-ID: 00000000000000000000000000000000;remote=daf7c278732bb5a557fb57925dffcbf7

Content-Length: 0

مقارنة بسيناريو عمل، سترى أنه في سيناريو العمل يتم تنفيذ منطق البحث استنادا إلى رأس الموجه (FQDN لمجموعة)

2017-09-22T13:56:02.215-04:00 rtp12-tpdmz-118-VCSC tvcs: Event="Search Attempted" Service="SIP" Src-alias-type="SIP" Src-alias="pstojano-test@dmzlab.call.ciscospark.com" Dst-alias-type="SIP" Dst-alias="sip:jorobb@rtp.ciscotac.net" Call-serial-number="17aa8dc7-422c-42ef-bdd9-b9750fbd0edf" Tag="8bd936da-f2ab-4412-96df-d64558f7597b" Detail="searchtype:INVITE" Level="1" UTCTime="2017-09-22 17:56:02,215"

2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,217" Module="network.cpl" Level="DEBUG": Remote-ip="192.168.1.6" Remote-port="7003" Detail="CPL: <routed> "

2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.cpl" Level="DEBUG": Remote-ip="192.168.1.6" Remote-port="7003" Detail="CPL: <location clear="yes" url="sip:cucm.rtp.ciscotac.net;lr" diversion="" dest-url-for-message="sip:jorobb@rtp.ciscotac.net" sip-route-set="" dest-service=""> added sip:cucm.rtp.ciscotac.net;lr to location set "

2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.cpl" Level="DEBUG": Remote-ip="192.168.1.6" Remote-port="7003" Detail="CPL: <proxy stop-on-busy="no" timeout="0"/> "

2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.search" Level="DEBUG": Detail="Search rule 'Inbound MS to CMS' did not match destination alias 'cucm.rtp.ciscotac.net;lr'"

2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.search" Level="DEBUG": Detail="Search rule 'multiway' did not match destination alias 'cucm.rtp.ciscotac.net;lr'"

2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.search" Level="DEBUG": Detail="Search rule 'WebEx Search Rule' did not match destination alias 'cucm.rtp.ciscotac.net;lr'"

2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.search" Level="DEBUG": Detail="Search rule 'ISDN Inbound' ignored due to source filtering"

2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.search" Level="DEBUG": Detail="Search rule 'recalls into CMS' did not match destination alias 'cucm.rtp.ciscotac.net;lr'"

2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.search" Level="DEBUG": Detail="Search rule 'CEtcp-rtp12-tpdmz-118-ucmpub' did not match destination alias 'cucm.rtp.ciscotac.net;lr'"

2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.search" Level="DEBUG": Detail="Search rule 'Conference Factory' did not match destination alias 'cucm.rtp.ciscotac.net;lr'"

2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,219" Module="network.search" Level="DEBUG": Detail="Search rule 'Inbound B2B Calling' did not match destination alias 'cucm.rtp.ciscotac.net;lr'"

2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,219" Module="network.search" Level="DEBUG": Detail="Search rule 'Calls to Cisco Webex' did not match destination alias 'cucm.rtp.ciscotac.net;lr'"

2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,219" Module="network.search" Level="DEBUG": Detail="Considering search rule 'as is local' towards target 'LocalZone' at priority '1' with alias 'cucm.rtp.ciscotac.net;lr'"

2017-09-22T13:56:02.219-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,219" Module="network.search" Level="DEBUG": Detail="Considering search rule 'Hybrid Call Service Inbound Routing' towards target 'CUCM11' at priority '2' with alias 'cucm.rtp.ciscotac.net;lr'"

يمكنك حينئذ ملاحظة أن المحول Expressway-C يقوم بإعادة توجيه المكالمة بشكل صحيح إلى وحدة التحكم CM الموحدة (192.168.1.21).

2017-09-22T13:56:02.232-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,232" Module="network.sip" Level="DEBUG": Action="Sent" Local-ip="192.168.1.5" Local-port="25606" Dst-ip="192.168.1.21" Dst-port="5065" Msg-Hash="866788495063340574"

SIPMSG:

|INVITE sip:jorobb@rtp.ciscotac.net SIP/2.0

Via: SIP/2.0/TCP 192.168.1.5:5060;egress-zone=CUCM11;branch=z9hG4bK251d6daf044e635607cc13d244b9ea45138220.69ccb8de20a0e853c1313782077f77b5;proxy-call-id=17aa8dc7-422c-42ef-bdd9-b9750fbd0edf;rport

Via: SIP/2.0/TLS 192.168.1.6:7003;egress-zone=HybridCallServiceTraversal;branch=z9hG4bKba323da436b2bc288200d56d11f02d4d272;proxy-call-id=32c76cef-e73c-4911-98d0-e2d2bb6fec77;received=192.168.1.6;rport=7003;ingress-zone=HybridCallServiceTraversal

Via: SIP/2.0/TLS 192.168.1.6:5073;branch=z9hG4bK06cde3f662d53a210b5b4b11b85500c19;x-cisco-local-service=nettle;received=192.168.1.6;rport=42533;ingress-zone=DefaultZone

Via: SIP/2.0/TLS 64.102.241.236:5061;egress-zone=DefaultZone;branch=z9hG4bK297799f31d0785ff7449e1d7dbe3595b271.2ed90cbed5b79c6cffad9ecd84cc8337;proxy-call-id=3be87d96-d2e6-4489-b936-8f9cb5ccaa5f;received=172.16.2.2;rport=25005

Via: SIP/2.0/TLS 192.168.4.146:5062;branch=z9hG4bK043ca6360f253c6abed9b23fbeff9819;received=148.62.40.64;rport=36149;ingress-zone=HybridCallServicesDNS

Via: SIP/2.0/TLS 127.0.0.1:5070;branch=z9hG4bK-353038-8c648a16c2c5d7b85fa5c759d59aa190;rport=47732

Call-ID: daa1a6fa546ce76591fc464f0a50ee32@127.0.0.1

CSeq: 1 INVITE

Contact: <sip:192.168.1.6:5073;transport=tls>;call-type=squared

From: "pstojano test" <sip:pstojano-test@dmzlab.call.ciscospark.com>;tag=567490631

To: <sip:jorobb@rtp.ciscotac.net>

Max-Forwards: 14

Route:

Record-Route: <sip:proxy-call-id=17aa8dc7-422c-42ef-bdd9-b9750fbd0edf@192.168.1.5:5060;transport=tcp;lr>

Record-Route: <sip:proxy-call-id=17aa8dc7-422c-42ef-bdd9-b9750fbd0edf@192.168.1.5:5061;transport=tls;lr>

Record-Route: <sip:proxy-call-id=32c76cef-e73c-4911-98d0-e2d2bb6fec77@192.168.1.6:7003;transport=tls;lr>

Record-Route: <sip:proxy-call-id=32c76cef-e73c-4911-98d0-e2d2bb6fec77@192.168.1.6:5061;transport=tls;lr>

Allow: INVITE,ACK,BYE,CANCEL,INFO,OPTIONS,REFER,SUBSCRIBE,NOTIFY

User-Agent: TANDBERG/4352 (X8.10.2-b2bua-1.0)

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

1. يتم نقل المكالمات من المناطق وإليها على الطريق السريع من خلال قواعد البحث.

2. يستخدم منطق Expressway الذي يسمى دعم مسارات SIP المحملة مسبقا والذي يعالج طلبات دعوة SIP التي تحتوي على رأس الموجه. يمكن تشغيل هذه القيمة أو إيقاف تشغيلها في المناطق (خادم التقاطع، عميل التقاطع، المجاور) على كل من Expressway-C و Expressway-E.

يمكنك الآن إستخدام xConfiguration لعرض التكوين على كل من خادم Expressway-E Traversal ومناطق عميل Expressway-C، وخاصة المناطق التي تم إعدادها ل Hybrid Call Service Connect. بالإضافة إلى تكوين المنطقة، يمكنك تحليل قواعد البحث التي تم تكوينها لتمرير هذا الاستدعاء من منطقة إلى أخرى. كما تعرف أن Expressway-E قام بتمرير المكالمة إلى Expressway-C حتى يكون تكوين منطقة خادم Traversal هناك قد تم إعداده بشكل صحيح.

ولتقسيم هذا الأمر، يخبرنا xConfig أدناه بأن اسم هذه المنطقة يسمى Hybrid Call Service Traversal. إنه من نوع منطقة TraversalServer. إنه يتصل ب Expressway-C عبر SIP TCP ميناء 7003.

الجزء الرئيسي ل Hybrid Call Service هو أنه يجب أن يكون لديها دعم مسارات SIP المحملة مسبقا قيد التشغيل. تقوم واجهة ويب Expressway بطلب دعم مسارات SIP المحملة مسبقا لهذه القيمة، بينما سيقوم التكوين xبعرضها كقبول SIP المحمل مسبقا

Expressway-E

*c xConfiguration Zones Zone 7 Name: "Hybrid Call Service Traversal"

*c xConfiguration Zones Zone 7 TraversalServer Authentication Mode: "DoNotCheckCredentials"

*c xConfiguration Zones Zone 7 TraversalServer Authentication UserName: "hybridauth"

*c xConfiguration Zones Zone 7 TraversalServer Collaboration Edge: "Off"

*c xConfiguration Zones Zone 7 TraversalServer H323 H46019 Demultiplexing Mode: "Off"

*c xConfiguration Zones Zone 7 TraversalServer H323 Port: "6007"

*c xConfiguration Zones Zone 7 TraversalServer H323 Protocol: "Assent"

*c xConfiguration Zones Zone 7 TraversalServer Registrations: "Allow"

*c xConfiguration Zones Zone 7 TraversalServer SIP Media AesGcm Support: "Off"

*c xConfiguration Zones Zone 7 TraversalServer SIP Media Encryption Mode: "Auto"

*c xConfiguration Zones Zone 7 TraversalServer SIP Media ICE Support: "Off"

*c xConfiguration Zones Zone 7 TraversalServer SIP Multistream Mode: "On"

*c xConfiguration Zones Zone 7 TraversalServer SIP ParameterPreservation Mode: "On"

*c xConfiguration Zones Zone 7 TraversalServer SIP Poison Mode: "Off"

*c xConfiguration Zones Zone 7 TraversalServer SIP Port: "7003"

*c xConfiguration Zones Zone 7 TraversalServer SIP PreloadedSipRoutes Accept: "On"

*c xConfiguration Zones Zone 7 TraversalServer SIP Protocol: "Assent"

*c xConfiguration Zones Zone 7 TraversalServer SIP TLS Verify Mode: "On"

*c xConfiguration Zones Zone 7 TraversalServer SIP TLS Verify Subject Name: "rtp12-tpdmz-118-VCSC.rtp.ciscotac.net"

*c xConfiguration Zones Zone 7 TraversalServer SIP Transport: "TLS"

*c xConfiguration Zones Zone 7 TraversalServer TCPProbe KeepAliveInterval: "20"

*c xConfiguration Zones Zone 7 TraversalServer TCPProbe RetryCount: "5"

*c xConfiguration Zones Zone 7 TraversalServer TCPProbe RetryInterval: "2"

*c xConfiguration Zones Zone 7 TraversalServer UDPProbe KeepAliveInterval: "20"

*c xConfiguration Zones Zone 7 TraversalServer UDPProbe RetryCount: "5"

*c xConfiguration Zones Zone 7 TraversalServer UDPProbe RetryInterval: "2"

*c xConfiguration Zones Zone 7 Type: "TraversalServer"

يمكنك أيضا تحديد أن هذه المنطقة بها قاعدة بحث 3 (Webex Hybrid) مرتبطة بها. تقوم قاعدة البحث في الأساس بإرسال اسم مستعار "أي" يأتي من خلال منطقة DNS لخدمات المكالمات المختلطة وتمريره إلى المنطقة أعلاه، وهو عبارة عن تبادل خدمة المكالمات المختلطة. كما هو متوقع، تم تكوين كل من منطقة قاعدة البحث وخادم العبور بشكل صحيح.

*c xConfiguration Zones Policy SearchRules Rule 3 Authentication: "No"

*c xConfiguration Zones Policy SearchRules Rule 3 Description: "Calls to VCS-C"

*c xConfiguration Zones Policy SearchRules Rule 3 Mode: "AnyAlias"

*c xConfiguration Zones Policy SearchRules Rule 3 Name: "Webex Hybrid"

*c xConfiguration Zones Policy SearchRules Rule 3 Pattern Behavior: "Strip"

*c xConfiguration Zones Policy SearchRules Rule 3 Pattern Replace:

*c xConfiguration Zones Policy SearchRules Rule 3 Pattern String:

*c xConfiguration Zones Policy SearchRules Rule 3 Pattern Type: "Prefix"

*c xConfiguration Zones Policy SearchRules Rule 3 Priority: "15"

*c xConfiguration Zones Policy SearchRules Rule 3 Progress: "Stop"

*c xConfiguration Zones Policy SearchRules Rule 3 Protocol: "SIP"

*c xConfiguration Zones Policy SearchRules Rule 3 SIPTrafficType: "Any"

*c xConfiguration Zones Policy SearchRules Rule 3 Source Mode: "Named"

*c xConfiguration Zones Policy SearchRules Rule 3 Source Name: "Hybrid Call Services DNS"

*c xConfiguration Zones Policy SearchRules Rule 3 State: "Enabled"

*c xConfiguration Zones Policy SearchRules Rule 3 SystemGenerated: "No"

*c xConfiguration Zones Policy SearchRules Rule 3 Target Name: "Hybrid Call Service Traversal"

*c xConfiguration Zones Policy SearchRules Rule 3 Target SIPVariant: "Any"

*c xConfiguration Zones Policy SearchRules Rule 3 Target Type: "Zone"

إذا قمت بالتركيز على xConfiguration الخاص ب Expressway-C، فيمكنك البدء بالبحث عن منطقة عميل Traversal ل Webex Hybrid. إحدى الطرق السهلة للعثور عليها هي البحث في رقم المنفذ الذي تعلمته من تكوين Expressway-E (منفذ SIP: "7003"). يساعدك هذا على التعرف بسرعة على المنطقة الصحيحة في xConfiguration.

وكما هو الحال من قبل، يمكنك التعرف على اسم المنطقة (إجتياز خدمة المكالمات المختلطة) والنوع (عميل العبور) وما تم تكوينه ل SIP الذي تم تحميله مسبقا قبول SipRoute (دعم مسارات SIP المحملة مسبقا). كما ترى من هذا xConfiguration، تم تعيين هذه القيمة إلى "إيقاف". استنادا إلى دليل النشر لخدمات المكالمات المختلطة من Cisco Webex، يجب تعيين هذه القيمة على "تشغيل".

بالإضافة إلى ذلك، إذا فحصنا تعريف دعم مسارات SIP المحملة مسبقا، يمكننا أن نرى بوضوح أن Expressway-C يجب أن يرفض رسالة إذا تم تعيين هذه القيمة على "إيقاف التشغيل" وكان INVIT يحتوي على رأس مسار: "قم بتبديل دعم مسارات SIP المحملة مسبقا إذا كنت تريد أن تقوم المنطقة برفض طلبات دعوة SIP التي تحتوي على هذا الرأس.

Expressway-C

*c xConfiguration Zones Zone 6 Name: "Hybrid Call Service Traversal"

*c xConfiguration Zones Zone 6 TraversalClient Accept Delegated Credential Checks: "Off"

*c xConfiguration Zones Zone 6 TraversalClient Authentication Mode: "DoNotCheckCredentials"

*c xConfiguration Zones Zone 6 TraversalClient Authentication Password: "{cipher}qeh8eq+fuVY1GHGgRLder/1lYDd76O/6KrHGA7g8bJs="

*c xConfiguration Zones Zone 6 TraversalClient Authentication UserName: "hybridauth"

*c xConfiguration Zones Zone 6 TraversalClient Collaboration Edge: "Off"

*c xConfiguration Zones Zone 6 TraversalClient H323 Port: "1719"

*c xConfiguration Zones Zone 6 TraversalClient H323 Protocol: "Assent"

*c xConfiguration Zones Zone 6 TraversalClient Peer 1 Address: "amer-expressway01.ciscotac.net"

*c xConfiguration Zones Zone 6 TraversalClient Peer 2 Address:

*c xConfiguration Zones Zone 6 TraversalClient Peer 3 Address:

*c xConfiguration Zones Zone 6 TraversalClient Peer 4 Address:

*c xConfiguration Zones Zone 6 TraversalClient Peer 5 Address:

*c xConfiguration Zones Zone 6 TraversalClient Peer 6 Address:

*c xConfiguration Zones Zone 6 TraversalClient Registrations: "Allow"

*c xConfiguration Zones Zone 6 TraversalClient RetryInterval: "120"

*c xConfiguration Zones Zone 6 TraversalClient SIP Media AesGcm Support: "Off"

*c xConfiguration Zones Zone 6 TraversalClient SIP Media Encryption Mode: "Auto"

*c xConfiguration Zones Zone 6 TraversalClient SIP Media ICE Support: "Off"

*c xConfiguration Zones Zone 6 TraversalClient SIP Multistream Mode: "On"

*c xConfiguration Zones Zone 6 TraversalClient SIP ParameterPreservation Mode: "On"

*c xConfiguration Zones Zone 6 TraversalClient SIP Poison Mode: "Off"

*c xConfiguration Zones Zone 6 TraversalClient SIP Port: "7003"

*c xConfiguration Zones Zone 6 TraversalClient SIP PreloadedSipRoutes Accept: "Off"

*c xConfiguration Zones Zone 6 TraversalClient SIP Protocol: "Assent"

*c xConfiguration Zones Zone 6 TraversalClient SIP TLS Verify Mode: "On"

*c xConfiguration Zones Zone 6 TraversalClient SIP TURN Server Address:

*c xConfiguration Zones Zone 6 TraversalClient SIP TURN Server Port:

*c xConfiguration Zones Zone 6 TraversalClient SIP Transport: "TLS"

*c xConfiguration Zones Zone 6 Type: "TraversalClient"

عند هذه النقطة، قمت بعزل المشكلة إلى تكوين غير صحيح لتكوين منطقة عميل إجتياز Expressway-C. يجب تبديل دعم مسارات SIP التي تم تحميلها مسبقا إلى تشغيل.

الحل

لتعيين دعم مسارات SIP التي تم تحميلها مسبقا بشكل صحيح:

1. تسجيل الدخول إلى Expressway-C

2. انتقل إلى التكوين > مناطق > مناطق

3. حدد منطقة عميل "تبادل خدمة المكالمات المختلطة" (ستختلف التسمية بين العميل والعميل)

4. تعيين دعم مسارات SIP المحملة مسبقا على تشغيل

5. حدد حفظ

ملاحظة: بينما يوضح هذا السيناريو الفشل على Expressway-C، يمكن ملاحظة نفس أخطاء التسجيل التشخيصية على ExpressWay-E إذا كان دعم مسارات SIP المحملة مسبقا قيد الإيقاف على منطقة Webex Hybrid Call Traversal Server. في هذه الحالة، لن ترى أبدا أن المكالمة تصل إلى الطريق السريع-C وأن الطريق السريع-E كان مسؤولا عن رفض المكالمة وإرسال ال 404 غير موجود.

المسألة 5. يتلقى تطبيق Cisco Webex إخطارين لاتصالات (أجهزة)

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

الإعلام الأول (TOAST) من الشخص الذي يبدأ المكالمة (طرف الاتصال) من جانب Cisco Webex. معرف الاستدعاء في هذا المثيل هو اسم العرض الخاص بالمستخدم الذي يقوم بتشغيل ذلك الاستدعاء. يأتي الإعلام الثاني (TOAST) من وحدة CTI أو Cisco Webex RD المحلية التي يتم تعيينها للمستخدم الذي يقوم بإجراء المكالمة. في البداية، يبدو هذا التصرف غريبا. ومع ذلك، إذا قمت بمراجعة الرسم التخطيطي للاتصال الوارد (من دليل تصميم المكالمات المختلطة من Cisco Webex)، فسيكون السلوك منطقيا بشكل أكبر كما هو موضح في الصورة.

من الرسم التوضيحي، يمكنك أن ترى أليس تتصل ببوب من تطبيق Cisco Webex وأنها تنزل المكالمة إلى المكان. يجب أن تتطابق هذه المكالمة مع URI الخاص بالدليل المعين لهاتف بوب. المشكلة هي أنه مع هذا التصميم، يتم تعيين URI الدليل أيضا إلى CTI-RD أو Cisco Webex RD. لذلك، عند تقديم المكالمة إلى CTI-RD أو Cisco Webex RD، يتم إرسال المكالمة إلى Cisco Webex لأن الجهاز لديه وجهة بعيدة تم تكوينها ل bob@example.call.ciscospark.com. الطريقة التي تتعامل بها Cisco Webex مع هذا الوضع هي أنها تلغي ساق الاتصال المحددة.

لكي تقوم Cisco Webex بإلغاء نقطة الاتصال بشكل صحيح، إحتاجت Cisco Webex في البداية إلى وضع معلمة في رأس SIP والتي سيبحث عنها لإلغاء هذه النقطة المحددة. المعلمة Cisco Webex تدخل في دعوة SIP وتدعى call-type=square" وتدخل هذه القيمة في رأس جهة الاتصال. إذا تم مسح هذه القيمة من الرسالة، فإن Cisco Webex لا يفهم كيفية إلغاء الاستدعاء.

مع هذه المعلومات، يمكنك إعادة النظر في السيناريو المقدم سابقا حيث كان تطبيق Cisco Webex الخاص بالمستخدم يتلقى إخطارين (علامتين) عندما كان مستخدم Cisco Webex جوناثان Robb يجري مكالمة. لاستكشاف أخطاء هذا النوع من المشاكل وإصلاحها، ستحتاج دائما إلى تجميع التسجيل التشخيصي من Expressway-C و Expressway-E. كنقطة بداية، يمكنك مراجعة سجلات Expressway-E لتحديد أن دعوة SIP تتضمن في الواقع القيمة call-type=square الموجودة في رأس جهة الاتصال الخاص بدعوة Cisco Webex الأولية المرسلة إلى الداخل. وسيضمن ذلك عدم تلاعب جدار الحماية بالرسالة بأي شكل من الأشكال. فيما يلي عينة مقتطفات من الدعوة الواردة إلى Expressway-E من هذا السيناريو.

2017-09-19T14:01:48.140-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 18:01:48,140" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="172.16.2.2" Local-port="5062" Src-ip="146.20.193.73" Src-port="40342" Msg-Hash="11658696457333185909"

SIPMSG:

|INVITE sip:pstojano-test@rtp.ciscotac.net SIP/2.0

Via: SIP/2.0/TLS 192.168.5.164:5062;branch=z9hG4bK564cd36d87f3417513c9b559dc666f71,SIP/2.0/TLS 127.0.0.1:5070;branch=z9hG4bK-3237-5c5060d07ecc546a0bb861ef52a5f507;rport=43306

Call-ID: 6bc0ca8210c0b48df69f38057ec1e48b@127.0.0.1

CSeq: 1 INVITE

Contact: "l2sip-UA" <sip:l2sip-UA@l2sip-cfa-01.wbx2.com:5062;transport=tls>;call-type=squared   <-- Webex inserted value

From: "Jonathan Robb"

;tag=540300020

To:

Max-Forwards: 70

Route:

,

تحتوي رأس جهة الاتصال على القيمة CALL-type=SQUARE الموجودة. عند هذه النقطة، يجب توجيه المكالمة عبر Expressway وإرسالها من منطقة خادم Webex المختلط التبادلي. يمكننا البحث في سجلات Expressway-E لتحديد كيفية إرسال المكالمة من Expressway-E. وسيعطينا ذلك فكرة عما إذا كان Expressway-E يتعامل مع الدعوة بأي شكل من الأشكال.

2017-09-19T14:01:48.468-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 18:01:48,468" Module="network.sip" Level="DEBUG":  Action="Sent" Local-ip="192.168.1.6" Local-port="7003" Dst-ip="192.168.1.5" Dst-port="26686" Msg-Hash="1847271284712495612"

SIPMSG:

INVITE sip:pstojano-test@rtp.ciscotac.net SIP/2.0

Via: SIP/2.0/TLS 192.168.1.6:7003;egress-zone=HybridCallServiceTraversal;branch=z9hG4bKec916b02b6d469abad0a30b93753f4b0859;proxy-call-id=d7372034-85d1-41f8-af84-dffed6d1a9a9;rport

Via: SIP/2.0/TLS 192.168.1.6:5073;branch=z9hG4bKd91699370129b4c10d09e269525de00c2;x-cisco-local-service=nettle;received=192.168.1.6;rport=43119;ingress-zone=DefaultZone

Via: SIP/2.0/TLS 64.102.241.236:5061;egress-zone=DefaultZone;branch=z9hG4bK52aac9a181192566e01b98ae0280bdff858.0e65cdfe078cabb269eecb6bce1328be;proxy-call-id=ec51e8da-e1a3-4210-95c9-494d12debcd8;received=172.16.2.2;rport=25016

Via: SIP/2.0/TLS 192.168.5.164:5062;branch=z9hG4bK564cd36d87f3417513c9b559dc666f71;received=146.20.193.73;rport=40342;ingress-zone=HybridCallServicesDNS

Via: SIP/2.0/TLS 127.0.0.1:5070;branch=z9hG4bK-3237-5c5060d07ecc546a0bb861ef52a5f507;rport=43306

Call-ID: 6bc0ca8210c0b48df69f38057ec1e48b@127.0.0.1

CSeq: 1 INVITE

Contact: <sip:192.168.1.6:5073;transport=tls>     <-- Webex inserted value is now missing

From: "Jonathan Robb"

;tag=540300020

To:

Max-Forwards: 15

Route: <sip:cucm.rtp.ciscotac.net;lr>

عند مراجعة دعوة SIP هذه التي يتم إرسالها من Expressway-E إلى Expressway-C، لاحظ أن رأس جهة الاتصال يفتقد مربع نوع المكالمة. هناك شيء آخر يجب الإشارة إليه وهو أنه في بند السطر 4، يمكنك أن ترى أن منطقة الخروج تساوي HybridCallServiceTraversal. يمكنك الآن إستنتاج أن السبب وراء حصول تطبيق Cisco Webex على إعلام ثان (إرسال تنبيه) عند الطلب هو بسبب تجريد Expressway-E لعلامة الاتصال=^2 من رأس SIP Invite Contact. السؤال الذي يجب الإجابة عليه هو ما الذي يمكن أن يسبب هذا الرأس المجرد.

يجب توجيه المكالمة عبر "خدمة المكالمات المختلطة" التي قمت بإعدادها على Expressway، لذا فهذا مكان مناسب لبدء التحقيق. إذا كان لديك xConfiguration، فيمكنك رؤية كيفية تكوين هذه المنطقة. لتحديد المنطقة في xConfiguration، يمكنك ببساطة إستخدام الاسم المسجل في سطر Via الذي تتم طباعته في السجلات. يمكنك أن ترى أعلاه كان يسمى egress-zone=HybridCallServiceTraversal. عندما يطبع هذا الاسم في سطر Via من رأس SIP، تتم إزالة الفراغات. سيكون لاسم المنطقة الحقيقية من منظور xConfiguration مسافات ويتم تنسيقه في Hybrid Call Service Traversal.

*c xConfiguration Zones Zone 7 TraversalServer Authentication Mode: "DoNotCheckCredentials"

*c xConfiguration Zones Zone 7 TraversalServer Authentication UserName: "hybridauth"

*c xConfiguration Zones Zone 7 TraversalServer Collaboration Edge: "Off"

*c xConfiguration Zones Zone 7 TraversalServer H323 H46019 Demultiplexing Mode: "Off"

*c xConfiguration Zones Zone 7 TraversalServer H323 Port: "6007"

*c xConfiguration Zones Zone 7 TraversalServer H323 Protocol: "Assent"

*c xConfiguration Zones Zone 7 TraversalServer Registrations: "Allow"

*c xConfiguration Zones Zone 7 TraversalServer SIP Media AesGcm Support: "Off"

*c xConfiguration Zones Zone 7 TraversalServer SIP Media Encryption Mode: "Auto"

*c xConfiguration Zones Zone 7 TraversalServer SIP Media ICE Support: "Off"

*c xConfiguration Zones Zone 7 TraversalServer SIP Multistream Mode: "On"

*c xConfiguration Zones Zone 7 TraversalServer SIP ParameterPreservation Mode: "Off" <-- Possible Suspect Value

*c xConfiguration Zones Zone 7 TraversalServer SIP Poison Mode: "Off"

*c xConfiguration Zones Zone 7 TraversalServer SIP Port: "7003"

*c xConfiguration Zones Zone 7 TraversalServer SIP PreloadedSipRoutes Accept: "On"   <-- Possible Suspect Value

*c xConfiguration Zones Zone 7 TraversalServer SIP Protocol: "Assent"

*c xConfiguration Zones Zone 7 TraversalServer SIP TLS Verify Mode: "On"

*c xConfiguration Zones Zone 7 TraversalServer SIP TLS Verify Subject Name: "rtp12-tpdmz-118-VCSC.rtp.ciscotac.net"

*c xConfiguration Zones Zone 7 TraversalServer SIP Transport: "TLS"

*c xConfiguration Zones Zone 7 TraversalServer TCPProbe KeepAliveInterval: "20"

*c xConfiguration Zones Zone 7 TraversalServer TCPProbe RetryCount: "5"

*c xConfiguration Zones Zone 7 TraversalServer TCPProbe RetryInterval: "2"

*c xConfiguration Zones Zone 7 TraversalServer UDPProbe KeepAliveInterval: "20"

*c xConfiguration Zones Zone 7 TraversalServer UDPProbe RetryCount: "5"

*c xConfiguration Zones Zone 7 TraversalServer UDPProbe RetryInterval: "2"

*c xConfiguration Zones Zone 7 Name: "Hybrid Call Service Traversal"

مع الإعدادات المحددة ل Hybrid Call Service Traversal، يمكنك البحث عن الإعدادات المحتملة التي تبرز، مثل:

- قبول SIP PreloadSIPRoutes: تشغيل

- وضع معلمة SIP Preservatoin: إيقاف تشغيل

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

دعم مسارات SIP المحملة مسبقا

قم بتشغيل تبديل مسارات SIP المحملة مسبقا لتمكين هذه المنطقة من معالجة طلبات دعوة SIP التي تحتوي على رأس المسار.

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

الاحتفاظ بمعلمة SIP

تحديد ما إذا كان BUA الخاص ب ExpressWay يحتفظ أو يعيد كتابة المعلمات في طلبات SIP الموجهة عبر هذه المنطقة.

حفظ URI الخاص بطلب SIP ومعلمات جهات الاتصال الخاصة بتوجيه الطلبات بين هذه المنطقة و B2BUA.

يتيح ل B2BUA إعادة كتابة URI الخاص بطلب SIP وبارامترات الاتصال الخاصة بتوجيه الطلبات بين هذه المنطقة و B2BUA، إذا لزم الأمر.

بناء على هذه التعريفات، xConfiguration، ووضع القيمة call-type=square في رأس "الاتصال" الخاص بدعوة SIP، يمكنك الاستنتاج بأن إيقاف تشغيل قيمة حفظ معلمة SIP في منطقة إجتياز خدمة الاتصال المختلطة هو السبب في سحب العلامة والحصول على تطبيق Cisco Webex على إعلامات مزدوجة الحلقة.

الحل

للحفاظ على القيمة CALL-type=SQUARE في رأس جهة الاتصال الخاص بدعوة SIP، يجب التأكد من أن Expressways تدعم حفظ معلمة SIP لجميع المناطق المعنية بمعالجة الاستدعاء:

1. تسجيل الدخول إلى Expressway-E

2. انتقل إلى التكوين > مناطق > مناطق

3. تحديد المنطقة التي يتم إستخدامها لخادم Traversal المختلط

4. تعيين قيمة الاحتفاظ بمعلمة SIP إلى On

5. قم بحفظ الإعدادات.

######################################################

ملاحظة: في هذا السيناريو، كانت منطقة خادم Webex Hybrid Traversal Server على Expressway-E غير مكونة بشكل صحيح. تذكر أنه من الممكن تماما تعيين قيمة حفظ معلمة SIP إلى "إيقاف تشغيل" في مناطق Webex Hybrid Traversal client أو CUCM المجاورة. سيتم تنفيذ كلا التكوينين على Expressway-C. إذا كان الأمر كذلك، يمكنك أن تتوقع أن يرسل Expressway-E قيمة نوع الاستدعاء=² إلى Expressway-C وأن يكون Expressway-C قد تم تجريده.

الصادر: محلي إلى Cisco Webex

ينتج عن كل فشل في المكالمات تقريبا والذي ينطوي على اتصال داخلي صادر ب Cisco Webex نفس العرض الذي تم الإبلاغ عنه: "عند الاتصال من هاتفي المسجل في CM الموحد بمستخدم آخر تم تمكينه لاتصال خدمة الاتصال، تظهر حلقات هواتفهم المحلية ولكن لا يأتي تطبيق Cisco Webex الخاص بها." لاستكشاف أخطاء هذا السيناريو وإصلاحها، من المهم فهم كل من تدفق المكالمات والمنطق الذي يحدث عند وضع هذا النوع من المكالمات.

تدفق منطقي عالي المستوى

1. يقوم المستخدم A بإجراء مكالمة من هاتف التشغيل المسبق الخاص به إلى URI الخاص بدليل المستخدم B

2. هاتف المستخدم B المحلي و CTI-RD/Webex-RD قبول المكالمة

3. يبدأ هاتف المستخدم (ب) المحلي في إظهار حلقات

4. يقوم CTI-RD/Webex-RD للمستخدم B برفع هذه المكالمة إلى وجهة UserB@example.call.ciscospark.com

5. يقوم Unified CM بتمرير هذه المكالمة إلى Expressway-C

6. يرسل Expressway-C المكالمة إلى Expressway-E

7. يقوم Expressway-E بإجراء بحث DNS على مجال callservice.ciscospark.com

8. يحاول Expressway-E الاتصال ببيئة Cisco Webex عبر المنفذ 5062.

9. يبدأ Expressway-E وبيئة Cisco Webex تبادل المصافحة

10. تقوم بيئة Cisco Webex بتمرير المكالمة إلى المستخدم B المتوفر في تطبيق Cisco Webex

11. يبدأ تطبيق Cisco Webex المتوفر للمستخدم B في إجراء التتابعات.

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

انتقل إلى هاتف المستخدم B الموجود مسبقا > Unified CM > CTI-RD/Webex-RD > Expressway-C > Expressway-E > بيئة Cisco Webex > تطبيق Cisco Webex كما هو موضح في الصورة.

ملاحظة: تم سحب الصورة من دليل تصميم Cisco Webex المختلط.

تلميحات تحليل السجل

إذا كنت تقوم باستكشاف أخطاء حالة فشلت فيها المكالمات المشفرة الصادرة إلى Cisco Webex، فستحتاج إلى تجميع سجلات Unified CM و Expressway-C و Expressway-E. بامتلاك هذه المجموعات من السجلات، يمكنك رؤية كيفية مرور المكالمة عبر البيئة. هناك طريقة سريعة أخرى لفهم مدى تلقي المكالمة داخل بيئة العمل لديك وهي إستخدام "محفوظات البحث" في Expressway. سوف تسمح لك "محفوظات بحث Expressway" بسرعة بإمكانية معرفة ما إذا كان إستدعاء Forked ل Cisco Webex هو الوصول إلى Expressway-C أو E.

لاستخدام "محفوظات البحث"، يمكنك تنفيذ ما يلي:

1. تسجيل الدخول إلى Expressway-E

إجراء مكالمة إختبار

انتقل إلى الحالة > محفوظات البحث

دققت إن يرى أنت مكالمة أن يتلقى غاية عنوان من Webex SIP URI أن يكون دعات (user@example.call.ciscospark.com)

إذا لم يظهر "محفوظات البحث" المكالمة التي تصل إلى محفوظات البحث في Expressway-E، فكرر هذه العملية على Expressway-C

قبل تحليل سجلات التشخيص على Expressway، ضع في الاعتبار كيفية تحديد هذه المكالمة:

1. سيكون URI طلب SIP عنوان SIP لمستخدم Cisco Webex

2. سيتم تنسيق حقل SIP FROM لكي يتم إدراج الطرف المتصل ك "الاسم الأول لاسم العائلة" <sip:Alias@Domain>

باستخدام هذه المعلومات، يمكنك البحث في سجلات التشخيص حسب URI للدليل الخاص بالطرف المتصل، أو الاسم الأول واسم العائلة لطرف الاتصال، أو عنوان SIP ل Cisco Webex. إذا لم يكن لديك أي من هذه المعلومات، فيمكنك إجراء بحث على دعوة SIP:" الذي سيحدد موقع جميع مكالمات SIP التي تعمل عبر الطريق السريع. بمجرد التعرف على دعوة SIP للاتصال الصادر، يمكنك بعد ذلك تحديد موقع معرف اتصال SIP ونسخه. بعد الحصول على هذا الإجراء، يمكنك ببساطة البحث في سجلات التشخيص استنادا إلى معرف المكالمة للاطلاع على جميع الرسائل المرتبطة بجهة الاتصال هذه.

فيما يلي بعض المشاكل الأكثر شيوعا التي تمت ملاحظتها مع المكالمات الصادرة من الهاتف المسجل في CM الموحد إلى بيئة Cisco WebEx عند إجراء المكالمات على مستخدم تم تمكينه للاتصال بخدمة Call Service Connect.

المسألة 1. يتعذر على Expressway حل عنوان callservice.ciscospark.com

يتمثل إجراء التشغيل القياسي لمنطقة DNS في Expressway في إجراء عمليات بحث DNS استنادا إلى المجال الذي يظهر على الجانب الأيمن من URI الخاص بالطلب. ولتوضيح ذلك، تأملوا في مثال. إذا تلقت منطقة DNS مكالمة تحتوي على URI للطلب من pstojano-test@dmzlab.call.ciscospark.com، فستؤدي منطقة Expressway DNS النموذجية منطق البحث DNS SRV على dmzlab.call.ciscospark.com الذي يعد الجانب الأيمن من URI للطلب. إذا كان Expressway سيقوم بذلك، يمكنك توقع حدوث البحث والاستجابة التاليين.

_sips._tcp.dmzlab.call.ciscospark.com.

Response: 5 10 5061 l2sip-cfa-01.wbx2.com.

l2sip-cfa-01.wbx2.com

Response: 146.20.193.64

إذا نظرت عن كثب، فسترى أن إستجابة سجل SRV توفر عنوان خادم ومنفذ 5061، وليس 5062.

هذا يعني أنه لن يحدث مصافحة TLS المتبادلة التي تحدث عبر المنفذ 5062 ويتم إستخدام منفذ منفصل لإرسال الإشارات بين Expressway و Cisco Webex. التحدي مع هذا هو أن دليل النشر لخدمات المكالمات المختلطة من Cisco Webex لا يدعو بشكل صريح إستخدام المنفذ 5061 لأن بعض البيئات لا تسمح للشركات بالاتصال بالعمل.

طريقة العمل بعد منطق البحث DNS Zone SRV القياسي هذا على Expressway هي تكوين Expressway حتى يتم إجراء عمليات بحث صريحة استنادا إلى قيمة تقوم بتوفيرها.

الآن عند تحليل هذه المكالمة المحددة، يمكنك التركيز على Expressway-E لأنك حددت (باستخدام محفوظات البحث) أن المكالمة وصلت إلى هذا الحد. ابدأ بأول دعوة SIP التي تأتي إلى Expressway-E لمعرفة المنطقة التي وصلت إليها، وقواعد البحث التي يتم إستخدامها، وأي منطقة يتم فيها إستدعاء، وإذا تم إرسالها بشكل صحيح إلى منطقة DNS، فما هو منطق البحث DNS الذي يحدث.

2017-09-19T13:18:50.562-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,556" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="192.168.1.6" Local-port="7003" Src-ip="192.168.1.5" Src-port="26686" Msg-Hash="4341754241544006348"

SIPMSG:

|INVITE sip:pstojano-test@dmzlab.call.ciscospark.com SIP/2.0

Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bK6d734eaf7a6d733bd1e79705b7445ebb46175.1d33be65c99c56898f85df813f1db3a7;proxy-call-id=47454c92-2b30-414a-b7fe-aff531296bcf;rport

Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK13187594dd412;received=192.168.1.21;ingress-zone=CUCM11

Call-ID: 991f7e80-9c11517a-130ac-1501a8c0@192.168.1.21

CSeq: 101 INVITE

Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=DESKTOP

Remote-Party-ID: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;party=calling;screen=yes;privacy=off

Contact: <sip:5010@192.168.1.21:5065;transport=tcp>;video;audio

From: "Jonathan Robb"

;tag=332677~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106860

To:

Max-Forwards: 15

Record-Route: <sip:proxy-call-id=47454c92-2b30-414a-b7fe-aff531296bcf@192.168.1.5:5061;transport=tls;lr>

Record-Route: <sip:proxy-call-id=47454c92-2b30-414a-b7fe-aff531296bcf@192.168.1.5:5060;transport=tcp;lr>

Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY

User-Agent: Cisco-CUCM11.5

Expires: 180

Date: Tue, 19 Sep 2017 17:18:50 GMT

Supported: timer,resource-priority,replaces,X-cisco-srtp-fallback,X-cisco-original-called

Session-Expires: 1800

Min-SE: 1800

Allow-Events: presence

X-TAATag: 2272025a-ce36-49d0-8d93-cb6a5e90ffe0

Session-ID: 75957d4fb66a13e835c10737aa332675;remote=00000000000000000000000000000000

Cisco-Guid: 2568978048-0000065536-0000000148-0352430272

Content-Type: application/sdp

Content-Length: 714

<SDP Omitted>

في دعوة SIP هذه، يمكنك تجميع URI للطلب (pstojano-test@dmzlab.call.ciscospark.com)، وCall-ID (991f7e80-9c11517a-130ac-1501a8c0)، من ("Jonathan Robb" <sip:5010@rtp.ciscotac.net>)، وإلى (sip:pstojano-test@dmzlab.call.ciscospark.com)، وUser-Agent (Cisco-CUCM11.5). بعد تلقي هذه الدعوة، يجب على Expressway الآن إتخاذ قرارات منطقية لتحديد ما إذا كان يمكنه توجيه المكالمة إلى منطقة أخرى. سيقوم Expressway بذلك استنادا إلى قواعد البحث.

2017-09-19T13:18:50.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,564" Module="network.search" Level="DEBUG":  Detail="Search rule 'B2B calls to VCS-C' did not match destination alias 'pstojano-test@dmzlab.call.ciscospark.com'"

2017-09-19T13:18:50.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,564" Module="network.search" Level="DEBUG":  Detail="Search rule 'Webex Hybrid' ignored due to source filtering"

2017-09-19T13:18:50.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,564" Module="network.search" Level="DEBUG":  Detail="Search rule 'Calls to Webex' did not match destination alias 'pstojano-test@dmzlab.call.ciscospark.com'"

2017-09-19T13:18:50.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,564" Module="network.search" Level="DEBUG":  Detail="Considering search rule 'Webex Hybrid - to Webex Cloud' towards target 'Hybrid Call Services DNS' at priority '90' with alias 'pstojano-test@dmzlab.call.ciscospark.com'"

استنادا إلى قصاصة السجل الواردة أعلاه، يمكنك أن ترى أن Expressway-E الذي تم تحليله من خلال أربع قواعد بحث، ومع ذلك تم مراعاة قاعدة واحدة فقط (Webex Hybrid - إلى Webex Cloud). كانت لقاعدة البحث أولوية من 90 وتم إستهدافها للانتقال إلى منطقة DNS لخدمات المكالمات المختلطة. الآن بعد إرسال المكالمة إلى منطقة DNS، يمكنك مراجعة عمليات بحث DNS SRV التي تحدث على Expressway-E

2017-09-19T13:18:50.565-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,565" Module="network.dns" Level="DEBUG":  Detail="Sending DNS query" Name="dmzlab.call.ciscospark.com" Type="NAPTR (IPv4 and IPv6)"

2017-09-19T13:18:50.718-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,718" Module="network.dns" Level="DEBUG":  Detail="Sending DNS query" Name="_sips._tcp.dmzlab.call.ciscospark.com" Type="SRV (IPv4 and IPv6)"

2017-09-19T13:18:50.795-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,795" Module="network.dns" Level="DEBUG":  Detail="Resolved hostname to:  ['IPv4''TCP''146.20.193.64:5061'] (A/AAAA)  Hostname:'l2sip-cfa-01.wbx2.com' Port:'5061' Priority:'5' TTL:'300' Weight:'10' (SRV) Number of relevant records retrieved: 2"

في القصاصة أعلاه، يمكنك أن ترى أن Expressway-E أجرى البحث SRV استنادا إلى الجانب الأيمن على URI الطلب (_sips._tcp.dmzlab.call.ciscospark.com) وقد تم الحل إلى اسم المضيف of l2sip-cfa-01.wbx2.com والمنفذ 5061. ويقرر الموقع hostname l2sip-cfa-01.wbx2.com ما يلي: 146.20.193.64. باستخدام هذه المعلومات، تتمثل الخطوة المنطقية التالية التي سيقوم بها Expressway في إرسال حزمة TCP SYN إلى 146.20.193.64 حتى يتمكن من محاولة إعداد المكالمة. من تسجيل Expressway-E، يمكنك المراجعة لمعرفة ما إذا كان هذا يحدث.

2017-09-19T13:18:51.145-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:51,145" Module="network.tcp" Level="DEBUG":  Src-ip="172.16.2.2" Src-port="25010" Dst-ip="146.20.193.64" Dst-port="5061" Detail="TCP Connecting"

2017-09-19T13:19:01.295-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:19:01,289" Module="network.tcp" Level="ERROR":  Src-ip="172.16.2.2" Src-port="25010" Dst-ip="146.20.193.64" Dst-port="5061" Detail="TCP Connection Failed"

في الجزء التشخيصي لتسجيل Expressway-E أعلاه، يمكنك أن ترى أن Expressway-E يحاول الاتصال ب IP 146.20.193.64 الذي تم حله مسبقا عبر منفذ TCP 5061 ومع ذلك، فإن هذا الاتصال يفشل بشكل صريح. ويمكن ملاحظة نفس الشيء من التقاط الحزمة الذي تم تجميعه.

استنادا إلى هذه النتائج، من الواضح أن حركة المرور عبر المنفذ 5061 غير ناجحة. ومع ذلك، فإن اتصال خدمة المكالمات المختلطة المقصود به إستخدام منفذ TCP 5062، وليس 5061. لذلك، تحتاج إلى التفكير في السبب وراء عدم حل Expressway-E لسجل SRV الذي قد يرجع المنفذ 5062. لمحاولة الإجابة على هذا السؤال، يمكنك البحث عن مشاكل التكوين المحتملة في منطقة DNS المختلطة ل Expressway-E Webex.

*c xConfiguration Zones Zone 6 Name: "Hybrid Call Services DNS"

*c xConfiguration Zones Zone 6 DNS SIP Authentication Trust Mode: "Off"

*c xConfiguration Zones Zone 6 DNS SIP Default Transport: "TLS"

*c xConfiguration Zones Zone 6 DNS SIP DnsOverride Name: "ciscospark.com"

*c xConfiguration Zones Zone 6 DNS SIP DnsOverride Override: "Off"

*c xConfiguration Zones Zone 6 DNS SIP Media AesGcm Support: "Off"

*c xConfiguration Zones Zone 6 DNS SIP Media Encryption Mode: "On"

*c xConfiguration Zones Zone 6 DNS SIP Media ICE Support: "Off"

*c xConfiguration Zones Zone 6 DNS SIP ParameterPreservation Mode: "Off"

*c xConfiguration Zones Zone 6 DNS SIP Poison Mode: "Off"

*c xConfiguration Zones Zone 6 DNS SIP PreloadedSipRoutes Accept: "On"

*c xConfiguration Zones Zone 6 DNS SIP Record Route Address Type: "IP"

*c xConfiguration Zones Zone 6 DNS SIP SearchAutoResponse: "Off"

*c xConfiguration Zones Zone 6 DNS SIP TLS Verify InboundClassification: "On"

*c xConfiguration Zones Zone 6 DNS SIP TLS Verify Mode: "On"

*c xConfiguration Zones Zone 6 DNS SIP TLS Verify Subject Name: "callservice.ciscospark.com"

*c xConfiguration Zones Zone 6 DNS SIP UDP BFCP Filter Mode: "Off"

*c xConfiguration Zones Zone 6 DNS SIP UDP IX Filter Mode: "Off"

في التكوين xConfiguration الخاص ب Expressway-E، يمكنك ملاحظة وجود قيمتين محددتين للمصلحة مرتبطتين بعمليات بحث DNS: اسم DNSOverride وتجاوز DNSOverride. بناء على هذا xConfiguration، تم تعيين "تجاوز DNSOverride" على "إيقاف"، لذلك لن يدخل اسم DNSOverride حيز التنفيذ. لفهم ما تقوم به هذه القيم بشكل أفضل، يمكنك إستخدام واجهة مستخدم ويب Expressway للبحث عن تعريف القيم.

تعديل طلب DNS (يترجم إلى تجاوز DNSoverride في xConfig)

يقوم بتوجيه مكالمات SIP الصادرة من هذه المنطقة إلى مجال SIP محدد يدويا بدلا من المجال في الوجهة المطلوبة. هذا الخيار مخصص بشكل أساسي للاستخدام مع Cisco Webex Call Service. راجع www.cisco.com/go/hybrid-services.

المجال المطلوب البحث عنه (يترجم إلى اسم تجاوز DnsOverride في xConfig)

أدخل FQDN للبحث عنه في DNS بدلا من البحث عن المجال على URI لبروتوكول SIP الصادر. لم يتأثر URI SIP الأصلي.

الآن بعد أن أصبحت لديك هذه التعريفات، من الواضح أن هذه القيم إذا تم تعيينها بشكل صحيح سوف تكون ذات صلة تماما بمنطق البحث الخاص ب DNS الخاص بنا. إذا قمت بإقران هذا مع عبارات من دليل النشر ل Cisco Webex Hybrid Call Services، فستجد أنه يجب تعيين طلب تعديل DNS على On ويجب تعيين المجال المراد البحث عنه على callService.ciscospark.com. إذا قمت بتغيير هذه القيم لتحديد المعلومات الصحيحة، فسيختلف منطق البحث الخاص ب DNS SRV تماما. فيما يلي جزء مما يمكن توقعه من منظور التسجيل التشخيصي ل Expressway-E

2017-09-19T10:18:35.048-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,048" Module="network.dns" Level="DEBUG":  Detail="Sending DNS query" Name="_sips._tcp.callservice.ciscospark.com" Type="SRV (IPv4 and IPv6)"

2017-09-19T10:18:35.126-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,126" Module="network.dns" Level="DEBUG":  Detail="Resolved hostname to:  ['IPv4''TCP''146.20.193.70:5062'] (A/AAAA)  ['IPv4''TCP''146.20.193.64:5062'] (A/AAAA)  Hostname:'l2sip-cfa-02.wbx2.com' Port:'5062' Priority:'5' TTL:'300' Weight:'10' (SRV)  Hostname:'l2sip-cfa-01.wbx2.com' Port:'5062' Priority:'5' TTL:'300' Weight:'10' (SRV) Number of relevant records retrieved: 4"

الحل

1. تسجيل الدخول إلى Expressway-E

2. انتقل إلى مناطق التكوين > مناطق

3. تحديد منطقة Webex Hybrid DNS التي تم تكوينها

4. تعيين طلب تعديل DNS إلى تشغيل

5. تعيين المجال للبحث عن قيمة إلى callservice.ciscospark.com

6. حفظ التغييرات

ملاحظة: في حالة وجود منطقة DNS واحدة فقط قيد الاستخدام على Expressway، يجب تكوين منطقة DNS منفصلة ليتم إستخدامها مع "خدمة المكالمات المختلطة" التي يمكنها الاستفادة من هذه القيم.

المسألة 2. تم حظر المنفذ 5062 خارج نطاق Cisco Webex

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

مثال على زر الربط الذي يتم تقديمه

كما هو الحال مع إصدار المكالمة الصادرة رقم 1، يمكنك بدء التحليل في تسجيل تشخيص Expressway-E، لأنك قد أستخدمت محفوظات البحث على Expressway لتحديد أن المكالمة تصل إلى هذا الحد. وكما في السابق، ابدأ بالدعوة الأولية التي تأتي إلى Expressway-E من Expressway-C. تذكر الأشياء التي تريد البحث عنها هي:

1. ما إذا كان Expressway-E يتلقى الدعوة أم لا

2. ما إذا كان منطق قاعدة البحث يقوم بتمرير الاستدعاء إلى منطقة DNS المختلطة

3. ما إذا كانت منطقة DNS تقوم بالبحث عن DNS وعلى المجال الصحيح

4. ما إذا كان النظام قد حاول تأكيد اتصال TCP للمنفذ 5062 وقام بإنشائه بشكل صحيح

5. ما إذا نجحت مصافحة TLS المتبادلة

2017-09-19T10:18:35.023-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,017" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="192.168.1.6" Local-port="7003" Src-ip="192.168.1.5" Src-port="26513" Msg-Hash="3732376649380137405"

SIPMSG:

|INVITE sip:pstojano-test@dmzlab.call.ciscospark.com SIP/2.0

Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bK57d8d5c823824bcddfd62f6ff7e09f9939482.899441b6d60c444e4ed58951d07b5224;proxy-call-id=696f6f1c-9abe-47f3-96a4-e26f649fb76f;rport

Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK12d4b77c97a64;received=192.168.1.21;ingress-zone=CUCM11

Call-ID: 6a48de80-9c11273a-12d08-1501a8c0@192.168.1.21

CSeq: 101 INVITE

Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=DESKTOP

Remote-Party-ID: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;party=calling;screen=yes;privacy=off

Contact: <sip:5010@192.168.1.21:5065;transport=tcp>;video;audio

From: "Jonathan Robb"

;tag=328867~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106829

To:

Max-Forwards: 15

Record-Route: <sip:proxy-call-id=696f6f1c-9abe-47f3-96a4-e26f649fb76f@192.168.1.5:5061;transport=tls;lr>

Record-Route: <sip:proxy-call-id=696f6f1c-9abe-47f3-96a4-e26f649fb76f@192.168.1.5:5060;transport=tcp;lr>

Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY

User-Agent: Cisco-CUCM11.5

Expires: 180

Date: Tue, 19 Sep 2017 14:18:34 GMT

Supported: timer,resource-priority,replaces,X-cisco-srtp-fallback,X-cisco-original-called

Session-Expires: 1800

Min-SE: 1800

Allow-Events: presence

X-TAATag: b2967a3b-93fb-4ca4-b0d7-131f75335684

Session-ID: 75957d4fb66a13e835c10737aa328865;remote=00000000000000000000000000000000

Cisco-Guid: 1783160448-0000065536-0000000126-0352430272

Content-Type: application/sdp

Content-Length: 714

<SDP Omitted>

وكما ترى في الدعوة اعلاه، يجري تسلم الدعوة كشيء عادي. هذا إجراء "تم إستقباله" وهو قادم من عنوان IP الخاص ب Expressway-C. يمكنك الآن الانتقال إلى منطق قاعدة البحث

2017-09-19T10:18:35.023-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,022" Module="network.search" Level="DEBUG":  Detail="Search rule 'B2B calls to VCS-C' did not match destination alias 'pstojano-test@dmzlab.call.ciscospark.com'"

2017-09-19T10:18:35.023-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,022" Module="network.search" Level="DEBUG":  Detail="Search rule 'Webex Hybrid' ignored due to source filtering"

2017-09-19T10:18:35.023-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,022" Module="network.search" Level="DEBUG":  Detail="Search rule 'Calls to Webex' did not match destination alias 'pstojano-test@dmzlab.call.ciscospark.com'"

2017-09-19T10:18:35.023-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,022" Module="network.search" Level="DEBUG":  Detail="Considering search rule 'Webex Hybrid - to Webex Cloud' towards target 'Hybrid Call Services DNS' at priority '90' with alias 'pstojano-test@dmzlab.call.ciscospark.com'"

استنادا إلى قصاصة السجل أعلاه، يمكنك أن ترى أن Expressway-E تم تحليله من خلال أربع قواعد بحث على أي حال واحد فقط (سحابة Webex Hybrid - إلى Webex) اعتبر. كانت لقاعدة البحث أولوية تبلغ 90 وكان الهدف هو الانتقال إلى منطقة DNS لخدمات المكالمات المختلطة. الآن بعد إرسال المكالمة إلى منطقة DNS، يمكنك مراجعة عمليات بحث DNS SRV التي تحدث على Expressway-E. كل هذا طبيعي تماما. يمكنك الآن التركيز على منطق البحث في DNS

2017-09-19T10:18:35.048-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,048" Module="network.dns" Level="DEBUG":  Detail="Sending DNS query" Name="_sips._tcp.callservice.ciscospark.com" Type="SRV (IPv4 and IPv6)"

2017-09-19T10:18:35.126-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,126" Module="network.dns" Level="DEBUG":  Detail="Resolved hostname to:  ['IPv4''TCP''146.20.193.70:5062'] (A/AAAA)  ['IPv4''TCP''146.20.193.64:5062'] (A/AAAA)  Hostname:'l2sip-cfa-02.wbx2.com' Port:'5062' Priority:'5' TTL:'300' Weight:'10' (SRV)  Hostname:'l2sip-cfa-01.wbx2.com' Port:'5062' Priority:'5' TTL:'300' Weight:'10' (SRV) Number of relevant records retrieved: 4"

يمكنك أن ترى بوضوح أنه في هذه الحالة، تم حل سجل SRV الخاص ب callservice.ciscospark.com. الاستجابة هي أربعة سجلات صالحة مختلفة تستخدم جميعها المنفذ 5062. هذا سلوك طبيعي. عند هذه النقطة، يمكنك الآن تحليل مصافحة TCP التي يجب أن تأتي بعد ذلك. كما تمت الإشارة إليه مسبقا في المستند، يمكنك البحث في سجلات التشخيص ل "توصيل TCP" والبحث عن عنصر الخط الذي يسرد منفذ DST="5062". أدناه عينة مما سترونه في هذا السيناريو:

2017-09-19T10:18:35.474-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,474" Module="network.tcp" Level="DEBUG":  Src-ip="172.16.2.2" Src-port="25026" Dst-ip="146.20.193.70" Dst-port="5062" Detail="TCP Connecting"

2017-09-19T10:28:35.295-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:28:35,289" Module="network.tcp" Level="ERROR":  Src-ip="172.16.2.2" Src-port="25026" Dst-ip="146.20.193.70" Dst-port="5062" Detail="TCP Connection Failed"

يمكنك أيضا إستخدام tcpdump الذي تم تضمينه مع حزمة التسجيل التشخيصية للحصول على مزيد من المعلومات التفصيلية حول مصافحة TCP كما هو موضح في الصورة.

عند هذه النقطة، يمكنك الاستنتاج بأن Expressway-E يوجه المكالمة بشكل صحيح. التحدي في هذا السيناريو هو عدم إمكانية إنشاء اتصال TCP باستخدام بيئة Webex. قد يحدث هذا الأمر لأن بيئة Webex لا تستجيب لحزمة TCP syn ومع ذلك فمن غير المحتمل إعتبار الخادم الذي يعالج الاتصال مشتركا بين العديد من العملاء. السبب الأكثر ترجيحا في هذا السيناريو هو عدم سماح نوع ما من الأجهزة الوسيطة (جدار الحماية و IPS وما إلى ذلك) لحركة المرور.

الحل

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

المسألة 3. تكوين قاعدة بحث Expressway غير صحيح

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

- قدم تطبيق Cisco Webex الخاص بالمستخدم المستدعي زر الانضمام

- الهاتف المتصل كان يعمل خاتما

- الهاتف الداخلي للمستخدم الذي تم الاتصال به كان يرن

- تطبيق Cisco Webex الخاص بالمستخدم المتصل لم يحدث أبدا

مثل جميع السيناريوهات الأخرى، ستحتاج أيضا إلى الاستفادة من آثار CUCM SDL مع سجلات تشخيص Expressway-C و E. كما هو الحال من قبل، يجب الإشارة إلى الاستفادة من محفوظات البحث والنصائح الخاصة بتعريف مكالمة في سجلات التشخيص. وكما حدث من قبل، فقد تقرر باستخدام تاريخ البحث الخاص ب Expressway-E أن هذه المكالمة قد أدت إلى حدوث ذلك وإلى الفشل. ما يلي أدناه بداية التحليل الذي نلقي فيه نظرة على دعوة بروتوكول معلومات التوجيه (SIP) الأولية القادمة إلى منفذ Expressway-E من منفذ Expressway-C.

2017-09-25T11:26:02.959-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,959" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="192.168.1.6" Local-port="7003" Src-ip="192.168.1.5" Src-port="25675" Msg-Hash="1536984498381728689"

SIPMSG:

|INVITE sip:pstojano-test@dmzlab.call.ciscospark.com SIP/2.0

Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bK1c7bf93ff08014ca5e00bb0b5f8b184b272412.a81f2992e3863ac202a000a3dd599763;proxy-call-id=f79b8631-947b-46d4-a888-911bf0150bfe;rport

Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK1c8c419938648;received=192.168.1.21;ingress-zone=CUCM11

Call-ID: d58f2680-9c91200a-1c7ba-1501a8c0@192.168.1.21

CSeq: 101 INVITE

Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=DESKTOP

Remote-Party-ID: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;party=calling;screen=yes;privacy=off

Contact: <sip:5010@192.168.1.21:5065;transport=tcp>;video;audio

From: "Jonathan Robb"

;

tag=505817~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106972

To:

Max-Forwards: 15

Record-Route: <sip:proxy-call-id=f79b8631-947b-46d4-a888-911bf0150bfe@192.168.1.5:5061;transport=tls;lr>

Record-Route: <sip:proxy-call-id=f79b8631-947b-46d4-a888-911bf0150bfe@192.168.1.5:5060;transport=tcp;lr>

Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY

User-Agent: Cisco-CUCM11.5

Expires: 180

Date: Mon, 25 Sep 2017 15:26:02 GMT

Supported: timer,resource-priority,replaces,X-cisco-srtp-fallback,X-cisco-original-called

Session-Expires: 1800

Min-SE: 1800

Allow-Events: presence

X-TAATag: 8e8c014d-5d01-4581-8108-5cb096778fc5

Session-ID: 75957d4fb66a13e835c10737aa505813;remote=00000000000000000000000000000000

Cisco-Guid: 3582928512-0000065536-0000000240-0352430272

Content-Type: application/sdp

Content-Length: 714

<SDP Omitted>

باستخدام معرف الاستدعاء (d58f2680-9c91200a-1c7ba-1501a8c0) من رأس SIP، يمكنك البحث بسرعة في جميع الرسائل المرتبطة بهذا الحوار. عند النظر إلى الوصول الثالث في سجلات معرف المكالمة، يمكنك أن ترى أن Expressway-E يرسل على الفور رقم 404 غير موجود على Expressway-C.

2017-09-25T11:26:13.286-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:13,286" Module="network.sip" Level="DEBUG":  Action="Sent" Local-ip="192.168.1.6" Local-port="7003" Dst-ip="192.168.1.5" Dst-port="25675" Msg-Hash="12372154521012287279"

SIPMSG:

|SIP/2.0 404 Not Found

Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bK1c7bf93ff08014ca5e00bb0b5f8b184b272412.a81f2992e3863ac202a000a3dd599763;proxy-call-id=f79b8631-947b-46d4-a888-911bf0150bfe;received=192.168.1.5;rport=25675;ingress-zone=HybridCallServiceTraversal

Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK1c8c419938648;received=192.168.1.21;ingress-zone=CUCM11

Call-ID: d58f2680-9c91200a-1c7ba-1501a8c0@192.168.1.21

CSeq: 101 INVITE

From: "Jonathan Robb"

;tag=505817~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106972

To:

>;tag=10d2cfbc45e4373f

Server: TANDBERG/4135 (X8.10.2) Warning: 399 192.168.1.6:7003 "Policy Response" Session-ID: 00000000000000000000000000000000;remote=75957d4fb66a13e835c10737aa505813 Content-Length: 0

هذه البيانات تخبرك شيئين:

1. لم يحاول Expressway-E إرسال الدعوة إلى Cisco Webex

2. كان Expressway-E هو الطرف المسؤول عن إتخاذ القرار المنطقي برفض المكالمة بخطأ 404 Not Found.

خطأ 404 لم يتم العثور عليه يعني بشكل عام أن Expressway غير قادر على العثور على عنوان الوجهة. ونظرا لأن الطرق السريعة تستخدم قواعد البحث لتوجيه المكالمات فيما بينها وبين البيئات المختلفة، ابدأ بالتركيز على التكوين xConfiguration الخاص ب Expressway-E. ضمن xConfiguration هذا، يمكنك البحث عن قاعدة البحث التي يجب تمرير الاستدعاء إلى منطقة Webex Hybrid DNS. للعثور على قواعد البحث التي تم تكوينها على Expressway من منظور xConfiguration، يمكنك البحث عن قاعدة SearchRules لنهج مناطق التكوين" من خلال القيام بذلك، سترى قائمة بتكوين قاعدة البحث لكل قاعدة بحث تم إنشاؤها على Expressway. سيزداد الرقم الذي يأتي بعد "القاعدة" استنادا إلى قاعدة البحث التي تم إنشاؤها أولا مع وضع علامة 1. إذا كنت تواجه مشكلة في العثور على قاعدة البحث. يمكنك إستخدام قيم التسمية المستخدمة بشكل شائع مثل Webex" لتحديد موقع قاعدة البحث بشكل أفضل. طريقة أخرى لتعريف القاعدة هي العثور على قيمة سلسلة النمط التي تم تعيينها على .*@.*\.ciscoSpark\.com". هذا هو "سلسلة النمط" التي من المفترض تكوينها. (بافتراض أن سلسلة النمط تم تكوينها بشكل صحيح)

بعد مراجعة xConfiguration من هذا السيناريو، يمكنك أن ترى أن قاعدة البحث 6 هي القاعدة الصحيحة لتمرير الاستدعاء إلى Cisco Webex.

*c xConfiguration Zones Policy SearchRules Rule 6 Authentication: "No"

*c xConfiguration Zones Policy SearchRules Rule 6 Description: "Outbound calls to Webex"

*c xConfiguration Zones Policy SearchRules Rule 6 Mode: "AliasPatternMatch"

*c xConfiguration Zones Policy SearchRules Rule 6 Name: "Webex Hybrid - to Webex Cloud"

*c xConfiguration Zones Policy SearchRules Rule 6 Pattern Behavior: "Leave"

*c xConfiguration Zones Policy SearchRules Rule 6 Pattern Replace:

*c xConfiguration Zones Policy SearchRules Rule 6 Pattern String: ".*@.*\.ciscospark\.com"

*c xConfiguration Zones Policy SearchRules Rule 6 Pattern Type: "Regex"

*c xConfiguration Zones Policy SearchRules Rule 6 Priority: "101"

*c xConfiguration Zones Policy SearchRules Rule 6 Progress: "Stop"

*c xConfiguration Zones Policy SearchRules Rule 6 Protocol: "SIP"

*c xConfiguration Zones Policy SearchRules Rule 6 SIPTrafficType: "Any"

*c xConfiguration Zones Policy SearchRules Rule 6 Source Mode: "Named"

*c xConfiguration Zones Policy SearchRules Rule 6 Source Name: "Hybrid Call Service Traversal"

*c xConfiguration Zones Policy SearchRules Rule 6 State: "Enabled"

*c xConfiguration Zones Policy SearchRules Rule 6 SystemGenerated: "No"

*c xConfiguration Zones Policy SearchRules Rule 6 Target Name: "Hybrid Call Services DNS"

*c xConfiguration Zones Policy SearchRules Rule 6 Target SIPVariant: "Any"

*c xConfiguration Zones Policy SearchRules Rule 6 Target Type: "Zone"

لاختبار هذا النمط، يمكننا إستخدام دالة التحقق النمط موصوفة في. النداء المهم هنا هو أننا نريد تكوين القيم التالية:

صيانة > أدوات > التحقق من النمط

- الاسم المستعار: ٪Request URI في الدعوة الأولية٪ (على سبيل المثال: pstojano-test@dmzlab.call.ciscospark.com)

- نوع النموذج: Regex

- سلسلة النقش .*@.*\.ciscoSpark\.com

- سلوك النمط: المغادرة

إذا تم إعداد Regex للتسطير بشكل صحيح، يجب أن ترى نتيجة نجاح نمط Check هذا. أدناه رسم توضيحي يظهر ذلك كما هو موضح في الصورة:

الآن بعد أن أصبح بإمكانك التأكد من وجود قاعدة البحث وتكوينها بشكل صحيح، يمكنك إلقاء نظرة أكثر قربا على منطق البحث الذي يقوم به Expressway لتحديد ما إذا كان يؤثر على Expressway-E الذي يقوم بإرسال عنصر 404 غير الموجود. في ما يلي عينة من منطق قاعدة البحث الذي كان Expressway يقوم بتنفيذه.

2017-09-25T11:26:02.966-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,966" Module="network.search" Level="DEBUG":  Detail="Search rule 'B2B calls to VCS-C' did not match destination alias 'pstojano-test@dmzlab.call.ciscospark.com'"

2017-09-25T11:26:02.966-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,966" Module="network.search" Level="DEBUG":  Detail="Search rule 'Webex Hybrid' ignored due to source filtering"

2017-09-25T11:26:02.966-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,966" Module="network.search" Level="DEBUG":  Detail="Search rule 'Calls to Webex' did not match destination alias 'pstojano-test@dmzlab.call.ciscospark.com'"

2017-09-25T11:26:02.967-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,967" Module="network.search" Level="DEBUG":  Detail="Considering search rule 'to DNS' towards target 'DNS' at priority '100' with alias 'pstojano-test@dmzlab.call.ciscospark.com'"

2017-09-25T11:26:02.968-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,968" Module="network.dns" Level="DEBUG": Detail="Sending DNS query" Name="dmzlab.call.ciscospark.com" Type="NAPTR (IPv4 and IPv6)"

2017-09-25T11:26:02.982-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,982" Module="network.dns" Level="DEBUG": Detail="Could not resolve hostname"

2017-09-25T11:26:02.982-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,982" Module="network.dns" Level="DEBUG": Detail="Sending DNS query" Name="_sips._tcp.dmzlab.call.ciscospark.com" Type="SRV (IPv4 and IPv6)"

في هذه العينة، يمكنك أن ترى أن Expressway قام بمعالجة أربع قواعد بحث. لم يتم النظر في ال 3 الأولى لأسباب مختلفة، ولكن تم النظر في ال 4. الجزء المثير للاهتمام من البيانات هو أنه بعد دراسة الموضوع مباشرة ينتقل Expressway مباشرة إلى منطق البحث في DNS. إذا كنت تتذكر ما رأيناه في xConfiguration، فإن قاعدة البحث التي تم تكوينها ل Webex Hybrid كانت تسمى Webex Hybrid - إلى Webex Cloud ولم يتم اعتبارها حتى في منطق قاعدة البحث هذه أعلاه. في هذه المرحلة، يجدر النظر في كيفية تنفيذ قاعدة البحث المدروسة (إلى DNS) بحيث يمكنك فهم ما إذا كانت تؤثر على إستخدام قاعدة البحث المختلطة ل Webex. للقيام بذلك، يمكنك إعادة زيارة xConfig هذه المرة للبحث عن قاعدة البحث المسماة "إلى DNS"

*c xConfiguration Zones Policy SearchRules Rule 1 Authentication: "No"

*c xConfiguration Zones Policy SearchRules Rule 1 Description:

*c xConfiguration Zones Policy SearchRules Rule 1 Mode: "AliasPatternMatch"

*c xConfiguration Zones Policy SearchRules Rule 1 Name: "to DNS"

*c xConfiguration Zones Policy SearchRules Rule 1 Pattern Behavior: "Leave"

*c xConfiguration Zones Policy SearchRules Rule 1 Pattern Replace:

*c xConfiguration Zones Policy SearchRules Rule 1 Pattern String: "(?!.*@%localdomains%.*$).*"

*c xConfiguration Zones Policy SearchRules Rule 1 Pattern Type: "Regex"

*c xConfiguration Zones Policy SearchRules Rule 1 Priority: "100"

*c xConfiguration Zones Policy SearchRules Rule 1 Progress: "Stop"

*c xConfiguration Zones Policy SearchRules Rule 1 Protocol: "Any"

*c xConfiguration Zones Policy SearchRules Rule 1 SIPTrafficType: "Any"

*c xConfiguration Zones Policy SearchRules Rule 1 Source Mode: "Any"

*c xConfiguration Zones Policy SearchRules Rule 1 Source Name: "Please Select"

*c xConfiguration Zones Policy SearchRules Rule 1 State: "Enabled"

*c xConfiguration Zones Policy SearchRules Rule 1 SystemGenerated: "No"

*c xConfiguration Zones Policy SearchRules Rule 1 Target Name: "DNS"

*c xConfiguration Zones Policy SearchRules Rule 1 Target SIPVariant: "Any"

*c xConfiguration Zones Policy SearchRules Rule 1 Target Type: "Zone"

بعد مراجعة قاعدة البحث هذه، يمكنك إتمام ما يلي:

- تطابق سلسلة النمط URI لطلب Cisco Webex

- تم تعيين الأولوية على 100

- تم تعيين التقدم (نمط السلوك) إلى إيقاف.

ما تنبئنا به هذه المعلومات هو أن URI الخاص بطلب Cisco Webex الذي يتم استدعاؤه سيطابق هذه القاعدة وإذا كانت القاعدة متطابقة فإن Expressway سيتوقف عن البحث (مع مراعاة) في قواعد البحث الأخرى. وبهذا الفهم، تصبح أولوية القاعدة عاملا رئيسيا. طريقة عمل أولوية قاعدة بحث Expressway هي أقل قاعدة أولوية يتم تجربتها أولا. وفيما يلي مثال على ذلك.

قاعدة البحث: محلي

سلوك النموذج: متابعة

الأولوية 1

قاعدة البحث: الجار

سلوك النموذج: متابعة

الأولوية 10

قاعدة البحث: DNS

سلوك النموذج: إيقاف

الأولوية 50

في هذا المثال، سيتم محاولة تشغيل قاعدة البحث المسماة محلي (1) أولا وإذا تم العثور على تطابق فإنها ستنتقل إلى "جار قاعدة البحث" (10) بسبب تعيين سلوك "النمط" إلى "متابعة". إذا لم تتطابق قاعدة البحث مع الجوار، ستظل مستمرة في البحث في DNS لقاعدة البحث (50) مع إعتبار هذا الأخير. إذا تم مطابقة DNS لقاعدة البحث، سيتم إيقاف البحث بغض النظر عما إذا كانت هناك قاعدة بحث أخرى ذات أولوية أعلى من 50، لأنه تم تعيين سلوك النمط على إيقاف.

باستخدام هذا الفهم، يمكنك إلقاء نظرة على أولويات قاعدة البحث بين قواعد إلى DNS" و"Webex Hybrid - إلى Webex Cloud".

*c xConfiguration Zones Policy SearchRules Rule 1 Name: "to DNS"

*c xConfiguration Zones Policy SearchRules Rule 1 Priority: "100"

*c xConfiguration Zones Policy SearchRules Rule 1 Progress: "Stop"

*c xConfiguration Zones Policy SearchRules Rule 6 Name: "Webex Hybrid - to Webex Cloud"

*c xConfiguration Zones Policy SearchRules Rule 6 Priority: "101"

*c xConfiguration Zones Policy SearchRules Rule 6 Progress: "Stop"

هنا، يمكنك أن ترى أن قاعدة "إلى DNS" لها أولوية أقل من قاعدة "Webex Hybrid - إلى Webex Cloud" - لذلك، سيتم تجربة قاعدة "إلى DNS" أولا. نظرا لأنه قد تم تعيين سلوك النمط (Progress) على الإيقاف، فإن Expressway-E لا يعتبر Webex Hybrid مطلقا - إلى قاعدة سحابة Webex، فشل الاستدعاء في نهاية المطاف.

الحل

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

1. تسجيل الدخول إلى Expressway-E

2. انتقل إلى التكوين > خطة الطلب > قواعد البحث

3. البحث عن قاعدة البحث المختلطة ل Webex والنقر فوقها (على سبيل المثال: الاسم: Webex Hybrid - إلى سحابة Webex)

4. قم بتعيين قيمة الأولوية إلى قيمة أقل من قواعد البحث الأخرى، ولكنها مرتفعة بما يكفي بحيث لا تؤثر على الآخرين. (مثال: الأولوية: 99)

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

المسألة 4. تكوين CPL غير صحيح في Expressway

يسمح حل Expressway بالتخفيف من حالات الاحتيال الناتجة عن رسوم المكالمات من خلال إستخدام منطق لغة معالجة المكالمات (CPL) المتوفر على الخادم. إذا كان حل Expressway الذي يتم نشره قيد الاستخدام فقط لخدمة المكالمات المختلطة من Cisco Webex والوصول المحمول والوصول عن بعد، فإننا نوصي بشدة بتمكين سياسة وقواعد قائمة التحكم في الوصول (CPL) وتنفيذها. بينما يكون تكوين قائمة التحكم في الوصول (CPL) على Expressway ل Cisco Webex Hybrid واضحا إلى حد ما، إذا تم تكوينها بشكل غير صحيح، فيمكن بسهولة منع محاولات الاتصال من الحدوث. توضح السيناريوهات أدناه كيفية إستخدام تسجيل التشخيص لتحديد تكوين CPL غير صحيح.

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

- قدم تطبيق Cisco Webex الخاص بالمستخدم المستدعي زر ربط

- الهاتف كان يلعب خاتما

- هاتف المستخدم المحلي كان يرن

- لم يحدث قط أن تم إستدعاء تطبيق المستخدم

مثل كل السيناريوهات الأخرى، يمكنك إستخدام آثار CUCM SDL مع سجلات تشخيص Expressway-C و E. كما في السابق، يجب أن تشير إلى  لاستخدام "محفوظات البحث" والتلميحات الخاصة بتعريف مكالمة في سجلات التشخيص. وكما حدث من قبل، فقد تقرر باستخدام تاريخ البحث الخاص ب Expressway-E أن هذه المكالمة كانت قادمة إلى هناك ولكنها فشلت. فيما يلي بداية التحليل الذي يمكنك من خلاله إلقاء نظرة على دعوة SIP الأولية القادمة إلى منفذ Expressway-E من منفذ Expressway-C.

2017-09-25T16:54:43.722-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 20:54:43,722" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="192.168.1.6" Local-port="7003" Src-ip="192.168.1.5" Src-port="26404" Msg-Hash="17204952472509519266"

SIPMSG:

|INVITE sip:pstojano-test@dmzlab.call.ciscospark.com SIP/2.0

Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bK781a130d234ed9aaec86834368739430283256.34216c32a0de36e16590bae36df388b6;proxy-call-id=3bbbf94a-082e-4088-8f5a-5ea7e82f8aac;rport

Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK1cf344a8b117e;received=192.168.1.21;ingress-zone=CUCM11

Call-ID: c030f100-9c916d13-1cdcb-1501a8c0@192.168.1.21

CSeq: 101 INVITE

Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=DESKTOP

Remote-Party-ID: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;party=calling;screen=yes;privacy=off

Contact: <sip:5010@192.168.1.21:5065;transport=tcp>;video;audio

From: "Jonathan Robb"

;tag=512579~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30107000

To:

Max-Forwards: 15

Record-Route: <sip:proxy-call-id=3bbbf94a-082e-4088-8f5a-5ea7e82f8aac@192.168.1.5:5061;transport=tls;lr>

Record-Route: <sip:proxy-call-id=3bbbf94a-082e-4088-8f5a-5ea7e82f8aac@192.168.1.5:5060;transport=tcp;lr>

Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY

User-Agent: Cisco-CUCM11.5

Expires: 180

Date: Mon, 25 Sep 2017 20:54:43 GMT

Supported: timer,resource-priority,replaces,X-cisco-srtp-fallback,X-cisco-original-called

Session-Expires: 1800

Min-SE: 1800

Allow-Events: presence

X-TAATag: 4fffefed-0512-4067-ac8c-35828f0a1150

Session-ID: 75957d4fb66a13e835c10737aa512577;remote=00000000000000000000000000000000

Cisco-Guid: 3224432896-0000065536-0000000264-0352430272

Content-Type: application/sdp

Content-Length: 714

<SDP Omitted>

باستخدام معرف المكالمة (c030f100-9c916d13-1cdcb-1501a8c0) من رأس SIP، يمكنك البحث بسرعة في جميع الرسائل المرتبطة بهذا الحوار. عند النظر إلى الوصول الثالث في سجلات معرف المكالمة، يمكنك أن ترى أن Expressway-E يرسل على الفور رقم 403 ممنوع إلى Expressway-C.

2017-09-25T16:54:43.727-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 20:54:43,727" Module="network.sip" Level="DEBUG":  Action="Sent" Local-ip="192.168.1.6" Local-port="7003" Dst-ip="192.168.1.5" Dst-port="26404" Msg-Hash="9195436101110134622"

SIPMSG:

|SIP/2.0 403 Forbidden

Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bK781a130d234ed9aaec86834368739430283256.34216c32a0de36e16590bae36df388b6;proxy-call-id=3bbbf94a-082e-4088-8f5a-5ea7e82f8aac;received=192.168.1.5;rport=26404;ingress-zone=HybridCallServiceTraversal

Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK1cf344a8b117e;received=192.168.1.21;ingress-zone=CUCM11

Call-ID: c030f100-9c916d13-1cdcb-1501a8c0@192.168.1.21

CSeq: 101 INVITE

From: "Jonathan Robb"

;tag=512579~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30107000

To:

;tag=64fe7f9eab37029d

Server: TANDBERG/4135 (X8.10.2)

Warning: 399 192.168.1.6:7003 "Policy Response"

Session-ID: 00000000000000000000000000000000;remote=75957d4fb66a13e835c10737aa512577

Content-Length: 0

لفهم سبب رفض Expressway-E لهذه المكالمة وإرسال خطأ 403 ممنوع إلى Expressway-C، تريد تحليل إدخالات السجل بين ممنوع 403 ودعوة SIP الأصلية التي تم إدخالها إلى Expressway. من خلال تحليل إدخالات السجل هذه، يمكنك بشكل نموذجي رؤية جميع القرارات المنطقية التي يتم إتخاذها. لاحظ أنك لا ترى أي قواعد بحث يتم استدعاؤها ولكن ترى منطق لغة عملية الاستدعاء (CPL) الذي يتم استدعاؤه. في الأسفل جزء من ذلك.

2017-09-25T16:54:43.725-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 20:54:43,725" Module="network.cpl" Level="DEBUG":  Remote-ip="192.168.1.5" Remote-port="26404" Detail="CPL:

"

2017-09-25T16:54:43.725-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 20:54:43,725" Module="network.cpl" Level="DEBUG":  Remote-ip="192.168.1.5" Remote-port="26404" Detail="CPL:

"

2017-09-25T16:54:43.725-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 20:54:43,726" Module="network.cpl" Level="DEBUG":  Remote-ip="192.168.1.5" Remote-port="26404" Detail="CPL:

matched "

2017-09-25T16:54:43.725-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 20:54:43,726" Module="network.cpl" Level="DEBUG":  Remote-ip="192.168.1.5" Remote-port="26404" Detail="CPL:

"

استنادا إلى تحليل السجل أعلاه. يمكنك تحديد أن CPL يرفض الاستدعاء.

2017-09-25T16:54:43.725-04:00 amer-expressway01 tvcs: Event="Search Completed" Reason="Forbidden" Service="SIP" Src-alias-type="SIP" Src-alias="5010@rtp.ciscotac.net" Dst-alias-type="SIP" Dst-alias="sip:pstojano-test@dmzlab.call.ciscospark.com" Call-serial-number="48c80582-ec79-4d89-82e2-e5546f35703c" Tag="4fffefed-0512-4067-ac8c-35828f0a1150" Detail="found:false, searchtype:INVITE, Info:Policy Response" Level="1" UTCTime="2017-09-25 20:54:43,726"

2017-09-25T16:54:43.725-04:00 amer-expressway01 tvcs: Event="Call Rejected" Service="SIP" Src-ip="192.168.1.5" Src-port="26404" Src-alias-type="SIP"

ملاحظة: في هذه الحالة، لن ترى قواعد البحث التي يتم استدعاؤها لأن قوائم التحكم في الوصول الخاصة ب CPLs و FindMe و Transforms تتم معالجتها جميعها قبل قاعدة بحث

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

*c xConfiguration Policy AdministratorPolicy Mode: "LocalCPL"

لفهم تكوين القاعدة بشكل أفضل، تحتاج إلى تسجيل الدخول إلى Expressway-E والتصفح إلى التكوين > إستدعاء النهج > القواعد كما هو موضح في الصورة.

عند مراجعة هذا التكوين، يمكنك الاطلاع على تكوين ما يلي

المصدر: .*

الوجهة: .*@dmzlab\.call\.ciscospark\.com.*

الإجراء: رفض

مقارنة بما تم توثيقه في دليل نشر خدمة المكالمات المختلطة من Cisco Webex، يمكنك أن ترى أن المصدر والوجهة تم تكوينهما بشكل عكسي.

الحل

لحل هذه المشكلة، تحتاج إلى إعادة ضبط تكوين قاعدة CPL حتى يتم تعيين المصدر على .*@٪Webex_subdomain٪\.call\.ciscospark\.com.* ونمط الوجهة هو .*

1. تسجيل الدخول إلى Expressway-E

2. انتقل إلى التكوين > سياسة الاتصال > القواعد

3. حدد القاعدة التي تم إعدادها لخدمة Cisco Webex Hybrid Call

4. أدخل نمط المصدر ك. *@٪Webex_subdomain٪\.call\.ciscoSpark\.com.*(ex: .*@dmzlab\.call\.ciscoSpark\.com.*)

5. أدخل النقش الوجهة باسم .*

6. حدد حفظ

للحصول على مزيد من المعلومات حول تنفيذ قائمة التحكم في الوصول (CPL) ل Webex Hybrid ارجع إلى دليل تصميم Cisco Webex المختلط.

ثنائي الإتجاه: من Cisco Webex إلى محلي أو محلي إلى Cisco Webex

المسألة 1. توفر نقطة نهاية التعاون/هاتف IP برنامج ترميز صوت بخلاف G.711 أو G.722 أو AAC-LD.

يدعم اتصال خدمة المكالمات المختلطة ثلاثة برامج تشفير صوت مختلفة: G.711 و G.722 و AAC-LD. لإنشاء مكالمة بنجاح باستخدام بيئة Cisco Webex، يجب إستخدام أحد برامج تشفير الصوت هذه. يمكن إعداد البيئة المحلية لاستخدام أنواع عديدة من برامج تشفير الصوت ولكن يمكن في الوقت نفسه إعدادها لتقييدها. يمكن أن يحدث ذلك بشكل مقصود أو غير مقصود باستخدام إعدادات المنطقة المخصصة و/أو الافتراضية على CM الموحد. لهذا السلوك الخاص، يمكن أن تختلف أنماط التسجيل استنادا إلى إتجاه المكالمة وإذا تم تكوين CM الموحد لاستخدام العرض المبكر أو المؤجل. وفيما يلي أمثلة على بضع حالات مختلفة يمكن أن يظهر فيها هذا السلوك:

1. يرسل Cisco Webex دعوة واردة مع/ SDP التي تقدم G.711 أو G.722 أو AAC-LD. يرسل Expressway-C هذه الرسالة إلى Unified CM ولكن Unified CM تم تكوينه للسماح فقط G.729 لهذه المكالمة. لذلك، سيقوم Unified CM برفض المكالمة لعدم توفر برنامج الترميز.

2. ويحاول Unified CM إستدعاء الصادر كعرض مبكر إلى Cisco Webex وهو ما يعني أن الدعوة الأولية المرسلة إلى Expressway-C سوف تحتوي على SDP الذي يدعم صوت G.729 فقط. بعد ذلك، يرسل Cisco Webex 200 OK مع/ SDP الذي يصفر الصوت (m=audio 0 RTP/SAVP) لأنه لا يدعم G.729. بمجرد تمرير Expressway-C لهذه الدعوة إلى CM الموحد، يقوم CM الموحد بإنهاء المكالمة نظرا لعدم توفر برنامج الترميز.

3. يحاول Unified CM إستدعاء الصادر على أنه عرض متأخر إلى Cisco Webex مما يعني أن الدعوة الأولية المرسلة إلى Expressway-C لن تحتوي على SDP. ثم يرسل Cisco Webex 200 OK مع/ SDP يحتوي على جميع برامج تشفير الصوت المدعومة التي يدعمها Cisco Webex. يرسل Expressway-C هذا 200 OK إلى Unified CM ولكن Unified CM تم تكوينه للسماح فقط G.729 لهذه المكالمة. لذلك، سيقوم Unified CM برفض المكالمة لعدم توفر برنامج الترميز.

إذا كنت تحاول تحديد فشل اتصال خدمة Call Connect المختلطة الذي يطابق هذه المشكلة، فيجب الحصول على سجلات Expressway بالإضافة إلى تعقب CM SDL الموحد. المثال قصاصات السجل أسفل حالة المطابقة #2 حيث يحاول Unified CM إستدعاء الصادر مثل عرض مبكر. ولأننا نعلم أن المكالمة تصل إلى Cisco Webex، يبدأ تحليل السجل على Expressway-E.

وفيما يلي قصاصة من الدعوة الأولية إلى Cisco Webex. يمكنك أن ترى أن ترميز الصوت المفضل تم تعيينه على G.729 (حمولة 18). 101 ل DTMF وهذا سيناريو خاص غير مهم.

2017-09-19T10:46:10.488-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:46:10,488" Module="network.sip" Level="DEBUG":  Action="Sent" Local-ip="172.16.2.2" Local-port="25034" Dst-ip="146.20.193.64" Dst-port="5062" Msg-Hash="4309505007645007056"

SIPMSG:

INVITE sip:pstojano-test@dmzlab.call.ciscospark.com SIP/2.0

Via: SIP/2.0/TLS 64.102.241.236:5062;egress-zone=HybridCallServicesDNS;branch=z9hG4bK323e6b15ad0cbbf409751f67848136fa1115;proxy-call-id=a3a78ee2-c01b-4741-b29b-55aedea256d2;rport

Via: SIP/2.0/TLS 172.16.2.2:5073;branch=z9hG4bK350703fe46645f0acddef05b35adc5c157;x-cisco-local-service=nettle;received=172.16.2.2;rport=41511;ingress-zone=DefaultZone

Via: SIP/2.0/TLS 192.168.1.6:5061;egress-zone=DefaultZone;branch=z9hG4bKf71f2bf47233d6ca52b579364594ac6c1114.a402e3f25603f5a77b60b17ea47dbf72;proxy-call-id=be17a470-0bca-4ad5-8a6c-14872e007efb;received=192.168.1.6;rport=25025

Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bKfcf4cfd09d213a88bd2331cef0bc82b540559.494a140082bd66357134b9eed4335df8;proxy-call-id=d4d4e950-babc-45d5-a4a7-c60a8b17a8bd;received=192.168.1.5;rport=26513;ingress-zone=HybridCallServiceTraversal

Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK12dd82194c4f7;received=192.168.1.21;ingress-zone=CUCM11

Call-ID: 44bdd400-9c112db1-12d95-1501a8c0@192.168.1.21

CSeq: 101 INVITE

Remote-Party-ID: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;privacy=off;screen=no;party=calling

Contact: <sip:172.16.2.2:5073;transport=tls>;video;audio

From: "Jonathan Robb"

;tag=329447~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106833 To:

Max-Forwards: 14

Record-Route: <sip:proxy-call-id=a3a78ee2-c01b-4741-b29b-55aedea256d2@64.102.241.236:5062;transport=tls;lr>

Record-Route: <sip:proxy-call-id=a3a78ee2-c01b-4741-b29b-55aedea256d2@172.16.2.2:5061;transport=tls;lr>

Allow: INVITE,ACK,BYE,CANCEL,INFO,OPTIONS,REFER,SUBSCRIBE,NOTIFY

User-Agent: TANDBERG/4352 (X8.10.2-b2bua-1.0)

Supported: X-cisco-srtp-fallback,replaces,timer

Session-Expires: 1800;refresher=uac

Min-SE: 500

X-TAATag: 14a0bd87-1825-4ecf-9f3d-4a23cfa69725

Session-ID: 75957d4fb66a13e835c10737aa329445;remote=00000000000000000000000000000000

Content-Type: application/sdp

Content-Length: 1407

v=0

o=tandberg 0 1 IN IP4 64.102.241.236

s=-

c=IN IP4 64.102.241.236

b=AS:384

t=0 0

m=audio 52668 RTP/SAVP 18 101  <-- CUCM is only supporting G.729 for this call

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:.............................................

a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:............................................. UNENCRYPTED_SRTCP

a=crypto:3 AES_CM_128_HMAC_SHA1_32 inline:.............................................

a=crypto:4 AES_CM_128_HMAC_SHA1_32 inline:............................................. UNENCRYPTED_SRTCP

a=sendrecv

a=rtcp:52669 IN IP4 64.102.241.236

m=video 52670 RTP/SAVP 126 97

b=TIAS:384000

a=rtpmap:126 H264/90000

a=fmtp:126 profile-level-id=42801e;packetization-mode=1;level-asymmetry-allowed=1

a=rtpmap:97 H264/90000

a=fmtp:97 profile-level-id=42801e;packetization-mode=0;level-asymmetry-allowed=1

a=rtcp-fb:* nack pli

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:.............................................

a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:............................................. UNENCRYPTED_SRTCP

a=crypto:3 AES_CM_128_HMAC_SHA1_32 inline:.............................................

a=crypto:4 AES_CM_128_HMAC_SHA1_32 inline:............................................. UNENCRYPTED_SRTCP

a=sendrecv

a=content:main

a=label:11

a=rtcp:52671 IN IP4 64.102.241.236

إستجابة لهذه الدعوة الأولية، يستجيب Cisco Webex برسالة الموافقة 200. إذا ألقيت نظرة عن كثب على هذه الرسالة، يمكنك أن ترى أن برنامج الترميز الصوتي قد تم صفره. هذه مشكلة لأنه بدون منفذ صوت معين، لن تتمكن المكالمة من التفاوض على هذا الدفق.

2017-09-19T10:46:27.073-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:46:27,072" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="172.16.2.2" Local-port="25034" Src-ip="146.20.193.64" Src-port="5062" Msg-Hash="5236578200712291002"

SIPMSG:

SIP/2.0 200 OK

Via: SIP/2.0/TLS 64.102.241.236:5062;egress-zone=HybridCallServicesDNS;branch=z9hG4bK323e6b15ad0cbbf409751f67848136fa1115;proxy-call-id=a3a78ee2-c01b-4741-b29b-55aedea256d2;rport=38245;received=192.168.5.26,SIP/2.0/TLS 172.16.2.2:5073;branch=z9hG4bK350703fe46645f0acddef05b35adc5c157;x-cisco-local-service=nettle;received=172.16.2.2;rport=41511;ingress-zone=DefaultZone,SIP/2.0/TLS 192.168.1.6:5061;egress-zone=DefaultZone;branch=z9hG4bKf71f2bf47233d6ca52b579364594ac6c1114.a402e3f25603f5a77b60b17ea47dbf72;proxy-call-id=be17a470-0bca-4ad5-8a6c-14872e007efb;received=192.168.1.6;rport=25025,SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bKfcf4cfd09d213a88bd2331cef0bc82b540559.494a140082bd66357134b9eed4335df8;proxy-call-id=d4d4e950-babc-45d5-a4a7-c60a8b17a8bd;received=192.168.1.5;rport=26513;ingress-zone=HybridCallServiceTraversal,SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK12dd82194c4f7;received=192.168.1.21;ingress-zone=CUCM11

Call-ID: 44bdd400-9c112db1-12d95-1501a8c0@192.168.1.21

CSeq: 101 INVITE

Contact: "l2sip-UA" <sip:l2sip-UA@l2sip-cfa-01.wbx2.com:5062;transport=tls>

From: "Jonathan Robb"

;tag=329447~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106833 To:

;tag=1311451760

Record-Route: <sip:l2sip-cfa-01.wbx2.com:5062;transport=tls;lr>,<sip:proxy-call-id=a3a78ee2-c01b-4741-b29b-55aedea256d2@64.102.241.236:5062;transport=tls;lr>,<sip:proxy-call-id=a3a78ee2-c01b-4741-b29b-55aedea256d2@172.16.2.2:5061;transport=tls;lr>

Allow: INVITE,ACK,CANCEL,BYE,REFER,INFO,OPTIONS,NOTIFY,SUBSCRIBE

User-Agent: Cisco-L2SIP

Supported: replaces

Accept: application/sdp

Allow-Events: kpml

Session-ID: ed35426ed3ade6fdc3b058792333df2b;remote=75957d4fb66a13e835c10737aa329445

Locus: 4711a33f-9d49-11e7-9bf6-dea12d0f2127

Locus-Type: CALL

Content-Type: application/sdp

Content-Length: 503

v=0

o=linus 0 1 IN IP4 146.20.193.109

s=-

c=IN IP4 146.20.193.109

b=TIAS:384000

t=0 0

m=audio 0 RTP/SAVP *      <-- Webex is zeroing this port out

m=video 33512 RTP/SAVP 108

c=IN IP4 146.20.193.109

b=TIAS:384000

a=content:main

a=sendrecv

a=rtpmap:108 H264/90000

a=fmtp:108 profile-level-id=42001E;packetization-mode=1;max-mbps=40500;max-fs=1620;max-fps=3000;max-br=10000;max-dpb=3037;level-asymmetry-allowed=1

a=rtcp-fb:* nack pli

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:........................................

a=label:200

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

إليك عينة مفصلة من رسالة BYE. يمكنك أن ترى بوضوح أن وكيل المستخدم هو Cisco-CUCM11.5 مما يعني أن الرسالة تم إنشاؤها بواسطة CM الموحد. هناك شيء آخر يجب الإشارة إليه وهو أن رمز السبب تم تعيينه للسبب=47. الترجمة العامة لهذا ليس هناك مورد متوفر.

2017-09-19T10:46:27.175-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:46:27,175" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="192.168.1.6" Local-port="7003" Src-ip="192.168.1.5" Src-port="26513" Msg-Hash="237943800593485079"

SIPMSG:

BYE sip:192.168.1.6:5071;transport=tls SIP/2.0

Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bK90a666b3461356f8cd605cec91e4538240575.494a140082bd66357134b9eed4335df8;proxy-call-id=d4d4e950-babc-45d5-a4a7-c60a8b17a8bd;rport

Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK12ddd10269d39;received=192.168.1.21;ingress-zone=CUCM11

Call-ID: 44bdd400-9c112db1-12d95-1501a8c0@192.168.1.21

CSeq: 102 BYE

From: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;tag=329447~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106833

To: <sip:pstojano-test@dmzlab.call.ciscospark.com>;tag=f3734601fb0eb541

Max-Forwards: 69

Route: <sip:proxy-call-id=be17a470-0bca-4ad5-8a6c-14872e007efb@192.168.1.6:7003;transport=tls;lr>,<sip:proxy-call-id=be17a470-0bca-4ad5-8a6c-14872e007efb@192.168.1.6:5061;transport=tls;lr>

User-Agent: Cisco-CUCM11.5

Date: Tue, 19 Sep 2017 14:46:09 GMT

X-TAATag: 14a0bd87-1825-4ecf-9f3d-4a23cfa69725

Reason: Q.850 ;cause=47

Session-ID: 75957d4fb66a13e835c10737aa329445;remote=ed35426ed3ade6fdc3b058792333df2b

Content-Length: 0

نظرا لأن مكون Cisco Webex قام بإنزال برنامج فك تشفير الصوت لعينة الاتصال هذه، يجب أن يكون التركيز على:

أ. الدعوة الأولية التي تم إرسالها إلى Cisco Webex و

ب. ما هو المنطق الذي استخدمه Cisco Webex لإلغاء هذا المنفذ.

والآن لننظر إلى ما هو فريد في الدعوة الأولية ما يمكن ملاحظته هو أنها تحتوي على G.729 فقط. بمعرفة ذلك، راجع دليل نشر خدمة المكالمات المختلطة من Cisco WebEx وراجع تحديدا فصل إعداد البيئة الخاص بك حيث تستدعي الخطوة 5 من استكمال المتطلبات الأساسية لقسم "اتصال خدمة المكالمات المختلطة" برامج الترميز المحددة المدعومة. هنا قد نرى هذا:

تدعم Cisco Webex برامج الترميز التالية:

- الصوت—G.711 و G.722 و AAC-LD

- الفيديو — H.264

ملاحظة: لا يتم إستخدام OPUS على الجزء المحلي من إستدعاء Cisco Webex Hybrid.

مع توفر هذه المعلومات، يمكنك إستنتاج أن Unified CM يرسل برنامج تشفير صوت غير مدعوم وهو السبب في أن Cisco Webex يقوم بتقسيم المنفذ إلى أصفار.

الحل:

ولمعالجة هذا الموقف تحديدا، قد تحتاج إلى مراجعة تكوين المنطقة بين Cisco Webex RD الذي يقوم بتثبيت الاستدعاء المحلي وشنطة SIP ل Expressway-C. للقيام بذلك، حدد تجمع الأجهزة الذي يوجد فيه هذان العنصران. يحتوي تجمع الأجهزة على تعيينات للمناطق.

لتحديد تجمع الأجهزة الخاص بشنطة SIP من Expressway-C:

1. سجل الدخول إلى Unified CM.

2. انتقل إلى الجهاز > خط الاتصال.

3. ابحث عن اسم خط الاتصال أو انقر فوق بحث.

4. حدد خط اتصال Expressway-C.

5. قم بتسجيل اسم تجمع الأجهزة.

لتحديد تجمع الأجهزة ل CTI-RD أو Cisco Webex-RD الذي ربط المكالمة:

1. انتقل إلى الجهاز > الهاتف.

2. عند البحث يمكنك تحديد "نوع الجهاز" الذي يحتوي على جهاز بعيد Webex أو CTI (حسب ما يستخدمه العميل).

3. قم بتسجيل اسم تجمع الأجهزة.

تحديد المنطقة المرفقة بكل تجمع أجهزة:

1. انتقل إلى النظام > تجمع الأجهزة.

2. البحث عن تجمع الأجهزة المستخدم لشنطة SIP من Expressway-C.

3. انقر فوق تجمع الأجهزة.

4. قم بتسجيل اسم المنطقة.

5. ابحث عن تجمع الأجهزة المستخدم ل Webex-RD أو CTI-RD.

6. انقر فوق تجمع الأجهزة.

7. قم بتسجيل اسم المنطقة.

تحديد علاقة المنطقة:

1. انتقل إلى النظام > معلومات المنطقة > المنطقة.

2. البحث عن إحدى المناطق المحددة.

3. حدد ما إذا كانت هناك علاقة منطقة بين المنطقتين اللتين تستخدمان G.729.

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

منطقة خط اتصال Expressway-C: ReserveBandwidth

منطقة Webex-RD: أجهزة RTP

وفيما يلي مثال رسومي للعلاقة بين مناطق RTP و ReserveBandwidth كما هو موضح في الصورة.

بتغيير تجمع الأجهزة الذي تم فيه إنشاء خط اتصال Expressway-C، يمكنك تغيير علاقة المنطقة. كان لتجمع الأجهزة الجديد منطقة تم تعيينها على RTP-Infrastructure، وبالتالي فإن علاقة المنطقة الجديدة بين Cisco Webex-RD و Expressway-C كانت RTP-Devices و RTP-Infrastructure. وكما هو موضح، يمكنك أن ترى هذه العلاقة تدعم AAC-LD وهو أحد برامج تشفير الصوت المدعومة ل Cisco Webex وبالتالي سيتم إعداد المكالمة بشكل صحيح.

المسألة 2. تم تجاوز الحد الأقصى لحجم الرسائل الواردة الواردة ل Unified CM

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

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

للإجابة على سؤال حول ما يحدث، يجب أن تعرف أنه بمجرد أن يستقبل CM الموحد رسالة SIP كبيرة جدا، فإنه ببساطة يغلق مأخذ TCP ولا يستجيب إلى Expressway-C.

و مع قول هذا، هناك العديد من الحالات و الطرق التي يمكن أن يحدث بها هذا:

1. يرسل Cisco Webex دعوة واردة w/ SDP كبيرة جدا. يقوم Expressway-C بتوصيل هذا إلى CM الموحد و Unified CM بإغلاق مقبس TCP ثم ينتهي مربع حوار SIP.

2. يقوم Unified CM بمحاولة إجراء المكالمة الصادرة في وقت مبكر من Offer إلى Webex مما يعني أن الدعوة الأولية المرسلة إلى Expressway-C سوف تحتوي على SDP. وبعد ذلك، يرسل Cisco Webex 200 OK مع/ SDP كاستجابة، بينما تكون إستجابة 200 OK عند تمريرها من Expressway-C إلى CM الموحد كبيرة جدا. يقوم Unified CM بإغلاق مقبس TCP ومن ثم سينتهي وقت مربع حوار SIP.

3. يحاول Unified CM إستدعاء الصادر كعرض متأخر ل Webex مما يعني أن INVITe الأولي الذي تم إرساله إلى Expressway-C لن يحتوي على SDP. وبعد ذلك، ترسل Cisco Webex 200 OK مع بروتوكول SDP وعرض 200 OK عند تمريره من Expressway-C إلى CM الموحد يكون كبيرا للغاية. يقوم Unified CM بإغلاق مقبس TCP ومن ثم سينتهي وقت مربع حوار SIP.

يساعدك البحث في سجلات Expressway-C الخاصة بهذا الشرط على فهم تدفق الرسائل. إذا كنت ستستخدم برنامجا مثل TranslatorX، فيمكنك أن ترى أن Expressway-C يقوم بتمرير Cisco Webex 200 OK w/ SDP إلى CM الموحد. يكمن التحدي في أن مدير المحتوى الموحد لا يستجيب مطلقا مع SIP ACK كما هو موضح في الصورة.

بما أن CMs الموحد هو الطرف المسؤول عن عدم الرد، فمن الجدير مراجعة آثار SDL لمعرفة كيفية معالجة CM الموحد لهذه الحالة. ما ستجده في هذا السيناريو هو أن CM الموحد يتجاهل الرسالة الكبيرة من Expressway-C. ستتم طباعة عنصر خط تسجيل مثل هذا.

CUCM Traces

53138762.000 |09:05:19.762 |AppInfo  |SIPSocketProtocol(5,100,14,707326)::handleReadComplete send SdlReadRsp: size 5000

53138763.000 |09:05:19.762 |SdlSig   |SdlReadRsp                             |wait                           |SIPTcp(5,100,71,1)               |SdlTCPConnection(5,100,14,707326) |5,100,14,707326.4^10.36.100.140^*        |*TraceFlagOverrode

53138763.001 |09:05:19.762 |AppInfo  |SIPTcp - SdlRead bufferLen=5000

53138763.002 |09:05:19.762 |AppInfo  |//SIP/Stack/Error/0x0/httpish_cache_header_val: DROPPING unregistered header Locus: c904ecb1-d286-11e6-bfdf-b60ed914549d

53138763.003 |09:05:19.762 |AppInfo  |//SIP/Stack/Info/0x0/httpish_msg_process_network_msg: Content Length 4068, Bytes Remaining 3804

53138763.004 |09:05:19.762 |AppInfo  |//SIP/Stack/Info/0x0/ccsip_process_network_message: process_network_msg: not complete

53138763.005 |09:05:19.762 |AppInfo  |SIPTcp - Ignoring large message from %Expressway-C_IP%:[5060]. Only allow up to 5000 bytes. Resetting connection.

بعد انتهاء مهلة حوار SIP، سيقوم Cisco Webex بإرسال رسالة رفض SIP 603 واردة إلى Expressway-E كما هو موضح في عينة السجل.

Expressway-E Traces

2017-01-04T09:05:40.645-05:00 vcs-expressway tvcs: UTCTime="2017-01-04 14:05:40,645" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="%Exp-E%" Local-port="25150" Src-ip="%Webex_IP%" Src-port="5062" Msg-Hash="2483073756671246315"

SIPMSG:

SIP/2.0 603 Decline

وكما ذكرنا، هناك ثلاثة سيناريوهات مختلفة التي تمكنك من رؤية هذا السلوك. للوضوح، تطابق نماذج السجل المقدمة في هذا التوضيح الحالة 3 حيث تم إرسال المكالمة إلى Cisco Webex كعرض متأخر.

الحل:

1. سجل الدخول إلى Unified CM.

2. انتقل إلى النظام > معلمات الخدمة.

3. حدد الخادم الذي يقوم بتشغيل خدمة "إدارة المكالمات".

4. أختر خدمة مدير المكالمات من Cisco عند طلبها لتحديد الخدمة.

5. حدد خيار متقدم.

6. تحت إعدادات معلمات CloudWide (الجهاز - SIP) قم بتغيير حجم رسالة SIP Max الواردة إلى 18000.

7. حدد حفظ.

8. كرر هذه العملية لكل عقدة CM الموحدة التي تقوم بتشغيل خدمة Cisco Call Manager.

ملاحظة: للاستفادة من هذا الإعداد، يجب إعادة تشغيل نقطة نهاية التعاون و/أو خط اتصال SIP لهاتف IP. يمكن إعادة تشغيل هذه الأجهزة بشكل فردي لتقليل التأثير على البيئة إلى الحد الأدنى. لا تقم بإعادة تعيين كل جهاز على CUCM إلا إذا كنت تعلم أنه من المقبول تماما القيام بذلك.

الملحق

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

فحص الأداة المساعدة للنمط

يحتوي Expressway على أداة مساعدة للتحقق من النمط تكون مفيدة عندما تريد إختبار ما إذا كان النموذج يطابق اسم مستعار معين ويتم تحويله بطريقة متوقعة. يمكن العثور على الأداة المساعدة على Expressway تحت الصيانة > أدوات > التحقق من خيار قائمة النماذج. وبشكل شائع، يتم إستخدام هذا الخيار إذا كنت ترغب في إختبار ما إذا كان تغيير قاعدة البحث الخاص بك سيطابق اسما مستعارا لسلسلة نمط بشكل صحيح ثم يقوم بتنفيذ معالجة ناجحة للسلسلة بشكل إختياري. بالنسبة لاتصال خدمة المكالمات المختلطة، يمكنك أيضا إختبار أن FQDN لمجموعة CM الموحدة سوف تطابق سلسلة النمط التي قمت بإعدادها لمجموعة CM الموحدة FQDN. عند إستخدام هذه الأداة المساعدة، تذكر أن الاستدعاء سيقوم بالتوجيه استنادا إلى المعلمة FQDN لمجموعة CM الموحدة المدرجة في رأس المسار، وليس URI الوجهة. على سبيل المثال، إذا كانت الدعوة التالية قد وصلت إلى Expressway، فقم باختبار وظيفة نمط التحقق من cucm.rtp.ciscotac.net، وليس jorobb@rtp.ciscotac.net.

SIPMSG:

|INVITE sip:jorobb@rtp.ciscotac.net SIP/2.0

Via: SIP/2.0/TLS 192.168.1.6:7003;egress-zone=HybridCallServiceTraversal;branch=z9hG4bKcac6d95278590991a2b516cf57e75827371;proxy-call-id=abcba873-eaae-4d64-83b4-c4541d4e620c;rport

Via: SIP/2.0/TLS 192.168.1.6:5073;branch=z9hG4bK837b03f2cd91b6b19be4fc58edb251bf12;x-cisco-local-service=nettle;received=192.168.1.6;rport=41913;ingress-zone=DefaultZone

Via: SIP/2.0/TLS 64.102.241.236:5061;egress-zone=DefaultZone;branch=z9hG4bK524f89592d00ffc45b7b53000271676c370.88b5177ac4d7cfcae1eb8f8be78da055;proxy-call-id=2db939b2-a49b-4307-8d96-23716a2c090b;received=172.16.2.2;rport=25010

Via: SIP/2.0/TLS 192.168.4.150:5062;branch=z9hG4bK92f9ef952712e6610c3e6b72770c1230;received=148.62.40.63;rport=39986;ingress-zone=HybridCallServicesDNS

Via: SIP/2.0/TLS 127.0.0.1:5070;branch=z9hG4bK-313634-3d27a6f914badee6420287903c9c6a45;rport=45939

Call-ID: 3e613afb185751cdf019b056285eb574@127.0.0.1

CSeq: 1 INVITE

Contact: <sip:192.168.1.6:5073;transport=tls>

From: "pstojano test" <sip:pstojano-test@dmzlab.call.ciscospark.com>;tag=145765215

To: <sip:jorobb@rtp.ciscotac.net>

Max-Forwards: 15

Route:

لاستخدام نمط التحقق لاختبار توجيه قاعدة البحث في رأس خدمة الاتصال المختلطة، اتبع الخطوات التالية:

1. انتقل إلى الصيانة > أدوات > التحقق من النمط.

2. بالنسبة للاسم المستعار، أدخل FQDN لمجموعة CM الموحدة.

3. اضبط نوع النموذج على البادئة.

4. قم بتعيين سلسلة النمط إلى FQDN لمجموعة CM الموحدة.

5. قم بتعيين سلوك النموذج للمغادرة.

6. حدد نقش الشيك.

إذا تم تكوين قواعد البحث على Expressway بشكل صحيح، يمكنك توقع رؤية النتائج التي ترجع رسالة ناجحة.

فيما يلي مثال لاختبار نقش تحقق ناجح كما هو موضح في الصورة.

السبب في نجاح هذا الأمر هو أن هذا الاسم المستعار (cucm.rtp.ciscotac.net) يطابق سلسلة نمط البادئة (cucm.rtp.ciscotac.net). لفهم كيفية توجيه مكالمة استنادا إلى هذه النتائج، يمكنك إستخدام الأداة المساعدة لتحديد موقع Expressway الموضحة.

تحديد موقع الأداة المساعدة

تكون الأداة المساعدة لتحديد الموقع في Expressway مفيدة إذا كنت تريد إختبار ما إذا كان بإمكان Expressway توجيه مكالمة إلى منطقة معينة استنادا إلى اسم مستعار محدد. كل ذلك يمكن انجازه دون الحاجة إلى إجراء مكالمة حقيقية. يمكن العثور على الأداة المساعدة "تحديد الموقع" على Expressway تحت الصيانة > أدوات > قائمة تحديد الموقع. سترى بعض التعليمات حول كيفية إستخدام وظيفة Location على Expressway-C لتحديد ما إذا كان بإمكان الخادم توجيه مكالمة استنادا إلى FQDN الخاص بمجموعة CM الموحدة الموجودة في رأس مسار SIP.

1. انتقل إلى صيانة > أدوات > تحديد موقع.

2. أدخل FQDN لمجموعة CM الموحدة في حقل الاسم المستعار.

3. حدد SIP كبروتوكول.

4. حدد منطقة عميل المحول المختلط من Cisco Webex للمصدر.

5. حدد تحديد موقع.

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

هنا نتائج تحديد الموقع. و المزخرفة هي قيم الفائدة. تظهر هذه النتائج:

- حقيقة أنه يمكن توجيه الاسم المستعار (صحيح)

- معلومات المصدر (اسم/نوع المنطقة)

- معلومات الوجهة (الاسم المستعار الذي يتم توجيهه)

- قاعدة البحث التي يتم مطابقتها (التوجيه الوارد لخدمة المكالمات المختلطة)

- المنطقة التي سيتم إرسال المكالمة إليها (CUCM11)

Search (1)

State: Completed

Found: True

Type: SIP (OPTIONS)

SIPVariant: Standards-based

CallRouted: True

CallSerial Number: ae73fb64-c305-457a-b7b3-59ea9688c630

Tag: 473a5b19-9a37-40bf-bbee-6f7bc94e7c77

Source (1)

Authenticated: True

Aliases (1)

Alias (1)

Type: Url

Origin: Unknown

Value: xcom-locate

Zone (1)

Name: Hybrid Call Service Traversal

Type: TraversalClient

Path (1)

Hop (1)

Address: 127.0.0.1

Destination (1)

Alias (1)

Type: Url

Origin: Unknown

Value: sip:cucm.rtp.ciscotac.net

StartTime: 2017-09-24 09:51:18

Duration: 0.01

SubSearch (1)

Type: Transforms

Action: Not Transformed

ResultAlias (1)

Type: Url

Origin: Unknown

Value: cucm.rtp.ciscotac.net

SubSearch (1)

Type: Admin Policy

Action: Proxy

ResultAlias (1)

Type: Url

Origin: Unknown

Value: cucm.rtp.ciscotac.net

SubSearch (1)

Type: FindMe

Action: Proxy

ResultAlias (1)

Type: Url

Origin: Unknown

Value: cucm.rtp.ciscotac.net

SubSearch (1)

Type: Search Rules

SearchRule (1)

Name: as is local

Zone (1)

Name: LocalZone

Type: Local

Protocol: SIP

Found: False

Reason: Not Found

StartTime: 2017-09-24 09:51:18

Duration: 0

Gatekeeper (1)

Address: 192.168.1.5:0

Alias (1)

Type: Url

Origin: Unknown

Value: cucm.rtp.ciscotac.net

Zone (2)

Name: LocalZone

Type: Local

Protocol: H323

Found: False

Reason: Not Found

StartTime: 2017-09-24 09:51:18

Duration: 0

Gatekeeper (1)

Address: 192.168.1.5:0

Alias (1)

Type: Url

Origin: Unknown

Value: cucm.rtp.ciscotac.net

SearchRule (2)

Name: Hybrid Call Service Inbound Routing

Zone (1)

Name: CUCM11

Type: Neighbor

Protocol: SIP

Found: True

StartTime: 2017-09-24 09:51:18

Duration: 0

Gatekeeper (1)

Address: 192.168.1.21:5065

Alias (1)

Type: Url

Origin: Unknown

Value: cucm.rtp.ciscotac.net

التسجيل التشخيص

في أي وقت تقوم فيه باستكشاف أخطاء الاتصال أو الوسائط وإصلاحها لمكالمة تعبر حل Expressway وإصلاحها، يجب إستخدام التسجيل التشخيصي. توفر هذه الإمكانية للطرق السريعة للمهندس معلومات تفصيلية حول جميع القرارات المنطقية التي يمر بها الطريق السريع أثناء مرور المكالمة. كما يمكنك مشاهدة رسائل SIP الخاصة ببكامل الجسم وكيفية مرور الطريق السريع التي تمر عبر هذه الاستدعاء وكيفية إعداد الطريق السريع لقنوات الوسائط. يحتوي تسجيل التشخيص على عدد من الوحدات النمطية المختلفة التي تغذي التسجيل. يمكن تعديل مستويات التسجيل لإظهار قيمة مميتة أو خطأ أو تحذير أو معلومات أو تصحيح أخطاء أو تتبع. بشكل افتراضي، يتم تعيين كل شيء إلى معلومات التي تلتقط كل شيء تقريبا تحتاج إليه لتشخيص مشكلة. من وقت لآخر، قد تحتاج لضبط مستوى تسجيل وحدة نمطية معينة من المعلومات إلى تصحيح الأخطاء للحصول على فهم أفضل لما يحدث. توضح الخطوات التالية كيف يمكنك تعديل مستويات تسجيل وحدة Developer.ssl المسؤولة عن توفير المعلومات الخاصة بالمصافحة (المتبادلة) عبر TLS.

1. قم بتسجيل الدخول إلى خادم Expressway (يجب القيام به على كل من Expressway-E و C).

2. انتقل إلى الصيانة > التشخيصات > متقدم > تكوين سجل الدعم.

3. قم بالتمرير إلى الوحدة النمطية التي ترغب في ضبطها، في هذا المثيل Developer.ssl وانقر فوقها.

4. بجوار معلمة المستوى، أختر تصحيح الأخطاء من القائمة.

5. طقطقة حفظ.

عند هذه النقطة، تكون مستعدا لالتقاط التسجيل التشخيصي:

1. قم بتسجيل الدخول إلى خادم Expressway (يجب القيام به على كل من Expressway-E و C).

2. انتقل إلى الصيانة > التشخيصات > التسجيل التشخيصي.

3. انقر على بدء سجل جديد (تأكد من تحديد خيار tcpdump).

4. قم بإعادة إنتاج المشكلة.

5. انقر فوق إيقاف التسجيل.

6. انقر فوق سجل التنزيل.

بالنسبة للتسجيل التشخيصي من Expressway، تذكر أنك قد تبدأ التسجيل من كل من Expressway-C و Expressway-E بالتوازي: أولا، بدء تسجيل الدخول إلى Expressway-E، ثم الانتقال إلى Expressway-C وبدء التسجيل. عند تلك النقطة، يمكنك عندها إعادة إنتاج المشكلة.

ملاحظة: لا تحتوي حزمة سجل تشخيص Expressway/VCS حاليا على معلومات حول شهادة Expressway Server أو قائمة المرجع المصدق الموثوق به. إذا كانت لديك حالة يكون فيها الحصول على هذه الوظيفة مفيدا، فيرجى إرفاق حالتك بهذا العيب.

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

- دليل النشر لخدمات المكالمات المختلطة من Cisco Webex

- دليل التصميم المختلط من Cisco Webex

- دليل مسؤول Cisco Expressway

- الدعم التقني والمستندات - Cisco Systems