Cisco Server Civîna 2.5.2. Bi fonksiyona tomarkirina konferansa vîdyoyê di moda Scalable û Resilient de kom bibin

Di vê hejmarê de ez ê hin tevliheviyên sazkirina serverek CMS-ê di moda komê ya têkçûyî de nîşan bidim û rave bikim.


TheoryBi gelemperî, sê celeb sazkirina servera CMS hene:

• Yekane Têkel(Yek hevgirtî), yanî. ev yek serverek e ku hemî karûbarên pêwîst li ser dimeşînin. Di pir rewşan de, ev celeb verastkirin tenê ji bo gihîştina xerîdar a hundurîn û di hawîrdorên piçûktir de maqûl e ku hûrgelî û zêdebûniya serverek yek pirsgirêkek krîtîk ne, an jî di rewşên ku CMS tenê hin fonksiyonan pêk tîne, wek ad hoc. konferansên li ser Cisco UCM.

  Plana xebatê ya nêzîk:
  

• Single Split(Single Split) bi lêzêdekirina serverek veqetandî ji bo gihîştina derveyî, celebê bicîhkirina berê dirêj dike. Di bicihkirinên mîras de, ev tê vê wateyê ku serverek CMS-ê li beşa torê ya bêçekdarkirî (DMZ) ku xerîdarên derveyî dikarin bigihîjin wê, û serverek CMS-ê di bingeha torê de ku xerîdarên hundurîn dikarin xwe bigihînin CMS-ê, bicîh bikin. Ev modela birêkûpêk a taybetî naha ji hêla tîpa ku jê re tê gotin tê veguheztin Single Edge, ku ji pêşkêşkeran pêk tê Cisco Expressway, yên ku gelek ji heman kapasîteyên dorpêçkirina Firewallê hene an dê hebin, ji ber vê yekê xerîdar ne hewce ne ku serverek CMS-ya serhêl lê zêde bikin.

  Plana xebatê ya nêzîk:
  

• Scalable û Resilient(Scalable and Fault Tolerant) Ev celeb ji bo her pêkhateyê zêdebûnê vedihewîne, dihêle ku pergal bi hewcedariyên we heya kapasîteya xwe ya herî zêde mezin bibe dema ku di rewşek têkçûyî de zêdebûnê peyda dike. Di heman demê de ew têgeha Single Edge bikar tîne da ku gihîştina derveyî ewle peyda bike. Ev celeb e ku em ê di vê beşê de lê binêrin. Ger em fam bikin ka meriv çawa vê celebê komê bi cih dike, em ê ne tenê celebên din ên bicîhkirinê fam bikin, lê em ê di heman demê de fam bikin ka meriv çawa komikên serverên CMS-ê biafirîne da ku mezinbûna potansiyel a daxwaziyê bicîh bîne.

Berî ku hûn berbi belavkirinê ve biçin, hûn hewce ne ku hin tiştên bingehîn fam bikin, bi navê

Parçeyên sereke yên nermalava CMS:

• Database: Destûrê dide we ku hûn hin veavakirinan, wek plana dialê, cîhên bikarhêner, û bikarhêner bixwe bi hev re bikin. Tenê ji bo hebûna bilind (yek master) kombûnê piştgirî dike.
• Pira bang bikin: Xizmetek ji bo konfêransên deng û vîdyoyê ku kontrola tam li ser rêvebirin û pêvajokirina bang û pêvajoyên multimedia peyda dike. Ji bo hebûna bilind û mezinbûnê kombûnê piştgirî dike.
• Pêşkêşkara XMPP: Berpirsiyar ji qeydkirin û rastkirina xerîdaran ku Serlêdana Civîna Cisco û/an WebRTC bikar tînin(danûstendina rast-ê, an tenê di gerokê de), û her weha îşaretkirina navberê. Tenê ji bo hebûna bilind dikare were kom kirin.
• Pira Webê: Gihîştina xerîdar ji WebRTC re peyda dike.
• Loadbalancer: Ji bo Serlêdanên Civîna Cisco-yê di moda Veqetandinê de yek xala girêdanê peyda dike. Ji bo girêdanên hatina navber û porta derveyî guhdarî dike. Bi heman rengî, balansa barkirinê girêdanên TLS-ê yên ji servera XMPP qebûl dike, bi navgîniya ku ew dikare girêdanên TCP-ê ji xerîdarên derveyî veguhezîne.
  Di senaryoya me de ew ê ne hewce be.
• server TURN: Teknolojiya dorpêçkirina Firewall ku destûrê dide peyda dike
  CMS-a me li pişt Firewall an NAT-ê bixin da ku xerîdarên derveyî bi karanîna Cisco Meeting App an cîhazên SIP-ê ve girêdin. Di senaryoya me de ew ê ne hewce be.
• Web Admin: Navbera îdarî û gihîştina API-ê, di nav de ji bo konferansên CM-ya yekbûyî ya taybetî.

Modes Configuration

Berevajî piraniya hilberên Cisco yên din, Cisco Meeting Server sê rêbazên veavakirinê piştgirî dike da ku her cûre bicîhkirinê bicîh bîne.

• Rêza fermanê (CLI): Navbera rêza fermanê ku ji bo mîhengên destpêkê û karên sertîfîkayê wekî MMP tê zanîn.
• Rêveberê Webê: Di serî de ji bo veavakirinên têkildar ên CallBridge, nemaze dema ku serverek ne-klusterkirî saz bikin.
• REST API: Ji bo karên mîhengê yên herî tevlihev û peywirên girêdayî databasa komkirî tê bikar anîn.

Ji bilî yên jorîn, protokol tê bikaranîn SFTP ji bo veguheztina pelan - bi gelemperî destûrname, sertîfîka, an têketin - ber û ji servera CMS.

Di rêberên bicîhkirinê de ji Cisco-yê bi spî û îngilîzî tê nivîsandin ku pêdivî ye ku kom were bicîh kirin. herî kêm sê pêşkêşker (girêdan) di çarçoveya databasan de. Bo Tenê bi hejmareke bêkêmasî ya girêkan dê mekanîzmaya ji bo hilbijartina Master Database ya nû bixebite, û bi gelemperî Database Master bi piraniya databasa servera CMS re têkiliyek heye.

