Cisco Toplantı Sunucusu 2.5.2. Video konferans kayıt işleviyle Ölçeklenebilir ve Dayanıklı modda küme

Bu sayımızda yük devretme kümesi modunda bir CMS sunucusu kurmanın bazı inceliklerini gösterip açıklayacağım.


ТеорияGenel olarak üç tür CMS sunucusu dağıtımı vardır:

• Tek Kombine(Tekli kombine), yani. bu, gerekli tüm hizmetlerin çalıştığı bir sunucudur. Çoğu durumda, bu tür dağıtım yalnızca dahili istemci erişimi için ve tek bir sunucunun ölçeklenebilirlik ve yedeklilik sınırlamalarının kritik bir sorun olmadığı daha küçük ortamlarda veya CMS'nin yalnızca geçici olarak belirli işlevleri gerçekleştirdiği durumlarda uygundur. Cisco UCM ile ilgili konferanslar.

  Yaklaşık çalışma şeması:
  

• Tek Bölünmüş(Tek Bölme), harici erişim için ayrı bir sunucu ekleyerek önceki dağıtım türünü genişletir. Eski dağıtımlarda bu, harici istemcilerin erişebileceği askerden arındırılmış bir ağ segmentinde (DMZ) bir CMS sunucusunun ve dahili istemcilerin CMS'ye erişebileceği ağ çekirdeğinde bir CMS sunucusunun konuşlandırılması anlamına geliyordu. Bu özel dağıtım modelinin yerini artık sözde tür alıyor Tek Kenarsunuculardan oluşan Cisco Ekspres Yolu, aynı Güvenlik Duvarı atlama özelliklerinin çoğuna sahip olan veya sahip olacak, böylece istemcilerin özel bir uç CMS sunucusu eklemesine gerek kalmaz.

  Yaklaşık çalışma şeması:
  

• Ölçeklenebilir ve Dayanıklı(Ölçeklenebilir ve Hata Toleranslı) Bu tür, her bileşen için yedeklilik içerir ve sistemin ihtiyaçlarınızla birlikte maksimum kapasitesine kadar büyümesine olanak tanırken arıza durumunda yedeklilik sağlar. Ayrıca güvenli harici erişim sağlamak için Tek Kenar konseptini kullanır. Bu bölümde inceleyeceğimiz tür budur. Bu tür bir kümenin nasıl dağıtılacağını anlarsak, yalnızca diğer dağıtım türlerini anlamakla kalmayıp, aynı zamanda talepteki potansiyel büyümeyi karşılamak için CMS sunucu kümelerinin nasıl oluşturulacağını da anlayabileceğiz.

Dağıtıma geçmeden önce bazı temel şeyleri anlamanız gerekir:

Ana CMS yazılım bileşenleri:

• veritabanı: Arama planı, kullanıcı alanları ve kullanıcıların kendisi gibi bazı yapılandırmaları birleştirmenize olanak tanır. Yalnızca yüksek kullanılabilirlik (tek ana) için kümelemeyi destekler.
• Çağrı Köprüsü: Çağrıların ve multimedya işlemlerinin yönetimi ve işlenmesi üzerinde tam kontrol sağlayan sesli ve görüntülü konferans hizmeti. Yüksek kullanılabilirlik ve ölçeklenebilirlik için kümelemeyi destekler.
• XMPP sunucusu: Cisco Meeting Uygulamasını ve/veya WebRTC'yi kullanan istemcilerin kaydından ve kimlik doğrulamasından sorumludur(gerçek zamanlı iletişim veya yalnızca tarayıcıda)ve ayrıca bileşenler arası sinyalizasyon. Yalnızca yüksek kullanılabilirlik için kümelenebilir.
• Web Köprüsü: WebRTC'ye istemci erişimi sağlar.
• Yük dengeleyici: Tek Bölme modunda Cisco Toplantı Uygulamaları için tek bir bağlantı noktası sağlar. Gelen bağlantılar için harici arayüzü ve bağlantı noktasını dinler. Aynı şekilde yük dengeleyici, XMPP sunucusundan gelen TLS bağlantılarını kabul eder ve bu sayede harici istemcilerden gelen TCP bağlantılarını değiştirebilir.
  Bizim senaryomuzda buna gerek kalmayacak.
• DÖNÜŞ sunucusu: Güvenlik Duvarı bypass teknolojisi sağlar.
  Cisco Toplantı Uygulaması veya SIP cihazlarını kullanarak harici istemcilere bağlanmak için CMS'mizi bir Güvenlik Duvarı veya NAT arkasına yerleştirin. Bizim senaryomuzda buna gerek kalmayacak.
• Web yöneticisi: Özel Unified CM konferansları da dahil olmak üzere yönetim arayüzü ve API erişimi.

Yapılandırma Modları

Diğer Cisco ürünlerinin çoğundan farklı olarak Cisco Meeting Server, her türlü dağıtıma uyum sağlamak için üç yapılandırma yöntemini destekler.

• Komut satırı (CLI): İlk yapılandırma ve sertifika görevleri için MMP olarak bilinen komut satırı arayüzü.
• Web Yöneticisi: Öncelikle CallBridge ile ilgili yapılandırmalar için, özellikle de kümelenmemiş tek bir sunucu kurarken.
• REST API: En karmaşık yapılandırma görevleri ve kümelenmiş veritabanıyla ilgili görevler için kullanılır.

Yukarıdakilere ek olarak, protokol kullanılır SFTP dosyaları (genellikle lisanslar, sertifikalar veya günlükler) CMS sunucusuna ve CMS sunucusundan aktarmak için.

Cisco'nun dağıtım kılavuzlarında kümenin konuşlandırılması gerektiği beyaz ve İngilizce olarak yazılmıştır. En az üç veritabanları bağlamında sunucular (düğümler). Çünkü Yeni bir Veritabanı Yöneticisi seçme mekanizması yalnızca tek sayıda düğümle çalışır ve genel olarak Veritabanı Yöneticisinin CMS sunucusu veritabanının çoğuyla bağlantısı vardır.

