Analoge telefonie weghalen voor VOIP

[JonasRetro]

Hey,

Ik heb even jullie mening nodig.

Het gaat over een klein bedrijfje waar wat analoge telefoons stonden met analoge telefooncentrale.
Maar door een mankement van Proximus werkt de analoge telefonie tijdelijk niet...
Er moeten techniekers komen (komende week pas)
Proximus had dit eerst doorverbonden naar de GSM maar dit was zeer onhandig omdat er slechts 1 toestel was.

Dus als noodoplossing liet ik gewoon een simpele OVH lijn (voor €1,20) opstarten (en draaien we hier MikoPBX) en een analoge gateway.
Nadien liet ik Proximus gewoon de lijn doorschakelen naar die OVH lijn.

Nu dit bevalt eigenlijk prima, en overwegen we dus dit permanent zo te laten en over te stappen naar VOIP.

Maar het ding is er zijn wat puntjes waarop ik moet letten,

- Meerdere oproepen tegelijk zou praktisch zijn, eventueel 2 zou al gemakkelijk zijn (als iemand belt, kunnen inkomende oproepen nog steeds dan)..
- Bij voorkeur een optie als de "lokale" centrale in huis uitvalt of gewoon het internet uitvalt, de gesprekken doorverbonden kunnen worden naar een GSM (is zoiets haalbaar?).

Ik dacht reeds aan OVH of Voys als provider.

Voys had ik reeds contact mee voor een SIP trunk , maar deze vertelden me als bij jou het internet uitvalt kunnen we geen automatische forward doen.
Je kan dit in zulke situaties manueel inschakelen.
Ik zou het precies toch praktischer vinden mocht dit automatisch kunnen?
In dit geval is mijn setup al beter dan de huidige Proximus setup...

Bij OVH heb ik echter wel reeds een SIP trunk gezien,

Maar dacht, laat ik even wat advies vragen aan de mensen die wat meer kennis van zaken hebben.
Alvast bedankt

[Splitter]

meerdere oproepen tegelijk kan, zolang je een trunk hebt met meerdere kanalen.
doorschakelen indien de pbx down is, kan bij de meeste ook wel (het is een ander verhaal als de pbx in de cloud draait en het internet lokaal down is, natuurlijk)

je kan kijken naar ovh, weepee, sewan, intellinet, destiny, teamtel, voys, ....

[JonasRetro]

WEEPEE interesseert me wel.

Tarieven zijn zéér scherp vind ik, maar ook iets Belgisch dus support in NL…
OVH is FR en dat zou voor mij een dikke ramp geweest zijn…

Heb al is gekeken naar hun SIP trunken maar ga ze morgen proberen contacteren…

Maar kan je ook een overgedragen nummer van Proximus dan bij hun gebruiken als uitgaande nummer (dus dat dat nr op display komt bij persoon die je belt)? Ik meen me te herinneren dat bij OVH dit niet kon? (Kan ook foute herinnering zijn)

[philippe_d]

Maar kan je ook een overgedragen nummer van Proximus dan bij hun gebruiken als uitgaande nummer (dus dat dat nr op display komt bij persoon die je belt)?

Beet je rare vraag, want dat is juist de bedoeling van een nummer porteren, namelijk dat je het kan gebruiken (zowel inkomend als uitgaand)

Ik meen me te herinneren dat bij OVH dit niet kon? (Kan ook foute herinnering zijn)

Bij OVH krijg je altijd eerst een "OVH nummer"
Van zodra je een Proximus nummer porteert heeft jouw OVH lijn dan 2 nummers.
Via de web manager kan je dan instellen welk nummer er gebruikt wordt voor uitgaande gesprekken.

[JonasRetro]

@philippe_d Dank voor de verduidelijking, zal iets zijn wat ik fout heb onthouden van vroeger. Maar bedankt om het duidelijk te maken

Ben uiteindelijk dus toch is voor WEEPEE gegaan, als test. Ik heb er gekozen voor een SIP trunk, enige wat momenteel nog niet goed ingesteld lijkt in mijn PBX zijn uitgaande oproepen, deze zijn steeds anoniem. Moet ik eens bekijken vanavond, maar wellicht moet de PBX meegeven welk nummer er "uitgaand" zichtbaar moet zijn want in een SIP trunk kan je toch meerdere nummers hebben?

[freddie]

Uit nieuwsgierigheid: waarom heb je gekozen voor MikoPBX (ziet er trouwens wel interessant uit, ook met de Docker-mogelijkheid), en niet bijvoorbeeld voor Yeastar, Auerswald of een FritzBox?

Wat betreft je vraag: bij een trunk moet je inderdaad zelf een uitgaand nummer meesturen.

