پروتکل کنفرانس

این سند به منظور توصیف تحولاتی است که ما برای مدیریت کنفرانس ها انجام خواهیم داد (آدیو / ویدیو). هدف بهبود اجرای فعلی است که به سادگی تماس های SIP را ترکیب می کند و یک نمای شبکه را فراهم می کند، به طوری که در آن شرکت کنندگان لیست شده اند، می توانند به طور مستقل خاموش شوند، یا طرح ویدیو تغییر کند (تا فقط یک شرکت کننده را نشان دهد)

تعاریف

• میزبان: کاربر است که جریان های صوتی / ویدیویی را برای دیگران مخلوط می کند

• شرکت کننده: هر کاربر در کنفرانس، حتی میزبان

اعلامیه

این سند تنها مراحل اول را برای حال توصیف می کند. این به معنای شناسایی شرکت کنندگان و موقعیت در مخلوط کننده ویدیویی است که به همه شرکت کنندگان ارسال می شود.

طرح های احتمالی

• شبکه: هر عضو با ارتفاع/بسیاری یکسان نشان داده می شود

• ONE_BIG_WITH_SMALL: یکی از اعضای به صورت بزرگ و دیگر پیش نمایش نمایش داده می شود

• ONE_BIG: یک عضو صفحه نمایش کامل را نشان می دهد

دو روش جدید برای مدیریت ترتیب کنفرانس در 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 (برای ارائه طرح مورد نظر) مدیریت می شود.

همگام سازی کنفرانس اطلاعات

توجه: در واقع، کلمه شرکت کننده برای callId مخلوط در یک کنفرانس استفاده می شود. این می تواند در ابتدا به برخی از مشکلات برای 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 = اندازه (باید) در ویدیو

• videoMuted = اگر ویدیو خاموش شده باشد

• audioLocalMuted = اگر صدا در محله خاموش شده باشد

• audioModeratorMuted = اگر صدا توسط منتظم ها خاموش شود

• isModerator = اگر یک مودراتور باشد

• دست بالا = اگر دست بالا باشد

• فعالیت صدا = اگر جریان فعالیت صدا داشته باشد

• ضبط کردن = اگر همتایان کنفرانس را ضبط می کنند

API جدید

یک روش جدید (در CallManager) و یک سیگنال جدید برای دریافت اطلاعات و به روزرسانی های کنفرانسی به ترتیب در دسترس هستند:

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

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

اجرای

Conference Object (که فقط اگر ما تماس ها را مخلوط کنیم وجود دارد، این بدان معنی است که ما استاد هستیم) اطلاعات را برای کل کنفرانس مدیریت می کند، بر اساس LayoutInfos هر Call object. getConferenceInfos اطلاعات را مستقیماً از این object بازمی گیرد.

بنابراین، هر Call شی اکنون دارای یک LayoutInfo است و اگر به روز شود، از شی Conference بخواهید تا اطلاعات خود را به روز کند.

مدیر یک کنفرانس اطلاعات خود را از طریق کانال SIP به عنوان یک پیام با نوع MIME زیر ارسال می کند: application/confInfo+json

پس، اگر یک تماس اطلاعات مربوطه دریافت کند، می دانیم که این تماس عضو یک کنفرانس است.

به طور خلاصه، Call مدیریت طرح های دریافت شده، Conference-managed ارسال طرح ها.

تغییر وضعیت کنفرانس

برای تغییر وضعیت کنفرانس، شرکت کنندگان باید دستورات را ارسال کنند که میزبان آنها را اداره کند.

پروتکل نیاز های زیر را دارد:

در واقع برای یک کنفرانس 3 سطح برای تعریف یک شرکت کننده است:

• حساب که هویت شرکت کننده است

• دستگاه ها، چون هر حساب می تواند از طریق چندین دستگاه به هم پیوسته شود

• رسانه ها، زیرا می تواند چندین ویدیو توسط دستگاه وجود داشته باشد (به عنوان مثال یک دوربین و یک اشتراک صفحه نمایش)

برای ذخیره کردن بیند وایت، مشتریان باید بتوانند چندین سفارش را به یکباره ارسال کنند.

اقدامات عمومی

برای تغییر طرح، مدیر می تواند یک بار مفید با "applications/confOrder+json" به عنوان نوع ارسال کند: جایی که 0 یک شبکه است، 1 یک کاربر در بزرگ، دیگران در کوچک، 2 یک کاربر در بزرگ است

اعمال حساب

در حال حاضر هیچ اقدام حمایت شده ای وجود ندارد، اما در آینده مدراتور: باید true/false برای تغییر یک مدیر مورد استفاده قرار گیرد.

اقدامات دستگاه

• hangup: true برای شنک کردن یک دستگاه از کنفرانس (تنها مدیران)

• raisehand: true/false برای تغییر وضعیت دست بلند کردن. فقط توسط دستگاه خود قابل انجام است، در غیر این صورت کاهش یافته است.

اقدامات رسانه ها

• muteAudio فقط توسط مدیران می توان صدای یک شرکت کننده را خاموش کرد

• muteVideo هنوز پشتیبانی نشده

• active برای نشان دادن رسانه ها به عنوان فعال.

• صوت فعالیت برای نشان دادن وضعیت فعالیت صوتی یک جریان رسانه ای (تنها مربوط به صوتی)

نمونه

بنابراین، درخواست / سفارش + json` شامل:

{
    "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,
}

توجه: نوع رسانه باید در اطلاعات کنفرانس ها شامل شود و می تواند برای بهبود نمایش مشتری استفاده شود (به عنوان مثال، اشتراک گذاری صفحه نمایش را قطع نکنید)

کنترل مدیران

در واقع سه احتمال وجود داره:

• تنظیم حساب تغییر برای اضافه کردن یک لیست مودراتورها (در config.yml (defaultModerators می تواند حاوی یک لیست مودراتورهای پیش فرض باشد)

• اگر localModeratorsEnabled درست باشد، تمام حساب های دستگاه باید مدراتور باشند

• اگر allModeratorsEnabled درست باشد، هر کسی در کنفرانس یک مدراتور خواهد بود

آینده

• جریان های جداگانه ای برای کنترل بیشتر؟

یادداشت/تبصرات

احتمال دارد که پروتکل برای نیازهای آینده تکامل یابد. من معتقدم که بهتر است که یک زمینه "ورژن" داشته باشیم. نسخه قدیمی تر اگر این زمینه از دست رفته باشد شناخته خواهد شد.