Browsed by
Etiket: Cisco Meeting Server

Cisco Meeting Server (CMS) – Temel Konfigürasyon

Cisco Meeting Server (CMS) – Temel Konfigürasyon

Merhaba, bu yazıda daha önce incelemiş olduğum Cisco Meeting Server’ın (CMS) temel konfigürasyonu ve web arayüzünü nasıl aktif edebileceğinizi bulabilirsiniz.

Cisco Meeting Server’ı konfigüre edebilmeniz için komut satırı (CLI), GUI ve API olmak üzere 3 farklı arayüz bulunuyor. Bunlardan ilki olan CLI arayüzüne, sunucunun konsolu üzerinden ve IP adresi verildikten sonra da SSH üzerinden de erişilebiliyor. Şimdi CLI arayüzünden başlayarak GUI arayüzüne geçebileceğimiz temel konfigürasyon adımlarına başlayalım:

CLI Temel Konfigürasyonu

CMS’e konsol üzerinden bağlandığınızda bir login ekranı karşılıyor. CMS’e default admin/admin olarak bağlandığınızda şifreyi değiştirmenizi istiyor.

Bu adımı geçtikten sonra IP verme işlemine geçebiliriz. CMS default olarak DHCP’den aldığı IP’yi kullanıyor, statik IP vermek istiyorsanız şu komutu kendi ayarlarınıza göre değiştirip uygulayabilirsiniz:

ipv4 a add 192.168.0.133/24 192.168.0.1

Burada a interface in adı, 192.168.0.133 IP adresi, /24 subnet mask ve 192.168.0.1 de tahmin edebileceğiniz gibi default gateway IP si.

IP adresini belirledikten sonra artık CMS’e SSH üzerinden de bağlanabilirsiniz.

Default olarak acano diye tanımlanan hostname i değiştirmek için şu komutu kullanabilirsiniz:

hostname cms1

Bu komuttan sonra hostname in aktif olabilmesi için CMS sizden reboot etmenizi istiyor. CMS’i reboot komutuyla reboot edebilirsiniz.

CMS’in düzgün çalışabilmesi için DNS ve NTP sunucularına ihtiyacınız var. Bunların hali hazırda olduğunu düşünerek aşağıdaki DNS (.100) ve NTP (.101) konfigürasyonlarını da giriyoruz:

ntp server add 192.168.0.101
dns add forwardzone . 192.168.0.100

Bu işlemlerden sonra GUI’yi aktif etmek için gerekli konfigürasyona başlayabilirsiniz.

WEB GUI Konfigürasyonu

Web arayüzünü kullanabilmek için öncelikli olarak HTTPS için bir sertifika üretmek gerekiyor. Bu sertifika hem self-signed hem de bir CA üzerinden imzalanmış bir sertifika olabilir. İşlem kolaylığı açısından self signed sertifika şu şekilde üretiliyor:

pki selfsigned cms1

Sertifika işleminden sonra web arayüzü için dinlenecek arayüzü ve HTTPS portunu belirtin:

webadmin listen a 445

kullanılacak sertifika(lar) için üst bölümde oluşturulan self-signed sertifika ve ilgili keyi belirtiyoruz:

webadmin certs cms1.key cms1.crt 

HTTP isteklerini HTTPS’e yönlendirmek için aşağıdaki komutu kullanabilirsiniz:

webadmin http-redirect enable 

ardından son olarak web admin modülünü aktif ediyorsunuz:

webadmin enable

Artık bu işlemden sonra CLI kullanıcısı ile web arayüzünü kullanabilir hale geliyorsunuz. Dilerseniz bu prosedürleri aşağıda hazırlamış olduğum videoda da bulabilirsiniz:

Bu noktada şunu belirtmeliyim ki CMS’in farklı servislerini konfigüre edebilmek için hem CLI, hem GUI, hem de API kullanmanız gerekebiliyor. Yani CLI’dan yapabileceğiniz her şeyi aynı zamanda GUI’den de yapamıyorsunuz.

