Julkinen Internet

Suora SIP-runko (topin päällä)

Asiakkaan KUUTIO tai SBC tulee asettaa julkisuuteen IP. Tämä on suositeltava vakiokäyttömallimme.

Koska tämä on pelkistetty lähestymistapa, se on myös vähiten joustava. Yksinkertaistetun topologian etuja ovat hallinta ja vianmääritys. Asiakas täydentää verkkokaaviot ja lähettää ne puhepostiryhmälle, ja soittokomennukset luodaan. KUUTIOn asettaminen DESH:iin vähentää NAT:n käsittelyn monimutkaisuutta. Kuutio on itse palomuuri, ja useimmat keskisuuret ja suuret tietotuottajat sijoittavat KUUTIO-kuutionsa julkiseen IP ja käyttävät suojausominaisuuksiaan.

Vpn

VPN on toisenlainen yhteystyyppi, joka käyttää julkista Internetiä. VPN:iä tarvitaan usein, kun asiakas tarvitsee suojatun yhteyden SIP-yhteyttä ja RTP. VPN saattaa myös olla pakollinen, jos asiakas ei voi asettaa KUUTIOTA julkiseen IP tilaan. VPN-yhteyksille tarvitaan puhetuotantotapaaminen.

Puheportit

• RTP: 8000 - 48199

• SIP: UDP 5060

IPSec VPN tai IPSec GRE-ylle

VPN-yhteys voi käyttää seuraavia asetuksia:

• SBC- ja SBC-yhteydet

• GW to GW -yhteys

Webex Yhteyskeskus (IPSec tai IPSec GRE-tunnelin yli ja Webex Contact Center S2S Connectivity) käyttämään UDP/5060:a TCP/5060:n sijaan

GRE-IPSec VPN tai IPSec on hyvä vaihtoehto turvalliselle SIP-ulkolinjalle, kun KUUTIO on julkisessa IP. Tämä on SBC–SBC-yhteys. (Kaavio 2) VPN tunneleita käyttäen yksityisiä IP osoitemalleja on myös otettava huomioon asiakkaiden välisten päällekkäisyyksien välttämiseksi. GRE-yhteyksien osalta IP aliverkkoa ovat: 10.x.248.x ja 10.x.249.x.

Toimipaikka todenn. (S2S)

S2S-yhteys voidaan ottaa käyttöön, jos asiakas tarvitsee suojatun yhteyden tai ei voi asettaa KUUTIOTA julkiseen IP. Tämä on yhdyskäytävä yhdyskäytävään. S2S-VPN-yhteyksille ei ole määritetty aliverkkoja, koska reititys perustuu mielenkiintoiseen liikenteeseen ilman loogista käyttöliittymää.

SIP-TLS ja SRTP

SRTP/SIP-TLS käyttäminen on toinen vaihtoehto, kun KUUTIO on julkisessa IP-osoitteessa. SRTP/SIP-TLS käytölle on kuitenkin suoritusosuma. KUUTIO-laite voi käsitellä kolmasosan SIP-istunnoista, jos olet varmistanut puhelut TLS tai SRTP. Tämä on SBC–SBC-yhteys.

SIP-TLS yhteyden muodostamiseksi on tarpeen vaihtaa varmenteita. Käytettävissä ovat seuraavat vaihtoehdot:

• Itse allekirjoitettuja varmenteita luodaan ja vaihdetaan asiakkaan ja Webex yhteyskeskuksen välillä.

• Julkinen myöntäjän varmenne – julkisen myöntäjän tueksi on tehtävä seuraavat toimet:

  • Asiakkaan on jaettava päävarmenne, joka ladataan Webex yhteyskeskuksen SBC:hen.

  • Asiakkaan on päivitettävä DNS niin, että se sisältää Webex Contact Center SBC :t.

Yksityinen yhteys

Usein suurten yrityspalvelujen yhteysvalinta, suora yhteys tarjoaa erityisen ja suojatun piirin. Jos asiakas tarvitsee suorat yhteydet, asiakkaalle voi Cisco Webex Contact Center antaa ensimmäisenä vaiheena V VIPS-piirijärjestystä koskevat ohjeet -asiakirjan sekä jatkosuunnittelukokouksen Webex Contact Center Voice Engineering -työryhmän kanssa, ja asiakasinsinöörejä on toteutettava seuraavassa vaiheessa. Asiakkaan on toimitettava yksityiskohtainen verkkokaavio asiakkaan ääniverkosta, mukaan lukien PSTN-palveluntarjoajien väliset yhteydet kokousta varten. Cisco ei isännöi asiakaslaitteita.

