సిస్కో మీటింగ్ సర్వర్ 2.5.2. వీడియో కాన్ఫరెన్స్ రికార్డింగ్‌తో స్కేలబుల్ మరియు రెసిలెంట్ మోడ్‌లో క్లస్టర్

ఈ సంచికలో నేను ఫెయిల్‌ఓవర్ క్లస్టర్ మోడ్‌లో CMS సర్వర్‌ను సెటప్ చేయడంలో కొన్ని చిక్కులను చూపుతాను మరియు వివరిస్తాను.


సిద్ధాంతంసాధారణంగా, CMS సర్వర్ విస్తరణలో మూడు రకాలు ఉన్నాయి:

• సింగిల్ కంబైన్డ్(సింగిల్ కంబైన్డ్), అనగా. ఇది అన్ని అవసరమైన సేవలను అమలు చేసే ఒక సర్వర్. చాలా సందర్భాలలో, ఈ రకమైన విస్తరణ అంతర్గత క్లయింట్ యాక్సెస్‌కు మరియు ఒకే సర్వర్ యొక్క స్కేలబిలిటీ మరియు రిడెండెన్సీ పరిమితులు క్లిష్టమైన సమస్య కానటువంటి చిన్న పరిసరాలలో లేదా తాత్కాలిక వంటి నిర్దిష్ట విధులను మాత్రమే CMS నిర్వహించే సందర్భాల్లో మాత్రమే అనుకూలంగా ఉంటుంది. సిస్కో UCMపై సమావేశాలు.

  పని యొక్క సుమారు పథకం:
  

• సింగిల్ స్ప్లిట్(సింగిల్ స్ప్లిట్) బాహ్య యాక్సెస్ కోసం ప్రత్యేక సర్వర్‌ని జోడించడం ద్వారా మునుపటి విస్తరణ రకాన్ని పొడిగిస్తుంది. లెగసీ డిప్లాయ్‌మెంట్‌లలో, బాహ్య క్లయింట్లు యాక్సెస్ చేయగల సైనికరహిత నెట్‌వర్క్ సెగ్మెంట్ (DMZ)లో CMS సర్వర్‌ని మరియు అంతర్గత క్లయింట్లు CMSని యాక్సెస్ చేయగల నెట్‌వర్క్ కోర్‌లోని ఒక CMS సర్వర్‌ని అమలు చేయడం దీని అర్థం. ఈ నిర్దిష్ట విస్తరణ మోడల్ ఇప్పుడు టైప్ అని పిలవబడే రకం ద్వారా భర్తీ చేయబడుతోంది సింగిల్ ఎడ్జ్, ఇది సర్వర్‌లను కలిగి ఉంటుంది సిస్కో ఎక్స్‌ప్రెస్‌వే, ఇది ఒకే రకమైన ఫైర్‌వాల్ బైపాస్ సామర్థ్యాలను కలిగి ఉంటుంది లేదా కలిగి ఉంటుంది కాబట్టి క్లయింట్‌లు డెడికేటెడ్ ఎడ్జ్ CMS సర్వర్‌ను జోడించాల్సిన అవసరం లేదు.

  పని యొక్క సుమారు పథకం:
  

• స్కేలబుల్ మరియు స్థితిస్థాపకత(స్కేలబుల్ మరియు ఫాల్ట్ టాలరెంట్) ఈ రకం ప్రతి కాంపోనెంట్‌కు రిడెండెన్సీని కలిగి ఉంటుంది, విఫలమైతే రిడెండెన్సీని అందిస్తూనే సిస్టమ్ దాని గరిష్ట సామర్థ్యానికి మీ అవసరాలకు అనుగుణంగా వృద్ధి చెందడానికి అనుమతిస్తుంది. సురక్షితమైన బాహ్య ప్రాప్యతను అందించడానికి ఇది సింగిల్ ఎడ్జ్ కాన్సెప్ట్‌ను కూడా ఉపయోగిస్తుంది. ఈ ఎపిసోడ్‌లో మనం చూడబోయే రకం ఇది. ఈ రకమైన క్లస్టర్‌ను ఎలా అమలు చేయాలో మేము అర్థం చేసుకుంటే, మేము ఇతర రకాల విస్తరణలను అర్థం చేసుకోలేము, కానీ డిమాండ్‌లో సంభావ్య వృద్ధికి అనుగుణంగా CMS సర్వర్‌ల క్లస్టర్‌లను ఎలా సృష్టించాలో కూడా మేము అర్థం చేసుకోగలుగుతాము.

విస్తరణకు వెళ్లే ముందు, మీరు కొన్ని ప్రాథమిక విషయాలను అర్థం చేసుకోవాలి, అవి

ప్రధాన CMS సాఫ్ట్‌వేర్ భాగాలు:

• డేటాబేస్: డయల్ ప్లాన్, యూజర్ స్పేస్‌లు మరియు యూజర్‌ల వంటి కొన్ని కాన్ఫిగరేషన్‌లను కలపడానికి మిమ్మల్ని అనుమతిస్తుంది. అధిక లభ్యత (సింగిల్ మాస్టర్) కోసం మాత్రమే క్లస్టరింగ్‌కు మద్దతు ఇస్తుంది.
• కాల్ వంతెన: కాల్‌లు మరియు మల్టీమీడియా ప్రక్రియల నిర్వహణ మరియు ప్రాసెసింగ్‌పై పూర్తి నియంత్రణను అందించే ఆడియో మరియు వీడియో కాన్ఫరెన్సింగ్ కోసం ఒక సేవ. అధిక లభ్యత మరియు స్కేలబిలిటీ కోసం క్లస్టరింగ్‌కు మద్దతు ఇస్తుంది.
• XMPP సర్వర్: సిస్కో మీటింగ్ అప్లికేషన్ మరియు/లేదా WebRTC(ని ఉపయోగించి ఖాతాదారుల నమోదు మరియు ప్రామాణీకరణ బాధ్యతనిజ-సమయ కమ్యూనికేషన్ లేదా బ్రౌజర్‌లో), అలాగే ఇంటర్‌కంపొనెంట్ సిగ్నలింగ్. అధిక లభ్యత కోసం మాత్రమే క్లస్టర్ చేయవచ్చు.
• వెబ్ వంతెన: WebRTCకి క్లయింట్ యాక్సెస్‌ను అందిస్తుంది.
• లోడ్ బ్యాలన్సర్: సింగిల్ స్ప్లిట్ మోడ్‌లో సిస్కో మీటింగ్ యాప్‌ల కోసం ఒకే కనెక్షన్ పాయింట్‌ను అందిస్తుంది. ఇన్‌కమింగ్ కనెక్షన్‌ల కోసం బాహ్య ఇంటర్‌ఫేస్ మరియు పోర్ట్‌ను వింటుంది. అదేవిధంగా, లోడ్ బ్యాలెన్సర్ XMPP సర్వర్ నుండి ఇన్‌కమింగ్ TLS కనెక్షన్‌లను అంగీకరిస్తుంది, దీని ద్వారా బాహ్య క్లయింట్‌ల నుండి TCP కనెక్షన్‌లను మార్చవచ్చు.
  మా దృష్టాంతంలో ఇది అవసరం లేదు.