Bij een Weepee trunk moet je erop letten dat je in de INVITE het nummer in lokaal of internationaal formaat meestuurt in de From-header bij (user) voor oproepen die naar buiten het Weepee-netwerk gaan.
Voor interne gesprekken binnen het Weepee-netwerk wordt je display name getoond. Daarom is het aan te raden ook je nummer in (name) mee te sturen.

Voorbeeld:
From: “(name)” <sip: (user)@(domain)>
From: "015xxx" <sip:[email protected]>

[Splitter]

ik vermoed dat OP gekozen heeft voor mikopbx omdat dat gratis is (net zoals freepbx en fusionpbx), terwijl de andere oplossingen die je opnoemt allemaal betalend zijn (en een fritzbox is geen echte pbx)

Dat je nummer anoniem meegestuurd zal worden kan aan 2 dingen liggen: je stuurt je nummer niet (correct) mee, of weepee laat enkel toe nummers die bij hen geporteerd zijn uit te sturen (en als je nummer dus nog niet bij hen zit, en je gewoon de trunk test, zal dat nummer niet meegestuurd worden)

[freddie]

@JonasRetro stuur Weepee een factuur door waaruit eigendom van het vast nummer blijkt en dan kunnen zij dat screenen aan die Trunk. Zo kan je al via hun uitbellen zonder te porteren. Vraag ook een nieuw nummer aan en dan kan je bij Proximus daarheen permanent doorschakelen, zo heb je ook een inbound route via die trunk.

@Splitter Het is inderdaad geen volwaardige centrale, maar ik denk niet dat het "klein bedrijfje" waar OP over spreekt dat nodig heeft. Hij sprak van 2 gelijktijdige oproepen. De fritzbox kan er minstens 4 aan.

[JonasRetro]

Hallo,

Bedankt voor de reactie's.

ik draai MikoPBX in Docker compose, gewoon omdat het praktisch (en inderdaad gratis) was. Ik overweeg wel andere systemen maar dit kon ik vrij snel en simpel opzetten toen het nodig was
Maar ik denk wel effectief aan een systeem dat zo draait...
Deze server blijft toch draaien, dus deze PBX erbij is 2x niks...

Maar als test ben ik gegaan voor een volledig nieuw nummer bij Weepee, dus geen "bewijs" nodig. Maar heb nog niks geconfigureerd van uitgaand nummer dusja kan niet werken...

Met de SIP trunk van Weepee die ik test, zou ik 15 gesprekken samen kunnen doen. Wat we nooit gaan bereiken want er zijn geen eens 15 toestellen...

[freddie]

Ik denk dat je hier best eens wat naleest: https://docs.mikopbx.com/mikopbx/englis ... eader-from

Maar zoals ik al zei stuur een Proximus-factuur naar Weepee zodat ze dat vast nummer uitgaand kunnen "meesturen" (Je moet dit ook vanuit mikopbx doen natuurlijk) en laat de oproepen die bij Proximus binnenkomen doorschakelen naar het nieuwe nummer dat je bij Weepee hebt aangevraagd. Want nu kunnen jullie toch niet uitbellen via jullie (Proximus) vast nummer?

Een fritzbox 4050 bv. lijkt mij een simpele en goedkope (€87) oplossing als centrale als je toch met analoge gateway werkt.

[JonasRetro]

Hi,

Even een late update, callerid werkt al even prima! Dus dat is geen probleem meer.

Er zijn momenteel zelfs 1 VOIP telefoon al die werkt (rest is via de ATA, maar elke telefoon heeft aparte SIP verbinding met de PBX).
Dit is 1 ATA met 8 poorten, die verschillende SIP verbindingen richting de MikoPBX stuurt (per gebruiker).

Momenteel schakel ik de PX oproepen door naar OVH, en ga dit denk ik voorlopig zo laten. (Was al een enorm gedoe om dit geregeld te krijgen bij de klantendienst...)
OVH staat als 2e lijn in de PBX.

Ik snap je bedoeling, het PX Caller ID gebruiken bij Weepee (en daarom factuur bewijs), maar ik wou eerst de caller id werkend hebben met de test lijn op de SIP trunk, dit werkt nu prima. Nu kan ik verder kijken .
Uitgaande oproepen deden ze meestal met aparte lijn, om inkomende oproepen niet te hinderen... Vandaar dat het niet echt stoorde dat we niet konden uitbellen...

Morgen bekijk ik dit verder, fijne avond nog.

Maar bedankt alvast

[freddie]

Deel je misschien even mee hoe je een Weepee trunk in mikopbx hebt ingesteld?

Welke hardware gebruik je?

[streulma]