Û wekî ku pratîk nîşan dide, du server (node) bi rastî ne bes in. Mekanîzmaya hilbijartinê dema ku Master ji nû ve were destpêkirin dixebite, servera Slave tenê piştî ku servera ji nû ve hatî rakirin dibe Master. Lêbelê, heke di komek ji du serveran de servera Master ji nişka ve derkeve, wê hingê servera Slave nabe Master, û heke Slave derkeve, wê hingê servera Master a mayî dê bibe Slave.

Lê di çarçoweya XMPP-ê de, bi rastî pêdivî ye ku meriv komek sê serveran bicivîne, ji ber ku heke, wek nimûne, hûn karûbarê XMPP-ê li ser yek ji serverên ku tê de XMMP di statûya Rêber de ye neçalak bikin, wê hingê li ser servera mayî XMPP dê di statûya Follower de bimîne û girêdanên CallBridge bi XMPP-ê re dê têk biçin, ji ber ku CallBridge bi statûya Rêber bi taybetî bi XMPP-ê ve girêdide. Û ev krîtîk e, ji ber ku ... yek bangek jî derbas nabe.

Di heman demê de di heman rêberên bicîhkirinê de komek bi yek serverek XMPP ve tê destnîşan kirin.

Û girtina li jor, eşkere dibe ku çima: ew dixebite ji ber ku ew di moda failover de ye.

Di doza me de, servera XMPP dê li ser her sê girêkan hebe.

Tê texmîn kirin ku her sê serverên me ne.

tomarên DNS

Berî ku hûn dest bi sazkirina pêşkêşkeran bikin, hûn hewce ne ku tomarên DNS-ê biafirînin А и SRV cureyên:

Ji kerema xwe not bikin ku di tomarên me yên DNS de du domain hene example.com û Conf.example.com. Example.com domainek e ku hemî aboneyên Rêvebirê Ragihandina Yekgirtî ya Cisco dikarin ji bo URI-yên xwe bikar bînin, ku bi îhtîmalek mezin di binesaziya we de heye an jî dibe ku hebe. An example.com heman domainê ku bikarhêner ji bo navnîşanên e-nameya xwe bikar tînin li hev dike. An jî muwekîlê Jabber li ser laptopa we dibe ku URI hebe [email parastî]. Domain Conf.example.com domaina ku dê ji bo bikarhênerên Cisco Meeting Server were mîheng kirin e. The domain of Cisco Meeting Server dê bibe Conf.example.com, ji ber vê yekê ji bo heman bikarhênerê Jabber, bikarhêner@ URI hewce dike ku were bikar anîn da ku têkeve Pêşkêşkara Civînê ya CiscoConf.example.com.

Veavakirina bingehîn

Hemî mîhengên ku li jêr têne diyar kirin li ser serverek têne xuyang kirin, lê ew hewce ne ku li ser her serverek di komê de bêne kirin.

QoS

Ji ber ku CMS diafirîne real-time seyrûsefera ku ji derengmayîn û windabûna pakêtê re hesas e, di pir rewşan de tê pêşniyar kirin ku meriv kalîteya karûbarê (QoS) mîheng bike. Ji bo ku bigihîje vê yekê, CMS bi Kodên Karûbarên Cûdakirî (DSCP) yên ku ew diafirîne, pakêtên nîşankirinê piştgirî dike. Her çend pêşanîkirina seyrûsefera DSCP-ê girêdayî ye ka seyrûsefer çawa ji hêla hêmanên torê yên binesaziya we ve tê hilanîn, di doza me de em ê CMS-ya xwe bi pêşanî DSCP-ya tîpîk li ser bingeha pratîkên çêtirîn QoS mîheng bikin.

Li ser her serverek em ê van fermanan têkevin

dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1A

Bi vî rengî, hemî seyrûsefera vîdyoyê AF41 (DSCP 0x22) hate nîşankirin, hemî seyrûsefera dengî bi EF (DSCP 0x2E) hate nîşankirin, celebên din ên seyrûsefera derengiya kêm ên wekî SIP û XMPP AF31 (DSCP 0x1A) bikar tînin.

Em kontrol dikin:

NTP

Protokola Demjimêra Torê (NTP) ne tenê ji bo peydakirina demjimêrên rast ên bang û konferansan, lê di heman demê de ji bo verastkirina sertîfîkayan jî girîng e.

Bi fermanek mîna serverên NTP-ê li binesaziya xwe zêde bikin

ntp server add <server>

Di doza me de, du serverên weha hene, ji ber vê yekê dê du tîm hebin.
Em kontrol dikin:

Û ji bo servera me devera demjimêr destnîşan bikin

DNS

Em bi fermanek mîna serverên DNS-ê li CMS-ê zêde dikin:

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

Di doza me de, du serverên weha hene, ji ber vê yekê dê du tîm hebin.
Em kontrol dikin:

Veavakirina Navrûya Torê

Em pêvekê bi fermanek mîna mîheng dikin:

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

Em kontrol dikin:

Navê serverê (Navê mêvandar)

Em navê serverê bi fermanek wekî:

hostname <name>

Û em ji nû ve dest pê bikin.


Ev veavakirina bingehîn temam dike.

Taybetmendî

TheoryCisco Meeting Server pêwendiya şîfrekirî di navbera pêkhateyên cihêreng de hewce dike, û di encamê de, sertîfîkayên X.509 ji bo hemî bicîhkirina CMS-ê hewce ne. Ew alîkarî dikin ku karûbar / pêşkêşker ji hêla serverên / karûbarên din ve tê bawer kirin.

Her karûbar belgeyek hewce dike, lê çêkirina sertîfîkayên cihêreng ji bo her karûbar dikare bibe sedema tevlihevî û tevliheviya nehewce. Xwezî, em dikarin cotek mifteya giştî-taybet a sertîfîkayê biafirînin û dûv re wan di gelek karûbaran de ji nû ve bikar bînin. Di doza me de, heman sertîfîka dê ji bo Call Bridge, XMPP Server, Web Bridge û Web Admin were bikar anîn. Bi vî rengî, hûn hewce ne ku ji bo her serverek di komê de cotek bişkojkên sertîfîkayên giştî û taybet biafirînin.

