تكوين وصول الضيف والمضيف واستكشاف أخطائه وإصلاحها على مساحات CMS

المقدمة

يصف هذا المستند كيفية إعداد وصول الضيف والمضيف على مساحات خادم الاجتماعات (CMS) من Cisco باستخدام أوامر API.

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

المتطلبات

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

• خادم الاجتماعات (CMS) من Cisco المزود بمساحات تم إعدادها وقادر على إجراء مكالمات إليه
• عميل واجهة برمجة التطبيقات (مثل ملصق، ساعي البريد) أو 
• دليل واجهة برمجة التطبيقات CMS

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

تستند المعلومات الواردة في هذا المستند إلى الإصدار 2.1 من CMS

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

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

يحدد المستند أنواع السيناريوهات:

• يتم إستخدام عناوين URI أو معرفات المكالمات المختلفة من قبل المشاركين الضيوف والمضيفين
• يتم إستخدام URI نفسه من قبل المشاركين الضيوف والمضيفين حيث يتم إجراء التفرقة بناء على إدخال PIN أو رمز المرور (كلاهما غير فارغ)
• يتم إستخدام URI نفسه من قبل الضيوف والمضيفين المشاركين حيث يتم إجراء التفرقة بناء على إدخال PIN أو رمز المرور (خليط من فارغ/غير فارغ)
• يعد المستخدم المضيف عضوا في المساحة ومرخصا له عبر تسجيل الدخول إلى WebRTC، وينضم المستخدمون الضيوف إلى الاجتماع باستخدام معرف المكالمة. يتم إستخدام URI و CallID نفسه من قبل الضيوف والمضيفين المشاركين مع PIN/رموز المرور الفارغة أو غير الفارغة للمستخدمين الضيوف

التكوين

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

أولا، يتم شرح الطريقة باستخدام URI مختلف (أو معرف الاستدعاء) للضيوف والمضيفين المشاركين، وبعد ذلك يتم إلحاق ذلك باستخدام رموز مرور مختلفة (أو مهلة) على نفس URI، للتمييز بين الضيوف والمضيفين المشاركين. تم إدخال الطريقة الثالثة لإدخال PIN الفارغ أو المهلة الخاصة بالمستخدمين الضيوف كميزة جديدة على CMS 2.1 كما هو موضح في القسم 2.4 من ملاحظات الإصدار. توضح الطريقة الرابعة كيفية إعداد وصول الضيف والمضيف على المساحات مع المالك/الأعضاء المعينين وجعل عضو المساحة (المالك) مضيف المساحة.

1) التكوين باستخدام عناوين URI مختلفة

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

1. إنشاء CallLegProfile ضيف (needsActivation = true)
2. إنشاء CallLegProfile للمضيف (needsActivation = false)
3. تعيين CallLegProfile للضيف إلى مساحة موجودة أو جديدة (تكون طريقة الوصول الافتراضية)
4. قم بإنشاء أسلوب وصول جديد على نفس المساحة باستخدام URI (و call-ID) مختلف وتعيين المضيف callLegProfile إليه

الخطوة 1. إنشاء CallLegProfile ضيف (needsActivation = true). 

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

ملاحظة: يمكنك أيضا تعيين هذا على مستوى المستأجر (/API/V1/المستأجرين/<Tenant-ID) أو مستوى النظام (API/V1/system/profile) لتطبيق هذا على جميع المساحات (أو لكل مستأجر)، ومع ذلك يظهر هنا على المساحة نفسها. ضع في الاعتبار أن التخصيص الأكثر تحديدا ل CallLegProfile يؤخذ في الاعتبار لسلوك الاستدعاء.

المعلمة needsActivation هي المعلمة الأكثر أهمية هنا لسلوك الضيف/المضيف لأنه إذا تم تعيينها إلى true، فلن يتمكن المشارك من تلقي الصوت والفيديو أو الإسهام بهما حتى ينضم واحد أو أكثر من كامل/منشط (مضيف) المشاركين. يمكن العثور على معلمات أخرى على CallLegProfile في القسم 8.4.3 من دليل واجهة برمجة التطبيقات (API)، والتي يمكن أن تكون فيها الواجهات المعروضة ذات صلة في هذا الإعداد أيضا (وفقا لمتطلباتك):

• PresentationContributionAllowed
• RXaudioMute
• rxVideoMute
• وضع إلغاء التنشيط (معطل | قطع الاتصال | REMAINactivated) و DEACTIVATIONmodeTime [الإجراء الذي سيتم تنفيذه عند ترك آخر منشط للاستدعاء]

لإنشاء CallLegProfile الضيف، قم بإجراء طلب POST على /api/v1/callLegProfile مع تعيين المعلمات والاحتياجات المفضلة إلى true بحيث يمكنك تنفيذ طلب GET على ذلك الاستدعاءLegProfile-ID بعد ذلك مع هذه النتيجة على سبيل المثال:

     
     
     
     
       < 
      needsActivation>true 
      needsActivation> 
      
        speakerOnly 
       
      
        false 
       
      
        true 
       
      
        false 
      < 
      deactivationMode>deactivate 
      deactivationMode> 
     

لاحظ أسفل CallLegProfile-ID كما هو موضح بالأسود حيث يجب تطبيق هذا على المساحة في الخطوة 3 للوصول الافتراضي للضيف.

الخطوة 2. قم بإنشاء CallLegProfile للمضيف (needsActivation = false).

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

