- Milyen okostelefont vegyek?
- OnePlus 7 - magabiztos folytatás
- Huawei P30 Pro - teletalálat
- Itt az első kép a 2024-es Nokia 3210-ről
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Samsung Galaxy A55 - új év, régi stratégia
- iPhone topik
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Digitális detox a Nokiától
Hirdetés
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
Samsung Univerzum: Így ismerhető meg a Galaxy AI bármilyen telefonon
ma A Try Galaxy webalkalmazás kontrollált környezetben mutatja meg, mit tud a One UI 6.1-es rendszer és a mesterséges intelligencia.
-
Agyi chipes gyártóba fektetett a kriptocég
it A Tether 200 millió dollárt fektet a Blackrock Neurotech agyi chipes vállalatba.
-
Mobilarena
VoIP
Új hozzászólás Aktív témák
-
VaZso
senior tag
Hasonlóképpen már én is jártam, bár én callback-et soha nem használtam náluk.
Ellenben saját Asterisk-re kapcsolódva indítottam hívást valamelyik efféle szolgáltató felé.
Közben a kapcsolatom megszakadt az Asteriskkel és lett egy pártíz perces hívásom belőle, amit kiszámláztak. Ha jól rémlik, ez is egy teszthívás volt - a vonal másik fele nem volt hosszasan tartva.
(Azt hiszem, le is nullázta ezzel a maradék pénzemet a fiókban, bár nem volt már sok.)Utánajártam kicsit a dolognak és az Asterisk logjában meg is találtam ezt a hívást.
Van egy opció a konfigurációs fileokban, hogy RTP/RTCP aktivitás hiányában szakítsa meg a kapcsolatot X másodpercet követően.Ez megoldotta a problémám (teszteltem direkt megszakított kapcsolattal és valóban eldobta a hívást ezután, míg előtte ez nem történt meg).
Azóta egyszer sem történt ilyen esemény (nem volt túlzott híváshossz) és ez majd' egy éve történt.
Ezzel csak arra szeretnék kilyukadni, hogy úgy tűnik, a callback megoldásukból is hiányzik valami efféle timeout érték. Pl. kíváncsi lennék, egy nem normál úton lekapcsolt mobilkészülék (pl. akksi kivétele) útján megszakadt vagy egyéb módon, de nem normális úton lebontott kapcsolat esetén vajon meddig számlázzák a hívást.
Szerintem itt lehet hiba a rendszerükben. -
VaZso
senior tag
Szerintem van egy rendszerük + weboldal (amit mindenhol használnak), az oldalhoz (vagy n oldalhoz?) tartozó ügyfélszolgálat néhány betanított emberrel, hogy ne keltsen teljesen elhagyatott érzést.
Sem e-mail, sem telefonszám, semmi közvetlen elérhetőség... egyiknél sem.
Átmegy rajtuk egy rakat hívás naponta és meglehetősen kis haszonnal dolgoznak.
Ha apróbb problémád van, talán segítenek, de sokat nem lehet várni tőlük.Ők is több útvonalon keresztül irányítják a hívásokat - vagy kiszámlázzák nekik is a kifogásolt hívásokat, vagy nem...
...mindenesetre nem szakemberekkel beszélsz, csak alap alkalmazottakkal (akikkel az itthoni ügyfélszolgálatokon is csak vergődsz, ha komolyabb problémád van) - aki nem fogja azt mondani, hogy a rendszer hibája. Valójában nem is tud utánanézni.Van olyan hívás is, amit kiszámláznak megtörténtnek, de mégsem jött létre, mert mondjuk csak kicsörgött a túloldal (és lesz belőle mondjuk 30 másodperc leszámlázva). Ez kb. olyan, mintha csinálnék egy Asterisk szervert, ami továbbadja a hívást, de közben felveszi a vonalat (tehát nem csak akkor épül fel a hívás, amikor a hívott felvette a telefont, hanem már előtte - akár csak a hagyományos, házi telefonközpontok esetén).
Ez nem az ő hibájuk, hanem a "beszállító" rendszere vacak (olcsó?) /és ez esetben nekik is számláz/, mégis az ő ügyfelük bosszankodik miatta.Én is jeleztem nekik korábban hasonló (túlszámlázás) problémákat, csak széttárták a karjukat... tény, hogy sok az ügyfél, kevés a haszon (egy percre vonatkoztatva), de azért bizalomromboló, viszont az alacsony ár "kompenzál" valamelyest.
...szóval nem annyira egyszerű a helyzet mint amilyennek elsőre tűnik.
Ők is csak közbenső szolgáltató - akár a Skype normál hívásai -, akik megpróbálják a legolcsóbb, de elfogadható minőségű útvonalat használni a híváshoz.
Talán egyedül ezt van értelme jelenteni, mármint ha adott időpontban a hívás kritikán aluli volt, mást kapcsolt (jó szám esetén), ilyesmi - panaszra kizárhatják a problémás útvonalat és így jobb lehet a minőség. Ezt képesek megcsinálni, ha pénzt nem is írnak jóvá.Az időben párhuzamos hívásokat úgy vettem észre, engedik, csak nem szeretik.
Mármint az első hívást normál áron számlázzák, a másodiknak viszont nem tudom a tarifáját - többet vonnak le érte.
Gondolom, nem szeretnék, hogy az ember továbbértékesítse magasabb áron.Nekem azért volt érdekes, mert szerettem volna családtaggal közös fiókot használni, de erről letettem a kiszámíthatatlan, magasabb árazás miatt.
------------
Amúgy a hülyének nézés általános ezeknél a cégeknél.
Ebay ugyanez pepitában - hülyének nézik az embert, ha ők a hunyók valamiben és mellébeszélnek.
Kriminális banda az is, a legrosszabb fajtából.[ Szerkesztve ]
-
VaZso
senior tag
-
VaZso
senior tag
Én sem ismerek ilyent, de végeztem egy gyors keresést és ezt találtam: Peers.
Nem állítom, hogy iszonyatosan nagy tudású program, de saját Asterisk-hez tudtam vele kapcsolódni és a hívás működött is rajt (mindkét fél hallatszott).
Hívni is lehetett - bár csengőhang nem jött ki a torkán, a hívást jelezte és fel is tudtam venni vagy visszautasítani.Bár gondolom, nem egészen ilyesmit keresel...
Tehát ha saját gépre be lehet állítani, akkor nyilván FVD-re is - legalábbis ha ismeri a G711 codecet vagy amit esetleg még ez a program ismer...
[ Szerkesztve ]
-
VaZso
senior tag
Asteriskkel mindent be lehet konfigurálni, amit egy telefonközpontnak tudnia kell.
"kérdésem, hogy be lehet ezt úgy configolni, hogy ha pl. érkezik egy telefonhívás a saját számomról és utána lenne még egy másik szám is megadva, akkor ezt dekódolva a freevoipdeal-lel, létesítenék egy phone2phone-t?"
Az "utána még egy másik szám" alatt mit értesz?
Elvileg a telefonoknál meg lehet adni ilyen p/w várakozást, ez normál hívás közben is működik ("bejátssza").
Ilyen alapon továbbtárcsázhat, persze.
Enélkül is megteheti, tehát ad egy tárcsahangot és hívsz valakit.
...csak jól kell beállítani, hogy azért más ne hívhasson össze-vissza....de normál callback-et is lehet csinálni vele, tehát adott készülékről rácsörögsz, az visszahív, bekér egy kódot (vagy számod alapján azonosít), majd bepötyögöd a hívandó számot - de lehet még cifrázni.
Ámbár kicsit bele kell ásni magad hozzá, ha nem ismered.
Nem ötperces dolog azért... -
VaZso
senior tag
Lehet még olyan oka is, hogy a telefon energiatakarékossági okból kifolyólag visszaveszi az órajelet alacsonyabb szintre, de nem marad így elég tartaléka és az órajel felkapcsolása is időbe telik (túl hirtelen nő meg a terhelés).
Tehát azért, mert beszélgetés közben a terhelés nem folyamatos, hanem ingadozik és a rendszer nem tudja elég dinamikusan követni a codec szükségleteit.
Esetleg nézz körül, van-e olyan program, amivel be tudod ezt állítani a beszélgetés idejére (akár fix értékre) és próbáld ki úgy is - szerintem fogsz találni ehhez segédprogramot.
Az eredményt azért írd le majd.(Ja és ez természetesen az akkumulátoros időre negatív hatással lehet, különösen, ha beszélgetés után is úgy marad...)
Talán azzal is elérsz valamit, ha valamilyen programot futtatsz még, ami dolgozik közben.
-
VaZso
senior tag
Attól is függ, mire lassítanak.
10 kbyte/s már bőven elég lenne, 5 kbyte/s még talán, alatta azért már szinte semmire sem jó.
Valójában még böngészésre sem használható, ha megnézzük egyes - gyakran látogatott - oldalak által elpazarolt adatmennyiséget. Persze tömöríteni és szűrni azt is lehet, de még így sem igazán nő a használhatóság 0 fölé.Ami a VoIP beszélgetés sávszélesség-igényét illeti, SIP helyett IAX-szel kellene próbálkozni hozzá.
...csak IAX kliens nem sok van.
Szolgáltató oldalon sincs általában támogatása, de Asterisk (nem véletlenül) kezeli, így azt közbeiktatva a probléma áthidalható lenne.Sőt - egyéb problémákra is jó lenne a kisebb adatfelhasználás mellett.
[ Szerkesztve ]
-
VaZso
senior tag
Mármint 32/32 kbit/s, nem pedig kbyte/s.
Vagyis ez elméletben 4 kbyte/s lenne - ez pedig nem alkalmas SIP-es beszélgetésekre.Ami azt illeti, nálam a Vodafone számlálása és a programom értékei egyeztek (bár mostanában nem fizettem elő mobilnetre). Könnyen lehet azért, hogy a programod sem tökéletes (és pl. rendszer frissítéseit valamiért nem számolja), de lehet a szolgáltató problémája is, nem tudom.
-
VaZso
senior tag
válasz atillaahun #2255 üzenetére
"És nálam továbbra is a hihetetlen kategóriába mennek azok a történetek, hogy ezt mások hetekig hónapokig használják rendszeresen mobilnetről megbízhatóan jó minőségben."
Pedig nem hihetetlen, csak több dologtól is függ.
Többek között:
- A készüléktől, amit használsz
- A hálózati kapcsolat minőségétől (sebességétől, terheltségétől, válaszidejétől)
- A használt szolgáltatás minőségétől (terheltségétől, válaszidejétől, az ő alszolgáltatóitól ill. azok minőségétől)Azért itt is figyelembe kell venni, hogy "olcsó húsnak híg a leve".
Amíg a szolgáltatók általánosan 10 Ft környékén kérnek el a bejövő hívásokért percenként, addig 3 Ft-os percdíj nehezen kivitelezhető még akkor is, ha a percalapú hívás révén valamekkora összeg "visszajön". (Persze nem tudom, milyen mennyiségi megállapodások vannak köztük, de kétlem, hogy hasonló árszintig mennének le.)...de azért általánosságban ezek a szolgáltatások egész normális minőségben szoktak működni normális minőségű kapcsolatot használva.
Amikor én próbáltam, még mobilnetről is tökéletes volt (igaz, közvetve ment hozzájuk a vonal).A mobilszolgáltatókat azért hagyjuk ki ebből, mert megpróbálják ezt korlátozni.
Ellenben wlan-ról működnie kell, ha jó a hálózatod és a szolgáltató sem kritikán aluli.Időnkénti hibák azért benne vannak a pakliban ennél a szolgáltatónál (és alszolgáltatóinál), ez sajnos igaz - de az callback-nél is meglesz.
Másfelől ha kicsit drágább oldalt használsz, valószínűleg korrektebb szolgáltatókon át megy a hívás is, kevesebb problémád lesz.[ Szerkesztve ]
-
VaZso
senior tag
válasz sumsang #2268 üzenetére
Igen, de a háttérinfrastruktúrát nem látjuk.
A SIP hívás elvileg átirányítható, tehát megoldhatják azt, hogy adott gép, adott IP-n fogadja a kéréseket, de a kiszolgálás egy másik címen történik a terheltség és földrajzi eloszlás alapján (vagy akár más szempontok alapján) pl.
Márpedig ez is fontos lehet, ugyanis a Föld egyes tájai között elég szép többletkésleltetést kap a vonal (és a hívottnál - pl. mobilszolgáltatók oldalán - is van egy késleltetés) és egy nagy szolgáltatónak ezt is illene megoldania... tehát a felhasználóhoz minél közelebb célszerű elhelyezni a központot, ill. annak adott gépét.
-
VaZso
senior tag
válasz atillaahun #2273 üzenetére
Valójában ezzel úgy jársz a legjobban, ha veszel egy helyi feltöltős kártyát és azt hívja a callback...
Ha a magyar számodat felhívja valaki mialatt külföldön tartózkodsz, a beszélgetés roaming díját te fizeted - akár egy itthoni számról hívtak, akár a callback funkció tette ezt (a magyar szolgáltató szerződik a külföldi szolgáltatóval és adja át a hívást a saját kezelésében lévő számhoz a külföldi partnernek - egyáltalán ezért enged fel ez a fél a hálózatára).
-
VaZso
senior tag
válasz atillaahun #2275 üzenetére
Azt a díjat fizeted, amit egy normál hívásfogadással is kifizettet veled a szolgáltató külföldön.
-
VaZso
senior tag
válasz atillaahun #2285 üzenetére
...hát ha Skype megy, vélhetően a SIP-es telefonhívás is menni fog.
Szerintem...Amúgy ha nagyon nem megy a mobiloddal, először próbáld más készüléken rendbe tenni a hívást (mondjuk egy PC-n).
Pl. Windows alatt X-Lite vagy Linux alatt Twinkle.Ha itt sem jó, más gond lesz (pl. router, net terhelése).
Időnként sajnos találkozni olyan telefonkészülékkel, amin elég vacakul mennek ezek a programok, ez is lehet ok... és a teszthez is több hívást célszerű indítani, mert néha ezek az olcsó szolgáltatások is vackok. -
VaZso
senior tag
válasz sumsang #2286 üzenetére
Különbség lehet feltöltőkártyás és előfizetéses készülékre rendelt internet csomag beállításai között.
Nekem a gépemen a telefonszámhoz *99# van írva (bár mintha ez sem számítana), az összes többi mező (APN-nel együtt) nincs kitöltve.
Egy másik gép azonos beállításokkal pár héttel ezelőtt vígan csatlakozott a netre előfizetéses T-mobil kártyával....de az ügyfélszolgálatnak is mondania kell rá valamit.
Mindenesetre nem olyan bonyolult a beállítás, ha jól sejtem... -
VaZso
senior tag
Hmm, ez enyhén érdekes...
Egyfelől az én jelenlegi tarifacsomagom nem "megszűnt" kategóriába esik, hanem "lezárt tarifa" címen fut.
Itt viszont évekkel ezelőtti csomag nagy számban található.Ha ezeket egy füst alatt törölnék, az csúnya dolog lenne...
...ám én kaptam egy ilyen SMS-t tőlük pár hete:"Tisztelt Ügyfelünk! 2012.12.17-től módosul az ÁSZF, egyidejűleg az ÁSZF 1. mellékletében található feltöltő kártyás alaptarifa díjait számszerűen is feltüntetjük az Előfizetői Szerződés Alapvető díjszabás, a díjszámítás alapja pontjában is. Ez a jelenleg Ön által használt tarifacsomag díjaiban nem jelent változást. A módosítás felmondási jogot nem keletkeztet. Információ: www..."
(Kiemelés tőlem.)Na most ha később ennek ellenére törölnék és bevágnák az "alap tarifacsomagot" az ember elé, azért szép "gesztus" volna tőlük.
Mindamellett úgy vélem, a jelenleg aktív tarifacsomagokat nem szeretné a szolgáltató egy "konténerbe" helyezni mint eddig, tehát minden ma aktív tarifacsomagra érvényes lehet a fenti.Ez egyfelől nem szimpatikus számomra, másfelől az ilyesformán papírra vetett, majdan a (régen meglévő, mondhatni hűséges) ügyfél felé számlázandó összeg véleményem szerint "enyhén" inkorrekt tőlük. Mi több, RABLÁS!
Azért ezt nem gondoltam volna... így kell az ügyféltől minél több pénzt lehúzni!?
-
VaZso
senior tag
-
VaZso
senior tag
Én a szoftveroldali tömörítésre gondoltam.
VoIP (SIP) esetén pl. G.711 (u-law, a-law), G.722, G.729, Speex, GSM, iLBC, SILK, stb. codec-eket (coder-decoder) is lehet használni, ezek más-más paraméterekkel bírnak. Sávszélesség-igény tekintetében is.
Ha jól tudom, Skype is megcsinálja, hogy más algoritmust használ (kép átvitelére pl.), ha lassabb hálózaton használod (vagy legalábbis más paraméterekkel működik). Viszont a mobilnet relatíve gyors, ellenben jellemzően meglehetősen korlátos is.
Egyébiránt audio forgalmat másképpen tömöríteni nem volna bölcs elképzelés, ugyanis annak minél inkább valósidejűnek kell maradnia. Márpedig minden tömörítés késleltetést is pakol a folyamatba.
(Hardverigényesebb codec esetén a lassú kódolás is okozhat plusz késleltetést, de nem erre gondolok.)
No meg nem véletlenül megy ez a típusú kommunikáció alapvetően UDP protokoll használatával.Másik a csomagvesztés: VoIP-nél alapvetően a csomagvesztés elfogadottabb dolog mint a késleltetés.
Mondhatnám, hogy ez még többé-kevésbé megengedett / belefér (és van is, a hagyományos GSM kommunikációban is van).
Némely codec a fentiek közül kifejezetten hibatűrő, tehát nem esik kétségbe némi csomagvesztésen, míg másikon nagyon meghallod.[ Szerkesztve ]
-
VaZso
senior tag
válasz egánede #2313 üzenetére
Symbianos telefonnal egyszer vacakoltam, végül sikerült működésre bírnom a saját SIP-kliensével.
Beállítás után abszolút tökéletesen működött - jobban mint az Android megoldása (bár lehet, azóta javítottak rajt) és kb. úgy, ahogy az N900-nál is....de beállítani vacak volt (konkrétan az összes készüléknél rosszabb).
Szerintem érdemes próbálkoznod, mert alapvetően jól össze van rakva ez a funkció a rendszeren (pl. ezzel visszhangos sem volt), csak ezekkel a hülyeségeivel kell foglalkozni előbb.
(Igaz, saját géppel teszteltem, tehát ebben a szolgáltató problémái nem hallatszottak... de hívtam vele másik mobilt is /ezt Dellmont rendszeren keresztül/ és abszolút jónak találtam.
A tesztgép másik hálózatban volt, tehát nem szimplán csak LAN-on működött.)Telepíteni kellett hozzá egy kiegészítést (ez lesz a kulcs) + jól megadni minden beállítást.
Ezt az utat járd ki, mert sokkal boldogabb leszel vele mint bármilyen másik megoldással. -
VaZso
senior tag
Nekem az iLBC "jött be" a legjobban.
Minősége egész jó, emellett viszonylag kicsi a sávszélesség-igénye.Telefont jobban terheli, de bírja az. - annak ellenére, hogy azért már nem a legújabb.
Átviteli hibákra viszonylag érzéketlen.Tehát ha a szolgáltató támogatja (és szempont a relatíve alacsony sávszélesség-igény), tapasztalatom szerint az a legjobb. (Nagyjából két perc per MB rémlik, ill. kicsivel MB alatt.)
---------------------
Ami a berregő csengőhangot illeti - ezt már többször írtátok...
Ez nem hiba, teljesen normális csengőhang... csak nem Magyarországon.
pl. Angliában, normál hívásnál is alapesetben mindig ezt hallod és nem ugyanazt mint ami itthon jellemző.Inkább az a baj, hogy a szolgáltató bizonyos alszolgáltatói (trunk-jei) elég vackok (nyilván olcsóak) és néha ezeket is "bekeveri" a híváshoz.
A másik dolog, hogy normális esetben a hívott rendszeréből kapod vissza a csengést, a fenti pedig még azelőtt csenget, hogy azt kapcsolta volna (így megnyugtatva, hogy folyamatban van a hívás).
Persze úgy csenget, amit beállítottak neki... és az nem a magyar csengetés.
Hátulütője, hogy nem hallod így a "pillanatnyilag nem elérhető" vagy ehhez hasonló hálózati üzeneteket, sem pedig az egyedi csengőhangokat.
A jobb szolgáltatók (trunk-ök / útvonalak) ezt is átadják, max. pár másodperccel később kezdi a kicsörgést (amikor a valóságban is megtörténik).Tehát a csengőhang jó, a szolgáltatóban van a hiba.
-
VaZso
senior tag
Erre írtam az útvonal (trunk) minőségi prolémáit... és nem csak T esetén lehet.
pl. vezetékes irányban is tapasztaltam olyat, hogy némelyik szolgáltató vacak útvonalon adja át a hívást.pl. számátadási és hangminőség problémák is voltak
Sőt, ezeknél az olcsó útvonalaknál időnként olyan is előfordult, hogy magyar csengőhangot hallottam, de nagyon zajosan... és jellemzően ilyenkor már csengetéskor is számolt.
Amúgy más-más irányokban (1 / 20 / 30 / 70) más-más útvonalat is választhat a szolgáltató, amik között hívásonként is lehet eltérés. Ill. vedd figyelembe, hogy sajnos ez az "olcsó hús" esete... cirka 3 Ft/perc áron senki sem fog konstans jó minőségű vonalat adni, sajnos ez a hátulütője... különösen, ha az itthoni szolgáltatók egymás között cirka 10 Ft/perc díjakat számolnak fel, ami kétlem, hogy kevesebb volna külföld irányából.
A legjobb, amit tehetsz, hogy feljegyzed a vacak hívásokat, összeveted a szolgáltató híváslistájával és jelented a szolgáltatónak. Normális esetben azt az útvonalat kiszedik, amivel problémásak a hívások (és sokszor előfordul az ilyesmi).
Bár felet, ~3 Ft/perc áron ezzel nem foglalkoznak - "ezt kell szeretni" eset -, más (drágább) márkájuknál meg lehetett csinálni.[ Szerkesztve ]
-
VaZso
senior tag
Milyen codec-et preferál a telefonod és mit ismer a szolgáltató?
Nekem EDGE-vel is tökéletesen működött iLBC-n, de sávszélesség-igényesebb codec nem biztos, hogy használható lesz...
Nekem úgy rémlik, Dellmont nem támogat iLBC-t (legalábbis régebben nem ment vele), ellenben GSM-et igen.Tehát javaslat: változtass a codec-prioritáson és próbáld újra.
Hívásminőség valószínű, változni fog (GSM-et nem találtam túl jónak pl.).Mondjuk nem tudom, milyen ez a "nem indul el" a hívás... azért a hívást el kellene indítania, max. a hangátvitellel kellene gondnak lennie.
[ Szerkesztve ]
-
VaZso
senior tag
Nem kizárt, hogy a szolgáltató manipulál valamit.
pl. az 5060-as adatkommunikációs port elérését tiltja, így amikor a készülék hívni próbál, nem kap választ a szolgáltatótól....mondjuk korlátozott nettel meg kiengedi, mert úgysem mész vele semmire.
Esetleg az is elég, ha véletlenszerűen vagy átengedi a hívást vagy nem - így téve használhatatlanná a VoIP-ot az ügyfél számára.
Nem tudom, az 5060-as port tiltásakor hogyan viselkedik a Symbian SIP megoldása.
-
VaZso
senior tag
Igen, az az alapértelmezett kommunikációs port - ha nem adod meg, azt használja automatikusan.
A hangkommunikáció egyébként nem itt zajlik, annak (az RTP kommunikációnak) van egy magasabb tartomány... viszont itt kommunikálja le a hívást és az ezzel kapcsolatos üzeneteket, ill. az RTP kommunikáció portszámát is.
Ha ezt letiltják, elérhetetlenné válik a szolgáltatás.
[ Szerkesztve ]
-
-
VaZso
senior tag
"más telók más sip portot használnak"
Ez nem így van. Az alapértelmezett SIP kommunikáció mindig ugyanazon a porton megy, telefontól függetlenül. Az ezen a porton bejövő kommunikációt a SIP szolgáltató beengedi a hálózatba és kezeli, "figyel rajta".
Lehet más porton vagy más porton is elérhető, de ebben az esetben a kliensnél meg kell adnod a portszámot hozzá. Ezt általában meg lehet tenni, az Android alap SIP klienssel is tudja.
Magyarul az alapértelmezett 5060-as port 5060-as marad, amíg másként nem rendelkezel (a szolgáltatóval karöltve, persze).
[ Szerkesztve ]
-
VaZso
senior tag
"Feltételezem, hogy a Nokia gyári SIP támogatása szabványos (...), így ezt könnyű korlátozni. A kerülő, vagy nem teljesen szabványos megoldásokat nehezebb."
Nincs nem teljesen szabványos, kerülő SIP megoldás.
Max. olyan kliens lehet, amiben vacakul implementálták a funkciót.
Portszámot mindegyiknél lehetett eddig változtatni, itt nem a SIP megoldás kerülő......de kétlem, hogy ez lenne a gond.
Ez a GoNet nálad melyik csomag? Én inkább azt gondolnám, hogy nem mindig / mindenhol / mindenkinek / minden csomagot / minden előfizetést korlátoz a szolgáltató.Nimbuzz az teljesen más, hozzád nem SIP-en jön már a hang.
Szerk.: A Nokia gyári kliensében pedig alapvetően tiltva van a 3G VoIP telefonálás a szolgáltatók miatt.
Bár ha Telenorral ment, gondolom, ezt már megoldottad.[ Szerkesztve ]
-
VaZso
senior tag
"hónapokkal ezelőtt még működött,,,,aztán egyik napról a másikra "megszünt" működni"
No igen, ez lesz a szolgáltatói korlátozás...
"Mobilvoip viszont ugyanezzel a csomaggal hibátlanul"
Nos a MobileVoIP egy külön kliens, bedrótozott beállításokkal (ha jól tudom persze).
Nem kötelező neki SIP protokollt, sem szabványos portot, sem egyéb szabványos megoldást használni.Azért emlegetem pl. az IAX protokollt, mert kevesebb a probléma vele mint SIP-pel és kisebb a sávszélesség-igénye is... csak kevés kliens képes használni.
Bár azt nem hinném, hogy a MobileVoIP is ezt használná persze.Legegyszerűbb eset az volna, ha egyszerűen más portot használ a kapcsolat felépítésére.
Meg kellene nézni, milyen forgalmat generál és akkor kicsit okosabb lenne az ember ezen a téren...Mégegy kulcsszó, ami különbséget jelenthet: STUN szerver használata.
-
VaZso
senior tag
A java VM azért a SIP-nél bonyolultabb szerintem, ill. két teljesen külön dolog.
A java egy programozási nyelv, a SIP pedig egy protokoll - bár azért az is szerteágazóbb dolog.Nimbuzznál azért számlázhatott, mert Dellmontnál figyelik az adott IP-ről indított hívásmennyiséget és bizonyos mennyiség fölött számláznak - és itt nem a te telefonod kapcsolódik SIP protokoll segítségével a szolgáltatóhoz, hanem a Nimbuzz szervere (tehát mások is használják / használták ugyanazt az IP-t telefonálásra).
Valami nagyon furcsa dolog lehet nálad, ha T-s netről közvetlenül nem megy, de másik telefonról megosztva (tehát közvetetten) igen... ha máskor próbálod, ill. közvetlenül utána kicseréled a kártyát és megpróbálsz SIP-en hívni, akkor is fennáll a jelenség? Tehát ezt "üzembiztosan" produkálja?
[ Szerkesztve ]
-
VaZso
senior tag
válasz pinnacle #2421 üzenetére
Nem, én ezt így fordítanám:
"Vagy a szolgáltató blokkolja a bejövő hívásokat, vagy legalább 5 egymást követő sikertelen hívás volt (utóbbi esetben az első sikeres hívás visszaállítja a státuszt zöldre)."
Ezt mi / hol írja egyébként?
Szerintem egyszerűen azt jelzi, hogy az utóbbi min. 5 hívás mind sikertelen volt, tehát valahol hiba lehet. Vélhetően telefonszolgáltatói blokkolásra gondolnak.
-
VaZso
senior tag
Hmm, ezt "látni" kellene, azt hiszem.
Akár azt, hogy mit lát ilyenkor a szolgáltató a kommunikációból, akár azt, hogy milyen forgalmat próbál / tud (vagy éppen nem) a telefon bonyolítani.A számhordozás nem kellene, hogy ezt befolyásolja, a szolgáltatónak ezt ugyanúgy kell kezelnie mint bármelyik másik számát.
Esetleg nem T-függő volt ez a telefon korábban?
[ Szerkesztve ]
-
VaZso
senior tag
Azon a másik telefonon nem tudod megpróbálni a SIP-et?
Egyébiránt ezen a telefonon nincs egyéb gondod a net eléréssel?
Bármi... időnként többször kell betölteni egy oldalt, akadozik a forgalom, bármi.
Vajon pl. az MTU rendben van? (Erre kíváncsi lennék mondjuk...)"de hogyan tehet különbséget mobilnet és mobilnet közt?"
Szerintem nem igazán kellene különbséget tegyen, ráadásul úgy, hogy _ugyanazon_ a mobilneten egyik elrendezésben megy, másikban nem.
Egyszerűen nem látom az okát.
Tehát másik telefonról NAT-olva jó, közvetlenül pedig nem jó... mintha valami hálózati probléma lenne vagy pl. egy "rejtett kód", ami T esetén ellehetetleníti a VoIP-ot - de ugye gyárilag független telefon miért szórakozna ilyennel.Esetleg a T-nek van valami furmányos megoldása, hogy telefonon korlátozni igyekszik a SIP-et, de azt megosztva (és pl. asztali gépről használva) már engedné?
Nem tudom, mire gondoljak...
Esetleg csinálj egy próbát mondjuk egy asztali op. rendszeren beállított SIP klienssel, miközben a vacakolós telefonról osztod a netet neki. Így megy a hívás?
-
VaZso
senior tag
válasz pinnacle #2426 üzenetére
A szolgáltató kimenő vonalainak problémái nem lesznek benne, viszont adott esetben akár két mobilnettől függ a vonal stabilitása... szóval fene tudja a minőséget.
Egyébként ez a user@sip.xxx sok esetben ill. több szolgáltatónál is működik, de egyébként beállítás kérdése - van olyan, amelyiknél nincs ilyen lehetőség.
-
VaZso
senior tag
válasz sumsang #2429 üzenetére
Kezdetben az volt az általános ezeknél a szolgáltatóknál, hogy user@szerver címmel el lehetett érni a regisztrált felhasználókat külső, tőlük független szolgáltatótól is. Más kérdés, hogy normál telefon irányba nem feltétlen volt átjárás egyiknél sem.
Az egyik első ilyen ingyenes szolgáltató talán az FWD / Pulver volt, de idővel ez is fizetőssé vált - ha jól nézem, '98 folyamán.
A jelenlegi szolgáltatók közül a legtöbben már egyenesen "tiltják" ezt a lehetőséget - ne az ő szerverüket terheld vele (adatforgalom, ha szükséges, codec fordítás + esetlegesen elmaradt haszon).
Eszerint Dellmonték ezt úgy oldották meg, hogy a saját rendszerükön belül legyen átjárás, ill. rendszeren belül hozzá is rendelik az adott telefonszámot.
Ez szép tőlük - habár én a náluk regisztrált fiókjaimnál nem szoktam "regisztrálni" a szerverre, épp' a bejövő hívások elvi hiánya miatt - csak hívásindításkor épül fel a kapcsolat.Amúgy szerver oldalon be lehet állítani gyakorlatilag bárhogyan a működést.
-
VaZso
senior tag
Hmm - érdekes, amit írsz. Erről lehet valahol olvasni?
Amúgy valóban a 443-mas az a port, amit a legnehezebben tudnak szűrni és általában engedélyezni kell, mert sok weboldal - köztük pl. a Gmail is - enélkül nem működik.
Más kérdés, hogy ez elvileg TCP 443-as port, a VoIP-nak pedig leginkább az UDP volna megfelelő.
Persze át lehet küldeni a forgalmat TCP-n is, de a késleltetést növeli, így az ember komfortérzete csökken (különösen rossz kapcsolat esetén, hibátlanon azért nem akkora gond).Akkor viszont valószínűsítem, hogy nem szabvány megoldást használ, vagy valamelyik relatíve szabványos megoldás (pl. IAX, mert az elég egyszerű hozzá) van becsomagolva HTTPS forgalomként.
-
VaZso
senior tag
Értem, köszönöm.
Én még nem is láttam ezt a programot, csak képen.
Speciel nincs most kéznél sem Android, sem Symbian, sem Blackberry, sem pedig Windows Phone, amire fel tudnám tenni...
Mindenesetre ez egy "3rd-party" programnak tűnik, tehát hozzájuk (eszerint Svédországba) érkezik HTTPS-en, majd onnan talán SIP-en mehet tovább Dellmontékhoz.
Legalábbis a felhasználónál ez nem SIP kapcsolat.
Új hozzászólás Aktív témák
● Olvasd el a téma összefoglalót!
● Nyílt egy topic a komolyabb kérdéseknek, ezentúl ott beszéljetek erről:
VoIP - mélyvíz
- Főzőcskés topic
- gban: Ingyen kellene, de tegnapra
- OLED TV topic
- Kínai, és egyéb olcsó órák topikja
- Politika
- Háztartási gépek
- Formula-1
- A pápa egyre jobban tart a romlott AI veszélyeitől
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- További aktív témák...