Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

[Rozwiązano] LTE z modemami huaweii z PLAY/T-mobile błąd VoIP

Oryginal_DekeR 13 Kwi 2018 12:38 2166 42
  • #1 13 Kwi 2018 12:38
    Oryginal_DekeR
    Poziom 17  

    Witam,
    od początku kwietnia część moich Klientów skarży się na brak rejestracji konta VoIP, bądź brak audio w obie strony - czy Koledzy mają podobne problemy z VoIP na LTE w tych sieciach?

    Używają routerów tp-linków i huawei, ale nie tutaj widzę problem, wielokrotnie prawidłowo konfigurowałem takie urządzenia dla LTE i VoIP.

    Na infoliniach obu operatorów uzyskuję różne informacje:
    -mamy awarie
    -porty komunikacji VoIP zostały chwilowo zablokowane ze względów bezpieczeństwa
    -w regulaminie jest napisane, że porty dla VoIP są na stałe zablokowane ze względów bezpieczeństwa
    - nie blokujemy portów dla VoIP

    Może Wy coś wiecie?

    0 29
  • Pomocny post
    #2 14 Kwi 2018 17:54
    jurek.adam
    Poziom 43  

    W Play nie masz publicznego IP więc zawsze jesteś za NAT. To już wystarczy, aby były problemy z VoIP. Jeśli operator udostępnia serwer STUN ustawiaj go klientom, to bardzo pomaga.

    Inne przydatne ustawienie to krótki czas na rejestrację (Registrar Expire) 30 lub 60 sek. Wtedy połączenie nie powinno być rozłączane przez "natownicę".

    2
  • Pomocny post
    #3 16 Kwi 2018 21:17
    jarek7714
    Poziom 15  

    jurek.adam napisał:
    W Play nie masz publicznego IP więc zawsze jesteś za NAT.
    Wyjaśnię bo widzę że kolega podaje nie precyzyjne informacje: w niektórych ofertach rzeczywiście jest wewnętrzny NAT operatora, w abonamencie internetowym, prepaid internet adres był publiczny (nie mylić z routowanym publicznym IP z dostępem z zewnątrz), jeżeli ktoś dziś korzysta może mnie poprawić.
    jurek.adam napisał:
    To już wystarczy, aby były problemy z VoIP.
    Nie wystarczy, sieci "mobilne" 3-4G w standardowej ofercie mają specyficzną konfigurację sieci (nawet gdy na WAN jest dostępny publiczny IP np. w Plusie, to klient bez wykupienia usługi dodatkowej nie dostanie się z zewnątrz na ten adres-ruch inicjowany z zewnątrz jest blokowany, nie mylić z przełożeniem tego wprost że jeżeli korzystamy z VoIP to do nas się nikt nie dodzwoni). Po prostu do takiej konfiguracji sieci musi być urządzenie końcowe z firmware które daje sobie z tym radę). W urządzeniach Huawei należy zwrócić uwagę aby była wyłączona funkcja
    Code:
     
    
    Ustawienia SIP ALG

    Urządzenie obsługuje funkcję SIP ALG. Aplikacja SIP po uruchomieniu umożliwia poprawną komunikację z innymi aplikacjami internetowymi.
    Włącz funkcję SIP ALG
    Port SIP:    5060
    , jeżeli korzystamy z modemów USB i routerów do ich obsługi polecam OpenWRT z tej strony https://www.ofmodemsandmen.com/firmware.html .
    jurek.adam napisał:
    Jeśli operator udostępnia serwer STUN ustawiaj go klientom, to bardzo pomaga.
    Średnio, zależy to od stosowanych urządzeń VoIP, wsparcie dla tego typu "podpórki" przez operatora SIP/VoIP.
    jurek.adam napisał:

    Inne przydatne ustawienie to krótki czas na rejestrację (Registrar Expire) 30 lub 60 sek.
    To akurat bardzo istotny czynnik do komunikacji przy SIP i sieciach 3-4G. Generalnie przy prawidłowej konfiguracji, prawidłowo działającym połączeniu 3-4G nie ma problemów z VoIP, nawet na darmowym BDI Aero2 (operatorzy nie stosują jakiś szczególnych obstrukcji, a nawet gdy jest wewnętrzny NAT, to nijak nie da się tego porównać do można powiedzieć amatorskiego sprzętu sieciowego stosowanego w naszych domach).

    1
  • #4 16 Kwi 2018 23:12
    jurek.adam
    Poziom 43  

    Konkretnie w Play - klient jest za NAT zawsze (jak skonfigurowanym to już inny temat), nie dostaje na swoim urządzeniu końcowym publicznego adresu, nie może otworzyć zewnętrznych portów, do Internetu, czyli 5060 oraz innych (do obsługi RTP itp.). W zależności od VoIP trzeba to niekiedy obchodzić. Po to STUN, by możliwe było przejście przez NAT. Np. Halonet, Ipcall, Actio, posiadają serwer STUN. Inni też zazwyczaj mają, ale nie zawsze się tym chwalą i trzeba pytać supportu. Jak działa bez STUN to dobrze, ale kiedy nie można logować się trzeba go użyć. SIP ALG, owszem nie ma zastosowania, domyślnie najczęściej jest wyłączone, a w innych przypadkach trzeba zrobić to ręcznie.

    Z praktyki wiem, że VoIP działa w Play (korzystam z Halonet, FCN, Betamax - bez STUN) - czas rejestracji ustawiłem na 60 sek, dzięki czemu nie mam problemu z połączeniami. Do kompletu dobrze mieć niski ping, poniżej 100ms.

    1
  • #5 17 Kwi 2018 09:03
    przeqpiciel
    Poziom 29  

    Skoro o VoIP mowa. Testowałem VoIP'a chyba na Play'u i żadna rejestracja nie chciała iść na port 5060, dopiero jak PBX'a w chmurze przestawiłem by gadał na innym, bardziej "kosmicznym" porcie to poleciało. Przez t sytuację mam wrażenie, że niektórzy GSM'owcy blokuj możliwość VoIP u siebie.

    0
  • #6 17 Kwi 2018 13:08
    jurek.adam
    Poziom 43  

    Z jakąkolwiek blokadą VoIP nie spotkałem się jeszcze. Problem najczęściej jest w konfiguracji urządzeń (jak pisał już jarek7714). Można łatwo zweryfikować, czy operator blokuje VoIP. Wystarczy smartfon z jakimkolwiek Androidem, ale bez doinstalowanego firewalla. Zainstalować na nim klienta VoIP, polecam CSipSimple, bo prosty i działa nawet na starych systemach:
    https://play.google.com/store/apps/details?id=com.csipsimple

    Jeżeli przy użyciu tej samej karty sim na smartfonie logowanie powiedzie się, a na modemie/routerze nie, to już wiadomo, gdzie szukać przyczyny.

    1
  • #7 17 Kwi 2018 13:13
    przeqpiciel
    Poziom 29  

    No u mnie był temat taki, że w OVH wisi Asterisk wystawiony na 5060. Odpalam jakikolwiek softphone i cisza w sygnalizacji po stronie Asteriska. Zmieniam 5060 na śmieszny port w postaci 35060 i bam. Sygnalizacja nagle dociera. Jesteś w stanie to wytłumaczyć ?

    0
  • #8 17 Kwi 2018 13:34
    jurek.adam
    Poziom 43  

    Nie jestem w stanie wytłumaczyć niczego jak nie znam przypadku konkretnie, użytego sprzętu, jego konfiguracji i nie robiłem testów.

    Co do samego Play, to zauważyłem, że działa też zarządzanie portami przez UPnP, co więcej cały czas przy tym majstrują z różnym efektem więc jeśli ktoś siebie w routerze to aktywuje sprawa może jeszcze się dodatkowo zagmatwać. Dlatego zalecam najpierw testy na czystym Androidzie, sprawdzić, czy klient rejestruje się i możliwe jest wykonywanie i odbieranie połączeń.

    Mam 3 takie konta u popularnych dostawców VoIP i bez znaczenia, którego operatora kartę użyję - logują się bez problemu via CSipSimple na Androidzie.

    1
  • #9 17 Kwi 2018 17:37
    jarek7714
    Poziom 15  

    jurek.adam napisał:
    Po to STUN, by możliwe było przejście przez NAT. Np. Halonet, Ipcall, Actio, posiadają serwer STUN. Inni też zazwyczaj mają, ale nie zawsze się tym chwalą i trzeba pytać supportu. Jak działa bez STUN to dobrze, ale kiedy nie można logować się trzeba go użyć.
    Generalnie ten STUN serwer jest do poprawienia sobie placebo (dziś nawet nie używany przez wszystkich operatorów SIP, wprowadzony w czasach gdy upload 128kbps[zapotrzebowanie na pasmo kodeka G711] było wyczynem w łączach internetowych, dodatkowo wielu klientów było schowanych za NAT, zmienne niestabilne opóźnienia, także występowała kumulacja niekorzystnych czynników: brak pasma, NAT, zmienne opóźnienia i STUN wówczas był dodatkowym wsparciem dla połączeń przychodzących).
    jurek.adam napisał:

    Z praktyki wiem, że VoIP działa w Play (korzystam z Halonet, FCN, Betamax - bez STUN) - czas rejestracji ustawiłem na 60 sek, dzięki czemu nie mam problemu z połączeniami.
    VoIP działa prawidłowo w każdej sieci macierzystej, RBM również i NAT nie robi tutaj "grubego" problemu-pod warunkiem że używamy na urządzeniu końcowym/bramie odpowiedniego softu obsługującego modem 3-4G, może być też oryginalny Huawei (z tym że tutaj trudniej odpalić jest dopalacze w postaci wymuszenia ciągłego ruchu w sieci-pingując hosta w sieci na OpenWRT
    Code:
     (while true; do ping google.com > /dev/null; sleep 3; done) & 
    https://eko.one.pl/?p=openwrt-3g . Przy takowym ustawieniu utrzymujemy stabilne połączenie z siecią (nawet gdy następuje odświeżenie adresu IP, to odbywa się to rzadko, a zazwyczaj wówczas występuje problem, a rozwiązuje go szybko restart urządzeń - raz na tydzień to nie problem). Osobiście używam Plfon, Ifon, Halonet i Happycall z tym że na publicznym IP, także działa to zupełnie bez obsługowo-ale do 2015 gdy miałem limity na LTE w Plusie, telefon miałem stale podpięty pod ofertę RBM na kartę.
    jurek.adam napisał:
    czas rejestracji ustawiłem na 60 sek, dzięki czemu nie mam problemu z połączeniami. Do kompletu dobrze mieć niski ping, poniżej 100ms.
    Krótki czas odświeżania rejestracji na serwerze to bardzo istotny parametr, natomiast co do opóźnień-to większe znaczenie ma stabilność opóźnień (zwłaszcza przy starszych urządzeniach VoIP) niż ich czas, pod warunkiem że ich czas mieści się poniżej 150ms (dekadę temu używałem VoIP z modemem Huawei E220-który dawał opóźnienia w przedziale 120-140ms, telefon działał bdb).
    przeqpiciel napisał:
    Przez t sytuację mam wrażenie, że niektórzy GSM'owcy blokuj możliwość VoIP u siebie.
    Niczego nie blokowali i nie blokują, tj. problem firmware urządzenia końcowego klienta które jest bramą do sieci.
    przeqpiciel napisał:
    No u mnie był temat taki, że w OVH wisi Asterisk wystawiony na 5060. Odpalam jakikolwiek softphone i cisza w sygnalizacji po stronie Asteriska. Zmieniam 5060 na śmieszny port w postaci 35060 i bam. Sygnalizacja nagle dociera. Jesteś w stanie to wytłumaczyć ?
    Tobie się tylko tak wydaje, portem zewnętrznym na którym następuje autoryzacja SIP i tak jest w 95% UDP 5060. Nic w tym nadzwyczajnego: stawiam router np. Asus WL500gp v1 wspierany przez różne softy i na jednych usługa będzie działać, a na innych nie, podobnie routery wspierane przez OpenWRT. P.S Port UDP5060 służy tylko do autoryzacji usługi, rozmowa/transmisja głosu odbywa się na portach UDP w przedziale 10000-20000, czasami nawet 10000-60000 np. HappyCall.

    0
  • #10 17 Kwi 2018 18:20
    jurek.adam
    Poziom 43  

    jarek7714 napisał:
    Generalnie ten STUN serwer jest do poprawienia sobie placebo (dziś nawet nie używany przez wszystkich operatorów SIP, wprowadzony w czasach gdy upload 128kbps[zapotrzebowanie na pasmo kodeka G711] było wyczynem w łączach internetowych, dodatkowo wielu klientów było schowanych za NAT, zmienne niestabilne opóźnienia, także występowała kumulacja niekorzystnych czynników: brak pasma, NAT, zmienne opóźnienia i STUN wówczas był dodatkowym wsparciem dla połączeń przychodzących).


    STUN nie jest placebo, a realnie potrzebną opcją nawet dziś. Przykład sieci kablowe niedające publicznego IP na końcowym urządzeniu, tak jest w niektórych lokalizacjach kablówek MM, Inea, Vectra, a ta ostatnia wręcz celowo wycina ruch VoIP poprzez konfigurację NAT/firewall na ich routerach. Nie da się zalogować nawet. Ratuje sytuację dopiero publiczne IP (tryb bridge, bo w router bez zmian), ale nie wszyscy klienci mogą mieć.

    Natomiast klienci operatorów mobilnych najczęściej nie mają urządzeń z OpenWRT tylko z softem producenckim (nie do każdego sprzętu da się wgrać alternatywę i nie każdy chce i umie), który nie zawsze pozwala na prawidłową obsługę VoIP więc głośno krzyczą o blokadach. Jak nie da się obejść problemów na danym urządzeniu/systemie to lepiej ustawić im STUN, żeby w ogóle działało.

    Dodano po 14 [minuty]:

    jarek7714 napisał:
    Krótki czas odświeżania rejestracji na serwerze to bardzo istotny parametr, natomiast co do opóźnień-to większe znaczenie ma stabilność opóźnień (zwłaszcza przy starszych urządzeniach VoIP) niż ich czas, pod warunkiem że ich czas mieści się poniżej 150ms (dekadę temu używałem VoIP z modemem Huawei E220-który dawał opóźnienia w przedziale 120-140ms, telefon działał bdb).


    Wiadomo, nie mogą ginąć pakiety, a ping nie może być jak huśtawka. Dla mnie łącze z pingiem powyżej 100 ms nie nadaje się do VoIP.

    1
  • #11 17 Kwi 2018 20:42
    jarek7714
    Poziom 15  

    jurek.adam napisał:

    STUN nie jest placebo, a realnie potrzebną opcją nawet dziś. Przykład sieci kablowe niedające publicznego IP na końcowym urządzeniu, tak jest w niektórych lokalizacjach kablówek MM, Inea, Vectra, a ta ostatnia wręcz celowo wycina ruch VoIP poprzez konfigurację NAT/firewall na ich routerach. Nie da się zalogować nawet. Ratuje sytuację dopiero publiczne IP (tryb bridge, bo w router bez zmian), ale nie wszyscy klienci mogą mieć.
    Jest-j.w stary mechanizm stosowany w innych realiach sieci, poza tym gdyby z premedytacją do tego podchodzili ISP to równie łatwo go wyciąć jak port autoryzacji SIP, gdyż działa głównie na porcie UDP3478. A problemem u ww dostawców są urządzenia końcowe operatora-modemo-routery których nie możemy podmienić, a ułomny soft nie daje sobie rady z prawidłową obsługą VoIP (ba są dostawcy którzy blokują dostęp do panelu konfiguracji). U dostawców mobilnych sprzęt dostarczany przez Huawei jest godny polecenia, innym czynnikiem na + jest wybór w telefonie IP/bramce VoIP kodeka G711/G711A.
    jurek.adam napisał:

    Wiadomo, nie mogą ginąć pakiety, a ping nie może być jak huśtawka. Dla mnie łącze z pingiem powyżej 100 ms nie nadaje się do VoIP.
    To małe masz doświadczenie z VoIP, ja używam kilkanaście lat (zakładałem łącze internetowe ze względu na co miesięczne rachunki po kilkaset złotych za rozmowy międzynarodowe), korzystałem z ok. 10 operatorów SIP (do 2010 roku nie było też "różowo" z dostawcami VoIP-urządzenia i łącza nie dawały sobie rady z obsługiwanym ruchem). Z VoIP korzystają nawet klienci ISP vi satelita, co jest nie lada wyczynem, przy opóźnieniu nawet 140ms jeżeli będzie stabilne klient na urządzeniu końcowym nie usłyszy żadnych uchybień w działaniu usługi, a może takowe usłyszeć jeżeli ping będzie skakał np. z 15ms do 150ms. Przy tym niższym pingu natomiast urządzenie udźwignie większą stratę pakietów (korzystam/korzystałem z LTE Plus/Play/Orange i na żadnym z nich nie spotykam się z gubieniem pakietów, nawet 2-3 lata wstecz na dojechanym internecie Play w LTE1800 takie zjawisko nie występowało-spadał transfer, ewentualnie zrywana była całkowicie sesja, dziś to już przeszłość, gdyż nadajniki tego operatora działają w 4 pasmach i aż takich problemów nie ma).

    0
  • #12 17 Kwi 2018 21:13
    jurek.adam
    Poziom 43  

    jarek7714 napisał:
    Jest-j.w stary mechanizm stosowany w innych realiach sieci, poza tym gdyby z premedytacją do tego podchodzili ISP to równie łatwo go wyciąć jak port autoryzacji SIP, gdyż działa głównie na porcie UDP3478. A problemem u ww dostawców są urządzenia końcowe operatora-modemo-routery których nie możemy podmienić, a ułomny soft nie daje sobie rady z prawidłową obsługą VoIP (ba są dostawcy którzy blokują dostęp do panelu konfiguracji). U dostawców mobilnych sprzęt dostarczany przez Huawei jest godny polecenia, innym czynnikiem na + jest wybór w telefonie IP/bramce VoIP kodeka G711/G711A.


    Kablówki mają podobne usługi w ofercie, taka Vectra blokuje dostęp do każdego routera, ale nawet jak go uzyskałem, to nie udało mi się uruchomić VoIP, mimo publicznego IP na nim. Tylko w bridge działa. To nie firmware blokuje, a głównie konfig kablówki jaki wysyłają do routera. STUN nie musi być nowinką, ważne, że działa w takich przypadkach i to wystarczy. Podobnie w mobilnym - blokuje router, jak nie da się tego przeskoczyć to użyć STUN i po sprawie.

    Dodano po 10 [minuty]:

    jarek7714 napisał:
    To małe masz doświadczenie z VoIP, ja używam kilkanaście lat (zakładałem łącze internetowe ze względu na co miesięczne rachunki po kilkaset złotych za rozmowy międzynarodowe), korzystałem z ok. 10 operatorów SIP (do 2010 roku nie było też "różowo" z dostawcami VoIP-urządzenia i łącza nie dawały sobie rady z obsługiwanym ruchem). Z VoIP korzystają nawet klienci ISP vi satelita, co jest nie lada wyczynem, przy opóźnieniu nawet 140ms jeżeli będzie stabilne klient na urządzeniu końcowym nie usłyszy żadnych uchybień w działaniu usługi, a może takowe usłyszeć jeżeli ping będzie skakał np. z 15ms do 150ms. Przy tym niższym pingu natomiast urządzenie udźwignie większą stratę pakietów (korzystam/korzystałem z LTE Plus/Play/Orange i na żadnym z nich nie spotykam się z gubieniem pakietów, nawet 2-3 lata wstecz na dojechanym internecie Play w LTE1800 takie zjawisko nie występowało-spadał transfer, ewentualnie zrywana była całkowicie sesja, dziś to już przeszłość, gdyż nadajniki tego operatora działają w 4 pasmach i aż takich problemów nie ma).



    Co z tego, że działa. Nie będę nikogo na siłę przekonywał, dlaczego ping <100ms jest dla mnie kluczowy. Po protokole UDP nie ma retransmisji danych jak po TCP więc stabilny, niski ping to podstawa. Zresztą nie każdemu musi zależeć na super jakości, niektórym nawet metaliczne przydźwięki, echa, przycinki też nie przeszkadzają. Takim nawet łącze satelitarne wystarczy.

    Na LTE może szczególnie nie giną pakiety, ale ping potrafi czasami skakać do dość wysokich wartości.

    2
  • #13 18 Kwi 2018 18:12
    jarek7714
    Poziom 15  

    jurek.adam napisał:

    Kablówki mają podobne usługi w ofercie, taka Vectra blokuje dostęp do każdego routera, ale nawet jak go uzyskałem, to nie udało mi się uruchomić VoIP, mimo publicznego IP na nim. Tylko w bridge działa. To nie firmware blokuje, a głównie konfig kablówki jaki wysyłają do routera. STUN nie musi być nowinką, ważne, że działa w takich przypadkach i to wystarczy. Podobnie w mobilnym - blokuje router, jak nie da się tego przeskoczyć to użyć STUN i po sprawie.
    O ile się tym nie zgadzam, to zastosowanie tego mechanizmu nikomu nie zaszkodzi, zwłaszcza jak operator SIP/urządzenie VoIP wspiera jego obsługę.
    jurek.adam napisał:

    Co z tego, że działa. Nie będę nikogo na siłę przekonywał, dlaczego ping <100ms jest dla mnie kluczowy. Po protokole UDP nie ma retransmisji danych jak po TCP więc stabilny, niski ping to podstawa. Zresztą nie każdemu musi zależeć na super jakości
    Raz głupoty piszesz, dwa wprowadzasz potencjalnych użytkowników w błąd-poczytaj sobie trochę o transmisji głosu i kodekach VoIP https://yadda.icm.edu.pl/baztech/element/bwme...httpwww_itl_waw_plczasopismatiti20041-267.pdf , przeczytałeś gdzieś przypadkowo zalecenia operatora SIP (asekuracja aby w razie problemów z jakością winę sprzedać klientowi). Jak nie wiesz z kim masz do czynienia, to nie pisz że nie zwracam uwagi na jakość-która jest wyższa na moich telefonach IP od średniej w sieciach mobilnych (przez pierwsze 2 lata korzystania z VoIP to była walka z jednej strony z ISP odnośnie jakości łącza, z drugiej wymiana operatorów SIP którzy nie potrafili utrzymać jakości). Poza tym dawno temu ze względu na jakość wymieniłem Linksysa i Grandsream na urządzenia Polycom i używam tylko kodeków G711,G711A.
    jurek.adam napisał:

    niektórym nawet metaliczne przydźwięki, echa, przycinki też nie przeszkadzają. Takim nawet łącze satelitarne wystarczy.

    Na LTE może szczególnie nie giną pakiety, ale ping potrafi czasami skakać do dość wysokich wartości.
    Makabra co Ty wypisujesz- po olbrzymich obniżkach cen połączeń międzynarodowych w ciągu ostatnich kilku lat u operatorów komórkowych, nie ma dziś "ciśnienia" na usługi VoIP, także klienci nie są wstanie zaakceptować takich fantazji o których wypisujesz. Co do pingu w LTE-jeżeli połączenie z siecią ma właściwe parametry, to działa bardzo stabilnie, nawet np. w Łodzi na najbardziej obciążonej sieci Plusa
    Code:
    ping elektroda.pl
    




    PING elektroda.pl (104.108.39.193): 56 data bytes
    64 bytes from 104.108.39.193: icmp_seq=0 ttl=52 time=34.004 ms
    64 bytes from 104.108.39.193: icmp_seq=1 ttl=52 time=45.849 ms
    64 bytes from 104.108.39.193: icmp_seq=2 ttl=52 time=41.730 ms
    64 bytes from 104.108.39.193: icmp_seq=3 ttl=52 time=45.513 ms
    64 bytes from 104.108.39.193: icmp_seq=4 ttl=52 time=40.322 ms
    64 bytes from 104.108.39.193: icmp_seq=5 ttl=52 time=45.276 ms
    64 bytes from 104.108.39.193: icmp_seq=6 ttl=52 time=40.041 ms
    64 bytes from 104.108.39.193: icmp_seq=7 ttl=52 time=44.721 ms
    64 bytes from 104.108.39.193: icmp_seq=8 ttl=52 time=39.750 ms
    64 bytes from 104.108.39.193: icmp_seq=9 ttl=52 time=46.041 ms
    64 bytes from 104.108.39.193: icmp_seq=10 ttl=52 time=44.980 ms
    64 bytes from 104.108.39.193: icmp_seq=11 ttl=52 time=43.967 ms
    64 bytes from 104.108.39.193: icmp_seq=12 ttl=52 time=42.883 ms
    64 bytes from 104.108.39.193: icmp_seq=13 ttl=52 time=41.937 ms
    64 bytes from 104.108.39.193: icmp_seq=14 ttl=52 time=40.822 ms...                                                                                                                                                             64 bytes from 104.108.39.193: icmp_seq=2227 ttl=52 time=44.007 ms
    64 bytes from 104.108.39.193: icmp_seq=2228 ttl=52 time=43.369 ms
    64 bytes from 104.108.39.193: icmp_seq=2229 ttl=52 time=40.867 ms
    64 bytes from 104.108.39.193: icmp_seq=2230 ttl=52 time=38.907 ms
    , na przeszło 2 tys. pakietów ani jednego zagubionego, 1-szt trzy cyfrowa 108ms, u konkurencji np. w Play na 2100MHz/2600MHz będą o połowę niższe.

    0
  • #14 18 Kwi 2018 18:47
    jurek.adam
    Poziom 43  

    ...ciach
    Ping działa po protokole diagnostycznym (ICMP), a VoIP głównie po UDP, jak już chcesz swoje wyniki zamieszczać to wykonaj testy po UDP. Mogę takie testy, które udowodnią przeciwną tezę tutaj wkleić, ale to nie ma sensu, bo wszystko zależy od lokalizacji, obciążenia nadajnika i paru innych czynników więc kategoryczne stawianie tez świadczy o wąskiej wyobraźni.
    ...ciach

    1
  • #15 18 Kwi 2018 19:55
    przeqpiciel
    Poziom 29  

    Nie UTP a UDP. I przestancie sie drapac laski. 😁

    0
  • #16 18 Kwi 2018 20:13
    jurek.adam
    Poziom 43  

    Racja, poprawiłem i ciachnąłem, żeby nie zaogniać.

    0
  • #17 20 Kwi 2018 16:03
    Oryginal_DekeR
    Poziom 17  

    Mhm, ciężko się do Waszej Koledzy dyskusji wplątać, ale postaram się odnieść do poruszanych kwestii:
    NAT - w przypadku moich Klientów zawsze jest NAT, nie tylko dla tych sieci

    SIP ALG - zawsze wyłączam, do tej pory to własnie rozwiązywało problem

    czas rejestracji - standardowo ustawiam 5 minut, teraz obciąłem do 1 minuty

    OpenWRT - nie zajmuję się zmianą firmware routerów Klientów

    uciachany panel www - polscy operatorzy maniakalnie wywalają opcje, dobrze że obecnie SIP ALG zostawiają na wierzchu, bo jeszcze 2 lata temu musiałem Klientom kazać zmieniać, żeby się do tego dobrać

    port SIP - mój system działa na 5060 i nie będę tego zmieniał

    STUN server - bardzo pomocny, w wielu przypadkach rozwiązuje mój problem [nie na aktualnych problemach LTE]

    Może podsumuję czego próbowałem dla bramki voip przy LTE:
    -Handle VIA received/rport
    -insert VIA received/rport
    -keep alive
    -STUN
    -DMZ
    -port forwarding

    niektóre ustawienia powodują rejestrację urządenia w systemie na 5060, ale nie ma audio, niektóre wrzucają jakiśdziki port, także nie ma audio

    dzięki za zainteresowanie tematem, czekam na kontakt od pomocy technicznej operatorów.

    1
  • #18 20 Kwi 2018 16:36
    jurek.adam
    Poziom 43  

    Z jakich operatorów VoIP korzystają Twoi klienci?

    0
  • #19 20 Kwi 2018 16:51
    przeqpiciel
    Poziom 29  

    Czy jak nie miales audio to spogladales do SDP w celu diagnostyki?

    1
  • #20 23 Kwi 2018 16:02
    Oryginal_DekeR
    Poziom 17  

    Głównie actio, kilku fcn - wszystko śmigało świetnie, aż na początku kwietnia rypło :(
    W logach komunikacja przychodziła nawet na te magiczne porty, ale nie podtrzymywałem nic zwrotnie. Jak pisałem powyżej wykonywałem kilka prób i szczerze już nie pamiętam co jaki efekt w logach dawało, żeby Wam opisać - teraz już komunikuję się z techniczną tmobile i play, jak dojdziemy do rozwiązania dam znać.

    0
  • #21 23 Kwi 2018 17:39
    makosuu
    Specjalista Sieci, Internet

    jurek.adam napisał:
    taka Vectra blokuje dostęp do każdego routera, ale nawet jak go uzyskałem, to nie udało mi się uruchomić VoIP, mimo publicznego IP na nim. Tylko w bridge działa.


    Bo Vectra nie daje publicznego IP w trybie router, tzn. jest coś w stylu podwójnego NAT, pomimo że IP WAN routera jest publiczny to jest inny niż ten pod którym widać z internetu.

    0
  • #22 23 Kwi 2018 18:58
    jurek.adam
    Poziom 43  

    Vectra daje publiczne IP w trybie router (nie w każdej lokalizacji), problem w tym, że to nic nie zmienia, bo VoIP i tak nie działa prawidłowo. Ten "dziwny" adres, o którym piszesz nie jest publiczny lecz z puli 100.X.X.X. Tylko w bridge z zewnętrznym IP VoIP działa bez problemu. Dobrze, że przynajmniej nie robią problemu z przełączeniem na bridge.

    Dodano po 1 [minuty]:

    Oryginal_DekeR napisał:
    Głównie actio, kilku fcn - wszystko śmigało świetnie, aż na początku kwietnia rypło :(



    FCN działa w Play/RBM/Fakt, korzystam. Actio nie wiem.

    1
  • #23 24 Kwi 2018 00:13
    jarek7714
    Poziom 15  

    Oryginal_DekeR napisał:

    STUN server - bardzo pomocny, w wielu przypadkach rozwiązuje mój problem [nie na aktualnych problemach LTE]

    Może podsumuję czego próbowałem dla bramki voip przy LTE:
    -Handle VIA received/rport
    -insert VIA received/rport
    -keep alive
    -STUN
    -DMZ
    -port forwarding

    niektóre ustawienia powodują rejestrację urządenia w systemie na 5060, ale nie ma audio, niektóre wrzucają jakiśdziki port, także nie ma audio

    dzięki za zainteresowanie tematem, czekam na kontakt od pomocy technicznej operatorów.
    Uściślijmy STUN serwer służy tylko do poprawy połączeń przychodzących (poprawi sytuację w małych sieciach LAN, gdzie na bramie jest publiczne IP, a dalej klienci go już nie mają, w przypadku sieci 3-4G bez routowanego/publicznego IP z dostępem z zewnątrz nie wiele wnosi (ustawić razem z keep alive i tyle), DMZ i port forwarding jest bezskuteczne. Najistotniejszym czynnikiem jest prawidłowe/właściwe działanie zapory NAT w sofcie routera (ja z tym walczyłem lata temu gdy nie miałem możliwości dostępu publicznego IP na LTE w Plusie/Play i wystarczyło podmienić soft w routerze i po problemie, na oryginalnych Huawei też nie było dramatu, ale ww OpenWRT i Oleg wymiata, nie wiem jak działa DD-WRT z modemami 3-4G, lecz w przypadku sieci ethernet do VoIP to bardzo zacne firmware).

    0
  • #24 24 Kwi 2018 06:59
    przeqpiciel
    Poziom 29  

    Tak patrzę na te Wasze posty i się zastanawiam. Czy jak mieliście problem z jakimkolwiek połączeniem to zaglądaliście do SDP? Bo cały czas wychwalanie tego STUN'a ani razu nie użyłem, zawsze zmiana była grana po stronie PBX i to lata.

    1
  • #25 24 Kwi 2018 07:54
    jurek.adam
    Poziom 43  

    Owszem, testować można różne rzeczy. W tym wątku chyba chodzi głównie o ustalenie, czy operator blokuje ruch VoiP i pisałem jak można to łatwo sprawdzić, smartfon w łapę i test połączenia przez prostą aplikację. Działają przychodzące/wychodzące - nie ma blokady.

    Czyli problem musi być po stronie sprzętu/firewalla skoro dopiero z nimi coś nie działa. Pozostaje zmiana konfiguracji/firmware. Czasami z różnych przyczyn jest to niemożliwe. STUN to nie jakiś super cymes, po prostu bywa czasem ostatnim kołem ratunkowym jak w ogóle nie idzie się zalogować (brak rejestracji).

    1
  • #26 24 Kwi 2018 23:27
    jarek7714
    Poziom 15  

    jurek.adam napisał:
    STUN to nie jakiś super cymes, po prostu bywa czasem ostatnim kołem ratunkowym jak w ogóle nie idzie się zalogować (brak rejestracji).
    STUN nie ma nic wspólnego z logowaniem się konta VoIP na serwerze SIP (z reguły port serwera SIP to UDP5060). STUN pomaga jednie w lokalizacji urządzenia w sieci IP i usprawnieniu działania zapory sieciowej NAT. W przypadku sieci 3-4G występują z reguły problemy na bramie NAT klienta używającego konkretnego firmware (ze względu na szczególną specyfikę sieci-blokada ruchu inicjowanego z zewnątrz). Na zalogowanym koncie VoIP mogą występować w skutek tego takie problemy: konto zalogowane lecz po wybraniu nr telefonicznego nie jest zespolone połączenie z nr telefonicznym, dwa-działają połączenia wychodzące ale telefon jest głuchy na połączenia przychodzące lub połączenie jest nawiązane lecz rozmowa jest urywana (dotyczy to obu rodzajów połączeń).

    0
  • #27 25 Kwi 2018 08:21
    jurek.adam
    Poziom 43  

    Są lepsze definicje w sieci: https://www.3cx.pl/voip-sip/stun-server/

    Cytat:
    STUN serwer umożliwia kilentom znalezienie ich adresu zewnętrznego, typu NAT-u używanego w ich sieci, oraz portu po stronie Internetu zasocjowanym przez NAT z lokalnym portem. Te informacje są następnie użyte w celu ustanowienia komunikacji UDP (ang. User Datagram Protocol – Datagramowy Protokół Użytkownika) pomiędzy kilentem a operatorem VOIP i przez to ustaleniem połączenia.


    Dodano po 28 [minuty]:

    jarek7714 napisał:
    Generalnie ten STUN serwer jest do poprawienia sobie placebo
    Co innego pisałeś o tym "placebo":
    https://trzepak.pl/viewtopic.php?f=16&t=48024&p=402434&hilit=stun#p402434


    jarek7714 napisał:
    Jak nie wiesz z kim masz do czynienia
    Ja nie wiem, ale inni od dawna wiedzą, służę linkiem, żebyś mógł sprostować tam, gdzie i opinia:
    https://trzepak.pl/viewtopic.php?f=16&t=42675&hilit=jarek7714

    I jeszcze jedno, podobnie jak użytkownicy tamtego forum nie mam ochoty na dyskusję z Tobą.

    2
  • #28 25 Kwi 2018 10:59
    jarek7714
    Poziom 15  

    jurek.adam napisał:

    I jeszcze jedno, podobnie jak użytkownicy tamtego forum nie mam ochoty na dyskusję z Tobą.
    Vice versa, natomiast nie mogę zostawić bez echa faktów nie mających nic wspólnego z działaniem VoIP na sieciach mobilnych. Skoro zadałeś sobie tyle trudu aby szukać moich postów na Trzepaku (ludzi którzy walczą o swoją "miskę ryżu" i kąsają jak im ucieka, a wielu ta miska "uryny" uciekła w wyniku mojego przedstawiania faktów), to trzeba było poszukać postów na forum Play z 2014/2015 roku-tam również jest odpowiedź dlaczego takowe połączenia działają w specyficzny sposób (w ówczesnym real-time).

    0
  • #29 25 Kwi 2018 16:10
    jurek.adam
    Poziom 43  

    Oryginal_DekeR napisał:
    Głównie actio, kilku fcn


    FCN cały czas mam na swojej bramce, obecnie korzystam głównie RBM5 z DIL. wszystko gra. Dziś też miałem okazję ustawiać Actio na Drayteku i również bez przeszkód działa w Play.

    1
  • #30 30 Kwi 2018 13:17
    radko_str
    Poziom 10  

    Jurek.adam
    Hejka
    ja też używam RBM z bramką VOIP Siemensa.
    Niestety od kwietnia mam problemy, wcześniej było wyśmienicie.
    Teraz ja mogę dzwonić i rozmowa jest czasami przerywana po 1 minucie 30 sek.
    Czasami można rozmawiać dłużej do 10 min
    Mój operator to happycall. Play sprawdzał konfiguracje numeru komórki i według nich wszystko w porządku.
    Happycall twierdzi że to firewall play'a.
    możliwości dodzwonienia się do mnie nadal brak.
    Moja bramka to Siemens A510, router dwr-116.
    Proszę opisz konfigurację swojego konta VOIP bardziej szczegółowo.
    Może masz jakąś konkretną radę.

    PS
    Przy włączonym serwerze STUN mam sygnał połączenia ale niestety nie ma głosu. Cisza w słuchawce.

    0