સિસ્કો મીટિંગ સર્વર 2.5.2. વિડિયો કોન્ફરન્સ રેકોર્ડિંગ કાર્ય સાથે સ્કેલેબલ અને સ્થિતિસ્થાપક મોડમાં ક્લસ્ટર

આ અંકમાં હું ફેલઓવર ક્લસ્ટર મોડમાં CMS સર્વરને સેટ કરવાની કેટલીક જટિલતાઓને બતાવીશ અને સમજાવીશ.


થિયરીસામાન્ય રીતે, CMS સર્વર જમાવટના ત્રણ પ્રકાર છે:

• એકલ સંયુક્ત(સિંગલ સંયુક્ત), એટલે કે. આ એક સર્વર છે જેના પર તમામ જરૂરી સેવાઓ ચાલી રહી છે. મોટા ભાગના કિસ્સાઓમાં, આ પ્રકારની જમાવટ માત્ર આંતરિક ક્લાયન્ટ એક્સેસ માટે અને નાના વાતાવરણમાં જ યોગ્ય છે જ્યાં એક સર્વરની માપનીયતા અને રીડન્ડન્સી મર્યાદાઓ ગંભીર સમસ્યા નથી, અથવા એવી પરિસ્થિતિઓમાં જ્યાં CMS માત્ર અમુક કાર્યો કરે છે, જેમ કે એડહોક. સિસ્કો UCM પર પરિષદો.

  કાર્યની અંદાજિત યોજના:
  

• સિંગલ સ્પ્લિટ(સિંગલ સ્પ્લિટ) બાહ્ય ઍક્સેસ માટે અલગ સર્વર ઉમેરીને અગાઉના જમાવટના પ્રકારને વિસ્તૃત કરે છે. લેગસી ડિપ્લોયમેન્ટ્સમાં, આનો અર્થ એ છે કે ડિમિલિટરાઇઝ્ડ નેટવર્ક સેગમેન્ટ (DMZ)માં CMS સર્વરને જમાવવું જ્યાં બાહ્ય ક્લાયન્ટ્સ તેને એક્સેસ કરી શકે અને નેટવર્ક કોરમાં એક CMS સર્વર જ્યાં આંતરિક ક્લાયન્ટ્સ CMS ઍક્સેસ કરી શકે. આ ચોક્કસ જમાવટ મોડલ હવે કહેવાતા પ્રકાર દ્વારા સ્થાનાંતરિત કરવામાં આવી રહ્યું છે સિંગલ એજ, જેમાં સર્વર્સનો સમાવેશ થાય છે સિસ્કો એક્સપ્રેસવે, જે કાં તો સમાન ફાયરવોલ બાયપાસ ક્ષમતાઓ ધરાવે છે અથવા હશે જેથી ક્લાયંટને સમર્પિત એજ CMS સર્વર ઉમેરવાની જરૂર નથી.

  કાર્યની અંદાજિત યોજના:
  

• માપી શકાય તેવું અને સ્થિતિસ્થાપક(સ્કેલેબલ અને ફોલ્ટ ટોલરન્ટ) આ પ્રકારમાં દરેક ઘટક માટે રીડન્ડન્સીનો સમાવેશ થાય છે, જે નિષ્ફળતાના કિસ્સામાં રીડન્ડન્સી પ્રદાન કરતી વખતે સિસ્ટમને તેની મહત્તમ ક્ષમતા સુધી તમારી જરૂરિયાતો સાથે વૃદ્ધિ કરવાની મંજૂરી આપે છે. તે સુરક્ષિત બાહ્ય ઍક્સેસ પ્રદાન કરવા માટે સિંગલ એજ ખ્યાલનો પણ ઉપયોગ કરે છે. આ તે પ્રકાર છે જે આપણે આ એપિસોડમાં જોઈશું. જો આપણે સમજીએ કે આ પ્રકારના ક્લસ્ટરને કેવી રીતે જમાવવું, તો અમે માત્ર અન્ય પ્રકારની ડિપ્લોયમેન્ટને જ નહીં, પરંતુ માંગમાં સંભવિત વૃદ્ધિને સમાવવા માટે CMS સર્વર્સના ક્લસ્ટર કેવી રીતે બનાવવું તે પણ સમજી શકીશું.

જમાવટ પર આગળ વધતા પહેલા, તમારે કેટલીક મૂળભૂત બાબતોને સમજવાની જરૂર છે, એટલે કે

મુખ્ય CMS સોફ્ટવેર ઘટકો:

• ડેટાબેઝ: તમને કેટલીક ગોઠવણીઓ, જેમ કે ડાયલ પ્લાન, યુઝર સ્પેસ અને યુઝર્સને જોડવાની મંજૂરી આપે છે. માત્ર ઉચ્ચ ઉપલબ્ધતા (સિંગલ માસ્ટર) માટે ક્લસ્ટરિંગને સપોર્ટ કરે છે.
• કૉલ બ્રિજ: ઑડિઓ અને વિડિયો કોન્ફરન્સિંગ માટેની સેવા કે જે કૉલ્સ અને મલ્ટીમીડિયા પ્રક્રિયાઓના સંચાલન અને પ્રક્રિયા પર સંપૂર્ણ નિયંત્રણ પ્રદાન કરે છે. ઉચ્ચ ઉપલબ્ધતા અને માપનીયતા માટે ક્લસ્ટરિંગને સપોર્ટ કરે છે.
• XMPP સર્વર: સિસ્કો મીટિંગ એપ્લિકેશન અને/અથવા WebRTC(નો ઉપયોગ કરીને ગ્રાહકોની નોંધણી અને પ્રમાણીકરણ માટે જવાબદારરીઅલ-ટાઇમ કોમ્યુનિકેશન, અથવા ફક્ત બ્રાઉઝરમાં), તેમજ ઇન્ટરકોમ્પોનન્ટ સિગ્નલિંગ. ઉચ્ચ ઉપલબ્ધતા માટે જ ક્લસ્ટર કરી શકાય છે.
• વેબ બ્રિજ: WebRTC માટે ક્લાયન્ટની ઍક્સેસ પ્રદાન કરે છે.
• લોડબેલેન્સર: સિંગલ સ્પ્લિટ મોડમાં સિસ્કો મીટિંગ એપ્સ માટે સિંગલ કનેક્શન પોઇન્ટ પ્રદાન કરે છે. ઇનકમિંગ કનેક્શન્સ માટે બાહ્ય ઇન્ટરફેસ અને પોર્ટ સાંભળે છે. સમાન રીતે, લોડ બેલેન્સર XMPP સર્વરમાંથી આવનારા TLS કનેક્શન્સને સ્વીકારે છે, જેના દ્વારા તે બાહ્ય ક્લાયન્ટ્સમાંથી TCP કનેક્શન્સને સ્વિચ કરી શકે છે.
  અમારા દૃશ્યમાં તેની જરૂર રહેશે નહીં.
• ટર્ન સર્વર: ફાયરવોલ બાયપાસ ટેકનોલોજી પૂરી પાડે છે જે પરવાનગી આપે છે
  સિસ્કો મીટિંગ એપ અથવા SIP ઉપકરણોનો ઉપયોગ કરીને બાહ્ય ક્લાયન્ટ્સને કનેક્ટ કરવા માટે ફાયરવોલ અથવા NAT પાછળ અમારા CMS મૂકો. અમારા દૃશ્યમાં તેની જરૂર રહેશે નહીં.
• વેબ એડમિન: વહીવટી ઈન્ટરફેસ અને API એક્સેસ, ખાસ યુનિફાઈડ CM કોન્ફરન્સ સહિત.

રૂપરેખાંકન મોડ્સ

સિસ્કોના અન્ય ઉત્પાદનોથી વિપરીત, સિસ્કો મીટિંગ સર્વર કોઈપણ પ્રકારની જમાવટને સમાવવા માટે ત્રણ રૂપરેખાંકન પદ્ધતિઓનું સમર્થન કરે છે.

• કમાન્ડ લાઇન (CLI): પ્રારંભિક રૂપરેખાંકન અને પ્રમાણપત્ર કાર્યો માટે MMP તરીકે ઓળખાતા આદેશ વાક્ય ઇન્ટરફેસ.
• વેબ એડમિનિસ્ટ્રેટર: મુખ્યત્વે કૉલબ્રિજ સંબંધિત રૂપરેખાંકનો માટે, ખાસ કરીને જ્યારે સિંગલ નોન-ક્લસ્ટર્ડ સર્વર સેટ કરો.
• REST API: સૌથી જટિલ રૂપરેખાંકન કાર્યો અને ક્લસ્ટર્ડ ડેટાબેઝ સંબંધિત કાર્યો માટે વપરાય છે.

