دليل أستكشاف الأخطاء وإصلاحها ل Cisco Webex Hybrid Call Service Connect

المقدمة

يصف هذا المستند حل 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 الموحدة الخاصة بهم. انظروا إلى هذا المثال، باستخدام أليس وبوب:

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

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

من منظور 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

الصادر: محلي إلى 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 
     

*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"

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)"

*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"

*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"

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>

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

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: 
      
       "

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" 

*c xConfiguration Policy AdministratorPolicy Mode: "LocalCPL"

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

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

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

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.

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

 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: 
      
      

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