Wij schakelen analoge centrale naar voip om met een Mediatrix toestel.
De Proximus lijn was bij ons ook kapot.

[JonasRetro]

Hoi,

Ik ben dus vandaag die Weepee gaan testen, alles lijkt prima te werken.
Tot plots inkomende gesprekken bleken geen geluid te hebben, tegenpartij hoort MIJ wel, maar omgekeerd niet. (maar deze gesprekken kwamen wel netjes binnen).
Dit - voorlopig - kunnen oplossen door poorten te portforwarden 10000 - 10800.
Bovendien het gesprek stopt na ca 20 seconden.

Maar wat ik niet begrijp is bij OVH, heb ik alles werkende gekregen zonder portforwarding.
Maar hier heb ik het echt niet werkend gekregen zonder portforwarding.

Maar portforwarden, ik zie zoiets liever niet want de "deur" staat gewoon open he dan...
Mij lijkt de enige oplossing dan portforwarden maar beperken tot de IP adressen van Weepee?



Maar Weepee zegt:

"Voor inkomend en uitgaand verkeer, dient u poort 5060 : TCP en UDP open te zetten.
Voor audio uitgaand kan het zijn dat u ook poort 1024 tot 65535 UDP moet openzetten, daar er uit veiligheidsoverweging steeds random poorten worden afgesproken met uw PBX / toestel.


Wat is jullie ervaring i.v.m. portforwarden en VOIP?

Ik nam ook reeds enkele testen met een STUN server maar dit deed weinig of niks. Ik ga nu verder uitzoeken waar de pakketjes precies blijven hangen want ze raken niet aan de PBX...


@freddie gebruikte hardware intern is Yeastar NeoGate TA800 (8x ATA)
En ja wil binnenkort zeker tonen hoe de configuratie in de MikoPBX loopt.

@streulma Ik heb indd. ook nog gedacht om de analoge centrale te laten zitten, maar heb uiteindelijk de poging gewaagd met iets volledig VOIP... Omdat het me interessant lijkt om VOIP devices toe te voegen in de toekomst...


Alvast bedankt

[Splitter]

je moet in de firewall inderdaad zorgen dat inkomend/uitgaande UDP (rtp) toegelaten is op de poorten dat weepee aanhaalt, of je gaat (soms) geen audio hebben.
je kan ze natuurlijk wel enkel open zetten van/naar je pbx en dan beperken op de IPs van weepee als je het zo dicht mogelijk wil houden.

5060 = signalling = voor de registratie van je trunk, en hierop krijg je ook de INVITES van inkomende oproepen.
5060 kan je als udp of tcp gebruiken (ligt eraan wat je in de pbx hebt gezet, meestal is dat ook udp), dus je hoeft niet noodzakelijk tcp open te zetten.
opnieuw kan je hier kiezen om dat enkel voor de weepee IPs te doen als het zo strikt mogelijk moet.

de andere poorten, voor udp/rtp, zijn voor de audio, en die zijn inderdaad random gekozen, al is weepee wel vrij ruim met zeggen dat elke poort vanaf 1024 open moet.
(lijkt me sterk dat ze aan hun zijde echt alle udp poorten gebruiken)

je kan aan jou zijde (op de pbx) in ieder geval normaalgezien de port-range aangeven dewelke aan jouw zijde gebruikt mag worden (freepbx heeft bv standaard 10000-20000), zodat je inkomend in ieder geval verder kan beperken.
uitgaand hebben de meeste mensen een vrij "lakse" regel, dus uitgaand is het mogelijk dat je helemaal niets moet openzetten, tenzij je een default deny doet.

ikzelf heb bv in mijn firewall op de wan een regel voor inkomende udp traffic vanaf de IPs waar ik telefonie van verwacht, en laat dit door indien de bestemming ook effectief mijn voip-vlan is.
omgekeerd mag mijn voip-vlan naar buiten naar eender welk ip, zolang het maar op bepaalde poorten is.

de ip's voor weepee kan je trouwens in hun helpdesk vinden: https://weepee.zendesk.com/hc/nl/articl ... -IP-ranges

[JonasRetro]

Om de PBX werkend te krijgen 5060 staat weer dicht, heb enkel 10000 - 10800 geopend en vanaf dan werkt alles prima.

Wel opmerkelijk is, de SIP trunk rechtstreeks op de VOIP telefoon aangesloten en daar werkt het meteen perfect!
Zonder gelijk welke portforwarding!

Ik ben er mee bezig.

Ik vond het gewoon erg vreemd, dat OVH zo lange tijd bij mij perfect werkte zonder portforwarding. En nu onlangs wel heel veel oproepen moest gaan verwerken... altijd prima gewerkt.

Bedankt al voor jullie info en ben er mee bezig

