Cisco Meeting Server 2.5.2. خوشه در حالت مقیاس پذیر و انعطاف پذیر با ضبط ویدئو کنفرانس

در این شماره من برخی از پیچیدگی های راه اندازی یک سرور CMS در حالت Failover Cluster را نشان داده و توضیح خواهم داد.


Теорияبه طور کلی، سه نوع استقرار سرور CMS وجود دارد:

• تک ترکیبی(تک ترکیبی)، یعنی. این یک سرور است که تمام خدمات لازم روی آن اجرا می شود. در بیشتر موارد، این نوع استقرار فقط برای دسترسی مشتری داخلی و در محیط‌های کوچک‌تر که مقیاس‌پذیری و محدودیت‌های افزونگی یک سرور منفرد مسئله مهمی نیست، یا در شرایطی که CMS فقط عملکردهای خاصی را انجام می‌دهد، مانند ad hoc مناسب است. کنفرانس های Cisco UCM.

  طرح تقریبی کار:
  

• تک تقسیم(Single Split) با افزودن یک سرور جداگانه برای دسترسی خارجی، نوع استقرار قبلی را گسترش می دهد. در استقرارهای قدیمی، این به معنای استقرار یک سرور CMS در یک بخش شبکه غیرنظامی (DMZ) است که در آن مشتریان خارجی می توانند به آن دسترسی داشته باشند، و یک سرور CMS در هسته شبکه که در آن مشتریان داخلی می توانند به CMS دسترسی داشته باشند. این مدل استقرار خاص در حال حاضر توسط نوع به اصطلاح جایگزین شده است تک لبه، که از سرورها تشکیل شده است بزرگراه سیسکو، که بسیاری از قابلیت های دور زدن فایروال را دارند یا خواهند داشت، بنابراین مشتریان نیازی به افزودن سرور CMS لبه اختصاصی ندارند.

  طرح تقریبی کار:
  

• مقیاس پذیر و انعطاف پذیر(Scalable and Fault Tolerant) این نوع شامل افزونگی برای هر جزء است که به سیستم اجازه می دهد تا با نیازهای شما تا حداکثر ظرفیت خود رشد کند در حالی که در صورت خرابی افزونگی ارائه می دهد. همچنین از مفهوم Single Edge برای ارائه دسترسی خارجی امن استفاده می کند. این نوعی است که در این قسمت به آن خواهیم پرداخت. اگر نحوه استقرار این نوع خوشه را بدانیم، نه تنها انواع دیگر استقرارها را درک خواهیم کرد، بلکه می‌توانیم نحوه ایجاد خوشه‌هایی از سرورهای CMS را برای تطبیق با رشد بالقوه تقاضا درک کنیم.

قبل از حرکت به سمت استقرار، باید چند چیز اساسی را درک کنید، یعنی

اجزای اصلی نرم افزار CMS:

• پایگاه داده: به شما امکان می دهد برخی از تنظیمات مانند پلان شماره گیری، فضاهای کاربر و خود کاربران را ترکیب کنید. پشتیبانی از خوشه بندی برای در دسترس بودن بالا (مستر تک) فقط.
• پل تماس بگیرید: سرویسی برای کنفرانس صوتی و تصویری که کنترل کامل بر مدیریت و پردازش تماس ها و فرآیندهای چند رسانه ای را فراهم می کند. از خوشه بندی برای در دسترس بودن و مقیاس پذیری بالا پشتیبانی می کند.
• سرور XMPP: مسئول ثبت نام و احراز هویت مشتریان با استفاده از برنامه Cisco Meeting و/یا WebRTC(ارتباط بلادرنگ یا به سادگی در مرورگر)و همچنین سیگنال دهی بین اجزایی. فقط برای در دسترس بودن بالا می تواند خوشه بندی شود.
• پل وب: دسترسی مشتری به WebRTC را فراهم می کند.
• متعادل کننده بار: یک نقطه اتصال واحد برای برنامه‌های جلسه Cisco در حالت تقسیم تک فراهم می‌کند. به رابط خارجی و پورت برای اتصالات ورودی گوش می دهد. به همین ترتیب، بار متعادل کننده اتصالات TLS ورودی از سرور XMPP را می پذیرد، که از طریق آن می تواند اتصالات TCP را از مشتریان خارجی تغییر دهد.
  در سناریوی ما نیازی به آن نخواهد بود.
• سرور را روشن کنید: فناوری دور زدن فایروال را ارائه می دهد که اجازه می دهد
  CMS خود را پشت فایروال یا NAT قرار دهید تا مشتریان خارجی را با استفاده از برنامه جلسه سیسکو یا دستگاه های SIP متصل کنید. در سناریوی ما نیازی به آن نخواهد بود.
• مدیر وب: رابط اداری و دسترسی API، از جمله برای کنفرانس های CM یکپارچه.

حالت های پیکربندی

برخلاف اکثر محصولات دیگر سیسکو، سرور جلسه سیسکو از سه روش پیکربندی برای سازگاری با هر نوع استقرار پشتیبانی می کند.

• خط فرمان (CLI): رابط خط فرمان معروف به MMP برای پیکربندی اولیه و وظایف گواهی.
• مدیر وب: در درجه اول برای پیکربندی های مربوط به CallBridge، به ویژه هنگام راه اندازی یک سرور منفرد غیر خوشه ای.
• REST API: برای پیچیده ترین وظایف پیکربندی و وظایف مربوط به پایگاه داده خوشه ای استفاده می شود.

علاوه بر موارد فوق، از پروتکل استفاده می شود SFTP برای انتقال فایل‌ها (معمولا مجوزها، گواهی‌ها یا گزارش‌ها) به و از سرور CMS.

در راهنماهای استقرار سیسکو به رنگ سفید و انگلیسی نوشته شده است که کلاستر باید مستقر شود. حداقل سه سرورها (گره ها) در زمینه پایگاه های داده. زیرا تنها با تعداد فرد گره، مکانیسم انتخاب پایگاه داده Master جدید کار می کند و به طور کلی Database Master با اکثر پایگاه داده سرور CMS ارتباط دارد.

و همانطور که تمرین نشان می دهد، دو سرور (گره) واقعاً کافی نیستند. مکانیسم انتخاب زمانی کار می‌کند که Master مجددا راه‌اندازی شود، سرور Slave تنها پس از بالا آمدن سرور راه‌اندازی شده، Master می‌شود. با این حال، اگر در یک خوشه از دو سرور، سرور Master به طور ناگهانی خاموش شود، سرور Slave به Master تبدیل نمی شود و اگر Slave خارج شود، سرور Master باقی مانده به Slave تبدیل می شود.

