[DISKUSSION] Warum blueSIP so reibungslos, andere nicht?

[der_Gersthofer]

Warum eigentlich klappt es mit blueSIP so reibungslos, nicht aber bei nahezu allen anderen Providern? Während ich bei denen praktisch nie eine Störung, nie einen Ausfall, nie eine schlechte Leitung, praktisch nie Probleme habe, treten bei nahezu allen anderen Providern - mal mehr, mal weniger - Probleme auf.

Liegt das nur an der geringen Kundenzahl oder aber daran, dass blueSIP sich strikt an die Standards hält? Wenn dem so wäre: Warum klappt das bei den anderen Providern (insbesondere denen die auch auf SER aufsetzen) nicht? Liegt das an der Abschottung? Den Ausnahmen, die aus welchen Gründen auch immer, programmiert werden?

blueSIP weist die Anmelund mit privaten IPs im Contact Header zurück (wer also einen veralteten Router / fehlerhafte Rouerkonfiguration hat kann sich gar nicht erst anmelden), aber warum machen das nicht auch alle anderen? Wenn es daran liegen sollte, dann wäre es für die anderen Provider an der Zeit, dem zu folgen, denn die ewigen Probleme (schlechte Leitungsqualität, Fehlermeldungen wie "Method not allowed", Anmeldung nur mit unverschlüsseltem Userklarnamen (wie bei Sipgate), keine volle ENUM Unterstützung oder etc.) nerven irgendwann.

Daher meine Bitte an die Provider: Haltet euch (endlich) an die Standards und hört auf, eure eigenen Süppchen zu kochen! Ich bin ein geduldiger Mensch und teste auch gerne mal. Aber irgendwann habe auch ich keine Lust mehr. Danke

 

[pfeffer]

nenene.
sipgate hat ein extrem schlaues NAT-Traversal-Trick. Den sollten sie auf gar keinen Fall abstellen. Er funktioniert durch jedes NAT hindurch, ohne irgendwelche Einstellungen vornehmen zu müssen. Kein STUN, kein rtp-Proxy (outbound-proxy). Einfach die Anmeldedaten eintragen, sipgate.de als SIP-Proxy - und es läuft (Probleme können nur noch wegen einer evtl. instalierten Firewall auftreten).
Der riege Vorteil ist: niemeand braucht etwas an seinem Router zu konfigurieren und, wenn man mal woanders ist mit seinem softphone www.phoner.de fertig konfiguriert auf einem USB-Stick läuft es garantiert.
Nein, diejenigen Provider, die private IP-Adressen einfach ablehnen, anstatt in diesem Fall einen intelligenten Mechanismus greigen zu lassen sind Mist.

Gruß,
Pfeffer.

 

[betateilchen]

Er funktioniert durch jedes NAT hindurch, ohne irgendwelche Einstellungen vornehmen zu müssen.

:lach: :lach: :lach:

 

[pfeffer]

hey, betateilchen, das stimmt!
hinter dem kompliziersten NAT, das zweifelsohne das symmetrische NAT ist, geht es vollkommen problemlos, ohne irgendwelche Einstellung vorzunehmen (d.h. man DARF KEINEN STUN-Server angeben und muss bei X-Lite die automatische IP-Adressenerkennung deaktivieren).

Gruß,
Pfeffer.

PS: Falls Du mir ein Gegenbeispiel nennen kannst, lasse ich mich gerne vom Gegenteil überzeugen. Dann gehen wir die Einstellungen durch.

 

[der_Gersthofer]

[...] (Probleme können nur noch wegen einer evtl. instalierten Firewall auftreten).

Das tolle ist ja nur, dass die meisten Leute eine Firewall haben (die nicht sip-aware ist) und die nicht unbedingt abstellen wollen... Und genau deswegen brauch ich ja auch u.a. STUN um ein Loch in der Firewall zu öffnen. Außerdem wäre mir das auch neu, dass Sipgate nun keinen STUN-Server mehr benötigen würde. Ihre ganzen Anleitungen auf der Homepageseite beschreiben immer den Eintrag des STUN-Servers (habe dazu gerade noch einmal nachgesehen, schau einfach noch einmal nach, z.B.: https://secure.sipgate.de/user/configuration.php?show_conf=ata486.
Überall der Sipgate-STUN-Server eingetragen.
Und deswegen sind wohl auch im SIPURA die ganzen NAT Einstellungen und NAT Keep Alive Enable auf "yes" gesetzt? https://secure.sipgate.de/user/configuration.php?show_conf=sipura
Ich kann deine Aussage ehrlich gesagt nicht glauben, aber zurück zum eigentlichen Thema:


Sipgate, Nikotel usw. arbeiten mit freien RTP-Proxies, das ist schön für alle Kunden, die ihre private IP im Contact Header nach außen geben, nur: Die Sprachqualität leidet dann natürlich wenn nicht außreichend freie RTP Proxy Kapazitäten vorhanden sind (was wieder eine Kostenfrage für Sipgate, Nikotel und Co ist, weshalb hier eher kanp kalkuliert werden dürfte).

Aber darum geht es mir auch nicht (nur). Warum z.B. wird ENUM nicht voll unterstützt (und stattdessen ein eigener closed ENUM-Dienst aufgebaut)? Warum z.B. erfordert Sipgate die Übermittlung des Usernamens im Klartext und warum ist nicht - so der Standard an den sich auch fast alle anderen Provider halten - schon aus Sicherheitsgründen "username encryption" möglich?
Warum ist bei Nikotel ein ENUM-Eintrag auf deren [email protected] faktisch nicht möglich und wird abgewisen wenn der Anruf nicht aus dem Nikotel-Netz kommt?

Das sind alles so Dinge. Ich fordere nichts unmögliches, nur das Einhalten von Standards.

 

[pfeffer]

zu NAT: glaub meine Aussage ruhig, oder probier's selbst aus. Wenn sipgate merkt, dass eine private IP verwendet wird, dann schaltet es automatisch eine rtp-Proxy ein. Mit Firewall, da kannst Du schon recht haben. Scheiß Firewalls. Die blockieren zum Teil Sachen, die explizit freigegeben sind.

ja bei ENUM usw. kann ich Deine Forderung nur unterstützen. Bei der Möglichkeit von extern erreicht werden zu können ebenfalls.
Aber was ist "username encryption" und wofür ist das da? - welche Clients unterstützen das?

Gruß,
Pfeffer.

 

[markbeu]

Ich glaube eher, das es bei BlueSip auch zu massiven Probs kommt, sobald die endlos Kunden haben, wie all die anderen gaengigen VoIP-Provider.
Ausserdem denke ich auch, dass viele probs durch miserable Hardware /Software bzw. den Enduser produziert werden....

Nur als Bsp: Mit Grandstream- ATA und D-Link-Router hatte ich nix als Probs, mit der jetzigen Kombination laeuft sogar Sipgate wieder astrein bei mir. ;-)

 

