සිස්කෝ රැස්වීම් සේවාදායකය 2.5.2. වීඩියෝ සම්මන්ත්‍රණ පටිගත කිරීමේ කාර්යය සමඟ පරිමාණය කළ හැකි සහ ප්‍රත්‍යස්ථ මාදිලියේ පොකුර

මෙම නිකුතුවේදී මම CMS සේවාදායකයක් අසාර්ථක පොකුරු ආකාරයෙන් සැකසීමේ සංකීර්ණතා කිහිපයක් පෙන්වා පැහැදිලි කරමි.


න්‍යායසාමාන්‍යයෙන්, CMS සේවාදායක යෙදවුම් වර්ග තුනක් තිබේ:

• තනි ඒකාබද්ධ(තනි ඒකාබද්ධ), i.e. මෙය අවශ්‍ය සියලුම සේවාවන් ක්‍රියාත්මක වන එක් සේවාදායකයකි. බොහෝ අවස්ථාවන්හිදී, මෙම ආකාරයේ යෙදවීම සුදුසු වන්නේ අභ්‍යන්තර සේවාදායක ප්‍රවේශය සඳහා සහ තනි සේවාදායකයක පරිමාණය සහ අතිරික්ත සීමාවන් තීරණාත්මක ගැටළුවක් නොවන කුඩා පරිසරයක හෝ CMS විසින් තාවකාලික වැනි ඇතැම් කාර්යයන් පමණක් සිදු කරන අවස්ථාවන්හිදී පමණි. Cisco UCM පිළිබඳ සම්මන්ත්‍රණ.

  වැඩ කිරීමේ ආසන්න යෝජනා ක්රමය:
  

• තනි භේදය(Single Split) බාහිර ප්‍රවේශය සඳහා වෙනම සේවාදායකයක් එක් කිරීමෙන් පෙර යෙදවුම් වර්ගය දිගු කරයි. උරුම යෙදවීම් වලදී, මෙයින් අදහස් කළේ බාහිර සේවාලාභීන්ට ප්‍රවේශ විය හැකි හමුදාකරණය කළ ජාල කොටසක (DMZ) CMS සේවාදායකයක් යෙදවීම සහ අභ්‍යන්තර සේවාදායකයින්ට CMS වෙත ප්‍රවේශ විය හැකි ජාල හරයේ එක් CMS සේවාදායකයක් යෙදවීමයි. මෙම විශේෂිත යෙදවුම් ආකෘතිය දැන් ඊනියා වර්ගය මගින් ආදේශ කරනු ලැබේ තනි දාරය, සර්වර් වලින් සමන්විත වේ සිස්කෝ අධිවේගී මාර්ගය, එකම ෆයර්වෝල් බයිපාස් හැකියාවන් බොහෝමයක් ඇති හෝ ඇති බැවින් සේවාදායකයින්ට කැපවූ එජ් CMS සේවාදායකයක් එක් කිරීමට අවශ්‍ය නොවේ.

  වැඩ කිරීමේ ආසන්න යෝජනා ක්රමය:
  

• පරිමාණය කළ හැකි සහ ඔරොත්තු දෙන(පරිමාණය කළ හැකි සහ දෝෂ ඉවසිය හැකි) මෙම වර්ගයට එක් එක් සංරචක සඳහා අතිරික්තය ඇතුළත් වන අතර, අසාර්ථක වූ විට අතිරික්තය සපයන අතරම ඔබේ අවශ්‍යතා සමඟ එහි උපරිම ධාරිතාව දක්වා වර්ධනය වීමට පද්ධතියට ඉඩ සලසයි. එය ආරක්ෂිත බාහිර ප්‍රවේශය සැපයීම සඳහා Single Edge සංකල්පය ද භාවිතා කරයි. මේ කතාංගයේ අපි බලමු මේ වර්ගය. මෙම වර්ගයේ පොකුරක් යෙදවිය යුතු ආකාරය අපි තේරුම් ගන්නේ නම්, අපි වෙනත් ආකාරයේ යෙදවීම් තේරුම් ගන්නවා පමණක් නොව, ඉල්ලුමේ විභව වර්ධනයට අනුගත වීම සඳහා CMS සේවාදායක පොකුරු නිර්මාණය කරන්නේ කෙසේද යන්න තේරුම් ගැනීමට අපට හැකි වනු ඇත.

යෙදවීම වෙත යාමට පෙර, ඔබ මූලික කරුණු කිහිපයක් තේරුම් ගත යුතුය, එනම්

ප්රධාන CMS මෘදුකාංග සංරචක:

• දත්ත සමුදාය: ඩයල් සැලැස්ම, පරිශීලක අවකාශයන්, සහ පරිශීලකයන්ම වැනි සමහර වින්‍යාසයන් ඒකාබද්ධ කිරීමට ඔබට ඉඩ සලසයි. ඉහළ ලබා ගත හැකි (තනි මාස්ටර්) සඳහා පමණක් පොකුරු සඳහා සහය දක්වයි.
• පාලම අමතන්න: ඇමතුම් සහ බහුමාධ්‍ය ක්‍රියාවලි කළමනාකරණය සහ සැකසීම පිළිබඳ පූර්ණ පාලනය සපයන ශ්‍රව්‍ය සහ දෘශ්‍ය සම්මන්ත්‍රණ සඳහා වූ සේවාවකි. ඉහළ ලබා ගැනීමේ හැකියාව සහ පරිමාණය සඳහා පොකුරු සඳහා සහය දක්වයි.
• XMPP සේවාදායකය: Cisco Meeting Application සහ/හෝ WebRTC(වෙබ්ආර්ටීසී) භාවිතා කරන සේවාලාභීන් ලියාපදිංචි කිරීම සහ සත්‍යාපනය කිරීම සඳහා වගකිව යුතුය.තත්‍ය කාලීන සන්නිවේදනය, හෝ සරලව බ්‍රවුසරයේ), මෙන්ම අන්තර් සංරචක සංඥා කිරීම. ඉහළ ලබා ගැනීම සඳහා පමණක් පොකුරු කළ හැක.
• වෙබ් පාලම: WebRTC වෙත සේවාදායක ප්‍රවේශය සපයයි.
• ලෝඩ් බැලන්සර්: Single Split මාදිලියේ Cisco Meeting Apps සඳහා තනි සම්බන්ධතා ලක්ෂයක් සපයයි. පැමිණෙන සම්බන්ධතා සඳහා බාහිර අතුරු මුහුණත සහ වරායට සවන් දෙයි. ඒ හා සමානව, පැටවුම් සමතුලිතකය XMPP සේවාදායකයෙන් ලැබෙන TLS සම්බන්ධතා පිළිගනී, එමඟින් බාහිර සේවාදායකයින්ගෙන් TCP සම්බන්ධතා මාරු කළ හැකිය.
  අපගේ තත්වය තුළ එය අවශ්ය නොවනු ඇත.
• TURN සේවාදායකය: ඉඩ දෙන Firewall බයිපාස් තාක්ෂණය සපයයි
  Cisco Meeting App හෝ SIP උපාංග භාවිතයෙන් බාහිර සේවාලාභීන් සම්බන්ධ කිරීමට Firewall හෝ NAT පිටුපස අපගේ CMS තබන්න. අපගේ තත්වය තුළ එය අවශ්ය නොවනු ඇත.
• වෙබ් පරිපාලක: විශේෂ ඒකාබද්ධ CM සම්මන්ත්‍රණ සඳහා ඇතුළුව පරිපාලන අතුරුමුහුණත සහ API ප්‍රවේශය.

මානකරන මාතයන්

අනෙකුත් බොහෝ Cisco නිෂ්පාදන මෙන් නොව, Cisco Meeting Server ඕනෑම ආකාරයක යෙදවීමක් සඳහා වින්‍යාස කිරීමේ ක්‍රම තුනකට සහය දක්වයි.

• විධාන රේඛාව (CLI): මූලික වින්‍යාස කිරීම් සහ සහතික කාර්යයන් සඳහා MMP ලෙස හඳුන්වන විධාන රේඛා අතුරුමුහුණත.
• වෙබ් පරිපාලක: මූලික වශයෙන් CallBridge ආශ්‍රිත වින්‍යාසයන් සඳහා, විශේෂයෙන්ම තනි පොකුරු නොවන සේවාදායකයක් පිහිටුවීමේදී.
• REST API: වඩාත් සංකීර්ණ වින්‍යාසකරණ කාර්යයන් සහ පොකුරු දත්ත සමුදාය සම්බන්ධ කාර්යයන් සඳහා භාවිතා වේ.

