Végpontokra vonatkozó követelmények

Webex Calling Edge

SIP-regisztráció vagy hívás végrehajtásához a következő lépéseket végezze el:

  • Azonosítsa egy SIP-végpont állomáscímét az aktív Edge-csomópontokhoz.

  • Teljesítse az összes felhasználó- és eszközkonfigurációra vonatkozó előfeltételt.

  • Bizonyosodjon meg arról, hogy a végpont rendelkezik nyilvános hálózati kapcsolattal a szolgáltatásazonosítás megkezdéséhez.

  • Teljesítse a végpont régió- vagy adatközpont-specifikus beüzemelési konfigurációval történő rendszerindításának előfeltételeit. Ezzel a konfigurációval lekérheti az adott tartománynév utótagját a szolgáltatásazonosításhoz.

IPv4 versus IPv6

Az eszközök egyvermes vagy kétvermes módban működnek. A konfiguráció határozza meg az előnyben részesített protokoll módosításait, és ezek a módosítások nem részei a szolgáltatásazonosításnak.

  • Egyvermes mód—Csak egy IP-protokollt (pl. IPv4) engedélyez, és figyelmen kívül hagyja a többi protokollcímet.

  • Kétvermes mód—A konfiguráción keresztül kiválasztja az előnyben részesített IP-verziót.

A kliens az összes előnyben részesített cím prioritását alacsonyabbnak (azaz előnyben részesítettnek) tekinti, mint az IP összes címét. Ha az előnyben részesített az IPv4, akkor az összes IPv4-címet megpróbálja a rendszer, mielőtt IPv6-címre kerülne sor. Ha az összes cím sikertelen, a ciklus újrakezdődik, a legalacsonyabb prioritású, előnyben részesített protokollcímmel.

A leküldéses értesítés beérkezésekor regisztráló mobilkliens a korábbi regisztrációk alapján dönthet a mód optimalizálásáról.

Az állomáscím feloldása a DNS SRV-címről

Az üzembe helyezés során kapott végpont-konfigurációs fájlban a tartományjelző a tartománynevet adja meg a hozzáférési peremhálózati szolgáltatás felderítéséhez. Példa a tartománynévre:

wxc.edge.bcld.webex.com

A példa alapján a DNS SRV-keresést végző végpont ehhez a tartományhoz a következőhöz hasonló választ kaphat:

 # 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.

Ebben az esetben az SRV-rekord 3 A-rekordra mutat.

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

A példában az összes állomás az 5061-es portra van közzétéve, eltérő súlyozással és prioritással.

Vegye figyelembe e végpontokra vonatkozó követelményeket.

  • Egy végpontnak használnia kell_sips ._tcp (szolgáltatás és protokoll kombináció) előtagként DNS SRV keresést végez a TLS alapú kommunikáció kezdeményezéséhez szükséges gazdagép cím lekéréséhez.

  • A végpontnak DNS SRV-keresést kell végrehajtania Az állomáscím feloldása a DNS SRV-címről szakaszban leírt feltételek esetén.

  • A végpontnak figyelembe kell vennie az egyes állomáscímekben közzétett állomás, port, súly és prioritás értékét. Emellett a SIP-regisztráció során a szoftvercsatorna-kapcsolat létrehozásakor létre kell hoznia az állomás és a port közötti affinitást.

  • A DNS SRV-rekord használatára vonatkozóan az állomások prioritás és súly alapján való kiválasztásának kritériumait az RFC 2782 ismerteti.

SIP-re és médiára vonatkozó követelmények

Követelmény

Leírás

Megbízhatósági tanúsítvány szükséges a nyilvános kulcs titkosításához

A Webex-tanúsítványok aláírási jogosultságáról és az eszközökhöz szükséges CA-gyökértanúsítványról a cikkben olvashat

Támogatott TLS-verziók a biztonságos SIP-hez

TLS 1,2

Támogatott TLS-rejtjelek a biztonságos SIP-hez

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

Támogatott SRTP-kulcsok a biztonságos médiához

AES_CM_128_HMAC_SHA1_80

A biztonságos SIP követelményei mTLS-sel (közös TLS)

A követelmények részletes magyarázata itt található.

A trönkről érkező hívások sikeres engedélyezéséhez és hitelesítéséhez aláírt tanúsítványra van szükség. A tanúsítványnak az alábbi követelményeknek kell megfelelnie:

  • A tanúsítványt a pontban említett hitelesítésszolgáltatónak kell aláírnia Milyen legfelső szintű hitelesítésszolgáltatók támogatottak a Cisco Webex audio és video platformok hívásai esetén?

  • Töltse fel a következőben említett bizalmi csomagot Milyen legfelső szintű hitelesítésszolgáltatók támogatottak a Cisco Webex audio és video platformok hívásai esetén? tovább a CUBE-ra.

  • A tanúsítványnak mindig érvényesnek kell lennie:

    • Az aláírt tanúsítványoknak mindig rendelkezniük kell érvényes lejárati dátummal.

    • A gyökér- vagy közbenső tanúsítványoknak érvényes lejárati idővel kell rendelkezniük, és nem lehetnek visszavontak.

    • A tanúsítványokat alá kell írni a kliens- és kiszolgálóhasználathoz.

    • A tanúsítványoknak tartalmazniuk kell a teljesen minősített tartománynevet (FQDN) általános névként, vagy a téma másik megnevezését a Control Hubban kiválasztott FQDN-nel együtt. Például:

      • Annak a trönknek, amely a szervezete Control Hubjából lett konfigurálva és az FQDN-je a london.lgw.cisco.com:5061, tartalmaznia kell a következőt a CN- vagy SAN-tanúsítványban: london.lgw.cisco.com.

      • Annak a trönknek, amely a szervezete Control Hubjából lett konfigurálva és az SRV-je a london.lgw.cisco.com volt, tartalmaznia kell a következőt a CN- vagy SAN-tanúsítványban: london.lgw.cisco.com. Azok a rekordok, amelyeket az SRV-cím (CNAME-re/A-rekordra/IP-címre) old fel, a SAN-ban opcionálisak.

    • Egynél több helyi átjáróval is megoszthat tanúsítványokat, azonban meg kell bizonyosodnia arról, hogy az FQDN-követelmények be vannak tartva.

Hatókörön kívül

Ez a cikk nem tartalmazza az alábbi, hálózatbiztonsággal kapcsolatos információkat:

  • F5-követelmények a CA-hoz és a rejtjelekhez

  • HTTP-alapú API a Webex-tűzfalszabályok letöltéséhez

  • API megbízható köteghez

  • Tűzfalkövetelmények és ALG-letiltás