• టర్న్ సర్వర్: అనుమతించే ఫైర్‌వాల్ బైపాస్ టెక్నాలజీని అందిస్తుంది
  సిస్కో మీటింగ్ యాప్ లేదా SIP పరికరాలను ఉపయోగించి బాహ్య క్లయింట్‌లను కనెక్ట్ చేయడానికి ఫైర్‌వాల్ లేదా NAT వెనుక మా CMS ఉంచండి. మా దృష్టాంతంలో ఇది అవసరం లేదు.
• వెబ్ అడ్మిన్: ప్రత్యేక ఏకీకృత CM సమావేశాలతో సహా అడ్మినిస్ట్రేటివ్ ఇంటర్‌ఫేస్ మరియు API యాక్సెస్.

కాన్ఫిగరేషన్ మోడ్‌లు

ఇతర Cisco ఉత్పత్తుల వలె కాకుండా, Cisco Meeting Server ఏ విధమైన విస్తరణకు అనుగుణంగా మూడు కాన్ఫిగరేషన్ పద్ధతులకు మద్దతు ఇస్తుంది.

• కమాండ్ లైన్ (CLI): ప్రారంభ కాన్ఫిగరేషన్ మరియు సర్టిఫికేట్ టాస్క్‌ల కోసం MMP అని పిలువబడే కమాండ్ లైన్ ఇంటర్‌ఫేస్.
• వెబ్ అడ్మినిస్ట్రేటర్: ప్రధానంగా కాల్‌బ్రిడ్జ్ సంబంధిత కాన్ఫిగరేషన్‌ల కోసం, ప్రత్యేకించి ఒకే నాన్-క్లస్టర్డ్ సర్వర్‌ని సెటప్ చేసేటప్పుడు.
• REST API: అత్యంత క్లిష్టమైన కాన్ఫిగరేషన్ టాస్క్‌లు మరియు క్లస్టర్డ్ డేటాబేస్ సంబంధిత టాస్క్‌ల కోసం ఉపయోగించబడుతుంది.

పైన పేర్కొన్న వాటికి అదనంగా, ప్రోటోకాల్ ఉపయోగించబడుతుంది SFTP ఫైల్‌లను-సాధారణంగా లైసెన్స్‌లు, సర్టిఫికెట్‌లు లేదా లాగ్‌లను CMS సర్వర్‌కు మరియు దాని నుండి బదిలీ చేయడానికి.

Cisco నుండి డిప్లాయ్‌మెంట్ గైడ్‌లలో క్లస్టర్‌ని అమలు చేయాలని తెలుపు మరియు ఆంగ్లంలో వ్రాయబడింది కనీసం మూడు డేటాబేస్‌ల సందర్భంలో సర్వర్లు (నోడ్‌లు). ఎందుకంటే కొత్త డేటాబేస్ మాస్టర్‌ని ఎంచుకునే విధానం బేసి సంఖ్యతో మాత్రమే పని చేస్తుంది మరియు సాధారణంగా డేటాబేస్ మాస్టర్ చాలా CMS సర్వర్ డేటాబేస్‌తో కనెక్షన్‌ని కలిగి ఉంటుంది.

మరియు ఆచరణలో చూపినట్లుగా, రెండు సర్వర్లు (నోడ్లు) నిజంగా సరిపోవు. మాస్టర్‌ని రీబూట్ చేసినప్పుడు ఎంపిక విధానం పని చేస్తుంది, రీబూట్ చేసిన సర్వర్‌ను తీసుకువచ్చిన తర్వాత మాత్రమే స్లేవ్ సర్వర్ మాస్టర్ అవుతుంది. అయితే, రెండు సర్వర్‌ల క్లస్టర్‌లో మాస్టర్ సర్వర్ అకస్మాత్తుగా నిష్క్రమిస్తే, స్లేవ్ సర్వర్ మాస్టర్ అవ్వదు మరియు స్లేవ్ బయటకు వెళితే, మిగిలిన మాస్టర్ సర్వర్ స్లేవ్ అవుతుంది.

కానీ XMPP సందర్భంలో, మూడు సర్వర్‌ల క్లస్టర్‌ను సమీకరించడం నిజంగా అవసరం, ఎందుకంటే ఉదాహరణకు, XMMP లీడర్ హోదాలో ఉన్న సర్వర్‌లలో ఒకదానిలో మీరు XMPP సేవను నిలిపివేస్తే, మిగిలిన సర్వర్‌లో XMPP అనుచరుల స్థితిలో ఉంటుంది మరియు XMPPకి కాల్‌బ్రిడ్జ్ కనెక్షన్‌లు పడిపోతాయి, ఎందుకంటే CallBridge లీడర్ హోదాతో XMPPకి ప్రత్యేకంగా కనెక్ట్ అవుతుంది. మరియు ఇది క్లిష్టమైనది, ఎందుకంటే... ఒక్క కాల్ కూడా వెళ్ళదు.

అదే విస్తరణ మార్గదర్శకాలలో ఒక XMPP సర్వర్‌తో కూడిన క్లస్టర్ ప్రదర్శించబడుతుంది.