ඉහත කරුණු වලට අමතරව, ප්රොටෝකෝලය භාවිතා වේ SFTP ගොනු-සාමාන්‍යයෙන් බලපත්‍ර, සහතික, හෝ ලොග්-CMS සේවාදායකය වෙත සහ එයින් මාරු කිරීමට.

Cisco වෙතින් විහිදුම් මාර්ගෝපදේශවල පොකුර යෙදවිය යුතු බව සුදු සහ ඉංග්‍රීසියෙන් ලියා ඇත. අවම වශයෙන් තුනක් දත්ත සමුදා සන්දර්භය තුළ සේවාදායකයන් (නෝඩ්). නිසා නව Database Master එකක් තෝරාගැනීමේ යාන්ත්‍රණය ක්‍රියා කරන්නේ ඔත්තේ නෝඩ් සංඛ්‍යාවක් සමඟ පමණක් වන අතර සාමාන්‍යයෙන් Database Master හට බොහෝ CMS සේවාදායක දත්ත ගබඩාව සමඟ සම්බන්ධයක් ඇත.

ප්රායෝගිකව පෙන්නුම් කරන පරිදි, සේවාදායකයන් දෙකක් (නෝඩ්) ඇත්තෙන්ම ප්රමාණවත් නොවේ. තේරීම් යාන්ත්‍රණය ක්‍රියාත්මක වන්නේ Master නැවත පණගැන්වූ විට, Slave සේවාදායකය Master බවට පත්වන්නේ නැවත පණගැන්වූ සේවාදායකය ගෙන ආ පසුවය. කෙසේ වෙතත්, සේවාදායකයන් දෙකක පොකුරක් තුළ මාස්ටර් සේවාදායකය හදිසියේ ක්‍රියා විරහිත වුවහොත්, ස්ලේව් සේවාදායකය මාස්ටර් බවට පත් නොවනු ඇති අතර, ස්ලේව් පිටතට ගියහොත්, ඉතිරි ප්‍රධාන සේවාදායකය ස්ලේව් බවට පත්වේ.

නමුත් XMPP හි සන්දර්භය තුළ, සේවාදායක තුනක පොකුරක් එකලස් කිරීම සැබවින්ම අවශ්‍ය වනු ඇත, මන්ද උදාහරණයක් ලෙස, ඔබ XMMP නායක තත්වයේ ඇති එක් සේවාදායකයක XMPP සේවාව අක්‍රිය කළහොත්, ඉතිරි සේවාදායකයේ XMPP අනුගාමික තත්ත්වයෙහි පවතිනු ඇති අතර XMPP වෙත CallBridge සම්බන්ධතා බිඳ වැටෙනු ඇත, මන්ද CallBridge නායක තත්ත්වය සමඟ XMPP වෙත පමණක් සම්බන්ධ වේ. මෙය තීරණාත්මක ය, මන්ද ... එක ඇමතුමක්වත් යන්නේ නැහැ.

එම යෙදවීමේ මාර්ගෝපදේශය තුළම එක් XMPP සේවාදායකයක් සහිත පොකුරක් පෙන්නුම් කෙරේ.

ඉහත කරුණු සැලකිල්ලට ගනිමින්, එයට හේතුව පැහැදිලි වේ: එය ක්‍රියා කරන්නේ එය අසාර්ථක මාදිලියේ ඇති බැවිනි.

අපගේ නඩුවේදී, XMPP සේවාදායකය නෝඩ් තුනේම පවතිනු ඇත.

අපේ සර්වර් තුනම ක්‍රියාත්මකයි කියලා උපකල්පනය කරනවා.

DNS වාර්තා

ඔබ සේවාදායකයන් පිහිටුවීම ආරම්භ කිරීමට පෙර, ඔබ DNS වාර්තා සෑදිය යුතුය А и එස්.ආර්.වී. වර්ග:

අපගේ DNS වාර්තා වල example.com සහ වසම් දෙකක් ඇති බව කරුණාවෙන් සලකන්න conf.example.com. Example.com යනු සියලුම Cisco Unified Communication Manager ග්‍රාහකයින්ට ඔවුන්ගේ URI සඳහා භාවිතා කළ හැකි වසමකි, එය ඔබගේ යටිතල ව්‍යූහය තුළ බොහෝ විට පවතින හෝ පවතින්නට ඉඩ ඇත. නැතහොත් example.com පරිශීලකයින් ඔවුන්ගේ ඊමේල් ලිපින සඳහා භාවිතා කරන වසමටම ගැලපේ. නැතහොත් ඔබගේ ලැප්ටොප් පරිගණකයේ ඇති Jabber සේවාලාභියාට URI එකක් තිබිය හැක [විද්‍යුත් ආරක්‍ෂිත]. වසම් conf.example.com යනු Cisco Meeting Server භාවිතා කරන්නන් සඳහා වින්‍යාස කෙරෙන වසම වේ. Cisco Meeting Server හි වසම වනු ඇත conf.example.com, එබැවින් එකම Jabber පරිශීලකයා සඳහා, Cisco Meeting Server වෙත ලොග් වීමට user@ URI භාවිතා කිරීමට අවශ්‍ය වනු ඇත.conf.example.com.

මූලික වින්යාසය

පහත විස්තර කර ඇති සියලුම සැකසුම් එක් සේවාදායකයක පෙන්වනු ලැබේ, නමුත් ඒවා පොකුරේ එක් එක් සේවාදායකයේ සිදු කළ යුතුය.

QoS

CMS ජනනය කරන බැවින් තත්ය කාලය ප්‍රමාදයන් සහ පැකට් අලාභයට සංවේදී වන රථවාහන, බොහෝ අවස්ථාවලදී සේවාවේ ගුණාත්මකභාවය (QoS) වින්‍යාස කිරීම නිර්දේශ කෙරේ. මෙය සාක්ෂාත් කර ගැනීම සඳහා, CMS එය උත්පාදනය කරන විවිධ සේවා කේත (DSCPs) සමඟ ටැග් කිරීමේ පැකට් සඳහා සහය දක්වයි. DSCP මත පදනම් වූ ගමනාගමන ප්‍රමුඛතාවය රඳා පවතින්නේ ඔබේ යටිතල ව්‍යුහයේ ජාල සංරචක මගින් ගමනාගමනය සකසන ආකාරය මත වුවද, අපගේ නඩුවේදී අපි QoS හොඳම භාවිතයන් මත පදනම්ව සාමාන්‍ය DSCP ප්‍රමුඛතාවයකින් අපගේ CMS වින්‍යාස කරන්නෙමු.

සෑම සේවාදායකයකම අපි මෙම විධානයන් ඇතුල් කරන්නෙමු

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 server add <server>

අපගේ නඩුවේදී, එවැනි සේවාදායකයන් දෙකක් ඇත, එබැවින් කණ්ඩායම් දෙකක් ඇත.
අපි පරීක්ෂා කරමු:

තවද අපගේ සේවාදායකය සඳහා කාල කලාපය සකසන්න

DNS

අපි එවැනි විධානයක් සමඟ CMS වෙත DNS සේවාදායකයන් එකතු කරමු:

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

අපගේ නඩුවේදී, එවැනි සේවාදායකයන් දෙකක් ඇත, එබැවින් කණ්ඩායම් දෙකක් ඇත.
අපි පරීක්ෂා කරමු:

ජාල අතුරුමුහුණත් වින්‍යාසය

අපි එවැනි විධානයක් සමඟ අතුරු මුහුණත වින්‍යාස කරමු:

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

අපි පරීක්ෂා කරමු:

සේවාදායකයේ නම (සත්කාරක නාමය)

අපි සේවාදායකයේ නම එවැනි විධානයකින් සකසන්නෙමු:

hostname <name>

තවද අපි නැවත ආරම්භ කරමු.


මෙය මූලික වින්‍යාසය සම්පූර්ණ කරයි.

සහතික