اما در زمینه XMPP، جمع آوری یک خوشه از سه سرور واقعاً ضروری است، زیرا به عنوان مثال، اگر سرویس XMPP را در یکی از سرورهایی که XMMP در آن وضعیت Leader است غیرفعال کنید، در سرور باقیمانده XMPP در وضعیت Follower باقی می‌ماند و اتصالات CallBridge به XMPP قطع می‌شود، زیرا CallBridge منحصراً به XMPP با وضعیت Leader متصل می شود. و این بسیار مهم است، زیرا ... حتی یک تماس هم انجام نخواهد شد

همچنین در همان راهنماهای استقرار یک خوشه با یک سرور XMPP نشان داده شده است.

و با در نظر گرفتن موارد فوق، دلیل آن مشخص می شود: به دلیل اینکه در حالت Failover است، کار می کند.

در مورد ما، سرور XMPP در هر سه گره وجود خواهد داشت.

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

رکوردهای DNS

قبل از شروع به راه اندازی سرورها، باید رکوردهای DNS ایجاد کنید А и SRV انواع:

لطفاً توجه داشته باشید که در رکوردهای DNS ما دو دامنه example.com و کنفرانس.example.com. Example.com دامنه‌ای است که همه مشترکین Cisco Unified Communication Manager می‌توانند برای URI خود استفاده کنند که به احتمال زیاد در زیرساخت شما وجود دارد یا احتمالاً وجود دارد. یا example.com با همان دامنه ای مطابقت دارد که کاربران برای آدرس های ایمیل خود استفاده می کنند. یا کلاینت Jabber در لپ تاپ شما ممکن است یک URI داشته باشد [ایمیل محافظت شده]. دامنه کنفرانس.example.com دامنه ای است که برای کاربران Cisco Meeting Server پیکربندی می شود. دامنه سرور جلسه سیسکو خواهد بود کنفرانس.example.com، بنابراین برای همان کاربر Jabber، user@ URI باید برای ورود به سرور Cisco Meeting استفاده شود.کنفرانس.example.com.

پیکربندی اولیه

تمام تنظیمات توضیح داده شده در زیر در یک سرور نشان داده شده است، اما آنها باید در هر سرور در خوشه انجام شوند.

کیفیت سرویس

از آنجایی که CMS تولید می کند زمان واقعی ترافیک حساس به تاخیر و از دست دادن بسته، در بیشتر موارد توصیه می شود که کیفیت خدمات (QoS) را پیکربندی کنید. برای رسیدن به این هدف، CMS از برچسب گذاری بسته ها با کدهای خدمات متمایز (DSCP) که تولید می کند، پشتیبانی می کند. اگرچه اولویت بندی ترافیک مبتنی بر DSCP به نحوه پردازش ترافیک توسط اجزای شبکه زیرساخت شما بستگی دارد، در مورد ما CMS خود را با اولویت بندی DSCP معمولی بر اساس بهترین شیوه های QoS پیکربندی می کنیم.

در هر سرور این دستورات را وارد خواهیم کرد

dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1A

بنابراین، تمام ترافیک ویدیویی با علامت AF41 (DSCP 0x22)، تمام ترافیک صوتی با علامت EF (DSCP 0x2E)، سایر انواع ترافیک کم تاخیر مانند SIP و XMPP از AF31 (DSCP 0x1A) استفاده می‌کنند.

ما بررسی می کنیم:

NTP

پروتکل زمان شبکه (NTP) نه تنها برای ارائه مُهر زمانی دقیق تماس‌ها و کنفرانس‌ها، بلکه برای تأیید گواهی‌ها نیز مهم است.

سرورهای NTP را با دستوری مانند به زیرساخت خود اضافه کنید

ntp server add <server>

در مورد ما، دو سرور وجود دارد، بنابراین دو تیم وجود خواهد داشت.
ما بررسی می کنیم:

و منطقه زمانی را برای سرور خود تنظیم کنید

DNS

سرورهای DNS را با دستوری مانند:

dns add forwardzone <domain-name> <server ip>

در مورد ما، دو سرور وجود دارد، بنابراین دو تیم وجود خواهد داشت.
ما بررسی می کنیم:

پیکربندی رابط شبکه

ما رابط را با دستوری مانند:

ipv4 <interface> add <address>/<prefix length> <gateway>

ما بررسی می کنیم:

نام سرور (نام میزبان)

نام سرور را با دستوری مانند:

hostname <name>

و راه اندازی مجدد می کنیم.


این پیکربندی اولیه را کامل می کند.

گواهینامه ها

ТеорияCisco Meeting Server به ارتباطات رمزگذاری شده بین اجزای مختلف نیاز دارد و در نتیجه، گواهی های X.509 برای همه استقرارهای CMS مورد نیاز است. آنها کمک می کنند تا اطمینان حاصل شود که خدمات / سرور مورد اعتماد سایر سرورها / خدمات است.

هر سرویس به یک گواهی نیاز دارد، اما ایجاد گواهی های جداگانه برای هر سرویس می تواند منجر به سردرگمی و پیچیدگی غیر ضروری شود. خوشبختانه، می‌توانیم جفت کلید عمومی-خصوصی یک گواهی را تولید کنیم و سپس از آن‌ها در چندین سرویس استفاده کنیم. در مورد ما، همان گواهی برای Call Bridge، XMPP Server، Web Bridge و Web Admin استفاده خواهد شد. بنابراین، شما باید یک جفت کلید گواهی عمومی و خصوصی برای هر سرور در خوشه ایجاد کنید.

با این حال، خوشه‌بندی پایگاه داده دارای الزامات گواهینامه خاصی است و بنابراین به گواهی‌های خاص خود نیاز دارد که با گواهی‌های سایر سرویس‌ها متفاوت است. CMS از یک گواهی سرور استفاده می کند که مشابه گواهی های استفاده شده توسط سرورهای دیگر است، اما یک گواهی مشتری نیز وجود دارد که برای اتصالات پایگاه داده استفاده می شود. گواهی های پایگاه داده هم برای احراز هویت و هم برای رمزگذاری استفاده می شود. به جای ارائه یک نام کاربری و رمز عبور برای مشتری برای اتصال به پایگاه داده، گواهی مشتری را ارائه می دهد که مورد اعتماد سرور است. هر سرور در کلاستر پایگاه داده از یک جفت کلید عمومی و خصوصی استفاده خواهد کرد. این به همه سرورهای خوشه اجازه می دهد تا داده ها را به گونه ای رمزگذاری کنند که فقط توسط سرورهای دیگری که جفت کلید یکسانی دارند رمزگشایی شوند.

