SIP URIs nicht mehr erreichbar?

Hab ich auch bekommen. Hatte dort einen Sipgate-Eintrag.
g.
 
Antwort von Sipgate

hab gerade an Sipgate ein Mehl gschickt und in nicht einmal 1 Minute folgende Anwort bekommen:
Hallo Herr Sch****,
wir haben aus Sicherheitsgründen die Unterstützung für nicht authentifizierte Anrufe eingestellt.
Mit freundlichen Grüßen
Was ist an URI-Calls "unsicher"?
Was sind "nicht authentifizierte Anrufe" ? Vorratsdatenspeicherung und G.W.Bush lassen grüßen!
g.
 
Zuletzt bearbeitet:
Bei mir war die E-Mail um 2:53 eingegangen. Ich hatte mal eine Nummer angemeldet, die eine @sipgate.de eintrag hatte, habe ich glatt vergessen zu ändern. Naja jetzt zeigt die ENUM auf die Dus.net SIP URL und alles läuft bestens.

@gogosch:nicht authentifizierte Anrufe sollen Werbeanrufe sein. Davon hatte ich 2 Stück, war ich aber mein Fehler, hatte die SIP URL offen im Internet stehen gehabt :(
 
Bei mir funktioniert alles noch einwandfrei

:)

Also ich versteh die ganze Aufregung nicht, also wenn ich das richtig verstanden habe , hat sipgate veranlasst das Ihre Nummern nicht mehr direkt von SiP zu SiP erreichbar ist und somit Ihr Netz abschottet. Richtig?

Aber meine Anrufe von meinem SiPHome Account zu meiner Sipgate Nummer sind trotzdem kostenfrei. Ich denke es liegt daran das SiPHome für Enums diese arpa-Domains nutzt, und hier habe ich als Zieladresse entsprechend meine sipgate-adresse hinterlegt. Und es wird tatsächlich kostenfrei verbunden obwohl die "Festnetznummer" von Sipgate angewählt wird.

Leider weiß ich nicht wie es umgekehrt ist , d.h. wenn man mit einem sipgate account direkt die sipadresse von siphome oder einem anderen anbieter anwählt, ob dies auch einwandfrei funktioniert:confused:

Vielleicht hat ja einer von Euch Profis damit schon Erfahrung gemacht, würd mich freuen da ein Feedback zu erhalten.

Zur Info über Phonerlite bekomme ich bei erfolgreiche Registrierung beider Accounts, einmal auf der Fritzbox siphome und auf dem Rechner Phonelite Sipgate, nur ein besetztzeichen, wie gesagt umgekehrt über das Telefon das an die Fritzbox angeschlossen ist klingelt es am Rechner(phonerlite);)

bis denn und gruß

Away
 
nixgegendenise schrieb:
Aber so lange es Menschen gibt, die glauben, es kostet den Provider Geld, wenn man von einer SIP-Adresse zu SIP-Adresse anruft, kann man Usern wie dir wohl alles andrehen und wahrscheinlich bald auch GEld dafür verlangen. :rolleyes:

Da die meisten hinter einer NAT stecken wird ein großer Teil der Gespräche warscheinlich über den Outbound-Proxy des Providers geleitet.
Das kostet den Provider Trafic, Hardware, Verwaltung, Wartung...
Außerden musste der Provider für deine Rufnummer bezahlen die du beim erstellen des Accounts bekommen hast. Ob du diese nun nutzt, oder nicht.
Die Datenbanken in denen dein Account gespeichert ist und deren Pflege sind für den Provider ebenso wenig kostenlos.
Sobald dein IP zu IP Gespräch aus irgendeinem Grund nicht perfekt ist, bemühst du den Support. Auch dies wird das betroffene Unternehmen wohl etwas kosten.

Aber solange die "Geiz ist geil" Menschen glauben dass ihnen alles umsonst in den Allerwertesten geschoben werden muss, sind dies warscheinlich alles leere Argumente die nicht zählen.
 