න්‍යායCisco Meeting Server හට විවිධ සංරචක අතර සංකේතාත්මක සන්නිවේදනයක් අවශ්‍ය වන අතර, එහි ප්‍රතිඵලයක් වශයෙන්, සියලුම CMS යෙදවීම් සඳහා X.509 සහතික අවශ්‍ය වේ. ඔවුන් සේවා/සේවාදායකය වෙනත් සේවාදායක/සේවා විසින් විශ්වාස කරන බව සහතික කිරීමට උදවු කරයි.

සෑම සේවාවක් සඳහාම සහතිකයක් අවශ්‍ය වේ, නමුත් එක් එක් සේවාව සඳහා වෙන වෙනම සහතික සෑදීම ව්‍යාකූලත්වයට හා අනවශ්‍ය සංකීර්ණත්වයට හේතු විය හැක. වාසනාවකට මෙන්, අපට සහතිකයක පොදු-පෞද්ගලික යතුරු යුගලයක් ජනනය කර ඒවා බහු සේවා හරහා නැවත භාවිත කළ හැක. අපගේ නඩුවේදී, Call Bridge, XMPP Server, Web Bridge සහ Web Admin සඳහා එකම සහතිකය භාවිතා කරනු ඇත. මේ අනුව, ඔබ පොකුරේ සෑම සේවාදායකයක් සඳහාම පොදු සහ පුද්ගලික සහතික යතුරු යුගලයක් සෑදිය යුතුය.

කෙසේ වෙතත්, දත්ත සමුදා පොකුරු සඳහා විශේෂ සහතික අවශ්‍යතා ඇති අතර එම නිසා අනෙකුත් සේවාවන්ට වඩා වෙනස් වන තමන්ගේම සහතික අවශ්‍ය වේ. CMS සේවාදායක සහතිකයක් භාවිතා කරයි, එය අනෙකුත් සේවාදායකයන් භාවිතා කරන සහතික වලට සමාන වේ, නමුත් දත්ත සමුදා සම්බන්ධතා සඳහා භාවිතා කරන සේවාදායක සහතිකයක් ද ඇත. දත්ත සමුදා සහතික සත්‍යාපනය සහ සංකේතනය යන දෙකටම භාවිතා වේ. සේවාදායකයාට දත්ත සමුදායට සම්බන්ධ වීමට පරිශීලක නාමයක් සහ මුරපදයක් ලබා දෙනවා වෙනුවට, එය සේවාදායකය විසින් විශ්වාස කරන සේවාදායක සහතිකයක් ඉදිරිපත් කරයි. දත්ත සමුදා පොකුරේ ඇති සෑම සේවාදායකයක්ම එකම පොදු සහ පුද්ගලික යතුරු යුගලයක් භාවිතා කරයි. මෙමගින් පොකුරේ ඇති සියලුම සේවාදායකයන්ට දත්ත සංකේතනය කිරීමට ඉඩ සලසයි, එය එකම යතුරු යුගලයක් බෙදා ගන්නා වෙනත් සේවාදායකයන්ට පමණක් විකේතනය කළ හැකිය.

වැඩ කිරීමට අතිරික්තය සඳහා, දත්ත සමුදා පොකුරු අවම වශයෙන් සේවාදායක 3 කින් සමන්විත විය යුතුය, නමුත් 5 ට වඩා වැඩි නොවිය යුතුය, ඕනෑම පොකුරු සාමාජිකයින් අතර උපරිම වට-සංචාර කාලය 200 ms වේ. මෙම සීමාව Call Bridge clustering වලට වඩා සීමා සහිත වේ, එබැවින් එය බොහෝ විට භූගෝලීය වශයෙන් බෙදා හරින ලද යෙදවීම් වල සීමාකාරී සාධකය වේ.

CMS සඳහා දත්ත සමුදා භූමිකාවට අනන්‍ය අවශ්‍යතා ගණනාවක් ඇත. අනෙකුත් භූමිකාවන් මෙන් නොව, එයට සේවාලාභියා සහ සේවාදායක සහතිකයක් අවශ්‍ය වේ, එහිදී සේවාදායක සහතිකයේ විශේෂිත CN ක්ෂේත්‍රයක් සේවාදායකය වෙත ඉදිරිපත් කෙරේ.

CMS එක මාස්ටර් එකක් සහ සම්පූර්ණයෙන්ම සමාන අනුරූ කිහිපයක් සහිත postgres දත්ත සමුදායක් භාවිතා කරයි. වරකට ඇත්තේ එක් ප්‍රාථමික දත්ත සමුදායක් පමණි ("දත්ත සමුදා සේවාදායකය"). පොකුරේ ඉතිරි සාමාජිකයන් අනුරූ හෝ "දත්ත සමුදා සේවාලාභීන්" වේ.

දත්ත සමුදා පොකුරක් සඳහා කැපවූ සේවාදායක සහතිකයක් සහ සේවාදායක සහතිකයක් අවශ්‍ය වේ. ඒවා සාමාන්‍යයෙන් අභ්‍යන්තර පුද්ගලික සහතික අධිකාරියක් වන සහතික මගින් අත්සන් කළ යුතුය. දත්ත සමුදා පොකුරේ ඕනෑම සාමාජිකයෙකුට ප්‍රධානියා විය හැකි බැවින්, දත්ත සමුදා සේවාදායකය සහ සේවාදායක සහතික යුගල (පොදු සහ පුද්ගලික යතුරු අඩංගු) සියලුම සේවාදායකයන් වෙත පිටපත් කළ යුතු අතර එමඟින් ඔවුන්ට සේවාදායකයාගේ හෝ දත්ත සමුදා සේවාදායකයාගේ අනන්‍යතාවය උපකල්පනය කළ හැකිය. ඊට අමතරව, සේවාලාභියා සහ සේවාදායක සහතික සත්‍යාපනය කළ හැකි බව සහතික කිරීම සඳහා 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. දත්ත සමුදාය සඳහා සහතික ("සේවාදායක" සහ "සේවාදායකයා") සහ "සේවාදායක" සහ "සේවාදායක" දත්ත සමුදා සහතික සඳහා ඉල්ලීමක් නිර්මාණය කිරීමේදී උත්පාදනය කරන ලද .key දිගුව සහිත ගොනු. මෙම ගොනු සියලුම සර්වර් වල සමාන විය යුතුය.
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 address පවතින CMS සේවාදායකයේ ප්‍රධාන ip ලිපිනය වන පොකුර ආරම්භ කරන ලද, සරලව Master.

විධානය සමඟ අපගේ දත්ත සමුදා පොකුර සියලුම සේවාදායකයන් මත ක්‍රියා කරන ආකාරය අපි පරීක්ෂා කරමු:

database cluster status

ඉතිරි තුන්වන සේවාදායකයේ අපි එයම කරමු.

එහි ප්‍රතිඵලයක් වශයෙන්, අපගේ පළමු සේවාදායකය මාස්ටර් බවත්, ඉතිරි අය වහලුන් බවත් පෙනී යයි.

වෙබ් පරිපාලක සේවාව

වෙබ් පරිපාලක සේවාව සබල කරන්න:

webadmin listen a 445

445 වරාය තෝරාගනු ලැබුවේ වෙබ් සේවාලාභියා වෙත පරිශීලක ප්‍රවේශය සඳහා 443 වරාය භාවිතා කරන බැවිනි

අපි එවැනි විධානයක් සමඟ සහතික ගොනු සමඟ වෙබ් පරිපාලක සේවාව වින්‍යාස කරමු:

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

සහ විධානය සමඟ වෙබ් පරිපාලක සක්‍රීය කරන්න:

webadmin enable

සියල්ල හොඳින් නම්, ජාලය සහ සහතිකය සඳහා Web Admin නිවැරදිව වින්‍යාස කර ඇති බව දැක්වෙන SUCCESS රේඛා අපට ලැබෙනු ඇත. අපි වෙබ් බ්‍රව්සරයක් භාවිතයෙන් සේවාවේ ක්‍රියාකාරිත්වය පරීක්ෂා කර වෙබ් පරිපාලකගේ ලිපිනය ඇතුළත් කරන්න, උදාහරණයක් ලෙස: cms.example.com: 445

පාලම් පොකුර අමතන්න