برای اینکه افزونگی کار کند، کلاسترهای پایگاه داده باید حداقل از 3 سرور تشکیل شده باشند، اما حداکثر 5 سرور، با حداکثر زمان رفت و برگشت 200 میلی ثانیه بین هر یک از اعضای خوشه. این محدودیت نسبت به خوشه‌بندی Call Bridge محدودتر است، بنابراین اغلب عامل محدودکننده در استقرارهای توزیع شده جغرافیایی است.

نقش پایگاه داده برای یک CMS دارای تعدادی الزامات منحصر به فرد است. برخلاف سایر نقش‌ها، به گواهی مشتری و سرور نیاز دارد، جایی که گواهی مشتری دارای یک فیلد CN خاص است که به سرور ارائه می‌شود.

CMS از یک پایگاه داده postgres با یک Master و چندین replica کاملاً یکسان استفاده می کند. تنها یک پایگاه داده اصلی در هر زمان وجود دارد ("سرور پایگاه داده"). اعضای باقی‌مانده خوشه کپی یا «مشتریان پایگاه داده» هستند.

یک خوشه پایگاه داده به یک گواهی سرور اختصاصی و یک گواهی مشتری نیاز دارد. آنها باید توسط گواهی ها، معمولاً یک مرجع گواهی خصوصی داخلی، امضا شوند. از آنجایی که هر عضوی از خوشه پایگاه داده می تواند به عنوان Master تبدیل شود، جفت های گواهی سرور پایگاه داده و مشتری (شامل کلیدهای عمومی و خصوصی) باید در همه سرورها کپی شوند تا بتوانند هویت مشتری یا سرور پایگاه داده را فرض کنند. علاوه بر این، گواهی ریشه CA باید بارگذاری شود تا اطمینان حاصل شود که گواهی های سرویس گیرنده و سرور قابل تأیید هستند.

بنابراین، ما یک درخواست برای یک گواهی ایجاد می کنیم که توسط همه سرویس های سرور به جز پایگاه داده استفاده می شود (یک درخواست جداگانه برای این کار وجود دارد) با دستوری مانند:

pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com

در CN نام کلی سرورهایمان را می نویسیم. به عنوان مثال، اگر نام هاست سرورهای ما سرور 01, سرور 02, سرور 03، سپس CN خواهد بود server.example.com

ما همین کار را روی دو سرور باقیمانده انجام می دهیم با این تفاوت که دستورات حاوی "نام میزبان" مربوطه هستند.

ما دو درخواست برای گواهی ایجاد می کنیم که توسط سرویس پایگاه داده با دستوراتی مانند:

pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com

pki csr dbclusterclient CN:postgres

جایی که سرور dbcluster и dbclusterclient نام درخواست‌های ما و گواهی‌های آینده، نام میزبان 1 (2) (3) نام سرورهای مربوطه

ما این روش را فقط روی یک سرور (!) انجام می دهیم و گواهی ها و فایل های کلیدی مربوطه را در سرورهای دیگر آپلود می کنیم.

حالت گواهی مشتری را در AD CS فعال کنید

همچنین باید گواهینامه های هر سرور را در یک فایل ادغام کنید.در *NIX:

cat server01.cer server02.cer server03.cer > server.cer

در Windows/DOS:

copy server01.cer + server02.cer + server03.cer  server.cer

و در هر سرور آپلود کنید:
1. گواهی سرور "انفرادی".
2. گواهی ریشه (همراه با موارد متوسط، در صورت وجود).
3. گواهی برای پایگاه داده ("سرور" و "مشتری") و فایل هایی با پسوند کلید، که هنگام ایجاد درخواست برای گواهی های پایگاه داده "سرور" و "مشتری" ایجاد شده اند. این فایل ها باید در همه سرورها یکسان باشند.
4. پرونده هر سه گواهی "انفرادی".

در نتیجه، شما باید چیزی شبیه به این تصویر فایل در هر سرور دریافت کنید.

خوشه پایگاه داده

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

پایگاه داده استاد

اولین قدم در راه اندازی Replication پایگاه داده، مشخص کردن گواهینامه هایی است که برای پایگاه داده استفاده می شود. این کار با استفاده از دستوری مانند:

database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>

حال اجازه دهید به CMS بگوییم که از کدام رابط برای خوشه بندی پایگاه داده با دستور استفاده کند:

database cluster localnode a

سپس پایگاه داده خوشه را در سرور اصلی با دستور مقداردهی اولیه می کنیم:

database cluster initialize

گره های پایگاه داده مشتری

ما همین رویه را فقط به جای دستور انجام می دهیم خوشه پایگاه داده اولیه دستوری مانند:

database cluster join <ip address existing master>

که در آن آدرس IP آدرس IP اصلی سرور CMS که خوشه بر روی آن مقداردهی اولیه شده است، به سادگی Master است.

با این دستور بررسی می کنیم که خوشه پایگاه داده ما در همه سرورها چگونه کار می کند:

database cluster status

ما همین کار را در سرور سوم باقیمانده انجام می دهیم.

در نتیجه، معلوم می شود که سرور اول ما Master است، بقیه Slave هستند.

سرویس مدیریت وب

فعال کردن سرویس مدیر وب:

webadmin listen a 445

پورت 445 به این دلیل انتخاب شد که پورت 443 برای دسترسی کاربر به سرویس گیرنده وب استفاده می شود

ما سرویس Web Admin را با فایل های گواهی با دستوری مانند:

webadmin certs <keyfile> <certificatefile> <ca bundle>

و Web Admin را با دستور فعال کنید:

webadmin enable

اگر همه چیز خوب باشد، خطوط SUCCESS را دریافت خواهیم کرد که نشان می دهد وب مدیر به درستی برای شبکه و گواهی پیکربندی شده است. ما عملکرد سرویس را با استفاده از یک مرورگر وب بررسی می کنیم و آدرس مدیر وب را وارد می کنیم، به عنوان مثال: cms.example.com: 445