Riippumatta siitä, valitseeko asiakas MPLS-, P2P-, VPLS- tai SD-WAN-vaihtoehdon, topologia näyttää samanlaiselta ja kaikki piirit päättyvät Webex Yhteyskeskuksen reititin/GW eivätkä Webex yhteyskeskuksen CUBEs-keskuksiin.

Suoralle yhteyden muodostamiselle asetetut kaistanleveysvaatimukset perustuvat G.711-koodekkiin (~100kbps puhelu jalkaa kohti), mikä mahdollistaa kaksi puheluetappia istuntoa kohden.

Datakeskuksen cross connect -yhteys

Jos asiakas päättää yksityisestä yhteydestä, on tarpeen tilata datakeskuksen cross connect -yhteydet siinä muodossa, jossa se kuvataan Cisco Webex Contact Center V VPN-piirijärjestyksen ohjeet -asiakirjassa. Asiakas vastaa syntyneistä kustannuksista ja asiakkaan piirin saamisesta määritettyyn pudotuspiiriin. (Viis.6.)

Cisco Webex Contact Center VHALLITUKSEN piirijärjestyksen ohjeiden asiakirja toimitetaan asiakkaalle suoraan aluksellaolon aikana, jos tämä yhteysasetus on ensisijainen.

Ei-vakiovarusteet

Jos suositeltavat topologiat eivät täytä kaikkia asiakkaan verkon vaatimuksia, suunnittelukokous on ajoitettava Cisco Voice Engineering -työryhmän kanssa asiakkaan Cisco-tiliryhmän kautta erityiseen hyväksyntämenettelyyn. Seuraavassa on esimerkkejä ei-vakio käyttöönotoista ja käyttöönotoista, joita ei suositella:

A2Q-poikkeukset

PSTN-toimittaja lopettaa piirin suoraan Webex Contact Center V CAPITARiin.

Gold Tenant -poikkeukset

Suosittelemme vahvasti suoraa SIP-runkoa Gold Tenant -asiakkaille. Tämä on topologia, jossa KUUTIO asetetaan julkiseen IP välilyöntiin. Gold Tenantin tarve on usein olemassa suurempien palveluntarjoajien kanssa; Palveluntarjoaja kuitenkin edellyttää, että Gold Tenant on todiste toimittajan aiottua tuotannon käyttöönottoa varten. Gold Tenant -konseptin todiste ylittää usein SIP-ulkolinjan avoimen Internet-yhteyden käytön ja vaatisi yhden aiemmin käsitellyistä yhteystyypeistä.

Gold Tenant -asiakkaita ei seurata.

Julkinen Internet – CUBE palomuurin takana

Kuution asettaminen yksityiseen IP-osoitteeseen NAT-palomuurin takana on toinen käyttöönottovaihtoehto. Asiakkaan IT-laitoksen suojausvaatimukset voivat säätää, että äänisovellus on palomuurin takana. Tällä toiminnolla on muutamia tunnettuja haittoja. Vaikka tämä ei ehkä aiheuttaisi ongelmia verkkokerroksessa, se voi aiheuttaa ongelmia SIP-sovelluskerroksessa. SIP-viesteissä käytetään yksityistä IP osoitetta, mikä aiheuttaa puhelun käsittelyvirheitä. Toinen tämäntyyppisessä käyttöönotossa otettava tekijä on palomuurin kapasiteetti. Palomuurien koko on mitoitettava asianmukaisesti VoIP liikennettä varten. Palomuurista voi muuten tulla pullonkaula, joka voi vaikuttaa puhelun laatuun ja puhelunkäsittelyyn.

Tämän käyttöönoton haitat ovat seuraavat:

• Mahdolliset CUBE-määritykset ja -määritysongelmat alussa.

• Palomuurin lataus on kasvanut, mikä voi vaikuttaa äänenlaatuun.

• Asiakas vastaa KUUTION määrittämisestä ja palomuurin kokoamisesta.

• Ei suositeltava topologia, koska se vaikuttaa SLA-painikkeisiin.

Tätä topologiaa ei suositella, koska SIP: n ja NAT: n käsittely on monimutkaisuutta. Kokous Cisco Voice Engineering -ryhmän ja asiakkaan kanssa edellyttää tämäntyyppisen käyttöönoton hyväksyntää.