ઉપરોક્ત ઉપરાંત, પ્રોટોકોલનો ઉપયોગ થાય છે SFTP CMS સર્વર પર અને તેમાંથી ફાઇલો-સામાન્ય રીતે લાઇસન્સ, પ્રમાણપત્રો અથવા લૉગ્સ ટ્રાન્સફર કરવા માટે.

સિસ્કોના જમાવટ માર્ગદર્શિકાઓમાં તે સફેદ અને અંગ્રેજીમાં લખાયેલું છે કે ક્લસ્ટરને તૈનાત કરવાની જરૂર છે ઓછામાં ઓછા ત્રણ ડેટાબેસેસના સંદર્ભમાં સર્વર્સ (નોડ્સ). કારણ કે નવા ડેટાબેઝ માસ્ટરને પસંદ કરવા માટેની મિકેનિઝમ માત્ર વિષમ સંખ્યામાં નોડ્સ સાથે જ કાર્ય કરશે અને સામાન્ય રીતે ડેટાબેઝ માસ્ટરનું મોટાભાગના CMS સર્વર ડેટાબેઝ સાથે જોડાણ હોય છે.

અને પ્રેક્ટિસ બતાવે છે તેમ, બે સર્વર (નોડ્સ) ખરેખર પૂરતા નથી. પસંદગી પદ્ધતિ કામ કરે છે જ્યારે માસ્ટર રીબૂટ થાય છે, સ્લેવ સર્વર રીબૂટ થયેલ સર્વરને લાવવામાં આવે પછી જ માસ્ટર બને છે. જો કે, જો બે સર્વરના ક્લસ્ટરમાં માસ્ટર સર્વર અચાનક બહાર નીકળી જાય, તો સ્લેવ સર્વર માસ્ટર બનશે નહીં, અને જો સ્લેવ બહાર જશે, તો બાકીનું માસ્ટર સર્વર સ્લેવ બની જશે.

પરંતુ XMPP ના સંદર્ભમાં, ત્રણ સર્વર્સના ક્લસ્ટરને એસેમ્બલ કરવું ખરેખર જરૂરી રહેશે, કારણ કે જો, ઉદાહરણ તરીકે, તમે XMPP સેવાને એક સર્વર પર અક્ષમ કરો છો જેમાં XMMP લીડર સ્ટેટસમાં છે, તો પછી બાકીના સર્વર પર XMPP ફોલોઅર સ્ટેટસમાં રહેશે અને XMPP સાથેના કૉલબ્રિજ કનેક્શન્સ બંધ થઈ જશે, કારણ કે કોલબ્રિજ લીડર સ્ટેટસ સાથે એક્સએમપીપી સાથે એક્સક્લુઝિવલી કનેક્ટ થાય છે. અને આ મહત્વપૂર્ણ છે, કારણ કે ... એક પણ કોલ પસાર થશે નહીં.

તે જ જમાવટ માર્ગદર્શિકાઓમાં પણ એક XMPP સર્વર સાથેનું ક્લસ્ટર દર્શાવવામાં આવ્યું છે.

અને ઉપરોક્તને ધ્યાનમાં લેતા, તે શા માટે સ્પષ્ટ થાય છે: તે કાર્ય કરે છે કારણ કે તે ફેલઓવર મોડમાં છે.

અમારા કિસ્સામાં, XMPP સર્વર ત્રણેય નોડ્સ પર હાજર રહેશે.

એવું માનવામાં આવે છે કે અમારા ત્રણેય સર્વર ચાલુ છે.

DNS રેકોર્ડ્સ

તમે સર્વર સેટ કરવાનું શરૂ કરો તે પહેલાં, તમારે DNS રેકોર્ડ્સ બનાવવાની જરૂર છે А и એસઆરવી પ્રકારો:

મહેરબાની કરીને નોંધ કરો કે અમારા DNS રેકોર્ડ્સમાં બે ડોમેન્સ છે example.com અને કોન્ફ.example.com. Example.com એ એક ડોમેન છે જેનો ઉપયોગ તમામ સિસ્કો યુનિફાઇડ કોમ્યુનિકેશન મેનેજર સબ્સ્ક્રાઇબર્સ તેમના URI માટે કરી શકે છે, જે મોટાભાગે તમારા ઇન્ફ્રાસ્ટ્રક્ચરમાં હાજર છે અથવા હાજર હોવાની શક્યતા છે. અથવા example.com એ જ ડોમેન સાથે મેળ ખાય છે જેનો ઉપયોગ વપરાશકર્તાઓ તેમના ઇમેઇલ સરનામાં માટે કરે છે. અથવા તમારા લેપટોપ પરના જબર ક્લાયંટ પાસે URI હોઈ શકે છે [ઇમેઇલ સુરક્ષિત]. ડોમેન કોન્ફ.example.com એ ડોમેન છે જે સિસ્કો મીટિંગ સર્વર વપરાશકર્તાઓ માટે ગોઠવવામાં આવશે. સિસ્કો મીટિંગ સર્વરનું ડોમેન હશે કોન્ફઉદાહરણ તરીકે.કોન્ફ.example.com.

મૂળભૂત રૂપરેખાંકન

નીચે વર્ણવેલ તમામ સેટિંગ્સ એક સર્વર પર બતાવવામાં આવી છે, પરંતુ તે ક્લસ્ટરમાં દરેક સર્વર પર કરવાની જરૂર છે.

ક્યુઓએસ

ત્યારથી CMS જનરેટ થાય છે વાસ્તવિક સમય વિલંબ અને પેકેટ નુકશાન પ્રત્યે સંવેદનશીલ ટ્રાફિક, મોટા ભાગના કિસ્સાઓમાં સેવાની ગુણવત્તા (QoS) રૂપરેખાંકિત કરવાની ભલામણ કરવામાં આવે છે. આ હાંસલ કરવા માટે, CMS તે જનરેટ કરે છે તે ડિફરન્શિએટેડ સર્વિસીસ કોડ્સ (DSCPs) સાથે ટેગિંગ પેકેટોને સપોર્ટ કરે છે. જો કે DSCP-આધારિત ટ્રાફિક પ્રાધાન્યતા તમારા ઈન્ફ્રાસ્ટ્રક્ચરના નેટવર્ક ઘટકો દ્વારા ટ્રાફિકની પ્રક્રિયા કેવી રીતે થાય છે તેના પર આધાર રાખે છે, અમારા કિસ્સામાં અમે QoS શ્રેષ્ઠ પ્રથાઓના આધારે અમારા CMS ને લાક્ષણિક DSCP અગ્રતા સાથે ગોઠવીશું.

દરેક સર્વર પર આપણે આ આદેશો દાખલ કરીશું

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

અમે CMS માં DNS સર્વર્સને આદેશ સાથે ઉમેરીએ છીએ જેમ કે:

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

અમારા કિસ્સામાં, આવા બે સર્વર છે, તેથી ત્યાં બે ટીમો હશે.
તપાસ કરી રહ્યું છે:

નેટવર્ક ઈન્ટરફેસ રૂપરેખાંકન

અમે આદેશ સાથે ઇન્ટરફેસને ગોઠવીએ છીએ જેમ કે:

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

તપાસ કરી રહ્યું છે:

સર્વર નામ (હોસ્ટનામ)

અમે આદેશ સાથે સર્વરનું નામ સેટ કરીએ છીએ જેમ કે:

hostname <name>

અને અમે રીબુટ કરીએ છીએ.


આ મૂળભૂત રૂપરેખાંકન પૂર્ણ કરે છે.

.Ы

થિયરીસિસ્કો મીટિંગ સર્વરને વિવિધ ઘટકો વચ્ચે એન્ક્રિપ્ટેડ સંચારની જરૂર છે, અને પરિણામે, તમામ CMS જમાવટ માટે X.509 પ્રમાણપત્રો જરૂરી છે. તેઓ ખાતરી કરવામાં મદદ કરે છે કે સેવાઓ/સર્વર અન્ય સર્વર્સ/સેવાઓ દ્વારા વિશ્વસનીય છે.