خوشه پل فراخوانی

Call Bridge تنها سرویسی است که در هر استقرار CMS وجود دارد. Call Bridge مکانیزم اصلی کنفرانس است. همچنین یک رابط SIP فراهم می‌کند تا تماس‌ها به‌عنوان مثال، یک سیسکو Unified CM به آن یا از آن هدایت شوند.

دستورات توضیح داده شده در زیر باید روی هر سرور با گواهینامه های مناسب اجرا شوند.
پس:

ما گواهی ها را با سرویس Call Bridge با دستوری مانند:

callbridge certs <keyfile> <certificatefile>[<cert-bundle>]

ما خدمات CallBridge را با این دستور به رابط مورد نیاز خود متصل می کنیم:

callbridge listen a

و سرویس را با دستور ریستارت کنید:

callbridge restart

اکنون که پل‌های تماس خود را پیکربندی کرده‌ایم، می‌توانیم خوشه‌بندی پل تماس را پیکربندی کنیم. خوشه بندی Call Bridge با پایگاه داده یا خوشه بندی XMPP متفاوت است. Call Bridge Cluster می تواند از 2 تا 8 گره را بدون هیچ محدودیتی پشتیبانی کند. این نه تنها افزونگی، بلکه تعادل بار را نیز فراهم می‌کند، به طوری که کنفرانس‌ها می‌توانند به طور فعال در سرورهای Call Bridge با استفاده از توزیع هوشمند تماس توزیع شوند. CMS دارای ویژگی های اضافی، گروه های Call Bridge و ویژگی های مرتبط است که می تواند برای مدیریت بیشتر استفاده شود.

خوشه‌بندی پل تماس عمدتاً از طریق رابط مدیریت وب پیکربندی می‌شود
رویه توضیح داده شده در زیر باید در هر سرور در کلاستر انجام شود.
بنابراین،

1. از طریق وب به Configuration > Cluster بروید.
2. در هویت پل را فراخوانی کنید به عنوان یک نام منحصر به فرد، callbridge[01,02,03] مربوط به نام سرور را وارد کنید. این نام‌ها دلخواه هستند، اما باید برای این خوشه منحصربه‌فرد باشند. آنها ماهیت توصیفی دارند زیرا نشان می دهند که شناسه سرور هستند [01,02,03].
3.B پل های تماس خوشه ای URL های مدیر وب سرورهای ما را در خوشه وارد کنید، سیستم مدیریت محتوا[01,02,03].example.com:445، در قسمت Address. حتما پورت را مشخص کنید. می توانید دامنه SIP پیوند همتا را خالی بگذارید.
4. یک گواهی به CallBridge Trust هر سرور اضافه کنید که فایل آن حاوی تمام گواهی های سرورهای ما است که در همان ابتدا با دستوری مانند:

callbridge trust cluster <trusted cluster certificate bundle>

و سرویس را با دستور ریستارت کنید:

callbridge restart

در نتیجه، در هر سرور باید این تصویر را دریافت کنید:

XMPP Cluster

سرویس XMPP در CMS برای انجام کلیه ثبت نام و احراز هویت برای برنامه های جلسه سیسکو (CMA)، از جمله سرویس گیرنده وب CMA WebRTC استفاده می شود. خود Call Bridge نیز به عنوان یک سرویس گیرنده XMPP برای اهداف احراز هویت عمل می کند و بنابراین باید مانند سایر کلاینت ها پیکربندی شود. تحمل خطا XMPP یک ویژگی است که از نسخه 2.1 در محیط های تولید پشتیبانی می شود

دستورات توضیح داده شده در زیر باید روی هر سرور با گواهینامه های مناسب اجرا شوند.
پس:

ما گواهی ها را با سرویس XMPP با دستوری مانند:

xmpp certs <keyfile> <certificatefile>[<cert-bundle>]

سپس رابط گوش دادن را با دستور تعریف کنید:

xmpp listen a

سرویس XMPP به یک دامنه منحصر به فرد نیاز دارد. این ورود برای کاربران است. به عبارت دیگر، زمانی که کاربر سعی می کند با استفاده از برنامه CMA (یا از طریق کلاینت WebRTC) وارد سیستم شود، userID@logindomain را وارد می کند. در مورد ما userid@ خواهد بودکنفرانس.example.com. چرا فقط example.com نیست؟ در استقرار خاص خود، دامنه Unified CM خود را انتخاب کردیم که کاربران Jabber در Unified CM به عنوان example.com از آن استفاده خواهند کرد، بنابراین به دامنه متفاوتی برای کاربران CMS نیاز داشتیم تا تماس‌ها را به و از CMS از طریق دامنه‌های SIP هدایت کنند.

یک دامنه XMPP با استفاده از دستوری مانند:

xmpp domain <domain>

و سرویس XMPP را با دستور زیر فعال کنید:

xmpp enable

در سرویس XMPP، شما باید برای هر پل تماس اعتباری ایجاد کنید که هنگام ثبت نام در سرویس XMPP استفاده می شود. این نام‌ها دلخواه هستند (و به نام‌های منحصربه‌فردی که برای خوشه‌بندی پل تماس پیکربندی کرده‌اید مربوط نمی‌شوند). شما باید سه پل تماس را روی یک سرور XMPP اضافه کنید و سپس آن اعتبارنامه ها را در سایر سرورهای XMPP در خوشه وارد کنید زیرا این پیکربندی در پایگاه داده خوشه نمی گنجد. بعداً ما هر پل تماس را طوری پیکربندی می‌کنیم که از این نام و رمز برای ثبت نام در سرویس XMPP استفاده کند.

اکنون باید سرویس XMPP را روی سرور اول با سه پل Call callbridge01، callbridge02 و callbridge03 پیکربندی کنیم. به هر حساب رمزهای عبور تصادفی اختصاص داده می شود. آنها بعداً در سرورهای دیگر Call Bridge برای ورود به این سرور XMPP وارد می شوند. دستورات زیر را وارد کنید:

xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03

در نتیجه، بررسی می کنیم که با دستور چه اتفاقی افتاده است:

xmpp callbridge list

دقیقاً همان تصویر باید در سرورهای باقی مانده پس از مراحل توضیح داده شده در زیر ظاهر شود.

بعد دقیقاً همان تنظیمات را روی دو سرور باقیمانده فقط با دستورات اضافه می کنیم

xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03