Lêbelê, komkirina databasê hin daxwazên sertîfîkayên taybetî hene û ji ber vê yekê sertîfîkayên xwe yên ku ji yên karûbarên din cûda ne hewce dike. CMS sertîfîkaya serverê bikar tîne, ku dişibihe sertîfîkayên ku ji hêla serverên din ve têne bikar anîn, lê di heman demê de sertîfîkayek xerîdar jî heye ku ji bo girêdanên databasê tê bikar anîn. Sertîfîkayên databasê hem ji bo rastkirin û hem jî ji bo şîfrekirinê têne bikar anîn. Li şûna ku ji bo xerîdar navek û şîfreyek peyda bike da ku bi databasê ve girêbide, ew sertîfîkayek xerîdar ku ji hêla serverê ve pêbawer e pêşkêşî dike. Her serverek di koma databasê de dê heman cotê mifteya giştî û taybet bikar bîne. Ev dihêle ku hemî pêşkêşkerên di komê de daneyan bi vî rengî şîfre bikin ku ew tenê ji hêla pêşkêşkerên din ve ku di heman demê de heman cotê mifteyê jî parve dikin ve were deşîfrekirin.

Ji bo ku zêdebûn kar bike, komikên databasê divê herî kêm ji 3 pêşkêşkeran pêk werin, lê ji 5-an zêdetir nebin, bi demek gerîdeya herî zêde 200 ms di navbera her endamên komê de. Ev sînor ji komkirina Call Bridge re sînordartir e, ji ber vê yekê ew pir caran faktora sînordar e di belavkirinên erdnîgarî de belavkirî.

Rola databasê ji bo CMS-ê çend hewcedariyên bêhempa hene. Berevajî rolên din, ew sertîfîkayek xerîdar û serverê hewce dike, ku sertîfîkaya xerîdar xwedan qada CN-ya taybetî ye ku ji serverê re tê pêşkêş kirin.

CMS databasek postgres bi yek master û çend kopiyên bi tevahî wekhev bikar tîne. Di carekê de tenê databasek bingehîn heye ("pêşkêşkera databasê"). Endamên mayî yên komê replicas an "mişteriyên databasê" ne.

Komek databasê sertîfîkayek serverek taybetî û sertîfîkayek xerîdar hewce dike. Pêdivî ye ku ew bi sertîfîkayan, bi gelemperî rayedarek sertîfîkaya taybet a hundurîn, bêne îmze kirin. Ji ber ku her endamek komê databasê dikare bibe serwer, pêdivî ye ku cotên sertîfîkayên servera databasê û xerîdar (bi kilîtên giştî û taybet vedihewîne) li hemî pêşkêşkeran were kopî kirin da ku ew karibin nasnameya xerîdar an servera databasê bistînin. Wekî din, divê sertîfîkaya root CA were barkirin da ku pê ewle bibe ku sertîfîkayên xerîdar û serverê dikarin werin verast kirin.

Ji ber vê yekê, em daxwaznameyek ji bo sertîfîkayekê diafirînin ku dê ji hêla hemî karûbarên serverê ve ji bilî databasê were bikar anîn (ji bo vê yekê daxwazek cûda hebe) bi fermanek mîna:

pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com

Di CN de em navê giştî yê serverên xwe dinivîsin. Mînakî, heke navên mêvandarên serverên me server01, server02, server03, paşê CN dê bibe server.example.com

Em heman tiştî li ser du pêşkêşkerên mayî dikin bi ferqa ku ferman dê "navên mêvandar" yên têkildar hebin.

Em du daxwazan ji bo sertîfîkayên ku dê ji hêla karûbarê databasê ve bi fermanên wekî:

pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com

pki csr dbclusterclient CN:postgres

ko dbclusterserver и dbclusterclient navên daxwazên me û sertîfîkayên pêşerojê, navê mêvandar1(2)(3) navên pêşkêşkerên têkildar.

Em vê prosedurê tenê li ser serverek (!) pêk tînin, û em ê sertîfîkayan û pelên .key yên têkildar li serverên din bar bikin.

Di AD CS de moda sertîfîkaya xerîdar çalak bike

Di heman demê de hûn hewce ne ku sertîfîkayên ji bo her serverê di yek pelê de bikin yek.Li *NIX:

cat server01.cer server02.cer server03.cer > server.cer

Li ser Windows/DOS:

copy server01.cer + server02.cer + server03.cer  server.cer

Û li her serverê barkirin:
1. Sertîfîkaya serverê "Kesî".
2. Sertîfîkaya Root (ligel yên navîn, heke hebe).
3. Sertîfîkayên ji bo databasê ("server" û "muwekîlê") û pelên bi dirêjkirina .key, ku dema ku daxwazek ji bo sertîfîkayên databasa "server" û "muwekîlê" hatî çêkirin hatine çêkirin. Divê ev pel li ser hemî pêşkêşkeran yek bin.
4. Dosya her sê sertîfîkayên "ferdî".

Wekî encamek, divê hûn li ser her serverê tiştek mîna vê wêneya pelê bistînin.

Cluster Database

Naha ku we hemî sertîfîkayên ku li serverên CMS-ê hatine barkirin hene, hûn dikarin komkirina databasê di navbera sê girêkan de mîheng bikin û çalak bikin. Gava yekem ev e ku meriv serverek wekî girêka sereke ya koma databasê hilbijêrin û wê bi tevahî mîheng bikin.

Database Master

Gava yekem di sazkirina dubarekirina databasê de ev e ku sertîfîkayên ku dê ji bo databasê werin bikar anîn diyar bikin. Ev bi karanîna fermanek mîna pêk tê:

database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>

Naha em ji CMS-ê re bibêjin ka kîjan navrû ji bo komkirina databasê bi fermanê re bikar bîne:

database cluster localnode a

Dûv re em databasa komê li ser servera sereke bi fermanê dest pê dikin:

database cluster initialize

Nodes Database Client

Em heman pêvajoyê dikin, tenê li şûna fermanê komika databasê destpêk dike fermanek wekî binivîse:

database cluster join <ip address existing master>

ku navnîşana ip-ê navnîşana ip-ya sereke ya servera CMS ya ku komê li ser hatî destpêkirin, tenê Master.

Em kontrol dikin ka koma databasa me li ser hemî serveran bi fermanê çawa dixebite:

database cluster status

Em heman tiştî li ser servera sêyemîn a mayî dikin.

Wekî encamek, derdikeve holê ku servera me ya yekem Master e, yên mayî Xulam in.

Xizmeta Rêveberiya Webê

Karûbarê rêvebirê malperê çalak bike:

webadmin listen a 445

Port 445 hate hilbijartin ji ber ku porta 443 ji bo gihîştina bikarhêner bi xerîdarek malperê tê bikar anîn

Em karûbarê Rêvebirê Webê bi pelên sertîfîkayê re bi fermanek mîna mîheng dikin:

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

Û bi fermanê Rêvebirê Webê çalak bikin:

webadmin enable

Ger her tişt baş be, em ê rêzikên SERKEFTÎ bistînin ku destnîşan dikin ku Rêvebirê Webê ji bo torê û sertîfîkayê rast hatî mîheng kirin. Em fonksiyona karûbarê bi karanîna gerokek webê kontrol dikin û navnîşana rêveberê malperê têkevin, mînakî: cms.example.com: 445

Banga Bridge Cluster

Call Bridge tenê karûbar e ku di her bicîhkirina CMS de heye. Call Bridge mekanîzmaya sereke ya konferansê ye. Di heman demê de ew navgînek SIP-ê peyda dike da ku bang ji hêla wê ve an jî ji hêla wê ve were rêve kirin, mînakî, Cisco Unified CM.

Fermanên ku li jêr têne diyar kirin divê li ser her serverek bi sertîfîkayên guncan werin bicîh kirin.
Ji ber vê yekê

Em sertîfîkayan bi karûbarê Call Bridge re bi fermanek mîna:

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

Em karûbarên CallBridge bi navgîniya ku em hewce ne bi fermanê ve girêdidin:

callbridge listen a

Û karûbarê bi fermanê ji nû ve bidin destpêkirin:

callbridge restart

Naha ku me Call Bridges mîheng kirine, em dikarin komkirina Call Bridge mîheng bikin. Komkirina Call Bridge ji berhevkirina databas an XMPP cûda ye. Call Bridge Cluster dikare ji 2 heta 8 girêkan bê sînor piştgirî bike. Ew ne tenê zêdebûnê, lê di heman demê de hevsengiya barkirinê jî peyda dike da ku konfêrans bi karanîna belavkirina banga aqilmend bi rengek çalak li ser serverên Call Bridge bêne belav kirin. CMS xwedan taybetmendiyên din, komên Call Bridge û taybetmendiyên têkildar hene ku dikarin ji bo birêvebirina bêtir bikar bînin.

Komkirina pira bangê di serî de bi navgîniya rêveberê webê ve hatî mîheng kirin
Pêvajoya ku li jêr hatî destnîşan kirin divê li ser her serverek di komê de were meşandin.
Û vî awayî,

1. Bi tevnê biçin Veavakirin > Cluster.
2. Di Banga nasnameya Bridge Wekî navek bêhempa, bi navê serverê re têkildar bi callbridge[01,02,03] binivîse. Ev nav keyfî ne, lê divê ji bo vê komê yekta bin. Ew di xwezayê de diyarker in ji ber ku ew destnîşan dikin ku ew nasnameyên serverê ne [01,02,03].
3.B Clustered Call Bridges URL-yên rêveberê malperê yên serverên me yên di komê de binivîsin, cms[01,02,03].example.com:445, di qada Navnîşan de. Bawer bikin ku portê diyar bikin. Hûn dikarin domaina SIP ya Peer link vala bihêlin.
4. Sertîfîkayek li pêbaweriya CallBridge ya her serverek zêde bikin, pelê wê hemî sertîfîkayên pêşkêşkerên me dihewîne, ku me di destpêkê de di vê pelê de kir yek, bi fermanek mîna:

callbridge trust cluster <trusted cluster certificate bundle>

Û karûbarê bi fermanê ji nû ve bidin destpêkirin:

callbridge restart

Wekî encamek, li ser her serverê divê hûn vê wêneyê bistînin:

XMPP Cluster

Karûbarê XMPP di CMS-ê de ji bo birêvebirina hemî tomarkirin û pejirandina ji bo Serlêdanên Civînê yên Cisco (CMA) tê bikar anîn, di nav de muwekîlê webê CMA WebRTC. Call Bridge bixwe jî ji bo mebestên erêkirinê wekî xerîdarek XMPP tevdigere û ji ber vê yekê divê wekî xerîdarên din were mîheng kirin. Tolerasyona xeletiya XMPP taybetmendiyek e ku ji guhertoya 2.1-ê ve di hawîrdorên hilberînê de tê piştgirî kirin

Fermanên ku li jêr têne diyar kirin divê li ser her serverek bi sertîfîkayên guncan werin bicîh kirin.
Ji ber vê yekê

Em sertîfîkayan bi karûbarê XMPP re bi fermanek mîna:

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

Dûv re pêwendiya guhdarîkirinê bi fermanê diyar bikin:

xmpp listen a

Karûbarê XMPP domainek yekta hewce dike. Ev têketin ji bo bikarhêneran e. Bi gotinek din, gava ku bikarhênerek hewl dide ku bi karanîna sepana CMA (an jî bi navgîniya xerîdar WebRTC) têkeve, ew têkevin userID@logindomain. Di doza me de ew ê userid@ beConf.example.com. Çima ew ne tenê nimûne.com e? Di danasîna xweya taybetî de, me domaina xweya CM-ya Yekgirtî hilbijart ku bikarhênerên Jabber dê di Unified CM-ê de wekî nimûne.com bikar bînin, ji ber vê yekê me ji bikarhênerên CMS-ê re domanek cûda hewce kir ku bangên ji CMS-ê û ji CMS-ê bi navgînên SIP-ê re rêve bibin.

Bi karanîna fermanek mîna domainek XMPP saz bikin:

xmpp domain <domain>

Û bi fermanê karûbarê XMPP çalak bikin:

xmpp enable