Cisco Meeting Server : H.323 Aramaları Etkinleştirmek

Cisco Meeting Server : H.323 Aramaları Etkinleştirmek

Merhaba, bu yazıda Cisco Meeting Server üzerinde H.323 Gateway fonksiyonunun nasıl aktif hale getirip H.323 çağrılarının karşılanabileceğini, ve ilgili konfigürasyon parametrelerini bulabilirsiniz.

Cisco Meeting Server bildiğiniz üzere SIP protokolü ile çalışan bir sunucu. Dolayısı ile CMS’e doğru gelen H.323 çağrıları karşılayabilmek için arada protokol dönüşümünü yapan bir gateway modülü mevcut. Eğer mevcut video konferans altyapınızda H.323 kullanıyorsanız ya da H.323 cihazlarınız varsa CMS ile entegrasyonu sağlamak için CMS üzerinde H.323 gateway özelliğini açabilirsiniz.

CMS İçindeki H.323 Gateway Modülü ve Protokol Dönüşümü

Cisco Meeting Server H.323 Konfigürasyon Adımları

CMS üzerinde H.323 Gateway modülünü aktif etmek için komut satırını kullanmamız gerekiyor. CMS’e SSH üzerinden bağlandıktan sonra aşağıdaki komutları girerek modülü aktif hale getirebilirsiniz.

İlk olarak gateway modüülü üzerinde H.323 & SIP çağrıları için dinlenmesi gereken arayüzü tanımlıyoruz:

h323_gateway h323 interfaces a 
h323_gateway sip interfaces a

CMS’in mevcut SIP sinyalleşmesi ile karışmaması adına H.323’ten SIP’e dönüştürülen mesajlar için kullanılacak, 5060 ve 5061 den farklı bir SIP portu tanımlıyoruz:

h323_gateway sip port 6061

H.323-SIP çağrıları için SIP proxy adresini (aslında sunucunun kendisi) tanımlıyoruz:

h323_gateway sip proxy 127.0.0.1

Daha sonra güvenli bağlantılar için H.323 gateway tarafından kullanılacak key-sertifika zincirini tanımlıyoruz:

h323_gateway certs cms1.key cms1.cer CA.cer

SIP’e dönüştürülen çağrılar için içeride “Incoming calls” tanımları ile eşleşebilmesi için SIP domain adını tanımlıyoruz:

h323_gateway sip_domain test.local
CMS Incoming Calls Ayarları

Son olarak da gateway modülünü aktif hale getiriyoruz:

h323_gateway enable

H.323 Gateway modülünün durumu ile ilgili bilgi almak isterseniz aşağıdaki komutu kullanabilirsiniz:

h323_gateway 
CMS H.323 Gateway Durum Bilgisi

Bu adımlardan sonra CMS’e doğru H.323 çağrılar yapabilirsiniz. Yapılan H.323 çağrılar CMS içinde SIP’e çevrildiği için GUI’de çağrıları SIP çağrısı olarak göreceksiniz.

Bu adımları ayrıca aşağıdaki video üzerinden de takip edebilirsiniz :

CMS Üzerinde H.323 Çağrıları Aktif Etmek
CMS (Cisco Meeting Server) İncelemesi

CMS (Cisco Meeting Server) İncelemesi

Merhaba, bu yazımda size Cisco’nun çoklu konferans sunucusu CMS i tanıtmaya çalışacağım. 