Ve uygulamanın gösterdiği gibi, iki sunucu (düğüm) gerçekten yeterli değil. Seçim mekanizması Ana sunucu yeniden başlatıldığında çalışır, Yardımcı sunucu ancak yeniden başlatılan sunucu açıldıktan sonra Ana sunucu haline gelir. Ancak iki sunucudan oluşan bir kümede Ana sunucu aniden kapanırsa, o zaman Slave sunucu Master olmayacak, Slave çıkarsa kalan Master sunucu Slave olacaktır.

Ancak XMPP bağlamında üç sunucudan oluşan bir kümenin bir araya getirilmesi gerçekten gerekli olacaktır, çünkü örneğin, XMMP'nin Lider durumunda olduğu sunuculardan birinde XMPP hizmetini devre dışı bırakırsanız, geri kalan sunucuda XMPP Takipçi durumunda kalacak ve XMPP'ye CallBridge bağlantıları kesilecektir çünkü CallBridge, Lider statüsüyle yalnızca XMPP'ye bağlanır. Ve bu çok kritik, çünkü... tek bir çağrı bile geçmeyecek.

Ayrıca aynı dağıtım kılavuzlarında bir XMPP sunucusuna sahip bir küme gösterilmektedir.

Yukarıdakileri dikkate aldığımızda, bunun nedeni açıkça ortaya çıkıyor: Yük devretme modunda olduğu için çalışıyor.

Bizim durumumuzda XMPP sunucusu her üç düğümde de mevcut olacaktır.

Sunucularımızın üçünün de çalışır durumda olduğu varsayılmaktadır.

DNS kayıtları

Sunucu kurulumuna başlamadan önce DNS kayıtları oluşturmanız gerekir А и SRV türleri:

DNS kayıtlarımızda example.com ve olmak üzere iki alan adı bulunduğunu lütfen unutmayın. conf.example.com. Örnek.com, tüm Cisco Tümleşik İletişim Yöneticisi abonelerinin URI'leri için kullanabileceği, büyük olasılıkla altyapınızda bulunan veya bulunması muhtemel bir etki alanıdır. Veya example.com, kullanıcıların e-posta adresleri için kullandıkları alan adının aynısıyla eşleşir. Veya dizüstü bilgisayarınızdaki Jabber istemcisinin bir URI'si olabilir [e-posta korumalı]. Alan adı conf.example.com, Cisco Toplantı Sunucusu kullanıcıları için yapılandırılacak etki alanıdır. Cisco Toplantı Sunucusunun etki alanı şu şekilde olacaktır: conf.example.com, yani aynı Jabber kullanıcısı için, Cisco Meeting Server'da oturum açmak için kullanıcı@ URI'sinin kullanılması gerekirconf.example.com.

Temel yapılandırma

Aşağıda açıklanan tüm ayarlar tek bir sunucuda gösterilmektedir ancak bunların kümedeki her sunucuda yapılması gerekir.

QoS