يمكنك إنشاؤها بواسطة طلب POST على /api/v1/callLegProfile مع تعيين المعلمات والاحتياجات المفضلة إلى false بحيث يمكنك تنفيذ طلب GET على ذلك الاستدعاءLegProfile-ID بعد ذلك مع هذه النتيجة على سبيل المثال:

     
     
     
     
       < 
      needsActivation> 
      false 
      needsActivation> 
      
        speakerOnly 
       
      
        true 
       
      
        false 
       
      
        false 
       
     

لاحظ أسفل CallLegProfile-ID كما هو موضح بالأسود حيث يجب تطبيق هذا على AccessMethod في الخطوة 4 للوصول إلى المضيف.

الخطوة 3. قم بتعيين CallLegProfile للضيف إلى مساحة موجودة أو جديدة (تكون أسلوب الوصولMethod الافتراضي).

قم بتنفيذ أمر PUT على مساحة موجودة (/API/V1/coSpaces/<coSpace-ID) لتكييف المساحة أو أمر POST على /API/v1/coSpaces لإنشاء أمر جديد باستخدام المعلمة callLegProfile التي تم إنشاؤها في الخطوة 1 كسلوك الاستدعاء لتلك المساحة. يمكنك أيضا تعيين معلمات URI ورمز المرور وCall-ID لتلك المساحة بالإضافة إلى رغبتك وفقا للقسم 6.2 من دليل API.

قم بإجراء طلب GET على تلك المساحة (/API/V1/coSpaces/<coSpace-ID>) للتحقق من اقتران CallLegProfile للضيف به، بالإضافة إلى قيمة URI وCall-ID. أحد الأمثلة التي تم إنشاؤها بواسطة هذا المثال callLegProfile الضيف في الخطوة 1 هو هذا الذي يحتوي على قيمة URI من guest.space وcall-id لعام 628821815 (لم يتم تعيين رمز المرور):

     
     
     
      
      
        Guest.space 
       
      
        true 
      < 
      uri>guest.space 
      uri>< 
      callId>628821815 
      callId>< 
      callLegProfile> 
      d4bfe12d-68cd-41c0-a671-48395ee170ab 
      callLegProfile> 
      
        bc392aaa-8c6d-4619-ad2f-cb30c4c53766 
       
      
        Guest@cms.steven.lab 
       
      
        iWqZQ.tTMIleeQHKMB.JYg 
       
      
        1 
       
     

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

الخطوة 4. قم بإنشاء أسلوب وصول جديد على تلك المساحة باستخدام URI (وcall-ID) مختلف وتخصيص المضيف callLegProfile له.

تريد إنشاء طريقة مختلفة للوصول إلى المساحة عن طريقة وصول الضيف التي هي حاليا الطريقة الافتراضية. ويتم تحقيق ذلك من خلال تحديد أسلوب وصول على المساحة نفسها بواسطة أمر POST على /api/v1/coSpaces/<coSpace-ID>/accessMethods مع إستخدام معرف CoSpace-ID كقيمة ذات علامة جريئة في الخطوة 3 (7cc797c9-c0a8-47cf-b519-8dc5a01f1ade) التي يتم تطبيقعليها HostLegProfile للخطوة 2 بالإضافة إلى حقل إستدعاءID مختلف.

بعد طلب GET على Space AccessMethod (/api/v1/coSpaces/<coSpace-ID>/accessMethods/<accessMethod-ID)، يجب أن تكون قادرا على رؤية نوع مماثل من الإخراج على هذا النحو، حيث يمكنك رؤية URI مختلف (host.space) وcall-id (888) بدلا من AccessMethod الافتراضي للمساحة بالإضافة إلى إستدعاء LegProfile المقترن بشكل خاص على الخطوة 2:

     
     
     
     
       < 
      uri>host.space 
      uri>< 
      callId>888 
      callId>< 
      passcode> 
      passcode>< 
      callLegProfile> 
      7306d2c1-bc15-4dbf-ab4a-1cbdaabd1912 
      callLegProfile> 
      
        r8.QXRrOMFp719gDL5ck6Q 
       
     

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

الآن يمكنك الاتصال بنفس الاجتماع:

• كضيف

        - عن طريق الاتصال ب Guest.Space URI (يتبعه المجال كما تم تكوينه في قواعد مطابقة المكالمات)

        - من خلال إدخال قيمة معرف المكالمة 628821815 عبر IVR أو الانضمام إلى WebRTC (لا يوجد رمز مرور)

• كمضيف

         - من خلال الاتصال ب URI الخاص بالمجال host.space (متبوعا بالمجال كما تم تكوينه في قواعد مطابقة المكالمات)

         - من خلال إدخال قيمة معرف المكالمة 888 عبر IVR أو الانضمام إلى WebRTC (لا يوجد رمز مرور)

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

2) التكوين باستخدام نفس معرفات فئات URI ولكن ليس بدون زائرين ورموز PIN/كلمات مرور للمضيف

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

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

1. إنشاء CallLegProfile ضيف (needsActivation = true)
2. إنشاء CallLegProfile للمضيف (needsActivation = false)
3. تعيين CallLegProfile للضيف إلى مساحة موجودة أو جديدة تحدد رمز مرور الضيف (PIN) (كطريقة الوصول الافتراضية)
4. قم بإنشاء أسلوب وصول جديد على نفس المساحة مع نفس URI (معرف اتصال مختلف) وعينت المضيف callLegProfile إليه متضمنا رمز مرور المضيف (PIN)