Belki bilenler vardır, Cisco 2009 yılında Tandberg’i satın alıp video konferans alanında bir oyuncu olduğunda Tandberg’den ayrılan bir ekip Acano adıyla başka bir firma kurarak ürün geliştirmeye devam ettiler. Piyasaya sürdükleri Acano Server, güçlü birlikte çalışabilirlik (interoperability) yetenekleri, multi-tenant yapısı, WebRTC desteği ve yüksek kapasite sunması yüzünden genelde servis sağlayıcılarına hitap eden bir ürün olarak sektörde yer alıyordu. 
Yakın geçmişte video konferans üreticileri kendilerine özgün ürün özelliklerinden ziyade birlikte çalışılabilirliğe odaklanmıştı. O dönemde Cisco, MCU olarak Telepresence Server ailesi altında çeşitli (şasi, donanım ve sanal sunucu) ürünlere sahipti fakat bu ürünlerde WebRTC ve Skype for Business (eski adıyla Lync) desteği ya yoktu ya da farklı gatewayler ile kısıtlı olarak sağlanıyordu. 2016 yılında Cisco Acano’yu 700M$ karşılığında satın aldığını duyurarak kendi ürün gamına kattı ve Telepresence Server ailesinin end-of-sale duyurusunu yaptı. Acano Server yeni adıyla CMS olarak sektörde yerini aldı.

Bu  kadar tarihçeden sonra ürün özelliklerine geçelim isterseniz. CMS, 1000 (1U Server Appliance)  ve 2000 (6U Blade Server Appliance) olmak üzere iki farklı donanım olarak karşımıza çıkıyor. İsterseniz kendi sanal sunucu kaynaklarınıza da kurabiliyorsunuz. 
 

CMS 1000 vs. 2000

Kapasite olarak 1000 serisi 96, 2000 ise 500 eş zamanlı HD (720p) çözünürlükte görüşmeyi destekleyebiliyor (Ve bu kapasitenin tamamını dilerseniz kullanabiliyorsunuz, nasıl olduğunu lisanslama bölümünde anlatacağım). Eğer sadece sesli konferans yapılacaksa bu sayı her iki donanım için de 3000 eş zamanlı katılımcıya kadar çıkıyor. Bilinen video standartlarının (H.261, H.263, H.264) yanı sıra Microsoft RTV, WebM, VP8 (WebRTC) desteği de mevcut. H.265 desteği henüz yok ama yakın zamanda gelecektir diye düşünüyorum. CMS cluster yapıda da çalışabiliyor bu da hem yedeklilik hem de ölçeklenebilirlik anlamında avantaj sağlıyor. Interoperability ve S4B uyumluluğundan yukarıda bahsetmiştik zaten.

CMS WebRTC Giriş Ekranı


Ürünü daha detaylı incelemek isterseniz datasheet bilgilerine buradan ulaşabilirsiniz.

CMS Lisanslama Modeli (SMP & PMP)

CMS’in lisanslama modeli ise apayrı bir konu. Geleneksel MCU lisanslama modellerinde eş zamanlı toplantı cihazı (port) sayılıyordu. Basitçe anlatmak gerekirse örneğin 12 port lisanslı bir MCU ile toplamda 12 katılımcılı bir toplantı yapabiliyordunuz. CMS’te ise lisanslama toplam eşzamanlı sanal toplantı odasına göre yapılıyor. Örneğin sizin 5 tane SMP veya PMP lisansınız var ise aynı anda katılımcı sayısından bağımsız (daha doğrusu donanım kapasitesi kadar) olarak toplamda 5 toplantı yapabilirsiniz. Biraz daha açmak gerekirse örneğin 96 HD port kapasiteli CMS 1000 kullanıyorsunuz ve 5 SMP lisansınız var. 1. toplantı 12 HD katılımcılı, 2. toplantı 25 HD katılımcılı, 3. toplantı 22 HD katılımcılı, 4. toplantı 33 HD katılımcılı ve 5. toplantı 4 HD katılımcılı olacak şekilde cihazı kullanabilirsiniz. Şimdi de lisanslama türlerine bakalım: 

Shared Multiparty Lisansı (SMP), daha çok ortak kullanılan video konferans cihazları olan kurumlar için uygun, daha doğrusu CUCM üzerinde video konferans cihazlarını herhangi bir LDAP kullanıcısı ile eşleştirmediğiniz durumda yapılan toplantılar için. Katılımcı sayısı donanım kapasitesi ile sınırlı olmak kaydıyla toplantı odası başına 1 adet SMP lisansı gerekiyor.

