تكوين CMS WebRTC أو وكيل Web App عبر Expressway

المقدمة

يصف هذا المستند خطوات تكوين WebRTC (CMS) لخادم الاجتماعات (Cisco Meeting Server) واستكشاف أخطائه وإصلاحها عبر Expressway.

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

المتطلبات

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

• ExpressWay X12.6.1 والإصدارات الأحدث (x12.6.1 والإصدارات الأحدث يمكن أن تعمل فقط مع CMS 2.9.2 أو إصدار أحدث بسبب التغييرات في سلوك EXP الدوران)
• خادم CMS 2.9.3 والإصدارات الأحدث
• ترجمة عنوان الشبكة (NAT)
• إجتياز باستخدام مرحلات (إستدارة) حول NAT 
• أدوات مساعدة تبادل الجلسات (STUN) ل NAT
• نظام اسم المجال (DNS)

المتطلبات الأساسية للتكوين:

• يجب تمكين الإعدادات الأساسية المتعلقة بالوصول عن بعد أو أثناء التنقل (MRA) (منطقة إجتياز الاتصالات الموحدة (UC) وأنفاق SSH) وتكوينها بالفعل على Expressway، انقر هنا للحصول على أدلة MRA.
• بالنسبة ل CMS 2.9.x - WebBridge (WB)، يتم تكوين XMPP و CallBridge على CMS وتمكينهما، راجع دليل التكوين
• قم بتشغيل مفتاح الخيار المثبت على Expressway-E. 
• تم فتح منفذ TCP رقم 443 على جدار الحماية من الإنترنت العام إلى عنوان IP العام ل Expressway-E.
• تم فتح منفذ TCP و UDP رقم 3478 (طلبات التحويل) على جدار الحماية من الإنترنت العام إلى عنوان IP العام الخاص ب Expressway-E.
  • لا يلزم وجود TCP 3478 إلا إذا تم تعيين 'turnservers' في CMS API على TCPPortNumberOverride على 3478.
• UDP Port 3478 (طلبات الدوران) المفتوحة على جدار الحماية من CMS إلى عنوان IP الخاص ل Expressway-E (إذا كنت تستخدم بطاقة واجهة شبكة (NIC) مزدوجة على Expressway-E).
  • يرسل CMS 2.9.2 وما قبله طلبات الربط إلى EXP E، بينما يرسل 2.9.3 بعد ذلك طلبات التخصيص
• سجلات DNS الخارجية لعنوان URL للانضمام إلى WebBridge، قابلة للحل إلى عنوان IP العام الموجود على واجهة Expressway-E.
• سجل DNS الداخلي لضم URL القابل للحل إلى عنوان IP الخاص بخادم WebBridge.
• في حالة تشغيل X12.5.2 أو إصدار أقدم، تأكد من أن انعكاس NAT مسموح به على جدار الحماية الخارجي لعنوان IP العام ل Expressway-E، انقر هنا على سبيل المثال التكوين. اعتبارا من X12.5.3، لم تعد هناك حاجة إلى إستخدام طريق سريع مستقل.
• عند إستخدام المنفذ 443 ل TURN، لا تزال بحاجة إلى فتح منفذ UDP 3478 للوسائط على جدار الحماية الخارجي. 

تحذير: عند تمكين منفذ TCP رقم 443، لم يعد بإمكان Expressway الاستجابة على منفذ TCP رقم 3478.

ملاحظة: لا يمكن إستخدام زوج Expressway الذي يتم إستخدامه لخدمات Jabber Guest لخدمات وكيل CMS WebRTC.

ملاحظة: في حالة الترقية إلى 3.0 أو إصدار أحدث من الإصدارات السابقة، يرجى الرجوع إلى الإرشادات الخاصة بالترقية السلسة من خادم الاجتماعات 2.9 إلى 3.0 من Cisco (وما بعده)

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

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

• واجهة برنامج تطبيق CMS (API)
• الطريق السريع
• خادم CMS

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

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

تمت إضافة دعم وكيل WebRTC إلى Expressway من الإصدار X8.9.2 الذي يمكن المستخدمين خارج الموقع من الاستعراض إلى Cisco Meeting Server Web Bridge.

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

اعتبارا من 5 فبراير/شباط 2021، هذه هي المستعرضات المدعومة ل CMS 3.1.1:

التكوين

الرسم التخطيطي للشبكة

توفر هذه الصورة مثالا على تدفق إتصالات وكيل الويب ل CMS WebRTC: (من دليل تكوين إستخدام منفذ Exp IP).

