ProHoster > ΠΠ»ΠΎΠ³ > Pagdumala > Cisco Meeting Server 2.5.2. Cluster sa Scalable ug Resilient mode nga adunay pagrekord sa video conference
Cisco Meeting Server 2.5.2. Cluster sa Scalable ug Resilient mode nga adunay pagrekord sa video conference
Niini nga isyu akong ipakita ug ipatin-aw ang pipila sa mga kakuti sa pag-set up sa usa ka CMS server sa failover cluster mode.
TeoryaSa kinatibuk-an, adunay tulo ka matang sa CMS server deployment:
Single Combined(Single combined), i.e. kini usa ka server diin ang tanan nga kinahanglan nga mga serbisyo nagdagan. Sa kadaghanan nga mga kaso, kini nga matang sa deployment angay lamang alang sa internal nga pag-access sa kliyente ug sa mas gagmay nga mga palibot diin ang scalability ug redundancy nga mga limitasyon sa usa ka server dili usa ka kritikal nga isyu, o sa mga sitwasyon diin ang CMS naghimo lamang sa pipila ka mga gimbuhaton, sama sa ad hoc mga komperensya sa Cisco UCM.
Gibanabana nga laraw sa trabaho:
Single Split(Single Split) nagpalapad sa miaging tipo sa pag-deploy pinaagi sa pagdugang og bulag nga server para sa eksternal nga pag-access. Sa legacy deployments, kini nagpasabot sa pagdeploy sa usa ka CMS server sa usa ka demilitarized network segment (DMZ) diin ang mga eksternal nga kliyente maka-access niini, ug usa ka CMS server sa network core diin ang mga internal nga kliyente maka-access sa CMS. Kini nga partikular nga modelo sa pag-deploy karon gipulihan sa gitawag nga tipo Usa ka Edge, nga naglangkob sa mga server Cisco Expressway, nga adunay o adunay daghan nga parehas nga mga kapabilidad sa pag-bypass sa Firewall aron ang mga kliyente dili kinahanglan nga magdugang usa ka gipahinungod nga sulud sa CMS server.
Gibanabana nga laraw sa trabaho:
Scalable ug Resilient(Scalable ug Fault Tolerant) Kini nga matang naglakip sa redundancy alang sa matag component, nga nagtugot sa sistema nga motubo uban sa imong mga panginahanglan ngadto sa pinakataas nga kapasidad niini samtang naghatag ug redundancy sa kaso sa kapakyasan. Gigamit usab niini ang konsepto sa Single Edge aron mahatagan ang luwas nga pag-access sa gawas. Kini ang tipo nga atong tan-awon sa kini nga yugto. Kung nahibal-an namon kung giunsa ang pag-deploy sa kini nga klase sa cluster, dili lang namon masabtan ang ubang mga lahi sa pag-deploy, apan masabtan usab namon kung giunsa paghimo ang mga cluster sa CMS server aron ma-accommodate ang potensyal nga pagtubo sa panginahanglan.
Sa dili pa mopadayon sa pag-deploy, kinahanglan nimo nga masabtan ang pipila ka mga batakang butang, nga mao
Panguna nga mga sangkap sa software sa CMS:
database: Nagtugot kanimo sa pagkombinar sa pipila ka mga configuration, sama sa dial plan, user space, ug user mismo. Nagsuporta sa clustering alang sa taas nga magamit (single master) lamang.
Tawga si Bridge: usa ka serbisyo alang sa audio ug video conferencing nga naghatag og bug-os nga kontrol sa pagdumala ug pagproseso sa mga tawag ug mga proseso sa multimedia. Nagsuporta sa clustering alang sa taas nga pagkaanaa ug scalability.
XMPP server: responsable sa pagrehistro ug pag-authenticate sa mga kliyente gamit ang Cisco Meeting Application ug/o WebRTC(real-time nga komunikasyon, o yano sa browser), ingon man usab sa intercomponent signaling. Mahimong i-cluster alang sa taas nga magamit lamang.
Tulay sa Web: Naghatag og access sa kliyente sa WebRTC.
Loadbalancer: Naghatag usa ka punto sa koneksyon alang sa Cisco Meeting Apps sa Single Split mode. Maminaw sa eksternal nga interface ug pantalan alang sa umaabot nga mga koneksyon. Sa parehas nga paagi, ang load balancer modawat sa umaabot nga mga koneksyon sa TLS gikan sa XMPP server, diin kini makabalhin sa mga koneksyon sa TCP gikan sa mga eksternal nga kliyente.
Sa among senaryo dili kini kinahanglan.
TURN server: Naghatag og Firewall bypass nga teknolohiya nga nagtugot
ibutang ang among CMS sa luyo sa usa ka Firewall o NAT aron makonektar ang mga eksternal nga kliyente gamit ang Cisco Meeting App o SIP nga mga aparato. Sa among senaryo dili kini kinahanglan.
Web Admin: Administrative interface ug API access, lakip ang espesyal nga Unified CM conferences.
Mga Mode sa Pag-configure
Dili sama sa kadaghanan sa ubang mga produkto sa Cisco, ang Cisco Meeting Server nagsuporta sa tulo ka mga pamaagi sa pag-configure aron ma-accommodate ang bisan unsang matang sa pag-deploy.
Command line (CLI): Command line interface nga nailhan nga MMP alang sa inisyal nga configuration ug mga buluhaton sa sertipiko.
Web Administrator: Panguna alang sa mga pag-configure nga may kalabotan sa CallBridge, labi na kung mag-set up sa usa ka dili-clustered server.
PAHULAY API: Gigamit alang sa labing komplikado nga mga buluhaton sa pag-configure ug mga clustered nga mga buluhaton nga may kalabutan sa database.
Dugang pa sa ibabaw, ang protocol gigamit SFTP sa pagbalhin sa mga fileβkasagaran mga lisensya, mga sertipiko, o mga logβngadto ug gikan sa CMS server.
Sa deployment guides gikan sa Cisco gisulat kini sa puti ug English nga ang cluster kinahanglang i-deploy labing menos tulo mga server (nodes) sa konteksto sa mga database. Kay Uban lamang sa usa ka talagsaon nga gidaghanon sa mga node ang mekanismo sa pagpili sa usa ka bag-ong Database Master magtrabaho, ug sa kinatibuk-an ang Database Master adunay koneksyon sa kadaghanan sa CMS server database.
Ug ingon sa gipakita sa praktis, ang duha ka mga server (node) dili gyud igo. Ang mekanismo sa pagpili molihok kung ang Agalon gi-reboot, ang Slave server mahimong Agalon lamang human ang rebooted server madala. Apan, kung sa usa ka kumpol sa duha ka mga server ang Master server kalit nga mawala, nan ang Slave server dili mahimong Agalon, ug kung ang Slave mogawas, nan ang nahabilin nga Master server mahimong Slave.
Apan sa konteksto sa XMPP, kinahanglan gyud nga mag-assemble og usa ka cluster sa tulo ka mga server, tungod kay kung, pananglitan, imong gi-disable ang serbisyo sa XMPP sa usa sa mga server diin ang XMMP naa sa status sa Lider, nan sa nahabilin nga server ang XMPP magpabilin sa status sa Follower ug ang mga koneksyon sa CallBridge sa XMPP mahulog, tungod kay Ang CallBridge nagkonektar lamang sa XMPP nga adunay status sa Lider. Ug kini kritikal, tungod kay ... walay bisan usa ka tawag nga moagi.
Usab sa parehas nga deployment naggiya usa ka cluster nga adunay usa ka XMPP server ang gipakita.
Ug sa pagkonsiderar sa ibabaw, kini nahimong tin-aw ngano: kini nagtrabaho tungod kay kini anaa sa failover mode.
Sa among kaso, ang XMPP server maanaa sa tanan nga tulo ka mga node.
Gituohan nga ang tanan nga tulo sa among mga server nahuman na.
Mga rekord sa DNS
Sa dili ka pa magsugod sa pag-set up sa mga server, kinahanglan nimo nga maghimo mga rekord sa DNS Π ΠΈ Ang SRV matang:
Palihug timan-i nga sa among mga DNS record adunay duha ka domain example.com ug conf.example.com. Ang Example.com usa ka domain nga magamit sa tanan nga mga subscriber sa Cisco Unified Communication Manager para sa ilang mga URI, nga lagmit naa sa imong imprastraktura o lagmit naa. O ang example.com nagpares sa parehas nga domain nga gigamit sa mga tiggamit alang sa ilang mga adres sa email. O ang kliyente sa Jabber sa imong laptop mahimong adunay URI [protektado sa email]. Domain confAng .example.com mao ang domain nga i-configure alang sa mga tiggamit sa Cisco Meeting Server. Ang domain sa Cisco Meeting Server mahimong conf.example.com, mao nga para sa sama nga Jabber user, ang user@ URI kinahanglan nga gamiton sa pag-log in sa Cisco Meeting Serverconf.example.com.
Basic nga configuration
Ang tanan nga mga setting nga gihulagway sa ubos gipakita sa usa ka server, apan kini kinahanglan nga buhaton sa matag server sa cluster.
QoS
Tungod kay ang CMS nagmugna Tinuod nga panahon sensitibo sa trapiko sa mga paglangan ug pagkawala sa packet, sa kadaghanan nga mga kaso girekomenda nga i-configure ang kalidad sa serbisyo (QoS). Aron makab-ot kini, gisuportahan sa CMS ang mga packet sa pag-tag gamit ang Differentiated Services Codes (DSCPs) nga nahimo niini. Bisan tuod ang DSCP-based nga traffic prioritization nagdepende kung giunsa ang trapiko giproseso sa network nga mga component sa imong imprastraktura, sa among kaso among i-configure ang among CMS gamit ang tipikal nga DSCP prioritization base sa QoS best practices.
Sa ingon, ang tanan nga trapiko sa video gimarkahan nga AF41 (DSCP 0x22), ang tanan nga trapiko sa tingog gimarkahan nga EF (DSCP 0x2E), uban pang mga lahi sa ubos nga trapiko sa latency sama sa SIP ug XMPP nga gigamit ang AF31 (DSCP 0x1A).
Pagsusi:
NTP
Ang Network Time Protocol (NTP) importante dili lamang sa paghatag og tukma nga mga timestamp sa mga tawag ug mga komperensya, kondili alang usab sa pag-verify sa mga sertipiko.
Idugang ang mga NTP server sa imong imprastraktura nga adunay usa ka command sama
ntp server add <server>
Sa among kaso, adunay duha ka ingon nga mga server, mao nga adunay duha ka mga team.
Pagsusi:
Ug ibutang ang time zone para sa among server
DNS
Gidugang namon ang mga DNS server sa CMS nga adunay usa ka mando sama sa:
dns add forwardzone <domain-name> <server ip>
Sa among kaso, adunay duha ka ingon nga mga server, mao nga adunay duha ka mga team.
Pagsusi:
Konfigurasyon sa Interface sa Network
Gi-configure namo ang interface gamit ang command sama sa:
Gibutang namon ang ngalan sa server nga adunay usa ka mando sama sa:
hostname <name>
Ug nag-reboot kami.
Nakompleto niini ang batakang pag-configure.
Mga sertipiko
TeoryaAng Cisco Meeting Server nanginahanglan og encrypted nga komunikasyon tali sa lain-laing mga component, ug isip resulta, gikinahanglan ang X.509 certificates para sa tanang CMS deployment. Nagtabang sila sa pagsiguro nga ang mga serbisyo / server gisaligan sa ubang mga server / serbisyo.
Ang matag serbisyo nanginahanglan usa ka sertipiko, apan ang paghimo og lahi nga mga sertipiko alang sa matag serbisyo mahimong mosangput sa kalibog ug dili kinahanglan nga pagkakomplikado. Sa swerte, makamugna mi og public-private key pair sa usa ka certificate ug unya gamiton kini pag-usab sa daghang serbisyo. Sa among kaso, ang parehas nga sertipiko ang gamiton alang sa Tawag Bridge, XMPP Server, Web Bridge ug Web Admin. Sa ingon, kinahanglan nimo nga maghimo usa ka pares nga publiko ug pribado nga mga yawe sa sertipiko alang sa matag server sa cluster.
Ang clustering sa database, bisan pa, adunay pipila ka espesyal nga mga kinahanglanon sa sertipiko ug busa nanginahanglan kaugalingon nga mga sertipiko nga lahi sa ubang mga serbisyo. Ang CMS naggamit sa usa ka sertipiko sa server, nga susama sa mga sertipiko nga gigamit sa ubang mga server, apan adunay usab usa ka sertipiko sa kliyente nga gigamit alang sa mga koneksyon sa database. Ang mga sertipiko sa database gigamit alang sa pag-authenticate ug pag-encrypt. Imbis nga maghatag usa ka username ug password alang sa kliyente aron makonektar sa database, nagpresentar kini usa ka sertipiko sa kliyente nga gisaligan sa server. Ang matag server sa database cluster mogamit sa parehas nga publiko ug pribado nga pares nga yawe. Gitugotan niini ang tanan nga mga server sa cluster nga ma-encrypt ang datos sa paagi nga mahimo ra kini ma-decrypt sa ubang mga server nga parehas usab nga pares nga yawe.
Para sa redundancy sa pagtrabaho, database clusters kinahanglan nga naglangkob sa usa ka minimum sa 3 servers, apan dili labaw pa kay sa 5, uban sa usa ka maximum round-trip nga panahon sa 200 ms tali sa bisan unsa nga cluster nga mga miyembro. Kini nga limitasyon mas estrikto kay sa Call Bridge clustering, mao nga kasagaran kini ang limiting factor sa geographically distributed deployments.
Ang papel sa database alang sa usa ka CMS adunay daghang talagsaon nga mga kinahanglanon. Dili sama sa ubang mga tahas, nanginahanglan kini usa ka sertipiko sa kliyente ug server, diin ang sertipiko sa kliyente adunay usa ka piho nga natad sa CN nga gipresentar sa server.
Ang CMS naggamit ug postgres database nga adunay usa ka master ug ubay-ubay nga parehas nga mga replika. Adunay usa lamang ka nag-unang database sa usa ka higayon (ang "database server"). Ang nahabilin nga mga miyembro sa cluster mga replika o "mga kliyente sa database".
Ang usa ka database cluster nanginahanglan usa ka gipahinungod nga sertipiko sa server ug usa ka sertipiko sa kliyente. Kinahanglang pirmahan sila pinaagi sa mga sertipiko, kasagaran usa ka internal nga pribadong awtoridad sa sertipiko. Tungod kay ang bisan kinsa nga miyembro sa database cluster mahimong master, ang database server ug kliyente nga mga pares nga sertipiko (nga adunay publiko ug pribado nga mga yawe) kinahanglan nga kopyahon sa tanan nga mga server aron sila makaangkon sa pagkatawo sa kliyente o database server. Dugang pa, ang CA root certificate kinahanglang i-load aron masiguro nga ang mga sertipiko sa kliyente ug server mahimong mapamatud-an.
Mao nga, naghimo kami usa ka hangyo alang sa usa ka sertipiko nga magamit sa tanan nga mga serbisyo sa server gawas sa database (adunay usa ka lahi nga hangyo alang niini) nga adunay usa ka mando sama sa:
Sa CN among gisulat ang kinatibuk-ang ngalan sa among mga server. Pananglitan, kung ang mga hostname sa among mga server server01, server02, server03, unya CN na server.example.com
Gibuhat namon ang parehas sa nahabilin nga duha nga mga server nga adunay kalainan nga ang mga mando adunay sulud nga katugbang nga "mga hostname"
Naghimo kami og duha ka hangyo alang sa mga sertipiko nga gamiton sa serbisyo sa database nga adunay mga sugo sama sa:
diin dbclusterserver ΠΈ dbclusterclient mga ngalan sa among mga hangyo ug umaabot nga mga sertipiko, hostname1(2)(3) mga ngalan sa katugbang nga mga server.
Gihimo namo kini nga pamaagi sa usa lamang ka server (!), ug among i-upload ang mga sertipiko ug katugbang nga .key files ngadto sa ubang mga server.
I-enable ang client certificate mode sa AD CS
Kinahanglan nimo usab nga i-merge ang mga sertipiko alang sa matag server sa usa ka file.Sa *NIX:
Ug i-upload sa matag server:
1. "Indibidwal" nga sertipiko sa server.
2. Root certificate (uban sa mga intermediate, kung aduna man).
3. Mga sertipiko alang sa database ("server" ug "kliyente") ug mga file nga adunay .key extension, nga namugna sa paghimo sa usa ka hangyo alang sa "server" ug "kliyente" nga mga sertipiko sa database. Kini nga mga file kinahanglan nga parehas sa tanan nga mga server.
4. File sa tanang tulo ka "indibidwal" nga mga sertipiko.
Ingon usa ka sangputanan, kinahanglan ka makakuha usa ka butang nga sama niini nga litrato sa file sa matag server.
Database Cluster
Karon nga naa na nimo ang tanan nga mga sertipiko nga gi-upload sa mga server sa CMS, mahimo nimong i-configure ug mahimo ang pag-cluster sa database taliwala sa tulo nga mga node. Ang unang lakang mao ang pagpili sa usa ka server isip master node sa database cluster ug bug-os nga i-configure kini.
Master nga Database
Ang unang lakang sa pag-set up sa database replication mao ang pagtino sa mga sertipiko nga gamiton alang sa database. Gihimo kini gamit ang usa ka mando sama sa:
Kung maayo ang tanan, makadawat kami mga linya sa SUCCESS nga nagpakita nga ang Web Admin husto nga gi-configure alang sa network ug sertipiko. Gisusi namo ang pagpaandar sa serbisyo gamit ang web browser ug gisulod ang adres sa web administrator, pananglitan: cms.example.com: 445
Tawga ang Bridge Cluster
Ang Call Bridge mao ra ang serbisyo nga naa sa matag pag-deploy sa CMS. Ang Call Bridge mao ang panguna nga mekanismo sa komperensya. Naghatag usab kini og interface sa SIP aron ang mga tawag madala ngadto o gikan niini pinaagi sa, pananglitan, usa ka Cisco Unified CM.
Ang mga sugo nga gihulagway sa ubos kinahanglan nga ipatuman sa matag server nga adunay angay nga mga sertipiko.
Busa:
Gi-associate namo ang mga sertipiko sa serbisyo sa Call Bridge nga adunay command sama sa:
Gibugkos namo ang mga serbisyo sa CallBridge sa interface nga among gikinahanglan sa sugo:
callbridge listen a
Ug i-restart ang serbisyo gamit ang mando:
callbridge restart
Karon nga na-configure na namo ang among Call Bridges, mahimo na namo nga i-configure ang Call Bridge clustering. Ang Call Bridge clustering lahi sa database o XMPP clustering. Makasuporta ang Call Bridge Cluster gikan sa 2 hangtod 8 node nga walaβy mga pagdili. Naghatag kini dili lamang sa redundancy, apan usab sa pagbalanse sa load aron ang mga komperensya mahimong aktibo nga maapod-apod sa mga server sa Call Bridge gamit ang intelihenteng pag-apod-apod sa tawag. Ang CMS adunay dugang nga mga bahin, Call Bridge nga mga grupo ug may kalabutan nga mga bahin nga magamit alang sa dugang nga pagdumala.
Ang call bridge clustering gi-configure una pinaagi sa web admin interface
Ang pamaagi nga gihulagway sa ubos kinahanglan nga himuon sa matag server sa cluster.
Ug busa,
1. Lakaw sa web ngadto sa Configuration > Cluster.
2. Sa Tawga ang identidad sa Bridge Ingon usa ka talagsaon nga ngalan, isulud ang callbridge [01,02,03] nga katumbas sa ngalan sa server. Kini nga mga ngalan kay arbitraryo, apan kinahanglan nga talagsaon alang niini nga cluster. Deskriptibo sila sa kinaiyahan tungod kay gipakita nila nga sila mga tig-ila sa server [01,02,03].
3.B Clustered Call Bridges pagsulod sa web administrator URL sa among mga server sa cluster, CMS[01,02,03].example.com:445, sa natad sa Address. Siguruha nga ipiho ang pantalan. Mahimo nimong biyaan nga walay sulod ang peer link nga SIP domain.
4. Pagdugang og sertipiko sa pagsalig sa CallBridge sa matag server, ang file diin naglangkob sa tanan nga mga sertipiko sa among mga server, nga among gihiusa sa kini nga file sa sinugdanan, nga adunay usa ka mando sama sa:
Ingon usa ka sangputanan, sa matag server kinahanglan nimo nga makuha kini nga litrato:
XMPP Cluster
Ang serbisyo sa XMPP sa CMS gigamit sa pagdumala sa tanang rehistrasyon ug authentication para sa Cisco Meeting Apps (CMA), lakip ang CMA WebRTC web client. Ang Call Bridge mismo naglihok usab ingon usa ka kliyente sa XMPP alang sa mga katuyoan sa pag-authenticate ug busa kinahanglan nga i-configure sama sa ubang mga kliyente. Ang XMPP fault tolerance usa ka bahin nga gisuportahan sa mga palibot sa produksiyon sukad sa bersyon 2.1
Ang mga sugo nga gihulagway sa ubos kinahanglan nga ipatuman sa matag server nga adunay angay nga mga sertipiko.
Busa:
Gi-associate namo ang mga sertipiko sa serbisyo sa XMPP sa usa ka sugo sama sa:
Dayon ipasabut ang interface sa pagpaminaw gamit ang sugo:
xmpp listen a
Ang serbisyo sa XMPP nanginahanglan usa ka talagsaon nga domain. Kini ang login alang sa mga tiggamit. Sa laing pagkasulti, kung ang usa ka user mosulay sa pag-login gamit ang CMA app (o pinaagi sa WebRTC client), sila mosulod userID@logindomain. Sa among kaso kini mahimong userid@conf.example.com. Ngano nga dili na lang example.com? Sa among partikular nga deployment, gipili namo ang among Unified CM domain nga gamiton sa mga user sa Jabber sa Unified CM isip example.com, mao nga nanginahanglan mi og lain nga domain para sa mga CMS user aron maruta ang mga tawag paingon ug gikan sa CMS pinaagi sa SIP domains.
I-set up ang XMPP domain gamit ang command sama sa:
xmpp domain <domain>
Ug i-enable ang serbisyo sa XMPP gamit ang command:
xmpp enable
Sa serbisyo sa XMPP, kinahanglan ka maghimo ug mga kredensyal para sa matag Tawag nga Tulay nga gamiton kung magparehistro sa serbisyo sa XMPP. Kini nga mga ngalan kay arbitraryo (ug walay kalabotan sa talagsaong mga ngalan nga imong gi-configure para sa call bridge clustering). Kinahanglan nimong idugang ang tulo ka mga tulay sa tawag sa usa ka server sa XMPP ug dayon isulod ang mga kredensyal sa ubang mga server sa XMPP sa cluster tungod kay kini nga pagsumpo dili mohaum sa database sa cluster. Sa ulahi among i-configure ang matag Call Bridge aron magamit kini nga ngalan ug sekreto aron magparehistro sa serbisyo sa XMPP.
Karon kinahanglan namong i-configure ang serbisyo sa XMPP sa unang server nga adunay tulo ka Call Bridges callbridge01, callbridge02 ug callbridge03. Ang matag account hatagan ug random nga mga password. Sa ulahi sila ipasulod sa ubang mga Call Bridge server aron maka-log in niini nga XMPP server. Pagsulod sa mosunod nga mga sugo:
Gidugang namon pag-ayo ang Sekreto aron, pananglitan, walaβy dugang nga mga wanang niini.
Ingon usa ka sangputanan, ang matag server kinahanglan adunay parehas nga litrato:
Sunod, sa tanan nga mga server sa cluster, among gipiho sa pagsalig ang file nga adunay tanan nga tulo nga mga sertipiko, nga gihimo kaniadto nga adunay usa ka mando nga sama niini:
xmpp cluster trust <trust bundle>
Gi-enable namo ang xmpp cluster mode sa tanang cluster server gamit ang command:
xmpp cluster enable
Sa unang server sa cluster, gisugdan namo ang paghimo sa usa ka xmpp cluster nga adunay command:
xmpp cluster initialize
Sa ubang mga server, pagdugang usa ka kumpol sa xmpp nga adunay usa ka mando sama sa:
xmpp cluster join <ip address head xmpp server>
Among gisusi sa matag server ang kalampusan sa paghimo og XMPP cluster sa matag server nga adunay mga sugo:
xmpp status
xmpp cluster status
Unang server:
Ikaduha nga server:
Ikatulong server:
Pagkonektar sa Call Bridge sa XMPP
Karon nga ang XMPP cluster nagdagan, kinahanglan nimo nga i-configure ang Call Bridge nga mga serbisyo aron makonektar sa XMPP cluster. Kini nga configuration gihimo pinaagi sa web admin.
Sa matag server, adto sa Configuration> General ug sa field Talagsaon nga Tawag Bridge nga ngalan pagsulat sa talagsaon nga mga ngalan nga katumbas sa server Tawag Bridge callbridge[01,02,03]... Sa uma domainconf.example.ru ug katugbang nga mga password, mahimo nimong espiya sila
sa bisan unsang server sa cluster nga adunay command:
xmpp callbridge list
Biyai nga walay sulod ang βServerβ field Callbridge mohimo ug DNS SRV lookup para sa _xmpp-component._tcp.conf.example.comaron makapangita usa ka magamit nga XMPP server. Ang mga adres sa IP alang sa pagkonektar sa mga callbridge sa XMPP mahimong magkalainlain sa matag server, nagdepende kini kung unsang mga kantidad ang gibalik sa hangyo sa rekord _xmpp-component._tcp.conf.example.com callbridge, nga sa baylo nagdepende sa mga setting sa prayoridad alang sa gihatag nga rekord sa DNS.
Sunod, adto sa Status> General aron masusi kung ang serbisyo sa Call Bride malampuson nga konektado sa serbisyo sa XMPP.
Tulay sa Web
Sa matag server sa cluster, i-enable ang serbisyo sa Web Bridge gamit ang command:
webbridge listen a:443
Gi-configure namon ang serbisyo sa Web Bridge nga adunay mga file sa sertipiko nga adunay usa ka mando sama sa:
Ang Web Bridge nagsuporta sa HTTPS. Kini mag-redirect sa HTTP ngadto sa HTTPS kung ma-configure nga gamiton ang "http-redirect".
Aron mahimo ang HTTP redirection, gamita ang mosunod nga sugo:
webbridge http-redirect enable
Aron mahibal-an ang Call Bridge nga ang Web Bridge makasalig sa mga koneksyon gikan sa Call Bridge, gamita ang mando:
webbridge trust <certfile>
diin kini usa ka file nga adunay tanan nga tulo ka mga sertipiko gikan sa matag server sa cluster.
Kini nga hulagway kinahanglan nga anaa sa matag server sa cluster.
Karon kinahanglan namon nga maghimo usa ka tiggamit nga adunay papel nga "appadmin", kinahanglan namon kini aron ma-configure namon ang among cluster(!), ug dili matag server sa cluster nga gilain, niining paagiha ang mga setting magamit nga parehas sa matag server bisan pa sa kamatuoran nga sila pagahimoon sa makausa.
Para sa pagtugot, pilia ang Basic sa Authorization section
Aron sa hustong pagpadala sa mga sugo ngadto sa CMS server, kinahanglan nimo nga itakda ang gikinahanglan nga encoding
Gipunting namon ang Webbridge gamit ang mando POST uban sa parameter url ug kahulogan cms.example.com
Sa webbridge mismo, among gipakita ang gikinahanglan nga mga parameter: pag-access sa bisita, protektadong pag-access, ug uban pa.
Tawga ang Bridge Groups
Sa kasagaran, ang CMS dili kanunay nga naghimo sa labing episyente nga paggamit sa mga kapanguhaan sa komperensya nga magamit niini.
Pananglitan, alang sa usa ka miting uban sa tulo ka mga partisipante, ang matag partisipante mahimong matapos sa tulo ka lain-laing mga Tawag Bridges. Aron kining tulo ka mga partisipante makakomunikar sa usag usa, ang Call Bridges awtomatik nga mag-establisar og mga koneksyon tali sa tanang server ug kliyente sa samang Luna, aron kining tanan morag ang tanang kliyente anaa sa samang server. Ikasubo, ang downside niini mao nga ang usa ka 3-tawo nga komperensya karon mogamit sa 9 media ports. Kini klaro nga usa ka dili maayo nga paggamit sa mga kapanguhaan. Dugang pa, kung ang usa ka Tawag nga Tulay tinuod nga nabug-atan, ang default nga mekanismo mao ang pagpadayon sa pagdawat sa mga tawag ug paghatag ug pagkunhod sa kalidad nga serbisyo sa tanan nga mga subscriber sa Tawag nga Tulay.
Nasulbad kini nga mga problema gamit ang bahin sa Call Bridge Group. Kini nga bahin gipaila sa bersyon 2.1 sa Cisco Meeting Server software ug gipalapdan aron suportahan ang pagbalanse sa load para sa inbound ug outbound nga mga tawag sa Cisco Meeting App (CMA), lakip ang mga partisipante sa WebRTC.
Aron masulbad ang problema sa pagkonekta pag-usab, tulo ka ma-configure nga limitasyon sa pagkarga ang gipaila alang sa matag Call Bridge:
LoadLimit β kini ang labing kadaghanon nga pagkarga sa numero para sa usa ka partikular nga Call Bridge. Ang matag plataporma adunay girekomendar nga limitasyon sa pagkarga, sama sa 96000 para sa CMS1000 ug 1.25 GHz kada vCPU para sa virtual machine. Ang lain-laing mga tawag naggamit sa usa ka piho nga kantidad sa mga kapanguhaan depende sa resolusyon ug frame rate sa partisipante. Bag-ongConferenceLoadLimitBasisPoints (default 50% loadLimit) - nagtakda sa limitasyon sa load sa server, pagkahuman gisalikway ang mga bag-ong komperensya. Anaa nga KomperensyaLoadLimitBasisPoints (default 80% sa loadLimit) - ang bili sa load sa server human niini ang mga partisipante nga moapil sa kasamtangan nga komperensya isalikway.
Samtang kini nga bahin gidisenyo alang sa pag-apod-apod sa tawag ug pagbalanse sa load, ang ubang mga grupo sama sa TURN Servers, Web Bridge Servers ug Recorders mahimo usab nga i-assign sa Call Bridge Groups aron sila usab ma-grupo sa hustong paagi alang sa labing maayo nga paggamit. Kung ang bisan kinsa niini nga mga butang wala ma-assign sa usa ka grupo sa tawag, kini gituohan nga magamit sa tanan nga mga server nga walaβy partikular nga prayoridad.
Kini nga mga parameter gi-configure dinhi: cms.example.com:445/api/v1/system/configuration/cluster
Sunod, among gipakita sa matag callbridge kung asa nga grupo sa callbridge kini nahisakop:
Unang callbridge
Ikaduha nga callbridge
Ikatulo nga callbridge
Busa, among gi-configure ang grupo sa Call Brdige aron mas episyenteng gamiton ang mga kahinguhaan sa Cisco Meeting Server cluster.
Pag-import sa mga tiggamit gikan sa Active Directory
Ang serbisyo sa Web Admin adunay LDAP configuration section, apan wala kini naghatag ug komplikadong mga opsyon sa configuration, ug ang impormasyon wala gitipigan sa cluster database, mao nga ang configuration kinahanglang buhaton, manwal sa matag server pinaagi sa Web interface, o pinaagi sa ang API, ug aron kita "makatulo ka beses" Ayaw pagbangon "among itakda ang datos pinaagi sa API.
Paggamit sa URL aron ma-access cms01.example.com:445/api/v1/ldapServers naghimo ug LDAP Server nga butang, nagpiho sa mga parametro sama sa:
IP sa server
numero sa pantalan
username
password
pagsiguro sa
Secure - pilia ang tinuod o sayup depende sa pantalan, 389 - dili luwas, 636 - gipanalipdan.
Pagmapa sa LDAP source parameters ngadto sa mga attribute sa Cisco Meeting Server.
Ang LDAP mapping nagmapa sa mga attribute sa LDAP directory ngadto sa mga attribute sa CMS. Ang aktuwal nga mga kinaiya:
jidMapping
nameMapping
coSpaceNameMapping
coSpaceUriMapping
coSpaceSecondaryUriMapping
Deskripsyon sa mga hiyasIADB nagrepresentar sa login ID sa user sa CMS. Tungod kay kini usa ka Microsoft Active Directory LDAP server, ang CMS JID nag-map sa sAMAccountName sa LDAP, nga mao ang Active Directory login ID sa user. Timan-i usab nga imong gikuha ang sAMAccountName ug idugang ang domain conf.pod6.cms.lab sa katapusan niini tungod kay kini ang login nga gamiton sa imong mga tiggamit sa pag-log in sa CMS.
nameMapping motakdo sa unsay anaa sa Active Directory displayName field ngadto sa CMS name field sa user.
coSpaceNameMapping nagmugna ug CMS space name base sa displayName field. Kini nga hiyas, kauban ang coSpaceUriMapping nga hiyas, mao ang gikinahanglan aron makahimo og luna alang sa matag user.
coSpaceUriMapping naghubit sa user nga bahin sa URI nga nalangkit sa personal nga luna sa user. Ang ubang mga domain mahimong ma-configure aron ma-dial sa kawanangan. Kung ang bahin sa gumagamit motakdo sa kini nga natad alang sa usa niini nga mga dominyo, ang tawag idirekta sa wanang sa kana nga tiggamit.
coSpaceSecondaryUriMapping naghubit sa ikaduhang URI aron makaabot sa wanang. Mahimo kining gamiton aron makadugang ug numeric nga alias para sa pagruta sa mga tawag ngadto sa gi-import nga luna sa user isip alternatibo sa alphanumeric URI nga gihubit sa coSpaceUriMapping parameter.
Ang LDAP server ug LDAP mapping gi-configure. Karon kinahanglan nimo nga isumpay sila pinaagi sa paghimo og LDAP nga tinubdan.
Paggamit sa URL aron ma-access cms01.example.com:445/api/v1/ldapSource paghimo ug LDAP Source object, nga nagtino sa mga parameter sama sa:
server
mapping
baseDn
filter
Karon nga kompleto na ang configuration sa LDAP, mahimo nimong ipahigayon ang manual synchronization operation.
Gihimo namo kini bisan sa Web interface sa matag server pinaagi sa pag-klik Pag-sync karon seksyon Active Directory
o pinaagi sa API nga adunay mando POST gamit ang URL aron ma-access cms01.example.com:445/api/v1/ldapSyncs
Mga komperensya sa Ad-Hoc
Unsa kini?Sa tradisyonal nga konsepto, ang usa ka komperensya kung ang duha ka mga partisipante nag-istoryahanay sa usag usa, ug usa sa mga partisipante (gamit ang usa ka aparato nga narehistro sa Unified CM) mopilit sa "Conference" nga buton, motawag sa laing tawo, ug pagkahuman makigsulti sa ikatulo nga partido. , gipugos pag-usab ang buton nga "Conference." aron maapil ang tanang partisipante sa tripartite nga komperensya.
Ang nagpalahi sa usa ka Ad-Hoc nga komperensya gikan sa usa ka naka-iskedyul nga komperensya sa usa ka CMS mao nga ang usa ka Ad-Hoc nga komperensya dili lamang usa ka tawag sa SIP sa usa ka CMS. Kung gi-klik sa tigpasiugda sa komperensya ang buton sa Komperensya sa ikaduhang higayon aron imbitahon ang tanan sa parehas nga miting, ang Unified CM kinahanglan maghimo usa ka tawag sa API sa CMS aron maghimo usa ka on-the-fly nga komperensya diin ang tanan nga mga tawag ibalhin. Kining tanan mahitabo nga wala mamatikdi sa mga partisipante.
Kini nagpasabot nga ang Unified CM kinahanglang i-configure ang mga kredensyal sa API ug WebAdmin address/port sa serbisyo ingon man ang SIP Trunk direkta ngadto sa CMS server aron ipadayon ang tawag.
Kung gikinahanglan, ang CUCM makahimo sa dinamikong paghimo og usa ka luna sa CMS aron ang matag tawag makaabot sa CMS ug mohaum sa umaabot nga tawag nga lagda nga gituyo alang sa mga luna.
Paghiusa sa CUCM gi-configure sa parehas nga paagi sama sa gihulagway sa artikulo sa sayo pa gawas nga sa Cisco UCM kinahanglan ka nga maghimo og tulo ka mga punoan alang sa CMS, tulo ka Conference Bridges, sa SIP Security Profile nagtino sa tulo ka Subject Names, Route Groups, Route Lists, Media Resourse Groups ug Media Resourse Group Lists, ug pagdugang og pipila ka mga lagda sa pagruta. ngadto sa Cisco Meeting Server.
Profile sa Seguridad sa SIP:
Mga punoan:
Ang matag punoan parehas ang hitsura:
Tulay sa Komperensya
Ang matag Conference Bridge managsama ang hitsura:
Grupo sa Ruta
Listahan sa Ruta
Grupo sa Kapanguhaan sa Media
Listahan sa Grupo sa Kapanguhaan sa Media
Mga Lagda sa Tawag
Dili sama sa mas advanced nga mga sistema sa pagdumala sa tawag sama sa Unified CM o Expressway, ang CMS nangita lang sa domain sa SIP Request-URI field para sa bag-ong mga tawag. Busa kung ang SIP INVITE para sa sip-on: [protektado sa email]Ang CMS ra ang nagpakabana sa domain.com. Gisunod sa CMS kini nga mga lagda aron mahibal-an kung asa i-ruta ang usa ka tawag:
1. Ang CMS unang mosulay sa pagpares sa SIP domain sa mga domain nga gi-configure sa umaabot nga tawag nga mga lagda. Kini nga mga tawag mahimong madala ngadto sa (βtargetβ) nga mga luna o espesipikong mga tiggamit, mga internal nga IVR, o direktang gisagol nga mga destinasyon sa Microsoft Lync/Skype for Business (S4B).
2. Kung walay tugma sa umaabot nga mga lagda sa tawag, ang CMS mosulay sa pagpares sa domain nga gi-configure sa call forwarding table. Kung gihimo ang usa ka panagsama, ang lagda mahimong dayag nga isalikway ang tawag o ipasa ang tawag. Niining panahona, ang CMS mahimong magsulat pag-usab sa domain, nga usahay mapuslanon sa pagtawag sa Lync domain. Mahimo ka usab nga mopili sa pagpasa sa paglabay, nga nagpasabut nga walaβy bisan usa sa mga natad ang dugang nga usbon, o mogamit usa ka internal nga plano sa dial sa CMS. Kung walay tugma sa mga lagda sa pagpasa sa tawag, ang default mao ang pagsalikway sa tawag. Hinumdomi nga sa CMS, bisan kung ang tawag "gipasa", ang media gigapos gihapon sa CMS, nga nagpasabot nga kini anaa sa signaling ug media traffic path.
Unya ang mga gipasa nga tawag lamang ang nailalom sa outgoing call rules. Kini nga mga setting nagtino sa mga destinasyon diin ang mga tawag gipadala, ang trunk type (bisan bag-o ba kini nga tawag sa Lync o usa ka standard nga tawag sa SIP), ug bisan unsang mga pagkakabig nga mahimo kung dili mapili ang pagbalhin sa lagda sa pagpasa sa tawag.
Ania ang aktuwal nga talaan kung unsa ang mahitabo sa panahon sa usa ka komperensya sa Ad-Hoc
Ang screenshot nagpakita niini nga dili maayo (wala ko kahibalo unsaon paghimo niini nga mas maayo), mao nga akong isulat ang log sama niini:
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
Ang Ad-Hoc nga komperensya mismo:
Mga Balaod sa umaabot nga Tawag Ang pag-configure sa mga parameter sa umaabot nga mga tawag gikinahanglan aron makadawat og tawag sa CMS. Sama sa imong nakita sa LDAP setup, ang tanang user gi-import gamit ang domain conf.pod6.cms.lab. Mao nga sa labing gamay, gusto nimo ang mga tawag sa kini nga domain aron ma-target ang mga wanang. Kinahanglan ka usab nga maghimo mga lagda alang sa tanan nga gituyo alang sa hingpit nga kwalipikado nga ngalan sa domain (ug tingali bisan ang IP address) sa matag usa sa mga server sa CMS. Ang among kontrol sa gawas nga tawag, Unified CM, mag-configure sa mga punoan sa SIP nga gipahinungod sa matag usa sa mga server sa CMS nga tinagsa. Depende kung ang destinasyon niini nga mga SIP trunks usa ka IP address o ang FQDN sa server ang magtino kung ang CMS kinahanglan nga i-configure aron makadawat mga tawag nga gitumong sa IP address niini o FQDN.
Ang domain nga adunay pinakataas nga prayoridad nga inbound nga lagda gigamit isip domain alang sa bisan unsang mga user space. Kung ang mga tiggamit mag-sync pinaagi sa LDAP, ang CMS awtomatik nga maghimo og mga luna, apan ang user nga bahin lamang sa URI (coSpaceUriMapping), pananglitan, user.space. Bahin domain Ang bug-os nga URI namugna base niini nga lagda. Sa tinuud, kung mag log in ka sa Web Bridge niining puntoha, imong makita nga ang Space URI walay domain. Pinaagi sa paghimo niini nga lagda isip pinakataas nga prayoridad, imong gitakda ang dominyo para sa mga namugna nga mga luna conf.example.com.
Mga Lagda sa Outgoing Call
Aron tugotan ang mga tiggamit sa paghimo sa mga outbound nga tawag sa Unified CM cluster, kinahanglan nimo nga i-configure ang mga outbound nga mga lagda. Ang domain sa mga endpoint nga narehistro sa Unified CM, sama sa Jabber, kay example.com. Ang mga tawag sa kini nga domain kinahanglan nga i-ruta ingon sagad nga tawag sa SIP sa Unified CM call processing nodes. Ang nag-unang server mao ang cucm-01.example.com, ug ang dugang nga server mao ang cucm-02.example.com.
Ang una nga lagda naghulagway sa pinakasimple nga pag-ruta sa mga tawag tali sa mga cluster server.
uma Lokal gikan sa domain responsable sa kung unsa ang ipakita sa SIP-URI sa nagtawag alang sa tawo nga gitawag pagkahuman sa simbolo nga "@". Kon atong biyaan nga walay sulod, unya human sa "@" nga simbolo adunay IP address sa CUCM diin kini nga tawag moagi. Kung atong itakda ang usa ka domain, unya pagkahuman sa simbolo nga "@" adunay tinuod nga domain. Kinahanglan kini aron makatawag og balik, kung dili, dili mahimo ang pagtawag balik pinaagi sa SIP-URI ngalan@ip-address.
Tawga kung gipaila Lokal gikan sa domain
Tawag kanus-a DILI gipakita Lokal gikan sa domain
Siguruha nga klaro nga ipiho ang Encrypted o Unencrypted alang sa mga outgoing nga tawag, tungod kay walaβy magamit sa Auto parameter.
recording
Ang mga komperensya sa video girekord sa Record server. Ang Recorder parehas ra sa Cisco Meeting Server. Ang Recorder wala magkinahanglan og pag-instalar sa bisan unsang lisensya. Ang mga lisensya sa pagrekord gikinahanglan alang sa mga server nga nagpadagan sa mga serbisyo sa CallBridge, i.e. usa ka lisensya sa Pagrekord gikinahanglan ug kinahanglan i-apply sa bahin sa CallBridge, ug dili sa server nga nagpadagan sa Recorder. Ang Recorder naglihok isip usa ka Extensible Messaging and Presence Protocol (XMPP) nga kliyente, mao nga ang XMPP server kinahanglang ma-enable sa server nga nag-host sa CallBridge.
Kay Adunay kami usa ka kumpol ug ang lisensya kinahanglan nga "iunat" sa tanan nga tulo nga mga server sa cluster. Dayon sa imong personal nga account sa mga lisensya nga among gi-associate (idugang) ang mga MAC address sa a-interface sa tanang CMS server nga gilakip sa cluster.
Ug kini ang litrato nga kinahanglan naa sa matag server sa cluster
Sa kinatibuk-an, adunay daghang mga senaryo sa pagbutang sa Recorder, apan magpabilin kami niini:
Sa wala pa i-set up ang Recorder, kinahanglan nimo nga mag-andam usa ka lugar diin ang mga komperensya sa video aktuwal nga irekord. Sa tinuod dinhi link, unsaon pag-set up sa tanan nga Pagrekord. Gipunting nako ang hinungdanon nga mga punto ug mga detalye:
1. Mas maayo nga i-slip ang sertipiko gikan sa unang server sa cluster.
2. Ang "Recorder dili magamit" nga sayup mahimong mahitabo tungod kay ang sayup nga sertipiko gipiho sa Recorder Trust.
3. Mahimong dili molihok ang pagsulat kung ang direktoryo sa NFS nga gitakda alang sa pagrekord dili ang direktoryo sa ugat.
Usahay adunay panginahanglan nga awtomatiko nga irekord ang usa ka komperensya sa usa ka piho nga tiggamit o wanang.
Alang niini, duha ka CallProfile ang gihimo:
Uban sa recording disabled
Ug uban sa awtomatikong pagrekord function
Sunod, among "ilakip" ang usa ka CallProfile nga adunay awtomatikong function sa pagrekord sa gusto nga wanang.
Sa CMS naestablisar pag-ayo nga kung ang usa ka CallProfile klaro nga gihigot sa bisan unsang wanang o wanang, nan kini nga CallProfile molihok lamang nga may kalabotan sa mga piho nga mga wanang. Ug kung ang CallProfile dili gigapos sa bisan unsang wanang, nan pinaagi sa default kini magamit sa mga wanang diin walaβy CallProfile nga klaro nga gigapos.
Sa sunod sulayan nako nga ihulagway kung giunsa ang pag-access sa CMS sa gawas sa internal nga network sa organisasyon.