تمكين ActiveControl على MRA/Expressway

المقدمة

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

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

المتطلبات

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

• Expressway (مكالمات MRA و B2B)

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

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

• Expressway X12.5
• Cisco Meeting Server (CMS) 2.9
• Cisco Unified Communications Manager 12.5

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

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

في هذا المستند، يكون التركيز الرئيسي على اتصال عميل MRA بخادم إجتماعات Cisco (CMS) ولكن ينطبق الأمر نفسه على النوع الآخر من الأنظمة الأساسية أو الاتصالات مثل الاتصال باجتماعات Webex على سبيل المثال. يمكن تطبيق نفس المنطق على النوع التالي من تدفقات الاستدعاءات:

• نقطة النهاية - CUCM - Expressway-C - Expressway-E - إجتماع Webex
• نقطة نهاية MRA - (Expressway-E - Expressway-C) - CUCM - Expressway-C - Expressway-E - إجتماع Webex

ملاحظة: تختلف ميزات ActiveControl التي تدعمها WebEx Meetings عن تلك الخاصة ب CMS في هذه اللحظة من حيث الوقت، وهي عبارة عن مجموعة فرعية محدودة فقط.

يوفر النظام الأساسي لخادم الاجتماعات من Cisco للمشاركين في الاجتماع إمكانية التحكم في تجربة الاجتماعات الخاصة بهم مباشرة من نقطة نهاية المؤتمرات الخاصة بهم من خلال ActiveControl دون الحاجة إلى تطبيقات أو مشغلات خارجية. يستخدم ActiveControl بروتوكول الوسائط iX في أجهزة Cisco ويتم التفاوض عليه كجزء من رسائل SIP الخاصة بمكالمة. اعتبارا من CMS الإصدار 2.5، الميزات الرئيسية الممكنة هي الميزات التالية (على الرغم من أنها يمكن أن تعتمد على نوع نقطة النهاية وإصدار البرنامج المستخدم):

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

في الصورة الأولى، ترى طريقة عرض مستخدم من عميل Jabber الذي قام بوضع إستدعاء في مساحة CMS بدون ActiveControl بينما تظهر الصورة الثانية لك طريقة عرض مستخدم غنية بالميزات أكثر حيث تمكن Jabber من التفاوض حول ActiveControl مع خادم CMS.

ActiveControl هو بروتوكول يستند إلى XML يتم نقله باستخدام بروتوكول iX الذي يتم التفاوض عليه في مكالمات بروتوكول وصف الجلسة (SDP) لبروتوكول بدء جلسة العمل (SIP). إنه بروتوكول Cisco (بروتوكول التحكم في المؤتمرات القابل للتوسيع (XCCP)) وتم التفاوض عليه في SIP فقط (حتى أن المكالمات المتشابكة لا تحتوي على ActiveControl) وتستفيد من UDP/UDT (بروتوكول نقل البيانات المستند إلى UDP) لنقل البيانات. يتم إجراء التفاوض الآمن من خلال TLS لمخطط البيانات (DTLS) الذي يمكن النظر إليه على أنه TLS عبر اتصال UDP. يتم عرض بعض العينات هنا للفروق في التفاوض.

غير مشفر

m=application xxxxx UDP/UDT/IX *
a=ixmap:11 xccp

مشفر (أفضل جهد - حاول التشفير ولكن اسمح بإجراء اتصال غير مشفر)

m=application xxxx UDP/UDT/IX *

a=ixmap:2 xccp

a=بصمة الإصبع:sha-1 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx: xx: xx: xx: xx:

مشفر (فرض التشفير - لا تسمح بإجراء اتصال إحتياطي غير مشفر)

m=application xxxx udp/DTLS/UDT/IX *

a=ixmap:2 xccp

a=بصمة الإصبع:sha-1 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx: xx: xx: xx: xx:

هناك بعض الحد الأدنى من إصدارات البرامج المطلوبة لدعم ActiveControl الكامل كما هو مدرج:

• Jabber الإصدار 12.5 أو إصدار أحدث (ملاحظات الإصدار)
• نقاط نهاية CE 8.3 أو إصدار أحدث، الإصدار 9.6.2 أو إصدار أحدث موصى به وفقا لدليل التحكم النشط من CMS (CE9.3.1 أو إصدار أحدث ل Webex وفقا لارتباط تعليمات Webex)
• CUCM 10.5 أو إصدار أحدث (لدعم Jabber 12.5 ActiveControl) (11.5(1) أو إصدار أحدث ل Webex وفقا للارتباط)
• CMS 2.1 أو إصدار أحدث، 2.5 أو إصدار أحدث موصى به وفقا لدليل CMS ActiveControl
• Expressway X12.5 أو إصدار أحدث (ملاحظات الإصدار) للسماح بدعم عملاء MRA غير المشفرة

هناك عدد قليل من خيارات التكوين التي يجب أخذها في الاعتبار:

• في CUCM تأكد من تكوين خطوط اتصال SIP ذات الصلة (إلى Expressway-C و CMS) باستخدام ملف تعريف SIP الذي تم التحقق من "السماح بوسائط تطبيق iX"
  
  
• في CMS هو مكنت افتراضيا من 2،1 فصاعدا، غير أن أنت يستطيع أعجزت هو عن طريق إنسجامProfile على أي أنت يستطيع ثبتت sipUDT إلى خطأ
• في Expressway على تكوين المنطقة ضمن الإعدادات المتقدمة (عند إستخدام ملف تعريف منطقة 'مخصصة')، تأكد من تعيين وضع عامل تصفية SIP UDP/IX على 'إيقاف' إذا كنت تريد السماح ل iX بالتمرير
  

المشكلة

معلومات عامة

يتم التفاوض على ActiveControl بشكل آمن بشكل مختلف عن قنوات الوسائط الأخرى. بالنسبة لقنوات الوسائط الأخرى مثل الصوت والفيديو على سبيل المثال، يتم إلحاق SDP بخطوط التشفير التي يتم إستخدامها للإعلان للجهة البعيدة عن مفتاح التشفير الذي يتم إستخدامه لهذه القناة. وبالتالي يمكن جعل قناة بروتوكول نقل الوقت الفعلي (RTP) آمنة وبالتالي تعتبر كبروتوكول RTP آمن (SRTP). بالنسبة لقناة iX، فإنها تستخدم بروتوكول DTLS لتشفير تدفق وسائط XCCP لذلك هو يستخدم آلية مختلفة.

لا يقوم برنامج Expressway بإنهاء بروتوكول DTLS. ويشار إلى ذلك ضمن قسم المحددات ضمن وظائف غير مدعومة في ملاحظات إصدار Expressway. 

إصدارات Expressway قبل X12.5

عند تشغيل إصدار Expressway قبل X12.5، إذا كان هناك اتصال قادم بقناة iX مشفرة يتم تمريره على طول منطقة TCP غير آمنة، فإن Expressway يقوم بتشريد كل من خطوط التشفير لقنوات الوسائط العادية بالإضافة إلى قناة iX بالكامل. ويتم عرض هذا بصريا لعميل MRA الذي يتصل بمساحة CMS حيث ترى أن الاتصال آمن من عميل MRA إلى Expressway-C ولكن بعد ذلك اعتمادا على ملف تعريف أمان الهاتف الذي تم إعداده على CUCM للجهاز، إما أنه غير مشفر (ويتم إرساله عبر منطقة CEtcp) أو مشفر (ويتم إرساله عبر منطقة CEtls). عندما يكون غير مشفر كما هو موضح في الصورة، ترى أن Expressway-C ينفصل عن خطوط التشفير لجميع قنوات الوسائط وحتى ينفصل عن قناة وسائط iX بالكامل لأنه لا يمكنه إنهاء بروتوكول DTLS. يحدث هذا عبر وكيل المستخدم من الخلف إلى الخلف (B2BUA) لأن تكوين المنطقة لمنطقة CEtcp تم إعداده باستخدام تشفير الوسائط "فرض غير مشفر". في الإتجاه المعاكس (عبر منطقة مرور الاتصالات الموحدة مع تشفير الوسائط "مشفر بالقوة") عند تلقي رد بروتوكول SDP، فإنها تضيف خطوط التشفير لخطوط الوسائط العادية والأصفار خارج المنفذ لقناة iX مما يؤدي إلى عدم تفاوض ActiveControl. داخليا عندما يكون العملاء مسجلون مباشرة إلى CUCM، فإنها تسمح بكل من قنوات الوسائط iX المشفرة وغير المشفرة حيث أن CUCM لا يضع نفسه في مسار الوسائط.