[Splitter]

let ook zeker op als je poorten dichtzet dat:

1) het ook nog werkt nadat je een 30tal minuten geen oproep hebt gemaakt/ontvangen (kan soms wat korter of langer zijn - dat is je registratietimer, en als je pbx bv geen sip options zou sturen om de poort op de firewall open te houden, kan het zijn dat je vervolgens geen inkomende oproepen meer krijgt, terwijl uitgaand wel nog zal werken want daarvoor stuurt de pbx/telefoon altijd de registratie terug mee)

2) het ook 100% van de tijd werkt met geluid (en niet dat je bv een poort overgeslagen hebt die 1x om de 50 gesprekken maar voorvalt, bv, wat zou leiden tot "soms heb ik eens een gesprek zonder geluid")

en je hebt in principe ook niet echt "port forwarding" nodig (de firewall zou moeten weten waar het naartoe moet), maar het moet wel toegelaten zijn,
want als de firewall zegt van die poorten zijn inkomend gewoon dicht... ja, dan komt de audio er niet door natuurlijk.

let ook op bepaalde firewalls hebben bv sip alg actief staan, en dat doet vaak meer slecht dan goed.

[JonasRetro]

Ja wat gewoon opmerkelijk is, in de VOIP telefoon.
Helemaal niks geconfigureerd in de router en werkte meteen prima!
Dus zou ook moeten lukken in de PBX.

(Enige wat wel ingesteld staat is port 5060 prioriteit krijgt in QOS) (Iets wat ik maanden geleden eens deed..)
SIP ALG deze ochtend meteen uitgezet in de router

De VOIP telefoon (op aparte OVH lijn) staat hier sinds eind vorig jaar en sedert dien geen enkele keer iets van problemen gehad.
Natuurlijk morgen ga ik denk ik gewoon de poorten openzetten (want ik moet hier 100000% zeker zijn) , maar ik wil begrijpen hoe dit werkt

Het ding is nu kan ik easy poortjes opengooien maar als het internet uitvalt heb ik het te doen met een 4G backup, daar kan ik niet op portforwarden.
En grappig genoeg een maand of 6 geleden, coax lag uit.
Telenet telefoonlijn (ook van de zaak) lag plat, en mijn OVH lijn werkte toen gewoon op de 4G backup...

[Splitter]

voor audio is het zo:

- je pbx/toestel registreert met de provider
- een INVITE (of dat nu inkomend of uitgaand is) gaat dan zeggen "hier is een call van x voor y, en ik wil audio op poort z"
- de tegenpartij stuurt een 200 OK met zijn eigen poorten

op die poorten zal dan de inkomende/uitgaande audio zijn.

in principe voor uitgaand is er meestal geen probleem (tenzij je dus specifiek uitgaand verkeer blokkeert, wat zelden het geval is in een standaard setup)
voor inkomend kan er dan een probleem zijn als de firewall dat niet doorheeft, of de poorten gewoon dichtstaan:

- indien de poort effectief dicht staat (dus specifiek "blokkeer deze udp poort", dan komt de audio niet voorbij de firewall
- indien de firewall niet snapt dat er een voip-gesprek is, of de nat tussen pbx/toestel en tegenpartij fout doet, omdat er geen manuele regel is en het automatisch niet lukt, komt de audio niet tot bij je pbx/toestel

in deze gevallen zal jij de tegenpartij niet horen.

vandaar als je dus bv een regel instelt "indien er verkeer vanaf deze IPs komt, op eender welke udp poort, stuur dat dan door naar mijn pbx" een bepaalde zekerheid geeft dat je audio er altijd zou moeten zijn, ook al werkt het mogelijks ook zonder deze regel.

uitgaand is dat eigenlijk net hetzelfde: als je firewall specifiek verkeer naar poort x niet zou toelaten, en dat is net toevallig de onderhandelde poort voor audio, dan zal de tegenpartij je niet horen. (maar meestal laat een firewall wel al het verkeer naar buiten standaard toe)


en of het nu om vdsl, coax, fiber, of 4g gaat: in principe maakt dat niet uit, zolang er geen gebruik gemaakt is van CGNAT (of de CGNAT goed ingesteld is)

[freddie]

OVH stuurt zelf heel frequent SIP OPTIONS. Weepee, dacht ik, niet. Kijk maar eens in SNgrep

Code: Selecteer alles

sudo docker exec -it mikopbx sngrep

Toegevoegd na 3 minuten 43 seconden:
@JonasRetro kan je in Mikopbx een ring group aanmaken? Ik zie enkel Queue staan.

Dat de beller het belsignaal hoort zeg maar zonder dat het gesprek al start. Want je kan bijvoorbeeld ook een Queue hebben die een belsignaal afspeelt.. maar dan is het gesprek eigenlijk al gestart

[Splitter]

een ringgroup of naar extensie ipv te laten opnemen door de pbx is quasi altijd een slecht idee (voor bedrijven) omdat je dan snel(ler) tegen timeouts vanaf de provider aanloopt.

stel bv dat je een ringgroup hebt en de pbx niet forceert om het gesprek bij de invite op te nemen, maar pas op het moment dat iemand opneemt....
als dat 31 seconden duurt maar de timeout ergens in het pad (bij beller of 1 van de providers onderweg) is 20 of 30, dan is je call weg (je kan dan natuurlijk wel een missed indication op je telefoon laten komen, maar dan moet jij de klant terugbellen...)

[JonasRetro]

@freddie In MikoPBX bij "Call queue" heb ik alle telefoons toegevoegd
Dialing strategy for agents = The call is received simultaneously by all call queue agents, including those who are busy.
Zo gaan hier alle telefoons samen af momenteel, maar het gesprek is eigenlijk inderdaad al bezig.

@Splitter Indd die regel geeft een zekerheid, en thx voor de uitleg

Ik bekijk de rest ondertussen weer even verder

[freddie]

een ringgroup of naar extensie ipv te laten opnemen door de pbx is quasi altijd een slecht idee (voor bedrijven) omdat je dan snel(ler) tegen timeouts vanaf de provider aanloopt.

Dat is op zich gemakkelijk op te lossen. Gewoon de timeout heel hoog zetten of alles van doorschakelen/voicemail bij de provider uitzetten. Bij een OVH lijn kan je dit bijv. doen.

Toegevoegd na 2 minuten 34 seconden:

@freddie In MikoPBX bij "Call queue" heb ik alle telefoons toegevoegd
Dialing strategy for agents = The call is received simultaneously by all call queue agents, including those who are busy.
Zo gaan hier alle telefoons samen af momenteel, maar het gesprek is eigenlijk inderdaad al bezig.

Dacht ik al, maar dat valt waarschijnlijk wel aan te passen rechtstreeks in het dialplan. Zo heb ik het ook eens bij VitalPBX moeten doen.

Je moet me toch wel eens de configuratie van de telefoon provider in miko doorsturen, want ik zie niet goed in hoe je het juiste nummer kunt meesturen als je bijv. meerdere nummers in een trunk hebt.

[JonasRetro]

@freddie Telephony providers -> daar bij de provider die je ingesteld hebt -> advanced settings -> Redefining SIP header "From" user: "hier heb ik nr"

Maar inderdaad hoe je meerdere nummers in 1 trunk moet behandelen heb ik ook nog geen idee van


Edit: trouwens daarnet zonder portforwarding dit draaiende gekregen...

In de router bij de Firewall;
UDP Other
Seconden (1-2097151, standaard 60)
UDP Stream
Seconden (1-2097151, standaard 180)

Deze gewoon wat langer gezet en leek meteen te werken....

Nochtans in de PBX staat ook "Support NAT session Send frequency in seconds: 30", dit had ik zelfs op 10s eens gezet maar heeft geen effect gehad.

[freddie]

Ik denk dat je wel wat moet toevoegen bij "Advanced Options" als je het een beetje wilt customizen. Maar het ziet er wel leuk uit. Bij VitalPBX raakte ik soms gewoon de weg kwijt in die eindeloze menu's en instellingen.

Toegevoegd na 5 minuten 47 seconden:

gebruikte hardware intern is Yeastar NeoGate TA800 (8x ATA)

En welke hardware gebruik je voor de MikoPBX docker container?

[Splitter]

Dat is op zich gemakkelijk op te lossen. Gewoon de timeout heel hoog zetten

nee, want dat is nog geen garantie, je hebt geen controle over het hele pad, en als er ergens onderweg die timeout op een lagere waarde staat,
zal je gesprek verbreken omdat dat deel van het pad geen 200 OK heeft ontvangen binnen de ingestelde tijd.

Je moet me toch wel eens de configuratie van de telefoon provider in miko doorsturen, want ik zie niet goed in hoe je het juiste nummer kunt meesturen als je bijv. meerdere nummers in een trunk hebt.

inkomend is het gewoon met de DID in de incoming call handling, uitgaand is het volgens mij in mikopbx niet in de gui ingebouwd, en moet je dat dan per extensie of rule in de configuratie toevoegen.

[JonasRetro]

@freddie Die draai ik op dit moment op een container op een Mini PC van Beelink.
Maar daar draait Homeassistant ook op...

[freddie]

nee, want dat is nog geen garantie, je hebt geen controle over het hele pad, en als er ergens onderweg die timeout op een lagere waarde staat,
zal je gesprek verbreken omdat dat deel van het pad geen 200 OK heeft ontvangen binnen de ingestelde tijd.

Heb je dit al voorgehad met enkele providers? Tot nu toe nog geen problemen gehad met Weepee, Sewan of OVH.

inkomend is het gewoon met de DID in de incoming call handling, uitgaand is het volgens mij in mikopbx niet in de gui ingebouwd, en moet je dat dan per extensie of rule in de configuratie toevoegen.

Wel straf want de fritzbox:

geen echte pbx

ondersteunt dit wel out of the box.

[JonasRetro]

Nadat het gewoon werkte zonder portforwarding (puur omdat ik wou weten hoe het zat).
Terug gekozen voor de veilige route met portforwarding (waar alleen de IP's van WEEPEE) binnen mogen via de portforwarding...

Ben wel nog zinnens om alles kwa VOIP in een compleet ander subnet te steken van het thuisnetwerk hier.
Maar vandaag is het gewoon het belangrijkste dat het werkt .


@Splitter en @freddie Ik wil jullie wel graag bedanken om mij verder te helpen hiermee, en vooral ook mij dit een heeel stuk beter weer te doen begrijpen .

[Splitter]

Heb je dit al voorgehad met enkele providers? Tot nu toe nog geen problemen gehad met Weepee, Sewan of OVH.

ik heb het al weten gebeuren ja

Wel straf want de fritzbox ondersteunt dit wel out of the box.

miko is gewoon asterisk, dus die ondersteunt dat ook "out of the box" - de ontwikkelaar (een rus) - heeft dat gewoon (nog) niet via zijn frontend naar boven gehaald, voor zover ik weet.
(maar ik dacht ook dat de ontwikkeling een hele tijd stil had gelegen ivm de oorlog, wat blijkbaar -als ik naar het github repo ga kijken- toch blijkt mee te vallen)
ik vind het wel een mooi project, want het haalt de pbx instellingen vrij eenvoudig naar voren, maar de afweging is dan altijd "wat met hetgene waar je net niet over nagedacht hebt" zoals blijkbaar uitgaande callerid instellen, idd.
ik zou het, denk ik, in het profiel van de extensie steken zodat je op extensie-niveau het uitgaande did kiest... maargoed, wat als je dan weer een andere did zou willen omdat je met meerdere uitbelt (bv sales & support), dan zou daar weer een route moeten zijn die dat override, en dan ga je het weer verder ingewikkelder maken natuurlijk

Terug gekozen voor de veilige route met portforwarding (waar alleen de IP's van WEEPEE) binnen mogen via de portforwarding...

let op je source ports, die gaan niet altijd in de range zitten dat je instelt, want het gaat daarbij over de destination en niet de source.
je zou de regel dus moeten aanpassen waarbij bronpoort (voor de audio) eender welke poort kan zijn (kiest de tegenpartij)

[JonasRetro]

Ah wacht bedankt voor de tip @Splitter

Ik had dit als basis genomen, ik dacht dat de PBX liet weten aan Weepee dit is de range waar je mag binnen werken.
Of is dat een denkfout van mij?

En over MikoPBX:
En ja net omdat het zo simpel was ging ik er mee aan de slag, ik had ook eerst FreePBX geprobeerd maar was een noodgeval dus moest gewoon snel gaan en dit kreeg ik vrij snel in orde .

[Splitter]

je stelt 10000-10800 in op de pbx, dat wil zeggen dat de pbx bij een call een random poort in die reeks zal kiezen om audio op *te ontvangen*.
in de INVITE/200 OK gaat je pbx dan een lijntje toevoegen met die gekozen poort, en weepee zal dan de audio naar die poort sturen.

dus, het is aan jou zijde de doelpoort (inkomend verkeer).
de bronpoort is de poort vanaf waar het verkeer naar jou toe komt, en is volledig gekozen door de tegenpartij en kan je dus (meestal) niet weten.
(vaak is het symmetrisch, en zal de poort dewelke weepee in de INVITE/200 zet ook de bronpoort zijn, maar die ken je dus niet op voorhand)

als je de vergelijking maakt met een website:

- je browser zal verbinden naar een website, en de poort waarop die website draait is 80 (http) of 443 (https)
=> dat is de "doelpoort", de poort waarop het verkeer zal binnenkomen, en dus waarop je webserver (pbx) luistert

- om die verbinding te maken zal je browser een random poort kiezen die vrij is op je computer, en dat kan eender welke poort zijn, dewelke zal gebruikt worden om het verkeer naar buiten te sturen
=> dat is de "bronpoort", de poort waarvan het verkeer vertrekt naar de bestemming

[JonasRetro]

let op je source ports, die gaan niet altijd in de range zitten dat je instelt, want het gaat daarbij over de destination en niet de source.
je zou de regel dus moeten aanpassen waarbij bronpoort (voor de audio) eender welke poort kan zijn (kiest de tegenpartij)

@Splitter Ok ja had inderdaad je tekst niet zo goed gelezen hierboven met de nadruk op "Source"

Maar stel me hier toch vragen bij?
Ik snap je uitleg wel heel goed hoor, maar bij een webserver portforward je toch ook enkel de poort 80?
En de bronpoort die is toch ook niet geportforward?

Portforwarding regels zijn toch uitsluitend voor inkomend verkeer (dus enkel voor de doelpoorten?)?
De provider stuurt dus zijn RTP (audio) dus naar 10000-10800 (specifieke port gekozen door de PBX)
Deze poort is dus de poort waarmee de data zal binnenkomen bij mijn router en dus netjes door de portforwarding heengaat richting de PBX?

Maar ik hoef toch niet de bronpoort (die poort waarmee de data bij Weepee zal aankomen) te portforwarden?
Portforwarding regels hebben toch enkel invloed op inkomende poorten?

Of kan de audio port toch buiten 10000-10800 deze range komen te vallen waardoor ik geen audio heb? Zoja waarom kan die daar buiten komen te vallen?

Bedankt voor de uitleg trouwens

[Splitter]

je doet inderdaad portforwarding voor inkomend verkeer (en inderdaad doelpoorten).

maar als je bij die regels ook de bronpoort gaat definieren, dan is de controle op bronpoort+doelpoort en dat kan dan mislopen (want de bronpoort ken je niet)

voor een webserver is het:

jouw pc => bronpoort (random) => internet => doelpoort (80/443) => (forward naar doelpoort) webserver
aan de kant van de webserver zou je dus een regel moeten zetten in de firewall "laat al het verkeer toe dat als doelpoort 80/443 heeft", zonder bronpoort te specifieren.

voor voip is het (laten we het voorbeeld van een inkomende call nemen):

weepee => INVITE => naar jou op (doel)poort 5060
in deze INVITE zit vervolgens de informatie van op welk IP en welke poort jouw PBX audio moet *versturen* naar weepee.
daarop antwoord jouw pbx met een 200 OK bericht naar weepee, en daar staat in welk IP en poort weepee moet gebruiken zodat jij audio hierop *ontvangt*

laten we zeggen:
INVITE van weepee = ip 1.2.3.4 en poort 17500
200 OK van jouw pbx = ip 9.8.7.6 en poort 10500

dan wil dat zeggen:
- jij gaat audio inkomend ontvangen van 1.2.3.4, en zij gaan dat sturen naar (doel)poort 10500 (deze poort moet dus open zijn en naar je pbx leiden)
- vervolgens gaat jouw pbx audio sturen naar 1.2.3.4 op (doel)poort 17500 (maar hier moet je -in de meeste scenario's- niets voor doen, gezien uitgaand meestal standaard toegelaten is)

in jouw geval zal de inkomende audio altijd binnen de gedefinieerde poorten in je pbx vallen (10000-10800), maar kan die komen van andere bronpoorten.

een bronpoort moet je enkel definieren bij diensten waarvan je verwacht dat de verbinding *komt van* een bepaalde poort, iets wat in principe vrij zeldzaam is,
omdat deze vaak random door de applicatie gekozen worden op basis van wat er vrij is op de pc/firewall,
terwijl je de doelpoort moet definieren bij diensten waarvan je verwacht dat de verbinding *gaat naar* een bepaalde poort

definieer je in 1 regel dus echter beide, dan moet zowel de bron als doelpoort binnen die definitie vallen om toegelaten te worden

dus in het kort:
- doelpoorten = inkomende regel in je firewall dewelke gelijk is aan de poorten die je in je pbx hebt opgegeven = zorgen dat je audio binnenkan
- bronpoorten = gewoon leeg/any laten, gezien je voor de inkomende verbinding niet weet vanaf welke poort die komt.

nog een belachelijke vergelijking voor je, omdat dat mijn stijl is:

als je een pakje verwacht van amazon, weet je wel dat er op dag X een koerier bij je aan de deur zal staan (want jouw deur is het doel), en je weet dat het van amazon komt (dat is het bron ip), maar je weet niet of het met bpost, postnl, dpd, dhl, .... komt (want dat is de bronpoort)
dus je zorgt dat je thuis bent (dat is de firewall regel met de doelpoort), maar je kijkt uit het raam voor eender welk van deze koeriers (dat is je 'any' bij de bronpoort)

[JonasRetro]

@Splitter
Hey,

Ik snap het, had je laatste berichtje net half gelezen en bekeek mn portforwarding nog is goed en zag daar nu inderdaad BRONPOORT en DOELPOORT staan, ik had hier recht overgekeken... (hoe blind kon ik zijn , hierdoor snapte ik ook niet waarom je die bronpoort wou in de portforwarding)...

Ik zat nog met mn gedachten bij de vorige router waar ik een publieke poort kon instellen (bijv 8080) en dan intern (80)...
Had geen aandacht besteed aan die tekst, maar redeneerde nog met het idee van de vorige router...
Ga straks dit even bekijken!
Ik had bronpoort dan ook geïnterpreteerd als "Publieke" poort en doelpoort als "interne" poort... Wat dus niet zal kloppen inderdaad...
Ik had hier domweg gewoon niet bij stilgestaan... Maar hier staat inderdaad bronpoort en doelpoort...



EDIT:

je doet inderdaad portforwarding voor inkomend verkeer (en inderdaad doelpoorten).

maar als je bij die regels ook de bronpoort gaat definieren, dan is de controle op bronpoort+doelpoort en dat kan dan mislopen (want de bronpoort ken je niet)

Maar op any kan ik de bronpoort niet zetten, ga dit straks even uitzoeken...

Heb wel net nog per toeval ergens mijn gedacht ergens laten op vallen.....
De audio stream zou in conflict kunnen komen met een andere container die draait op port 10018...
Dus als bij toeval poort 10018 aan de beurt komt zou het eens kunnen zijn dat de RTP ook niet tot stand kan komen...

Heb daarom de range aangepast in de PBX van port 10020 tot 10800...

In de toekomst zou ik wel die container een eigen IP adres willen geven, om dit soort issues 100% te voorkomen maar normaal zouden er nu totaal geen (interne) poort conflicten mogen zijn...

Bedankt voor al je uitleg

[Splitter]

Ik had bronpoort dan ook geïnterpreteerd als "Publieke" poort en doelpoort als "interne" poort... Wat dus niet zal kloppen inderdaad...

het is mogelijk dat het een slechte vertaling is en ze met bronpoort inderdaad de bestemming op de wan-zijde bedoelen,
want het is uiteindelijk wel een forwarding rule, maar dan zou ik het toch maar een rare firewall/router vinden.
maar het zou dus eventueel wel kunnen inderdaad, maar daarvoor zal je even de documentatie van de gebruiker hardware/software er moeten bijhalen.

mij lijkt het normaalgezien als men spreekt over bron/source dat het is "waar het vandaan komt" en niet "waar het naartoe ging" (of dat nu aan wan of lan zijde is)

[JonasRetro]

@Splitter Ja begon zonet in dezelfde richting te denken dat het mogelijks een slechte vertaling zou kunnen zijn. Ga dit dan eens testen en indien slechte vertaling melden aan TP-Link…

Maar ga dit inderdaad eerst testen… ik kreeg namelijk een fout, ik kon maar 1x een externe poort hebben... (Wat logisch is bij publieke port, maar niet bij externe poort)...


Want hoe jij het uitlegt klinkt het logisch…
Want source port zou ik nu ik dat gelezen heb ook niet meteen als “externe poort” zeggen…

Ik had het zo geïnterpreteerd omdat dit zo was in oude router en had er niet zo heel veel aandacht voor toen ik hiermee bezig was…

Verstuurd vanaf iPhone


EDIT:

Ik denk toch dat het Externe poort is en interne poort... (wat dus eigenlijk toch wijst op slechte vertaling)...

Ik heb als test een webserver gedraaid op poort 8080 op mijn laptop.
Maar via GSM kon ik deze netjes bezoeken op http://Publiek_IPV4:61 met bovenstaande regel...

[freddie]

@JonasRetro alles volledig operationeel gekregen?

[JonasRetro]

@freddie Ja alles werkt intussen OK via Weepee en de PBX.


Ik heb wel de codec nog aangepast naar G722 (G722 als eerste in rij), en sedert dien wel gigantisch scherp geluid (ook op de analoge telefoons). Je hoort de mensen echt zéér duidelijk nu... G711 was ook best OK, maar de switch naar G722 merk je wel ...

Maar ik hou jullie zeker nog op de hoogte, maar heb het afgelopen week erg druk gehad & afgelopen nacht zéér slecht geslapen, was anders zinnens om vandaag een en ander te doen...

[freddie]

G722 heeft helaas weinig zin. Analoge telefoons = G711, PTSN-interconnecties = G711.

Ben je van plan om de gesprekskwaliteit te monitoren? Door parameters als jitter, packet loss, delay etc. te capteren?