[Voip] neue VOIP Datenbank in Betrieb, entkoppelt vom redeemer

Thu Aug 14 18:59:19 CEST 2014

Am 2014-08-14 um 18:27 schrieb Christoph Loesch:
> On 08/14/2014 01:30 PM, Erich N. Pekarek wrote:
>> Hallo!
>>
>> Am 2014-08-14 um 12:16 schrieb Matthias Šubik:
>>> Hallo,
>>> On 13.08.2014, at 21:45, Erich N. Pekarek wrote:
>>> ...
>>>>     Automatische generiere Passwörter sind wertlos, wenn sie im 
>>>> Klartext übertragen werden.
>>> +1
>> Was sagt das Voip-Team dazu?
>
> vom user gesetzte "einfache" passwörter sind wertvoller oder wie?
Ohne Verschlüsselung sind beide Varianten wertlos. Wie Du weißt, wird 
der Datenverkehr über WLAN in diesem Netz auch nicht verschlüsselt:
Ist das eine absichtliche Einladung?
> wir versuchen schritt für schritt zu verbessern, bitte keine perfekten 
> riesensprünge erwarten.
Aber das wissen wir doch und wir sind dankbar für jeden Schritt vorwärts.
In Anbetracht früherer Ereignisse sollte dies auch unabhängig von zu 
befürchtenden Mehrkosten (die ja abgestellt wurden) behoben werden: Es 
geht wohl auch um Datenschutz und bloß um Sorgfalt.
>
>>>>     Die User-ID bei "last seen" im Telefonbuch auszugeben ist 
>>>> vielleicht auch keine so tolle Idee.
>>> Benutzeridentifikation ist nicht so cool, aber die Funktion an sich 
>>> ist sehr gut!
>> Die Funktion habe ich ja nicht kritisiert. ;-)
>
> dann bitte bessere idee vorschlagen! kritik ist ok, aber bitte mit 
> einem vorschlag wie man es besser machen kann, weil reine kritik 
> machts uns nur schwerer alle glücklich zu stellen.
Wie gesagt: die User-ID aller eingeloggter User im Telefon für jeden 
Nutzerlevel anzuzeigen, ist problematisch. Das sollten nur Admins können.
Für den Rest könnte man sich auf entweder das generelle Ausblenden der 
UserID (nicht aber der Timestamps) oder die Verschleierung eines Teils 
der UserID beschränken.
>
>>>
>>>>     Für die Laien: was ist "force_rport,comedia"
>>> das sind Verbindungseinstellungen, rport ist die Angabe nach 
>>> RFC3581, und comedia ist connection oriented media 
>>> (http://www.cisco.com/c/en/us/td/docs/ios/voice/sip/configuration/guide/15_0/sip_15_0_book/sip_cg-com_fork_mlpp.html)
>> Die Links könnte man ins Frontend einbauen - zB als mouseover:[?].
>>> Alter NAT-Wein in hoffentlich nun funktionierenden Schläuchen. 
>>> NAT+SIP ist einfach ein Kopfschmerzgenerator (schlechter Wein, um im 
>>> Bild zu bleiben), hätte man das nur gleich am Anfang richtig 
>>> eingebaut. Bisherige Lösungen STUN/ICE usw. waren einfach nur Hacks, 
>>> die nie mit allen Clients, und vor allem mit nicht allen NAT-Routern 
>>> zusammengearbeitet haben.
>> Ja, das Problem der problematischen NAT-Router haben die heise-Leute 
>> auch schon aufgegriffen - am Beispiel von Multipath-TCP 
>> http://www.heise.de/netze/artikel/Middleboxen-verkalken-das-Internet-2133877.html 
>>
>>
>>>>     Das Suchen der richtigen Settings kann je nach Device mühsam 
>>>> sein. (Random Port oder nicht?, SIP Secure oder nicht?) -> bitte 
>>>> Dokumentation.
>>> Das weiß meistens nur der Hersteller des NAT-Routers. Chello-Thomson 
>>> Router haben übrigens dazu einen SIP-ALG-Schalter (an/aus), der nach 
>>> meinen Tests SIP nur auf Port 5060 folgt, und die entsprechenden 
>>> Ports freischaltet. Was ein wenig ein Problem ist, wenn das Telefon 
>>> prompt auf Ports besteht, die der Router anderweitig nutzen muss, 
>>> oder kann. Dann geht plötzlich in einer Richtung kein Audio mehr.
>> Wie gesagt: Dokumentation - ggfs Debugging-Anleitungen sind vonnöten.
>
> fang mal damit an und wir fügen die inhalte dazu ein die dir fehlen ;)

