[LUGA] Mit freundlicher Unterstützung von:
init.at

Mail Thread Index


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [luga] internet provider empfehlung für wien?



Am Montag 21 März 2011 11:18:52 schrieb Bernd Petrovitsch:
> On Sam, 2011-03-19 at 21:52 +0100, Hermann Himmelbauer wrote:
> > Am Freitag 18 März 2011 11:00:28 schrieb Bernd Petrovitsch:
> > > On Fre, 2011-03-18 at 01:39 +0100, Hermann Himmelbauer wrote:
> > > > Am Montag 14 März 2011 14:16:30 schrieb Hakan Evirgen:
> > > > Und dazu kommen dann in meinem persönlichen Fall noch
> > > > Vermittlungsprobleme aufgrund von falschem Routing, für das sich dann
> > > > natürlich kein Betreiber
> > >
> > > *Wer* hat *wo* genau *wie* falsch geroutet?
> >
> > Wie genau die Infrastruktur dahinter aussieht, weiß ich nicht, liegen
> > dürfte es an dem Interconnection-Provider, der aus einem unerfindlichen
> > Grund falsch routet.
>
> IP-Routing (als solches) oder "nur" VoIP (d.h. SIP und/oder RTP oder
> was-auch-immer.....)?

Nein, "nur" VoIP. Ich habe ja nicht wirklich den Durchblick, wie das 
funktioniert - aber soweit ich es verstehe, ist für eine Telefonnummer 
ähnlich DNS in einen Server der Provider bzw. sein VoIP-Gateway eingetragen. 
Das ist die Voraussetzung, dass die Gespräche auch richtig ankommen. Bei 
manchen Interconnection-Providern steht aber zu meiner Nummer statt der UPC 
offenbar die Telekom drinnen.

Und anscheinend bekommt es niemand hin, diesen Eintrag zu verändern.

Ich persönlich frage mich ja schon auch, warum das so ein Problem ist - denn 
bei DNS kommt es doch recht selten vor, dass die Server nicht synchronisieren 
und manche DNS-Server über Jahre hinweg falsch auflösen.

Bei der Telefonie scheint das aber doch recht häufig vorzukommen (das ist 
nicht der 1. Fall, den ich diesbezüglich erlebe) - da frage ich mich schon, 
was da technisch oder strukturell in der Telekomwelt verbockt ist.

> > anrufen. Die wieder bieten ein sogenanntes "Schlichtungsverfahren" an.
> > Wie lange das aber dauert, steht in den Sternen. Und dass mein Interesse,
> > da weitere Stunden hineinzuinvestieren gering ist, liegt auf der Hand.
>
> Klar.
> Nur wissen viele, wie groß die Abneigung gegen derartige (und andere)
> Verfahren ist und wenn man als Kunde klein genug ist und "eh nie was
> machen wird" und erstmal ein Zeit schinden....
> Soll in anderen Branchen nicht unüblich sein.

Stimmt. Eine andere, effektive und für mich weniger aufwendige Methode ist, 
des Anbieter zu wechseln - egal wer jetzt "Schuld" hat. Blöd ist nur, dass 
man so aus der Vertragsbindungsdauer nicht rauskommt - günstiger ist es aber 
immer noch.

> > > Du hast ein Problem bei der Kooperation von verschiedenen Systemen, die
> > > Du ausgesucht bzw. zusammenstellt hast, und bei einem Problem erwartest
> > > Du, daß der Hersteller/Verkäufer eines dieser Systeme einen Fehler
> > > sucht?
> >
> > Genau. Weil wenn ich zuerst bei beiden Anbietern (Telefonanlage und
> > Provider)
>
> Hmm, und wo dazwischen liegen dann die 2 Provider, die Du oben erwähnt
> hast? Welcher der beiden hat da versprochen (und für welches Setup)?

Das ist wieder ein anderes, zweites Problem, das nichts mit der Vermittlung zu 
tun hat. Auf der einen Seite ist der Hersteller der Telefonanlage (Auerswald) 
und auf der anderen Seite die UPC. Dass die Auerswald-Anlage einen Linux 
Kernel-Trace bei Beginn des RTP-Traffics produziert - und das offenbar nur 
bei UPC, war meines Erachtens nicht einfach vorauszusehen.

> Ausprobieren?

Das ist normalerweise auch meine Lösung. Aber immer kann ich das nicht tun. 
Wenn die Gesamtlösung für den Kunden € X kostet, aber der Aufwand für die 
Teststellung € X * 5 kostet, wird es schwierig. Ich kann auch nicht jedes 
Gerät bzw. jede Gerätekombination zuerst bei mir ausprobieren. Das ist ein 
Ding der Unmöglichkeit - auch zeitlich gesehen. Da bleibt mir nichts anderes 
übrig, als zu vertrauen bzw. "probieren geht über studieren" anzuwenden.

> > Somit ergibt sich aber für meinen Anwendungsfall - nämlich ein kleines
> > Büro mit 2 Mitarbeitern, das keine besonderen Anforderungen, aber ein
> > funktionierendes Fax braucht, die sehr klare Antwort: VoIP ist gegenüber
>
> "Fax und VoIP" war oben noch gar nicht dabei - da gibt es dann die
> nächste Liste mit potentiellen Problemen. Oder meintest Du eh nur "T.38
> Fax" oder ein Fax-Gateway beim Gatewaybetreiber?

Naja, in dem kleinen Büro gibt's ein Fax, das dann über die VoIP-Leitung 
funktionieren sollte (mit T.38), aber nicht tut - gut, man hat mich auch 
vorgewarnt, dass nur ca. 80% der Faxe funktionieren werden. In der Realität 
gehen aber nur 10%. Und das Fax-Gateway beim Provider, das als Lösung 
vorgeschlagen wird, geht ebensowenig zuverlässig - wahrscheinlich deshalb, 
weil viele Faxgeräte mit Hylafax (das wird als Gateway eingesetzt) nicht 
zurechtkommen.

Liebe Grüße,
Hermann

-- 
hermann@qwer.tk
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7



powered by LINUX the choice of a gnu generation
linux user group austria;
Suche
Suche
Letzte Änderung:
webmaster@luga.at
Mrz 2011