CMS ürettiğinden beri gerçek zaman Trafik gecikmelere ve paket kaybına duyarlı olduğundan, çoğu durumda hizmet kalitesinin (QoS) yapılandırılması önerilir. Bunu başarmak için CMS, paketleri kendi ürettiği Farklılaştırılmış Hizmet Kodlarıyla (DSCP'ler) etiketlemeyi destekler. DSCP tabanlı trafik önceliklendirmesi, trafiğin altyapınızın ağ bileşenleri tarafından nasıl işlendiğine bağlı olsa da, bizim durumumuzda CMS'mizi QoS en iyi uygulamalarına dayalı tipik DSCP önceliklendirmesi ile yapılandıracağız.

Her sunucuya bu komutları gireceğiz

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

Böylece, tüm video trafiği AF41 (DSCP 0x22) olarak işaretlendi, tüm ses trafiği EF (DSCP 0x2E) olarak işaretlendi; SIP ve XMPP gibi diğer düşük gecikmeli trafik türleri AF31 (DSCP 0x1A) kullanıyor.

Kontrol ediyoruz:

NTP

Ağ Zaman Protokolü (NTP), yalnızca aramaların ve konferansların doğru zaman damgalarını sağlamak için değil, aynı zamanda sertifikaları doğrulamak için de önemlidir.

Gibi bir komutla altyapınıza NTP sunucuları ekleyin

ntp server add <server>

Bizim durumumuzda böyle iki sunucu var, yani iki takım olacak.
Kontrol ediyoruz:

Ve sunucumuzun saat dilimini ayarlayın

DNS

Aşağıdaki gibi bir komutla DNS sunucularını CMS'ye ekliyoruz:

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

Bizim durumumuzda böyle iki sunucu var, yani iki takım olacak.
Kontrol ediyoruz:

Ağ Arayüzü Yapılandırması

Arayüzü aşağıdaki gibi bir komutla yapılandırıyoruz:

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

Kontrol ediyoruz:

Sunucu adı (Ana Bilgisayar Adı)

Sunucu adını aşağıdaki gibi bir komutla belirliyoruz:

hostname <name>

Ve yeniden başlatıyoruz.


Bu, temel yapılandırmayı tamamlar.

Sertifikalar

ТеорияCisco Toplantı Sunucusu, çeşitli bileşenler arasında şifreli iletişim gerektirir ve sonuç olarak tüm CMS dağıtımları için X.509 sertifikaları gerekir. Hizmetlere/sunucuya diğer sunucular/hizmetler tarafından güvenilmesini sağlamaya yardımcı olurlar.

Her hizmet bir sertifika gerektirir ancak her hizmet için ayrı sertifikalar oluşturmak kafa karışıklığına ve gereksiz karmaşıklığa yol açabilir. Neyse ki, bir sertifikanın genel-özel anahtar çiftini oluşturabilir ve bunları birden fazla hizmette yeniden kullanabiliriz. Bizim durumumuzda Call Bridge, XMPP Server, Web Bridge ve Web Admin için aynı sertifika kullanılacaktır. Bu nedenle, kümedeki her sunucu için bir çift genel ve özel sertifika anahtarı oluşturmanız gerekir.

Ancak veritabanı kümelemenin bazı özel sertifika gereksinimleri vardır ve bu nedenle diğer hizmetlerden farklı olan kendi sertifikalarını gerektirir. CMS, diğer sunucuların kullandığı sertifikalara benzer bir sunucu sertifikası kullanır ancak veritabanı bağlantıları için kullanılan bir istemci sertifikası da vardır. Veritabanı sertifikaları hem kimlik doğrulama hem de şifreleme için kullanılır. İstemcinin veritabanına bağlanması için kullanıcı adı ve parola sağlamak yerine, sunucunun güvendiği bir istemci sertifikası sunar. Veritabanı kümesindeki her sunucu aynı genel ve özel anahtar çiftini kullanacaktır. Bu, kümedeki tüm sunucuların verileri yalnızca aynı anahtar çiftini paylaşan diğer sunucular tarafından çözülebilecek şekilde şifrelemesine olanak tanır.

Artıklığın işe yaraması için, veritabanı kümeleri en az 3 sunucudan oluşmalı, ancak en fazla 5 sunucudan oluşmalı ve herhangi bir küme üyesi arasında maksimum gidiş-dönüş süresi 200 ms olmalıdır. Bu sınır, Call Bridge kümelemesinden daha kısıtlayıcı olduğundan coğrafi olarak dağıtılmış dağıtımlarda genellikle sınırlayıcı faktördür.

Bir CMS'nin veritabanı rolünün bir takım benzersiz gereksinimleri vardır. Diğer rollerden farklı olarak, istemci sertifikasının sunucuya sunulan belirli bir CN alanına sahip olduğu bir istemci ve sunucu sertifikası gerektirir.

CMS, bir ana kopya ve birkaç tamamen aynı kopyadan oluşan bir postgres veritabanı kullanır. Aynı anda yalnızca bir birincil veritabanı vardır (“veritabanı sunucusu”). Kümenin geri kalan üyeleri kopyalar veya "veritabanı istemcileridir".

Bir veritabanı kümesi, özel bir sunucu sertifikası ve bir istemci sertifikası gerektirir. Genellikle dahili bir özel sertifika yetkilisi olan sertifikalar tarafından imzalanmaları gerekir. Veritabanı kümesinin herhangi bir üyesi ana yönetici olabileceğinden, veritabanı sunucusu ve istemci sertifikası çiftlerinin (genel ve özel anahtarları içeren), istemcinin veya veritabanı sunucusunun kimliğini üstlenebilmeleri için tüm sunuculara kopyalanması gerekir. Ayrıca istemci ve sunucu sertifikalarının doğrulanabilmesini sağlamak için CA kök sertifikasının da yüklenmesi gerekir.

Böylece aşağıdaki gibi bir komutla veritabanı dışındaki tüm sunucu servislerinin kullanacağı bir sertifika isteği oluşturuyoruz (bunun için ayrı bir istek olacak)

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

CN'de sunucularımızın genel adını yazıyoruz. Örneğin, sunucularımızın ana bilgisayar adları server01, server02, server03, o zaman CN olacak sunucu.example.com

Komutların ilgili "ana bilgisayar adlarını" içermesi farkıyla geri kalan iki sunucuda da aynısını yapıyoruz.

Veritabanı hizmeti tarafından kullanılacak sertifikalar için aşağıdaki gibi komutlarla iki istek oluşturuyoruz:

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

pki csr dbclusterclient CN:postgres

nerede dbclusterserver и dbclusterclient Taleplerimizin adları ve gelecekteki sertifikalarımız, ana bilgisayar adı1(2)(3) ilgili sunucuların adları.

Bu işlemi yalnızca bir sunucuda (!) gerçekleştiriyoruz ve sertifikaları ve ilgili .key dosyalarını diğer sunuculara yükleyeceğiz.

AD CS'de istemci sertifikası modunu etkinleştirin

Ayrıca her sunucunun sertifikalarını tek bir dosyada birleştirmeniz gerekir.*NIX'te:

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

Windows/DOS'ta:

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

Ve her sunucuya yükleyin:
1. “Bireysel” sunucu sertifikası.
2. Kök sertifika (varsa ara sertifikalarla birlikte).
3. "Sunucu" ve "istemci" veritabanı sertifikaları için bir istek oluşturulurken oluşturulan veritabanı ("sunucu" ve "istemci") sertifikaları ve .key uzantılı dosyalar. Bu dosyalar tüm sunucularda aynı olmalıdır.
4. Üç “bireysel” sertifikanın tümünün dosyası.

Sonuç olarak, her sunucuda bu dosya resmine benzer bir şey elde etmelisiniz.

Veritabanı Kümesi

Artık CMS sunucularına yüklenen tüm sertifikalara sahip olduğunuza göre, üç düğüm arasında veritabanı kümelemesini yapılandırabilir ve etkinleştirebilirsiniz. İlk adım, veritabanı kümesinin ana düğümü olarak bir sunucuyu seçmek ve onu tamamen yapılandırmaktır.

Ana Veritabanı

Veritabanı çoğaltmasını ayarlamanın ilk adımı, veritabanı için kullanılacak sertifikaları belirlemektir. Bu, aşağıdaki gibi bir komut kullanılarak yapılır:

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

Şimdi CMS’e veritabanı kümeleme için hangi arayüzü kullanacağını şu komutla anlatalım:

database cluster localnode a

Daha sonra ana sunucu üzerinde Cluster veritabanını şu komutla başlatıyoruz:

database cluster initialize

İstemci Veritabanı Düğümleri

Aynı işlemi yalnızca komut yerine yapıyoruz veritabanı kümesi başlatılıyor şöyle bir komut girin:

database cluster join <ip address existing master>

burada ip adresi kümenin başlatıldığı CMS sunucusunun mevcut ana ip adresidir, kısaca Master.

Veritabanı kümemizin tüm sunucularda nasıl çalıştığını şu komutla kontrol ediyoruz:

database cluster status

Aynısını kalan üçüncü sunucuda da yapıyoruz.

Sonuç olarak ilk sunucumuzun Master, geri kalanının Slave olduğu ortaya çıkıyor.

Web Yönetici Hizmeti

Web yöneticisi hizmetini etkinleştirin:

webadmin listen a 445

Bağlantı noktası 445, web istemcisine kullanıcı erişimi için bağlantı noktası 443 kullanıldığından seçildi

Web Admin hizmetini aşağıdaki gibi bir komutla sertifika dosyalarıyla yapılandırıyoruz:

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

Ve Web Admin'i şu komutla etkinleştirin:

webadmin enable

Her şey yolundaysa, Web Admin'in ağ ve sertifika için doğru şekilde yapılandırıldığını gösteren BAŞARI satırları alacağız. Hizmetin işlevselliğini bir web tarayıcısı kullanarak kontrol ediyoruz ve web yöneticisinin adresini giriyoruz, örneğin: cms.example.com: 445

Köprü Kümesini Çağır

Call Bridge, her CMS dağıtımında mevcut olan tek hizmettir. Çağrı Köprüsü ana konferans mekanizmasıdır. Ayrıca, çağrıların örneğin bir Cisco Unified CM tarafından kendisine veya buradan yönlendirilebilmesi için bir SIP arayüzü de sağlar.

Aşağıda açıklanan komutlar, uygun sertifikalara sahip her sunucuda çalıştırılmalıdır.
Yani:

Sertifikaları Call Bridge hizmetiyle aşağıdaki gibi bir komutla ilişkilendiririz:

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

CallBridge servislerini ihtiyacımız olan arayüze şu komutla bağlıyoruz:

callbridge listen a

Ve hizmeti şu komutla yeniden başlatın:

callbridge restart

Artık Çağrı Köprülerimizi yapılandırdığımıza göre Çağrı Köprüsü kümelemesini yapılandırabiliriz. Çağrı Köprüsü kümelemesi veritabanı veya XMPP kümelemesinden farklıdır. Call Bridge Cluster herhangi bir kısıtlama olmaksızın 2 ila 8 düğümü destekleyebilir. Yalnızca yedekleme sağlamakla kalmaz, aynı zamanda yük dengelemeyi de sağlar, böylece akıllı çağrı dağıtımı kullanılarak konferanslar Call Bridge sunucuları arasında aktif olarak dağıtılabilir. CMS, daha fazla yönetim için kullanılabilecek ek özelliklere, Çağrı Köprüsü gruplarına ve ilgili özelliklere sahiptir.

Çağrı köprüsü kümelemesi öncelikle web yöneticisi arayüzü aracılığıyla yapılandırılır
Aşağıda açıklanan prosedür, kümedeki her sunucuda gerçekleştirilmelidir.
Bu durumda,

1. Web üzerinden Yapılandırma > Küme'ye gidin.
2. Köprü kimliğini ara Benzersiz ad olarak sunucu adına karşılık gelen çağrı köprüsünü[01,02,03] girin. Bu adlar isteğe bağlıdır ancak bu küme için benzersiz olmalıdır. Doğası gereği açıklayıcıdırlar çünkü sunucu tanımlayıcıları olduklarını belirtirler [01,02,03].
3.B Kümelenmiş Çağrı Köprüleri sunucularımızın web yönetici URL'lerini kümeye girin, cms[01,02,03].example.com:445, Adres alanında. Bağlantı noktasını belirttiğinizden emin olun. Eş bağlantısı SIP alanını boş bırakabilirsiniz.
4. Her sunucunun CallBridge güvenine, başlangıçta bu dosyaya birleştirdiğimiz sunucularımızın tüm sertifikalarını içeren bir sertifikayı aşağıdaki gibi bir komutla ekleyin:

callbridge trust cluster <trusted cluster certificate bundle>

Ve hizmeti şu komutla yeniden başlatın:

callbridge restart

Sonuç olarak, her sunucuda şu resmi görmelisiniz:

XMPP Kümesi

CMS'deki XMPP hizmeti, CMA WebRTC web istemcisi de dahil olmak üzere Cisco Meeting Apps (CMA) için tüm kayıt ve kimlik doğrulama işlemlerini gerçekleştirmek için kullanılır. Çağrı Köprüsü'nün kendisi de kimlik doğrulama amacıyla bir XMPP istemcisi görevi görür ve bu nedenle diğer istemciler gibi yapılandırılmalıdır. XMPP hata toleransı, sürüm 2.1'den beri üretim ortamlarında desteklenen bir özelliktir.

Aşağıda açıklanan komutlar, uygun sertifikalara sahip her sunucuda çalıştırılmalıdır.
Yani:

Sertifikaları XMPP hizmetiyle aşağıdaki gibi bir komutla ilişkilendiririz:

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

Ardından dinleme arayüzünü şu komutla tanımlayın:

xmpp listen a

XMPP hizmeti benzersiz bir etki alanı gerektirir. Bu kullanıcılar için giriş bilgileridir. Başka bir deyişle, bir kullanıcı CMA uygulamasını kullanarak (veya WebRTC istemcisi aracılığıyla) oturum açmaya çalıştığında userID@logindomain adresini girer. Bizim durumumuzda userid@ olacaktır.conf.example.com. Neden sadece example.com değil? Özel dağıtımımızda, Jabber kullanıcılarının Unified CM'de kullanacağı Unified CM etki alanımızı example.com olarak seçtik, bu nedenle CMS kullanıcılarının çağrıları SIP etki alanları aracılığıyla CMS'ye ve CMS'den yönlendirmesi için farklı bir etki alanına ihtiyacımız vardı.

Aşağıdaki gibi bir komut kullanarak bir XMPP etki alanı kurun:

xmpp domain <domain>

Ve XMPP hizmetini şu komutla etkinleştirin:

xmpp enable

XMPP hizmetinde, XMPP hizmetine kaydolurken kullanılacak her Çağrı Köprüsü için kimlik bilgileri oluşturmanız gerekir. Bu adlar isteğe bağlıdır (ve çağrı köprüsü kümelemesi için yapılandırdığınız benzersiz adlarla ilişkili değildir). Bu yapılandırma küme veritabanına uymadığından, bir XMPP sunucusuna üç çağrı köprüsü eklemeniz ve ardından bu kimlik bilgilerini kümedeki diğer XMPP sunucularına girmeniz gerekir. Daha sonra her Çağrı Köprüsünü, XMPP hizmetine kaydolmak için bu adı ve sırrı kullanacak şekilde yapılandıracağız.

Şimdi ilk sunucuda XMPP hizmetini üç Çağrı Köprüsü callbridge01, callbridge02 ve callbridge03 ile yapılandırmamız gerekiyor. Her hesaba rastgele şifreler atanacaktır. Daha sonra bu XMPP sunucusunda oturum açmak için diğer Call Bridge sunucularına girilecekler. Aşağıdaki komutları girin:

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

Sonuç olarak, komutla ne olduğunu kontrol ediyoruz:

xmpp callbridge list

Aşağıda açıklanan adımlardan sonra kalan sunucularda tam olarak aynı resim görünmelidir.

Daha sonra kalan iki sunucuya da tamamen aynı ayarları yalnızca komutlarla ekliyoruz.

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

Secret'ı çok dikkatli bir şekilde ekliyoruz ki örneğin içinde fazladan boşluk kalmasın.


Sonuç olarak, her sunucunun aynı resme sahip olması gerekir:

Daha sonra, kümedeki tüm sunucularda, daha önce aşağıdaki gibi bir komutla oluşturulan, üç sertifikanın tümünü içeren dosyayı güven içinde belirtiriz:

xmpp cluster trust <trust bundle>

Xmpp küme modunu tüm küme sunucularında şu komutla etkinleştiriyoruz:

xmpp cluster enable

Kümenin ilk sunucusunda xmpp kümesinin oluşturulmasını şu komutla başlatıyoruz:

xmpp cluster initialize

Diğer sunucularda, aşağıdaki gibi bir komutla xmpp'ye bir küme ekleyin:

xmpp cluster join <ip address head xmpp server>

Her sunucuda bir XMPP kümesi oluşturma başarısını şu komutlarla kontrol ediyoruz:

xmpp status
xmpp cluster status

İlk sunucu:

İkinci Server:

Üçüncü sunucu:

Çağrı Köprüsünü XMPP'ye Bağlama

Artık XMPP kümesi çalıştığına göre, XMPP kümesine bağlanmak için Çağrı Köprüsü hizmetlerini yapılandırmanız gerekir. Bu yapılandırma web yöneticisi aracılığıyla yapılır.

Her sunucuda Yapılandırma > Genel'e gidin ve alana gidin Benzersiz Çağrı Köprüsü adı sunucuya Çağrı Köprüsü'ne karşılık gelen benzersiz adlar yazın çağrı köprüsü[01,02,03]... alanında domain conf.example.ru ve karşılık gelen şifreleri gözetleyebilirsiniz.
kümedeki herhangi bir sunucuda şu komutla:

xmpp callbridge list

“Sunucu” alanını boş bırakın çağrı köprüsü için bir DNS SRV araması gerçekleştirecek _xmpp-bileşeni._tcp.conf.example.comKullanılabilir bir XMPP sunucusu bulmak için. Çağrı köprülerini XMPP'ye bağlamak için kullanılan IP adresleri her sunucuda farklılık gösterebilir; bu, kayıt isteğine hangi değerlerin döndürüldüğüne bağlıdır _xmpp-bileşeni._tcp.conf.example.com çağrı köprüsü, bu da belirli bir DNS kaydının öncelik ayarlarına bağlıdır.

Daha sonra Call Bride hizmetinin XMPP hizmetine başarıyla bağlanıp bağlanmadığını doğrulamak için Durum > Genel'e gidin.

Web Köprüsü

Kümedeki her sunucuda Web Köprüsü hizmetini şu komutla etkinleştirin:

webbridge listen a:443

Web Bridge hizmetini aşağıdaki gibi bir komutla sertifika dosyalarıyla yapılandırıyoruz:

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

Web Köprüsü HTTPS'yi destekler. "http-redirect" kullanacak şekilde yapılandırılmışsa HTTP'yi HTTPS'ye yönlendirecektir.
HTTP yeniden yönlendirmesini etkinleştirmek için aşağıdaki komutu kullanın:

webbridge http-redirect enable

Call Bridge'in Web Bridge'in Call Bridge'den gelen bağlantılara güvenebileceğini bilmesini sağlamak için şu komutu kullanın:

webbridge trust <certfile>

burada bu, kümedeki her sunucudaki üç sertifikanın tümünü içeren bir dosyadır.

Bu resim kümedeki her sunucuda bulunmalıdır.


Artık “appadmin” rolünde bir kullanıcı oluşturmamız gerekiyor, buna ihtiyacımız var ki kümemizi(!) yapılandırabilelim, kümedeki her sunucuyu ayrı ayrı değil, bu şekilde ayarlar her sunucuya eşit olarak uygulanacaktır. bir kez yapılacakları gerçeği.


Daha fazla kurulum için kullanacağız Postacı.

Yetkilendirme için Yetkilendirme bölümünde Temel'i seçin

Komutları CMS sunucusuna doğru şekilde göndermek için gerekli kodlamayı ayarlamanız gerekir.

Webbridge komutunu şu komutla belirliyoruz: POST parametreli url ve anlam cms.example.com



Web köprüsünün kendisinde gerekli parametreleri belirtiyoruz: misafir erişimi, korumalı erişim vb.

Köprü Gruplarını Ara

Varsayılan olarak CMS, kendisine sunulan konferans kaynaklarının her zaman en verimli şekilde kullanılmasını sağlamaz.

Örneğin, üç katılımcılı bir toplantı için her katılımcı üç farklı Çağrı Köprüsüne girebilir. Bu üç katılımcının birbirleriyle iletişim kurabilmesi için Call Bridges, aynı Alandaki tüm sunucular ve istemciler arasında otomatik olarak bağlantı kuracak ve böylece tüm istemciler aynı sunucudaymış gibi görünecek. Ne yazık ki bunun dezavantajı, 3 kişilik tek bir konferansın artık 9 medya bağlantı noktasını kullanmasıdır. Bu açıkça kaynakların verimsiz kullanımıdır. Ek olarak, bir Çağrı Köprüsü gerçekten aşırı yüklendiğinde, varsayılan mekanizma, çağrıları kabul etmeye devam etmek ve o Çağrı Köprüsü'nün tüm abonelerine düşük kalitede hizmet sağlamaktır.

Bu sorunlar Çağrı Köprü Grubu özelliği kullanılarak çözülür. Bu özellik, Cisco Meeting Server yazılımının 2.1 sürümünde tanıtıldı ve WebRTC katılımcıları da dahil olmak üzere hem gelen hem de giden Cisco Meeting Uygulaması (CMA) çağrıları için yük dengelemeyi destekleyecek şekilde genişletildi.

Yeniden bağlanma sorununu çözmek amacıyla her Çağrı Köprüsü için yapılandırılabilir üç yük sınırı getirildi:

Yükleme limiti — bu, belirli bir Çağrı Köprüsü için maksimum sayısal yüktür. Her platformun, CMS96000 için 1000 ve sanal makine için vCPU başına 1.25 GHz gibi önerilen bir yük sınırı vardır. Farklı çağrılar, katılımcının çözünürlüğüne ve kare hızına bağlı olarak belirli miktarda kaynak tüketir.
YeniKonferansYükLimitTemelPuan (varsayılan %50 loadLimit) - sunucu yükleme sınırını ayarlar ve sonrasında yeni konferanslar reddedilir.
MevcutKonferansYükLimitTemelPuan (varsayılan loadLimit'in %80'i) - mevcut bir konferansa katılan katılımcıların reddedileceği sunucu yükleme değeri.

Bu özellik çağrı dağıtımı ve yük dengeleme için tasarlanmış olsa da, TURN Sunucuları, Web Köprü Sunucuları ve Kaydedicileri gibi diğer gruplar da Çağrı Köprüsü Gruplarına atanarak optimum kullanım için uygun şekilde gruplandırılabilirler. Bu nesnelerden herhangi biri bir çağrı grubuna atanmamışsa, bunların herhangi bir öncelik olmaksızın tüm sunucularda mevcut olduğu varsayılır.

Bu parametreler burada yapılandırılır: cms.example.com:445/api/v1/sistem/yapılandırma/küme

Daha sonra, her bir çağrı köprüsüne hangi çağrı köprüsü grubuna ait olduğunu belirtiriz:

İlk çağrı köprüsü

İkinci çağrı köprüsü

Üçüncü çağrı köprüsü


Böylece Call Brdige grubunu Cisco Meeting Server kümesinin kaynaklarını daha verimli kullanacak şekilde yapılandırdık.

Kullanıcıları Active Directory'den içe aktarma

Web Admin hizmetinin bir LDAP yapılandırma bölümü vardır, ancak karmaşık yapılandırma seçenekleri sağlamaz ve bilgiler küme veritabanında saklanmaz; bu nedenle yapılandırmanın, Web arayüzü aracılığıyla her sunucuda manuel olarak veya aracılığıyla yapılması gerekecektir. API ve böylece “üç kez “Kalkmayın” diye yine de API aracılığıyla verileri ayarlayacağız.

Erişmek için URL kullanma cms01.example.com:445/api/v1/ldapServers, aşağıdaki gibi parametreleri belirterek bir LDAP Sunucusu nesnesi oluşturur:

• sunucu IP'si
• Port numarası
• Kullanıcı adı
• şifre
• güvenli

Güvenli - bağlantı noktasına bağlı olarak doğru veya yanlışı seçin, 389 - güvenli değil, 636 - korumalı.


LDAP kaynak parametrelerini Cisco Meeting Server'daki niteliklerle eşleme.
LDAP eşlemesi, LDAP dizinindeki öznitelikleri CMS'deki özniteliklerle eşler. Gerçek nitelikler:

• jid Eşleme
• isimEşleme
• coSpaceNameEşleme
• coSpaceUriHaritalama
• coSpaceİkincilUriHaritalama

Niteliklerin açıklamasıJID CMS'de kullanıcının oturum açma kimliğini temsil eder. Bu bir Microsoft Active Directory LDAP sunucusu olduğundan, CMS JID, esasen kullanıcının Active Directory oturum açma kimliği olan LDAP'deki sAMAccountName ile eşleşir. Ayrıca sAMAccountName'i alıp sonuna conf.pod6.cms.lab alan adını eklediğinizi unutmayın; çünkü bu, kullanıcılarınızın CMS'de oturum açmak için kullanacağı oturum açma adıdır.

isimEşleme Active Directory displayName alanında bulunanları kullanıcının CMS adı alanıyla eşleştirir.

coSpaceNameEşleme displayName alanını temel alarak bir CMS alanı adı oluşturur. Bu öznitelik, coSpaceUriMapping özniteliğiyle birlikte her kullanıcı için bir alan oluşturmak için gerekli olan özniteliktir.

coSpaceUriHaritalama URI'nin kullanıcının kişisel alanıyla ilişkili kullanıcı kısmını tanımlar. Bazı etki alanları uzaya çevrilecek şekilde yapılandırılabilir. Kullanıcı kısmı bu alan adlarından biri için bu alanla eşleşirse çağrı o kullanıcının alanına yönlendirilecektir.

coSpaceİkincilUriHaritalama uzaya ulaşmak için ikinci bir URI tanımlar. Bu, çağrıları içe aktarılan kullanıcının alanına yönlendirmek için coSpaceUriMapping parametresinde tanımlanan alfasayısal URI'ye alternatif olarak sayısal bir takma ad eklemek için kullanılabilir.

LDAP sunucusu ve LDAP eşlemesi yapılandırılmıştır. Şimdi bir LDAP kaynağı oluşturarak bunları birbirine bağlamanız gerekiyor.

Erişmek için URL kullanma cms01.example.com:445/api/v1/ldapSource aşağıdaki gibi parametreleri belirterek bir LDAP Kaynağı nesnesi oluşturur:

• sunucu
• haritalama
• temelDn
• filtre

Artık LDAP yapılandırması tamamlandığına göre manuel senkronizasyon işlemini gerçekleştirebilirsiniz.

Bunu her sunucunun Web arayüzünde tıklayarak yaparız. Şimdi senkronize et bölüm Active Directory


veya API aracılığıyla komutla POST erişmek için URL kullanma cms01.example.com:445/api/v1/ldapSyncs

Geçici konferanslar

Bu nedir?Geleneksel konseptte konferans, iki katılımcının birbiriyle konuşması ve katılımcılardan birinin (Unified CM'ye kayıtlı bir cihazı kullanarak) "Konferans" düğmesine basması, diğer kişiyi araması ve ardından üçüncü tarafla konuşmasıdır. , üçlü konferanstaki tüm katılımcıları birleştirmek için tekrar "Konferans" düğmesine basar.

Bir Geçici konferansı bir CMS'deki planlanmış bir konferanstan ayıran şey, Özel bir konferansın yalnızca CMS'ye yapılan bir SIP çağrısı olmamasıdır. Konferansı başlatan, herkesi aynı toplantıya davet etmek için Konferans düğmesini ikinci kez tıklattığında, Unified CM'nin daha sonra tüm çağrıların aktarılacağı bir anında konferans oluşturmak için CMS'ye bir API çağrısı yapması gerekir. Bütün bunlar katılımcılar tarafından fark edilmeden gerçekleşir.

Bu, Unified CM'nin aramaya devam etmek için hizmetin API kimlik bilgilerini ve WebAdmin adresini/bağlantı noktasının yanı sıra SIP Hattını doğrudan CMS sunucusuna yapılandırması gerektiği anlamına gelir.

Gerekirse CUCM, her çağrının CMS'ye ulaşabilmesi ve boşluklara yönelik gelen çağrı kuralıyla eşleşebilmesi için CMS'de dinamik olarak bir alan oluşturabilir.

CUCM ile entegrasyon makalede açıklandığı şekilde yapılandırılmıştır daha erken ancak Cisco UCM'de CMS için üç hat, üç Konferans Köprüsü oluşturmanız, SIP Güvenlik Profilinde üç Konu Adı, Rota Grupları, Rota Listeleri, Medya Kaynak Grupları ve Medya Kaynak Grup Listeleri belirtmeniz ve birkaç yönlendirme kuralı eklemeniz gerekir. Cisco Toplantı Sunucusuna.

SIP Güvenlik Profili:


Sandıklar:


Her gövde aynı görünüyor:




Konferans köprüsü


Her Konferans Köprüsü aynı görünür:


Rota Grubu


Rota Listesi


Medya Kaynak Grubu


Medya Kaynağı Grubu Listesi

Çağrı Kuralları

Unified CM veya Expressway gibi daha gelişmiş çağrı yönetimi sistemlerinden farklı olarak CMS, yeni çağrılar için yalnızca SIP İsteği-URI alanındaki etki alanını arar. Yani SIP INVITE yudum içinse: [e-posta korumalı]CMS yalnızca domain.com'u önemser. CMS, bir çağrının nereye yönlendirileceğini belirlemek için şu kuralları izler:

1. CMS öncelikle SIP etki alanını, gelen çağrı kurallarında yapılandırılan etki alanlarıyla eşleştirmeye çalışır. Bu çağrılar daha sonra ("hedefli") alanlara veya belirli kullanıcılara, dahili IVR'lere veya doğrudan entegre Microsoft Lync/Skype for Business (S4B) hedeflerine yönlendirilebilir.
2. Gelen çağrı kurallarında eşleşme yoksa CMS, çağrı yönlendirme tablosunda yapılandırılan alan adını eşleştirmeye çalışacaktır. Bir eşleşme yapılırsa kural, çağrıyı açıkça reddedebilir veya çağrıyı iletebilir. Şu anda CMS etki alanını yeniden yazabilir ve bu bazen Lync etki alanlarını çağırmak için yararlı olabilir. Ayrıca, hiçbir alanın daha fazla değiştirilmeyeceği anlamına gelen pas atmayı veya dahili bir CMS arama planı kullanmayı da seçebilirsiniz. Çağrı yönlendirme kurallarında eşleşme yoksa, varsayılan seçenek çağrının reddedilmesidir. CMS'de çağrı "yönlendirilmiş" olmasına rağmen medyanın hala CMS'ye bağlı olduğunu, bunun da sinyalizasyon ve medya trafiği yolunda olacağı anlamına geldiğini unutmayın.
Bu durumda yalnızca yönlendirilen çağrılar giden çağrı kurallarına tabidir. Bu ayarlar, çağrıların gönderildiği hedefleri, hat türünü (yeni bir Lync çağrısı mı yoksa standart bir SIP çağrısı mı olduğunu) ve çağrı iletme kuralında aktarım seçilmemişse gerçekleştirilebilecek tüm dönüştürmeleri belirler.

İşte geçici bir konferans sırasında olup bitenlerin gerçek günlüğü

Ekran görüntüsü bunu kötü gösteriyor (nasıl daha iyi hale getireceğimi bilmiyorum), bu yüzden günlüğü şu şekilde yazacağım:

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

Geçici konferansın kendisi:


Gelen Arama Kuralları
CMS'de çağrı alabilmek için gelen çağrıların parametrelerini yapılandırmak gerekir. LDAP kurulumunda gördüğünüz gibi tüm kullanıcılar conf.pod6.cms.lab alanıyla içe aktarıldı. Yani en azından bu alana yapılan çağrıların alanları hedeflemesini istiyorsunuz. Ayrıca her bir CMS sunucusunun tam etki alanı adına (ve hatta IP adresine) yönelik her şey için kurallar ayarlamanız gerekecektir. Harici çağrı kontrolümüz Unified CM, CMS sunucularının her birine ayrılmış SIP hatlarını ayrı ayrı yapılandıracaktır. Bu SIP hatlarının hedefinin bir IP adresi mi yoksa sunucunun FQDN'si mi olduğuna bağlı olarak, CMS'nin kendi IP adresine veya FQDN'sine yönlendirilen çağrıları kabul edecek şekilde yapılandırılması gerekip gerekmediğini belirleyecektir.

En yüksek öncelikli gelen kuralına sahip olan alan adı, tüm kullanıcı alanları için alan adı olarak kullanılır. Kullanıcılar LDAP aracılığıyla senkronizasyon yaptığında, CMS otomatik olarak alanlar oluşturur, ancak bu alanlar yalnızca URI'nin kullanıcı kısmıdır (coSpaceUriMapping), örneğin user.space. Parça domain Tam URI bu kurala göre oluşturulur. Hatta bu noktada Web Bridge'e giriş yapacak olsanız Space URI'nin bir etki alanına sahip olmadığını görürsünüz. Bu kuralı en yüksek öncelik olarak ayarladığınızda, oluşturulan alanların etki alanını ayarlamış olursunuz. konf.örnek.com.


Giden Arama Kuralları

Kullanıcıların Unified CM kümesine giden aramalar yapmasına izin vermek için giden kuralları yapılandırmanız gerekir. Jabber gibi Unified CM'ye kayıtlı uç noktaların etki alanı example.com'dur. Bu etki alanına yapılan çağrılar, standart SIP çağrıları gibi Unified CM çağrı işleme düğümlerine yönlendirilmelidir. Ana sunucu cucm-01.example.com, ek sunucu ise cucm-02.example.com'dur.

İlk kural, çağrıların küme sunucuları arasında en basit şekilde yönlendirilmesini açıklar.

Tarla Etki alanından yerel Arayanın SIP-URI'sinde “@” simgesinden sonra aranan kişi için neyin görüntüleneceğinden sorumludur. Boş bırakırsak “@” simgesinden sonra bu çağrının geçtiği CUCM’nin IP adresi gelecektir. Bir alan adı belirtirsek, “@” sembolünden sonra aslında bir alan adı olacaktır. Geri arama yapabilmek için bu gereklidir, aksi takdirde SIP-URI name@ip-address aracılığıyla geri arama mümkün olmayacaktır.

Belirtildiğinde ara Etki alanından yerel


Ne zaman ara DEĞİL belirtilen Etki alanından yerel


Otomatik parametresiyle hiçbir şey çalışmadığından, giden çağrılar için açıkça Şifreli veya Şifresiz'i belirttiğinizden emin olun.

Kayıt

Video konferanslar Kayıt sunucusu tarafından kaydedilir. Kaydedici, Cisco Toplantı Sunucusu ile tamamen aynıdır. Kaydedici herhangi bir lisansın kurulumunu gerektirmez. CallBridge hizmetlerini çalıştıran sunucular için kayıt lisansları gereklidir; Kayıt lisansı gereklidir ve Kaydediciyi çalıştıran sunucuya değil, CallBridge bileşenine uygulanmalıdır. Kaydedici, Genişletilebilir Mesajlaşma ve Durum Protokolü (XMPP) istemcisi gibi davrandığından, XMPP sunucusunun CallBridge'i barındıran sunucuda etkinleştirilmesi gerekir.

Çünkü Bir kümemiz var ve lisansın kümedeki üç sunucunun tümüne "genişletilmesi" gerekiyor. Daha sonra kişisel hesabınızdaki lisanslara, kümeye dahil olan tüm CMS sunucularının a-arayüzlerinin MAC adreslerini ilişkilendiririz (ekleriz).

Ve bu da kümedeki her sunucuda olması gereken resim

Genel olarak, Kaydediciyi yerleştirmek için birkaç senaryo vardır, ancak biz buna bağlı kalacağız:


Kaydediciyi kurmadan önce video konferansların gerçekten kaydedileceği bir yer hazırlamanız gerekir. Aslında burada bağlantı, tüm Kayıtların nasıl kurulacağı. Önemli noktalara ve ayrıntılara odaklanıyorum:

1. Sertifikayı kümedeki ilk sunucudan kaydırmak daha iyidir.
2. Kaydedici Güveninde yanlış sertifika belirtildiği için "Kaydedici kullanılamıyor" hatası oluşabilir.
3. Kayıt için belirlenen NFS dizini kök dizin değilse yazma işlemi çalışmayabilir.

Bazen belirli bir kullanıcının veya alanın konferansını otomatik olarak kaydetmeye ihtiyaç duyulur.

Bunun için iki Çağrı Profili oluşturulur:
Kayıt devre dışıyken


Ve otomatik kayıt fonksiyonu ile


Daha sonra, otomatik kayıt işlevine sahip bir Çağrı Profilini gerekli alana "ekliyoruz".


CMS'de, eğer bir CallProfile açıkça herhangi bir alana veya alana bağlıysa, bu CallProfile yalnızca bu belirli alanlarla ilişkili olarak çalışacak şekilde kurulmuştur. Ve eğer CallProfile herhangi bir alana bağlı değilse, o zaman varsayılan olarak hiçbir CallProfile'ın açıkça bağlı olmadığı alanlara uygulanır.

Bir dahaki sefere CMS'ye kuruluşun iç ağı dışından nasıl erişildiğini anlatmaya çalışacağım.

Kaynaklar:

• 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-later. pdf

Kaynak: habr.com