Zahteve za končne točke

Klicni rob Webex

Če želite izvesti registracijo ali klic SIP, naredite naslednje korake:

  • Odkrijte gostiteljski naslov končne točke SIP za aktivna vozlišča Edge.

  • Izpolnite vse predhodne pogoje, povezane z nastavitvijo uporabnika in naprave.

  • Zagotovite, da ima končna točka javno omrežno povezljivost, da lahko začne odkrivanje storitev.

  • Izpolnite predpogoje za zagon končne točke s konfiguracijo zagotavljanja, značilno za regijo ali podatkovno središče. Ta konfiguracija pomaga pridobiti ustrezno končnico domenskega imena za odkrivanje storitev.

IPv4 v primerjavi z IPv6

Naprave lahko delujejo v načinu z eno različico ali dvema skladoma. Spremembe prednostnega protokola določa konfiguracija, te spremembe pa niso del odkrivanja storitev.

  • Način enega sklada - omogoči samo en protokol IP (na primer IPv4) in ne upošteva naslovov drugih protokolov.

  • Način dvojnega sklada - s konfiguracijo izbere prednostno različico IP.

Odjemalec meni, da je prednost vseh prednostnih naslovov nižja (torej prednostna) od vseh naslovov IP. Če je prednostno izbran IPv4, se pred iskanjem naslova IPv6 poskusijo vsi naslovi IPv4. Če so vsi naslovi neuspešni, se cikel začne znova z najnižjim prednostnim prednostnim protokolnim naslovom.

Mobilni odjemalec, ki se registrira ob prejemu potisnega obvestila, se lahko odloči za optimizacijo načina na podlagi prejšnjih registracij.

Rešitev naslova gostitelja iz naslova DNS SRV

V konfiguracijski datoteki končne točke, pridobljeni z zagotavljanjem, indikator domene določa ime domene za odkrivanje storitve access edge. Primer imena domene je:

wxc.edge.bcld.webex.com

Iz primera je razvidno, da lahko končna točka, ki za to domeno izvede poizvedbo DNS SRV, dobi podoben odgovor, kot sledi:

 # nslookup -type=srv _sips._tcp. wxc.edge.bcld.webex.com _sips._tcp.wxc.edge.bcld.webex.com SRV 5 100 5061 sip-edge1.us-dc1.bcld.webex.com. _sips._tcp.wxc.edge.bcld.webex.com SRV 10 105 5061 sip-edge2.us-dc1. bcld.webex.com.

V tem primeru zapis SRV kaže na 3 zapise A.

 sip-edge1.us-dc1.bcld.webex.com sip-edge2.us-dc1.bcld.webex.com

V tem primeru so vsi gostitelji oglašeni za stik z vratom 5061 z različno utežjo in prioriteto.

Upoštevajte te zahteve za končne točke.

  • Končna točka mora uporabiti _sips._tcp (kombinacija storitve in protokola) kot predpono za izvedbo iskanja DNS SRV za pridobitev naslova gostitelja za začetek komunikacije na podlagi TLS.

  • Končna točka mora opraviti iskanje DNS SRV v skladu s pogoji, pojasnjenimi v razdelku Razreševanje naslova gostitelja iz naslova DNS SRV.

  • Končna točka mora upoštevati gostitelja, vrata, utež in prednost, kot so oglaševani za vsak naslov gostitelja. Prav tako mora ustvariti sorodnost gostitelja in vrat pri ustvarjanju vtične povezave med registracijo SIP.

  • Merila za izbiro gostiteljev na podlagi prednosti in teže, ki se nanašajo na uporabo zapisa SRV DNS, so pojasnjena v standardu RFC 2782.

Zahteve za SIP in medije

Zahteva

Opis

Zaupanja vredno potrdilo, potrebno za šifriranje z javnim ključem

Oglejte si članek , v katerem boste izvedeli več o organu za podpisovanje potrdil Webex in korenskem CA, ki je potreben v napravah.

Podprta različica TLS za varen SIP

TLS 1.2

Podprte šifre TLS za varen SIP

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLS_DHE_DSS_WITH_AES_128_GCM_SHA256

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

TLS_DHE_DSS_WITH_AES_128_CBC_SHA256

TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256

Podprti ključi SRTP za varne medije

AES_CM_128_HMAC_SHA1_80

Zahteve za varen SIP z mTLS (vzajemni TLS)

Zahteve so podrobno pojasnjene tukaj.

Za uspešno avtorizacijo in avtentikacijo klicev iz magistralnega omrežja je potrebno podpisano potrdilo. Potrdilo mora izpolnjevati naslednje zahteve:

  • Potrdilo mora biti podpisano s strani CA, ki je naveden na spletni strani Kateri korenski overitelji potrdil so podprti za klice na platforme Cisco Webex Audio in Video?

  • V CUBE naložite sveženj zaupanja, omenjen v What Root Certificate Authorities are Supported for Calls to Cisco Webex Audio and Video Platforms?.

  • Potrdilo mora biti vedno veljavno:

    • Podpisana potrdila morajo imeti vedno veljaven rok veljavnosti.

    • Korenski ali vmesni certifikati morajo imeti veljaven rok veljavnosti in ne smejo biti preklicani.

    • Potrdila morajo biti podpisana za uporabo v odjemalcu in strežniku.

    • Potrdila morajo vsebovati popolnoma kvalificirano domensko ime (FQDN) kot skupno ime ali nadomestno ime subjekta v potrdilu z izbrano FQDN v nadzornem vozlišču. Na primer:

      • Krovno omrežje, konfigurirano iz nadzornega vozlišča vaše organizacije z london.lgw.cisco.com:5061 kot FQDN, mora vsebovati london.lgw.cisco.com v certifikatu CN ali SAN.

      • V glavnem omrežju, ki je konfigurirano iz nadzornega vozlišča vaše organizacije in ima v SRV naveden naslov london.lgw.cisco.com, mora biti v potrdilu CN ali SAN naveden naslov london.lgw.cisco.com. Zapisi, na katere se naslov SRV razreši (zapis CNAME/A/IP naslov), so v SAN neobvezni.

    • Potrdila lahko delite z več kot enim lokalnim prehodom, vendar se prepričajte, da so izpolnjene zahteve glede FQDN.

Izven področja uporabe

Ta članek ne vključuje naslednjih informacij, povezanih z varnostjo omrežja:

  • Zahteve družbe F5 za CA in šifre

  • API na osnovi protokola HTTP za prenos pravil požarnega zidu za Webex.

  • API za sveženj zaupanja

  • Zahteva za požarni zid in onemogočanje ALG