[der_Gersthofer]

Wenn sipgate merkt, dass eine private IP verwendet wird, dann schaltet es automatisch eine rtp-Proxy ein.

Genau das habe ich schon in meinem ersten Beitrag geschrieben mit freien RTP Proxies. Und genau das ist nicht besonders "toll", sondern führt letztlich dazu, dass die Sprachqualität schlechter wird, denn je mehr Gespräche über diese RTP Proxies laufen desto schlimmer. Jeder Provider wird aus Kostengründen eher knapp kalkulieren und eher weniger als mehr RTP Proxy Kapazitäten bereithalten. Das ist aber übrigens auch nichts besonders Sipgate Innovatives (wie von dir suggeriert) sondern machen sehr viele Provider wie auch Nikotel, sipnsip, purtel usw.

Man sollte also lieber auf die Standards setzen die da eben lauten: eine private IP kann nicht herangezogen werden. Nur so ist eine Interoperabilität sichergestellt.
Nach gut 1 1/2 Jahren VoIP-Erfahrung bin ich persönlich ziemlich genervt davon, dass die Provider sich nicht an die Standards halten sondern viele in vielen Bereichen ihr eigenes Süppchen kochen und daher immer wieder neue Probleme auftauchen (aktuell kann ich z.B. über Sipgate keine Mobiltelefone anrufen, alles andere (Festnetz, intern, 1000) geht und auch mit allen anderen Providern geht es - aber das wird jetzt OT).

QSC z. B. versteht wieder kein "Langer SIP-Contact (RFC3840)" und so zieht sich das durch viele Provider; der eine hält sich da nicht, der andere dort nicht an die Standards und die Folge ist bei jedem User und bei jedem Endgerät anders. Ich will nicht sagen, dass ansonsten alles in Butter wäre denn auf Routerherstellerseite / Endgeräteherstellerseite hakt es sicher auch, aber es wird nicht dadurch besser, dass sich die Provider (auch) nicht an die Standards halten.

 

[pfeffer]

1. Bei Anrufen auf das PSTN wird die Bandbreite bei dem VoIP-Provider sowieso benötigt. Das ist - zumindest bei mir - immernoch der Großteil der Anrufe.

2. Wenn beide Seiten im Internet sind und auf beiden Seiten ein symmetrisches NAT läuft gibt es keine Möglichkeit, ohne Portweiterleitungen mit einander zu kommunizieren, außer über einen rtp-Proxy. Da hilft STUN nichts.

3. Alle Linux-Router machen symmetrisches NAT (iptables). Ich weiß nicht, wie es ansonsten aussieht, wie häufig symmetrisches NAT ist. Aber wenn es sehr verbreitet ist, dann kommt man (will man keine Portweiterleitungen den Leuten zumuten) ohne rtp-Proxy nicht aus.

4. Portweiterleitungen für SIP sind Mist, weil es vom Client abhängt, welche Ports weitergeleitet werden müssen. Und wenn man mehrer Clients hinter 1 NAT hat, muss man die auch noch bei den Clients unterschiedlich konfigurieren (können).

Also bei allen anderen Sachen stimme ich Dir ja zu...
Aber erklär mich doch noch bitte (vielleicht in einem anderen Thread), was "username encryption" ist, und wozu es dienen soll.

Gruß,
Pfeffer.

 

[der_Gersthofer]

Zu "username encoding" vgl. http://www.ip-phone-forum.de/forum/viewtopic.php?t=18044

Symmetrisches NAT ist nicht sonderich verbreitet; ja da geht es nicht ohne Proxy Server, aber dann sollte man gleichwohl zu den wenigen Leuten die symmetrisches NAT haben sagen, ihr müsst einen eigenen Proxy betreiben oder eben ordentliche Portweiterleitung machen (was zugegen schwierig ist), aber wer kein sauber konfiguriertes System mitbringt muss sich darum eben erst einmal kümmern. Das ist ja auch kein reiner Selbstzweck sondern würde die Systeme der Provider auch entsprechend entlasten und so mehr Kapazitäten für andere Dinge bereithalten.
Ohne das Einhalten von Standards wird das nie eine verlässliche Technik werden (wenn man mehrere Provider einsetzt und mehrere Clients betreiben will; wenn ich nur einen Client betreibe und nur bei einem Provider bin und dann vielleicht noch dessen extra für diesen hergestellten Router/ATA nutze geht es natürlich).