VoIP intercom systeem


  • PWS TU Delft admin

    Beste Balte,

    Dit ziet er al aardig goed uit! Ik zie dat jullie al flink wat tijd in het oriënteren/onderzoek hebben gestopt.

    Wat voor mij op dit moment nog niet helemaal duidelijk is, is welk onderdeel jullie precies willen gaan ontwerpen en welke onderdelen jullie "out-of-the-box" willen gaan gebruiken?

    Verder neem ik aan dat het voor jullie nu vast staat dat jullie met dit onderwerp verder gaan?

    Groetjes,
    Joost



  • Joost,

    Ik ben de afgelopen tijd bezig geweest met het schrijven van een concept. Hierin wordt denk ik je vraag beantwoord.

    Het idee is om enkel de missing links tussen de open source projecten te schrijven. Kort gezegd is dat: FreeSwitch aansturen middels een NodeJS server en een gebruikersinterface bouwen.

    In dit eerste concept is nog niks over hardware gerept, dat zal pas in een tweede concept na de herfstvakantie komen. Het idee is dan ook dat wat nu op papier staat zo rond de herfstvakantie ook in het echt zal bestaan.


  • PWS TU Delft admin

    Beste Balte,

    Dat ziet er goed uit! Is het een optie voor jullie om de Node server in de cloud te hosten? Bijvoorbeeld bij AWS of DigitalOcean?

    Veel succes!

    Groetjes,
    Joost


  • PWS TU Delft admin

    Beste Balte,

    Helemaal goed! Ik wilde voorkomen dat je zelf met daadwerkelijke servers aan de slag zou gaan om tijd te besparen.

    Veel succes!

    Groetjes,
    Joost



  • Ik beschik zelf over een vps waar ik een node server op kan hosten, vanwaar die vraag ineens?



  • Voor de implementatie van WebRTC is een beveiligde verbinding nodig. Dat op zichzelf is geen probleem, maar voordat de browser deze verbinding accepteert is er een certificaat nodig. Dit zorgt voor complicaties, maar is niet te vermijden. Ik zie een aantal oplossingen met elk zijn nadelen en voordelen.

    1 unregistered certificate

    • Voordeel, turnkey solution. Project blijft toegankelijk voor minder geavanceerde gebruikers
    • Nadeel: gebruikers aanleren om waarschuwingen weg te klikken.

    2 local dns

    • Voordeel, geen waarschuwingen.
    • Nadeel, ingewikkeld om te installeren.

    3 hosting in de cloud

    • Voordeel, veilig certificaat, makkelijker te installeren dan dns, samenwerking meerdere fysieke locaties
    • Nadeel, vps en domeinnaam is vereiste, internetverbinding vereiste.

    Hierbij valt oplossing 2 wat mij betreft af, dit is namelijk niet flexibel inzetbaar. Oplossing 1 heeft ethische bezwaren, alhoewel de verbinding niet minder veilig is (omdat deze zich binnen het lokale bevind) leren we gebruikers aan om waarschuwingen van de browser te negeren. Oplossing 3 heeft als nadeel dat niet op iedere locatie een internetverbinding beschikbaar is. Het voordeel van oplossing 3 is dat meerdere fysieke locaties een intercom kunnen delen. Dus bijvoorbeeld een studio, een remote studio en een locatieverslaggever.

    Mis ik hierin nog een oplossing, en wat zijn jouw meningen over de beste oplossing?


  • PWS TU Delft admin

    Hoi Balte,

    Mij lijkt optie 3 zeker het makkelijkst. Wat betreft optie 1 en 2 heb je denk ik gelijk.

    Ik weet alleen niet precies op wat voor locaties je het systeem wilt kunnen testen/gebruiken. Tegenwoordig kun je overal natuurlijk wel aan een internet verbinding komen via een hotspot van je telefoon desnoods dus dit hoeft misschien geen probleem te zijn? De plekken waar je het wilt gaan gebruiken zou ik als voornaamste argument gebruiken voor één van de 3 keuzes.

    Groetjes,
    Joost



  • Zonder hier uitvoeriger onderzoek naar gedaan te hebben doe ik de aanname dat dit op twee locaties gebruikt zal worden:

    1. een studio omgeving - waar een vaste internetverbinding ligt
    2. een live locatie - kerk, sporthal, theaterzaal etc. waar vaak een vaste internetverbinding ligt, maar de vraag is of deze van voldoende snelheid / betrouwbaarheid is.

    Een nadeel is dat je hier op het platteland al snel in buitengebied zit waar vaak nog enkel adsl beschikbaar is. Een hotspot op de telefoon is een mogelijkheid, maar brengt zeker extra kosten mee.

    Als je in de broncode kijkt op https://github.com/baltedewit/openintercom dan zul je misschien ook begrijpen dat er een extra reden is om niet voor optie drie te kiezen. Mijn client -> server beveiliging is niet optimaal, omdat ik gebruik maak van ongeregistreerde clients. Dat zou opgelost moeten worden met bijvoorbeeld tokens die verstrekt worden en gecontroleerd etc. Al met al een fikse uitbreiding van FeathersJS vrees ik.

    Ik denk dat oplossing 3 de beste oplossing is om dit probleem zo goed mogelijk op te lossen, maar tegelijkertijd brengt het wel flinke nadelen mee. Ik ga me denk ik op het moment beperken tot oplossing 1, omdat ik daarmee de minste tijd besteed en ik altijd nog aan oplossing 3 kan gaan denken mocht er nog ergens wat extra tijd vandaan komen.


  • PWS TU Delft admin

    Beste @balte,

    Dit klinkt als een verstandige keuze. Vergeet niet om deze keuzes goed te beargumenteren in je PWS om aan te geven dat je hier over na hebt gedacht.

    Heb je nog specifieke vragen waar ik je nu mee kan helpen?

    Groetjes,
    Joost


Aanmelden om te reageren
 

Het lijkt erop dat je verbinding naar Forum verloren is gegaan, wacht even terwijl we de verbinding proberen te herstellen.