සෑම CMS යෙදවීමකම පවතින එකම සේවාව ඇමතුම් පාලමයි. Call Bridge යනු ප්‍රධාන සම්මන්ත්‍රණ යාන්ත්‍රණයයි. එය SIP අතුරුමුහුණතක් ද සපයන අතර, උදාහරණයක් ලෙස, Cisco Unified CM මගින් ඇමතුම් වෙත හෝ එයින් ඇමතුම් ලබා ගත හැක.

පහත විස්තර කර ඇති විධාන සුදුසු සහතික සමඟ එක් එක් සේවාදායකය මත ක්‍රියාත්මක කළ යුතුය.
ඉතින්:

අපි එවැනි විධානයක් සමඟ Call Bridge සේවාව සමඟ සහතික සම්බන්ධ කරමු:

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

අපි CallBridge සේවාවන් අපට අවශ්‍ය අතුරු මුහුණතට විධානය සමඟ සම්බන්ධ කරමු:

callbridge listen a

සහ විධානය සමඟ සේවාව නැවත ආරම්භ කරන්න:

callbridge restart

දැන් අපි අපේ Call Bridges වින්‍යාස කර ඇති නිසා, අපට Call Bridge clustering වින්‍යාසගත කළ හැක. Call Bridge clustering database හෝ XMPP clustering වලට වඩා වෙනස් වේ. Call Bridge Cluster කිසිදු සීමාවකින් තොරව නෝඩ් 2 සිට 8 දක්වා සහය දැක්විය හැක. එය අතිරික්තය පමණක් නොව, පූරණ තුලනය ද සපයයි, එවිට බුද්ධිමත් ඇමතුම් බෙදාහැරීම භාවිතයෙන් Call Bridge සේවාදායකයන් හරහා සම්මන්ත්‍රණ ක්‍රියාකාරීව බෙදා හැරිය හැක. CMS හි අමතර විශේෂාංග, Call Bridge කණ්ඩායම් සහ වැඩිදුර කළමනාකරණය සඳහා භාවිත කළ හැකි අදාළ විශේෂාංග ඇත.

Call bridge clustering මූලික වශයෙන් වෙබ් පරිපාලක අතුරුමුහුණත හරහා වින්‍යාස කර ඇත
පහත විස්තර කර ඇති ක්‍රියාපටිපාටිය පොකුරේ සෑම සේවාදායකයකම සිදු කළ යුතුය.
එසේ නම්,

1. වෙබය හරහා Configuration > Cluster වෙත යන්න.
2. දී පාලම් අනන්‍යතාවය අමතන්න අද්විතීය නමක් ලෙස, සේවාදායකයේ නමට අනුරූප වන callbridge[01,02,03] ඇතුලත් කරන්න. මෙම නම් අත්තනෝමතික ය, නමුත් මෙම පොකුර සඳහා අනන්‍ය විය යුතුය. ඒවා සර්වර් හඳුනාගැනීම් [01,02,03] බව පෙන්නුම් කරන නිසා ඒවා විස්තරාත්මක ස්වභාවයක් ගනී.
3.බී පොකුරු ඇමතුම් පාලම් පොකුරේ අපගේ සේවාදායකයන්ගේ වෙබ් පරිපාලක URL ඇතුළත් කරන්න, cms[01,02,03].example.com:445, ලිපින ක්ෂේත්‍රයේ. වරාය සඳහන් කිරීමට වග බලා ගන්න. ඔබට Peer සබැඳිය SIP වසම හිස්ව තැබිය හැක.
4. එක් එක් සේවාදායකයේ CallBridge භාරයට සහතිකයක් එක් කරන්න, එහි ගොනුවේ අපගේ සේවාදායකයන්ගේ සියලුම සහතික අඩංගු වේ, අපි ආරම්භයේදීම මෙම ගොනුවට ඒකාබද්ධ කළ, වැනි විධානයක් සමඟ:

callbridge trust cluster <trusted cluster certificate bundle>

සහ විධානය සමඟ සේවාව නැවත ආරම්භ කරන්න:

callbridge restart

ප්රතිඵලයක් වශයෙන්, සෑම සේවාදායකයකම ඔබට මෙම පින්තූරය ලබා ගත යුතුය:

XMPP පොකුර

CMS හි XMPP සේවාව CMA WebRTC වෙබ් සේවාලාභියා ඇතුළුව Cisco Meeting Apps (CMA) සඳහා සියලුම ලියාපදිංචිය සහ සත්‍යාපනය හැසිරවීමට භාවිතා කරයි. ඇමතුම් පාලම සත්‍යාපන අරමුණු සඳහා XMPP සේවාලාභියෙකු ලෙසද ක්‍රියා කරන අතර එම නිසා අනෙකුත් සේවාලාභීන් මෙන් වින්‍යාසගත කළ යුතුය. XMPP වැරදි ඉවසීම යනු 2.1 අනුවාදයේ සිට නිෂ්පාදන පරිසරයන්හි සහාය දක්වන විශේෂාංගයකි

පහත විස්තර කර ඇති විධාන සුදුසු සහතික සමඟ එක් එක් සේවාදායකය මත ක්‍රියාත්මක කළ යුතුය.
ඉතින්:

අපි මෙවැනි විධානයක් සමඟ XMPP සේවාව සමඟ සහතික සම්බන්ධ කරමු:

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

ඉන්පසු විධානය සමඟ සවන්දීමේ අතුරු මුහුණත නිර්වචනය කරන්න:

xmpp listen a

XMPP සේවාවට අනන්‍ය වසමක් අවශ්‍ය වේ. මෙය පරිශීලකයින් සඳහා වන පිවිසුමයි. වෙනත් වචන වලින් කිවහොත්, පරිශීලකයෙකු CMA යෙදුම භාවිතයෙන් (හෝ WebRTC සේවාලාභියා හරහා) පුරනය වීමට උත්සාහ කරන විට, ඔවුන් userID@logindomain ඇතුල් කරයි. අපගේ නඩුවේදී එය userid@ වනු ඇතconf.example.com. එය example.com පමණක් නොවන්නේ ඇයි? අපගේ විශේෂිත යෙදවීමේදී, අපි අපගේ Unified CM වසම තෝරා ගත්තෙමු, එය Jabber පරිශීලකයින් Unified CM හි example.com ලෙස භාවිත කරනු ඇත, එබැවින් CMS පරිශීලකයින්ට SIP වසම් හරහා CMS වෙත සහ ඉන් පිටතට ඇමතුම් යැවීමට අපට වෙනත් වසමක් අවශ්‍ය විය.

වැනි විධානයක් භාවිතා කරමින් XMPP වසමක් සකසන්න:

xmpp domain <domain>

විධානය සමඟ XMPP සේවාව සක්‍රීය කරන්න:

xmpp enable

XMPP සේවාව තුළ, ඔබ XMPP සේවාව සමඟ ලියාපදිංචි වන විට භාවිතා කරන සෑම ඇමතුම් පාලමක් සඳහාම අක්තපත්‍ර සෑදිය යුතුය. මෙම නම් අත්තනෝමතික වේ (සහ ඔබ ඇමතුම් පාලම් පොකුරු සඳහා වින්‍යාස කළ අද්විතීය නම්වලට සම්බන්ධ නොවේ). මෙම වින්‍යාසය පොකුරු දත්ත ගබඩාවට නොගැලපෙන නිසා ඔබ එක් XMPP සේවාදායකයක් මත ඇමතුම් පාලම් තුනක් එකතු කළ යුතු අතර පසුව එම අක්තපත්‍ර පොකුරේ ඇති අනෙකුත් XMPP සේවාදායකයන් වෙත ඇතුළත් කළ යුතුය. පසුව අපි එක් එක් ඇමතුම් පාලම XMPP සේවාව සමඟ ලියාපදිංචි වීමට මෙම නම සහ රහස භාවිතා කිරීමට වින්‍යාස කරන්නෙමු.

දැන් අපි Call Bridge01, callbridge02 සහ callbridge03 යන Call Bridges තුනකින් පළමු සේවාදායකයේ XMPP සේවාව වින්‍යාසගත කළ යුතුයි. සෑම ගිණුමකටම අහඹු මුරපද පවරනු ලැබේ. මෙම XMPP සේවාදායකයට ප්‍රවිෂ්ට වීමට ඒවා පසුව වෙනත් Call Bridge සේවාදායකයන් වෙත ඇතුළත් කරනු ඇත. පහත විධාන ඇතුලත් කරන්න:

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 පොකුරට සම්බන්ධ වීමට Call Bridge සේවා වින්‍යාසගත කළ යුතුය. මෙම වින්‍යාසය වෙබ් පරිපාලක හරහා සිදු කෙරේ.

