حل مشكلات حافة التعاون الأكثر شيوعا

المقدمة

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

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

يعد الوصول عن بعد ووصول الأجهزة المحمولة (MRA) حلا لنشر إمكانات Jabber التي لا تستخدم أية شبكة خاصة ظاهرية (VPN). يتيح هذا الحل للمستخدمين النهائيين إمكانية الاتصال بموارد المؤسسات الداخلية من أي مكان في العالم. تمت كتابة هذا الدليل لمنح المهندسين الذين يقومون باستكشاف أخطاء حل Collaboration Edge وإصلاحها القدرة على تحديد معظم المشاكل الشائعة التي تواجهها أثناء عبارة النشر وحلها بسرعة.

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

المتطلبات

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

• برنامج Cisco Unified Communications Manager (CUCM)
• Cisco Expressway Core
• Cisco Expressway Edge
• المراسلة الفورية والحضور (IM&P) من Cisco
• Cisco Jabber ل Windows
• Cisco Jabber ل Mac
• Cisco Jabber ل Android
• Cisco Jabber ل iOS®
• شهادات الأمان
• نظام اسم المجال (DNS)

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

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

• Expressway الإصدار X8.1.1 أو إصدار أحدث
• CUCM الإصدار 9.1(2)SU1 أو إصدار أحدث و IM&P الإصدار 9.1(1) أو إصدار أحدث
• Cisco Jabber الإصدار 9.7 أو إصدار أحدث

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

مشاكل تسجيل الدخول

يتعذر على Jabber تسجيل الدخول من خلال MRA

ويمكن ان يكون هذا العرض ناجما عن مجموعة واسعة من المشاكل، التي يجري ذكر بعضها هنا.

1. لم يتم إنشاء سجل خدمة Collaboration Edge (SRV) و/أو منفذ 8443 الذي يتعذر الوصول إليه

لكي يتمكن عميل Jabber من تسجيل الدخول بنجاح باستخدام MRA، يجب إنشاء سجل SRV خاص لحافة التعاون والوصول إليه خارجيا. عندما يتم بدء تشغيل عميل Jabber في البداية، فإنه يقوم بإجراء استعلامات DNS SRV:

1. _Cisco-UDS: يتم إستخدام سجل SRV هذا لتحديد ما إذا كان خادم CUCM متوفرا.
   
   
2. _cuplogin: يتم إستخدام سجل SRV هذا لتحديد ما إذا كان خادم IM&P متوفرا.
   
   
3. _collab-edge: يتم إستخدام سجل SRV هذا لتحديد ما إذا كانت MRA متوفرة.
   
   

إذا تم بدء تشغيل عميل Jabber ولم يستلم إجابة SRV ل _cisco-uds و_cuplogin ويتلقى إجابة ل _collab-edge، فإنه يستخدم هذه الإجابة لمحاولة الاتصال ب Expressway-E المدرج في إجابة SRV.

يشير سجل _collab-edge SRV إلى اسم المجال المؤهل بالكامل (FQDN) من Expressway-E مع المنفذ 8443. إذا لم يتم إنشاء SRV_collab-edge أو لم يكن متوفرا خارجيا، أو إذا كان متوفرا، ولكن لا يمكن الوصول إلى المنفذ 8443، فيفشل عميل Jabber في تسجيل الدخول.

يمكنك تأكيد ما إذا كان سجل _collab-edge SRV قابلا للحل وما إذا كان يمكن الوصول إلى منفذ TCP 8443 باستخدام مدقق SRV في محلل حلول التعاون (CSA).

إن ليس ميناء 8443 reachable، هذا أمكن لأن أمن أداة (جدار حماية) يمنع الميناء أو misconfiguration من التقصير مدخل (GW) أو ساكن إستاتيكي مسحاج تخديد في ال exp-E.

2. شهادة غير مقبولة أو غير متوفرة على الطريق السريع VCS

بعد أن يتلقى عميل Jabber إجابة عن _collab-edge، يتصل بعد ذلك Expressway مع Transport Layer Security (TLS) عبر المنفذ 8443 لمحاولة إسترداد الشهادة من Expressway لإعداد TLS للاتصال بين عميل Jabber و Expressway.

إذا لم يكن Expressway لديه شهادة موقعة صالحة تحتوي على FQDN أو مجال Expressway، فسيفشل ذلك ويفشل عميل Jabber في تسجيل الدخول.