మరియు పైన పేర్కొన్న వాటిని పరిగణనలోకి తీసుకుంటే, ఎందుకు స్పష్టమవుతుంది: ఇది ఫెయిల్ఓవర్ మోడ్‌లో ఉన్నందున ఇది పనిచేస్తుంది.

మా విషయంలో, XMPP సర్వర్ మూడు నోడ్‌లలో ఉంటుంది.

మా మూడు సర్వర్‌లు అప్‌లో ఉన్నాయని భావించబడుతుంది.

DNS రికార్డులు

మీరు సర్వర్‌లను సెటప్ చేయడానికి ముందు, మీరు DNS రికార్డులను సృష్టించాలి А и ఎస్‌ఆర్‌వి రకాలు:

దయచేసి మా DNS రికార్డులలో example.com మరియు అనే రెండు డొమైన్‌లు ఉన్నాయని గమనించండి సమా.example.com. Example.com అనేది సిస్కో యూనిఫైడ్ కమ్యూనికేషన్ మేనేజర్ సబ్‌స్క్రైబర్‌లందరూ తమ URIల కోసం ఉపయోగించగల డొమైన్, ఇది మీ ఇన్‌ఫ్రాస్ట్రక్చర్‌లో ఎక్కువగా ఉంటుంది లేదా ఉండవచ్చు. లేదా example.com వినియోగదారులు వారి ఇమెయిల్ చిరునామాల కోసం ఉపయోగించే అదే డొమైన్‌తో సరిపోలుతుంది. లేదా మీ ల్యాప్‌టాప్‌లోని జబ్బర్ క్లయింట్ URIని కలిగి ఉండవచ్చు [ఇమెయిల్ రక్షించబడింది]. డొమైన్ సమా.example.com అనేది సిస్కో మీటింగ్ సర్వర్ వినియోగదారుల కోసం కాన్ఫిగర్ చేయబడే డొమైన్. సిస్కో మీటింగ్ సర్వర్ డొమైన్ ఉంటుంది సమా.example.com, కాబట్టి అదే జబ్బర్ వినియోగదారు కోసం, సిస్కో మీటింగ్ సర్వర్‌లోకి లాగిన్ చేయడానికి యూజర్@ URIని ఉపయోగించాల్సి ఉంటుందిసమా.example.com.

ప్రాథమిక కాన్ఫిగరేషన్

దిగువ వివరించిన అన్ని సెట్టింగ్‌లు ఒక సర్వర్‌లో చూపబడతాయి, అయితే అవి క్లస్టర్‌లోని ప్రతి సర్వర్‌లో చేయాలి.

QoS

CMS ఉత్పత్తి చేస్తుంది కాబట్టి రియల్ టైమ్ ఆలస్యం మరియు ప్యాకెట్ నష్టానికి ట్రాఫిక్ సున్నితంగా ఉంటుంది, చాలా సందర్భాలలో సేవ యొక్క నాణ్యత (QoS) కాన్ఫిగర్ చేయడానికి సిఫార్సు చేయబడింది. దీనిని సాధించడానికి, CMS అది ఉత్పత్తి చేసే డిఫరెన్సియేటెడ్ సర్వీసెస్ కోడ్‌లతో (DSCPలు) ట్యాగింగ్ ప్యాకెట్‌లకు మద్దతు ఇస్తుంది. మీ ఇన్‌ఫ్రాస్ట్రక్చర్‌లోని నెట్‌వర్క్ భాగాల ద్వారా ట్రాఫిక్ ఎలా ప్రాసెస్ చేయబడుతుందనే దానిపై 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లో మేము మా సర్వర్‌ల సాధారణ పేరును వ్రాస్తాము. ఉదాహరణకు, మా సర్వర్‌ల హోస్ట్ పేర్లు server01, server02, server03, అప్పుడు 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) సంబంధిత సర్వర్ల పేర్లు.

మేము ఈ విధానాన్ని ఒక సర్వర్‌లో (!) మాత్రమే చేస్తాము మరియు మేము ఇతర సర్వర్‌లకు సర్టిఫికేట్‌లు మరియు సంబంధిత .కీ ఫైల్‌లను అప్‌లోడ్ చేస్తాము.

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>

క్లస్టర్ ప్రారంభించబడిన CMS సర్వర్ యొక్క ip చిరునామా ఇప్పటికే ఉన్న మాస్టర్ ip చిరునామా, కేవలం మాస్టర్.

కమాండ్‌తో అన్ని సర్వర్‌లలో మా డేటాబేస్ క్లస్టర్ ఎలా పనిచేస్తుందో మేము తనిఖీ చేస్తాము:

database cluster status

మేము మిగిలిన మూడవ సర్వర్‌లో కూడా అదే చేస్తాము.

ఫలితంగా, మా మొదటి సర్వర్ మాస్టర్ అని, మిగిలిన వారు బానిసలు అని తేలింది.

వెబ్ అడ్మిన్ సర్వీస్

వెబ్ అడ్మినిస్ట్రేటర్ సేవను ప్రారంభించండి:

webadmin listen a 445

వెబ్ క్లయింట్‌కు వినియోగదారు యాక్సెస్ కోసం పోర్ట్ 445 ఉపయోగించబడుతుంది కాబట్టి పోర్ట్ 443 ఎంచుకోబడింది

మేము వెబ్ అడ్మిన్ సేవను సర్టిఫికేట్ ఫైల్‌లతో ఇలాంటి ఆదేశంతో కాన్ఫిగర్ చేస్తాము:

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

మరియు ఆదేశంతో వెబ్ అడ్మిన్‌ని ప్రారంభించండి:

webadmin enable