සෑම සේවාදායකයකම, වින්‍යාසය> සාමාන්‍ය සහ ක්ෂේත්‍රය වෙත යන්න අද්විතීය ඇමතුම් පාලම නම Call Bridge සේවාදායකයට අනුරූප අද්විතීය නම් ලියන්න callbridge[01,02,03]. Поле වසම් conf.example.ru සහ අනුරූප මුරපද, ඔබට ඒවා ඔත්තු බලන්න පුළුවන්
විධානය සහිත පොකුරේ ඕනෑම සේවාදායකයක:

xmpp callbridge list

"සේවාදායක" ක්ෂේත්රය හිස්ව තබන්න කෝල්බ්‍රිජ් සඳහා DNS SRV සෙවීමක් සිදු කරනු ඇත _xmpp-component._tcp.conf.example.comපවතින XMPP සේවාදායකයක් සොයා ගැනීමට. XMPP වෙත Callbridges සම්බන්ධ කිරීම සඳහා IP ලිපින එක් එක් සේවාදායකය මත වෙනස් විය හැක, එය වාර්තා ඉල්ලීම වෙත ආපසු ලබා දෙන අගයන් මත රඳා පවතී. _xmpp-component._tcp.conf.example.com callbridge, එය අනෙක් අතට දී ඇති DNS වාර්තාවක් සඳහා ප්‍රමුඛතා සැකසීම් මත රඳා පවතී.

මීළඟට, Call Bride සේවාව XMPP සේවාවට සාර්ථකව සම්බන්ධ වී ඇත්දැයි තහවුරු කර ගැනීමට Status > General වෙත යන්න.

වෙබ් පාලම

පොකුරේ ඇති සෑම සේවාදායකයකම, විධානය සමඟ Web Bridge සේවාව සක්‍රීය කරන්න:

webbridge listen a:443

අපි මෙවැනි විධානයක් සමඟ සහතික ගොනු සමඟ Web Bridge සේවාව වින්‍යාස කරමු:

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

වෙබ් පාලම HTTPS සඳහා සහය දක්වයි. එය "http-redirect" භාවිතා කිරීමට වින්‍යාස කර ඇත්නම් HTTP HTTPS වෙත හරවා යවනු ඇත.
HTTP යළි-යොමුවීම් සක්රිය කිරීමට, පහත විධානය භාවිතා කරන්න:

webbridge http-redirect enable

වෙබ් පාලමට Call Bridge වෙතින් සම්බන්ධතා විශ්වාස කළ හැකි බව Call Bridge හට දැනුම් දීමට, විධානය භාවිතා කරන්න:

webbridge trust <certfile>

මෙය පොකුරේ ඇති සෑම සේවාදායකයකින්ම සහතික තුනම අඩංගු ගොනුවකි.

මෙම පින්තූරය පොකුරේ සෑම සේවාදායකයකම තිබිය යුතුය.


දැන් අපට “appadmin” භූමිකාව සහිත පරිශීලකයෙකු නිර්මාණය කිරීමට අවශ්‍ය වේ, අපට එය අවශ්‍ය වන අතර එමඟින් අපට අපගේ පොකුරු (!) වින්‍යාසගත කළ හැකි අතර, පොකුරේ ඇති සෑම සේවාදායකයක්ම වෙන වෙනම නොව, මේ ආකාරයෙන් සැකසුම් සෑම සේවාදායකයකටම සමානව යොදනු ලැබේ. ඒවා එක් වරක් සාදනු ඇත.


වැඩිදුර සැකසීම සඳහා අපි භාවිතා කරන්නෙමු තැපැල්කරු.

අවසරය සඳහා, බලය පැවරීමේ කොටසේ මූලික තෝරන්න

CMS සේවාදායකයට නිවැරදිව විධාන යැවීමට, ඔබට අවශ්‍ය කේතනය සැකසිය යුතුය

අපි විධානය සමඟ Webbridge නියම කරමු තැපැල් පරාමිතිය සමඟ url එක සහ අර්ථය cms.example.com



වෙබ්බ්‍රිජ් තුළම, අපි අවශ්‍ය පරාමිතීන් දක්වන්නෙමු: ආගන්තුක ප්‍රවේශය, ආරක්ෂිත ප්‍රවේශය යනාදිය.

පාලම් කණ්ඩායම් අමතන්න

පෙරනිමියෙන්, CMS සෑම විටම එයට ලබා ගත හැකි සම්මන්ත්‍රණ සම්පත් වඩාත් කාර්යක්ෂමව භාවිතා නොකරයි.

උදාහරණයක් ලෙස, සහභාගිවන්නන් තිදෙනෙකු සමඟ රැස්වීමක් සඳහා, එක් එක් සහභාගිවන්නෙකු විවිධ ඇමතුම් පාලම් තුනකින් අවසන් විය හැක. මෙම සහභාගිවන්නන් තිදෙනා එකිනෙකා සමඟ සන්නිවේදනය කිරීම සඳහා, Call Bridges ස්වයංක්‍රීයව සියලුම සේවාදායකයන් සහ සේවාලාභීන් අතර එකම අවකාශයක සම්බන්ධතා ඇති කරයි, එවිට සියලු සේවාලාභීන් එකම සේවාදායකයේ සිටින බව පෙනේ. අවාසනාවකට, මෙහි ඇති අවාසිය නම් තනි පුද්ගල සම්මන්ත්‍රණයක් දැන් මාධ්‍ය වරායන් 3 ක් පරිභෝජනය කිරීමයි. මෙය පැහැදිලිවම සම්පත් අකාර්යක්ෂම ලෙස භාවිතා කිරීමකි. මීට අමතරව, ඇමතුම් පාලමක් සැබවින්ම අධික ලෙස පටවා ඇති විට, පෙරනිමි යාන්ත්‍රණය වන්නේ ඇමතුම් භාර ගැනීම සහ එම ඇමතුම් පාලමේ සියලුම ග්‍රාහකයින්ට අඩු ගුණාත්මක සේවාවක් සැපයීමයි.

මෙම ගැටළු Call Bridge Group විශේෂාංගය භාවිතයෙන් විසඳනු ලැබේ. මෙම විශේෂාංගය Cisco Meeting Server මෘදුකාංගයේ 2.1 අනුවාදයෙන් හඳුන්වා දී ඇති අතර WebRTC සහභාගිවන්නන් ඇතුළුව පැමිණෙන සහ පිටතට යන Cisco Meeting App (CMA) ඇමතුම් සඳහා බර සමතුලිත කිරීමට සහාය වීම සඳහා දීර්ඝ කර ඇත.

නැවත සම්බන්ධ කිරීමේ ගැටලුව විසඳීම සඳහා, එක් එක් ඇමතුම් පාලම සඳහා වින්‍යාසගත කළ හැකි පැටවුම් සීමාවන් තුනක් හඳුන්වා දී ඇත:

LoadLimit - මෙය විශේෂිත ඇමතුම් පාලමක් සඳහා උපරිම සංඛ්‍යාත්මක භාරයයි. සෑම වේදිකාවකටම CMS96000 සඳහා 1000 සහ අතථ්‍ය යන්ත්‍රය සඳහා vCPU එකකට 1.25 GHz වැනි නිර්දේශිත පැටවුම් සීමාවක් ඇත. සහභාගිවන්නාගේ විභේදනය සහ රාමු අනුපාතය අනුව විවිධ ඇමතුම් යම් සම්පත් ප්රමාණයක් පරිභෝජනය කරයි.
NewConferenceLoadLimitBasisPoints (පෙරනිමි 50% loadLimit) - නව සම්මන්ත්‍රණ ප්‍රතික්ෂේප කිරීමෙන් පසුව සේවාදායක පැටවීමේ සීමාව සකසයි.
පවතින සම්මන්ත්‍රණLoadLimitBasisPoints (loadLimit හි පෙරනිමි 80%) - දැනට පවතින සම්මන්ත්‍රණයකට සම්බන්ධ වන සහභාගිවන්නන් ප්‍රතික්ෂේප කරනු ලබන සේවාදායක පැටවීමේ අගය.