Di karûbarê XMPP de, divê hûn ji bo her Pira Bangê pêbaweriyê biafirînin ku dê dema ku bi karûbarê XMPP-ê re qeyd kirin were bikar anîn. Van navan keyfî ne (û bi navên yekta yên ku we ji bo komkirina pira bangê mîheng kirine ve girêdayî ne). Pêdivî ye ku hûn sê pirên bangê li ser serverek XMPP zêde bikin û dûv re wan pêbaweriyan li ser serverên din ên XMPP yên di komê de binivîsin ji ber ku ev veavakirin di databasa komê de cîh nagire. Dûv re em ê her Pira Bangê mîheng bikin da ku vê nav û veşartî bikar bînin da ku bi karûbarê XMPP re qeyd bikin.

Naha divê em karûbarê XMPP-ê li ser servera yekem bi sê Call Bridges callbridge01, callbridge02 û callbridge03 mîheng bikin. Her hesab dê şîfreyên rasthatî werin veqetandin. Dê paşê ew li ser serverên din ên Call Bridge werin tomar kirin ku têkevin vê servera XMPP. Fermanên jêrîn binivîse:

xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03

Wekî encamek, em kontrol dikin ka bi fermanê çi bûye:

xmpp callbridge list

Pêdivî ye ku tam heman wêne li ser serverên mayî piştî gavên ku li jêr hatine destnîşan kirin xuya bibe.

Dûv re, em tam heman mîhengan li ser du serverên mayî, tenê bi fermanan lê zêde dikin

xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03

Em Secret pir bi baldarî lê zêde dikin da ku, mînakî, tê de cîhên zêde nebin.


Wekî encamek, divê her server heman wêneyê hebe:

Dûv re, li ser hemî serverên di komê de, em bi pêbaweriya pelê ku her sê sertîfîkayan vedihewîne, ku berê bi fermanek weha hatî afirandin destnîşan dikin:

xmpp cluster trust <trust bundle>

Em moda komê ya xmpp li ser hemî pêşkêşkerên komê bi fermanê çalak dikin:

xmpp cluster enable

Li ser servera yekem a komê, em bi fermanê dest bi afirandina komek xmpp dikin:

xmpp cluster initialize

Li ser pêşkêşkerên din, bi fermanek mîna komek li xmpp zêde bikin:

xmpp cluster join <ip address head xmpp server>

Em li ser her serverek bi fermanan serkeftina afirandina komek XMPP li ser her serverê kontrol dikin:

xmpp status
xmpp cluster status

Pêşkêşkara yekem:

Pêşkêşkara duyemîn:

Pêşkêşkara sêyemîn:

Girêdana Call Bridge bi XMPP

Naha ku komika XMPP dimeşe, hûn hewce ne ku karûbarên Call Bridge mîheng bikin da ku bi koma XMPP-ê ve girêbidin. Ev veavakirin bi riya rêveberê webê tê kirin.

Li ser her serverê, biçin Veavakirin> Giştî û li qadê Navê yekane Call Bridge navên yekta yên ku bi servera Call Bridge re têkildar in binivîsin callbridge[01,02,03]... Li meydanê Domain conf.example.ru û şîfreyên têkildar, hûn dikarin wan bişopînin
li ser her serverek di komê de bi fermanê:

xmpp callbridge list

Qada "Server" vala bihêlin Callbridge dê ji bo lêgerînek DNS SRV pêk bîne _xmpp-component._tcp.conf.example.comda ku serverek XMPP ya berdest bibînin. Dibe ku navnîşanên IP-yê ji bo girêdana pira bangê bi XMPP-ê re li ser her serverek cûda bibin, ew bi kîjan nirxan ve li daxwaza tomarê vegere ve girêdayî ye. _xmpp-component._tcp.conf.example.com callbridge, ku di encamê de bi mîhengên pêşîn ên ji bo tomarek DNS-ya diyarkirî ve girêdayî ye.

Dûv re, biçin Rewş > Giştî da ku verast bikin ka karûbarê Call Bride bi serfirazî bi karûbarê XMPP ve girêdayî ye.

Pira Webê

Li ser her serverek di komê de, bi fermanê karûbarê Web Bridge çalak bikin:

webbridge listen a:443

Em karûbarê Web Bridge bi pelên sertîfîkayê bi fermanek mîna mîheng dikin:

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

Web Bridge HTTPS piştgirî dike. Ger ji bo karanîna "http-beralîkirin" were mîheng kirin dê HTTP beralî HTTPS bike.
Ji bo çalakkirina beralîkirina HTTP, emrê jêrîn bikar bînin:

webbridge http-redirect enable

Ji bo ku Call Bridge zanibe ku Web Bridge dikare pêwendiyên ji Call Bridge bawer bike, emrê bikar bînin:

webbridge trust <certfile>

ku ev pelek e ku her sê sertîfîkayên ji her serverek di komê de vedihewîne.

Divê ev wêne li ser her serverek di komê de be.


Naha pêdivî ye ku em bikarhênerek bi rola "appadmin" biafirînin, ji me re lazim e ku em bikarin koma xwe (!) mîheng bikin, û ne her serverek di komê de ji hev cuda, bi vî rengî dê mîheng li ser her serverek wekhev bêne sepandin tevî ku rastiya ku ew ê carekê bêne çêkirin.


Ji bo sazkirina bêtir em ê bikar bînin Postevan.

Ji bo destûrnameyê, di beşa Destûrnameyê de Bingehîn hilbijêrin

Ji bo ku emrên rast ji servera CMS re bişînin, hûn hewce ne ku kodkirina pêwîst saz bikin

Em bi fermanê Webbridge diyar dikin KOZ bi parametre url û wateya cms.example.com



Di webbridge bixwe de, em pîvanên pêwîst destnîşan dikin: gihîştina mêvan, gihîştina parastî, hwd.

Banga Komên Bridge

Ji hêla xwerû, CMS her gav çavkaniyên konferansê yên ku jê re peyda dibin karanîna herî bikêr nake.

Mînakî, ji bo civînek bi sê beşdaran re, dibe ku her beşdarek li sê Pirên Bangê yên cûda biqede. Ji bo ku van her sê beşdaran bi hev re têkilî daynin, Call Bridges dê bixweber di heman Cihê de di navbera hemî pêşkêşker û xerîdaran de pêwendiyan saz bike, da ku ew hemî xuya bike ku hemî xerîdar li ser heman serverê ne. Mixabin, xirabiya vê yekê ev e ku konferansek 3-kesî dê naha 9 portên medyayê bixwe. Ev eşkere bikaranîna bêkêmasî ya çavkaniyan e. Wekî din, dema ku Pira Bangek bi rastî zêde tê barkirin, mekanîzmaya xwerû ev e ku meriv bangan bidomîne û karûbarê kalîteyê kêm ji hemî aboneyên wê Pira Bangê re peyda bike.