అన్నీ సరిగ్గా ఉంటే, నెట్‌వర్క్ మరియు సర్టిఫికేట్ కోసం వెబ్ అడ్మిన్ సరిగ్గా కాన్ఫిగర్ చేయబడిందని సూచించే SUCCESS లైన్‌లను మేము స్వీకరిస్తాము. మేము వెబ్ బ్రౌజర్‌ని ఉపయోగించి సేవ యొక్క కార్యాచరణను తనిఖీ చేస్తాము మరియు వెబ్ అడ్మినిస్ట్రేటర్ చిరునామాను నమోదు చేస్తాము, ఉదాహరణకు: 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లను నమోదు చేయండి, సెం[01,02,03].example.com:445, చిరునామా ఫీల్డ్‌లో. పోర్ట్‌ను ఖచ్చితంగా పేర్కొనండి. మీరు పీర్ లింక్ SIP డొమైన్‌ను ఖాళీగా ఉంచవచ్చు.
4. ప్రతి సర్వర్ యొక్క కాల్‌బ్రిడ్జ్ ట్రస్ట్‌కు ఒక ప్రమాణపత్రాన్ని జోడించండి, దాని ఫైల్‌లో మా సర్వర్‌ల యొక్క అన్ని సర్టిఫికేట్‌లు ఉన్నాయి, వీటిని మేము ప్రారంభంలోనే ఈ ఫైల్‌లో విలీనం చేసాము, ఇలాంటి ఆదేశంతో:

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@సమా.example.com. ఇది కేవలం example.com ఎందుకు కాదు? మా ప్రత్యేక విస్తరణలో, జబ్బర్ వినియోగదారులు యూనిఫైడ్ CMలో example.comగా ఉపయోగించే మా యూనిఫైడ్ CM డొమైన్‌ని ఎంచుకున్నాము, కాబట్టి CMS యూజర్‌లు SIP డొమైన్‌ల ద్వారా CMSకి మరియు CMS నుండి కాల్‌లను రూట్ చేయడానికి మాకు వేరే డొమైన్ అవసరం.

వంటి ఆదేశాన్ని ఉపయోగించి XMPP డొమైన్‌ను సెటప్ చేయండి:

xmpp domain <domain>

మరియు ఆదేశంతో XMPP సేవను ప్రారంభించండి:

xmpp enable

XMPP సేవలో, XMPP సేవతో నమోదు చేసుకునేటప్పుడు ఉపయోగించబడే ప్రతి కాల్ బ్రిడ్జ్ కోసం మీరు తప్పనిసరిగా ఆధారాలను సృష్టించాలి. ఈ పేర్లు ఏకపక్షంగా ఉంటాయి (మరియు మీరు కాల్ బ్రిడ్జ్ క్లస్టరింగ్ కోసం కాన్ఫిగర్ చేసిన ప్రత్యేక పేర్లకు సంబంధించినవి కావు). మీరు తప్పనిసరిగా ఒక XMPP సర్వర్‌లో మూడు కాల్ బ్రిడ్జిలను జోడించి, ఆపై క్లస్టర్‌లోని ఇతర XMPP సర్వర్‌లలో ఆ ఆధారాలను నమోదు చేయాలి ఎందుకంటే ఈ కాన్ఫిగరేషన్ క్లస్టర్ డేటాబేస్‌కి సరిపోదు. తర్వాత మేము ఈ పేరును మరియు XMPP సేవతో నమోదు చేసుకోవడానికి రహస్యాన్ని ఉపయోగించడానికి ప్రతి కాల్ వంతెనను కాన్ఫిగర్ చేస్తాము.

ఇప్పుడు మనం XMPP సేవను మొదటి సర్వర్‌లో మూడు కాల్ బ్రిడ్జ్‌లతో కాల్‌బ్రిడ్జ్01, కాల్‌బ్రిడ్జ్02 మరియు కాల్‌బ్రిడ్జ్03తో కాన్ఫిగర్ చేయాలి. ప్రతి ఖాతాకు యాదృచ్ఛిక పాస్‌వర్డ్‌లు కేటాయించబడతాయి. ఈ 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

"సర్వర్" ఫీల్డ్‌ను ఖాళీగా ఉంచండి కాల్‌బ్రిడ్జ్ కోసం DNS SRV శోధనను నిర్వహిస్తుంది _xmpp-component._tcp.conf.example.comఅందుబాటులో ఉన్న XMPP సర్వర్‌ని కనుగొనడానికి. XMPPకి కాల్‌బ్రిడ్జ్‌లను కనెక్ట్ చేయడానికి IP చిరునామాలు ప్రతి సర్వర్‌లో తేడా ఉండవచ్చు, ఇది రికార్డ్ అభ్యర్థనకు ఏ విలువలు తిరిగి ఇవ్వబడుతుందనే దానిపై ఆధారపడి ఉంటుంది. _xmpp-component._tcp.conf.example.com కాల్‌బ్రిడ్జ్, ఇది ఇచ్చిన DNS రికార్డ్ కోసం ప్రాధాన్యత సెట్టింగ్‌లపై ఆధారపడి ఉంటుంది.

తర్వాత, కాల్ బ్రైడ్ సేవ విజయవంతంగా XMPP సేవకు కనెక్ట్ చేయబడిందో లేదో ధృవీకరించడానికి స్థితి > జనరల్‌కి వెళ్లండి.

వెబ్ వంతెన

క్లస్టర్‌లోని ప్రతి సర్వర్‌లో, ఆదేశంతో వెబ్ బ్రిడ్జ్ సేవను ప్రారంభించండి:

webbridge listen a:443

మేము వెబ్ బ్రిడ్జ్ సేవను సర్టిఫికేట్ ఫైల్‌లతో కాన్ఫిగర్ చేస్తాము:

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

వెబ్ బ్రిడ్జ్ HTTPSకి మద్దతు ఇస్తుంది. ఇది "http-redirect"ని ఉపయోగించడానికి కాన్ఫిగర్ చేయబడితే HTTPని HTTPSకి దారి మళ్లిస్తుంది.
HTTP దారి మళ్లింపును ప్రారంభించడానికి, కింది ఆదేశాన్ని ఉపయోగించండి:

webbridge http-redirect enable

వెబ్ బ్రిడ్జ్ కాల్ బ్రిడ్జ్ నుండి కనెక్షన్‌లను విశ్వసించగలదని కాల్ బ్రిడ్జ్‌కి తెలియజేయడానికి, ఆదేశాన్ని ఉపయోగించండి:

webbridge trust <certfile>

ఇక్కడ ఇది క్లస్టర్‌లోని ప్రతి సర్వర్ నుండి మూడు సర్టిఫికేట్‌లను కలిగి ఉన్న ఫైల్.

ఈ చిత్రం క్లస్టర్‌లోని ప్రతి సర్వర్‌లో ఉండాలి.