Secret را خیلی با دقت اضافه می کنیم تا مثلاً فضای اضافی در آن نباشد.


در نتیجه، هر سرور باید تصویر یکسانی داشته باشد:

در مرحله بعد، در تمام سرورهای کلاستر، فایلی را که حاوی هر سه گواهی است که قبلاً با دستوری مانند زیر ایجاد شده است، به صورت اعتماد مشخص می کنیم:

xmpp cluster trust <trust bundle>

حالت خوشه xmpp را در تمام سرورهای کلاستر با دستور زیر فعال می کنیم:

xmpp cluster enable

در اولین سرور خوشه، ایجاد یک کلاستر xmpp را با دستور زیر آغاز می کنیم:

xmpp cluster initialize

در سرورهای دیگر، یک کلاستر به xmpp با دستوری مانند:

xmpp cluster join <ip address head xmpp server>

ما در هر سرور موفقیت ایجاد یک کلاستر XMPP در هر سرور را با دستورات زیر بررسی می کنیم:

xmpp status
xmpp cluster status

سرور اول:

سرور دوم:

سرور سوم:

اتصال پل تماس به XMPP

اکنون که کلاستر XMPP در حال اجرا است، باید سرویس های Call Bridge را برای اتصال به خوشه XMPP پیکربندی کنید. این تنظیمات از طریق ادمین وب انجام می شود.

در هر سرور، به Configuration > General و در فیلد بروید نام منحصر به فرد Call Bridge نام های منحصر به فرد Call Bridge مربوط به سرور را بنویسید پل تماس[01,02,03]به در زمینه دامنه conf.example.ru و رمزهای عبور مربوطه، می توانید از آنها جاسوسی کنید
در هر سروری در کلاستر با دستور:

xmpp callbridge list

قسمت "Server" را خالی بگذارید تماس تلفنی یک جستجوی DNS SRV برای انجام خواهد داد _xmpp-component._tcp.conf.example.comبرای یافتن سرور XMPP موجود. آدرس های IP برای اتصال پل های تماس به XMPP ممکن است در هر سرور متفاوت باشد، بستگی به این دارد که چه مقادیری به درخواست رکورد برگردانده می شود. _xmpp-component._tcp.conf.example.com callbridge، که به نوبه خود به تنظیمات اولویت برای یک رکورد DNS معین بستگی دارد.

سپس به مسیر Status > General بروید تا بررسی کنید که آیا سرویس Call Bride با موفقیت به سرویس XMPP متصل شده است یا خیر.

پل وب

در هر سرور در کلاستر، سرویس Web Bridge را با دستور زیر فعال کنید:

webbridge listen a:443

ما سرویس Web Bridge را با فایل های گواهی با دستوری مانند:

webbridge  certs <keyfile> <certificatefile> <ca bundle>

Web Bridge از HTTPS پشتیبانی می کند. اگر برای استفاده از "http-redirect" پیکربندی شده باشد، HTTP را به HTTPS هدایت می کند.
برای فعال کردن تغییر مسیر HTTP، از دستور زیر استفاده کنید:

webbridge http-redirect enable

برای اینکه به Call Bridge بفهمید که Web Bridge می تواند به اتصالات Call Bridge اعتماد کند، از دستور استفاده کنید:

webbridge trust <certfile>

که در آن این یک فایل حاوی هر سه گواهی از هر سرور در خوشه است.

این تصویر باید در هر سرور در خوشه باشد.


اکنون باید یک کاربر با نقش "appadmin" ایجاد کنیم، به آن نیاز داریم تا بتوانیم خوشه (!) خود را پیکربندی کنیم و نه هر سرور در کلاستر به طور جداگانه، به این ترتیب تنظیمات به طور یکسان برای هر سرور علیرغم وجود واقعیت این است که آنها یک بار ساخته می شوند.


برای راه اندازی بیشتر استفاده خواهیم کرد پستچی.

برای مجوز، Basic را در قسمت Authorization انتخاب کنید

برای ارسال صحیح دستورات به سرور CMS، باید کدگذاری مورد نیاز را تنظیم کنید

با دستور Webbridge را مشخص می کنیم پست با پارامتر آدرس و معنی cms.example.com



در خود وببریج، پارامترهای مورد نیاز را نشان می دهیم: دسترسی مهمان، دسترسی محافظت شده و غیره.

تماس با گروه های پل

به‌طور پیش‌فرض، CMS همیشه از منابع کنفرانس در دسترس خود به بهترین شکل ممکن استفاده نمی‌کند.

به عنوان مثال، برای جلسه ای با سه شرکت کننده، هر شرکت کننده ممکن است در سه پل تماس مختلف قرار گیرد. برای اینکه این سه شرکت‌کننده با یکدیگر ارتباط برقرار کنند، Call Bridges به طور خودکار بین همه سرورها و کلاینت‌ها در یک Space ارتباط برقرار می‌کند، به طوری که به نظر می‌رسد همه کلاینت‌ها روی یک سرور هستند. متاسفانه، نقطه ضعف این است که یک کنفرانس 3 نفره اکنون 9 پورت رسانه را مصرف می کند. بدیهی است که این استفاده ناکارآمد از منابع است. علاوه بر این، زمانی که یک پل تماس واقعاً بیش از حد بارگذاری می‌شود، مکانیسم پیش‌فرض ادامه پذیرش تماس‌ها و ارائه خدمات با کیفیت پایین‌تر برای همه مشترکین آن پل تماس است.

این مشکلات با استفاده از قابلیت Call Bridge Group حل می شوند. این ویژگی در نسخه 2.1 نرم افزار Cisco Meeting Server معرفی شد و برای پشتیبانی از تعادل بار برای تماس های ورودی و خروجی Cisco Meeting App (CMA) از جمله شرکت کنندگان WebRTC توسعه یافته است.

برای حل مشکل اتصال مجدد، سه محدودیت بار قابل تنظیم برای هر پل تماس معرفی شده است:

LoadLimit - این حداکثر بار عددی برای یک پل تماس خاص است. هر پلتفرم دارای محدودیت بار توصیه شده است، مانند 96000 برای CMS1000 و 1.25 گیگاهرتز در هر vCPU برای ماشین مجازی. تماس‌های مختلف بسته به وضوح و نرخ فریم شرکت‌کننده، مقدار معینی از منابع را مصرف می‌کنند.
NewConferenceLoadLimitBasisPoints (پیش‌فرض 50% loadLimit) - محدودیت بار سرور را تعیین می‌کند و پس از آن کنفرانس‌های جدید رد می‌شوند.
ExistingConferenceLoadLimitBasisPoints (پیش‌فرض 80% loadLimit) - مقدار بارگذاری سرور که پس از آن شرکت‌کنندگانی که به کنفرانس موجود می‌پیوندند رد می‌شوند.