દરેક સેવા માટે પ્રમાણપત્રની જરૂર છે, પરંતુ દરેક સેવા માટે અલગ પ્રમાણપત્રો બનાવવાથી મૂંઝવણ અને બિનજરૂરી જટિલતા થઈ શકે છે. સદભાગ્યે, અમે પ્રમાણપત્રની સાર્વજનિક-ખાનગી કી જોડી બનાવી શકીએ છીએ અને પછી બહુવિધ સેવાઓમાં તેનો ફરીથી ઉપયોગ કરી શકીએ છીએ. અમારા કિસ્સામાં, સમાન પ્રમાણપત્રનો ઉપયોગ કૉલ બ્રિજ, XMPP સર્વર, વેબ બ્રિજ અને વેબ એડમિન માટે કરવામાં આવશે. આમ, તમારે ક્લસ્ટરમાં દરેક સર્વર માટે જાહેર અને ખાનગી પ્રમાણપત્ર કીની જોડી બનાવવાની જરૂર છે.

ડેટાબેઝ ક્લસ્ટરીંગ, જોકે, કેટલીક વિશિષ્ટ પ્રમાણપત્ર આવશ્યકતાઓ ધરાવે છે અને તેથી તેના પોતાના પ્રમાણપત્રોની જરૂર છે જે અન્ય સેવાઓ કરતાં અલગ છે. CMS સર્વર પ્રમાણપત્રનો ઉપયોગ કરે છે, જે અન્ય સર્વર્સ દ્વારા ઉપયોગમાં લેવાતા પ્રમાણપત્રો જેવું જ છે, પરંતુ ડેટાબેઝ કનેક્શન્સ માટે ક્લાયંટ પ્રમાણપત્રનો પણ ઉપયોગ થાય છે. ડેટાબેઝ પ્રમાણપત્રોનો ઉપયોગ પ્રમાણીકરણ અને એન્ક્રિપ્શન બંને માટે થાય છે. ક્લાયંટને ડેટાબેઝ સાથે કનેક્ટ કરવા માટે વપરાશકર્તાનામ અને પાસવર્ડ આપવાને બદલે, તે ક્લાયંટ પ્રમાણપત્ર રજૂ કરે છે જે સર્વર દ્વારા વિશ્વસનીય છે. ડેટાબેઝ ક્લસ્ટરમાં દરેક સર્વર સમાન જાહેર અને ખાનગી કી જોડીનો ઉપયોગ કરશે. આ ક્લસ્ટરમાંના બધા સર્વર્સને ડેટાને એવી રીતે એન્ક્રિપ્ટ કરવાની મંજૂરી આપે છે કે તે અન્ય સર્વર્સ દ્વારા જ ડિક્રિપ્ટ કરી શકાય છે જે સમાન કી જોડી પણ શેર કરે છે.

કાર્ય કરવા માટે નિરર્થકતા માટે, ડેટાબેઝ ક્લસ્ટરમાં ઓછામાં ઓછા 3 સર્વર હોવા જોઈએ, પરંતુ 5 કરતાં વધુ નહીં, કોઈપણ ક્લસ્ટર સભ્યો વચ્ચે મહત્તમ રાઉન્ડ-ટ્રીપ સમય 200 ms છે. આ મર્યાદા કૉલ બ્રિજ ક્લસ્ટરિંગ કરતાં વધુ પ્રતિબંધિત છે, તેથી તે ઘણીવાર ભૌગોલિક રીતે વિતરિત જમાવટમાં મર્યાદિત પરિબળ છે.

CMS માટે ડેટાબેઝની ભૂમિકામાં સંખ્યાબંધ અનન્ય આવશ્યકતાઓ હોય છે. અન્ય ભૂમિકાઓથી વિપરીત, તેને ક્લાયંટ અને સર્વર પ્રમાણપત્રની જરૂર છે, જ્યાં ક્લાયંટ પ્રમાણપત્રમાં ચોક્કસ CN ફીલ્ડ હોય છે જે સર્વરને પ્રસ્તુત કરવામાં આવે છે.

CMS પોસ્ટગ્રેસ ડેટાબેઝનો ઉપયોગ કરે છે જેમાં એક માસ્ટર અને ઘણી બધી સમાન પ્રતિકૃતિઓ હોય છે. એક સમયે માત્ર એક જ પ્રાથમિક ડેટાબેઝ છે ("ડેટાબેઝ સર્વર"). ક્લસ્ટરના બાકીના સભ્યો પ્રતિકૃતિઓ અથવા "ડેટાબેઝ ક્લાયન્ટ્સ" છે.

ડેટાબેઝ ક્લસ્ટરને સમર્પિત સર્વર પ્રમાણપત્ર અને ક્લાયંટ પ્રમાણપત્રની જરૂર છે. તેઓ પ્રમાણપત્રો દ્વારા સહી થયેલ હોવા જોઈએ, સામાન્ય રીતે આંતરિક ખાનગી પ્રમાણપત્ર સત્તાધિકાર. કારણ કે ડેટાબેઝ ક્લસ્ટરનો કોઈપણ સભ્ય માસ્ટર બની શકે છે, ડેટાબેઝ સર્વર અને ક્લાયંટ સર્ટિફિકેટ જોડીઓ (જાહેર અને ખાનગી કી સમાવે છે) બધા સર્વર્સ પર નકલ કરવી આવશ્યક છે જેથી તેઓ ક્લાયંટ અથવા ડેટાબેઝ સર્વરની ઓળખ ધારણ કરી શકે. વધુમાં, ક્લાયંટ અને સર્વર પ્રમાણપત્રો ચકાસી શકાય તેની ખાતરી કરવા માટે 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

જ્યાં dbclusterserver и dbclusterclient અમારી વિનંતીઓ અને ભાવિ પ્રમાણપત્રોના નામ, યજમાનનું નામ1(2)(3) અનુરૂપ સર્વરોના નામ.

અમે આ પ્રક્રિયા માત્ર એક સર્વર (!) પર કરીએ છીએ, અને અમે પ્રમાણપત્રો અને અનુરૂપ .key ફાઇલોને અન્ય સર્વર પર અપલોડ કરીશું.

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 સર્વર્સ પર અપલોડ થયેલ તમામ પ્રમાણપત્રો છે, તો તમે ત્રણ નોડ્સ વચ્ચે ડેટાબેઝ ક્લસ્ટરિંગને ગોઠવી અને સક્ષમ કરી શકો છો. પ્રથમ પગલું એ ડેટાબેઝ ક્લસ્ટરના મુખ્ય નોડ તરીકે એક સર્વરને પસંદ કરવાનું અને તેને સંપૂર્ણ રીતે ગોઠવવાનું છે.

માસ્ટર ડેટાબેઝ

ડેટાબેઝ પ્રતિકૃતિ સુયોજિત કરવા માટેનું પ્રથમ પગલું એ પ્રમાણપત્રોનો ઉલ્લેખ કરવાનું છે જેનો ડેટાબેઝ માટે ઉપયોગ કરવામાં આવશે. આ આદેશનો ઉપયોગ કરીને કરવામાં આવે છે જેમ કે:

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 સરનામું CMS સર્વરનું હાલનું માસ્ટર ip સરનામું કે જેના પર ક્લસ્ટર શરૂ કરવામાં આવ્યું હતું, ફક્ત માસ્ટર.

અમે આદેશ સાથે અમારા ડેટાબેઝ ક્લસ્ટર બધા સર્વર્સ પર કેવી રીતે કાર્ય કરે છે તે તપાસીએ છીએ:

database cluster status

અમે બાકીના ત્રીજા સર્વર પર તે જ કરીએ છીએ.

પરિણામે, તે તારણ આપે છે કે અમારું પ્રથમ સર્વર માસ્ટર છે, બાકીના ગુલામો છે.

વેબ એડમિન સેવા

વેબ એડમિનિસ્ટ્રેટર સેવાને સક્ષમ કરો:

webadmin listen a 445

પોર્ટ 445 પસંદ કરવામાં આવ્યું હતું કારણ કે પોર્ટ 443 નો ઉપયોગ વેબ ક્લાયંટની વપરાશકર્તા ઍક્સેસ માટે થાય છે

અમે વેબ એડમિન સેવાને પ્રમાણપત્ર ફાઇલો સાથે આદેશ સાથે ગોઠવીએ છીએ જેમ કે:

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

અને આદેશ સાથે વેબ એડમિનને સક્ષમ કરો:

webadmin enable

જો બધું બરાબર છે, તો અમને સફળતાની રેખાઓ પ્રાપ્ત થશે જે દર્શાવે છે કે વેબ એડમિન નેટવર્ક અને પ્રમાણપત્ર માટે યોગ્ય રીતે ગોઠવેલ છે. અમે વેબ બ્રાઉઝરનો ઉપયોગ કરીને સેવાની કાર્યક્ષમતા તપાસીએ છીએ અને વેબ એડમિનિસ્ટ્રેટરનું સરનામું દાખલ કરીએ છીએ, ઉદાહરણ તરીકે: cms.example.com: 445

કૉલ બ્રિજ ક્લસ્ટર