මෙම විශේෂාංගය ඇමතුම් බෙදා හැරීම සහ බර සමතුලිත කිරීම සඳහා නිර්මාණය කර ඇති අතර, TURN සේවාදායක, වෙබ් පාලම් සේවාදායක සහ රෙකෝඩර වැනි අනෙකුත් කණ්ඩායම් ද Call Bridge Groups වෙත පැවරිය හැකි අතර එමඟින් ඒවා ප්‍රශස්ත භාවිතය සඳහා නිසි ලෙස කාණ්ඩගත කළ හැකිය. මෙම වස්තූන්ගෙන් කිසිවක් ඇමතුම් කණ්ඩායමකට පවරා නොමැති නම්, ඒවා කිසිදු විශේෂ ප්‍රමුඛතාවයකින් තොරව සියලුම සේවාදායකයන්ට ලබා ගත හැකි යැයි උපකල්පනය කෙරේ.

මෙම පරාමිතීන් මෙහි වින්‍යාස කර ඇත: cms.example.com:445/api/v1/system/configuration/cluster

ඊළඟට, අපි එක් එක් කෝල්බ්‍රිජ් වෙත එය අයත් වන්නේ කුමන කෝල්බ්‍රිජ් කණ්ඩායමටද යන්න දක්වන්නෙමු:

පළමු ඇමතුම් පාලම

දෙවන ඇමතුම් පාලම

තුන්වන ඇමතුම් පාලම


මේ අනුව, Cisco Meeting Server පොකුරේ සම්පත් වඩාත් කාර්යක්ෂමව භාවිතා කිරීමට අපි Call Brdige සමූහය වින්‍යාස කළෙමු.

සක්‍රීය නාමාවලියෙන් පරිශීලකයින් ආයාත කිරීම

වෙබ් පරිපාලක සේවාවට LDAP වින්‍යාස කිරීමේ අංශයක් ඇත, නමුත් එය සංකීර්ණ වින්‍යාස විකල්ප සපයන්නේ නැත, සහ තොරතුරු පොකුරු දත්ත ගබඩාවේ ගබඩා කර නැත, එබැවින් වින්‍යාස කිරීම එක් එක් සේවාදායකයේ වෙබ් අතුරු මුහුණත හරහා අතින් සිදු කළ යුතුය. API, සහ ඒ නිසා අපි "තුන් වරක් "නැඟිටින්න එපා" අපි තවමත් API හරහා දත්ත සකසන්නෙමු.

ප්‍රවේශ වීමට URL භාවිතා කිරීම cms01.example.com:445/api/v1/ldapServers විසින් LDAP සේවාදායක වස්තුවක් සාදයි, එවැනි පරාමිති සඳහන් කරයි:

• සේවාදායක IP
• වරාය අංකය
• පරිශීලක නාමය
• මුරපදය
• ආරක්ෂිත

ආරක්ෂිත - වරාය මත පදනම්ව සත්‍ය හෝ අසත්‍ය තෝරන්න, 389 - ආරක්ෂිත නොවේ, 636 - ආරක්ෂිතයි.


Cisco Meeting Server හි ගුණාංග සඳහා LDAP මූලාශ්‍ර පරාමිතීන් සිතියම්ගත කිරීම.
LDAP සිතියම්ගත කිරීම LDAP නාමාවලියෙහි ඇති ගුණාංග CMS හි ඇති ගුණාංග වෙත සිතියම්ගත කරයි. සැබෑ ගුණාංග:

• jidMapping
• namemapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

ගුණාංග විස්තර කිරීමIADB CMS හි පරිශීලකගේ පිවිසුම් ID නියෝජනය කරයි. මෙය Microsoft Active Directory LDAP සේවාදායකයක් බැවින්, CMS JID විසින් LDAP හි sAMAccountName වෙත සිතියම් ගත කරයි, එය අත්‍යවශ්‍යයෙන්ම පරිශීලකයාගේ සක්‍රීය නාමාවලි පිවිසුම් ID වේ. ඔබ sAMAccountName ගෙන එහි අවසානයට conf.pod6.cms.lab වසම එක් කරන බව සලකන්න, මන්ද ඔබේ පරිශීලකයින් CMS වෙත ලොග් වීමට භාවිතා කරන පිවිසුම මෙයයි.

namemapping ක්‍රියාකාරී නාමාවලි displayName ක්ෂේත්‍රයේ අඩංගු දේ පරිශීලකයාගේ CMS නාම ක්ෂේත්‍රයට ගැලපේ.

coSpaceNameMapping displayName ක්ෂේත්‍රය මත පදනම්ව CMS ඉඩ නාමයක් නිර්මාණය කරයි. මෙම ගුණාංගය, coSpaceUriMapping ගුණාංගය සමඟින්, එක් එක් පරිශීලකයා සඳහා ඉඩක් නිර්මාණය කිරීමට අවශ්‍ය වේ.

coSpaceUriMapping පරිශීලකයාගේ පුද්ගලික අවකාශය හා සම්බන්ධ URI හි පරිශීලක කොටස නිර්වචනය කරයි. සමහර වසම් අභ්‍යවකාශයට ඇමතීම සඳහා වින්‍යාසගත කළ හැක. පරිශීලක කොටස මෙම වසම් වලින් එකකට මෙම ක්ෂේත්‍රයට ගැලපේ නම්, ඇමතුම එම පරිශීලකයාගේ අවකාශය වෙත යොමු කෙරේ.

coSpaceSecondaryUriMapping අභ්‍යවකාශයට ළඟා වීමට දෙවන URI නිර්වචනය කරයි. coSpaceUriMapping පරාමිතිය තුළ අර්ථ දක්වා ඇති අක්ෂරාංක URI සඳහා විකල්පයක් ලෙස ආනයනය කරන ලද පරිශීලකයාගේ අවකාශය වෙත ඇමතුම් මාර්ගගත කිරීම සඳහා සංඛ්‍යාත්මක අන්වර්ථයක් එක් කිරීමට මෙය භාවිතා කළ හැක.

LDAP සේවාදායකය සහ LDAP සිතියම්කරණය වින්‍යාස කර ඇත. දැන් ඔබට LDAP මූලාශ්‍රයක් නිර්මාණය කිරීමෙන් ඒවා එකට සම්බන්ධ කළ යුතුය.

ප්‍රවේශ වීමට URL භාවිතා කිරීම cms01.example.com:445/api/v1/ldapSource LDAP මූලාශ්‍ර වස්තුවක් නිර්මාණය කරයි, එවැනි පරාමිති සඳහන් කරයි:

• සේවාදායකය
• සිතියම් ගත
• පදනම්Dn
• පෙරහන

දැන් LDAP වින්‍යාසය සම්පූර්ණයි, ඔබට අතින් සමමුහුර්ත කිරීමේ මෙහෙයුම සිදු කළ හැක.

අපි මෙය එක් එක් සේවාදායකයේ වෙබ් අතුරු මුහුණතෙහි ක්ලික් කිරීමෙන් කරන්නෙමු සමමුහුර්ත කරන්න දැන් කොටස සක්රීය නාමාවලිය


හෝ විධානය සමඟ API හරහා තැපැල් ප්රවේශ වීමට URL භාවිතා කිරීම cms01.example.com:445/api/v1/ldapSyncs

Ad-Hoc සම්මන්ත්රණ

මොකක්ද මේ?සාම්ප්‍රදායික සංකල්පයට අනුව, සම්මන්ත්‍රණයක් යනු සහභාගිවන්නන් දෙදෙනෙකු එකිනෙකා සමඟ කතා කරන අතර, සහභාගිවන්නන්ගෙන් එක් අයෙක් (ඒකාබද්ධ CM සමඟ ලියාපදිංචි වූ උපාංගයක් භාවිතා කරමින්) "සම්මන්ත්‍රණ" බොත්තම ඔබා, අනෙක් පුද්ගලයා අමතා, එම තෙවන පාර්ශවය සමඟ කතා කිරීමෙන් පසුවය. , ත්‍රෛපාර්ශ්වික සම්මන්ත්‍රණයේ සියලුම සහභාගිවන්නන් සමඟ එක් වීමට "සම්මන්ත්‍රණය" බොත්තම නැවත ඔබන්න.