ఇప్పుడు మనం “అప్పడ్మిన్” పాత్రతో వినియోగదారుని సృష్టించాలి, మనకు ఇది అవసరం, తద్వారా మన క్లస్టర్‌ను (!) కాన్ఫిగర్ చేయవచ్చు మరియు క్లస్టర్‌లోని ప్రతి సర్వర్‌ని విడిగా కాకుండా, ఈ విధంగా సెట్టింగులు ప్రతి సర్వర్‌కు సమానంగా వర్తించబడతాయి. వారు ఒకసారి తయారు చేస్తారు వాస్తవం.


తదుపరి సెటప్ కోసం మేము ఉపయోగిస్తాము పోస్ట్మాన్.

అధికారం కోసం, ఆథరైజేషన్ విభాగంలో బేసిక్‌ని ఎంచుకోండి

CMS సర్వర్‌కు ఆదేశాలను సరిగ్గా పంపడానికి, మీరు అవసరమైన ఎన్‌కోడింగ్‌ను సెట్ చేయాలి

మేము కమాండ్‌తో వెబ్‌బ్రిడ్జ్‌ని నిర్దేశిస్తాము POST పరామితితో url మరియు అర్థం cms.example.com



వెబ్‌బ్రిడ్జ్‌లోనే, మేము అవసరమైన పారామితులను సూచిస్తాము: అతిథి యాక్సెస్, రక్షిత యాక్సెస్, మొదలైనవి.

వంతెన సమూహాలకు కాల్ చేయండి

డిఫాల్ట్‌గా, CMS ఎల్లప్పుడూ తనకు అందుబాటులో ఉన్న కాన్ఫరెన్సింగ్ వనరులను అత్యంత సమర్థవంతంగా ఉపయోగించదు.

ఉదాహరణకు, ముగ్గురు పార్టిసిపెంట్‌లతో మీటింగ్ కోసం, ప్రతి పార్టిసిపెంట్ మూడు వేర్వేరు కాల్ బ్రిడ్జ్‌లలో ముగుస్తుంది. ఈ ముగ్గురు పార్టిసిపెంట్‌లు ఒకరితో ఒకరు కమ్యూనికేట్ చేయడానికి, కాల్ బ్రిడ్జ్‌లు అన్ని సర్వర్‌లు మరియు క్లయింట్‌ల మధ్య ఒకే స్థలంలో స్వయంచాలకంగా కనెక్షన్‌లను ఏర్పరుస్తాయి, తద్వారా క్లయింట్‌లందరూ ఒకే సర్వర్‌లో ఉన్నట్లుగా కనిపిస్తుంది. దురదృష్టవశాత్తూ, దీని ప్రతికూలత ఏమిటంటే, ఒకే 3-వ్యక్తి సమావేశం ఇప్పుడు 9 మీడియా పోర్ట్‌లను వినియోగిస్తుంది. ఇది సహజంగానే వనరుల అసమర్థ వినియోగం. అదనంగా, కాల్ బ్రిడ్జ్ నిజంగా ఓవర్‌లోడ్ అయినప్పుడు, డిఫాల్ట్ మెకానిజం కాల్‌లను అంగీకరించడం కొనసాగించడం మరియు ఆ కాల్ బ్రిడ్జ్‌లోని సబ్‌స్క్రైబర్లందరికీ తగ్గిన నాణ్యత సేవను అందించడం.

కాల్ బ్రిడ్జ్ గ్రూప్ ఫీచర్‌ని ఉపయోగించి ఈ సమస్యలు పరిష్కరించబడతాయి. ఈ ఫీచర్ Cisco Meeting Server సాఫ్ట్‌వేర్ వెర్షన్ 2.1లో పరిచయం చేయబడింది మరియు WebRTC పార్టిసిపెంట్‌లతో సహా ఇన్‌బౌండ్ మరియు అవుట్‌బౌండ్ సిస్కో మీటింగ్ యాప్ (CMA) కాల్స్ రెండింటికీ లోడ్ బ్యాలెన్సింగ్‌కు మద్దతుగా విస్తరించబడింది.

రీకనెక్షన్ సమస్యను పరిష్కరించడానికి, ప్రతి కాల్ బ్రిడ్జికి మూడు కాన్ఫిగర్ చేయగల లోడ్ పరిమితులు ప్రవేశపెట్టబడ్డాయి:

లోడ్ పరిమితి — ఇది ఒక నిర్దిష్ట కాల్ బ్రిడ్జ్ కోసం గరిష్ట సంఖ్యా లోడ్. ప్రతి ప్లాట్‌ఫారమ్‌కు CMS96000 కోసం 1000 మరియు వర్చువల్ మెషీన్‌కు ఒక్కో vCPUకి 1.25 GHz వంటి సిఫార్సు చేయబడిన లోడ్ పరిమితి ఉంటుంది. వివిధ కాల్‌లు పాల్గొనేవారి రిజల్యూషన్ మరియు ఫ్రేమ్ రేట్‌పై ఆధారపడి నిర్దిష్ట మొత్తంలో వనరులను వినియోగిస్తాయి.
NewConferenceLoadLimitBasisPoints (డిఫాల్ట్ 50% లోడ్‌లిమిట్) - సర్వర్ లోడ్ పరిమితిని సెట్ చేస్తుంది, ఆ తర్వాత కొత్త సమావేశాలు తిరస్కరించబడతాయి.
ఇప్పటికే ఉన్న కాన్ఫరెన్స్‌లోడ్‌లిమిట్ బేసిస్ పాయింట్‌లు (లోడ్‌లిమిట్‌లో డిఫాల్ట్ 80%) - ఇప్పటికే ఉన్న కాన్ఫరెన్స్‌లో చేరిన పాల్గొనేవారు తిరస్కరించబడే సర్వర్ లోడ్ విలువ.