Warum sollte, nur weil ich hinter einem NAT stecke, der Traffic über einen Proxy geleitet werden müssen? Soweit ich die Routing- und NAT-Mechanismen verstanden habe, ist das nicht nötig. Ich habe jedenfalls in keinem meiner Softphones, die allesamt hinter einem NAT (FBF 7170) laufen, einen Proxy konfiguriert - und ich kann einwandfrei telefonieren.
 
Das stimmt zwar generell, wenn wir uns das Thema dieses Threads anschauen, dann geht es jedoch um sipgate, d.h. Adressen der Form [email protected]. Hier ist der Provider mit seinem Proxy im Spiel.

Das hat nun aber nichts mit NAT zu tun, sondern einfach nur mit der Tatsache, daß eine SIP-URI von einem Provider verwendet wird.

--gandalf.
 
@Adrian_fe

Dein permanentes Ignorieren der tatsächlich vorgebrachten, gerechtfertigten Kritikpunkte und das verdrehen der selbigen, um die Kritiker hier manipulativ in eine bestimmte Schublade zu zwängen lassen Dich, Deine Postings und vor allem die Motivation dahinter in einem =sehr= merkwürdigen Licht erscheinen.

My 2c.
 
Vollzitat vom Beitrag direkt drüber entfernt, siehe Forumregeln. Ghostwalker

Vielleicht ist unser Adrian_fe selber Provider oder sipgate-Mitarbeiter?
g.
 
Nach Aussage eines Sipgate-Mitarbeiters auf der diesjährigen CeBIT mir gegenüber haben sie absolutes Schreibverbot für dieses Forum. Von daher glaube ich zumindest letzteres nicht.
 
[Oftopic]
Genau sowas versteh ich nicht, warum haben die schreib verbot für Voip Foren.
Genau hier könnten sie sich besser mit denn Usern und deren Probleme mit Sipgate beschäftigen und zu einer lösung führen.
[/Oftopic]
 
Wegen des Schreibverbots musst Du Dich schon mit der Geschäftsleitung von Sipgate auseinander setzen - das kommt definitiv nicht von uns. Mitlesen tun hier übrigens viele Sipgate-Mitarbeiter, auch der Support. Es gibt wohl kaum eine bessere Quelle für Störungsmeldungen, mal abgesehen von den Meldungen, die direkt eingereicht werden.
 
@ Adrian_fe

über den Proxy geht i.A. nur der Signalisierungsverkehr (SIP), also ein paar (ca 12) Pakete pro Anruf und daher zu wenige, um Traficmäßig relevant zu sein im Gegensatz zu den NAT-keepalives alle 30 sec.

Der Sprachkanal (RTP) geht i.A. direkt von Teilnehmer zu Teilnehmer, auch unter Verwendung eines VoIP Providers, ausgenommen die sehr raren Fälle, wo der Provider einen RTP-Proxy anbietet; und ich habe nichts dergleichen bei sipgate bemerkt.

schufti
 
In der Meldung "sipgate sperrt Anrufe aus dem World Wide Web" auf
http://www.teltarif.de/arch/2006/kw33/s22737.html nimmt Sipgate offiziell Stellung zur Sperrung:

"Nach Angaben von sipgate-Sprecher Wilhelm Fuchs dient die Maßnahme dem Schutz der Kunden und des eigenen Netzes. Bei e164.org hätten die User ihre Einträge selber editieren können. Dazu sei es teilweise zu Fehleingaben gekommen, wodurch die Nutzer nicht mehr erreichbar gewesen seien. Zudem diene die Sperrung zum Schutz vor Internetanrufen aus beliebigen Netzen. Hier könne es leicht zum Missbrauch kommen, hieß es. Daher habe man sich entschieden, URI-Anrufe nur noch aus den Partnernetzen, mit denen man in Kontakt stehem, zuzulassen."
 
Bei e164.org hätten die User ihre Einträge selber editieren können. Dazu sei es teilweise zu Fehleingaben gekommen, wodurch die Nutzer nicht mehr erreichbar gewesen seien.
Tolle Logik, wenn dann durch eine Abschaltung ohne jede Ankündigung alle anderen Nutzer mit richtigem Eintrag auch nicht mehr erreichbar gemacht werden. Nach der gleichen Logik werden demnächst auch die Telefonnummern abgeschafft, weil ich ja eine Rufumleitung auch selbst editieren kann und dabei Fehler machen kann.
Daher habe man sich entschieden, URI-Anrufe nur noch aus den Partnernetzen, mit denen man in Kontakt stehem, zuzulassen.
Anrufe aus Partnernetzen sind keine URI-Anrufe.