ملاحظة: عند تشغيل X12.5.2 أو إصدار سابق، يجب تكوين جدار الحماية الخارجي للسماح بانعكاس NAT لعنوان IP العام و Expressway-E (عادة ما تكون جدران الحماية حزم عدم الثقة التي تحتوي على نفس عنوان IP للمصدر والوجهة). اعتبارا من X12.5.3، لم تعد هناك حاجة إلى إستخدام طريق سريع مستقل.

خطوات التكوين

الخطوة 1. دمج CMS WB على Expressway-C

أ. انتقل إلى التكوين > الاتصالات الموحدة > خادم الاجتماعات من Cisco.

ب. تمكين Meeting Server Web Proxy.

ج. أدخل عنوان URL للانضمام في حقل URI لعميل حساب Guest.

د. انقر فوق حفظ.

ه. أضف عنوان URL للانضمام إلى CMS إلى شهادة خادم Expressway-E كاسم موضوع بديل (SAN). راجع إنشاء شهادة Cisco VCS واستخدام دليل النشر.

الخطوة 2. تمكين تشغيل Expressway-E وإضافة بيانات اعتماد المصادقة إلى قاعدة بيانات بيانات المصادقة المحلية

أ. انتقل إلى التكوين > Traversal > Turn.

ب. تمكين خدمات TURN، من إيقاف التشغيل إلى تشغيل.

c. أختر تكوين بيانات اعتماد عميل TURN على قاعدة البيانات المحلية وأضفت بيانات الاعتماد (اسم المستخدم وكلمة المرور).

ملاحظة: إذا كان لديك مجموعة من أنظمة Expressway-Es والتي سيتم إستخدامها جميعا كخوادم TURN، فتأكد من تمكينها على جميع العقد. يجب تكوين مثيلات TurnServer منفصلة عبر واجهة برمجة التطبيقات (API)، وتوجيهها إلى كل خادم من خوادم Expressway-E في المجموعة (وفقا لعملية التكوين الموضحة في الخطوة 4، والتي تظهر العملية لخادم Expressway-E واحد؛ وسيكون تكوين TurnServer الثاني مماثلا، فقط باستخدام عناوين IP المقابلة وقلب بيانات الاعتماد لخادم ExpressWay-E الآخر).

ملاحظة: يمكنك إستخدام موازن حمل الشبكة أمام الطرق السريعة الخاصة بك لحركة مرور بيانات TCP/HTTPS، ولكن يجب أن ينتقل TURN Media من العميل إلى IP العام الخاص بالخوادم. يجب ألا يمر Turn Media من خلال موازن حمل الشبكة

الخطوة 3. تغيير منفذ الإدارة ل Expressway-E

وهذه الخطوة مطلوبة نظرا لأن إتصالات WebRTC تأتي على TCP 443، ولكن قام EXP 12.7 بتقديم واجهة إدارة مخصصة جديدة (DMI) يمكن إستخدامها ل 443.

أ. انتقل إلى نظام > إدارة.

ب. تحت تكوين خادم الويب، قم بتغيير منفذ مسؤول الويب إلى 445 من الخيارات المنسدلة، ثم انقر فوق حفظ.

ج. كرر الخطوات من 3a إلى 3b على جميع Expressway-Es المستخدمة لخدمات وكيل WebRTC.

ملاحظة: توصي Cisco بتغيير منفذ الإدارة لأن عملاء WebRTC يستخدمون 443. إذا حاول مستعرض WebRTC الوصول إلى المنفذ 80، فإن Expressway-E يعيد توجيه الاتصال إلى 443.

الخطوة 4. إضافة Expressway-E كخادم (خوادم) TURN لمرور NAT للوسائط على خادم CMS

في CMS 2.9.x، أستخدم قائمة التكوين —> API لإضافة ملقمات التفات:

• serverAddress: (عنوان IP الخاص ل Expressway)
• عنوان العميل: (عنوان IP العام ل Expressway)
• النوع: (expressway)
• اسم المستخدم: (كما تم تكوينه في الخطوة 2c)
• كلمة المرور: (كما تم تكوينها في الخطوة 2c)
• tcpPortNumberOverride: 3478

د. كرر الخطوة 4c لكل خادم Expressway-E ليتم إستخدامه ل TURN

تقدم هذه الصورة مثالا للخطوات التكوينية:

التحقق من الصحة

استخدم هذا القسم لتأكيد عمل التكوين بشكل صحيح.