ఈ ఫీచర్ కాల్ పంపిణీ మరియు లోడ్ బ్యాలెన్సింగ్ కోసం రూపొందించబడినప్పటికీ, టర్న్ సర్వర్లు, వెబ్ బ్రిడ్జ్ సర్వర్లు మరియు రికార్డర్‌లు వంటి ఇతర సమూహాలు కూడా కాల్ బ్రిడ్జ్ సమూహాలకు కేటాయించబడతాయి, తద్వారా అవి సరైన ఉపయోగం కోసం సరిగ్గా సమూహం చేయబడతాయి. ఈ ఆబ్జెక్ట్‌లలో ఏదైనా కాల్ గ్రూప్‌కు కేటాయించబడకపోతే, అవి ఎటువంటి ప్రత్యేక ప్రాధాన్యత లేకుండా అన్ని సర్వర్‌లకు అందుబాటులో ఉంటాయని భావించబడుతుంది.

ఈ పారామితులు ఇక్కడ కాన్ఫిగర్ చేయబడ్డాయి: cms.example.com:445/api/v1/సిస్టమ్/కాన్ఫిగరేషన్/క్లస్టర్

తర్వాత, మేము ప్రతి కాల్‌బ్రిడ్జ్‌కి అది ఏ కాల్‌బ్రిడ్జ్ సమూహానికి చెందినదో సూచిస్తాము:

మొదటి కాల్బ్రిడ్జ్

రెండవ కాల్బ్రిడ్జ్

మూడవ కాల్‌బ్రిడ్జ్


అందువలన, Cisco Meeting Server క్లస్టర్ యొక్క వనరులను మరింత సమర్ధవంతంగా ఉపయోగించడానికి మేము Call Brdige సమూహాన్ని కాన్ఫిగర్ చేసాము.

యాక్టివ్ డైరెక్టరీ నుండి వినియోగదారులను దిగుమతి చేస్తోంది

వెబ్ అడ్మిన్ సేవకు LDAP కాన్ఫిగరేషన్ విభాగం ఉంది, కానీ ఇది సంక్లిష్టమైన కాన్ఫిగరేషన్ ఎంపికలను అందించదు మరియు క్లస్టర్ డేటాబేస్‌లో సమాచారం నిల్వ చేయబడదు, కాబట్టి కాన్ఫిగరేషన్ వెబ్ ఇంటర్‌ఫేస్ ద్వారా ప్రతి సర్వర్‌లో మాన్యువల్‌గా చేయాలి API, మరియు మేము "మూడు సార్లు "లేవకండి" కాబట్టి మేము ఇప్పటికీ API ద్వారా డేటాను సెట్ చేస్తాము.

యాక్సెస్ చేయడానికి URLని ఉపయోగించడం cms01.example.com:445/api/v1/ldapServers LDAP సర్వర్ ఆబ్జెక్ట్‌ను సృష్టిస్తుంది, పారామితులను పేర్కొంటుంది:

• సర్వర్ IP
• పోర్ట్ సంఖ్య
• యూజర్ పేరు
• పాస్వర్డ్
• సురక్షిత

సురక్షితము - పోర్ట్‌పై ఆధారపడి ఒప్పు లేదా తప్పును ఎంచుకోండి, 389 - సురక్షితం కాదు, 636 - రక్షించబడింది.


సిస్కో మీటింగ్ సర్వర్‌లోని అట్రిబ్యూట్‌లకు LDAP సోర్స్ పారామితులను మ్యాపింగ్ చేస్తోంది.
LDAP మ్యాపింగ్ LDAP డైరెక్టరీలోని లక్షణాలను CMSలోని లక్షణాలకు మ్యాప్ చేస్తుంది. వాస్తవ లక్షణాలు:

• jid మ్యాపింగ్
• పేరు మ్యాపింగ్
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

లక్షణాల వివరణJID CMSలో వినియోగదారు లాగిన్ IDని సూచిస్తుంది. ఇది మైక్రోసాఫ్ట్ యాక్టివ్ డైరెక్టరీ LDAP సర్వర్ అయినందున, CMS JID LDAPలోని sAMAccountNameకి మ్యాప్ చేస్తుంది, ఇది తప్పనిసరిగా వినియోగదారు యొక్క యాక్టివ్ డైరెక్టరీ లాగిన్ ID. మీరు sAMAccountName తీసుకొని దాని చివరన conf.pod6.cms.lab డొమైన్‌ను జోడించారని కూడా గమనించండి ఎందుకంటే ఇది మీ వినియోగదారులు CMSకి లాగిన్ చేయడానికి ఉపయోగించే లాగిన్.

పేరు మ్యాపింగ్ యాక్టివ్ డైరెక్టరీ డిస్‌ప్లే నేమ్ ఫీల్డ్‌లో ఉన్న దానితో యూజర్ యొక్క CMS నేమ్ ఫీల్డ్‌తో సరిపోలుతుంది.

coSpaceNameMapping displayName ఫీల్డ్ ఆధారంగా CMS స్పేస్ నేమ్‌ను సృష్టిస్తుంది. ఈ లక్షణం, coSpaceUriMapping లక్షణంతో పాటు, ప్రతి వినియోగదారు కోసం ఖాళీని సృష్టించడానికి అవసరం.

coSpaceUriMapping వినియోగదారు వ్యక్తిగత స్థలంతో అనుబంధించబడిన URI యొక్క వినియోగదారు భాగాన్ని నిర్వచిస్తుంది. కొన్ని డొమైన్‌లను స్పేస్‌లోకి డయల్ చేయడానికి కాన్ఫిగర్ చేయవచ్చు. ఈ డొమైన్‌లలో ఒకదానికి వినియోగదారు భాగం ఈ ఫీల్డ్‌తో సరిపోలితే, కాల్ ఆ వినియోగదారు స్పేస్‌కు మళ్లించబడుతుంది.

coSpaceSecondaryUriMapping అంతరిక్షాన్ని చేరుకోవడానికి రెండవ URIని నిర్వచిస్తుంది. coSpaceUriMapping పరామితిలో నిర్వచించబడిన ఆల్ఫాన్యూమరిక్ URIకి ప్రత్యామ్నాయంగా దిగుమతి చేసుకున్న వినియోగదారు స్థలానికి కాల్‌లను రూటింగ్ చేయడానికి సంఖ్యా మారుపేరును జోడించడానికి ఇది ఉపయోగించబడుతుంది.