કૉલ બ્રિજ એ દરેક CMS જમાવટમાં હાજર એકમાત્ર સેવા છે. કૉલ બ્રિજ એ મુખ્ય કોન્ફરન્સિંગ મિકેનિઝમ છે. તે એક SIP ઈન્ટરફેસ પણ પૂરું પાડે છે જેથી કરીને કૉલ્સ તેના દ્વારા અથવા તેના દ્વારા રૂટ કરી શકાય, ઉદાહરણ તરીકે, સિસ્કો યુનિફાઈડ CM.

નીચે વર્ણવેલ આદેશો દરેક સર્વર પર યોગ્ય પ્રમાણપત્રો સાથે એક્ઝિક્યુટ કરવા જોઈએ.
તેથી:

અમે પ્રમાણપત્રોને કૉલ બ્રિજ સેવા સાથે એક આદેશ સાથે સાંકળીએ છીએ જેમ કે:

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

અમે કૉલબ્રિજ સેવાઓને આદેશ સાથે જોઈતા ઈન્ટરફેસ સાથે જોડીએ છીએ:

callbridge listen a

અને આદેશ સાથે સેવા પુનઃપ્રારંભ કરો:

callbridge restart

હવે જ્યારે અમારી પાસે અમારા કૉલ બ્રિજ રૂપરેખાંકિત છે, અમે કૉલ બ્રિજ ક્લસ્ટરિંગને ગોઠવી શકીએ છીએ. કૉલ બ્રિજ ક્લસ્ટરિંગ ડેટાબેઝ અથવા XMPP ક્લસ્ટરિંગથી અલગ છે. કૉલ બ્રિજ ક્લસ્ટર કોઈપણ પ્રતિબંધ વિના 2 થી 8 નોડ્સને સપોર્ટ કરી શકે છે. તે માત્ર નિરર્થકતા જ નહીં, પરંતુ લોડ બેલેન્સિંગ પણ પ્રદાન કરે છે જેથી બુદ્ધિશાળી કૉલ ડિસ્ટ્રિબ્યુશનનો ઉપયોગ કરીને કૉલ બ્રિજ સર્વર્સ પર પરિષદો સક્રિયપણે વિતરિત કરી શકાય. CMSમાં વધારાની સુવિધાઓ, કૉલ બ્રિજ જૂથો અને સંબંધિત સુવિધાઓ છે જેનો ઉપયોગ વધુ વ્યવસ્થાપન માટે થઈ શકે છે.

કૉલ બ્રિજ ક્લસ્ટરિંગ મુખ્યત્વે વેબ એડમિન ઇન્ટરફેસ દ્વારા ગોઠવવામાં આવે છે
નીચે વર્ણવેલ પ્રક્રિયા ક્લસ્ટરમાં દરેક સર્વર પર હાથ ધરવામાં આવશ્યક છે.
અને તેથી,

1. વેબ દ્વારા રૂપરેખાંકન > ક્લસ્ટર પર જાઓ.
2.ઇન કૉલ બ્રિજ ઓળખ અનન્ય નામ તરીકે, સર્વરના નામને અનુરૂપ કૉલબ્રિજ[01,02,03] દાખલ કરો. આ નામો મનસ્વી છે, પરંતુ આ ક્લસ્ટર માટે અનન્ય હોવા જોઈએ. તેઓ પ્રકૃતિમાં વર્ણનાત્મક છે કારણ કે તેઓ સૂચવે છે કે તેઓ સર્વર ઓળખકર્તા છે [01,02,03].
3.બી ક્લસ્ટર્ડ કૉલ બ્રિજ ક્લસ્ટરમાં અમારા સર્વર્સના વેબ એડમિનિસ્ટ્રેટર URL દાખલ કરો, CMS[01,02,03].example.com:445, એડ્રેસ ફીલ્ડમાં. બંદરનો ઉલ્લેખ કરવાની ખાતરી કરો. તમે પીઅર લિંક SIP ડોમેન ખાલી છોડી શકો છો.
4. દરેક સર્વરના CallBridge ટ્રસ્ટમાં પ્રમાણપત્ર ઉમેરો, જેની ફાઇલમાં અમારા સર્વરના તમામ પ્રમાણપત્રો છે, જેને અમે આ ફાઇલમાં ખૂબ જ શરૂઆતમાં મર્જ કર્યા છે, જેમ કે આદેશ સાથે:

callbridge trust cluster <trusted cluster certificate bundle>

અને આદેશ સાથે સેવા પુનઃપ્રારંભ કરો:

callbridge restart

પરિણામે, દરેક સર્વર પર તમારે આ ચિત્ર મેળવવું જોઈએ:

XMPP ક્લસ્ટર

CMS માં XMPP સેવાનો ઉપયોગ CMA WebRTC વેબ ક્લાયંટ સહિત સિસ્કો મીટિંગ એપ્સ (CMA) માટે તમામ નોંધણી અને પ્રમાણીકરણને હેન્ડલ કરવા માટે થાય છે. કૉલ બ્રિજ પોતે પણ પ્રમાણીકરણ હેતુઓ માટે XMPP ક્લાયંટ તરીકે કાર્ય કરે છે અને તેથી તે અન્ય ક્લાયન્ટ્સની જેમ ગોઠવેલું હોવું જોઈએ. XMPP ફોલ્ટ ટોલરન્સ એ એક લક્ષણ છે જે ઉત્પાદન વાતાવરણમાં સંસ્કરણ 2.1 થી સપોર્ટેડ છે

નીચે વર્ણવેલ આદેશો દરેક સર્વર પર યોગ્ય પ્રમાણપત્રો સાથે એક્ઝિક્યુટ કરવા જોઈએ.
તેથી:

અમે XMPP સેવા સાથે પ્રમાણપત્રોને આદેશ સાથે સાંકળીએ છીએ જેમ કે:

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

પછી આદેશ સાથે સાંભળવાના ઇન્ટરફેસને વ્યાખ્યાયિત કરો:

xmpp listen a

XMPP સેવાને અનન્ય ડોમેનની જરૂર છે. આ વપરાશકર્તાઓ માટે લૉગિન છે. બીજા શબ્દોમાં કહીએ તો, જ્યારે વપરાશકર્તા CMA એપ્લિકેશન (અથવા WebRTC ક્લાયન્ટ દ્વારા) નો ઉપયોગ કરીને લૉગિન કરવાનો પ્રયાસ કરે છે, ત્યારે તેઓ userID@logindomain દાખલ કરે છે. અમારા કિસ્સામાં તે userid@ હશેકોન્ફ.example.com. શા માટે તે માત્ર example.com નથી? અમારા ચોક્કસ જમાવટમાં, અમે અમારું યુનિફાઇડ CM ડોમેન પસંદ કર્યું છે કે જે Jabber વપરાશકર્તાઓ યુનિફાઇડ CMમાં example.com તરીકે ઉપયોગ કરશે, તેથી અમને CMS વપરાશકર્તાઓ માટે SIP ડોમેન્સ દ્વારા CMS પર અને રૂટ કૉલ્સ કરવા માટે એક અલગ ડોમેનની જરૂર હતી.

આદેશનો ઉપયોગ કરીને XMPP ડોમેન સેટ કરો જેમ કે:

xmpp domain <domain>

અને આદેશ સાથે XMPP સેવાને સક્ષમ કરો:

xmpp enable

XMPP સેવામાં, તમારે દરેક કૉલ બ્રિજ માટે ઓળખપત્રો બનાવવા આવશ્યક છે જેનો ઉપયોગ XMPP સેવા સાથે નોંધણી કરતી વખતે કરવામાં આવશે. આ નામો મનસ્વી છે (અને તમે કૉલ બ્રિજ ક્લસ્ટરિંગ માટે ગોઠવેલા અનન્ય નામો સાથે સંબંધિત નથી). તમારે એક XMPP સર્વર પર ત્રણ કૉલ બ્રિજ ઉમેરવા જોઈએ અને પછી ક્લસ્ટરમાં અન્ય XMPP સર્વર પર તે ઓળખપત્રો દાખલ કરવા જોઈએ કારણ કે આ ગોઠવણી ક્લસ્ટર ડેટાબેઝમાં ફિટ થતી નથી. બાદમાં અમે XMPP સેવા સાથે નોંધણી કરવા માટે આ નામ અને ગુપ્તનો ઉપયોગ કરવા માટે દરેક કૉલ બ્રિજને ગોઠવીશું.