Van pirsgirêkan bi karanîna taybetmendiya Koma Call Bridge têne çareser kirin. Ev taybetmendî di guhertoya 2.1-ê ya nermalava Cisco Meeting Server-ê de hate destnîşan kirin û ji bo piştgirîkirina hevsengiya barkirinê hem ji bo bangên Cisco Meeting App (CMA) yên hundurîn û hem jî ji derve ve, tevî beşdarên WebRTC, hate dirêj kirin.

Ji bo çareserkirina pirsgirêka ji nû ve girêdanê, sê sînorên barkirinê yên mîhengkirî ji bo her Pira Bangê hatine destnîşan kirin:

LoadLimit - ev ji bo Pira Bangek taybetî barkirina jimareya herî zêde ye. Her platformek sînorek barkirinê ya pêşniyarkirî heye, wek mînak 96000 ji bo CMS1000 û 1.25 GHz per vCPU ji bo makîneya virtual. Bangên cihêreng li gorî çareserî û rêjeya çarçoweya beşdaran hejmarek çavkanî dixwe.
NewConferenceLoadLimitBasisPoints (bixweber 50% loadLimit) - sînorê barkirina serverê destnîşan dike, piştî ku konferansên nû têne red kirin.
ExistingConferenceLoadLimitBasisPoints (jixweber 80% ji loadLimit) - nirxa barkirina serverê piştî ku beşdarên ku beşdarî konferansek heyî dibin dê bêne red kirin.

Dema ku ev taybetmendî ji bo belavkirina bangê û hevsengkirina barkirinê hate çêkirin, komên din ên wekî Pêşkêşkerên TURN, Pêşkêşkerên Pira Webê û Tomarkeran jî dikarin ji Komên Call Bridge re werin veqetandin da ku ew jî ji bo karanîna çêtirîn bi rêkûpêk bêne kom kirin. Ger yek ji van tiştan ji komek bangê re neyê veqetandin, tê texmîn kirin ku ew bêyî pêşanîyek taybetî ji hemî serveran re peyda dibin.

Van parameteran li vir têne mîheng kirin: cms.example.com: 445 / api / v1 / sîstem / veavakirin / kom

Dûv re, em ji her callbridge-ê re destnîşan dikin ku ew ji kîjan koma callbridge e:

Callbridge yekem

Pira banga duyemîn

Pira banga sêyemîn


Bi vî rengî, me koma Call Brdige mîheng kir da ku çavkaniyên komê Pêşkêşkara Civînê ya Cisco bi bandortir bikar bîne.

Bikarhêneran ji Active Directory derdixin

Karûbarê Rêvebirê Webê xwedan beşek veavakirina LDAP-ê ye, lê ew vebijarkên mîhengê tevlihev peyda nake, û agahdarî di databasa komê de nayê hilanîn, ji ber vê yekê pêdivî ye ku veavakirin, bi destan li ser her serverek bi navgîniya navgîniya Webê, an bi riya API-ê, û ji bo ku em "sê caran "Rabin" em ê dîsa jî daneyan bi navgîniya API-ê saz bikin.

Ji bo gihîştina URL-ê bikar bînin cms01.example.com:445/api/v1/ldapServers objeyek Pêşkêşkara LDAP diafirîne, pîvanên wekî:

• Server IP
• hejmara port
• Navê bikarhêner
• şîfreya
• bicî

Ewle - li gorî portê rast an xelet hilbijêrin, 389 - ne ewledar, 636 - parastî.


Nexşeya pîvanên çavkaniya LDAP-ê li ser taybetmendiyan di Servera Civîna Cisco de.
Nexşeya LDAP-ê taybetmendiyên di pelrêça LDAP-ê de bi taybetmendiyên di CMS-ê de nexşe dike. Taybetmendiyên rastîn:

• jidMapping
• nameMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Danasîna taybetmendiyanJID Nasnameya têketinê ya bikarhêner di CMS-ê de temsîl dike. Ji ber ku ev serverek Microsoft Active Directory LDAP-ê ye, CMS JID nexşeya sAMAccountName di LDAP-ê de, ku bi eslê xwe nasnava têketina Active Directory-ya bikarhêner e. Her weha bala xwe bidin ku hûn sAMAccountName digirin û domainê conf.pod6.cms.lab li dawiya wê zêde dikin ji ber ku ev têketin e ku bikarhênerên we dê bikar bînin da ku têkevin CMS-ê.

nameMapping Tişta ku di qada DisplayName ya Navnîşana Active Directory de heye bi qada navê CMS ya bikarhêner re li hev dike.

coSpaceNameMapping li ser bingeha qada displayName navek cîhê CMS diafirîne. Ev taybetmendî, digel taybetmendiya coSpaceUriMapping, ji ​​bo afirandina cîhek ji bo her bikarhênerek pêdivî ye.

coSpaceUriMapping beşa bikarhêner a URI ya ku bi cîhê kesane yê bikarhêner ve girêdayî ye diyar dike. Hin domain dikarin werin mîheng kirin ku li cîhê werin veguheztin. Ger beşa bikarhêner ji bo yek ji van domanan vê qadê li hev bike, dê bang li cîhê wî bikarhênerî were rêve kirin.

coSpaceSecondaryUriMapping URI-ya duyemîn diyar dike ku bigihîje cîhê. Ev dikare were bikar anîn da ku navekî jimareyî ji bo rêvekirina bangan li cîhê bikarhênerê îthalkirî wekî alternatîfek ji URI-ya alphanumerîkî ya ku di parametreya coSpaceUriMapping de hatî destnîşan kirin were zêdekirin.

Pêşkêşkara LDAP û nexşeya LDAP-ê têne mîheng kirin. Naha hûn hewce ne ku wan bi afirandina çavkaniyek LDAP-ê bi hev re girêdin.