LDAP సర్వర్ మరియు LDAP మ్యాపింగ్ కాన్ఫిగర్ చేయబడ్డాయి. ఇప్పుడు మీరు LDAP మూలాన్ని సృష్టించడం ద్వారా వాటిని ఒకదానితో ఒకటి లింక్ చేయాలి.

యాక్సెస్ చేయడానికి URLని ఉపయోగించడం cms01.example.com:445/api/v1/ldapSource వంటి పారామితులను పేర్కొంటూ, LDAP మూల వస్తువును సృష్టిస్తుంది:

• సర్వర్
• మ్యాపింగ్
• బేస్ డిఎన్
• వడపోత

ఇప్పుడు LDAP కాన్ఫిగరేషన్ పూర్తయింది, మీరు మాన్యువల్ సింక్రొనైజేషన్ ఆపరేషన్ చేయవచ్చు.

మేము దీన్ని క్లిక్ చేయడం ద్వారా ప్రతి సర్వర్ యొక్క వెబ్ ఇంటర్‌ఫేస్‌లో చేస్తాము ఇప్పుడు సమకాలీకరించండి విభాగం యాక్టివ్ డైరెక్టరీ


లేదా ఆదేశంతో API ద్వారా POST యాక్సెస్ చేయడానికి URLని ఉపయోగిస్తోంది cms01.example.com:445/api/v1/ldapSyncs

తాత్కాలిక సమావేశాలు

ఇది ఏమిటి?సాంప్రదాయ భావనలో, ఇద్దరు పాల్గొనేవారు ఒకరితో ఒకరు మాట్లాడుకోవడం మరియు పాల్గొనేవారిలో ఒకరు (యూనిఫైడ్ CMతో రిజిస్టర్ చేయబడిన పరికరాన్ని ఉపయోగించడం) "కాన్ఫరెన్స్" బటన్‌ను నొక్కి, అవతలి వ్యక్తికి కాల్ చేసి, ఆ మూడవ పక్షంతో మాట్లాడిన తర్వాత కాన్ఫరెన్స్ అంటారు. , త్రైపాక్షిక కాన్ఫరెన్స్‌లో పాల్గొనే వారందరితో చేరడానికి "కాన్ఫరెన్స్" బటన్‌ను మళ్లీ నొక్కండి.

CMSలో షెడ్యూల్ చేయబడిన కాన్ఫరెన్స్ నుండి అడ్-హాక్ కాన్ఫరెన్స్‌ను వేరు చేసేది ఏమిటంటే, అడ్-హాక్ కాన్ఫరెన్స్ కేవలం CMSకి SIP కాల్ కాదు. కాన్ఫరెన్స్ ఇనిషియేటర్ అందరినీ ఒకే సమావేశానికి ఆహ్వానించడానికి రెండవసారి కాన్ఫరెన్స్ బటన్‌ను క్లిక్ చేసినప్పుడు, అన్ని కాల్‌లు బదిలీ చేయబడే ఆన్-ది-ఫ్లై కాన్ఫరెన్స్‌ను రూపొందించడానికి యూనిఫైడ్ CM తప్పనిసరిగా CMSకి API కాల్ చేయాలి. ఇదంతా పార్టిసిపెంట్స్ గమనించకుండానే జరుగుతుంది.

దీని అర్థం యూనిఫైడ్ CM తప్పనిసరిగా API ఆధారాలను మరియు సేవ యొక్క వెబ్‌అడ్మిన్ చిరునామా/పోర్ట్ అలాగే SIP ట్రంక్‌ను నేరుగా CMS సర్వర్‌కి కాల్‌ని కొనసాగించడానికి కాన్ఫిగర్ చేయాలి.

అవసరమైతే, CUCM డైనమిక్‌గా CMSలో ఖాళీని సృష్టించగలదు, తద్వారా ప్రతి కాల్ CMSకి చేరుకుంటుంది మరియు స్పేస్‌ల కోసం ఉద్దేశించిన ఇన్‌కమింగ్ కాల్ నియమానికి సరిపోలుతుంది.

CUCMతో ఏకీకరణ వ్యాసంలో వివరించిన విధంగానే కాన్ఫిగర్ చేయబడింది ముందు Cisco UCMలో కాకుండా మీరు CMS కోసం మూడు ట్రంక్‌లు, మూడు కాన్ఫరెన్స్ బ్రిడ్జ్‌లను సృష్టించాలి, SIP సెక్యూరిటీ ప్రొఫైల్‌లో మూడు సబ్జెక్ట్ పేర్లు, రూట్ గ్రూప్‌లు, రూట్ లిస్ట్‌లు, మీడియా రిసోర్స్ గ్రూప్‌లు మరియు మీడియా రిసోర్స్ గ్రూప్ జాబితాలను పేర్కొనండి మరియు కొన్ని రూటింగ్ నియమాలను జోడించండి సిస్కో మీటింగ్ సర్వర్‌కి.

SIP భద్రతా ప్రొఫైల్:


ట్రంక్లు:


ప్రతి ట్రంక్ ఒకేలా కనిపిస్తుంది:




కాన్ఫరెన్స్ వంతెన


ప్రతి కాన్ఫరెన్స్ వంతెన ఒకేలా కనిపిస్తుంది:


రూట్ గ్రూప్


రూట్ జాబితా


మీడియా రిసోర్స్ గ్రూప్


మీడియా రిసోర్స్ గ్రూప్ జాబితా

కాల్ నియమాలు

యూనిఫైడ్ CM లేదా ఎక్స్‌ప్రెస్‌వే వంటి మరింత అధునాతన కాల్ మేనేజ్‌మెంట్ సిస్టమ్‌ల వలె కాకుండా, CMS కొత్త కాల్‌ల కోసం SIP అభ్యర్థన-URI ఫీల్డ్‌లోని డొమైన్‌ను మాత్రమే చూస్తుంది. కాబట్టి SIP ఆహ్వానం సిప్ కోసం అయితే: [ఇమెయిల్ రక్షించబడింది]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 చిరునామా కూడా) కోసం ఉద్దేశించిన ప్రతిదానికీ నియమాలను సెటప్ చేయాలి. మా బాహ్య కాల్ నియంత్రణ, యూనిఫైడ్ CM, ప్రతి CMS సర్వర్‌లకు వ్యక్తిగతంగా అంకితం చేయబడిన SIP ట్రంక్‌లను కాన్ఫిగర్ చేస్తుంది. ఈ SIP ట్రంక్‌ల గమ్యస్థానం IP చిరునామా కాదా లేదా సర్వర్ యొక్క FQDN దాని IP చిరునామా లేదా FQDNకి దర్శకత్వం వహించిన కాల్‌లను ఆమోదించడానికి CMS కాన్ఫిగర్ చేయబడాలా అనేదానిపై ఆధారపడి ఉంటుంది.