CMS එකක නියමිත සම්මන්ත්‍රණයකින් Ad-Hoc සම්මන්ත්‍රණයක් වෙන්කර හඳුනා ගන්නේ Ad-Hoc සම්මන්ත්‍රණයක් යනු CMS වෙත SIP ඇමතුමක් පමණක් නොවේ. සම්මන්ත්‍රණ ආරම්භකයා සියලු දෙනාටම එකම රැස්වීමකට ආරාධනා කිරීම සඳහා දෙවන වරට සම්මන්ත්‍රණ බොත්තම ක්ලික් කළ විට, සියලු ඇමතුම් මාරු කරනු ලබන පියාසර සම්මන්ත්‍රණයක් සෑදීමට Unified CM CMS වෙත API ඇමතුමක් කළ යුතුය. මේ සියල්ල සිදුවන්නේ සහභාගිවන්නන්ගේ අවධානයට ලක් නොවීය.

මෙයින් අදහස් කරන්නේ ඇමතුම දිගටම කරගෙන යාමට Unified CM විසින් API අක්තපත්‍ර සහ WebAdmin ලිපිනය/සේවාවේ තොට මෙන්ම SIP Trunk කෙලින්ම CMS සේවාදායකයට වින්‍යාස කළ යුතු බවයි.

අවශ්‍ය නම්, CUCM හට ගතිකව CMS තුළ ඉඩක් නිර්මාණය කළ හැකි අතර එමඟින් සෑම ඇමතුමකටම CMS වෙත ළඟා විය හැකි අතර හිස්තැන් සඳහා අදහස් කරන ලද ඇමතුම් රීතියට ගැලපේ.

CUCM සමඟ ඒකාබද්ධ වීම ලිපියේ විස්තර කර ඇති ආකාරයටම වින්යාස කර ඇත කලින් Cisco UCM මත හැර, ඔබට CMS සඳහා ටන්ක තුනක්, සම්මන්ත්‍රණ පාලම් තුනක්, SIP ආරක්ෂක පැතිකඩෙහි විෂය නාම තුනක්, මාර්ග කණ්ඩායම්, මාර්ග ලැයිස්තු, මාධ්‍ය සම්පත් කණ්ඩායම් සහ මාධ්‍ය සම්පත් කණ්ඩායම් ලැයිස්තු සඳහන් කරන්න, සහ මාර්ගගත කිරීමේ නීති කිහිපයක් එක් කරන්න. Cisco Meeting Server වෙත.

SIP ආරක්ෂක පැතිකඩ:


කඳන්:


සෑම කඳක්ම එක හා සමානයි:




සම්මන්ත්රණ පාලම


සෑම සම්මන්ත්‍රණ පාලමක්ම එක හා සමානයි:


මාර්ග සමූහය


මාර්ග ලැයිස්තුව


මාධ්ය සම්පත් සමූහය


මාධ්‍ය සම්පත් කණ්ඩායම් ලැයිස්තුව

ඇමතුම් නීති

Unified CM හෝ Expressway වැනි වඩාත් දියුණු ඇමතුම් කළමනාකරණ පද්ධති මෙන් නොව, CMS නව ඇමතුම් සඳහා SIP Request-URI ක්ෂේත්‍රයේ වසම පමණක් බලයි. එබැවින් SIP INVITE sip සඳහා නම්: [විද්‍යුත් ආරක්‍ෂිත]CMS domain.com ගැන පමණක් සැලකිලිමත් වේ. CMS ඇමතුමක් ගෙන යා යුතු ස්ථානය තීරණය කිරීමට මෙම නීති අනුගමනය කරයි:

1. CMS ප්‍රථමයෙන් SIP වසම එන ඇමතුම් රීතිවල වින්‍යාස කර ඇති වසම් සමඟ ගැලපීමට උත්සාහ කරයි. මෙම ඇමතුම් පසුව ("ඉලක්කගත") අවකාශයන් හෝ විශේෂිත පරිශීලකයින්, අභ්‍යන්තර IVRs, හෝ සෘජුවම ඒකාබද්ධ වූ Microsoft Lync/Skype for Business (S4B) ගමනාන්ත වෙත යොමු කළ හැක.
2. එන ඇමතුම් රීති වල ගැළපීමක් නොමැති නම්, CMS ඇමතුම් යොමු කිරීමේ වගුවේ වින්‍යාස කර ඇති වසම සමඟ ගැළපීමට උත්සාහ කරයි. ගැලපීමක් සිදු වුවහොත්, රීතියට පැහැදිලිවම ඇමතුම ප්‍රතික්ෂේප කිරීමට හෝ ඇමතුම යොමු කිරීමට හැකිය. මෙම අවස්ථාවේදී, CMS විසින් වසම නැවත ලිවිය හැක, එය සමහර විට Lync වසම් ඇමතීමට ප්‍රයෝජනවත් වේ. ඔබට විසි කිරීම සමත් වීමට ද තෝරා ගත හැකිය, එයින් අදහස් වන්නේ ක්ෂේත්‍ර කිසිවක් තවදුරටත් වෙනස් නොකරනු ඇති බවයි, නැතහොත් අභ්‍යන්තර CMS ඩයල් සැලැස්මක් භාවිත කරන්න. ඇමතුම් යොමු කිරීමේ නීතිවල ගැළපීමක් නොමැති නම්, පෙරනිමිය වන්නේ ඇමතුම ප්‍රතික්ෂේප කිරීමයි. CMS හි, ඇමතුම "ඉදිරිපත්" වුවද, මාධ්‍ය තවමත් CMS වෙත බැඳී ඇති බව මතක තබා ගන්න, එයින් අදහස් වන්නේ එය සංඥා සහ මාධ්‍ය ගමනාගමන මාර්ගයේ පවතිනු ඇති බවයි.
එවිට පිටතට යන ඇමතුම් නීතිවලට යටත් වන්නේ යොමු කරන ලද ඇමතුම් පමණි. මෙම සිටුවම් මඟින් ඇමතුම් යවන ගමනාන්ත, කඳ වර්ගය (එය නව Lync ඇමතුමක් හෝ සම්මත SIP ඇමතුමක් වේවා) සහ ඇමතුම් යොමු කිරීමේ රීතිය තුළ මාරු කිරීම තෝරා නොගතහොත් සිදු කළ හැකි ඕනෑම පරිවර්තනයක් තීරණය කරයි.

Ad-Hoc සම්මන්ත්‍රණයක් අතරතුර සිදුවන දේ පිළිබඳ සැබෑ ලොගය මෙන්න

තිර පිටපත එය දුර්වල ලෙස පෙන්වයි (එය වඩා හොඳ කරන්නේ කෙසේදැයි මම නොදනිමි), එබැවින් මම ලොගය මෙසේ ලියන්නෙමි:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ad-Hoc සම්මන්ත්‍රණයම:


එන ඇමතුම් නීති
CMS හි ඇමතුමක් ලබා ගැනීමට හැකි වන පරිදි පැමිණෙන ඇමතුම්වල පරාමිතීන් වින්‍යාස කිරීම අවශ්‍ය වේ. ඔබ LDAP සැකසුම තුළ දුටු පරිදි, සියලුම පරිශීලකයන් conf.pod6.cms.lab වසම සමඟින් ආයාත කර ඇත. එබැවින් අවම වශයෙන්, ඔබට අවකාශයන් ඉලක්ක කර ගැනීමට මෙම වසම වෙත ඇමතුම් අවශ්‍ය වේ. ඔබ එක් එක් CMS සේවාදායකයේ සම්පූර්ණ සුදුසුකම් ලත් වසම් නාමය (සහ සමහර විට IP ලිපිනය පවා) සඳහා අදහස් කරන සෑම දෙයක් සඳහාම නීති සැකසීමට අවශ්‍ය වනු ඇත. අපගේ බාහිර ඇමතුම් පාලනය, Unified CM, එක් එක් CMS සේවාදායකයන් සඳහා වෙන් වූ SIP ටන්ක තනි තනිව වින්‍යාස කරනු ඇත. මෙම SIP ටන්කවල ගමනාන්තය IP ලිපිනයක් ද නැතහොත් සේවාදායකයේ FQDN ද යන්න මත පදනම්ව CMS එහි IP ලිපිනයට හෝ FQDN වෙත යොමු කරන ඇමතුම් පිළිගැනීමට වින්‍යාස කළ යුතුද යන්න තීරණය කරයි.