Ji bo gihîştina URL-ê bikar bînin cms01.example.com:445/api/v1/ldapSource neşeyek Çavkaniya LDAP-ê diafirîne, pîvanên wekî:

• server
• Maşallah
• bingehDn
• parzûn

Naha ku veavakirina LDAP qediya, hûn dikarin operasyona hevdengkirina destan pêk bînin.

Em vê yekê di navgîniya Webê ya her serverê de bi tikandinê dikin Niha senkronîze bikin beşa Dîra Active Active


an jî bi fermana API-ê re KOZ ji bo gihîştina URL-ê bikar bînin cms01.example.com:445/api/v1/ldapSyncs

konferansên Ad-Hoc

Ev çi ye?Di konsepta kevneşopî de, konferansek ew e ku du beşdar bi hev re diaxivin, û yek ji beşdaran (alavek ku bi Unified CM ve hatî tomar kirin bikar tîne) pêl bişkoka "Konferansê" dike, gazî kesê din dike û piştî ku bi wî partiya sêyemîn re diaxive. , dîsa pêl bişkoka "Konferanse" dike da ku beşdarî konferansa sê alî bibe.

Ya ku konferansek Ad-Hoc ji konferansek plansazkirî ya di CMS-ê de cûda dike ev e ku konferansek Ad-Hoc ne tenê bangek SIP-ê ji CMS-ê re ye. Gava ku destpêkerê konferansê cara duyemîn bişkoka Konferansê bikirtîne da ku her kesî vexwîne heman civînê, CM-ya Yekgirtî divê bangek API-yê ji CMS-ê re bike da ku konferansek li ser-firînê biafirîne ku paşê hemî bang lê têne veguheztin. Hemî ev yek ji hêla beşdaran ve nayê dîtin.

Ev tê vê wateyê ku Unified CM pêdivî ye ku pêbaweriyên API û navnîşana WebAdmin / porta karûbar û her weha SIP Trunk rasterast ji servera CMS-ê re mîheng bike da ku bangê bidomîne.

Ger hewce be, CUCM dikare bi awayekî dînamîkî cîhek di CMS-ê de biafirîne da ku her bangek bikaribe bigihîje CMS-ê û qaîdeya banga gihîştî ya ku ji bo cîhan hatî armanc kirin li hev bike.

Yekbûn bi CUCM re bi heman awayê ku di gotarê de hatî destnîşan kirin têne mîheng kirin berê ji bilî ku li ser Cisco UCM hûn hewce ne ku ji bo CMS-ê, sê Pirên Konferansê sê qulikan biafirînin, di Profîla Ewlekariya SIP-ê de sê Navên Mijara, Komên Rê, Lîsteyên Rê, Komên Çavkaniyên Medyayê û Lîsteyên Komên Çavkaniya Medyayê diyar bikin, û çend qaîdeyên rêwîtiyê lê zêde bikin. ji bo Cisco Civîna Server.

Profîla Ewlekariya SIP:


Trunks:


Her stûnek yek xuya dike:




Pira Konferansê


Her Pira Konferansê heman xuya dike:


Route Group


Lîsteya rê


Koma Çavkaniya Medyayê


Lîsteya Koma Çavkaniya Medyayê

Qaîdeyên Bangê

Berevajî pergalên rêveberiya banga pêşkeftî yên wekî Unified CM an Expressway, CMS tenê ji bo bangên nû li domainê di qada SIP Request-URI de digere. Ji ber vê yekê heke SIP INVITE ji bo sip e: [email parastî]CMS tenê li ser domain.com eleqedar e. CMS van rêbazan dişopîne da ku diyar bike ka meriv li ku derê bangek rêve dike:

1. CMS pêşî hewl dide ku domaina SIP-ê bi domên ku di qaîdeyên banga hatinê de hatine mîheng kirin re hevber bike. Dûv re ev bang dikarin li cîhên ("armanc") an bikarhênerên taybetî, IVR-yên hundurîn, an rasterast Microsoft Lync / Skype ji bo Karsaziyê (S4B) yekbûyî werin rêve kirin.
2. Ger di qaîdeyên banga gihîştî de hevber tune be, CMS dê hewl bide ku domaina ku di tabloya şandina bangê de hatî mîheng kirin bihevre bike. Ger lihevhatinek çêbibe, qaîdeyek dikare bi eşkere bangê red bike an bangê bişîne. Di vê demê de, CMS dikare domainê ji nû ve binivîsîne, ku carinan ji bo bangkirina domên Lync kêrhatî ye. Her weha hûn dikarin hilbijêrin ku hûn avêtinê derbas bikin, ku tê vê wateyê ku yek ji qadan dê bêtir neyê guheztin, an planek guheztina CMS-a hundurîn bikar bînin. Ger di qaîdeyên şandina bangê de lihevhatî tune be, ya xwerû redkirina bangê ye. Bînin bîra xwe ku di CMS-ê de, her çend bang "pêşveçûn" be jî, medya hîn jî bi CMS-ê ve girêdayî ye, ku tê vê wateyê ku ew ê di rêça îşaretkirin û trafîka medyayê de be.
Dûv re tenê bangên şandin di bin qaîdeyên banga derketinê de ne. Van mîhengan meqsedên ku lê têne şandin, celebê boriyê (çi ew bangek nû ya Lync be an bangek standard SIP be), û her veguheztinên ku dikarin bêne kirin heke veguheztin di qaîdeya şandina bangê de neyê hilbijartin diyar dikin.

Li vir qeyda rastîn a ku di dema konferansek Ad-Hoc de diqewime heye

Dîmenê wê xirab nîşan dide (ez nizanim meriv wê çawa çêtir bikim), ji ber vê yekê ez ê têketinê bi vî rengî binivîsim:

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

Konferansa Ad-Hoc bixwe:


Qaîdeyên Banga Hatina
Veavakirina parametreyên bangên hatinî pêdivî ye ku meriv bikaribe di CMS-ê de bangek werbigire. Wekî ku we di sazkirina LDAP-ê de dît, hemî bikarhêner bi domainê conf.pod6.cms.lab ve hatin şandin. Ji ber vê yekê bi kêmanî, hûn dixwazin bangên vê domainê bikin ku cîhan bikin armanc. Her weha hûn ê hewce bikin ku ji bo her tiştê ku ji bo navê domainê bi tevahî jêhatî (û dibe ku navnîşana IP-yê) ya her yek ji serverên CMS-ê jî tête armanc kirin, rêgez saz bikin. Kontrola banga meya derveyî, CM-ya Yekgirtî, dê stûnên SIP-ê ku ji bo her yek ji serverên CMS-ê veqetandî veqetandî mîheng bike. Bi vê yekê ve girêdayî ye ku mebesta van SIP-ê navnîşanek IP-yê ye an FQDN-ya serverê dê diyar bike ka CMS pêdivî ye ku were mîheng kirin da ku bangên ku ji navnîşana IP-ya wê an FQDN-ê têne şandin qebûl bike.

Domaina ku xwedan qaîdeya hundurîn a herî pêşîn e, ji bo her cîhên bikarhêner wekî domain tê bikar anîn. Dema ku bikarhêner bi LDAP-ê hevdem dikin, CMS bixweber cîhan diafirîne, lê tenê beşa bikarhêner a URI (coSpaceUriMapping), mînakî user.space. Par domain URI-ya tevahî li ser vê qaîdeyê tête çêkirin. Bi rastî, heke hûn di vê nuqteyê de têkevin Web Bridge, hûn ê bibînin ku Space URI xwedan domainek nîne. Bi danîna vê qaîdeyê wekî pêşîniya herî bilind, hûn domainê ji bo cîhên hatine çêkirin wekî diyar dikin conf.nimûne.com.


Rêbazên Banga Derketî

Ji bo ku hûn bihêlin bikarhêner bangên derketinê li koma CM-ya Yekgirtî bikin, divê hûn qaîdeyên derketinê mîheng bikin. Domaina xalên paşîn ên ku bi CM-ya Yekgirtî re hatine tomar kirin, wek Jabber, example.com e. Pêdivî ye ku bangên vê domainê wekî bangên SIP-ê standard ji girêkên pêvajoyek banga CM-ya Yekgirtî re werin rêve kirin. Pêşkêşkara sereke cucm-01.example.com e, û servera zêde jî cucm-02.example.com e.

Rêbaza yekem rêwîtiya herî hêsan a bangên di navbera pêşkêşkerên komê de vedibêje.

warê Herêmî ji domain Berpirsiyariya tiştê ku dê di SIP-URI-ya telefonker de ji bo kesê ku li dû sembola "@" tê gazî kirin were xuyang kirin. Ger em wê vala bihêlin, wê hingê piştî nîşana "@" dê navnîşana IP-ya CUCM-ê hebe ku ev bang tê de derbas dibe. Ger em domainek diyar bikin, wê hingê piştî nîşana "@" dê bi rastî domainek hebe. Ev pêdivî ye ku meriv bikaribe vegere, wekî din ne gengaz e ku hûn bi navgîniya SIP-URI name@ip-adresa vegere bang bikin.

Dema ku diyar kirin bang bikin Herêmî ji domain


Dema ku telefon bikin Ne diyar kirin Herêmî ji domain


Pê bawer bin ku hûn ji bo bangên derketinê bi eşkere Şîfrekirî an Neşîfrekirî destnîşan bikin, ji ber ku tiştek bi Parametreya Xweser re naxebite.

Girtinî

Konferansên vîdyoyê ji hêla servera Record ve têne tomar kirin. Recorder tam eynî wekî Servera Civîna Cisco ye. Recorder sazkirina ti lîsansan hewce nake. Lîsansên tomarkirinê ji bo pêşkêşkerên ku karûbarên CallBridge dixebitin hewce ne, yanî. destûrnameyek Tomarkirinê hewce ye û divê li ser pêkhateya CallBridge, û ne ji servera ku Recorder dixebitîne, were sepandin. Tomar wekî xerîdarek Peyam û Protokola Hebûnê ya Berfireh (XMPP) tevdigere, ji ber vê yekê divê servera XMPP li ser servera ku CallBridge mêvandar e were çalak kirin.

Bo Komek me heye û pêdivî ye ku destûrname li ser her sê serverên di komê de were "dirêj kirin". Dûv re tenê di hesabê weya kesane de di lîsansan de em navnîşanên MAC-ê yên navbeynkarên a-ya hemî pêşkêşkerên CMS-ê yên ku di nav komê de ne têne girêdan (lê zêde dikin).

Û ev wêneya ku divê li ser her serverek di komê de be

Bi gelemperî, ji bo danîna Recorder çend senaryo hene, lê em ê li ser vê bisekinin:


Berî sazkirina Recorder, hûn hewce ne ku cîhek ku konferansên vîdyoyê bi rastî bêne tomar kirin amade bikin. Bi rastî li vir pirtûk, çawa ji bo sazkirina hemû Recording. Ez li ser xal û hûrguliyên girîng disekinim:

1. Çêtir e ku sertîfîkayê ji servera yekem a di komê de derxîne.
2. Dibe ku xeletiya "Qydar tunebe" çêbibe ji ber ku sertîfîkaya xelet di Baweriya Tomarê de hatî destnîşan kirin.
3. Heke pelrêça NFS ya ku ji bo tomarkirinê hatî destnîşankirin ne pelrêça root be, dibe ku nivîsandin nexebite.

Carinan hewce ye ku bixweber konferansek bikarhênerek an cîhek taybetî tomar bike.

Ji bo vê yekê, du CallProfile têne afirandin:
Bi tomarkirinê neçalak


Û bi fonksiyona tomarkirina otomatîk


Dûv re, em CallProfilek bi fonksiyonek tomarkirina otomatîkî li cîhê xwestinê "girêdidin".


Di CMS-ê de ew qas hatî destnîşan kirin ku heke CallProfile bi eşkere bi cîhek an cîhek ve girêdayî be, wê hingê ev CallProfile tenê bi van cîhên taybetî re têkildar dixebite. Û heke CallProfile bi tu cîhekî ve ne girêdayî ye, wê hingê ew bi xwerû li wan cîhên ku tu CallProfile bi eşkereyî ve girêdayî ne tê sepandin.

Cara din ez ê hewl bidim ku vebêjim ka meriv çawa CMS li derveyî tora navxweyî ya rêxistinê tê gihîştin.

Çavkaniyên

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

Source: www.habr.com