అత్యధిక ప్రాధాన్యత కలిగిన ఇన్‌బౌండ్ నియమాన్ని కలిగి ఉన్న డొమైన్ ఏదైనా వినియోగదారు ఖాళీల కోసం డొమైన్‌గా ఉపయోగించబడుతుంది. వినియోగదారులు LDAP ద్వారా సమకాలీకరించినప్పుడు, CMS స్వయంచాలకంగా ఖాళీలను సృష్టిస్తుంది, కానీ URI (coSpaceUriMapping) యొక్క వినియోగదారు భాగం మాత్రమే, ఉదాహరణకు, user.space. భాగం డొమైన్ ఈ నియమం ఆధారంగా పూర్తి URI రూపొందించబడింది. వాస్తవానికి, మీరు ఈ సమయంలో వెబ్ బ్రిడ్జ్‌కి లాగిన్ చేస్తే, స్పేస్ URIకి డొమైన్ లేదని మీరు చూస్తారు. ఈ నియమాన్ని అత్యంత ప్రాధాన్యతగా సెట్ చేయడం ద్వారా, మీరు రూపొందించబడిన ఖాళీల కోసం డొమైన్‌ను సెట్ చేస్తున్నారు confexample.com.


అవుట్‌గోయింగ్ కాల్ నియమాలు

యూనిఫైడ్ CM క్లస్టర్‌కి అవుట్‌బౌండ్ కాల్‌లు చేయడానికి వినియోగదారులను అనుమతించడానికి, మీరు తప్పనిసరిగా అవుట్‌బౌండ్ నియమాలను కాన్ఫిగర్ చేయాలి. జబ్బర్ వంటి యూనిఫైడ్ CMతో నమోదు చేయబడిన ముగింపు పాయింట్ల డొమైన్ example.com. ఈ డొమైన్‌కు చేసే కాల్‌లు ప్రామాణిక SIP కాల్‌ల వలె యూనిఫైడ్ CM కాల్ ప్రాసెసింగ్ నోడ్‌లకు మళ్లించబడాలి. ప్రధాన సర్వర్ cucm-01.example.com మరియు అదనపు సర్వర్ cucm-02.example.com.

మొదటి నియమం క్లస్టర్ సర్వర్‌ల మధ్య కాల్‌ల యొక్క సరళమైన రూటింగ్‌ను వివరిస్తుంది.

ఫీల్డ్ డొమైన్ నుండి స్థానికం "@" గుర్తు తర్వాత కాల్ చేయబడిన వ్యక్తికి కాలర్ యొక్క SIP-URIలో ప్రదర్శించబడే వాటికి బాధ్యత వహిస్తుంది. మేము దానిని ఖాళీగా ఉంచినట్లయితే, "@" గుర్తు తర్వాత ఈ కాల్ పాస్ అయ్యే CUCM యొక్క IP చిరునామా ఉంటుంది. మేము డొమైన్‌ను పేర్కొన్నట్లయితే, “@” గుర్తు తర్వాత వాస్తవానికి డొమైన్ ఉంటుంది. తిరిగి కాల్ చేయడానికి ఇది అవసరం, లేకపోతే SIP-URI name@ip-address ద్వారా తిరిగి కాల్ చేయడం సాధ్యం కాదు.

పేర్కొన్నప్పుడు కాల్ చేయండి డొమైన్ నుండి స్థానికం


ఎప్పుడు కాల్ చేయండి NOT సూచించబడింది డొమైన్ నుండి స్థానికం


అవుట్‌గోయింగ్ కాల్‌ల కోసం ఎన్‌క్రిప్టెడ్ లేదా అన్‌క్రిప్టెడ్ అని స్పష్టంగా పేర్కొనండి, ఎందుకంటే ఆటో పారామీటర్‌తో ఏదీ పని చేయదు.

రికార్డింగ్

వీడియో సమావేశాలు రికార్డ్ సర్వర్ ద్వారా రికార్డ్ చేయబడతాయి. రికార్డర్ సరిగ్గా సిస్కో మీటింగ్ సర్వర్ లాగానే ఉంటుంది. రికార్డర్‌కు ఎలాంటి లైసెన్స్‌ల ఇన్‌స్టాలేషన్ అవసరం లేదు. CallBridge సేవలను అమలు చేసే సర్వర్‌లకు రికార్డింగ్ లైసెన్స్‌లు అవసరం, అనగా. రికార్డింగ్ లైసెన్స్ అవసరం మరియు తప్పనిసరిగా కాల్‌బ్రిడ్జ్ కాంపోనెంట్‌కు వర్తింపజేయాలి మరియు సర్వర్ నడుస్తున్న రికార్డర్‌కు కాదు. రికార్డర్ ఎక్స్‌టెన్సిబుల్ మెసేజింగ్ మరియు ప్రెజెన్స్ ప్రోటోకాల్ (XMPP) క్లయింట్‌గా ప్రవర్తిస్తుంది, కాబట్టి XMPP సర్వర్ తప్పనిసరిగా CallBridge హోస్టింగ్ సర్వర్‌లో ప్రారంభించబడాలి.

ఎందుకంటే మాకు క్లస్టర్ ఉంది మరియు క్లస్టర్‌లోని మూడు సర్వర్‌లలో లైసెన్స్‌ను "విస్తరించాలి". అప్పుడు మీ వ్యక్తిగత ఖాతాలో మేము క్లస్టర్‌లో చేర్చబడిన అన్ని CMS సర్వర్‌ల యొక్క A-ఇంటర్‌ఫేస్‌ల యొక్క 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-మరియు-తరువాత. pdf

మూలం: www.habr.com