الخطوة 1. إنشاء CallLegProfile ضيف (needsActivation = true). 

يمكن إستخدام نفس التكوين كما هو الحال في المثال السابق 1 وحتى نفس إستدعاء LegProfile للضيف (d4bfe12d-68cd-41c0-a671-48395ee170ab) كما هو موضح.

الخطوة 2. إنشاء CallLegProfile للمضيف (needsActivation = false)

يمكن إستخدام نفس التكوين مثل المثال السابق 1 وحتى المضيف نفسه callLegProfile (7306d2c1-bc15-4dbf-ab4a-1cbdaabd1912) كما هو موضح.

الخطوة 3. قم بتعيين CallLegProfile للضيف إلى مساحة موجودة أو جديدة تحدد رمز مرور الضيف (PIN) (نظرا لأنه أسلوب الوصول الافتراضي).

بالمثل كما كان الحال من قبل، يمكنك تنفيذ عملية PUT على مساحة موجودة (/api/v1/coSpaces/<cospace-id>) أو عملية POST لإنشاء مساحة جديدة (/api/v1/coSpaces) مع المعلمات المطلوبة ل URI ورمز المرور ومعرف المكالمة على سبيل المثال بالإضافة إلى إستدعاء الضيف LegProfile (من الخطوة 1) التي قمت بتعيينها له وفقا للقسم 6.2 من دليل API.

إذا قمت بتنفيذ طلب GET على تلك المساحة، فيجب أن تكون قادرا على رؤية نوع إخراج مماثل لهذا حيث ترى معرف معلومات URI الخاص ب guestpin.space، ومعرف اتصال خاص ب 189، وضيفنا الذي تم إنشاؤه مسبقا callLegProfile ورمز مرور ل 789:

     
     
     
      
      
        Guest/Host PIN 
       
      
        false 
      < 
      uri>guestpin.space 
      uri>< 
      callId>189 
      callId>< 
      callLegProfile> 
      d4bfe12d-68cd-41c0-a671-48395ee170ab 
      callLegProfile>< 
      passcode>789 
      passcode> 
      
        X7f83UX7PHcIYp0JbT0fUA 
       
      
        1 
       
     

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

  

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

وفي هذه المساحة، يمكنك أيضا إنشاء طريقة وصول مختلفة للمضيفين (حيث يتم تعيين إستدعاء LegProfile للضيف على المساحة نفسها كخيار الانضمام الافتراضي)، تماما مثل مثال التكوين الأول. ويتم القيام بذلك باستخدام أمر POST على /api/v1/coSpaces/<coSpace-ID>/accessMethods مع قيمة coSpace-ID لمساحتنا وهي 22d9f4ca-8b88-4d11-bba9-e2a2f7428c46 كما هو موضح في الخطوة السابقة. في أمر POST هذا، يمكنك توفير المعلمات المختلفة مثل URI (guestpin.space، وهو نفسه المعرف الأصلي)، و call-id (889)، وcallLegProfile المضيف كما هو محدد في الخطوة 2 ورمز مرور المضيف أو PIN (1234 في هذه الحالة).

إذا قمت بتنفيذ طلب GET على طريقة الوصول هذه، فيجب أن تكون قادرا على رؤية نوع مماثل من المخرجات التي تعرض URI نفسه ل guestpin.space، وcall-id لعام 889، والمضيف callLegProfile والمضيف PIN ل 1234:

     
     
     
     
       < 
      uri>guestpin.space 
      uri>< 
      callId>889 
      callId>< 
      passcode>1234 
      passcode>< 
      callLegProfile> 
      7306d2c1-bc15-4dbf-ab4a-1cbdaabd1912 
      callLegProfile> 
      
        c0wnqI1qB9JGRdmekHEO1w 
       
     

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

الآن يمكنك الاتصال بنفس الاجتماع:

• كضيف

           - من خلال الاتصال ب Guestpin.Space URI (متبوعا بالمجال كما تم تكوينه في قواعد مطابقة المكالمات) وإدخال PIN 789

           - من خلال إدخال قيمة معرف المكالمة 189 عبر IVR أو WebRTC مع PIN 789

• كمضيف

           - من خلال الاتصال ب Guestpin.Space URI (متبوعا بالمجال كما تم تكوينه في قواعد مطابقة المكالمات) وإدخال PIN 1234

           - من خلال إدخال قيمة معرف المكالمة 889 عبر IVR أو WebRTC مع PIN 1234

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

3) التكوين باستخدام نفس عناوين URI مع مزيج من رقم PIN للضيف الفارغ ورقم PIN للمضيف غير الفارغ