Mit solchen Pressemitteilungen macht sich Sipgate in meinen Augen nur lächerlich.
 
KuniGunther schrieb:
Anrufe aus Partnernetzen sind keine URI-Anrufe.
Kommt drauf an, wie die Anrufe realisiert werden. Es ist durchaus möglich, solche Anrufe als URI-Anrufe zu routen. Passende SIP-Rewrite-Regeln machen's möglich.
 
Das ist schon richtig, aber solange ich nicht [email protected] eingeben kann, ist es für den Nutzer kein URI-Call. Anrufe über SIP gehen im Endeffekt natürlich immer irgendwie über eine SIP-URI.

Z.B. kann ich über Web.de meine Sipgatenummer kostenlose erreichen, aber eben nicht [email protected]. Über einen anderen Provider muss ich eine Vorwahl eingeben. D.h. ich müsste in meinen Telefonbuch mehrere Adressen haben, um jemanden bei Sipgate anzurufen, je nachdem wie der Ruf rausgehen soll.
 
Zuletzt bearbeitet:
Ghostwalker schrieb:
Warum sollte, nur weil ich hinter einem NAT stecke, der Traffic über einen Proxy geleitet werden müssen?
Weil sonst die Sprache nicht oder nur in eine Richtung übertragen werden kann. Die Signalisierung geht sowieso über den Provider. Allerdings gibt Dein Softphone hinter dem NAT im SDP-Teil des SIP-Pakets eine Adresse und einen Port mit, wo RTP-Daten hingeschickt werden sollen. Nach dem "Austritt" aus dem NAT stimmt mindestens der Port nicht mehr (Port-Forwarding ausgenommen). Deshalb schreibt der Provider das Paket um und sagt der Gegenstelle, sie soll doch bitte ihre RTP-Pakete an einen eigenen Server des Providers schicken. Bei der Antwort der Gegenstelle nochmal das gleiche. Nun reden die beiden Seiten nicht mehr direkt sondern über den RTP-Proxy des Providers. Und der Betrieb solcher Server kostet den Betreiber natürlich auch Geld.

Kannst Du testen, indem Du zwischen zwei X-Lites telefonierst. Dann schaust Du Dir mal mit F9 den Log davon an, da steht dann im einkommenden INVITE garantiert eine andere IP-Adresse im SDP als im ausgehenden INVITE, bei Sipgate bestimmt irgendwas mit 217.10.x.y. Damit hast Du gerade einen RTP-Proxy gefunden.

Und ich kann Dir nochwas sagen. Wenn jetzt erstmal das mit der Überwachung richtig losgeht, dann wirds richtig lustig. Dann werden noch viel mehr Gespräche über den Proxy geleitet, damit man die dort abgreifen kann.

Soviel mal von nem Studenten, der sich für die Uni recht intensiv mit SIP auseinandersetzen musste.
 
Da hast Du wohl das Kapitel über STUN überschlagen. NAT-Router sind kein Grund für RTP-Proxies, da eigentlich alle Clients STUN unterstützen. Meine X-Lites (beide hinter NAT) kommunizieren wenigsten munter direkt miteinander. (Und im Gegensatz zum dus.net-Server habe ich den Sipgate-Server noch nicht als RTP-Proxy arbeiten sehen.)

Zur Überwachung: Wenn ich meinen Provider als PSTN-Gateway nutze, dann geht sowieso der komplette Traffic über ihn. Und wenn ich bei direkten SIP-Calls die Überwachung umgehen will, dann brauche ich ja keinen Provider zu nutzen.
 

Neueste Beiträge

Statistik des Forums

Themen
244,950
Beiträge
2,221,421
Mitglieder
371,720
Neuestes Mitglied
Den Afleck
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.