بروتوكول المؤتمر

يهدف هذا الوثيقة إلى وصف التطورات التي سنقوم بها لإدارة المؤتمرات (الصوت / الفيديو). الهدف هو تحسين التنفيذ الحالي الذي يدمج ببساطة مكالمات SIP ويوفر عرض شبكة، لمشاهدة حيث يتم سرد المشاركين، يمكن أن تكون غمية بشكل مستقل، أو تغيير ترتيب الفيديو (لإظهار مشارك واحد فقط)

التعريفات

المضيف: هو المستخدم الذي يخلط فيديو الصوتية للآخرين
المشارك: كل مستخدم في المؤتمر، حتى المضيف

الإفراج عن المسؤولية

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

التخطيطات المحتملة

الشبكة: يتم عرض كل عضو بنفس الارتفاع/الربع
ONE_BIG_WITH_SMALL: يتم زيادة عضو واحد وتعرض المشاهدة المسبقة الأخرى
واحد_بج: عضو واحد يأخذ الشاشة الكاملة تم عرضها

هناك طريقتان جديدة متاحة لإدارة ترتيب المؤتمر في CallManager:

/**
 * Change the conference layout
 * @param confId
 * @param layout    0 = matrix, 1 = one big, others in small, 2 = one in big
 */
void setConferenceLayout(const std::string& confId, int layout);

/**
 * Change the active participant (used in layout != matrix)
 * @param confId
 * @param participantId    If participantId not found, the local video will be shown
 */
void setActiveParticipant(const std::string& confId, const std::string& participantId);

التنفيذ بسيط جدا. كل شيء يتم إدارته من قبل conference.cpp (للربط بالمشارك بالصادر) و video_mixer.cpp (لتسجيل التخطيط المطلوب).

المعلومات المزامنة للمؤتمرات

ملاحظة: في الواقع، يتم استخدام كلمة المشارك للدعوة المختلطة في مؤتمر. يمكن أن يؤدي هذا في البداية إلى بعض المشاكل لـ API ويجب إصلاحها في المستقبل

الهدف هو إبلاغ جميع المشاركين بأضافية البيانات الخاصة بالفيديو المقدم. وهذا يعني ما هو المشارك في المؤتمر ومكان موقع الفيديو.

إذا كان المشارك هو مؤتمر نفسه، يجب دمج معلومات التخطيط المتوصلة عند إرسالها إلى المشاركين الآخرين. لا يجب دمج معلومات التخطيط عند إرسالها مرة أخرى إلى مؤتمر.

معلومات التخطيط

يتم تخزين التخطيط كـ VectorMapStringString للعملاء وعلى المستوى الداخلي مع متجه بتصميم التالي:

Layout = {
    {
        "uri": "participant", "x":"0", "y":"0", "w": "0", "h": "0", "isModerator": "true"
    },
    {
        "uri": "participant1", "x":"0", "y":"0", "w": "0", "h": "0", "isModerator": "false"
    }
    (...)
}

المفاتيح المحتملة هي:

uri = uri حساب
الجهاز = رقم الهوية للجهاز
الوسائط = هوية الوسائط
النشط = إذا كان المشارك نشطا
x = موقف (x) في الفيديو
y = موقف (y) في الفيديو
w = حجم (الربع) في الفيديو
h = حجم (الارتفاع) في الفيديو
الفيديو المُغلق = إذا كان الفيديو المُغلق
audioLocalMuted = إذا كان الصوت محلياً محتاجاً
audioModeratorMuted = إذا كان الصوت يتوقف عن المواصلين
isModerator = إذا كان هو المدير
يدي رفع = إذا رفعت اليد
النشاط الصوتي = إذا كان لدى التيار النشاط الصوتي
التسجيل = إذا كان الزميل يسجل المؤتمر

إدارة إدارة الإدارة الجديدة

هناك طريقة جديدة (في CallManager) وإشارة جديدة للحصول على معلومات المؤتمر الحالية وتحديثات:

VectorMapStringString getConferenceInfos(const std::string& confId);

void onConferenceInfosUpdated(const std::string& confId, const VectorMapStringString& infos);

يدير " Conference]] Object (الذي لا يوجد إلا إذا قمنا بتدمير المكالمات، وهذا يعني أننا المديرون) المعلومات للكونفرنس بأكملها، بناءً على " LayoutInfos " لكل " Call` Object. سيتم استرداد " getConferenceInfos " المعلومات مباشرةً من هذا الموضوع.

لذلك، كل Call كائن الآن لديه معلومات التخطيط وإذا تم تحديثها، اطلب من كائن Conference تحديث معلوماتها.

يرسل مدير المؤتمر معلوماته عبر قناة SIP كرسالة ذات نوع MIME التالي: application/confInfo+json

إذاً، إذا تلقيت مكالمة معلومات، فنحن نعلم أن هذه المكالمة هي عضو في مؤتمر.

لتلخيص، Call يدير التخطيطات المستلمة، Conference-managed المشاريع المرسلة.

تغيير حالة المؤتمر

لتغيير حالة المؤتمر، يحتاج المشاركون إلى إرسال أوامر سيتعامل بها المضيف.

البروتوكول له الاحتياجات التالية:

يجب أن تتعامل مع الطلبات على مستويات متعددة في الواقع للمؤتمر 3 مستويات لتحديد المشارك:

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

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

الإجراءات العامة

لتغيير التخطيط، يمكن للمدير إرسال تحميل مفيد مع "التطبيق/confOrder+json" كنوع: حيث 0 هو شبكة، 1 هو مستخدم واحد في الكبير، الآخرين في الصغر، 2 هو واحد في الكبير

أفعال الحساب

في الوقت الحالي، لا يوجد أي إجراء مدعوم، ومع ذلك، في المستقبل الموسيط: يجب التعامل مع true/false لتغيير الموسيط.

أفعال الجهاز

hangup: true لشنق جهاز من المؤتمر (المديرين فقط)
raisehand: true/false لتغيير وضع اليد الرفع. فقط ممكنة من قبل الجهاز نفسه، وإلا انقطعت.

أفعال وسائل الإعلام

muteAudio فقط ممكنا من قبل المديرين لتخفيف صوت المشارك
muteVideo لم يتم دعمها بعد.
active ليشير إلى أن وسائل الإعلام نشطة.
صوت النشاط للإشارة إلى حالة النشاط الصوتي في سلسلة الإعلام (مناسبة للصوت فقط)

مثال

So, the application/confOrder+json will contain:

{
    "989587609427420" : {
        "moderator": true, /* false  */
        "devices": {
            "40940943604396R64363": {
                "hangup": true,
                "raisehand": true, /* false */
                "media":{
                    "3532532662432" : {
                        "muteAudio": true, /* false */
                        "muteVideo": true, /* false */
                        "active": true, /* false */
                        "voiceActivity": true /* false */
                    }
                }
            }
        }
    },
    "layout": 0, /* 1, 2 */
}

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

مراقبة المديرين

هناك في الواقع 3 إحتمالات:

إعداد حساب التغيير لإضافة قائمة للمديرين (في config.yml (defaultModerators يمكن أن تحتوي على قائمة للمديرين الافتراضيين)
إذا كان localModeratorsEnabled صحيحاً، فإن جميع حسابات الجهاز ستكون معايرات
إذا كان كل المديرين تمكينهم صحيحاً، فكل شخص في المؤتمر سيكون المدير

المستقبل

تدفقات منفصلة للسماح بمزيد من التحكم؟

ملاحظات/ تعليقات

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