હવે આપણે પ્રથમ સર્વર પર XMPP સેવાને ત્રણ કૉલ બ્રિજ callbridge01, callbridge02 અને callbridge03 સાથે ગોઠવવાની જરૂર છે. દરેક એકાઉન્ટને રેન્ડમ પાસવર્ડ અસાઇન કરવામાં આવશે. આ 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

અમે સિક્રેટ ખૂબ જ કાળજીપૂર્વક ઉમેરીએ છીએ જેથી, ઉદાહરણ તરીકે, તેમાં કોઈ વધારાની જગ્યાઓ ન હોય.


પરિણામે, દરેક સર્વરમાં સમાન ચિત્ર હોવું જોઈએ:

આગળ, ક્લસ્ટરમાંના બધા સર્વર્સ પર, અમે ત્રણેય પ્રમાણપત્રો ધરાવતી ફાઇલનો વિશ્વાસપૂર્વક ઉલ્લેખ કરીએ છીએ, જે આના જેવા આદેશ સાથે અગાઉ બનાવેલ છે:

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 ક્લસ્ટર ચાલી રહ્યું છે, તમારે XMPP ક્લસ્ટર સાથે જોડાવા માટે કૉલ બ્રિજ સેવાઓને ગોઠવવાની જરૂર છે. આ ગોઠવણી વેબ એડમિન દ્વારા કરવામાં આવે છે.

દરેક સર્વર પર, રૂપરેખાંકન > સામાન્ય અને ક્ષેત્રમાં જાઓ અનન્ય કૉલ બ્રિજ નામ સર્વર કૉલ બ્રિજને અનુરૂપ અનન્ય નામો લખો કોલબ્રિજ[01,02,03]... ક્ષેત્રમાં ડોમેન conf.example.ru અને અનુરૂપ પાસવર્ડ્સ, તમે તેમના પર જાસૂસી કરી શકો છો
આદેશ સાથે ક્લસ્ટરમાં કોઈપણ સર્વર પર:

xmpp callbridge list

"સર્વર" ફીલ્ડને ખાલી છોડો ક Callલબ્રીજ માટે DNS SRV લુકઅપ કરશે _xmpp-component._tcp.conf.example.comઉપલબ્ધ XMPP સર્વર શોધવા માટે. કૉલબ્રિજને XMPP સાથે કનેક્ટ કરવા માટેના IP સરનામાં દરેક સર્વર પર અલગ-અલગ હોઈ શકે છે, તે રેકોર્ડ વિનંતી પર કયા મૂલ્યો પરત કરવામાં આવે છે તેના પર આધાર રાખે છે _xmpp-component._tcp.conf.example.com callbridge, જે બદલામાં આપેલ DNS રેકોર્ડ માટે પ્રાથમિકતા સેટિંગ્સ પર આધાર રાખે છે.

આગળ, કૉલ બ્રાઇડ સેવા XMPP સેવા સાથે સફળતાપૂર્વક જોડાયેલ છે કે કેમ તે ચકાસવા માટે સ્ટેટસ > જનરલ પર જાઓ.

વેબ બ્રિજ

ક્લસ્ટરમાં દરેક સર્વર પર, આદેશ સાથે વેબ બ્રિજ સેવાને સક્ષમ કરો:

webbridge listen a:443

અમે વેબ બ્રિજ સેવાને પ્રમાણપત્ર ફાઇલો સાથે આદેશ સાથે ગોઠવીએ છીએ જેમ કે:

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

વેબ બ્રિજ HTTPS ને સપોર્ટ કરે છે. જો "http-રીડાયરેક્ટ" નો ઉપયોગ કરવા માટે ગોઠવેલ હોય તો તે HTTP ને HTTPS પર રીડાયરેક્ટ કરશે.
HTTP રીડાયરેક્શનને સક્ષમ કરવા માટે, નીચેના આદેશનો ઉપયોગ કરો:

webbridge http-redirect enable

કૉલ બ્રિજને જણાવવા માટે કે વેબ બ્રિજ કૉલ બ્રિજના કનેક્શન પર વિશ્વાસ કરી શકે છે, આદેશનો ઉપયોગ કરો:

webbridge trust <certfile>

જ્યાં આ ક્લસ્ટરના દરેક સર્વરમાંથી ત્રણેય પ્રમાણપત્રો ધરાવતી ફાઇલ છે.

આ ચિત્ર ક્લસ્ટરના દરેક સર્વર પર હોવું જોઈએ.


હવે આપણે "એપડમિન" ભૂમિકા સાથે વપરાશકર્તા બનાવવાની જરૂર છે, અમને તેની જરૂર છે જેથી કરીને અમે અમારા ક્લસ્ટર(!)ને ગોઠવી શકીએ, અને ક્લસ્ટરમાં દરેક સર્વરને અલગથી નહીં, આ રીતે સેટિંગ્સ દરેક સર્વર પર સમાનરૂપે લાગુ કરવામાં આવશે. હકીકત એ છે કે તેઓ એકવાર બનાવવામાં આવશે.


વધુ સેટઅપ માટે અમે ઉપયોગ કરીશું પોસ્ટમેન.

અધિકૃતતા માટે, અધિકૃતતા વિભાગમાં મૂળભૂત પસંદ કરો

CMS સર્વરને યોગ્ય રીતે આદેશો મોકલવા માટે, તમારે જરૂરી એન્કોડિંગ સેટ કરવાની જરૂર છે

અમે આદેશ સાથે વેબબ્રિજનો ઉલ્લેખ કરીએ છીએ પોસ્ટ પરિમાણ સાથે URL અને અર્થ cms.example.com



વેબબ્રિજમાં જ, અમે જરૂરી પરિમાણો સૂચવીએ છીએ: અતિથિ ઍક્સેસ, સુરક્ષિત ઍક્સેસ, વગેરે.

કૉલ બ્રિજ જૂથો

મૂળભૂત રીતે, CMS હંમેશા તેને ઉપલબ્ધ કોન્ફરન્સિંગ સંસાધનોનો સૌથી વધુ કાર્યક્ષમ ઉપયોગ કરતું નથી.

ઉદાહરણ તરીકે, ત્રણ સહભાગીઓ સાથેની મીટિંગ માટે, દરેક સહભાગી ત્રણ અલગ-અલગ કૉલ બ્રિજ પર સમાપ્ત થઈ શકે છે. આ ત્રણેય સહભાગીઓ એકબીજા સાથે વાતચીત કરી શકે તે માટે, કૉલ બ્રિજ એ જ સ્પેસમાં બધા સર્વર્સ અને ક્લાયન્ટ્સ વચ્ચે આપમેળે જોડાણો સ્થાપિત કરશે, જેથી તે બધા એવું લાગે કે જાણે બધા ક્લાયન્ટ્સ એક જ સર્વર પર હોય. કમનસીબે, આનું નુકસાન એ છે કે એક 3-વ્યક્તિની કોન્ફરન્સ હવે 9 મીડિયા પોર્ટનો ઉપયોગ કરશે. આ દેખીતી રીતે સંસાધનોનો બિનકાર્યક્ષમ ઉપયોગ છે. વધુમાં, જ્યારે કૉલ બ્રિજ ખરેખર ઓવરલોડ થાય છે, ત્યારે ડિફૉલ્ટ મિકેનિઝમ કૉલ્સ સ્વીકારવાનું ચાલુ રાખવાનું છે અને તે કૉલ બ્રિજના તમામ સબ્સ્ક્રાઇબર્સને ઓછી ગુણવત્તાયુક્ત સેવા પ્રદાન કરે છે.

આ સમસ્યાઓ કૉલ બ્રિજ ગ્રુપ સુવિધાનો ઉપયોગ કરીને ઉકેલવામાં આવે છે. આ સુવિધા સિસ્કો મીટિંગ સર્વર સૉફ્ટવેરના સંસ્કરણ 2.1 માં રજૂ કરવામાં આવી હતી અને WebRTC સહભાગીઓ સહિત, ઇનબાઉન્ડ અને આઉટબાઉન્ડ સિસ્કો મીટિંગ એપ્લિકેશન (CMA) કૉલ્સ માટે લોડ બેલેન્સિંગને સપોર્ટ કરવા માટે વિસ્તૃત કરવામાં આવી છે.

પુનઃજોડાણની સમસ્યાને ઉકેલવા માટે, દરેક કૉલ બ્રિજ માટે ત્રણ રૂપરેખાંકિત લોડ મર્યાદા રજૂ કરવામાં આવી છે:

લોડ લિમિટ — આ ચોક્કસ કૉલ બ્રિજ માટે મહત્તમ સંખ્યાત્મક લોડ છે. દરેક પ્લેટફોર્મની ભલામણ કરેલ લોડ મર્યાદા છે, જેમ કે CMS96000 માટે 1000 અને વર્ચ્યુઅલ મશીન માટે 1.25 GHz પ્રતિ vCPU. સહભાગીના રિઝોલ્યુશન અને ફ્રેમ રેટના આધારે વિવિધ કૉલ્સમાં ચોક્કસ સંસાધનોનો ઉપયોગ થાય છે.
ન્યૂ કોન્ફરન્સ લોડ લિમિટ બેસિસ પોઈન્ટ્સ (ડિફૉલ્ટ 50% લોડ લિમિટ) - સર્વર લોડ મર્યાદા સેટ કરે છે, જેના પછી નવી પરિષદો નકારી કાઢવામાં આવે છે.
હાલની કોન્ફરન્સ લોડ લિમિટ બેસિસ પોઈન્ટ્સ (લોડ લિમિટના ડિફોલ્ટ 80%) - સર્વર લોડ મૂલ્ય કે જેના પછી હાજર કોન્ફરન્સમાં જોડાનારા સહભાગીઓ નકારવામાં આવશે.

જ્યારે આ સુવિધા કોલ ડિસ્ટ્રિબ્યુશન અને લોડ બેલેન્સિંગ માટે ડિઝાઇન કરવામાં આવી હતી, ત્યારે અન્ય જૂથો જેમ કે ટર્ન સર્વર્સ, વેબ બ્રિજ સર્વર્સ અને રેકોર્ડર્સ પણ કૉલ બ્રિજ જૂથોને સોંપી શકાય છે જેથી તેઓ શ્રેષ્ઠ ઉપયોગ માટે યોગ્ય રીતે જૂથબદ્ધ થઈ શકે. જો આમાંના કોઈપણ ઑબ્જેક્ટ કૉલ જૂથને અસાઇન કરવામાં આવ્યાં નથી, તો તે કોઈ ચોક્કસ પ્રાથમિકતા વિના બધા સર્વર્સ માટે ઉપલબ્ધ હોવાનું માનવામાં આવે છે.

આ પરિમાણો અહીં ગોઠવેલ છે: cms.example.com:445/api/v1/system/configuration/cluster

આગળ, અમે દરેક કૉલબ્રિજને સૂચવીએ છીએ કે તે કયા કૉલબ્રિજ જૂથનો છે:

પ્રથમ કોલબ્રિજ

બીજો કોલબ્રિજ

ત્રીજો કોલબ્રિજ


આમ, અમે સિસ્કો મીટિંગ સર્વર ક્લસ્ટરના સંસાધનોનો વધુ અસરકારક રીતે ઉપયોગ કરવા માટે કૉલ બ્રિડિજ જૂથને ગોઠવ્યું છે.

સક્રિય ડિરેક્ટરીમાંથી વપરાશકર્તાઓને આયાત કરી રહ્યાં છે

વેબ એડમિન સેવામાં LDAP રૂપરેખાંકન વિભાગ છે, પરંતુ તે જટિલ રૂપરેખાંકન વિકલ્પો પ્રદાન કરતું નથી, અને માહિતી ક્લસ્ટર ડેટાબેઝમાં સંગ્રહિત નથી, તેથી રૂપરેખાંકન કરવું પડશે, કાં તો વેબ ઈન્ટરફેસ દ્વારા દરેક સર્વર પર મેન્યુઅલી, અથવા મારફતે. API, અને તેથી અમે "ત્રણ વખત "ઉઠશો નહીં" અમે હજી પણ API દ્વારા ડેટા સેટ કરીશું.

ઍક્સેસ કરવા માટે URL નો ઉપયોગ કરવો cms01.example.com:445/api/v1/ldapServers LDAP સર્વર ઑબ્જેક્ટ બનાવે છે, પરિમાણોનો ઉલ્લેખ કરે છે જેમ કે:

• સર્વર IP
• પોર્ટ નંબર
• વપરાશકર્તા નામ
• પાસવર્ડ
• સુરક્ષિત

સુરક્ષિત - પોર્ટના આધારે સાચું કે ખોટું પસંદ કરો, 389 - સુરક્ષિત નથી, 636 - સુરક્ષિત.


સિસ્કો મીટિંગ સર્વરમાં વિશેષતાઓ માટે LDAP સ્ત્રોત પરિમાણોનું મેપિંગ.
LDAP મેપિંગ LDAP ડિરેક્ટરીમાંના લક્ષણોને CMS માંના લક્ષણો સાથે મેપ કરે છે. વાસ્તવિક લક્ષણો:

• jidMapping
• નેમમેપિંગ
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

લક્ષણોનું વર્ણનજેઆઈડી CMS માં વપરાશકર્તાના લોગિન ID ને રજૂ કરે છે. આ માઇક્રોસોફ્ટ એક્ટિવ ડિરેક્ટરી LDAP સર્વર હોવાથી, CMS JID LDAP માં sAMAccountName સાથે મેપ કરે છે, જે અનિવાર્યપણે વપરાશકર્તાની એક્ટિવ ડિરેક્ટરી લૉગિન ID છે. એ પણ નોંધ કરો કે તમે sAMAccountName લો અને તેના અંતમાં ડોમેન conf.pod6.cms.lab ઉમેરો કારણ કે આ તે લોગીન છે જેનો ઉપયોગ તમારા વપરાશકર્તાઓ CMS માં લૉગ ઇન કરવા માટે કરશે.

નેમમેપિંગ સક્રિય ડિરેક્ટરી ડિસ્પ્લેનામ ફીલ્ડમાં જે સમાયેલ છે તે વપરાશકર્તાના CMS નામ ફીલ્ડ સાથે મેળ ખાય છે.

coSpaceNameMapping ડિસ્પ્લેનામ ફીલ્ડ પર આધારિત CMS સ્પેસ નામ બનાવે છે. આ લક્ષણ, coSpaceUriMapping વિશેષતા સાથે, દરેક વપરાશકર્તા માટે જગ્યા બનાવવા માટે જરૂરી છે.

coSpaceUriMapping વપરાશકર્તાની વ્યક્તિગત જગ્યા સાથે સંકળાયેલ URI ના વપરાશકર્તા ભાગને વ્યાખ્યાયિત કરે છે. કેટલાક ડોમેન્સ સ્પેસમાં ડાયલ કરવા માટે ગોઠવી શકાય છે. જો વપરાશકર્તાનો ભાગ આ ડોમેન્સમાંથી એક માટે આ ફીલ્ડ સાથે મેળ ખાતો હોય, તો કૉલ તે વપરાશકર્તાની જગ્યા પર નિર્દેશિત કરવામાં આવશે.

coSpaceSecondaryUriMapping જગ્યા સુધી પહોંચવા માટે બીજા URI ને વ્યાખ્યાયિત કરે છે. આનો ઉપયોગ coSpaceUriMapping પેરામીટરમાં વ્યાખ્યાયિત આલ્ફાન્યૂમેરિક URIના વિકલ્પ તરીકે આયાત કરેલ વપરાશકર્તાની સ્પેસમાં રૂટીંગ કોલ્સ માટે આંકડાકીય ઉપનામ ઉમેરવા માટે થઈ શકે છે.

LDAP સર્વર અને LDAP મેપિંગ ગોઠવેલ છે. હવે તમારે LDAP સ્ત્રોત બનાવીને તેમને એકસાથે લિંક કરવાની જરૂર છે.

ઍક્સેસ કરવા માટે URL નો ઉપયોગ કરવો cms01.example.com:445/api/v1/ldapSource એક LDAP સ્ત્રોત ઑબ્જેક્ટ બનાવો, પરિમાણોનો ઉલ્લેખ કરીને જેમ કે:

• સર્વર
• મેપિંગ
• baseDn
• ફિલ્ટર

હવે જ્યારે LDAP રૂપરેખાંકન પૂર્ણ થયું છે, તો તમે મેન્યુઅલ સિંક્રોનાઇઝેશન કામગીરી કરી શકો છો.

અમે આ દરેક સર્વરના વેબ ઈન્ટરફેસમાં ક્લિક કરીને કરીએ છીએ હમણાં સમન્વયિત કરો કલમ સક્રિય માર્ગદર્શન


અથવા આદેશ સાથે API દ્વારા પોસ્ટ ઍક્સેસ કરવા માટે URL નો ઉપયોગ કરીને cms01.example.com:445/api/v1/ldapSyncs

એડ-હોક પરિષદો