SIP-Server, Port oder Random Port, SIP Secure: ja/nein/optional; STUN: 
ja/nein.
Gerade mit der Android-App CSipSimple habe ich immer wieder Probleme 
beim Einrichten - was wie von Matthias erwähnt mit unterschiedlichen 
NAT-Konzepten zu tun haben kann.

Eine Umgehung könnte ein optionales Tunnel-Setup für das VoIP-System 
sein, der uns das NAT erspart.
>
>>>>
>>> ...
>>>> 2014-06-13: Die enum.at GmbH hat den Vertrag zum Betrieb der ENUM 
>>>> Registry für +43 mit Ende 2014 gekündigt. Für weitere Informationen 
>>>> und über die weitere Zukunft von ENUM informieren Sie sich bitte 
>>>> bei der RTR:
>>> Dazu gibt es ein Infogespräch mit der RTR nächste Woche, und ich bin 
>>> aus beruflichen Gründen dort, und kann dann berichten.
>> Danke!
>>>
>>>>>> Habt ihr konkrete Pläne (= in absehbarer Zeit), auch das 
>>>>>> Telefonieren ins Festnetz wieder zu aktivieren?
>>> ...
>>>>    1. Wer raustelefonieren dürfen will, zahlt aufs Vereinskonto 
>>>> einen Beitrag von € 1-3/Monat.
>>> wäre ein zusätzliches "Produkt" des Vereins, mit entsprechendem 
>>> Adminaufwand. Dann doch lieber herschenken.
>> Ack.
>
> es gibt die (nicht gänzlich durchdachte) idee benutzern die 
> möglichkeit zu geben, uns eine sim karte und einen (aus einer liste) 
> unterstützten 3g-usb-stick zu geben, der dann fürs raustelefonieren 
> genutzt wird für einen bestimmten user account. das mit 1-3eur aufs 
> vereinskonto bezahlen usw ist viel zuviel aufwand für den wir die zeit 
> leider nicht haben.
Ob man jetzt eine SIM-Karte und ein 3G-Netz oder einen 
Prepaid-Account/SIP-Trunk verwendet ist wohl egal. Einfacher dürfte das 
SIP sein.
Bedenke, dass Kosten von 0,5 Cent nach Österreich bei einigen Anbietern 
gleich oder geringer als bei der SIM-Variante sind, während AGB der 
Mobilfunker oft Gateways untersagen.
>
>>> ...
>>>>     Funkfeuer vertreibt als Reseller selbst solche Prepaid-Accounts 
>>>> an die Mitglieder, die zahlen selbst, und Funkfeuer erhält 
>>>> womöglich noch eine Provision.
>>> Auch hier der Bürokratieaufwand, aber wäre möglich.
>> Die Verrechnung wäre klar, aber das Raustelefonieren wäre stark 
>> beschränkt.
>> Was aber machbar sein müsste, sind Telefonate, die unzweifelhaft 
>> Voip-Voip sind.
>
> enum ist bei uns eh aktiv, also z.b. sil-funkfeuer und funkfeuer-sil 
> anrufe funktionieren via enum problemlos, somit sollte es überallhin 
> bzw von überall funktionieren wo auch enum aktiv ist.

- wie gerade tel. besprochen -
Wobei es mir nicht klar war, dass 0720 ebenso wie 0780 über enum läuft. 
Man lernt nie aus.
>
>>> Für den gelegentlichen Anruf ins Festnetz findet man sicher ein 
>>> Sponsoring (white-listing der Zielnummernbereiche), aber Abrechnung 
>>> ist halt eine deutlich höherer Aufwand, besonders die Abklärung, wer 
>>> wo das Risiko trägt.
>> Darum würde ich Prepaid-Services empfehlen. Da kann schlimmstenfalls 
>> das (geringe) Guthaben verloren sein. Teilweise bekommt man für 12 
>> Euro 2000 Minuten - je nach Destination und das Guthaben hat laut 
>> einigen Anbietern auch kein Ablaufdatum.
>> Abrechnung würde der Fairness dienen, wenn man mit einem Pool 
>> arbeitet. Bei Individualaccounts hätte man am Endpunkt einen weiteren 
>> Account einzurichten und kann womöglich keine Nummer mitschicken. 
>> Daher die Überlegung, den Account - wie bei diversen Messengern und 
>> Maildiensten üblich - gleichsam über einen (individuellen) Proxy 
>> laufen zu lassen. Kann man das?
>
> siehe weiter oben die genannte idee.
Sie ebenso oben.

LG
Erich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.funkfeuer.at/pipermail/voip/attachments/20140814/da321b08/attachment.html>