ඉහළම ප්‍රමුඛතා ඇතුල් වීමේ රීතිය ඇති වසම ඕනෑම පරිශීලක අවකාශයක් සඳහා වසම ලෙස භාවිත කෙරේ. පරිශීලකයන් LDAP හරහා සමමුහුර්ත කරන විට, CMS ස්වයංක්‍රීයව හිස්තැන් නිර්මාණය කරයි, නමුත් URI (coSpaceUriMapping) හි පරිශීලක කොටස පමණි, උදාහරණයක් ලෙස, user.space. කොටස වසම් මෙම රීතිය මත පදනම්ව සම්පූර්ණ URI ජනනය වේ. ඇත්ත වශයෙන්ම, ඔබ මෙම අවස්ථාවේදී Web Bridge වෙත පිවිසීමට ගියහොත්, Space URI හි වසමක් නොමැති බව ඔබට පෙනෙනු ඇත. මෙම රීතිය ඉහළම ප්‍රමුඛතාවය ලෙස සැකසීමෙන්, ඔබ ජනනය කරන ලද අවකාශයන් සඳහා වසම සකසයි conf.example.com.


පිටතට යන ඇමතුම් නීති

Unified CM පර්ෂදයට පිටතට යන ඇමතුම් ලබා ගැනීමට පරිශීලකයින්ට ඉඩ දීමට, ඔබ පිටතට යන නීති වින්‍යාස කළ යුතුය. Jabber වැනි Unified CM සමඟ ලියාපදිංචි වූ අන්ත ලක්ෂ්‍ය වසම example.com වේ. මෙම වසම වෙත වන ඇමතුම් සම්මත SIP ඇමතුම් ලෙස ඒකාබද්ධ CM ඇමතුම් සැකසුම් නෝඩ් වෙත යොමු කළ යුතුය. ප්‍රධාන සේවාදායකය cucm-01.example.com වන අතර අතිරේක සේවාදායකය cucm-02.example.com වේ.

පළමු රීතිය පොකුරු සේවාදායකයන් අතර ඇමතුම් සරලම මාර්ගගත කිරීම විස්තර කරයි.

ක්ෂේත්රයේ වසමෙන් දේශීය "@" සංකේතයෙන් පසුව අමතන පුද්ගලයා සඳහා ඇමතුම්කරුගේ SIP-URI හි සංදර්ශණය වන දේ සඳහා වගකිව යුතුය. අපි එය හිස්ව තැබුවහොත්, “@” සංකේතයට පසුව මෙම ඇමතුම හරහා යන CUCM හි IP ලිපිනය ඇත. අපි වසමක් සඳහන් කරන්නේ නම්, "@" සංකේතයට පසුව වසමක් ඇත. නැවත ඇමතීමට හැකි වීම සඳහා මෙය අවශ්‍ය වේ, එසේ නොමැතිනම් SIP-URI name@ip-address හරහා නැවත ඇමතීමට නොහැකි වනු ඇත.

සඳහන් කළ විට අමතන්න වසමෙන් දේශීය


විට අමතන්න නෙ දක්වා ඇත වසමෙන් දේශීය


ස්වයංක්‍රීය පරාමිතිය සමඟ කිසිවක් ක්‍රියා නොකරන නිසා, පිටතට යන ඇමතුම් සඳහා සංකේතාත්මක හෝ සංකේතනය නොකළ බව පැහැදිලිව සඳහන් කිරීමට වග බලා ගන්න.

පටිගත කිරීම

වීඩියෝ සම්මන්ත්‍රණ වාර්තා සේවාදායකය විසින් පටිගත කරනු ලැබේ. රෙකෝඩරය හරියටම සිස්කෝ රැස්වීම් සේවාදායකයට සමාන වේ. රෙකෝඩරයට බලපත්‍රයක් ස්ථාපනය කිරීම අවශ්‍ය නොවේ. CallBridge සේවා ධාවනය වන සේවාදායකයන් සඳහා පටිගත කිරීමේ බලපත්‍ර අවශ්‍ය වේ, i.e. පටිගත කිරීමේ බලපත්‍රයක් අවශ්‍ය වන අතර එය යෙදිය යුත්තේ CallBridge සංරචකයට මිස සේවාදායක ධාවන රෙකෝඩරයට නොවේ. රෙකෝඩරය විස්තීරණ පණිවිඩ යැවීමේ සහ පැමිණීමේ ප්‍රොටෝකෝලය (XMPP) සේවාලාභියෙකු ලෙස ක්‍රියා කරයි, එබැවින් CallBridge සත්කාරක සේවාදායකයේ XMPP සේවාදායකය සක්‍රීය කළ යුතුය.

නිසා අපට පොකුරක් ඇති අතර බලපත්‍රය පොකුරේ ඇති සර්වර් තුනම "දිගු" කළ යුතුය. පසුව බලපත්‍රවල ඔබගේ පුද්ගලික ගිණුමේ අපි පොකුරට ඇතුළත් සියලුම CMS සේවාදායකයන්ගේ a-අතුරුමුහුණත් වල MAC ලිපින සම්බන්ධ කරමු (එකතු කරන්න).

තවද මෙය පොකුරේ සෑම සේවාදායකයකම තිබිය යුතු පින්තූරයයි

පොදුවේ ගත් කල, රෙකෝඩරය තැබීම සඳහා අවස්ථා කිහිපයක් ඇත, නමුත් අපි මෙයට ඇලී සිටින්නෙමු:


රෙකෝඩරය පිහිටුවීමට පෙර, වීඩියෝ සම්මන්ත්‍රණ සැබවින්ම පටිගත කරන ස්ථානයක් ඔබ විසින් සකස් කළ යුතුය. ඇත්තටම මෙතන සබැඳිය, සියලුම පටිගත කිරීම් සකසන්නේ කෙසේද. මම වැදගත් කරුණු සහ විස්තර කෙරෙහි අවධානය යොමු කරමි:

1. පොකුරේ පළමු සේවාදායකයෙන් සහතිකය ලිස්සා යාම වඩා හොඳය.
2. රෙකෝඩර් භාරයේ වැරදි සහතිකය සඳහන් කර ඇති නිසා "රෙකෝඩරය නොමැත" දෝෂය ඇති විය හැක.
3. පටිගත කිරීම සඳහා නිශ්චිතව දක්වා ඇති NFS බහලුම මූල නාමාවලිය නොවේ නම් ලිවීම ක්‍රියා නොකරනු ඇත.

සමහර විට එක් විශේෂිත පරිශීලකයෙකුගේ හෝ අවකාශයක සම්මන්ත්‍රණයක් ස්වයංක්‍රීයව පටිගත කිරීමේ අවශ්‍යතාවයක් ඇත.

මේ සඳහා, CallProfiles දෙකක් සාදනු ලැබේ:
පටිගත කිරීම අබල කර ඇත


සහ ස්වයංක්රීය පටිගත කිරීමේ කාර්යය සමඟ


මීලඟට, අපි අවශ්ය අවකාශයට ස්වයංක්රීය පටිගත කිරීමේ කාර්යයක් සහිත CallProfile "ඇමිණීම".


CMS හි එය කෙතරම් තහවුරු වී ඇත්ද යත්, CallProfile කිසියම් අවකාශයකට හෝ අවකාශයකට පැහැදිලිව බැඳී තිබේ නම්, මෙම CallProfile ක්‍රියා කරන්නේ මෙම විශේෂිත අවකාශයන් සම්බන්ධයෙන් පමණි. තවද CallProfile කිසිදු ඉඩකට බැඳී නොමැති නම්, පෙරනිමියෙන් එය CallProfile නිශ්චිතව බැඳී නොමැති එම අවකාශයන් වෙත යොදනු ලැබේ.

ඊළඟ වතාවේ මම සංවිධානයේ අභ්‍යන්තර ජාලයෙන් පිටත CMS වෙත ප්‍රවේශ වන ආකාරය විස්තර කිරීමට උත්සාහ කරමි.

මූලාශ්ර:

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

මූලාශ්රය: www.habr.com