وينطبق نفس النوع من المنطق على إتصالات المكالمات عبر Expressway إلى إجتماعات Webex. ويتطلب ذلك أن يكون المسار الكامل في نهاية آمن نظرا لأن خوادم Expressway (قبل X12.5) تمر فقط عبر معلومات اتصال DTLS ولكن لا تنهي الأمر بنفسها لبدء جلسة جديدة أو لتشفير/فك تشفير قناة الوسائط على أقدام الاتصال المختلفة.

إصدارات Expressway من X12.5 والإصدارات الأحدث

عند تشغيل إصدار Expressway من X12.5 أو إصدار أعلى، تغير السلوك كما هو الآن يمر عبر قناة iX عبر اتصال منطقة TCP كتشفير إجباري (UDP/DTLS/UDT/IX) للسماح بالتفاوض باستمرار حول قناة iX ولكن فقط عندما يستخدم الطرف البعيد التشفير أيضا. وهو يفرض التشفير لأن Expressway لا ينهي جلسة DTLS وبالتالي يعمل فقط على المرور بحيث يعتمد على الطرف البعيد لبدء/إنهاء جلسة DTLS بعد ذلك. يتم إسقاط خطوط التشفير عبر اتصال TCP لأغراض الأمان. يتم تغطية هذا التغيير في السلوك في ملاحظات الإصدار وفقا للقسم 'MRA: دعم iX المشفر (ل ActiveControl). وما يحدث بعد ذلك، يعتمد على إصدار CUCM حيث تغير السلوك في 12.5(1)SU1 حيث يسمح بالمرور عبر قناة iX وكذلك على الاتصالات الواردة غير الآمنة. حتى عند وجود خط اتصال TLS SIP آمن إلى CMS، عند تشغيل إصدار CUCM أقل من 12.5(1)SU1، فإنه ينزع قناة iX قبل تمريرها إلى CMS مما يؤدي في نهاية المطاف إلى منفذ خروج أصفر من CUCM إلى Expressway-C.

من خلال إرسال إشارات المكالمات الآمنة الطرفية ومسار الوسائط، يمكن التفاوض على قناة iX مباشرة (عبر نقلات مختلفة من خوادم Expressway) بين العميل (MRA) وحل المؤتمرات (CMS أو إجتماع Webex). تظهر الصورة نفس تدفق المكالمات لعميل MRA المتصل بمساحة CMS ولكن الآن باستخدام ملف تعريف أمان هاتف آمن تم تكوينه على CUCM وشنطة SIP آمنة ل TLS إلى CMS. يمكنك أن ترى أن المسار نهاية إلى نهاية آمن وأن معلمة بصمة الإصبع DTLS قد تم تمريرها عبر المسار بأكمله.

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

لا يتم دائما تمرير خطوط SIP الآمنة ل TLS إلى خادم (خوادم) CMS لأن CUCM (بافتراض أن خط اتصال SIP به خيار SRTP الذي تم تمكينه) من اتصال SIP آمن قادم وقناة iX بالإضافة إلى خطوط التشفير ولكن CMS يرد فقط مع التشفير إلى قناة iX (السماح ل ActiveControl) (بافتراض أن تشفير وسائط SIP تم تعيينه على مسموح به أو فرضه على CMS ضمن إعدادات > إعداداتالاستدعاء) ولكن ليس لديه تشفير على قنوات الوسائط الأخرى عند إيقاف تشغيله خطوط التشفير منهم طبقا للصورة. يمكن لخوادم Expressway الإضافة في خطوط التشفير مرة أخرى لتأمين هذا الجزء من الاتصال لا يزال مستمرا (ويتم التفاوض على iX مباشرة بين العملاء النهائيين الذين لا يزالون عبر DTLS) ولكن هذا ليس مثاليا من وجهة نظر أمنية، وبالتالي يوصى بإنشاء خط اتصال SIP آمن إلى جسر المؤتمر. عندما لا يتم التحقق من SRTP Allowed على خط اتصال SIP، يقوم CUCM بشطب خطوط التشفير ويفشل تفاوض iX الآمن كذلك.