الخطوة 1. في Expressway-C، تأكد من أن WB مدمج بشكل صحيح

أ. انتقل إلى التكوين > الاتصالات الموحدة > خادم الاجتماعات من Cisco. أنت ينبغي رأيت العنوان من ال WB:

ب. انتقل إلى التكوين > الاتصالات الموحدة > قائمة السماح ل HTTP > القواعد المضافة تلقائيا. تحقق من إضافة هذا إلى القواعد:

Meeting Server web bridges 	https 	443 	Prefix 	/ 	GET, POST, PUT, HEAD, DELETE
Meeting Server web bridges 	wss 	443 	Prefix 	/ 	GET, POST, PUT, HEAD, DELETE

ملاحظة: لا يتوقع العثور على WB في العقد التي تم اكتشافها لأن القواعد هي ببساطة للسماح بوكيل حركة مرور HTTPS إلى WB، وليس بالضرورة للاتصال الموحد.

ج. تأكد من أنه قد تم إنشاء نفق Secure Shell (SSH) الخاص ب FQDN على Expressway-C إلى Expressway-E، ومن أنه نشط. انتقل إلى الحالة > الاتصالات الموحدة > حالة أنفاق SSH للاتصالات الموحدة. يجب أن ترى FQDN الخاص ب WB، ويجب أن يكون الهدف هو Expressway-E.

الخطوة 2. تحقق من إضافة خادم TURN إلى خادم CMS

في قائمة واجهة برمجة التطبيقات (API) ل CMS، ابحث عن ملقمات التشغيل، وانقر فوق كل ملقم. يوجد داخل كل كائن إرتباط للتحقق من الحالة:

يعرض الإخراج المعلومات التي تتضمن وقت الذهاب والعودة (RTT) بالمللي ثانية (مللي ثانية) المقترن بخادم TURN. هذه المعلومات مهمة لتحديد CB لأفضل خادم TURN لاستخدامه.

الخطوة 3. التحقق من إستخدام ترحيل الدوران أثناء المكالمة الجارية

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

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

أدوات مفيدة:

• ملف HAR من المستعرضات (كيفية إنشاء ملف HAR في Chrome أو Firefox)
• عملية تفريغ WebRTC InternalAls من المستعرض - chrome://webrtc-internals أو edge://webrtc-internals - إنشاء عملية تفريغ بمجرد محاولة الانضمام.
• يمكن أن تكون سجلات وحدة تحكم المستعرض مفيدة أيضا.
• التقاط Wireshark من العميل، EXP E و EXP C و CMS.
• تعليمات تصحيح أخطاء Exp E Network.http.TrafficServer حول أستكشاف أخطاء WebSocket وإصلاحها.

يتصل عميل WebRTC الخارجي ولكن لا توجد وسائط (بسبب فشل ICE)

في هذا السيناريو، يمكن لعميل RTC حل معرف المكالمة إلى jalero.space، ولكن عند إدخال اسمك وتحديد اتصال "انضمام"، يعرض العميل الاتصال، كما هو موضح في هذه الصورة:

بعد حوالي 30 ثانية، يتم إعادة توجيهها إلى صفحة WB الأولية.

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

• قم بتشغيل Wireshark على عميل RTC عند محاولة إجراء مكالمة وعند حدوث الفشل، قم بإيقاف الالتقاط.
• بعد حدوث المشكلة، تحقق من سجلات أحداث CMS:

انتقل إلى سجلات > سجلات الأحداث على WebAdmin CMS.

• تصفية آثار Wireshark باستخدام الصعق. راجع هذا المثال:

في آثار Wireshark، ترى أن العميل يرسل طلب التخصيص مع بيانات الاعتماد المكونة، إلى خادم Expressway-E TURN على المنفذ 3478:

1329    2017-04-15 10:26:42.108282    10.55.157.229    10.48.36.248    STUN    186 
   Allocate Request UDP user: expturncreds realm: TANDBERG with nonce

يرد الخادم بخطأ توزيع:

1363    2017-04-15 10:26:42.214119    10.48.36.248    10.55.157.229    STUN    254
    Allocate Error Response user: expturncreds with nonce realm: TANDBERG UDP error-code: 431
 (*Unknown error code*) Integrity Check Failure

 أو

3965    2017-04-15 10:34:54.277477    10.48.36.248    10.55.157.229    STUN    218
    Allocate Error Response user: expturncreds with nonce realm: TANDBERG UDP error-code: 401
 (Unauthorized) Unauthorized