در حالی که این ویژگی برای توزیع تماس و متعادل‌سازی بار طراحی شده است، گروه‌های دیگری مانند سرورهای TURN، سرورهای پل وب و ضبط‌کننده‌ها نیز می‌توانند به گروه‌های پل تماس اختصاص داده شوند تا بتوانند برای استفاده بهینه به درستی گروه‌بندی شوند. اگر هر یک از این اشیاء به یک گروه فراخوانی اختصاص داده نشود، فرض می شود که بدون اولویت خاصی برای همه سرورها در دسترس هستند.

این پارامترها در اینجا پیکربندی می شوند: cms.example.com:445/api/v1/system/configuration/cluster

در مرحله بعد، به هر callbridge نشان می دهیم که متعلق به کدام گروه callbridge است:

اولین کال بریج

پل تماس دوم

پل تماس سوم


بنابراین، ما گروه Call Brdige را برای استفاده موثرتر از منابع خوشه سرور Cisco Meeting پیکربندی کردیم.

وارد کردن کاربران از اکتیو دایرکتوری

سرویس Web Admin یک بخش پیکربندی LDAP دارد، اما گزینه های پیکربندی پیچیده را ارائه نمی دهد و اطلاعات در پایگاه داده خوشه ذخیره نمی شود، بنابراین پیکربندی باید به صورت دستی در هر سرور از طریق رابط وب یا از طریق انجام شود. API، و به این ترتیب که «سه بار «بلند نشو»، همچنان داده‌ها را از طریق API تنظیم می‌کنیم.

استفاده از URL برای دسترسی cms01.example.com:445/api/v1/ldapServers یک شی سرور LDAP ایجاد می کند و پارامترهایی مانند:

• آی پی سرور
• شماره پورت
• نام کاربری
• رمز عبور
• امن

ایمن - بسته به پورت درست یا نادرست را انتخاب کنید، 389 - امن نیست، 636 - محافظت شده است.


نگاشت پارامترهای منبع LDAP به ویژگی ها در Cisco Meeting Server.
نقشه برداری LDAP ویژگی های موجود در فهرست LDAP را به ویژگی های موجود در CMS نگاشت می کند. صفات واقعی:

• jidMapping
• nameMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

شرح صفاتIADB نشان دهنده شناسه ورود کاربر در CMS است. از آنجایی که این یک سرور LDAP اکتیو دایرکتوری مایکروسافت است، CMS JID به sAMAccountName در LDAP، که اساساً شناسه ورود به Active Directory کاربر است، نگاشت می شود. همچنین توجه داشته باشید که sAMAccountName را انتخاب کرده و دامنه conf.pod6.cms.lab را به انتهای آن اضافه کنید زیرا این همان لاگینی است که کاربران شما برای ورود به سیستم مدیریت محتوا از آن استفاده می کنند.

nameMapping آنچه در قسمت displayName اکتیو دایرکتوری موجود است را با قسمت نام CMS کاربر مطابقت می دهد.

coSpaceNameMapping یک نام فضای CMS بر اساس فیلد displayName ایجاد می کند. این ویژگی به همراه ویژگی coSpaceUriMapping چیزی است که برای ایجاد فضایی برای هر کاربر لازم است.

coSpaceUriMapping قسمت کاربر از URI مرتبط با فضای شخصی کاربر را تعریف می کند. برخی از دامنه ها را می توان برای شماره گیری در فضا پیکربندی کرد. اگر قسمت کاربر با این فیلد برای یکی از این دامنه ها مطابقت داشته باشد، تماس به فضای آن کاربر هدایت می شود.

coSpaceSecondaryUriMapping یک URI دوم برای رسیدن به فضا تعریف می کند. این می تواند برای افزودن نام مستعار عددی برای مسیریابی تماس ها به فضای کاربر وارد شده به عنوان جایگزینی برای URI الفبایی تعریف شده در پارامتر coSpaceUriMapping استفاده شود.

سرور LDAP و نقشه برداری LDAP پیکربندی شده اند. اکنون باید آنها را با ایجاد یک منبع LDAP به یکدیگر پیوند دهید.

استفاده از URL برای دسترسی cms01.example.com:445/api/v1/ldapSource یک شی منبع LDAP ایجاد می کند و پارامترهایی مانند:

• سرور
• نقشه برداری
• baseDn
• فیلتر

اکنون که پیکربندی LDAP کامل شده است، می توانید عملیات همگام سازی دستی را انجام دهید.

ما این کار را در رابط وب هر سرور با کلیک کردن انجام می دهیم اکنون همگام سازی کنید بخش اکتیو دایرکتوری


یا از طریق API با دستور پست استفاده از URL برای دسترسی cms01.example.com:445/api/v1/ldapSyncs

کنفرانس های Ad-Hoc

این چیست؟در مفهوم سنتی، کنفرانس زمانی است که دو شرکت کننده با یکدیگر صحبت می کنند و یکی از شرکت کنندگان (با استفاده از دستگاهی که با Unified CM ثبت شده است) دکمه "کنفرانس" را فشار داده، با شخص دیگر تماس می گیرد و پس از صحبت با شخص ثالث ، دوباره دکمه "کنفرانس" را فشار دهید تا به همه شرکت کنندگان در کنفرانس سه جانبه بپیوندید.

آنچه یک کنفرانس Ad-Hoc را از یک کنفرانس برنامه ریزی شده در یک CMS متمایز می کند این است که یک کنفرانس Ad-Hoc فقط یک تماس SIP با CMS نیست. هنگامی که آغازگر کنفرانس برای بار دوم روی دکمه کنفرانس کلیک می‌کند تا همه را به یک جلسه دعوت کند، Unified CM باید یک تماس API با CMS برقرار کند تا یک کنفرانس در جریان ایجاد کند که سپس همه تماس‌ها به آن منتقل می‌شوند. همه اینها بدون توجه شرکت کنندگان اتفاق می افتد.

این بدان معناست که Unified CM باید اعتبار API و آدرس/پورت WebAdmin سرویس و همچنین SIP Trunk را مستقیماً در سرور CMS برای ادامه تماس پیکربندی کند.