في حالة حدوث هذه المشكلة، أستخدم أداة طلب توقيع الشهادة (CSR) على Expressway، والتي تتضمن تلقائيا FQDN الخاص ب Expressway كاسم بديل للموضوع (SAN).

ملاحظة: تتطلب إدارة الوصول عن بعد (MRA) وجود اتصال آمن بين Expressway-C و Expressway-E وبين نقاط النهاية الخارجية.

يمكن العثور على الجدول التالي الذي يحتوي على متطلبات شهادة Expressway حسب الميزة في دليل نشر MRA:

3. لم يتم العثور على خوادم UDS في تكوين الحافة

بعد أن يقوم عميل Jabber بإنشاء اتصال آمن مع Expressway-E بنجاح، فإنه يطلب تكوين الحافة الخاصة به (get_edge_config). يحتوي تكوين الحافة هذا على سجلات SRV ل _cuplogin و_cisco-uds. إذا لم يتم إرجاع سجلات _cisco-uds SRV في تكوين الحافة، فلن يتمكن عميل Jabber من متابعة تسجيل الدخول.

ولإصلاح هذا الأمر، تأكد من إنشاء سجلات _cisco-uds SRV داخليا وقابل للحل بواسطة Expressway-C.

يمكن العثور على مزيد من المعلومات حول سجلات DNS SRV في دليل نشر MRA الخاص ب X8.11.

وهذا أيضا عرض شائع إذا كنت في مجال مزدوج. إذا قمت بتشغيل مجال مزدوج ووجدت أن عميل Jabber لم يتم إرجاعه إلى أي خدمة بيانات مستخدم (UDS)، فيجب عليك تأكيد إنشاء سجلات _Cisco-UDS SRV في DNS الداخلي مع المجال الخارجي.

ملاحظة: بعد إصدار Expressway Version X12.5، لم يعد من الضروري إضافة سجل SRV ل _Cisco-UDS إلى DNS الداخلي. لمزيد من المعلومات حول هذا التحسين، راجع الوصول المتنقل والوصول عن بعد من خلال دليل نشر Expressway من Cisco (X12.5).

4. تظهر سجلات Expressway-C هذا الخطأ: XCP_JABBERD Detail=غير قادر على الاتصال بالمضيف '٪IP٪'، المنفذ 7400:(111) تم رفض الاتصال

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

1. يستخدم بطاقة واجهة شبكة (NIC) واحدة.
2. تم تثبيت مفتاح خيار الشبكة المتقدمة.
3. تم تعيين خيار إستخدام واجهات الشبكة المزدوجة على نعم.

لتصحيح هذه المشكلة، قم بتغيير خيار إستخدام واجهات الشبكة المزدوجة إلى لا.

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

5. لا يتطابق اسم المضيف/اسم المجال لخادم Expressway-E مع ما تم تكوينه في SRV _collab-edge

إذا لم يتطابق اسم/مجال خادم Expressway-E في تكوين صفحة DNS مع ما تم إستقباله في إجابة SRV _collab-edge، فلن يتمكن عميل Jabber من الاتصال ب Expressway-E. يستخدم عميل Jabber عنصر xmppEdgeServer/Address في إستجابة get_edge_config لإنشاء اتصال XMPP ب Expressway-E.

هذا مثال على ما يبدو عليه xmppEdgeServer/Address في إستجابة get_edge_config من Expressway-E إلى عميل Jabber:

<xmppEdgeServer>
<server>
<address>examplelab-vcse1.example URL</address>
<tlsPort>5222</tlsPort>
</server>
</xmppEdgeServer>

لتجنب هذا، تأكد من أن سجل _collab-edge SRV يطابق اسم المضيف/اسم المجال ل Expressway-E. تم تصنيف معرف تصحيح الأخطاء من Cisco CSCuo83458 لهذا الدعم وأضيف دعم جزئي على معرف تصحيح الأخطاء من Cisco CSCuo82526.

6. تعذر تسجيل الدخول بسبب الاشتراك الحالي في اتصال WebEx

تظهر Jabber لسجلات Windows هذا:

2014-11-22 19:55:39,122 INFO  [0x00002808] [very\WebexCasLookupDirectorImpl.cpp(134)]
[service-discovery] [WebexCasLookupDirectorImpl::makeCasLookupWhenNetworkIs
Available] - makeCasLookupForDomain result is  'Code: IS_WEBEX_CUSTOMER; Server: 
http://URL server; 
Url: http://example URL server';;;.2014-11-22 
19:55:39,122 INFO  [0x00002808] [overy\WebexCasLookupDirectorImpl.cpp(67)]
[service-discovery] [WebexCasLookupDirectorImpl::determineIsWebexCustomer] - 
Discovered Webex Result from server. Returning server result.2014-11-22 19:55:39,122 
DEBUG [0x00002808] [ery\WebexCasLookupUrlConfigImpl.cpp(102)]
[service-discovery] [WebexCasLookupUrlConfigImpl::setLastCasUrl] - setting last_cas_
lookup_url : http://example URL server2014-11-22 
19:55:39,123 DEBUG [0x00002808] [pters\config\ConfigStoreManager.cpp(286)]
[ConfigStoreManager] [ConfigStoreManager::storeValue] - key : [last_cas_lookup_url]
value : [http://example URL server/cas/FederatedSSO?org=example URL]2014-11-22 
19:55:39,123 DEBUG [0x00002808] [common\processing\TaskDispatcher.cpp(29)]
[TaskDispatcher] [Processing::TaskDispatcher::enqueue] - Enqueue ConfigStore::persist
Values - Queue Size: 02014-11-22 19:55:39,123 DEBUG [0x00002808] [pters\config\ConfigStore
Manager.cpp(140)]
[ConfigStoreManager] [ConfigStoreManager::getValue] - key : [last_cas_lookup_url] 
skipLocal : [0]  value: [http://website URL/cas/FederatedSSO?org=example URL]
success: [true] configStoreName: [LocalFileConfigStore]

يتم توجيه محاولات تسجيل الدخول إلى اتصال WebEx.

للحصول على حل دائم، يجب الاتصال ب WebEx حتى يتم إلغاء تشغيل الموقع.

الحل

في المدى القصير، يمكنك إستخدام أحد هذه الخيارات لاستبعاده من البحث.

• قم بإضافة هذه المعلمة إلى jabber-config.xml. ثم قم بتحميل ملف Jabber-config.xml إلى خادم TFTP على CUCM. يتطلب أن يقوم العميل بتسجيل الدخول داخليا أولا.
  
  

  <?xml version="1.0" encoding="utf-8"?>
  <config version="1.0">
  <Policies>
  <ServiceDiscoveryExcludedServices>WEBEX<
  /ServiceDiscoveryExcludedServices>
  </Policies>
  </config>

• من منظور تطبيق، قم بتشغيل ما يلي:
  msiexec.exe /i CiscoJabberSetup.msi /quiet clear=1 Authenticator=CUP Excluded_Services=Webex

ملاحظة: لا يعمل الخيار الثاني مع الأجهزة المحمولة.

• إنشاء عنوان URL قابل للنقر يستثني خدمة Webex:
  ciscojabber://provision?ServiceDiscoveryExcludedServices=WEBEX

يمكنك العثور على مزيد من التفاصيل حول اكتشاف خدمة الاتصالات الموحدة وكيفية إستبعاد بعض الخدمات في النشر المحلي ل Cisco Jabber 12.8.

7. يعرض خادم Expressway-C رسالة الخطأ: "مكونة ولكن مع أخطاء. خادم الإمداد: في انتظار معلومات خادم التقاطع.

إذا قمت بالانتقال إلى الحالة > الاتصالات الموحدة ورأيت رسالة الخطأ، "مكونة ولكن مع أخطاء. خادم الإمداد: في انتظار معلومات الخادم التبادلي." بالنسبة لتسجيلات Unified CM وخدمة IM&P، يحتوي خادم (خوادم) DNS الداخلية التي تم تكوينها على Expressway-C على سجلي DNS A ل Expressway-E. قد يكون السبب وراء العديد من سجلات DNS A ل Expressway-E أن المستخدم المتأثر انتقل من بطاقة واجهة شبكة (NIC) واحدة مع تمكين NAT الثابت على Expressway-E إلى بطاقة واجهة شبكة (NIC) مزدوجة مع تمكين NAT الثابت، أو العكس، ونسيت حذف سجل DNS A المناسب في خادم (خوادم) DNS الداخلية. لذلك، عند إستخدام أداة بحث DNS المساعدة في Expressway-C وحل Expressway-E FQDN، تلاحظ سجلي DNS A.

الحل

إن Expressway-E NIC يكون شكلت ل وحيد NIC مع ساكن إستاتيكي nat:

1. احذف سجل DNS A لعنوان IP الداخلي ل Expressway-E في خادم (خوادم) DNS التي تم تكوينها في Expressway-C.
2. قم بمسح ذاكرة التخزين المؤقت ل DNS في Expressway-C والكمبيوتر الشخصي للمستخدم عبر CMD (IPCONFIG /flushdns).
3. قم بإعادة تمهيد خادم Expressway-C.

إن Expressway-E NIC يكون شكلت لمزدوج NIC مع ساكن إستاتيكي nat يمكن:

1. احذف سجل DNS A لعنوان IP الخارجي ل Expressway-E في خادم (خوادم) DNS التي تم تكوينها في Expressway-C.
2. قم بمسح ذاكرة التخزين المؤقت ل DNS في Expressway-C وجهاز كمبيوتر المستخدم عبر CMD (IPCONFIG /flushdns).
3. قم بإعادة تمهيد خادم Expressway-C.،

8. تم تثبيت Microsoft DirectAccess

إذا كنت تستخدم Microsoft DirectAccess على نفس جهاز الكمبيوتر مثل عميل Jabber، فعند محاولة تسجيل الدخول عن بعد، قد يؤدي ذلك إلى كسر MRA. يفرض DirectAccess إنشاء قنوات لاستعلامات DNS في الشبكة الداخلية كما لو كان الكمبيوتر الشخصي يستخدم شبكة VPN.

ملاحظة: لا يتم دعم Microsoft DirectAccess مع Jabber عبر MRA. يعد أي أستكشاف الأخطاء وإصلاحها أفضل جهد. تكوين DirectAccess هو مسؤولية مسؤول الشبكة.

في بعض الأحيان يمكنك حظر كافة سجلات DNS بنجاح في جدول نهج تحليل اسم Microsoft DirectAccess. لا تتم معالجة هذه السجلات بواسطة DirectAccess (يجب أن تكون Jabber قادرة على حل هذه المشاكل عبر DNS العام باستخدام MRA):

• سجل SRV ل _Cisco-UDS
• سجل SRV ل _cuplogin
• سجل SRV ل _collab-edge
• سجل لكافة Expressway ES

9. فشل عمليات البحث العكسية عن DNS في Expressway

بداية من الإصدار X8.8، يتطلب Expressway/VCS إنشاء إدخالات DNS العكسية والتأفقية ل ExpE و ExpC وجميع عقد CUCM. 

للحصول على المتطلبات الكاملة، راجع المتطلبات الأساسية وتبعيات البرامج في ملاحظات الإصدار x8.8 وسجلات DNS للوصول إلى الأجهزة المحمولة والوصول عن بعد.

إذا لم تكن سجلات DNS الداخلية موجودة، فقد يكون هناك خطأ في سجلات Expressway يشير إلى reverseDNSLookup:

2016-07-30T13:58:11.102-06:00 hostname XCP_JABBERD[20026]: UTCTime="2016-07-30 19:58:11,102" ThreadID="139882696623872" Module="Jabber" Level="WARN " CodeLocation="cvsservice.cpp:409" Detail="caught exception: exception in reverseDNSLookup: reverse DNS lookup failed for address=x.x.x.x"

يستقبل Expressway-C شبكة FQDN واحدة فقط عند الاستعلام عن سجل PTR الخاص ب Expressway-E IP. إذا إستلمت FQDN غير صحيح من DNS، فإنها تظهر هذا السطر في السجلات وتفشل:

2020-04-03T17:48:43.685-04:00 hostname XCP_JABBERD[10043]: UTCTime="2020-04-03 21:48:43,685" ThreadID="140028119959296" Module="Jabber" Level="WARN " CodeLocation="cvsservice.cpp:601" Detail="Certificate verification failed for host=xx.xx.xx.xx, additional info: Invalid Hostname"

مشاكل التسجيل

Softphone غير قادر على التسجيل، غير مسموح بطريقة SIP/2.0 405

يظهر سجل تشخيص من Expressway-C رسالة SIP/2.0 405 Method غير مسموح بها إستجابة لطلب التسجيل الذي أرسله عميل Jabber. من المحتمل أن يكون هذا بسبب جلسة عمل حالية بدء بروتوكول (SIP) شنطة بين Expressway-C و CUCM مع ميناء 5060/5061.

SIP/2.0 405 Method Not Allowed
Via: SIP/2.0/TCP 10.10.40.108:5060;egress-zone=CollabZone;branch=z9hG4bK81e7f5f1c1
ab5450c0b406c91fcbdf181249.81ba6621f0f43eb4f9c0dc0db83fb291;proxy-call-id=da9e25aa-
80de-4523-b9bc-be31ee1328ce;rport,SIP/2.0/TLS 10.10.200.68:7001;egress-zone=Traversal
Zone;branch=z9hG4bK55fc42260aa6a2e3741919177aa84141920.a504aa862a5e99ae796914e85d35
27fe;proxy-call-id=6e43b657-d409-489c-9064-3787fc4919b8;received=10.10.200.68;rport=
7001;ingress-zone=TraversalZone,SIP/2.0/TLS 
192.168.1.162:50784;branch=z9hG4bK3a04bdf3;received=172.18.105.10;rport=50784;
ingress-zone=CollaborationEdgeZone
From: <sip:5151@collabzone>;tag=cb5c78b12b4401ec236e1642-1077593a
To: <sip:5151@collabzone>;tag=981335114
Date: Mon, 19 Jan 2015 21:47:08 GMT
Call-ID: cb5c78b1-2b4401d7-26010f99-0fa7194d@192.168.1.162
Server: Cisco-CUCM10.5
CSeq: 1105 REGISTER
Warning: 399 collabzone "SIP trunk disallows REGISTER"
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0 

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

CUCM

1. قم بإنشاء ملف تعريف أمان جديد لشنطة SIP باستخدام منفذ إستماع آخر غير 5060 (5065).
2. قم بإنشاء خط اتصال SIP مقترن بملف تعريف أمان خط اتصال SIP ووجهة تم تعيينها على عنوان IP ل Expressway-C، المنفذ 5060.

Expressway-C

1. قم بإنشاء منطقة مجاورة ل CUCM (المناطق) باستخدام منفذ هدف آخر غير 5060 (5065) لمطابقة تكوين CUCM.
2. في إعدادات Expressway-C > البروتوكولات > SIP، تأكد من أن Expressway-C لا يزال يصغي إلى SIP على 5060.

Softphone غير قادر على التسجيل، السبب="مجال غير معروف"

يظهر سجل تشخيص من Expressway-C الحدث="Registration Rejected" Reason="Unknown domain" service="sip" src-ip="xxx.xxx.xxx.xxx" src-port="51601" protocol="TCP" aor="sip:xxx.xxx.xxx".

in order to صححت هذا إصدار، فحصت هذا نقطة:

• هل يستخدم عميل Jabber ملف تعريف أمان الجهاز الآمن في CUCM عندما لا تكون النية هي إستخدام ملف تعريف أمان جهاز غير آمن؟
  
  
• إذا كان عملاء Jabber يستخدمون ملف تعريف أمان جهاز مؤمن، فهل هو اسم ملف تعريف الأمان بتنسيق FQDN وهل يتم تكوين اسم FQDN هذا على شهادة Expressway-C كشبكة منطقة تخزين (SAN)؟
  
  
• إذا كان عملاء Jabber يستخدمون ملف تعريف أمان جهاز مؤمن، انتقل إلى System > معلمات Enterprise > معلمات الأمان > وضع أمان نظام نظام المجموعة وتحقق من تعيين وضع أمان نظام نظام المجموعة على 1 للتحقق من تأمين نظام CUCM. إذا كانت القيمة 0، فيجب على المسؤول المرور عبر الإجراء الموثق لتأمين نظام المجموعة.

Softphone غير قادر على التسجيل، السبب "انتهاء صلاحية العد التنازلي الخامل"

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

2015-02-02T19:46:31+01:00 collabedge tvcs: UTCTime="2015-02-02 18:46:31,144" 
Module="network.tcp" Level="DEBUG":  Src-ip="JabberPubIP" Src-port="4211" 
Dst-ip="VCS-E_IP" Dst-port="5061" Detail="TCP Connecting"
2015-02-02T19:46:31+01:00 collabedge tvcs: UTCTime="2015-02-02 18:46:31,144" 
Module="network.tcp" Level="DEBUG":  Src-ip="JabberPubIP" Src-port="4211" Dst-ip=
"VCS-E_IP" Dst-port="5061" Detail="TCP Connection Established"2015-02-02T19:46:49+01:00 
collabedge tvcs: UTCTime="2015-02-02 18:46:49,606" 
Module="network.tcp" Level="DEBUG":  Src-port="4211" Dst-ip=
"VCS-E_IP" Dst-port="5061" Detail="TCP Connection Closed" Reason="Idle 
countdown expired"

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

إذا واجهت هذا الموقف، فمن المحتمل بدرجة كبيرة أن يكون لجدار الحماية الموجود أمام Expressway-E وظيفة SIP Inspection/Application Layer Gateway (ALG) قيد التشغيل. لحل هذه المشكلة، يجب عليك إلغاء هذه الوظيفة. إذا لم تكن متأكدا من كيفية القيام بذلك، فارجع وثائق منتجات مورد جدار الحماية الخاص بك.

للحصول على مزيد من المعلومات حول فحص SIP/ALG، يمكنك الرجوع إلى الملحق 4 من دليل نشر التكوين الخاص بتكوين Expressway-E و Expressway-C-Basic من Cisco.

فشل MRA بسبب وكيل الهاتف المهيأ في البرامج الثابتة

يظهر سجل تشخيص من Expressway-E فشل تفاوض TLS في المنفذ 5061، ومع ذلك نجحت مصافحة SSL في المنفذ 8443.

2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,533" Module="network.tcp" Level="DEBUG": Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="TCP Connecting"
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,534" Module="network.tcp" Level="DEBUG": Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="TCP Connection Established"
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,535" Module="developer.ssl" Level="ERROR" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(67)" Method="::TTSSLErrorOutput" Thread="0x7fae4ddb1700": TTSSL_continueHandshake: Failed to establish SSL connection
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,535" Module="network.tcp" Level="DEBUG":  Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="TCP Connection Closed" Reason="Got EOF on socket"
2015-08-04T10:14:23-05:00 expe tvcs: Event="Inbound TLS Negotiation Error" Service="SIP"  Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="No SSL error available, probably remote disconnect" Protocol="TLS" Level="1" UTCTime="2015-08-04 15:14:23,535"

السجلات من Jabber:

-- 2015-08-04 10:48:04.775 ERROR [ad95000] - [csf.cert.][checkIdentifiers] Verification of identity: 'URL address' failed.
-- 2015-08-04 10:48:04.777 INFO [ad95000] - [csf.cert][handlePlatformVerificationResultSynchronously] Verification result : FAILURE reason : [CN_NO_MATCH UNKNOWN]
-- 2015-08-04 10:48:05.284 WARNING [ad95000] - [csf.ecc.handyiron][ssl_state_callback] SSL alert read:fatal:handshake failure
type=eSIP, isRelevant=true, server=URL server name:5061, connectionState=eFailed, isEncrypted=true, failureReason=eTLSFailure, SSLErrorCode=336151568
type=eSIP, isRelevant=true, server=192.168.102.253:5060, connectionState=eFailed, isEncrypted=false, failureReason=eFailedToConnect, serverType=ePrimary, role=eNone
-- 2015-08-04 10:48:05.287 ERROR [ad95000] - [csf.ecc.handyiron][secSSLIsConnected] SSL_do_handshake() returned : SSL_ERROR_SSL.

يظهر التقاط الحزمة من Jabber تفاوض SSL مع Expressway E IP، ومع ذلك فإن الشهادة المرسلة لا تأتي من هذا الخادم:

يحتوي FW على وكيل هاتف تم تكوينه.

الحل:

تأكد من تشغيل FW لوكيل الهاتف. للتحقق من ذلك، أدخل الأمر show run policy-map ويظهر لك شيئا مشابها ل:

class sec_sip
inspect sip phone-proxy ASA-phone-proxy

قم بتعطيل "وكيل الهاتف" لخدمات الهاتف للاتصال بنجاح.

المشاكل المتعلقة بالاتصال

لا توجد وسائط عند الاتصال عبر MRA

هذه بعض من التكوينات غير الصحيحة والخاملة التي يمكن أن تتسبب في هذه المشكلة في عمليات نشر بطاقات واجهة الشبكة (NIC) الأحادية والثنائية:

• لا يتم تكوين NAT الثابت في Expressway-E تحت النظام > واجهات الشبكة > IP. nat في الشبكة طبقة بعد يحتاج أن يكون في جدار الحماية، غير أن هذا إعداد يترجم ال ip في التطبيق طبقة.
• منافذ TCP/UDP غير مفتوحة في جدار الحماية. للحصول على قائمة بالمنافذ، ارجع إلى دليل تكوين إستخدام منفذ Cisco Expressway IP.

لا يوصى باستخدام بطاقة واجهة شبكة (NIC) واحدة مع عمليات نشر NAT الثابتة. فيما يلي بعض الاعتبارات لمنع المسائل الإعلامية:

• في منطقة مرور الاتصالات الموحدة (UC)، يحتاج Expressway-C إلى الإشارة إلى عنوان IP العام المكون في Expressway-E.
• يجب أن تكون الوسائط "فائقة الأداء" أو معكوسة في جدار الحماية الخارجي. يمكن العثور على مثال تكوين مع جدار حماية Cisco ASA في تكوين انعكاس NAT على ASA لأجهزة VCS Expressway TelePresence. 

يمكن العثور على مزيد من المعلومات حول هذا الأمر في الملحق 4 من دليل نشر التكوين الأساسي ل Cisco Expressway-E و Expressway-C.

لا يوجد رد اتصال عند الاتصال ب MRA إلى PSTN

ترجع هذه المشكلة إلى وجود قيود على ExpressWay قبل الإصدار X8.5. يصف معرف تصحيح الأخطاء من Cisco CSCua72781 كيف لا يقوم Expressway-C بإعادة توجيه الوسائط المبكرة في تقدم جلسة 183 أو 180 رنين عبر منطقة التجتاز. إذا قمت بتشغيل الإصدارات X8.1.x أو X8.2.x، فيمكنك الترقية إلى الإصدار X8.5 أو تنفيذ الحل البديل المدرج هنا.

من الممكن إستخدام حل بديل على عنصر الحدود الموحدة (CUBE) من Cisco إذا قمت بإنشاء ملف تعريف SIP يحول 183 إلى 180 ويطبقه على نظير الطلب الوارد. على سبيل المثال:

voice class sip-profiles 11
response 183 sip-header SIP-StatusLine modify "SIP/2.0 183 Session Progress" 
"SIP/2.0 180 Ringing"

بعد ذلك، يقومون بتعطيل 180 وسائط مبكرة إما على ملف تعريف SIP ل CUCM > CUBE أو CUBE نفسه في وضع تكوين SIP-UA.

disable-early-media 180

مشاكل CUCM و IM&P

خطأ ASCII يمنع إضافة CUCM 

عند إضافة CUCM إلى Expressway-C، تواجه خطأ ASCII يمنع إضافة CUCM.

عندما يضيف Expressway-C CUCM إلى قاعدة بياناته، فإنه يمر بسلسلة من استعلامات AXL التي تتعلق بوظائف get and list. وتتضمن الأمثلة على ذلك getCallManager وlistCallManager وlistProcessNode وlistProcessNodeService وgetCCMVersion. بعد تشغيل عملية getCallManager، يتم تشغيلها بواسطة مجموعة ExecuteSQLQuery لاسترداد كافة ميزات CUCM Call Manager-trust أو Tomcat-trust.

بمجرد أن يتلقى CUCM الاستعلام وينفذ عليه، تقوم CUCM بعد ذلك بإبلاغ جميع شهاداتها. إذا كانت إحدى الشهادات تحتوي على حرف غير ASCII، فسيقوم Expressway بتوليد خطأ في واجهة الويب مماثل ل "لا يمكن ل ترميز ASCII فك ترميز البايت 0xc3 في الموضع 42487: ترتيبي ليس في النطاق (128).

تتبعت هذا إصدار مع cisco بق id CSCuo54489 وحللت في صيغة X8.2.

حالات فشل TLS الصادرة على 5061 من Expressway-C إلى CUCM في عمليات النشر الآمنة

يقع هذا إصدار عندما يستعمل أنت توقيع ذاتي على CUCM و Tomcat.pem/CallManager.pem يتلقى ال نفسه موضوع. عولجت الإصدار مع cisco بق id CSCun30200. الحل البديل لتصحيح المشكلة هو حذف tomcat.pem وتعطيل TLS التحقق من تكوين CUCM على Expressway-C.

لم تتم إضافة خادم IM&P وواجهت أخطاء

عند إضافة خادم IM&P، يشير Expressway-C إلى أن "هذا الخادم ليس خادم IM و Presence" أو "غير قادر على الاتصال بخطأ HTTP لاستعلام .AXL "'httpeRror:500"، والذي ينتج عنه عدم إضافة خادم IM&P.

كجزء من إضافة خادم IM&P، يستخدم Expressway-C استعلام AXL للبحث عن شهادات IM&P في دليل صريح. بسبب معرف تصحيح الأخطاء من Cisco CSCul05131، فإن الشهادات ليست في هذا المخزن؛ لذلك، أنت تواجه الخطأ الخطأ الخطأ.

مسائل متنوعة

تظهر حالة البريد الصوتي على عميل Jabber "غير متصل"

لتمكين حالة البريد الصوتي الخاصة بعميل Jabber من الاتصال بنجاح، يجب تكوين عنوان IP الخاص باتصال Cisco Unity Connection أو اسم المضيف داخل قائمة السماح الخاصة ب HTTP على Expressway-C.

لإكمال ذلك من Expressway-C، قم بتنفيذ الإجراء ذي الصلة:

إجراء الإصدارين x8.1 و x8.2

1. انقر فوق تكوين > الاتصالات الموحدة > تكوين > تكوين قائمة السماح الخاصة بخادم HTTP.
2. انقر فوق جديد > إدخال IP/اسم المضيف > إنشاء إدخال.
3. قم بتسجيل الخروج من عميل Jabber، ثم قم بتسجيل الدخول مرة أخرى.

إجراء الإصدار X8.5

1. انقر على تكوين > الاتصالات الموحدة > خوادم اتصال الوحدة.
2. انقر فوق جديد > إدخال IP/اسم المضيف، مسوغات حساب المستخدم > إضافة عنوان.
3. قم بتسجيل الخروج من عميل Jabber، ثم قم بتسجيل الدخول مرة أخرى.

لا تظهر صور جهات الاتصال على عملاء Jabber من خلال Expressway

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

1. يجب تعديل الملف jabber-config.xml لتوجيه العملاء إلى خادم الويب لدقة صورة جهة الاتصال. التكوين هنا يحقق ذلك.
   
   

   <Directory>
   <DirectoryServerType>UDS</DirectoryServerType>
   <PhotoUriWithToken>http://%IP/Hostname%/photo%%uid%%.jpg<
   /PhotoUriWithToken>
   <UdsServer>%IP%</UdsServer>
   <MinimumCharacterQuery>3</MinimumCharacterQuery>
   </Directory>

2. 1. انقر فوق تكوين > الاتصالات الموحدة > تكوين > تكوين قائمة السماح الخاصة بخادم HTTP.
   2. انقر فوق جديد > إدخال IP/اسم المضيف > إنشاء إدخال.
   3. قم بتسجيل الخروج من عميل Jabber، ثم قم بتسجيل الدخول مرة أخرى.يجب أن يحتوي Expressway-C على خادم الويب المدرج ضمن قائمة السماح لخادم HTTP.

   ملاحظة: لمزيد من المعلومات حول دقة صورة جهة اتصال UDS، ارجع إلى وثائق صورة جهة اتصال Jabber.

تتم مطالبة عملاء Jabber بقبول شهادة Expressway-E أثناء تسجيل الدخول

يمكن أن تكون رسالة الخطأ هذه مرتبطة بشهادة Expressway Edge غير الموقعة من قبل مرجع مصدق عام موثوق به من قبل جهاز العميل أو أن المجال غير موجود كشبكة تخزين (SAN) في شهادة الخادم.

لإيقاف عميل Jabber من مطالبة قبول شهادة Expressway، يجب أن تستوفي المعيارين الواردين أدناه:

• يجب أن يكون لدى الجهاز/الجهاز الذي يقوم بتشغيل عميل Jabber الموقع الخاص بشهادة Expressway-E المذكورة داخل مخزن الشهادات الموثوق به.
  
  

  ملاحظة: يمكن تحقيق ذلك بسهولة إذا كنت تستخدم مرجع مصدق عام لأن الأجهزة المحمولة تحتوي على مخزن مصدق كبير.

• يجب أن يكون مجال تسجيل Unified CM المستخدم للسجل Collab-Edge موجودا داخل شبكة منطقة التخزين (SAN) لشهادة Expressway-E. تمنحك أداة CSR في خادم Expressway خيار إضافة مجال تسجيل CM الموحد كشبكة منطقة تخزين (SAN)، ويتم تحميلها مسبقا إذا تم تكوين المجال ل MRA. إذا كان المرجع المصدق الذي يوقع على الشهادة لا يقبل مجالا كشبكة تخزين (SAN)، فيمكنك أيضا إستخدام خيار "CollabEdgeDNS"، الذي يضيف البادئة "collab-edge" إلى المجال:

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

• دليل الوصول عن بعد أثناء التنقل عبر الطرق السريعة
• دليل نشر إنشاء شهادة Expressway واستخدامها من Cisco
• إستخدام منفذ IP لخادم إتصالات الفيديو (Cisco VCS) لنظام TelePresence لجدار الحماية
• دليل النشر والتثبيت ل Cisco Jabber
• الدعم التقني والمستندات - Cisco Systems