في سجلات CMS، يتم عرض رسالة السجل هذه:

2017-04-15	10:34:56.536	Warning	call 7: ICE failure 4 (unauthorized - check credentials)

الحل:

تحقق من بيانات اعتماد TURN التي تم تكوينها على CMS، وتأكد من تطابقها مع ما تم تكوينه على قاعدة بيانات المصادقة المحلية ل Expressway-E.

لا يحصل عميل WebRTC الخارجي على خيار الاتصال للانضمام

في صفحة حالة CallBridge > عامة، يتم عرض هذا:

2017-04-15	12:09:06.647	Web bridge connection to "webbridge.alero.aca" failed (DNS failure)
2017-04-15	12:10:11.634	Warning	web bridge link 2: name resolution for "webbridge.alero.aca" failed
2017-04-15	11:55:50.835	Info	failed to establish connection to web bridge link 2 (unknown error)

الحل:

• تأكد من إمكانية حل CallBridge لعنوان URL المتصل ب WebBridge FQDN (يجب ألا يقوم CallBridge بحل هذا الأمر إلى عنوان IP الخاص ب Expressway-E).
• قم بمسح ذاكرة التخزين المؤقت ل DNS على CallBridge، عبر واجهة سطر الأوامر (CLI)، باستخدام تدفق DNS للأمر.
• تأكد من أن WB يثق بشهادة خادم CallBridge (وليس المصدر).

توقف عميل WebRTC الخارجي (على تحميل الوسائط) عند الاتصال ب Cospace ثم يعاد توجيهه إلى الصفحة الأولية ل WB

الحل:

• تأكد من أن CMS يمكنه حل سجل _xmpp-client SRV على الشبكة الداخلية لمجال CB، وتأكد من أن إتصالات WebRTC تعمل داخليا.
• تجميع التقاط Wireshark على العميل والتسجيل التشخيصي بما في ذلك tcpdump على Expressway-E أثناء محاولة الاتصال بالعميل الخارجي:

انتقل إلى الصيانة > التشخيصات > التسجيل التشخيصي وتأكد من تحديد أخذ tcpdump أثناء التسجيل، كما هو موضح في هذه الصورة، قبل تحديد بدء سجل جديد:

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

• قم باستخراج/فك ضغط حزمة السجل التي تم تنزيلها من Expressway-E وافتح ملف .pcap الذي تم الالتقاط على الواجهة الأمامية العامة.
• التصفية على كلا من حزم الالتقاط باستخدام الصعق:
  • ثم ابحث عن طلب الربط من العميل الخارجي إلى عنوان IP العام في Expressway-E، انقر بزر الماوس الأيمن وحدد المتابعة > تدفق UDP.
  • عادة ما يكون منفذ الوجهة لطلب الربط من العميل في النطاق 24000-2999، وهو نطاق منفذ TURN الخاص بترحيل الارتباطات على Expressway-E.
• إذا لم يتم تلقي إستجابة لطلبات التوثيق من جانب العميل، فتحقق من التقاط Expressway-E إذا كانت الطلبات واردة.
• إذا كانت الطلبات واردة وكان Expressway-E يرد على العميل، فتحقق مما إذا كان FW الخارجي يسمح بحركة مرور UDP الصادرة.
• إذا لم تكن الطلبات واردة، فتحقق من FW للتأكد من عدم حظر نطاق المنفذ المدرج سابقا.
• إن نشرت Expressway-E مع مزدوج شبكة قارن جهاز تحكم (مزدوج-NIC) مع ساكن إستاتيكي nat أسلوب يمكن و x12.5.2 أو مبكر، بعد ذلك ضمنت أن انعكاس nat ساندت وشكلت على فورتك الخارجي. اعتبارا من X12.5.3 لم تعد هناك حاجة لذلك في الطريق السريع المستقل.

يتعذر على عميل WebRTC الخارجي الانضمام إلى CoSpace والحصول على التحذير (تعذر الاتصال - إعادة المحاولة لاحقا)

في هذا السيناريو، يمكن لعميل RTC حل معرف المكالمة إلى jalero.space، ولكن عند إدخال اسمك وتحديد اتصال "مشترك"، يتم عرض التحذير غير قادر على الاتصال - المحاولة مرة أخرى لاحقا فورا:

الحل:

تحقق من قدرة CMS، على الشبكة الداخلية، على حل سجل _xmpp-client SRV دائما لمجال CB.

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

• دليل إستخدام منفذ VCS/Expressway IP
• الدعم التقني والمستندات - Cisco Systems