આ શું છે?પરંપરાગત ખ્યાલમાં, કોન્ફરન્સ એ છે જ્યારે બે સહભાગીઓ એકબીજા સાથે વાત કરતા હોય, અને સહભાગીઓમાંથી એક (યુનિફાઈડ સીએમ સાથે નોંધાયેલ ઉપકરણનો ઉપયોગ કરીને) "કોન્ફરન્સ" બટન દબાવે છે, બીજી વ્યક્તિને કૉલ કરે છે અને તે ત્રીજા પક્ષ સાથે વાત કર્યા પછી , ત્રિપક્ષીય પરિષદમાં બધા સહભાગીઓને જોડવા માટે ફરીથી "કોન્ફરન્સ" બટન દબાવો.

એડ-હોક કોન્ફરન્સને સીએમએસમાં સુનિશ્ચિત કોન્ફરન્સથી શું અલગ પાડે છે તે એ છે કે એડ-હોક કોન્ફરન્સ એ સીએમએસ માટે માત્ર એક SIP કૉલ નથી. જ્યારે કોન્ફરન્સ આરંભ કરનાર દરેકને સમાન મીટિંગમાં આમંત્રિત કરવા માટે બીજી વખત કોન્ફરન્સ બટનને ક્લિક કરે છે, ત્યારે યુનિફાઇડ સીએમએ ઑન-ધ-ફ્લાય કોન્ફરન્સ બનાવવા માટે CMS પર API કૉલ કરવો આવશ્યક છે જેમાં તમામ કૉલ્સ ટ્રાન્સફર કરવામાં આવે છે. આ બધું સહભાગીઓના ધ્યાન વિના થાય છે.

આનો અર્થ એ છે કે યુનિફાઇડ સીએમ એ કૉલ ચાલુ રાખવા માટે API ઓળખપત્રો અને સેવાના વેબએડમિન સરનામા/પોર્ટ તેમજ SIP ટ્રંકને સીધા CMS સર્વર પર ગોઠવવું આવશ્યક છે.

જો જરૂરી હોય તો, CUCM ગતિશીલ રીતે CMS માં એક જગ્યા બનાવી શકે છે જેથી કરીને દરેક કૉલ CMS સુધી પહોંચી શકે અને સ્પેસ માટે બનાવાયેલ ઇનકમિંગ કૉલ નિયમ સાથે મેળ ખાય.

CUCM સાથે એકીકરણ લેખમાં વર્ણવ્યા પ્રમાણે તે જ રીતે ગોઠવેલ છે અગાઉ સિસ્કો યુસીએમ પર તમારે સીએમએસ માટે ત્રણ ટ્રંક બનાવવાની જરૂર છે, ત્રણ કોન્ફરન્સ બ્રિજ, એસઆઈપી સુરક્ષા પ્રોફાઇલમાં ત્રણ વિષયના નામો, રૂટ જૂથો, રૂટ સૂચિઓ, મીડિયા રિસોર્સ જૂથો અને મીડિયા રિસોર્સ જૂથ સૂચિનો ઉલ્લેખ કરો અને થોડા રૂટીંગ નિયમો ઉમેરો. સિસ્કો મીટિંગ સર્વર પર.

SIP સુરક્ષા પ્રોફાઇલ:


થડ:


દરેક થડ સમાન દેખાય છે:




કોન્ફરન્સ બ્રિજ


દરેક કોન્ફરન્સ બ્રિજ સમાન દેખાય છે:


રૂટ ગ્રુપ


રૂટ યાદી


મીડિયા સંસાધન જૂથ


મીડિયા સંસાધન જૂથ સૂચિ

કૉલ નિયમો

યુનિફાઇડ સીએમ અથવા એક્સપ્રેસવે જેવી વધુ અદ્યતન કૉલ મેનેજમેન્ટ સિસ્ટમ્સથી વિપરીત, સીએમએસ ફક્ત નવા કૉલ્સ માટે એસઆઈપી વિનંતી-યુઆરઆઈ ફીલ્ડમાં ડોમેન જુએ છે. તેથી જો SIP INVITE ચુસક માટે છે: [ઇમેઇલ સુરક્ષિત]CMS માત્ર domain.com ની જ કાળજી રાખે છે. કૉલ ક્યાં રૂટ કરવો તે નક્કી કરવા માટે CMS આ નિયમોનું પાલન કરે છે:

1. CMS પ્રથમ SIP ડોમેનને ઇનકમિંગ કોલ નિયમોમાં ગોઠવેલા ડોમેન્સ સાથે મેચ કરવાનો પ્રયાસ કરે છે. આ કૉલ્સ પછી ("લક્ષિત") જગ્યાઓ અથવા ચોક્કસ વપરાશકર્તાઓ, આંતરિક IVR અથવા સીધા સંકલિત Microsoft Lync/Skype for Business (S4B) ગંતવ્ય સ્થાનો પર રૂટ કરી શકાય છે.
2. જો ઇનકમિંગ કૉલ નિયમોમાં કોઈ મેળ ન હોય, તો CMS કૉલ ફોરવર્ડિંગ કોષ્ટકમાં ગોઠવેલા ડોમેન સાથે મેચ કરવાનો પ્રયાસ કરશે. જો મેચ કરવામાં આવે છે, તો નિયમ સ્પષ્ટપણે કૉલને નકારી શકે છે અથવા કૉલને ફોરવર્ડ કરી શકે છે. આ સમયે, CMS ડોમેનને ફરીથી લખી શકે છે, જે ક્યારેક Lync ડોમેન્સને કૉલ કરવા માટે ઉપયોગી છે. તમે થ્રો પાસ કરવાનું પણ પસંદ કરી શકો છો, જેનો અર્થ છે કે કોઈપણ ફીલ્ડમાં વધુ ફેરફાર કરવામાં આવશે નહીં અથવા આંતરિક CMS ડાયલ પ્લાનનો ઉપયોગ કરવામાં આવશે. જો કૉલ ફોરવર્ડિંગ નિયમોમાં કોઈ મેળ ન હોય, તો ડિફોલ્ટ કૉલને નકારવા માટે છે. ધ્યાનમાં રાખો કે CMS માં, જો કે કૉલ "ફોરવર્ડ કરેલ છે", મીડિયા હજુ પણ CMS સાથે બંધાયેલ છે, જેનો અર્થ છે કે તે સિગ્નલિંગ અને મીડિયા ટ્રાફિક પાથમાં હશે.
પછી માત્ર ફોરવર્ડ કરેલા કોલ જ આઉટગોઇંગ કોલ નિયમોને આધીન છે. આ સેટિંગ્સ નિર્ધારિત કરે છે કે જ્યાં કૉલ્સ મોકલવામાં આવે છે, ટ્રંક પ્રકાર (પછી તે નવો Lync કૉલ હોય કે પ્રમાણભૂત SIP કૉલ હોય), અને કૉલ ફોરવર્ડિંગ નિયમમાં ટ્રાન્સફર પસંદ ન કરવામાં આવે તો કરી શકાય તેવા કોઈપણ રૂપાંતરણો.

એડ-હોક કોન્ફરન્સ દરમિયાન શું થાય છે તેનો વાસ્તવિક લોગ અહીં છે

સ્ક્રીનશૉટ તેને ખરાબ રીતે બતાવે છે (મને ખબર નથી કે તેને કેવી રીતે વધુ સારું બનાવવું), તેથી હું આ રીતે લોગ લખીશ:

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

એડ-હોક કોન્ફરન્સ પોતે:


ઇનકમિંગ કૉલ નિયમો
CMS માં કૉલ પ્રાપ્ત કરવા માટે સક્ષમ થવા માટે ઇનકમિંગ કૉલ્સના પરિમાણોને ગોઠવવું જરૂરી છે. જેમ તમે LDAP સેટઅપમાં જોયું તેમ, બધા વપરાશકર્તાઓ ડોમેન conf.pod6.cms.lab સાથે આયાત કરવામાં આવ્યા હતા. તેથી ઓછામાં ઓછા, તમે આ ડોમેન પર સ્પેસને લક્ષ્ય બનાવવા માટે કૉલ કરવા માંગો છો. તમારે દરેક CMS સર્વરના સંપૂર્ણ લાયકાત ધરાવતા ડોમેન નામ (અને કદાચ IP સરનામું પણ) માટે બનાવાયેલ દરેક વસ્તુ માટે નિયમો સેટ કરવાની જરૂર પડશે. અમારું બાહ્ય કૉલ નિયંત્રણ, યુનિફાઇડ સીએમ, દરેક CMS સર્વરને વ્યક્તિગત રીતે સમર્પિત SIP ટ્રંકને ગોઠવશે. આ SIP ટ્રંક્સનું ગંતવ્ય IP સરનામું છે કે કેમ તેના આધારે સર્વરનું FQDN નક્કી કરશે કે CMS ને તેના IP સરનામાં અથવા FQDN પર નિર્દેશિત કૉલ્સ સ્વીકારવા માટે રૂપરેખાંકિત કરવાની જરૂર છે કે કેમ.

