Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Europejski lider sprzedaży techniki i elektroniki.
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

NFON - Nowoczesna centrala telefoniczna w chmurze

gulson 05 Gru 2017 13:47 2130 54
  • NFON - Nowoczesna centrala telefoniczna w chmurze

    NFON – Nowoczesna centrala telefoniczna w chmurze

    NFON to propozycja firmy Biznes Innovation na wirtualną centralę IP zrealizowaną jako usługa chmurowa. Wykorzystanie chmury obliczeniowej to aktualny trend w świecie IT umożliwiający przyspieszenie wdrożenia, ograniczenie kosztów początkowych, zwiększenie dostępności oraz skalowalności usług. Klient wykorzystuje obecnie posiadane łącze do internetu oraz telefony IP (lub inny urządzenia SIP) połączone przez internet z wirtualną centralą. Rolę telefonu może pełnić także oprogramowanie (softphone) uruchomione na PC lub smartfonie. Centralą zarządzamy z wykorzystaniem interfejsu WEB, natomiast zamówione zasoby (np. ilość numerów) można zmieniać z miesiąca na miesiąc.

    Wyłącznym dystrybutorem usług NFON w Polsce jest firma Biznes Innovation, a wsparciem klienta zajmuje się 80 firm partnerskich, mających siedziby w całym kraju. Dzięki temu każdy klient zyskuje indywidualnego, lokalnego opiekuna.
    Bardzo istotny jest fakt, że NFON to operator zarejestrowany w Polsce. Oznacza to, że podlega wszelkim regulacjom prawnym obowiązującym w naszym kraju tak jak wszyscy inni operatorzy działający na rynku.

    Firmy i specjaliści IT zainteresowani rozwiązaniem mają szansę na bezpłatne testy wirtualnej centrali przez 30 dni, kontakt:
    Biznes Innovation
    +48 22 246 4000
    +48 666 453 555
    mail(malpa)biznesinnovation.com
    www.nfon.com.pl

    Centrala NFON udostępniona jako usługa w chmurze to:
    - gwarancja jakości i bezpieczeństwo dostarczane przez usługodawcę,
    - łatwy, przejrzysty, samoobsługowy system dostępny przez WEB dla zespołu IT klienta,
    - all inclusive - 160 funkcji zaawansowanej centrali IP,
    - automatyczna konfiguracja nowych telefonów oraz zdalne zarządzanie telefonami przyłączonymi do systemu.

    Przyjrzyjmy się bliżej pomysłowi na dostarczenie centrali jako skalowalnej usługi udostępnianej w chmurze, odnosząc się do rozwiązań PBX / IP PBX zrealizowanych jako fizyczny sprzęt w naszej firmie.

    Niezawodność usługi na poziomie >99.9% zagwarantowana jest przez profesjonalne dwa centra rozproszone geograficznie. Kontakt dla klientów w pojedynczym punkcie helpdesk 24/7. Jeżeli łącze internetowe w naszej firmie ulegnie awarii możemy skorzystać z łącza zapasowego (np. bezprzewodowego) zapewniając połączenie z internetem i ciągłość działania usługi telefonicznej. Dodatkowo dla każdego numeru można zdefiniować awaryjny numer (np. komórkowy), w sytuacji braku łączności z internetem w naszej firmie zadzwoni komórka zamiast telefon na naszym biurku.

    Natomiast w przypadku sprzętowych central telefonicznych zainstalowanych w budynku firmy (on-premises) rzadko stosowane były rozwiązania zapewniające redundancję. Awaria sprzętowa centrali często wiązała się z niedostępnością, aż do wymiany lub naprawy sprzętu. Rozwiązania redundantne zdarzały się najczęściej w przypadku centrali zainstalowanej w siedzibie głównej firmy i urządzeniach SIP w oddziałach, które zarejestrowane były do centrali z wykorzystaniem internetu. Pojedynczym punktem awarii było też łącze ISDN PRA/BRA lub nawet analogowe łącze doprowadzone do budynku i połączone z PBX. W przypadku IP PBX wykorzystanie SIP trunk do operatora zwiększało dostępność, gdyż można wykorzystać zapasowe łącze do internetu.

    Szybkość i skalowalność wdrożenia zapewnia łatwa konfiguracja telefonów IP (auto provisioning), wykorzystanie istniejącej infrastruktury połączenia z internetem oraz łatwe zarządzanie centralą poprzez interfejs WEB, a także łatwe skalowanie zamówionych zasobów. Skalowanie zasobów może pomóc w stopniowym wdrożeniu oraz dopasowaniu usługi do aktualnego rozwoju i potrzeb firmy. Dla zespołu IT dostępne są szkolenia stacjonarne lub webinary dostarczające wiedzę o sposobie konfiguracji centrali.

    NFON - Nowoczesna centrala telefoniczna w chmurze

    Nowy telefon IP po wyjęciu z pudełka i podłączeniu do sieci spróbuje połączyć się z portalem swojego producenta (jeżeli otrzyma odpowiednią konfigurację z DHCP, aby uzyskać łączność z internetem). Jeżeli producent telefonu współpracuje z NFON, to poprzez wprowadzenie danych o zakupionych telefonach w portalu NFON możemy przypisać do naszych telefonów określoną konfigurację. Telefonem przyłączonym do systemu zarządzamy poprzez interfejs WEB NFON. Warto wspomnieć o możliwości zasilania telefonów IP poprzez PoE oraz przełącznikach sieciowych występujących w wielu modelach telefonów co pozwala na wykorzystanie istniejącego gniazda sieciowego do podłączenia telefonu i PC. W większych instalacjach warto zadbać o VLAN dedykowany dla urządzeń SIP oraz zadbać o zarezerwowanie pasma dla połączeń głosowych na urządzeniu brzegowym w naszej sieci.

    Połączenia inicjowane są z wewnątrz naszej sieci do chmury operatora, co ułatwia konfigurację reguł na urządzeniach sieciowych. Dostępna jest aplikacja pozwalająca na wykonanie testu i wygenerowanie raportu o ew. wykrytych problemach i potrzebnych działaniach (np. zakres portów do uwzględnienia w konfiguracji mechanizmów bezpieczeństwa). Sygnalizacja SIP może być zabezpieczona z wykorzystaniem TLS, natomiast dane głosowe przenoszone po SRTP.

    W odróżnieniu od NFON w przypadku central sprzętowych możliwość rozbudowy zapewniana jest albo licencyjnie (kupujemy licencję na funkcjonalności lub np. ilość zarejestrowanych numerów) lub poprzez dokupienie dodatkowych kart z wyposażeniem (np. porty analogowe lub ISDN) ew. dokupienie sprzętu (np. media gateway).

    Urządzenia końcowe to zwykle telefony IP SIP wykorzystujące kodek G.722 lub G.711. Do centrali wirtualnej możemy zarejestrować także posiadany media gateway umożliwiający podłączenie np. telefonów analogowych lub jedno-/kilkaportowe bramki dla faxów analogowych. Zastosowanie telefonów analogowych ogranicza funkcjonalność (np. dostęp do korporacyjnej książki telefonicznej). Użycie telefonów analogowych może być korzystne, gdy chcemy wykorzystać istniejącą w budynku infrastrukturę dla telefonów tradycyjnych. Sprzętowe faxy możemy wyeliminować usługą fax-to-mail, pdf-to-fax co pozwoli na oszczędność na materiałach eksploatacyjnych oraz ułatwienie dostępu do usługi faxowej. W przypadku np. fabryk/magazynów wykorzystanie stacji DECT SIP pozwala na podłączenie do systemu telefonów bezprzewodowych.
    Urządzeniem końcowym może być aplikacja (softphone). Aplikacja zainstalowana na PC pozwala np. integrować się z systemem obsługi klienta CRM lub wybrać numer po jego kliknięciu w mailu lub na stronie www. Aplikacja zainstalowana na smartfonie daje mobilność urządzenia końcowego a także np. unikanie roamingu gdy np. na lotnisku dostępna jest Wi-Fi.
    Integracja z komunikatorem Skype for Business powoduje, że z jednej aplikacji możemy dzwonić zarówno do użytkowników SfB, jak i telefonów w PSTN.

    Usługi dodatkowe - wirtualna centrala dostarcza wiele funkcjonalności podobnie jak zaawansowana sprzętowa IP PBX. Możemy konfigurować zapowiedzi IVR z listami wyboru, nagrywanie, grupy przejmowania wywołań (pickup group), numery wspólne dla grupy (hunt group), książka korporacyjna i wiele innych, takie jak audio-konferencje na kilkadziesiąt osób. Do audiokonferencji uczestnicy mogą wdzwaniać się numerem ze swojego kraju, co obniża koszty połączeń. Audio-konferencję można uatrakcyjnić poprzez prezentację slajdów, prezenter udostępnia dane uruchamiając aplikację, natomiast odbiorcy korzystają ze strony www.

    NFON - Nowoczesna centrala telefoniczna w chmurze

    W przypadku prostych central sprzętowych często można je traktować jako urządzenie typu np. przełącznik sieciowy, w którym raz na jakiś czas aktualizujemy firmware. Tego typu centrale potrafią pracować bezawaryjnie przez długie lata, jednak poza niezawodnością sprzętu warto dbać o bezpieczeństwo urządzeń połączonych z internetem. Bardziej zaawansowane IP PBX to zwykle zmodyfikowane systemy operacyjne z wieloma procesami obsługującymi VOIP, które wymagają regularnej aktualizacji w okresie wsparcia. Zmiana wersji oprogramowania centrali IP PBX czasami może wiązać się z dodatkowym kosztem. Natomiast w przypadku centrali wirtualnej przenosimy zadania związane z jej utrzymaniem na usługodawcę.

    Funkcjonalność połączeń telefonicznych dla firmy można zapewnić na wiele sposobów zarówno centralą wirtualną, jak i nową lub istniejącą fizyczną centralą PBX/IP PBX. Optymalne rozwiązanie zależy od bardzo wielu czynników technicznych i ekonomicznych, a decyzja o wyborze docelowego rozwiązania często nie jest trywialna.

    W jakich zastosowaniach widzicie możliwość wdrożenia wirtualnej centrali telefonicznej?

    Materiał sponsorowany.

    0 29
  • #2 05 Gru 2017 19:13
    TechEkspert
    Redaktor

    Interesuje mnie konkretna sytuacja,
    dwa telefony IP znajdują się w firmie w dwóch pokojach obok siebie i działają w tym samym segmencie LAN,
    dzwonię z telefonu A na telefon B,
    sygnalizacja "idzie" od telefonu przez internet do chmury operatora,
    połączenie zostało zestawione,
    czy dane RTP / SRTP przesyłane są między telefonami A i B przez lokalną sieć LAN czy przez łącze do interentu do chmury i z powrotem?

    Jak to wygląda gdy A i B znajdują się w dwóch lokalizacjach połączonych do interentu, lub dwóch lokalizacjach spiętych VPN / prywatnym WAN (np. na politechnikach funkcjonowało kiedyś takie rozwiązanie).

    Druga sprawa, czy funkcjonalność bilingowania może być oddzielona w interfejsie WEB od zarządzania i konfiguracją centrali? (np. dział finanse / IT).

    Trzecia sprawa, czy redundancja ośrodków zapewniających usługę chmurową opiera się o DNS, czy do telefonu spływa konfiguracja do dwóch sip registrar podstawowego i zapasowego?

    1
  • #3 06 Gru 2017 10:10
    Tomasz Robaczewski
    Poziom 4  

    Witam, dziękuję za konkretne pytania, odpowiedzi poniżej:

    >>dwa telefony IP znajdują się w firmie w dwóch pokojach obok siebie i działają w tym samym segmencie LAN, dzwonię z telefonu A na telefon B, sygnalizacja "idzie" od telefonu przez internet do chmury operatora, połączenie zostało zestawione, czy dane RTP / SRTP przesyłane są między telefonami A i B przez lokalną sieć LAN czy przez łącze do interentu do chmury i z powrotem?

    odp: zarówno SIP jak i RTP "idą" przez datacenter NFON, a dzieje się tak ze względu na usługi dodane (szyfrowanie , nagrywanie, ... ) oraz aby zapewnić możliwość monitorowania QoS - każda rozmowa jest próbkowana/monitorowana pod kątem jakości strumienia audio (utrata pakietów, jitter, ...).

    >>Druga sprawa, czy funkcjonalność bilingowania może być oddzielona w interfejsie WEB od zarządzania i konfiguracją centrali? (np. dział finanse / IT).

    odp: billing on-line, jest dostępny za pośrednictwem oddzielnego / innego niż administracyjny, interfejsu www

    >>>Trzecia sprawa, czy redundancja ośrodków zapewniających usługę chmurową opiera się o DNS, czy do telefonu spływa konfiguracja do dwóch sip registrar podstawowego i zapasowego?

    odp: telefon podlegający auto-provisioningowi (np. Yealink T4X ), otrzymuje automatycznie IP aktywnego sip-registrara, natomiast telefon nie-provisionowany zdalnie przez NFON (czyli dowolny terminal SIP) "szuka" sip-registrara via DNS.

    Pozdrawiam, T.Robaczewski

    0
  • #4 06 Gru 2017 11:29
    R-MIK
    Poziom 38  

    gulson napisał:
    Natomiast w przypadku sprzętowych central telefonicznych zainstalowanych w budynku firmy (on-premises) rzadko stosowane były rozwiązania zapewniające redundancję.

    Z naciskiem na słowo były, teraz, w większych systemach, to już norma.

    Dodano po 2 [minuty]:

    Tomasz Robaczewski napisał:
    odp: zarówno SIP jak i RTP "idą" przez datacenter NFON, a dzieje się tak ze względu na usługi dodane (szyfrowanie , nagrywanie, ... ) oraz aby zapewnić możliwość monitorowania QoS - każda rozmowa jest próbkowana/monitorowana pod kątem jakości strumienia audio (utrata pakietów, jitter, ...).

    I tego poważni klienci nie lubią. Nie chcą aby rozmowy wewnętrzne przechodziły przez zewnętrznych operatorów. Jak "spinam" oddziały firmy, czy nawet pojedyncze telefony (np służbowy w domu) to robię to bardzo często przez VPN.

    0
  • #5 06 Gru 2017 13:25
    Tomasz Robaczewski
    Poziom 4  

    R-MIK napisał:
    gulson napisał:
    Natomiast w przypadku sprzętowych central telefonicznych zainstalowanych w budynku firmy (on-premises) rzadko stosowane były rozwiązania zapewniające redundancję.

    Z naciskiem na słowo były, teraz, w większych systemach, to już norma.


    Jasne, ale każda redundancja dodatkowo kosztuje, a im wyższy poziom jej zaimplementowania w systemie, tym mniejszy jej koszt liczony per extension.


    Dodano po 2 [minuty]:

    R-MIK napisał:
    Tomasz Robaczewski napisał:
    odp: zarówno SIP jak i RTP "idą" przez datacenter NFON, a dzieje się tak ze względu na usługi dodane (szyfrowanie , nagrywanie, ... ) oraz aby zapewnić możliwość monitorowania QoS - każda rozmowa jest próbkowana/monitorowana pod kątem jakości strumienia audio (utrata pakietów, jitter, ...).

    I tego poważni klienci nie lubią. Nie chcą aby rozmowy wewnętrzne przechodziły przez zewnętrznych operatorów. Jak "spinam" oddziały firmy, czy nawet pojedyncze telefony (np służbowy w domu) to robię to bardzo często przez VPN.


    Można coś lubić bądź nie lubić, rozumiem, klient nasz pan, ale jakie tacy "poważni" klienci przedstawiają argumenty?

    0
  • #6 06 Gru 2017 13:54
    R-MIK
    Poziom 38  

    Tomasz Robaczewski napisał:
    Można coś lubić bądź nie lubić, rozumiem, klient nasz pan, ale jakie tacy "poważni" klienci przedstawiają argumenty?

    Bezpieczeństwo w bezpieczeństwie 9iso 2002 czy coś), ziobrofony poza firmą zakazane. Dla mnie, przy linkowaniu central, czy wpisze adres publiczny, czy lokalny (VPN) to jeden diabeł.

    Jak też nie mam ochoty, aby moje rozmowy były podsłuchiwane (np Prezes rozmawia z sekretarką o zdradzie żony).

    1
  • #7 06 Gru 2017 14:12
    Tomasz Robaczewski
    Poziom 4  

    ...eeeee, myslałem, że jakieś konkretne , twarde argumenty mają, a tu takie tam gadanie :-)

    Tunel TLS dla SIP i SRTP zestawiany dynamicznie via NFON end-to-end (telefon-telefon) w zupełności wystarczy, i to nawet nawet jak mamy "kreta" we własnej firmie (a w takim wypadku VPN nie pomoże)

    BTW - taki pan Prezes, rozmawiając z panią Krysią o du... pani Maryni z komórki oczywiście jest w swoim mniemaniu bezpieczny... :-)

    0
  • #8 06 Gru 2017 14:16
    R-MIK
    Poziom 38  

    Tomasz Robaczewski napisał:
    ...eeeee, myslałem, że jakieś konkretne , twarde argumenty mają, a tu takie tam gadanie :-)

    Twarde i konkretne to sa takie, że jak nie działa internet, to w firmie z biurka na biurko nie moża zatelefonować

    Tomasz Robaczewski napisał:

    BTW - taki pan Prezes, rozmawiając z panią Krysią o du... pani Maryni z komórki oczywiście jest w swoim mniemaniu bezpieczny... :-)

    Tak, sa aplikacje szyfrujące na Androida.

    0
  • #9 06 Gru 2017 14:47
    Tomasz Robaczewski
    Poziom 4  

    R-MIK napisał:
    Tomasz Robaczewski napisał:
    ...eeeee, myslałem, że jakieś konkretne , twarde argumenty mają, a tu takie tam gadanie :-)

    Twarde i konkretne to sa takie, że jak nie działa internet, to w firmie z biurka na biurko nie moża zatelefonować


    Oczywiście, nie można się z takim argumentem nie zgodzić, ale powstaje pytanie, co w przypadku braku netu jest ważniejsze dla firmy naszego klienta:

    - mozliwość tylko łączności wewnętrznej - pewnie w niektórych urzędach tak... :-)

    - czy może zachowanie pełnego działania telefonii w zakresie połączeń przychodzących (włacznie z IVR, kolejkowaniem, itp)? - to raczej w firmach nastawionych na obsługę dzwoniacych interesantów

    W tym drugim przypadku, z punktu widzenia interesanta dzwoniącego do firmy naszego klienta, nic się nie zmienia. Połączenie przychodzące na numer firmy chwilowo odciętej od internetu, jest procedowane w NFON tak jak zawsze, a dopiero na końcu, wywołanie nie jest kierowane na właściwy numer wewnętrzny w PBX, lecz na "backupową" komórkę danego pracownika (backup indywidualny, uprzednio zdefiniowany dla każdego extension w PBX).

    0
  • #10 06 Gru 2017 15:18
    R-MIK
    Poziom 38  

    Tak zerknąłem na cennik. Opłata miesięczna za aktywne urządzenie 35zł netto. Port centrali abonenckiej to 100zł netto, VoIP40zł/port przy zakupie 10 szt, 50zł przy jedne sztuce. Czyli w 3 miesiące zwraca sie koszt zakupu centrali. Ja zobaczyłem opłatę instalacyjną 149zł za urządzenie (centralę na własność kupie za 100/port) to gdzie ta konkurencyjność? Mnie wychodzi zdecydowanie drożej.

    Nagrywanie 20zł na miesiąc, ja za licencje nagrywania jednorazowo płace 100/kanał (przy 5 kanałach 80zł). Kanały sa przydzielane dynamicznie i maja priorytety, więc np 3 kanały wystarcza na 50 abonentów, przykład z życia: central 100ab, wiązka DDI 100nr na 4xBRA, 5 kanałów nagrywania (nie ma sensu więcej niż 8), w statystykach nie mam komunikatu, ze zabrakło kanałów nagrywających.
    Czyli w najdroższym rozwiązaniu dla własnej centrali wychodzi zwrot po 5 miesiącach. A w przypadku najkorzystniejszym miesiąc.
    Gdzie ta konkurencyjność cenowa?

    0
  • #11 06 Gru 2017 15:35
    Tomasz Robaczewski
    Poziom 4  

    Cena na stronie to jedno a cena końcowa to drugie - sprawa jest mocno indywidalna i zawsze mozna ponegocjować...

    Zapraszamy z konkretnym klientem to porozmawiamy, im będzie większy, tym bardziej Pan się pozytywnie zdziwi na koniec dnia :-)

    0
  • #12 06 Gru 2017 15:42
    krzybu
    Poziom 9  

    Konkurencyjność cenową można ocenić jedynie w ujęciu całościowym, więc zapraszamy do dyskusji konkretnego tematu biznesowego. W Pana kalkulacji nie są uwzględnione na przykład Pańskie koszta osobowe ;). Wiedza fachowa obecnie bardzo kosztuje... A cennik to punkt wyjścia do dalszej rozmowy!
    Faktycznie jest tak, że wybór chmura czy rozwiązanie własne-sprzętowe to kwestia preferencji i uwarunkowań lokalnych, rzadziej ceny. Chmura wygrywa, jeśli chcemy mieć łatwo, szybko, skalowalnie i jednego odpowiedzialnego za bezpieczeństwo i jakość usługi.
    Pozdrowienia
    Krzysztof

    0
  • #13 06 Gru 2017 16:01
    R-MIK
    Poziom 38  

    Tomasz Robaczewski napisał:
    sprawa jest mocno indywidalna i zawsze mozna ponegocjować...

    Z firmami oferującymi centrale także.
    Osobiście, dotychczas myślałem, że rozwiązania w chmurze są dobre dla małych firm, ale widzę, ze nie bardo mogę coś sensownego zaproponować klientowi, który chce zakupić centrlę 2/6.
    Zastanawia mnie także możliwość komunikacji własnej aplikacji z centralą, takie jak daje XML Slicana czy CTIP.

    0
  • #14 06 Gru 2017 17:21
    krzybu
    Poziom 9  

    Chmura NFON oferuje różniste API, najłatwiej jednak integrować się na poziomie stacji roboczej przez tzw. CTI, np. poprzez standardowe protokoły uaCSTA.
    Wtedy mamy możliwość wywoływania akcji w aplikacjach czy przeglądarkach na bazie numeru telefonu oraz click-to-call.

    0
  • #15 06 Gru 2017 18:30
    R-MIK
    Poziom 38  

    krzybu napisał:
    Chmura NFON oferuje różniste API, najłatwiej jednak integrować się na poziomie stacji roboczej przez tzw. CTI, np. poprzez standardowe protokoły uaCSTA.
    Wtedy mamy możliwość wywoływania akcji w aplikacjach czy przeglądarkach na bazie numeru telefonu oraz click-to-call.

    Protokoły CTI sa dość ograniczone, dam konkrety przykład.
    Czy mogę otrzymać informacje o nr, który mnie wywołuje, jaki nr wybrał w stanie RING. W razie potrzeby, takie połączenie mogę, przekierować na konkretny nr, grupę, odrzucić, przekierować na zapowiedź czy cos innego. Jak tego nie zrobie, to połaczenie trafia na standardowy scenariusz (ivr, grupę)?

    0
  • #16 06 Gru 2017 18:49
    TechEkspert
    Redaktor

    Puszczenie całego ruchu przez łącze internetowe w relacji lokalizacja-chmura to założenie projektowe, które nie pozwoli zoptymalizować ruchu wewnętrznego/internetowego w firmie mającej np. w budynku 300 słuchawek, ale znacząco upraszcza konfigurację urządzeń brzegowych oraz umożliwia m.in np. łatwą realizację centralnego nagrywania. Założenie projektowe nie jest ani złe ani dobre, zwyczajnie będzie lub nie zgrywać się ze stawianymi wymaganiami.

    Natomiast co do redundancji i kosztów to jak zwykle sprawa jest względna.

    Np. w centrali IP obsługującej dużą firmę lub nawet klika oddziałów redundantne zasilanie, interfejsy sieciowe oraz np. HDD pracujące w RAID to standard, ale w przypadku małych prostych central typu kilkanaście-kilkadziesiąt linii wewnętrznych i kilka linii miejskich analog/BRA rozwiązania redundantne do rzadkość.
    Taka prosta centrala posiada zwykle transformatorowy zasilacz + płyta główna + kilka kart - potrafi pracować bezawaryjnie kilkanaście lat i w tym segmencie cenowym dodatkowe skomplikowanie konstrukcji nie jest potrzebne.

    Takie małe centrale mogą być zarządzane przez przeszkolonego pracownika (znaczące obniżenie kosztów) a w małych firmach BRA może być wystarczające i bardzo efektywne kosztowo. Przy większej ilości kanałów SIP trunk lub PRA świadczony po IP na bramie medialnej (np. brak IP iwyłącznie interfejs PRA w starej centrali) lub PRA na parze miedzianej także daje dobrą cenę w stosunku do możliwości.
    Co do niezawodności prostych central istnieje pewna pułapka, często centrala jest tak bezobsługowa że osoba która potrafiła zarządzać centralą już dawno nie pracuje, laptop z zainstalowanym oprogramowaniem i "kabelek" do programowania został już dawno wyrzucony a kart do centrali nie można już kupić u producenta od kilku lat. Nikt nie wykupuje wsparcia zewnętrznego gdyż kosztować będzie tyle co nowa centrala o tych samych lub lepszych parametrach. Rozpiętość funkcjonujących rozwiązań jest od konfiguracji centrali przez CLI poprzez WEB po starsze rozwiązania z interfejsem UART (lub w nowszej wersji USB<->UART) + program do konfiguracji, który nie koniecznie uruchomi się np. na Windows10...
    Problem występuje gdy zapomniana centrala ulegnie uszkodzeniu i jej wymiana na nową + konfiguracja zajmie sporo czasu.

    Są firmy gdzie nie buduje się wewnętrznych działów technicznych i wszystko jest outsorcowane, wtedy warto konsolidować usługi,
    podobnie przy firmach często zmieniających położenie biura lub potrzebujących częstej zmiany ilości zasobów tam usługi chmurowe mogą być optymalne.

    0
  • #17 06 Gru 2017 20:48
    krzybu
    Poziom 9  

    Co do CTI, prawda, nie temu ma służyć. A-number based routing to już domena zaawansowanych systemów call center, też mozna w chmurze. Firmy za to zwykle używają w tej roli ludzkiego recepcjonisty, wtedy mamy rzeczywisty substytut AI i jeszcze filtr antyspamowy!

    0
  • #18 06 Gru 2017 21:05
    R-MIK
    Poziom 38  

    krzybu napisał:
    Co do CTI, prawda, nie temu ma służyć. A-number based routing to już domena zaawansowanych systemów call center, też mozna w chmurze. Firmy za to zwykle używają w tej roli ludzkiego recepcjonisty, wtedy mamy rzeczywisty substytut AI i jeszcze filtr antyspamowy!

    Miałem na myśli konkretny przypadek. Klient ma 3 grupy klientów, zwykli (oni moga telefonować np 8:00 - 18:00), z umowa serwisową (8:00 - 22:00) i VIP (cała doba). Kazda grupa ma dostępne inne numery miejskie, nr wywołujacego jest w bazie z znacznikiem jak kategoria (chodzi oczywiscie o tych z umowa serwisową i VIP). Naturalnie, dopisywanie nr jest przez strone www. Da się to zrobic na NFON? Klien ma centrle o niewielkiej pojemności, na pewno nie więcej niż 20 nr, miał jednak takie życzenie, na Slicanie mu to zrobiłem.

    0
  • #19 06 Gru 2017 23:03
    TechEkspert
    Redaktor

    Ciekawe i nietypowe wykorzystanie listy numerów jako dostępu dla klientów VIP. Pytanie czy można zrobić IVR pytający o numer klienta, w zależności od podanego numeru może kierować na nagranie zgłoszenia, lub na grupę HG pracowników.

    0
  • #20 06 Gru 2017 23:20
    R-MIK
    Poziom 38  

    TechEkspert napisał:
    Ciekawe i nietypowe wykorzystanie listy numerów jako dostępu dla klientów VIP. Pytanie czy można zrobić IVR pytający o numer klienta, w zależności od podanego numeru może kierować na nagranie zgłoszenia, lub na grupę HG pracowników.

    Innemu klientowi robiłem takie cos tez na Slicanie ale nie XLM-em tylko WEB-API (jakos tak Slican to nazwał).
    - zgłasza sie zapowiedź pyta o id klienta
    - po wpisaniu nr pyta o pin
    - jeśli ok, to łączy z jakąś tam grupę, jeśli żle to jeszcze 3 próby, jak złe to konsultant (w godzinach pracy) lub zapowiedź "sorry Gregory....".
    Coś tam jeszcze było z CLIP, jak rozpoznał to nie trzeba było wpisywać id i pin.
    To API-WEB działa z dowolnym serwerem z PHP, nie ma dużo możliwości ale łatwo sie to robi i serwer nie musi być w sieci lokalnej (praktycznie dowolny serwer w chmurze). W tym rozwiazaniu, centrala Slican wysyła zapytania do serwera, w XML zarówno centrala jak i serwer może wysyłać zapytania.
    Robiłem też jakis bajer, że z poziomu strony www mozna było wybierac nr, takie CTI przez WWW. Teraz nie ma to sensu, bo w Slicanie jest taka funkcjonalność, zdaje sie płatna (ja mam wszystko za free).

    0
  • #21 07 Gru 2017 14:39
    szwagros
    Poziom 29  

    Niestety to rozwiązanie (i w ogóle voip) jest zależne od sieci klienta i jego urządzeń. Mnóstwo miałem przypadków niesłyszących się rozmówców, nielogujących się aparatów itp, większość spowodowana tym że router nie bardzo radził sobie z pakietami SIP. A najczęstszy przypadek to chyba wiszące sesje na Mikrotiku których nie widać w conntracku, co skutkuje natowaniem na błędny port.
    Jeśli VOIP, to tylko dedykowana sieć IP.

    0
  • #22 07 Gru 2017 14:48
    krzybu
    Poziom 9  

    Wydzielona sieć IP niszczy zalety oszczędnościowe VoIP/SIP. Po prostu sieć IP musi być odpowiednio zaprojektowana, łącznie z ustawieniami firewall'a.
    Dziś firmy stosują kilka metod:
    a) nadmiarowe pasmo załatwia sprawę (najczęstsza metoda przy łączach fiber)
    b) dedykowane VLANy pod VoIP
    c) QoS pod VoIP
    Wydzielonych sieci praktycznie się nie spotyka...

    0
  • #23 07 Gru 2017 15:13
    szwagros
    Poziom 29  

    krzybu napisał:
    Wydzielonych sieci praktycznie się nie spotyka...

    Dlatego opinia o voip jest jaka jest. Idąc z ofertą do jakiejś firmy o wiele łatwiej jest sprzedać usługę nazywając ją Telefonią Cyfrową niż Telefonią Voip...

    0
  • #24 07 Gru 2017 15:31
    R-MIK
    Poziom 38  

    szwagros napisał:
    krzybu napisał:
    Wydzielonych sieci praktycznie się nie spotyka...

    Dlatego opinia o voip jest jaka jest. Idąc z ofertą do jakiejś firmy o wiele łatwiej jest sprzedać usługę nazywając ją Telefonią Cyfrową niż Telefonią Voip...

    Znana i "lubiana" przez wszystkich firma Elektronix, reklamuje swoje małe centrale MSX i MINI jak współpracujące z ISDN BRA. Nie znalazłem kart ISDN więc spytałem czy tylko MSN czy także DDI, to otrzymałem informację, że przez porty analogowe w NT :-) Z VoIP jest jak widzę podobnie, bo jak zapytałem o COLP, to dowidziałem sie, że nie wspierają. No właśnie, czy NFON wspiera COLP?

    0
  • #25 07 Gru 2017 16:01
    szwagros
    Poziom 29  

    R-MIK napisał:
    No właśnie, czy NFON wspiera COLP?

    Protokół SIP to umożliwia (patrz rfc4916). Większym problemem byłoby chyba znalezienie telefonu voip to obsługującego.

    0
  • #26 07 Gru 2017 17:06
    R-MIK
    Poziom 38  

    szwagros napisał:
    Protokół SIP to umożliwia (patrz rfc4916)

    GSM też, a operatorzy nie dają takiej funkcjonalności. Poruszałem ten temat na Elektrodzie. Podobnie CW dla łączy ASS, możliwość istnieje, operatorzy nie udostępniają.

    0
  • #27 07 Gru 2017 21:21
    krzybu
    Poziom 9  

    szwagros napisał:
    krzybu napisał:
    Wydzielonych sieci praktycznie się nie spotyka...

    Dlatego opinia o voip jest jaka jest. Idąc z ofertą do jakiejś firmy o wiele łatwiej jest sprzedać usługę nazywając ją Telefonią Cyfrową niż Telefonią Voip...

    100% prawda, nazwa VoIP nie oddaje oferty wirtualnej telefonii internetowej i ma nienajlepsze skojarzenia.

    0
  • #28 08 Gru 2017 11:36
    Tomasz Robaczewski
    Poziom 4  

    R-MIK napisał:
    ... No właśnie, czy NFON wspiera COLP?


    Tak, oczywiscie tylko wewnatrz PBX, czyli np. GSM dzwoni do NFON, po dowolnej ilości transferów wewnątrz PBX, aktualnie rozmawiający z nim wewnętrzny NFON widzi na wyświetlaczu swojego telefonu numer GSM.

    Dodano po 3 [minuty]:

    R-MIK napisał:
    ...Innemu klientowi robiłem takie cos tez na Slicanie ale nie XLM-em tylko WEB-API (jakos tak Slican to nazwał).
    - zgłasza sie zapowiedź pyta o id klienta
    - po wpisaniu nr pyta o pin
    - jeśli ok, to łączy z jakąś tam grupę,...


    Damy radę i w NFON :)

    0
  • #29 08 Gru 2017 12:10
    R-MIK
    Poziom 38  

    Tomasz Robaczewski napisał:
    R-MIK napisał:
    ... No właśnie, czy NFON wspiera COLP?


    Tak, oczywiscie tylko wewnatrz PBX, czyli np. GSM dzwoni do NFON, po dowolnej ilości transferów wewnątrz PBX, aktualnie rozmawiający z nim wewnętrzny NFON widzi na wyświetlaczu swojego telefonu numer GSM.

    Widzę, ze nie bardzo Pan wie co to COLP. COLP to prezentacja nr osiągnietego.
    Przykładowo telefonuję na nr stacjonarny, tam jest przeniesienia np na komórkę. Dochodzi do połączenia ale nie ze stacjonarnym tylko z komórka, na wyswietlaczu nr który wybrałem (stacjonarny) zostaje zastąpiony nr komórkowym (tym, z którym faktycznie sie połączyłem). Inny przykład, nr AUS, telefonuje po taksówkę na 19xxx, to połaczenie jest płatne, widzę jednak że prawdziwy nr (AUS to "aliasy" do rzeczywistych nr) to np 221234567. Kolejnym razem wybiore 221234567 bo mam to w opłacie abonamentowej.
    Nie wiem jaki nr teram ma BluLine, ale kiedyś prawdziwy nr to 800xxxxxx gdzie w xxxxxxx były takze cyfry A, B, C, D.

    0
  • #30 08 Gru 2017 12:24
    Tomasz Robaczewski
    Poziom 4  

    COLP możemy interpretować zależnie, czy patrzymy "w przód" czy "wstecz".
    W NFON, opcja "wtecz" działa - zawsze widzimy numer, z którym aktualnie rozmawiamy a nie numer kolegi, który do nas połączenie przekierował.

    ..ale to zreszta nieważne, gdyż z opisu widze, że Panu chodzi o COLP międzysieciowy najwyraźniej, aby np. zoptymalizowac koszty zamawiania taksówek w firmie :-)

    0
TME logo Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME
TME Logo