يتوفر هذا التكوين فقط بدءا من الإصدار 2.1 من CMS وما بعده بسبب بعض أوامر API التي تمت إضافتها حديثا من وضع رمز المرور ومهلة الرمز المرور على قسم callProfile. وهذا يسمح لرقم التعريف الشخصي (PIN) الفارغ للضيوف للانضمام (إما إدخال # أو المهلة) بينما يملك المضيف رقم تعريف شخصي (PIN) للوصول إلى المساحة وتنشيطها. يتحكم CallProfile في تجربة الاتصال ل SIP (بما في ذلك Lync) وبالتالي لا ينطبق على عملاء CMA (سواء العملاء السميكون أو WebRTC).

تكون خطوات التكوين مماثلة لخطوات المثال 2، مع إضافة callProfile:

1. إنشاء CallLegProfile ضيف (needsActivation = true)
2. إنشاء CallLegProfile للمضيف (needsActivation = false)
3. قم بإنشاء CallProfile باستخدام PasswordMode وpasswordCodeTimeout للتكوين المطلوب
4. قم بتعيين CallLegProfile وCallProfile للخطوة 3 إلى مساحة موجودة أو جديدة تحدد رمز مرور الضيف (PIN) (نظرا لكونه طريقة الوصول الافتراضية)
5. قم بإنشاء أسلوب وصول جديد على نفس المساحة مع نفس URI (معرف اتصال مختلف) وعينت المضيف callLegProfile إليه متضمنا رمز مرور المضيف (PIN)

بما أن التكوينات متطابقة تماما مع أمثلة التكوين 1 و 2، فإن هناك إشارات إلى تلك التكوينات. في الواقع تم إستخدام نفس المساحة في الاختبار كما في المثال 2، ولكن تمت إضافتها مع CallProfile الآن.

الخطوة 1. إنشاء CallLegProfile ضيف (needsActivation = true).

يمكن إستخدام نفس التكوين مثل المثال السابق 1 وحتى نفس إستدعاء الضيف LegProfile (d4bfe12d-68cd-41c0-a671-48395ee170ab) كما هو موضح.

الخطوة 2. قم بإنشاء CallLegProfile للمضيف (needsActivation = false).

يمكن إستخدام نفس التكوين مثل المثال السابق 1 وحتى نفس إستدعاء المضيف LegProfile (7306d2c1-bc15-4dbf-ab4a-1cbdaabd1912) كما هو موضح.

الخطوة 3. قم بإنشاء CallProfile باستخدام وضع كلمة المرور وpasswordTimeout للتكوين المطلوب.

يمكنك إنشاء CallProfile الذي يحدد تجربة الاتصال في مكالمات SIP (بما في ذلك Lync). هناك عدد قليل من التكوينات الممكنة هنا، مثل السماح بالتسجيل أو التدفق أو الحد الأقصى للمشاركين على سبيل المثال ولكن التركيز هنا على إضافات واجهة برمجة التطبيقات الجديدة من CMS 2.1 المتعلقة بمعالجة رمز المرور. ويمكن العثور على المعلمات الأخرى في القسم 8.2 من دليل واجهة برمجة التطبيقات.

هناك معلمان يحددان سلوك رمز المرور هنا، وهما:

• PasswordCodeMode

            - مطلوب: ينتظر IVR إلى الأبد ليدخل المستخدم رمز PIN أو # لرقم PIN فارغ (للضيوف)

            - المهلة: ينتظر IVR مقدار رمز المرورTimeout من الثواني لكي يدخل المشترك رقم التعريف الشخصي (PIN) وإذا لم يتم إجراء أي إدخال خلال ذلك الوقت، فإنه يفترض إدخال رقم تعريف شخصي (PIN) فارغ (#)

• passwordTimeout: يجب فقط أن يتم تعيينه عند تعيين passwordCodeMode على المهلة ويتحكم في مقدار الوقت قبل ترجمة رمز المرور كواحد فارغ

من أجل إنشاء CallProfile، قم بتنفيذ أمر POST على /api/v1/callProfile (أو PUT on /api/v1/callProfile/<callProfile-id>إذا كنت تريد تعديل ملف تعريف موجود) باستخدام المعلمات المطلوبة ل passwordMode وpasswordTimeout. إذا قمت بتنفيذ أمر GET على ملف تعريف المكالمة المحدد، فيجب أن تحصل على نوع مماثل من النتيجة، على سبيل المثال حيث قمت بإعداد الوضع كمهلة وقيمة المهلة 5 ثوان:

     
     
     
     
       < 
      passcodeMode>timeout 
      passcodeMode>< 
      passcodeTimeout>5 
      passcodeTimeout> 
     

لاحظ أسفل CallProfile-ID كما هو موضح بالخط الغامق حيث يجب إستخدام هذا للتعيين إلى المساحة ليكون سلوك الاستدعاء هذا في الخطوة 4.

الخطوة 4. قم بتعيين CallLegProfile وCallProfile للخطوة 3 إلى مساحة موجودة أو جديدة تحدد رمز مرور الضيف (PIN) (نظرا لكونه طريقة الوصول الافتراضية).

بالمثل كما كان الحال قبل، يمكنك إما القيام بعملية PUT على مساحة موجودة (/api/v1/coSpaces/<cospace-id>) أو عملية POST لإنشاء مساحة جديدة (/api/v1/coSpaces) مع المعلمات المطلوبة ل URI وcall-id على سبيل المثال بالإضافة إلى Guest callLegProfile (من الخطوة 1). الفرق من الأمثلة السابقة هو callProfile من الخطوة 3 وحقيقة أنه لم يتم تعيين رمز مرور له.

إذا قمت بتنفيذ طلب GET على تلك المساحة، فيجب أن تكون قادرا على رؤية نوع مماثل من المخرجات على هذا المثال، حيث ترى URI الخاص ب guestpin.space، وcall-id الخاص ب 189، وcallProfile الذي تم إنشاؤه مسبقاLegProfile وcallProfile كما تم إعداده في الخطوة 3:

     
     
     
      
      
        Guest/Host PIN 
       
      
        false 
      < 
      uri>guestpin.space 
      uri>< 
      callId>189 
      callId>< 
      callLegProfile> 
      d4bfe12d-68cd-41c0-a671-48395ee170ab 
      callLegProfile>< 
      callProfile> 
      4b0eff60-e4aa-4303-8646-a7e800a4eac6 
      callProfile> 
      
        X7f83UX7PHcIYp0JbT0fUA 
       
      
        1 
       
     

لاحظ أسفل معرف المساحة كما تم تمييزه بالأسود حيث يجب إستخدامه لإنشاء AccessMethod على تلك المساحة المحددة في الخطوة 5.

الخطوة 5. قم بإنشاء أسلوب وصول جديد على نفس المساحة مع نفس URI (معرف اتصال مختلف) وعينت المضيف callLegProfile إليه متضمنا رمز مرور المضيف (PIN).

وفي هذه المساحة، يمكنك أيضا إنشاء طريقة وصول مختلفة للمضيفين (حيث يتم تعيين إستدعاء LegProfile للضيف على المساحة نفسها كخيار الانضمام الافتراضي)، تماما مثل مثال التكوين الأول. ويتم القيام بذلك باستخدام أمر POST على /api/v1/coSpaces/<coSpace-ID>/accessMethods حيث يتم إستبدال قيمة coSpace-ID بقيمة المساحة الخاصة بك وهي 22d9f4ca-8b88-4d11-bba9-e2a2f7428c46 كما هو موضح في الخطوة السابقة لهذه الحالة. في هذا الأمر POST، يمكنك توفير معلمات مختلفة مثل URI (guestpin.space، وهو نفس المعرف الأصلي)، وcall-id (889)، وcallLegProfile المضيف كما هو محدد في الخطوة 2 ورمز مرور المضيف أو رمز PIN (1234 في هذه الحالة).

إذا قمت بتنفيذ طلب GET على طريقة الوصول هذه، فيجب أن تكون قادرا على رؤية نوع مماثل من المخرجات التي تعرض URI نفسه ل guestpin.space، وcall-id لعام 889، والمضيف callLegProfile والمضيف PIN ل 1234:

     
     
     
     
       < 
      uri>guestpin.space 
      uri>< 
      callId>889 
      callId>< 
      passcode>1234 
      passcode>< 
      callLegProfile> 
      7306d2c1-bc15-4dbf-ab4a-1cbdaabd1912 
      callLegProfile> 
      
        c0wnqI1qB9JGRdmekHEO1w 
       
     

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

الآن يمكنك الاتصال بنفس الاجتماع:

• كضيف

               - من خلال الاتصال ب Guestpin.Space URI (متبوعا بالمجال كما تم تكوينه في قواعد مطابقة الاستدعاءات) وإدخال # ك PIN أو السماح به المهلة بعد 5 ثوان

               - من خلال إدخال قيمة Call-ID 189 عبر IVR أو WebRTC Join

• كمضيف

               - من خلال الاتصال ب Guestpin.Space URI (متبوعا بالمجال كما تم تكوينه في قواعد مطابقة المكالمات) وإدخال PIN 1234

               - من خلال إدخال قيمة Call-ID 889 عبر IVR أو WebRTC مع PIN 1234

4) المستخدم المضيف هو عضو في المساحة ومرخص له عبر سجل الدخول إلى WebRTC، وينضم المستخدمون الضيوف إلى الاجتماع باستخدام معرف المكالمة. يتم إستخدام URI و CallID نفسه من قبل الضيوف والمضيفين المشاركين مع PIN/رموز المرور الفارغة أو غير الفارغة للمستخدمين الضيوف

يلزم تنفيذ الخطوات التالية للحصول على تفرقة وصول الضيف/المضيف على نفس المساحة للأعضاء وغير الأعضاء في المساحة:

1. إنشاء CallLegProfile ضيف(needsActivation = true)
2. إنشاء مضيف callLegProfile(needsActivation = false)
3. تعيين CallLegProfile للضيف لمساحة موجودة أو جديدة (كطريقة الوصول الافتراضية)
4. قم بإنشاء أسلوب وصول جديد على نفس المساحة مع نفس URI (و call-id) وتخصيص callLegProfile للمضيف إليه
5. تعيين مستخدم'sownerJIDto نفس المساحة. (في حالة عدم التعيين)
6. إضافة OwnerIDas المستخدم العضو إلى نفس المساحة وassignmentCallLegProfileto ذلك المستخدم العضو

الخطوة 1. إنشاء إستدعاء الضيف LegProfile (needsActivation = true). 

يتم إستخدام نفس التكوين كما هو الحال في المثال السابق 1 ونقطة إستدعاء الضيف LegProfile (bfe7d07f-c7cb-4e90-a46e-4811bbaf6978) في هذا المثال.

لاحظ أسفل CallLegProfile-ID كما هو موضح بالأسود حيث يجب تطبيق هذا على المساحة في الخطوة 3 لوصول الضيوف.

الخطوة 2. إنشاء إستدعاء مضيف LegProfile (needsActivation = false)

يتم إستخدام نفس التكوين كالمثال السابق 1 ومضيف إستدعاء LegProfile (0e76e943-6d90-43df-9f23-7f1985a74639) في هذا المثال.

لاحظ أسفل CallLegProfile-ID كما هو موضح بالخط الغامق حيث يجب تطبيق هذا على AccessMethod في الخطوة 4 للوصول إلى المضيف وعلى عضو CoSpace في الخطوة 6.

الخطوة 3. قم بتخصيص CallLegProfile للضيف لمساحة موجودة أو جديدة (نظرا لكونه AccessMethod الافتراضي).

قم بتنفيذ أمر PUT على مساحة موجودة (/API/V1/coSpaces/<coSpace-ID) لتكييف المساحة أو أمر POST على /API/v1/coSpaces لإنشاء أمر جديد باستخدام المعلمة callLegProfile التي تم إنشاؤها في الخطوة 1 كسلوك الاستدعاء لتلك المساحة. يمكنك أيضا تعيين معلمات URI وCall-ID لتلك المساحة بالإضافة إلى رغبتك وفقا للقسم 6.2 من دليل واجهة برمجة التطبيقات.

قم بإجراء طلب GET على تلك المساحة (/API/V1/coSpaces/<coSpace-ID>) للتحقق من اقتران CallLegProfile للضيف به، بالإضافة إلى قيمة URI وCall-ID. أحد مخرجات المثال الذي تم إنشاؤه ضمن CallLegProfile في الخطوة 1 هو هذا ذو قيمة URI للعمومية وcall-id ل 1234 (لم يتم تعيين رمز المرور)، غير MemberAccessset إلىTrue:

<?xml version="1.0" ?>
<coSpace id="96d28acb-86c6-478d-b81a-a37ffb0adafc">
        <name>Global</name>
        <autoGenerated>false</autoGenerated>
        <uri>global</uri>
        <callId>1234</callId>
        <callLegProfile>bfe7d07f-c7cb-4e90-a46e-4811bbaf6978</callLegProfile>
        <nonMemberAccess>true</nonMemberAccess>
        <secret>0w4O2zTTF0WdL4ymF8D0_A</secret>
        <defaultLayout>allEqual</defaultLayout>
</coSpace>

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

الخطوة 4. قم بإنشاء أسلوب وصول جديد على تلك المساحة مع نفس URI (وcall-id) وتعيين المضيف callLegProfile إليه.

تريد إنشاء طريقة مختلفة للوصول إلى المساحة عن طريقة وصول الضيف التي هي حاليا الطريقة الافتراضية. ويتم تحقيق ذلك من خلال تحديد أسلوب وصول على المساحة نفسها بواسطة أمر POSTcommand على /API/V1/coSpaces/<coSpace-ID>/accessMethods مع إستخدام معرف CoSpace-ID كقيمة ذات علامة جريئة في الخطوة 3 (96d28acb-86c6-478d-b81a-a37ffb0adafc) التي يتم فيها تطبيق ملف تعريفCallLegللخطوة 2 من المضيف بالإضافة إلى نفسURI إستدعاء-id. يمكنك إضافة رمز مرور غير فارغ للمضيفين الذين يتصلون عبر CallID (دون تسجيل الدخول كمستخدم عبر WebRTC).

بعد طلب GET على ACCESSmethod (/api/v1/coSpaces/<coSpace-ID>/accessMethods/<accessMethod-ID)، يجب أن تكون قادرا على رؤية نوع إخراج مماثل لهذا النوع، حيث يمكنك رؤية URI نفسه (العمومي) وcall-id (1234) بالإضافة إلى المضيف المرتبط بشكل خاص callLegProfile كما تم إعداده في الخطوة 2 ورمز مرور المضيف(12345):

<?xml version="1.0" ?>
<accessMethod id="c4ecc16e-945f-4e35-ba03-d9b69107b32c">
        <uri>global</uri>
        <callId>1234</callId>
        <passcode>12345</passcode>
        <callLegProfile>0e76e943-6d90-43df-9f23-7f1985a74639</callLegProfile>
        <secret>kffO1zTTE0feL4fsdf43w_B </secret>
</accessMethod>

الخطوة 5. تعيين مالك المستخدم Jidto المساحة. (في حالة عدم التعيين). إضافة OwnerJID إلى المساحة بواسطة SpecificIngownerJid (user1@evacanoalone.net) على المساحة بواسطة أمر PUTon/api/v1/coSpaces/<coSpace-id>

بعد طلب GET على تلك المساحة، يجب أن تكون قادرا على رؤية أنه تم تعيين OwnerIdand OwnerJidhave إلى المساحة:

<?xml version="1.0" ?>
<coSpace id="96d28acb-86c6-478d-b81a-a37ffb0adafc">
        <name>Global</name>
        <autoGenerated>false</autoGenerated>
        <uri>global</uri>
        <callId>1234</callId>
        <callLegProfile>bfe7d07f-c7cb-4e90-a46e-4811bbaf6978</callLegProfile>
        <nonMemberAccess>true</nonMemberAccess>
        <ownerId>1d942281-413e-4a2a-b776-91a674c3a5a9</ownerId>
        <ownerJid>user1@evacanoalone.net</ownerJid>
        <secret>0w4O2zTTF0WdL4ymF8D0_A</secret>
        <numAccessMethods>1</numAccessMethods>
        <defaultLayout>allEqual</defaultLayout>
</coSpace>

لاحظ معرف المالك (1d942281-413e-4a2a-b776-91a674c3a5a9).

الخطوة 6. أضف معرف المالك هذا (1d942281-413e-4a2a-b776-91a674c3a5a9) من الخطوة 5 كمستخدم عضو إلى المساحة وassignCallLegProfileto ذلك المستخدم العضو. ويتم تحقيق ذلك من خلال تحديد JIdandhostCallLegProfileon Space نفسه (specifyingcoSpaceID) بواسطة أمر POSTcommand (/api/v1/coSpaces/<coSpaceID>/coSpaceUsers).يمكن العثور على معلمات أخرى على coSpaceUsers في القسم 6.4.2 من دليل API، والذي يمكن أن تكون فيه المعلمات المعروضة ذات صلة بهذا الإعداد أيضا:

       <canDestroy>true</canDestroy>

        <canAddRemoveMember>true</canAddRemoveMember>

        <canChangeName>true</canChangeName>

        <canChangeUri>false</canChangeUri>

        <canChangeCallId>false</canChangeCallId>

        <canChangePasscode>true</canChangePasscode>

        <canPostMessage>صحيح</canPostMessage>

        <canDeleteAllMessages>false</canDeleteAllMessages>

        <canRemoveSelf>false</canRemoveSelf>

هل تريد تأكيد إضافة المستخدم العضو إلى المساحة بواسطة الأمر aGETcommand (/API/V1/coSpaces/<coSpaceID>/coSpaceUsers؟)

<?xml version="1.0" ?>
<coSpaceUsers total="1">
<coSpaceUser id="1d942281-413e-4a2a-b776-91a674c3a5a9">
<userId>1d942281-413e-4a2a-b776-91a674c3a5a9</userId>
<userJid>user1@evacanoalone.net</userJid>
<autoGenerated>false</autoGenerated>
</coSpaceUser>
</coSpaceUsers>

قم بتدوين معرف المستخدم (إذا كانت الخطوة 5 مختلفة لنموذج OwnerID). تحقق من تعيين CallLegProfilehas إلى CoSpaceUser بواسطة aGETrequest specifyingcoSpaceIDanduserID (/api/v1/coSpaces/<coSpaceID>/coSpaceUsers/<userID>)

<?xml version="1.0" ?>
<coSpaceUser id="1d942281-413e-4a2a-b776-91a674c3a5a9">
        
     
     
       1d942281-413e-4a2a-b776-91a674c3a5a9 
     
        
     
     
       user1@evacanoalone.net 
     
        <autoGenerated>false</autoGenerated>
        <canDestroy>true</canDestroy>
        <canAddRemoveMember>true</canAddRemoveMember>
        <canChangeName>true</canChangeName>
        <canChangeUri>false</canChangeUri>
        <canChangeCallId>false</canChangeCallId>
        <canChangePasscode>true</canChangePasscode>
        <canPostMessage>true</canPostMessage>
        <canDeleteAllMessages>false</canDeleteAllMessages>
        <canRemoveSelf>false</canRemoveSelf>
        <canChangeNonMemberAccessAllowed>true</canChangeNonMemberAccessAllowed>
        
     
     0e76e943-6d90-43df-9f23-7f1985a74639
</coSpaceUser>

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

الآن يمكنك الاتصال بنفس الاجتماع:

• كضيف

        - عن طريق الاتصال ب URI (يتبعه المجال كما تم تكوينه في قواعد مطابقة المكالمات)

        - من خلال إدخال قيمة معرف المكالمة 1234 عبر IVR أو الانضمام إلى WebRTC (بدون رمز مرور)

• كمضيف

           من خلال تسجيل الدخول كمستخدم (عضو في المساحة مع إستدعاء LegProfile المعين ل "المضيف"، مع user1@evacanoalone.net في هذا السيناريو) من خلال WebRTC والانضمام إلى المساحة ( URI "العمومي").

         - من خلال الاتصال ب URI "العمومي" (متبوعا بالمجال كما تم تكوينه في قواعد مطابقة المكالمات) ورمز المرور 12345.

         - من خلال إدخال قيمة معرف المكالمة 1234 عبر IVR أو الانضمام إلى WebRTC (مع رمز مرور المضيف 12345)

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

يمكن للمضيف (المالك/العضو) تعيين (تحرير/إزالة) كلمة مرور للضيوف مباشرة في تطبيق WebRTC أو تعطيل وصول غير العضو (الضيف) بالكامل للمساحة:

  

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

يوفر هذا القسم معلومات يمكنك إستخدامها لاستكشاف أخطاء التكوين وإصلاحها.

يظهر تسجيل CMS بشكل مختصر عندما تنضم كضيف أو عندما ينضم المضيف الأول ولكن من الأفضل التحقق من إستخدام طلبات GET إلى CallProfile وكذلك تعريفات CallLegProfile للضيف والمضيف وتخصيصها على طرق الوصول ذات الصلة (أو طريقة الوصول الافتراضية) أو على مستوى أعلى (المستوى العام أو مستوى المستأجر).

يمكنك اتباع هذا الهيكل للحصول على جميع المعلومات:

1. الحصول على /api/v1/callProfile (إذا كنت تستخدم هذا مع PasswordCodeMode)
   > التحقق بالتفصيل من معرف callProfile المطلوب باستخدام GET on /API/v1/callProfile/<callProfile-id
2. الحصول على ملفات تعريف API/V1/CallLegProfile
   > تحقق بالتفصيل من الاستدعاءات المطلوبة ل LegProfile-IDs للضيف والمضيف باستخدام GET on /API/v1/callProfile/<callProfile-id
3. الحصول على /API/V1/CoSpaces
   > تحقق بالتفصيل من معرف المساحة المطلوب باستخدام GET on /API/V1/coSpaces/<coSpace-ID>
   > التحقق من اقتران CallProfile-ID (الخطوة 1) و Guest CallLegProfile (الخطوة 2) بهذه المساحة
      [إذا لم يكن موجودا، تحقق من العناصر الأقل تحديدا مثل المستأجر (/API/V1/المستأجرين/<Tenant-ID) أو المستوى العام (API/V1/النظام/ملفات التعريف)]
4. الحصول على /API/V1/coSpaces/<coSpace-id>/accessMethods
   > تحقق بالتفصيل من AccessMethod المطلوب باستخدام GET on /API/V1/coSpaces/<coSpace-id>/accessMethods/<accessMethod-id> للتحقق من تعيين callLegProfile للمضيف

في تسجيل CMS كما هو موضح في هذا المثال، لديك أول ضيفين مشاركين داخلين (اتصل ب 38 من 2000@steven.lab واتصل ب 39 من 1060@steven.lab) وتطلعان إلى مساحة guestpin.space@acano.steven.lab ثم ينضم المضيف. يمكنك أن ترى من القصاصة التي تعرفنا بها للضيوف عن ما يجب القيام به باستخدامها (لإلغاء تنشيطها) ويمكنك أن ترى تغير هذا السلوك لتلك المكالمات عندما ينضم المضيف (stejanss.movi@steven.lab) إلى المساحة (توقف إلغاء تنشيطه). وبالمثل يمكنك مشاهدة نفس التسجيل مرة أخرى عندما ينتقل الضيوف إلى البهو مرة أخرى بمجرد عدم وجود مضيفين بعد الآن على المساحة (ليتم إلغاء تنشيطهم).

2017-02-21  17:48:54.809  Info     call 38: incoming encrypted SIP call from "sip:2000@steven.lab" to local URI "sip:guestpin.space@acano.steven.lab"
2017-02-21  17:48:54.822  Info     call 38: setting up UDT RTP session for DTLS (combined media and control)
2017-02-21  17:48:54.837  Info     call 38: compensating for far end not matching payload types
2017-02-21  17:48:54.847  Info     sending prompt response (2) to BFCP message
2017-02-21  17:48:54.847  Info     call 38: sending BFCP hello as client following receipt of hello when BFCP not active
2017-02-21  17:48:54.883  Warning  call 38: replacing pending BFCP message "PrimitiveHelloAck" with "PrimitiveHelloAck"
2017-02-21  17:48:54.883  Info     call 38: BFCP (client role) now active
2017-02-21  17:48:59.294  Info     call 39: incoming encrypted SIP call from "sip:1060@steven.lab" to local URI "sip:guestpin.space@acano.steven.lab"
2017-02-21  17:48:59.310  Info     call 39: setting up UDT RTP session for DTLS (combined media and control)
2017-02-21  17:48:59.323  Info     call 39: compensating for far end not matching payload types
2017-02-21  17:48:59.569  Info     sending prompt response (2) to BFCP message
2017-02-21  17:48:59.569  Info     call 39: sending BFCP hello as client following receipt of hello when BFCP not active
2017-02-21  17:48:59.746  Info     call 39: BFCP (client role) now active
2017-02-21  17:49:07.971  Info     configuring call e2264fb0-483f-45bc-a4f3-5a4ce326e72c to be deactivated
2017-02-21  17:49:07.972  Info     participant "2000@steven.lab" joined space 22d9f4ca-8b88-4d11-bba9-e2a2f7428c46 (Guest/Host PIN)
2017-02-21  17:49:12.463  Info     configuring call b1b5d433-5ab5-49e1-9ae3-3f4f71703d1b to be deactivated
2017-02-21  17:49:12.463  Info     participant "1060@steven.lab" joined space 22d9f4ca-8b88-4d11-bba9-e2a2f7428c46 (Guest/Host PIN)
2017-02-21  17:49:12.463  Info     conference "Guest/Host PIN": unencrypted call legs now present
2017-02-21  17:49:16.872  Info     call 40: incoming encrypted SIP call from "sip:stejanss.movi@steven.lab" to local URI "sip:guestpin.space@acano.steven.lab"
2017-02-21  17:49:16.885  Info     call 40: setting up UDT RTP session for DTLS (combined media and control)
2017-02-21  17:49:24.260  Info     call 40: audio prompt play time out
2017-02-21  17:49:26.670  Info     participant "stejanss.movi@steven.lab" joined space 22d9f4ca-8b88-4d11-bba9-e2a2f7428c46 (Guest/Host PIN)
2017-02-21  17:49:26.670  Info     call e2264fb0-483f-45bc-a4f3-5a4ce326e72c ceasing to be deactivated
2017-02-21  17:49:26.670  Info     call b1b5d433-5ab5-49e1-9ae3-3f4f71703d1b ceasing to be deactivated
2017-02-21  17:49:30.832  Info     call 40: ending; remote SIP teardown - connected for 0:14
2017-02-21  17:49:30.833  Info     participant "stejanss.movi@steven.lab" left space 22d9f4ca-8b88-4d11-bba9-e2a2f7428c46 (Guest/Host PIN)
2017-02-21  17:49:30.833  Info     configuring call e2264fb0-483f-45bc-a4f3-5a4ce326e72c to be deactivated
2017-02-21  17:49:30.833  Info     configuring call b1b5d433-5ab5-49e1-9ae3-3f4f71703d1b to be deactivated

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

• الدعم التقني والمستندات - Cisco Systems
• وثائق CMS