જે ડોમેનમાં સૌથી વધુ પ્રાધાન્યતા ઇનબાઉન્ડ નિયમ હોય છે તેનો ઉપયોગ કોઈપણ વપરાશકર્તા જગ્યાઓ માટે ડોમેન તરીકે થાય છે. જ્યારે વપરાશકર્તાઓ LDAP દ્વારા સમન્વયિત થાય છે, ત્યારે CMS આપોઆપ જગ્યાઓ બનાવે છે, પરંતુ માત્ર URI (coSpaceUriMapping), ઉદાહરણ તરીકે, user.space. ભાગ ડોમેન આ નિયમના આધારે સંપૂર્ણ URI જનરેટ થાય છે. વાસ્તવમાં, જો તમે આ સમયે વેબ બ્રિજમાં લૉગ ઇન કરો છો, તો તમે જોશો કે સ્પેસ URI પાસે ડોમેન નથી. આ નિયમને સર્વોચ્ચ અગ્રતા તરીકે સેટ કરીને, તમે જનરેટ થયેલ જગ્યાઓ માટે ડોમેન સેટ કરી રહ્યાં છો conf.example.com.


આઉટગોઇંગ કોલ નિયમો

યુનિફાઇડ CM ક્લસ્ટર પર આઉટબાઉન્ડ કૉલ કરવા માટે વપરાશકર્તાઓને મંજૂરી આપવા માટે, તમારે આઉટબાઉન્ડ નિયમો ગોઠવવા આવશ્યક છે. યુનિફાઇડ સીએમ સાથે નોંધાયેલ એન્ડપોઇન્ટ્સનું ડોમેન, જેમ કે જબર, example.com છે. આ ડોમેન પરના કૉલ્સને સ્ટાન્ડર્ડ SIP કૉલ્સ તરીકે યુનિફાઇડ CM કૉલ પ્રોસેસિંગ નોડ્સ પર રૂટ કરવા જોઈએ. મુખ્ય સર્વર cucm-01.example.com છે, અને વધારાનું સર્વર cucm-02.example.com છે.

પ્રથમ નિયમ ક્લસ્ટર સર્વર્સ વચ્ચેના કૉલ્સના સૌથી સરળ રૂટીંગનું વર્ણન કરે છે.

ક્ષેત્ર ડોમેનથી સ્થાનિક કૉલરના SIP-URIમાં જે વ્યક્તિને “@” પ્રતીક પછી કૉલ કરવામાં આવશે તેના માટે તે જવાબદાર છે. જો આપણે તેને ખાલી છોડી દઈએ, તો પછી “@” ચિહ્ન પછી CUCM નું IP સરનામું હશે જેના દ્વારા આ કૉલ પસાર થાય છે. જો આપણે ડોમેનનો ઉલ્લેખ કરીએ, તો પછી “@” પ્રતીક પછી ખરેખર એક ડોમેન હશે. પાછા કૉલ કરવા માટે સક્ષમ થવા માટે આ જરૂરી છે, અન્યથા SIP-URI name@ip-address દ્વારા પાછા કૉલ કરવાનું શક્ય બનશે નહીં.

જ્યારે ઉલ્લેખિત હોય ત્યારે કૉલ કરો ડોમેનથી સ્થાનિક


જ્યારે કૉલ કરો ના સંકેત ડોમેનથી સ્થાનિક


આઉટગોઇંગ કૉલ્સ માટે સ્પષ્ટપણે એન્ક્રિપ્ટેડ અથવા અનએન્ક્રિપ્ટેડનો ઉલ્લેખ કરવાની ખાતરી કરો, કારણ કે ઑટો પેરામીટર સાથે કંઈ કામ કરતું નથી.

રેકોર્ડિંગ

વિડિયો કોન્ફરન્સ રેકોર્ડ સર્વર દ્વારા રેકોર્ડ કરવામાં આવે છે. રેકોર્ડર બરાબર સિસ્કો મીટિંગ સર્વર જેવું જ છે. રેકોર્ડરને કોઈપણ લાઇસન્સ ઇન્સ્ટોલ કરવાની જરૂર નથી. કૉલબ્રિજ સેવાઓ ચલાવતા સર્વર્સ માટે રેકોર્ડિંગ લાઇસન્સ જરૂરી છે, એટલે કે. રેકોર્ડિંગ લાઇસન્સ આવશ્યક છે અને તે કૉલબ્રિજ ઘટક પર લાગુ થવું જોઈએ, અને જ્યાં રેકોર્ડર ચાલી રહ્યું છે તે સર્વર પર નહીં. રેકોર્ડર એક્સ્ટેન્સિબલ મેસેજિંગ એન્ડ પ્રેઝન્સ પ્રોટોકોલ (XMPP) ક્લાયન્ટ તરીકે વર્તે છે, તેથી XMPP સર્વર હોસ્ટિંગ CallBridge પર સક્ષમ હોવું આવશ્યક છે.

કારણ કે અમારી પાસે એક ક્લસ્ટર છે અને ક્લસ્ટરના ત્રણેય સર્વર પર લાયસન્સ "વિસ્તરેલું" હોવું જરૂરી છે. પછી ફક્ત તમારા વ્યક્તિગત ખાતામાં અમે ક્લસ્ટરમાં સમાવિષ્ટ તમામ CMS સર્વર્સના એ-ઇંટરફેસના MAC એડ્રેસને સાંકળીએ છીએ (ઉમેરો)

અને આ તે ચિત્ર છે જે ક્લસ્ટરના દરેક સર્વર પર હોવું જોઈએ

સામાન્ય રીતે, રેકોર્ડર મૂકવા માટે ઘણા દૃશ્યો છે, પરંતુ અમે આને વળગી રહીશું:


રેકોર્ડર સેટ કરતા પહેલા, તમારે એવી જગ્યા તૈયાર કરવાની જરૂર છે જ્યાં વિડિયો કોન્ફરન્સ ખરેખર રેકોર્ડ કરવામાં આવશે. ખરેખર અહીં ссылка, તમામ રેકોર્ડિંગ કેવી રીતે સેટ કરવું. હું મહત્વપૂર્ણ મુદ્દાઓ અને વિગતો પર ધ્યાન કેન્દ્રિત કરું છું:

1. ક્લસ્ટરમાં પ્રથમ સર્વરમાંથી પ્રમાણપત્ર કાપવું વધુ સારું છે.
2. "રેકોર્ડર અનુપલબ્ધ" ભૂલ આવી શકે છે કારણ કે રેકોર્ડર ટ્રસ્ટમાં ખોટું પ્રમાણપત્ર નિર્દિષ્ટ કરવામાં આવ્યું છે.
3. જો રેકોર્ડીંગ માટે સ્પષ્ટ કરેલ NFS ડિરેક્ટરી રૂટ ડિરેક્ટરી ન હોય તો લેખન કામ કરી શકશે નહીં.

કેટલીકવાર કોઈ ચોક્કસ વપરાશકર્તા અથવા જગ્યાની કોન્ફરન્સને આપમેળે રેકોર્ડ કરવાની જરૂર હોય છે.

આ માટે, બે કૉલપ્રોફાઈલ્સ બનાવવામાં આવી છે:
રેકોર્ડિંગ અક્ષમ સાથે


અને આપોઆપ રેકોર્ડિંગ કાર્ય સાથે


આગળ, અમે જરૂરી જગ્યામાં સ્વચાલિત રેકોર્ડિંગ કાર્ય સાથે કૉલપ્રોફાઈલને "જોડીએ છીએ".


CMS માં તે એટલું સ્થાપિત છે કે જો કૉલપ્રોફાઈલ સ્પષ્ટપણે કોઈપણ જગ્યા અથવા જગ્યા સાથે જોડાયેલી હોય, તો આ કૉલપ્રોફાઈલ ફક્ત આ ચોક્કસ જગ્યાઓના સંબંધમાં જ કાર્ય કરે છે. અને જો કૉલપ્રોફાઈલ કોઈપણ જગ્યા સાથે બંધાયેલ નથી, તો ડિફૉલ્ટ રૂપે તે તે જગ્યાઓ પર લાગુ થાય છે જ્યાં કોઈ કૉલપ્રોફાઈલ સ્પષ્ટપણે બંધાયેલ નથી.

આગલી વખતે હું સંસ્થાના આંતરિક નેટવર્કની બહાર 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-later. પીડીએફ

સોર્સ: www.habr.com