الحل

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

1. توصيفات أمان الهاتف الآمنة لنقاط النهاية (الوضع المختلط CUCM)
2. SIP OAuth ل Jabber
3. قناة iX مشفرة لتوصيفات أمان الهاتف غير الآمنة (CUCM 12.5(1)SU1 أو أعلى)
   
   

الحل 1: تأمين ملفات تعريف أمان الهاتف لنقاط النهاية (الوضع المختلط CUCM)

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

• CUCM في الوضع المختلط

Pro:

• يعمل على أي إصدار من CUCM
• يعمل لجميع أجهزة العميل

كون:

• يتطلب تكوين CUCM في الوضع المختلط (وعمليات CAPF على نقاط النهاية المسبقة)

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

بالنسبة لعملاء MRA، لا توجد عملية CAPF مطلوبة ولكن تأكد من اتباع خطوات التكوين الإضافية باستخدام ملف تعريف أمان الهاتف الآمن مع اسم يطابق أحد الأسماء البديلة لموضوع شهادة خادم Expressway-C كما هو مبرز في مثال تكوين نقاط النهاية المستندة إلى TC ل Collaboration Edge (والذي ينطبق أيضا على نقاط النهاية المستندة إلى CE وعملاء Jabber).

عند الاتصال من نقطة نهاية on-prem أو عميل Jabber إلى إجتماع Webex، تحتاج إلى إجراء عملية CAPF لتسجيل العميل بشكل آمن إلى CUCM. وهذا مطلوب لضمان تدفق المكالمات الآمنة من نهاية إلى نهاية حيث يمكن أن يمر Expressway عبر تفاوض DTLS ولا يعالج نفسه.

من أجل تأمين الاتصال من نهاية إلى نهاية، تأكد أيضا من أن جميع خطوط اتصال SIP ذات الصلة (إلى Expressway-C في حالة الاتصال باجتماع Webex و CMS في حالة الاتصال بمؤتمر CMS) آمنة من خطوط اتصال SIP باستخدام TLS مع ملف تعريف أمان خط اتصال SIP آمن.

الحل 2: SIP OAuth ل Jabber

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

• Cisco Jabber 12.5 أو أعلى (ملاحظات الإصدار)
• CUCM الإصدار 12.5 أو إصدار أعلى (ملاحظات الإصدار) مع تمكين تدفق تسجيل الدخول مع التحديث
• Expressway X12.5.1 أو أعلى (ملاحظات الإصدار) مع التخويل بواسطة الرمز المميز OAuth مع تمكين التحديث

Pro:

• يسمح بالتسجيل الآمن والتبديل السهل بين وضع الاستعداد وإيقاف التشغيل دون الحاجة إلى تجديد CAPF في كل مرة
• لا حاجة لإعداد CUCM في الوضع المختلط

كون:

• ينطبق فقط على Jabber، ولا ينطبق على نقاط النهاية ل TC/CE

يتيح لك وضع SIP OAuth إستخدام رموز تحديث OAuth المميزة لمصادقة Cisco Jabber في البيئات الآمنة. وهو يسمح بتأمين إرسال الإشارات والوسائط دون متطلبات CAPF من الحل 1. يتم إكمال التحقق من صحة الرمز المميز أثناء تسجيل SIP عند تمكين التخويل المستند إلى OAuth على مجموعة CUCM ونقاط النهاية Jabber.

يتم توثيق التكوين على CUCM في دليل تكوين الميزة ويتطلب أن يكون لديك OAuth مع تدفق تسجيل الدخول إلى التحديث بموجب معلمات المؤسسة التي تم تمكينها بالفعل. لتمكين هذا أيضا عبر MRA، تأكد من تحديث عقد CUCM في خادم Expressway-C تحت التكوين > الاتصال الموحد > خوادم CM الموحدة حتى يمكنك تحت التكوين > مناطق > مناطق أن ترى الآن مناطق CEOAuth التي تم إنشاؤها تلقائيا. تأكد أيضا من أنه تحت التكوين > الاتصال الموحد > التكوين الذي يتم تخويله بواسطة رمز OAuth المميز مع التحديث تم تمكينه أيضا.