Personal Multiparty Lisansı (PMP) ise bir kullanıcıya ait video uç cihazı ile yapılan toplantılar için kullanılıyor. Örneğin kendi LDAP kullanıcınıza ait bir Jabber yazılımınız ile toplantı yaptığınızda 1 adet PMP kullanıyorsunuz. PMP lisansları ortak kullanılamıyor, CMS konfigürasyonunda hangi LDAP kullanıcılarının PMP lisans kullanabileceğini belirtiyorsunuz. Bu arada örneğin bir yöneticinin kendi video konferans cihazı var ise onu kullanıcı ile eşleştirip PMP lisans kullanmasını sağlayabilirsiniz. Yalnız burada dikkat edilmesi gereken bir şey var, PMP lisansları CMS üzerinde API ile kullanıcılara atandığı için (niyeyse?) randevulu konferanslarda (statik odalarda) kullanılamıyor, bu lisansın kullanılabilmesi için API ile bir etkileşim olan konferansa (Ad-hoc veya TMS üzerinden rezerve edilmiş olabilir.) katılmanız gerekiyor. 

Sizlerin de tahmin edebileceğiniz gibi PMP lisansı SMP lisansından daha düşük fiyatlı olarak satılıyor. Eğer yeni bir video konferans cihazı sipariş edecekseniz SMP lisansını cihaz ile bundle olarak daha uygun fiyata alabiliyorsunuz. Mevcut Cisco MCU ya da Telepresence Server’a sahip kurumlar da CMS migration lisanslarını kullanarak (mevcut yatırımı koruyarak) CMS’e geçiş yapabilirler. 

Bu lisansların yanında görüşmelerin kayıt edilebilmesi ve WebRTC arayüzünün kişiselleştirilebilmesi için de recording ve branding lisansları bulunuyor.

Cluster Mimarisi

Yedeklilik özellikleri ve kapasiteyi arttırmak adına birden çok CMS i cluster bir biçimde çalıştırabiliyorsunuz. Yalnız burada dikkat edilmesi gereken şey yedeklilik için minimum 3 adet sunucuya ihtiyacınız var. Sunuculardan biri master database verisini tutarken diğer ikisini yedekli olarak çağrı işlemleri için konfigüre edebilirsiniz. 

 
Tipik CMS Cluster Mimarisi

Kurulum & Konfigürasyon

CMS’i eğer bir appliance şeklinde aldıysanız zaten kurulu bir şekilde geliyor, siz komut satırından gerekli konfigürasyonları yaptıktan sonra web arayüzünü açıp konfigürasyona oradan devam edebiliyorsunuz. İleri seviye konfigürasyonlar için (PMP lisansı kullanacak kullanıcıları belirtmek gibi) API kullanmanız gerekiyor. Burada bir eleştiri olarak bunun pek de kolay olmadığını belirtebilirim. CMS ile ilgili tüm konfigürasyon dokümanlarını bu linkte bulabilirsiniz.
 
CMS ile CUCM’i birlikte çalıştırmak için aralarında SIP trunk tanımlamanız gerekmekte. Ad-hoc konferanslar için de bu trunk ın güvenli yani encrypted olması gerekiyor, bu da işin içine sertifikaların dahil olması demek. Yukarıda belirttiğim linkte sertifikaların nasıl oluşturulacağı ile ilgili dokümanları da bulabilirsiniz. Trunk tanımlarını yaptıktan sonra ilgili route patternleri de ayarlayarak artık çağrıları CMS’e teslim edip konferans görüşmelerini yapabilir hale geliyorsunuz.

Son Söz

CMS, S4B desteği, WebRTC gibi getirdiği yeni özellikler sayesinde kurumların ve kurumlar arası iletişimin çok daha esnek olabilmesine olanak sağlıyor. Sanal yapıda çalışması, düşük donanım ihtiyacı ve uygun lisanslama modeli ile de diğer üreticilerden öne çıkıyor. Her ne kadar kurulumu biraz uğraştırsa da kullanımı oldukça kolay.