در صورت لزوم، CUCM می تواند به صورت پویا یک فضای در CMS ایجاد کند تا هر تماس بتواند به CMS برسد و با قانون تماس ورودی که برای فضاها در نظر گرفته شده است مطابقت داشته باشد.

ادغام با CUCM به همان روشی که در مقاله توضیح داده شد پیکربندی شده است زودتر با این تفاوت که در Cisco UCM باید سه ترانک برای CMS، سه پل کنفرانس ایجاد کنید، در نمایه امنیتی SIP، سه نام موضوع، گروه‌های مسیر، فهرست‌های مسیر، گروه‌های منابع رسانه‌ای و فهرست‌های گروه منابع رسانه‌ای را مشخص کنید، و چند قانون مسیریابی اضافه کنید. به سرور جلسه سیسکو.

نمایه امنیتی SIP:


تنه ها:


هر تنه یکسان به نظر می رسد:




پل کنفرانس


هر پل کنفرانس یکسان به نظر می رسد:


گروه مسیر


فهرست مسیر


گروه منابع رسانه ای


فهرست گروه منابع رسانه ای

قوانین تماس

برخلاف سیستم‌های مدیریت تماس پیشرفته‌تر مانند Unified CM یا Expressway، CMS فقط دامنه را در قسمت SIP Request-URI برای تماس‌های جدید جستجو می‌کند. بنابراین اگر SIP INVITE برای جرعه جرعه است: [ایمیل محافظت شده]CMS فقط به domain.com اهمیت می دهد. CMS برای تعیین مسیریابی تماس از این قوانین پیروی می کند:

1. CMS ابتدا سعی می کند دامنه SIP را با دامنه های پیکربندی شده در قوانین تماس ورودی مطابقت دهد. سپس می‌توان این تماس‌ها را به فضاهای («هدف‌مند») یا کاربران خاص، دستگاه‌های تلفن گویا داخلی یا مقاصد Microsoft Lync/Skype for Business (S4B) که مستقیماً یکپارچه شده‌اند هدایت کرد.
2. اگر در قوانین تماس ورودی مطابقت نداشته باشد، CMS سعی می کند دامنه پیکربندی شده در جدول انتقال تماس را مطابقت دهد. اگر تطابق برقرار شود، قانون می‌تواند به صراحت تماس را رد کند یا تماس را فوروارد کند. در این زمان، CMS ممکن است دامنه را بازنویسی کند، که گاهی اوقات برای فراخوانی دامنه های Lync مفید است. شما همچنین می توانید انتخاب کنید که پرتاب را ارسال کنید، به این معنی که هیچ یک از فیلدها بیشتر تغییر نخواهند کرد، یا از برنامه شماره گیری داخلی CMS استفاده کنید. اگر در قوانین انتقال تماس مطابقت وجود نداشته باشد، پیش‌فرض رد تماس است. به خاطر داشته باشید که در CMS، اگرچه تماس "Forwarded" است، رسانه همچنان به CMS محدود است، به این معنی که در مسیر سیگنالینگ و ترافیک رسانه قرار خواهد گرفت.
سپس فقط تماس های فوروارد شده مشمول قوانین تماس خروجی هستند. این تنظیمات مقصدهایی را که تماس‌ها ارسال می‌شوند، نوع ترانک (خواه تماس جدید Lync یا یک تماس استاندارد SIP) و هرگونه تبدیلی را که می‌توان در صورت انتخاب نشدن انتقال در قانون انتقال تماس انجام داد، تعیین می‌کند.

در اینجا گزارش واقعی از آنچه در طول یک کنفرانس Ad-Hoc اتفاق می افتد است

اسکرین شات آن را ضعیف نشان می دهد (نمی دانم چگونه آن را بهتر کنم)، بنابراین گزارش را به این صورت می نویسم:

Info	127.0.0.1:35870: API user "api" created new space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call create failed to find coSpace -- attempting to retrieve from database

Info	API "001036270012" Space GUID: 7986bb6c-af4e-488d-9190-a75f16844e44 <--> Call GUID: 93bfb890-646c-4364-8795-9587bfdc55ba <--> Call Correlator GUID: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66 <--> Internal G

Info	127.0.0.1:35872: API user "api" created new call 93bfb890-646c-4364-8795-9587bfdc55ba

Info	call 7: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg bc0be45e-ce8f-411c-be04-594e0220c38e in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 has control/media GUID: fb587c12-23d2-4351-af61-d6365cbd648d

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 named "001036270012"

Info	call 7: configured - API call leg bc0be45e-ce8f-411c-be04-594e0220c38e with SIP call ID "[email protected]"

Info	call 7: setting up UDT RTP session for DTLS (combined media and control)
Info	conference "001036270012": unencrypted call legs now present

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 8: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg db61b242-1c6f-49bd-8339-091f62f5777a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	call 8: configured - API call leg db61b242-1c6f-49bd-8339-091f62f5777a with SIP call ID "[email protected]"

Info	call 8: setting up UDT RTP session for DTLS (combined media and control)

Info	call 9: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	call 9: configured - API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a with SIP call ID "[email protected]"

Info	call 9: setting up UDT RTP session for DTLS (combined media and control)
Info	call 8: compensating for far end not matching payload types

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (289e823d-6da8-486c-a7df-fe177f05e010) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 7: compensating for far end not matching payload types
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: compensating for far end not matching payload types

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (d27e9a53-2c8a-4e9c-9363-0415cd812767) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 9: BFCP (client role) now active
Info	call 9: sending BFCP hello as client following receipt of hello when BFCP not active
Info	call 9: BFCP (client role) now active
Info	call 7: ending; remote SIP teardown - connected for 0:13
Info	call 7: destroying API call leg bc0be45e-ce8f-411c-be04-594e0220c38e

Info	participant "[email protected]" left space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call 9: on hold
Info	call 9: non matching payload types mode 1/0
Info	call 9: answering offer in non matching payload types mode
Info	call 8: on hold
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: ending; remote SIP teardown - connected for 0:12

خود کنفرانس Ad-Hoc:


قوانین تماس ورودی
پیکربندی پارامترهای تماس های دریافتی برای اینکه بتوان تماسی را در CMS دریافت کرد، ضروری است. همانطور که در تنظیمات LDAP دیدید، همه کاربران با دامنه conf.pod6.cms.lab وارد شدند. بنابراین حداقل، شما می خواهید تماس هایی به این دامنه برای هدف قرار دادن فضاها انجام شود. همچنین باید قوانینی را برای هر چیزی که برای نام دامنه کاملاً واجد شرایط (و شاید حتی آدرس IP) هر یک از سرورهای CMS در نظر گرفته شده است تنظیم کنید. کنترل تماس خارجی ما، Unified CM، SIP ترانک های اختصاص داده شده به هر یک از سرورهای CMS را به صورت جداگانه پیکربندی می کند. بسته به اینکه مقصد این ترانک های SIP یک آدرس IP باشد یا FQDN سرور، تعیین می کند که آیا CMS برای پذیرش تماس های هدایت شده به آدرس IP یا FQDN آن نیاز به پیکربندی دارد.

دامنه ای که دارای بالاترین اولویت قانون ورودی است به عنوان دامنه برای هر فضای کاربری استفاده می شود. هنگامی که کاربران از طریق LDAP همگام‌سازی می‌شوند، CMS به طور خودکار فضاها را ایجاد می‌کند، اما فقط قسمت کاربر از URI (coSpaceUriMapping)، به عنوان مثال، user.space. قسمت دامنه URI کامل بر اساس این قانون تولید می شود. در واقع، اگر بخواهید در این مرحله وارد Web Bridge شوید، خواهید دید که Space URI دامنه ندارد. با تنظیم این قانون به عنوان بالاترین اولویت، دامنه را برای فضاهای تولید شده تنظیم می کنید کنتexample.com.


قوانین تماس خروجی

برای اینکه به کاربران امکان برقراری تماس های خروجی با کلاستر Unified CM را بدهید، باید قوانین خروجی را پیکربندی کنید. دامنه نقاط پایانی ثبت شده با Unified CM، مانند Jabber، example.com است. تماس‌های این دامنه باید به‌عنوان تماس‌های استاندارد SIP به گره‌های پردازش تماس واحد CM هدایت شوند. سرور اصلی cucm-01.example.com و سرور اضافی cucm-02.example.com است.

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

رشته محلی از دامنه مسئول چیزی است که در SIP-URI تماس گیرنده برای شخصی که بعد از علامت «@» با او تماس گرفته می شود، نمایش داده می شود. اگر آن را خالی بگذاریم، پس از علامت "@" آدرس IP CUCM وجود خواهد داشت که این تماس از طریق آن عبور می کند. اگر یک دامنه را مشخص کنیم، پس از نماد "@" در واقع یک دامنه وجود خواهد داشت. این برای امکان تماس مجدد ضروری است، در غیر این صورت امکان تماس از طریق SIP-URI name@ip-address وجود نخواهد داشت.

وقتی مشخص شد تماس بگیرید محلی از دامنه


کی زنگ بزن NOT نشان داد محلی از دامنه


مطمئن شوید که به صراحت برای تماس های خروجی Encrypted یا Unencrypted را مشخص کنید، زیرا هیچ چیز با پارامتر Auto کار نمی کند.

ضبط

ویدئو کنفرانس ها توسط سرور Record ضبط می شود. Recorder دقیقاً مشابه Cisco Meeting Server است. ضبط کننده نیازی به نصب هیچ مجوزی ندارد. مجوزهای ضبط برای سرورهایی که خدمات CallBridge را اجرا می کنند مورد نیاز است. مجوز ضبط مورد نیاز است و باید برای مؤلفه CallBridge اعمال شود و نه برای سروری که Recorder را اجرا می کند. ضبط‌کننده به‌عنوان یک سرویس گیرنده پیام‌رسانی و حضوری توسعه‌پذیر (XMPP) عمل می‌کند، بنابراین سرور XMPP باید در سرور میزبان CallBridge فعال شود.

زیرا ما یک خوشه داریم و مجوز باید در هر سه سرور در کلاستر "گسترش" شود. سپس به سادگی در حساب شخصی شما در مجوزها، آدرس‌های MAC رابط‌های a تمام سرورهای CMS موجود در خوشه را مرتبط می‌کنیم (اضافه می‌کنیم).

و این تصویری است که باید در هر سرور در خوشه باشد

به طور کلی، چندین سناریو برای قرار دادن Recorder وجود دارد، اما ما به این موضوع پایبند هستیم:


قبل از راه‌اندازی Recorder، باید مکانی را آماده کنید که کنفرانس‌های ویدئویی واقعاً در آن ضبط شوند. در واقع اینجا پیوند، نحوه تنظیم همه ضبط. من روی نکات و جزئیات مهم تمرکز می کنم:

1. بهتر است گواهی را از اولین سرور در کلاستر اسلپ کنید.
2. خطای "Recorder unavailable" ممکن است رخ دهد زیرا گواهی اشتباه در Recorder Trust مشخص شده است.
3. اگر دایرکتوری NFS مشخص شده برای ضبط، دایرکتوری اصلی نباشد، نوشتن ممکن است کار نکند.

گاهی اوقات نیاز به ضبط خودکار کنفرانس یک کاربر یا فضای خاص وجود دارد.

برای این کار، دو CallProfiles ایجاد می شود:
با ضبط غیر فعال


و با عملکرد ضبط خودکار


در مرحله بعد، یک CallProfile با عملکرد ضبط خودکار را به فضای مورد نیاز "ضمیمه" می کنیم.


در CMS به قدری ثابت شده است که اگر یک CallProfile به صراحت به هر فضا یا فضایی گره خورده باشد، آنگاه این CallProfile فقط در رابطه با این فضاهای خاص کار می کند. و اگر CallProfile به هیچ فاصله ای محدود نشده باشد، به طور پیش فرض برای آن فضاهایی اعمال می شود که هیچ CallProfile صراحتاً به آن محدود نشده است.

دفعه بعد سعی خواهم کرد نحوه دسترسی به CMS در خارج از شبکه داخلی سازمان را شرح دهم.

منابع:

• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-5/Cisco-Meeting-Server-2-5-Single-Combined-Server-Deployment.pdf
• www.cisco.com/c/en/us/support/docs/conferencing/meeting-server/202722-Configure-Recorder-in-CMS-Acano-Call-Bri.html
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-3/Cisco-Meeting-Server-MMP-Command-Reference-2-3.pdf
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-5/Cisco-Meeting-Server-API-Reference-Guide-2-4-and-Alter. pdf

منبع: www.habr.com