باستخدام هذا التكوين، يمكنك تحقيق اتصال اتصال مكالمات آمن مماثل من نهاية إلى نهاية لكل من الإشارات والوسائط وبالتالي فإن Expressway يمر فقط عبر تفاوض DTLS لأنه لا ينهي حركة المرور نفسها. ويلاحظ ذلك في الصورة التي يكون الاختلاف الوحيد بالمقارنة بالحل السابق فيها هو أنها تستخدم منطقة CEOTH على Expressway-C إلى CUCM في مقابل منطقة CEls لأنها تستخدم SIP OAuth بدلا من تسجيل الجهاز الآمن عبر TLS عندما يعمل CUCM في وضع مختلط مع ملف تعريف أمان هاتف آمن ولكن بعيدا عن ذلك، يظل الكل كما هو.

الحل 3: قناة iX المشفرة لتوصيفات أمان الهاتف غير الآمنة (CUCM 12.5(1)SU1 أو أعلى)

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

• CUCM الإصدار 12.5(1)SU1 أو إصدار أعلى (ملاحظات الإصدار)
• Expressway X12.5.1 أو أعلى (ملاحظات الإصدار)

Pro:

• لا حاجة لإعداد CUCM في الوضع المختلط
• لا حاجة لإعداد إتصالات شاملة آمنة
• قابلة للتطبيق على كل من نقاط النهاية لكل من Jabber و TC/CE

كون:

• ترقية CUCM المطلوبة
• الإصدارات المقيدة ل CUCM فقط هي المعتمدة

من CUCM 12.5(1)SU1، فإنه يدعم تفاوض تشفير iX لأي جهاز خط SIP حتى يمكنه التفاوض على معلومات DTLS في رسائل ActiveControl الآمنة لنقاط النهاية أو الهواتف البرمجية غير الآمنة. وهو يرسل عبر أفضل جهد تشفير iX عبر TCP مما يسمح للهواتف بأن تنتهي قناة iX مشفرة رغم اتصال TCP غير الآمن (وليس TLS) إلى CUCM.

في دليل الأمان ل CUCM 12.5(1)SU1 ضمن قسم "قناة iX المشفرة"، يظهر ذلك أنه بالنسبة للأوضاع غير المشفرة باستخدام أجهزة غير آمنة، يمكن التفاوض حول أفضل الجهود والتشفير الإجباري ل iX مع الشرط الأساسي أن يلتزم نظامك بالتوافق مع التصدير وأن خط اتصال SIP إلى جسر المؤتمر الخاص بك آمن.

في CUCM:

• يجب أن تستخدم CUCM المقيد للتصدير (ليس غير مقيد)
• بموجب النظام > الترخيص > إدارة الترخيص، يجب تعيين "الوظائف التي يتم التحكم فيها بواسطة التصدير" على المسموح بها.
• يجب أن يكون لدى خط اتصال SIP الخاص بك الخيار SRTP Allowed" ممكن (بغض النظر عما إذا كان خط الاتصال نفسه آمنا أو غير آمن)

على CMS:

• يجب أن يكون لدى CallBridge لديك ترخيص بتشفير (وبالتالي ليس لديك ترخيص CallBridgeNoEncryption)
• في WebAdmin تحت التكوين > إعدادات الاتصال، يجب أن تكون قد قمت بتعيين تشفير وسائط SIP إلى مسموح به (أو مطلوب)

في الصورة، يمكنك أن ترى أن الاتصال آمن حتى يرسل Expressway-C ثم C عبر SDP إلى CUCM بدون خطوط التشفير ولكنه لا يتضمن قناة وسائط iX بعد. لذلك فإن الوسائط العادية للصوت/الفيديو/... غير مؤمنة بخطوط التشفير ولكن لديها اتصال آمن لقناة وسائط iX الآن بحيث لا يحتاج Expressway إلى إنهاء اتصال DTLS. وبالتالي، يمكن التفاوض حول ActiveControl بين العميل وجسر المؤتمرات مباشرة، حتى مع ملف تعريف أمان هاتف غير آمن. في الإصدارات السابقة من CUCM، سيكون التدفق مختلفا، ولن يتم التفاوض على ActiveControl لأنه لا يمر عبر قناة iX إلى CMS في المقام الأول حيث أنه قد تم سحب ذلك الجزء بالفعل.