[Frage] Provider mit korrektem From: Header für eingehen SIP Traffic

[Stefanix]

Sipgate.de macht's, Dus.net macht's auch:

Der From: Header für eingehenden SIP Traffic wird verhunzt!
Ein eingehender Anruf von user@providerY wird bei Sipgate als [email protected] im From: Header übertragen. Bei Dus.net ist's [email protected]!
Ein direkter Rückruf ist daher nicht möglich.
Einzig bei Voxalot ist's korrekt. Die haben aber keine PSTN Nummern.

Gibt's einen brauchbaren Provider in Deutschland, der PSTN Nummern hat, eingehenden SIP Traffic erlaubt und auch korrekt behandelt?

Ich weiss, SIP-SIP Traffic ist nicht gewollt, bringt kein Geld. Wird aber immer relevanter. Und bei Flatrates, bzw. "plus" Tarifen mit Grundgebühr sollte das doch auch mit drin sein und korrekt arbeiten.

Ist's nicht gewollt oder nicht gekonnt (oder beides?)

Danke!
-Stefanix

 

[Ziil-IT Support]

Hallo Stefanix, aus Gallien? ;-)

ja gibt es bestimmt, man muss sie nur alle ausprobieren...

 

[Timmbo]

Hallo,

wenn der Call aus dem Festnetz kommt und daher kommt er meistens, ist das schon richtig, da der VoIP-Übergabepunkt eben bei sipgate usw liegt.
Was soll denn Deiner Meinung nach stehen, wenn der Call aus dem PSTN Netz kommt?

Grüße
Timm

 

[Ziil-IT Support]

Er möchte bestimmt, dass dort der Header des anrufenden Providers des Anrufers steht...

Ruft z.B. ein Teilnehmer von bellsip auf seiner VoIP-Leitung an, möchte er das dort [email protected] im Header steht und von seinem Provider auch durchgereicht wird.

 

[Timmbo]

Hallo,

ja das dachte ich mir, hat Er aber nicht geschrieben.
Das würde aber nur gehen, wenn der User vom Bellsip den Call über VoIP an seinen Provider übergibt, sobald er über das PSTN Netz geroutet wird, ist es damit vorbei.
ENUM wäre dafür gut geeignet, doch leider ist das ja bei Euch in DE quasi nicht in Verwendung, im Gegensatz zu AT. Wir haben genau soviel ENUM-Einträge wie DE, aber DE hat 10x soviel Einwohner.

Grüße
Timm

 

[Ziil-IT Support]

Das mag sein, es gibt finanzielle Gründe dafür, warum man das in DE nicht macht ;-)

 

[Timmbo]

Hallo,

das versteh wer mag, bei Euch gibt es doch eh lauter Flatrates.
Bei uns gibt sogar ein paar Provider die das anbieten und die bekommen natürlich dadurch auch mehr Kunden.
Das i.d. Regel die Provider dafür nicht sind ist mir schon klar, da muß halt der Kunde selbst, oder ein Dienstleister der das für Firmen einrichtet, das mit anbieten.
ENUM wird mit Sicherheit nicht von den Providern angeboten, das muß man schon selbst in die Hand nehmen.

Grüße
Timm

 

[Stefanix]

Hallo Timm, ich schrieb "eingehenden SIP" Traffic, nicht PSTN. Die Enum Abfrage hat damit weniger zu tun. Es geht ja auch um den From: Header, nicht den To: Header.
Gut, bei numerischen User IDs könnte der Provider (also Sipgate bzw. Dus.net in diesem Fall), davon ausgehen, dass dies PSTN Nummern sind, und für diese einfach die eigenen Serveradresse ranhängen. Beim Rueckruf würde das evtl. ein kostenpflichtiges PSTN Gespräch. Bei meinen Tests handelte es sich aber um alphanumerische IDs, d.h. 100% SIP. Und die sollten nicht verändert werden.
Wer hier also was besseres als Sipgate oder dus.net kennt: Sachdienliche Hinweise werden mit "Dankeschön" belohnt!

 

[stinkstiefel]

Schon mal darüber nachgedacht was dir die SIP-URI nutzt wenn du sie eventuell nicht direkt erreichen kannst?

 

[Stefanix]

Schon mal darüber nachgedacht was dir die SIP-URI nutzt wenn du sie eventuell nicht direkt erreichen kannst?

Nö. Warum sollte das auch nicht möglich sein, ausser der UA ist nicht registriert, oder irgendwas ist faul. Ich weiss nur, dass ich garnicht zurückrufen kann, wenn ich nicht die SIP-URI des Anrufers korrekt übermittelt bekomme.

 

[stinkstiefel]

Ausser "nicht registriert" und "irgendwas ist faul" fällt mir noch ein weiterer Grund ein. Mit [email protected] oder [email protected] bist du ja noch nicht ganz am Ziel. Nun überlege mal was die Gegenstelle ggf. mit deinem Verbindungsverlangen, zu einer dieser Adressen, mit deiner Antwortadresse [email protected] macht.

 

[Stefanix]

Mit [email protected] oder [email protected] bist du ja noch nicht ganz am Ziel.

Natürlich nicht, weil das FALSCH ist!

[email protected] (Beispiel) ruft mich unter [email protected] an.
dus.net macht daraus [email protected] im From: Header.
Das ist definitiv falsch, ich kann nicht zurückrufen. Würde die korrekte SIP-URI im From: Header stehen, könnte ich das.

 

[stinkstiefel]

Natürlich nicht, weil das FALSCH ist!

Ich hätte auch [email protected] schreiben können. Probiere es einfach mal aus dann verstehst du vielleicht was ich u.a. mit Ziel meinte.

 

[Andre]

Echtes From: z.B.: [email protected]
Wenn das vom Sipprovider übermittelt würde, wäre ein Rückruf erst recht nicht möglich. Der Domainanteil ändert sich mit jeder neu zugewiesenen IP.
Woher soll der SIP-Provider denn wissen, dass man zusätzlich noch eine DynDNS betreibt oder zu den glücklichen mit fester IP zählt?
Klar, wenn der Anrufer einem Asterisk betreibt, kann er dies setzen. Aber 99% der VoIP-Nutzer tun dies nicht.
Wer eine FritzBox fon betreibt, von dem weis der Sipprovider Nutzernamen und IP. Das hilft dem Angerufenen wie gesagt, nicht wirklich weiter.

Wenn beide DynDNS haben (ggf. für die zweite PVC!), dann muß man eben den Anruf direkt durchführen - womit auch der Rückruf diesen Weg gehen würde.

 

[Stefanix]

Also, Andre, [email protected] ist natürlich kein "echter" From: Header. Aber das war wohl nicht ernst gemeint.
Jetzt verstehe ich, in welcher Weise ich wahrscheinlich missverstanden wurde. Ich beziehe mich beim From: Header NICHT auf die SIP URI, die beim Registrieren benutzt wird (die sieht natürlich niemals so aus, wie von Andre geschildert). Vielmehr möchte ich die öffentlich erreichbare Adresse erhalten. Die KANN mit der bei der Registrierung verwendeten Adresse übereinstimmen, muss es aber nicht.
Beispiel: Ich registriere mich bei Sipgate.de mit [email protected]. Damit erreicht Sipgate meinen UA, aber ankommende SIP calls bei Sipgate damit werden mit 404 beantwortet. Meine öffentliche SIP URI bei Sipgate ist [email protected].

Nun aber zurück zum Problem: jemand mit einem reinen SIP account bei einer Firma, URI sip:[email protected] kann mich bei Sipgate unter obiger URI erreichen. Der From: Header wird korrekt an Sipgate übermittelt. Sipgate schickt an meinen UA aber sip:[email protected]! Das ist inkorrekt, und die übermittelte Adresse kann ich nicht zum Rückruf nutzen. Dus.net setzt noch zwei Nullen vorne ran und nimmt den Punkt weg: [email protected].

Nun habe ich noch weiter probiert und festgestellt, dass es letztendlich nicht so wichtig ist, da beide Provider offensichtlich sowieso keine abgehenden Anrufe per SIP URI zulassen.
Jetzt weiss ich wieder, warum ich Voxalot immer für meine abgehenden SIP calls benutzt habe.
Wollte aber am liebsten alles auf einem Account vereinen.

Und nun kann ich meine eigene Frage auch beantworten: BellSIP machts korrekt! Habe mich gerade registriert und es ausprobiert. Läuft gut, genauso wie bei Voxalot. Ausserdem haben die auch PSTN Nummern, sprich ein Gateway zum POTS.
Werde mir das Angebot näher ansehen und ggf. wechseln. Lieber wäre mir natürlich, ich könnte alles unter Sipgate abwickeln, wie bisher.

P.S.: Mir ist bekannt, dass ich einen UA auch direkt anrufen kann, ohne über den Provider zu gehen, DynDNS, ggf. SRV Record, etc. Das war nicht die Frage.

Gruss
Stefanix

 

[Andre]

[email protected] ist genau das Format, mit dem man einen Anruf an meine Fritzbox durchführen kann - p123456C7.dip.t-dialin.net ist das Ergebnis von tracert auf meine externe IP, also der Domainname, der zur momentan zugewiesenen IP gehört. Das ist die öffentliche Adresse des SIP-Endgerätes! Mit "Registrierungsdaten" hat das nichts zu tun.

Es ginge natürlich auch [email protected], wenn das die zugehörige IP-Adresse ist.
Für den SIP-Provider sind 99% der Kunden nur und einzig auf diesem Wege zu erreichen.

... da beide Provider offensichtlich sowieso keine abgehenden Anrufe per SIP URI zulassen...

Da wird mir lamgsam klar, wo das Problem besteht. Ein abgehender Anruf von einem SIP-Endgerät auf eine SIP-Uri geht doch meist direkt und nicht über einen SIP-Provider. Außer für Paralelruf, Rufumleitung und Telefonbuchnutzung macht das doch gar keinen Sinn, über einen SIP-Provider abgehend eine SIP-Uri anzurufen. Schade, dass Du keine Signatur hast, mich würde schon interessieren, was für ein Gerät das so abwickelt.

Wenn man natürlich SIP-Anrufe über einen Provider führen würde, dann hätte man ein vernünftiges From. Aber das ist der absolute Ausnahmefall. Der Regelfall beim Sipgerät ist, dass es die Verbindung zum Ziel direkt herstellt, wenn das Ziel eine SIP-Uri ist. Da ist das From quasi nie sicher und hat dann, wenn es halbwegs alles richtig macht, den von mir beschriebenen Aufbau.
Wenn man Pech hat: Anrufender kommt von einer Telefonanlage mit Nebenstellen hat, die den Absender nach dem Muster <NbSt>@IP aufbaut - was absolut logisch und auch richtig wäre.

Die Nebenstelle sei z.B. 1 (wie bei fon1 einer Fritz.Box). Dann hätte man als Absender ein 1@dynIP. Kann man auch nach Monaten noch zurückrufen. Mit 60%iger Wahrscheinlichkeit (Verbreitung der Fritz-Boxen in Deutschland) erreicht man auch jemanden - nur halt jemand anderen als gewünscht.

Es gibt schon Gründe, warum Sipgate (auf meine Nachfrage, wie man per SIP-Uri einen Sipgate Acount anrufen könne) [email protected] gar nicht unterstützt. Das geht nur aus "Partnernetzen".

 

[Timmbo]

Hallo Stefanix,

"eingehenden SIP-Traffic" hast du ja immer, auch wenn der Call bei Sipgate per PSTN ankommt, zu Dir wird er doch immer per SIP zugestellt.
Das Problem ist wohl aber schon erkannt, die meisten Provider lassen Calls als SIP-URI außerhalb Ihrer Netzte doch garnicht zu, also macht es doch überhaupt keinen Sinn dies auch so anzuzeigen. Dafür wäre ENUM das Richtige, denn dort stehen alle Nummern drin die "von außen" erreichbar sind, vorrausgesetzt sie sind eingetragen.

Grüße
Timm

 

[Stefanix]

Timmbo, jo, natürlich ist alles was an meinem SIP UA ankommt SIP.
Von "incoming" Traffic spricht man bei Vermittlungsstellen (also auch VoIP Providern) normalerweise bei Verkehr von anderen Vermittlungsstellen. Der Verkehr zu eigenen Teilnehmern (dazu gehören auch PBXes) ist "terminating".
Also ich bezog mich auf ankommenden SIP traffic von anderen Providern zu meinem Provider. Vielleicht sollte man mal einen Sticky Thread mit der Terminologie posten. Dann würden sich hier alle vielleicht besser verstehen. Ich machs aber auch manchmal falsch.

Viele Provider haben Beschränkungen bei incoming und outgoing SIP traffic, leider. Im geschilderten Fall geht aber der eingehende Anruf, nur der Absender (quasi die CLI) wird verdreht. Das ist unschön, auch wenn ich sowieso nicht zurückrufen kann, da ausgehende SIP calls zu beliebigen URIs unterbunden werden.

Dass es anders geht habe ich jetzt bei BellSIP gesehen. Darum gings mir hier eigentlich. Das ist ein kleiner Provider, so dass ich mir nicht sicher bin, ob die langfristig und stabilen Service bieten.

Noch kurz zu Andre: Du siehst einige Dinge falsch. Die genante URI ist mit Sicherheit nicht die URI, mit der ein SIP Provider deinen registrierten UA anruft! Ferner schickt ein UA sein INVITE immer zum Provider (SIP Server in der UA Konfiguration), nicht direkt zum gewünschten UA. Diesen "Trick" kann man mit zwischengeschalteteter PBX machen. Aber das ist off-topic, können wir vielleicht woanders diskutieren.

 

[Stefanix]

Noch was zu Andre: Ich spreche über normale SIP UAs, z.B. ein Desktop Phone, wie das GXP-2020, oder irgendein Softclient direkt am Internet (bzw. über NAT). Ich weiss nicht genau, was die diversen Fritzboxen machen. Scheinbar haben sie eine kleine PBX integriert und machen enum query selbst, lösen die SIP URI auf, etc. Dann bist du quasi dein eigener Provider. Damit brauchst du keinen externen Provider, der sich um abgehende calls kümmert. Dennoch musst du im Regelfall über den Provider des terminierenden UA's gehen. Spezialkonfigurationen sind auch hier möglich, nämlich wenn die SIP URI des angerufenen DynDNS nutzt, oder ein SRV record darauf verweist. Vernünftigerweise sollte dann auf der terminierenden Seite auch eine PBX existieren (muss aber nicht).
Das sind durchaus interessante Spielarten, bei denen wir ganz ohne Provider auskommen, solange wir kein PSTN brauchen. Der Normalfall ist das mit Sicherheit nicht. Oder liege ich da falsch und Andre's Konfiguration ist so weit verbreitet?

Nachtrag: Einige Beiträge gingen an meiner ursprüngliche Frage vorbei. Jeder ist von seiner Konfiguration als Normalfall ausgegangen. Aber Dank dieser Diskussion ist die Fritzbox in mein Blickfeld gerückt. Eigentlich wollte ich keinen SIP Server zu Hause betreiben, und das den Providern überlassen, die ich für PSTN sowieso brauche. Andre's Bemerkungen haben mich aber nachdenklich gemacht. Die FritzBox scheint ja eine tolle Kiste zu sein, und vermutlich auch einfach administrierbar. Muss also her!
Danke für die Anregung!

 

[Andre]

Klar, wenn Du Softphones oder Endgeräte hinter einer NAT betreibst, ist die Abwicklung über einen SIP-Provider natürlich Plicht. Eine eingehende Gesprächssignalisierung von einer anderen Quelle könnte von der NAT nicht zugeordnet werden (außer für genau ein Endgerät, wenn man Portweiterleitung betreibt).
Die FritzBox ist in ihrer ursprünglichen Version kein SIP-Server (die neueren haben jedoch einen eingebaut), sondern haben schlicht nach außen eine echte IP. Damit kann - wie es SIP vorsieht - der Rufaufbau direkt zwischen Endgeräten erfolgen.
Der ganze Aufbau über Provider auch bei reinen VoIP-Verbindungen ist eigentlich nur ein Workaround, um die NAT-Problematik zu umgehen - nebenbei reduziert es die Gefahr des Telefonspams (in der Hinsicht ist es sogar Positiv, wenn nur Partnernetze erlaubt sind, über die Rückverfolgung des Anrufers möglich ist).
Es bleibt abzuwarten, wie es mit IP6 wird - in dem Moment werden SIP-Provider eigentlich als Zwischenstelle überflüssig. Mittels SIP-Uri wären dann grundsätzlich auch interne Telefone direkt ansprechbar.
Wenn man SIP-Calls über einen SIP-Provider führt, bekommt der eigene Provider einen SIP-Call, der als Absender die eigene IP, den Port, den Nutzernamen und das Kennwort enthält. Der eigene SIP Provider liefert dem Angerufenen dann eine SIP-Uri in Form von benutzer@providerdomain. Damit wird aber auch das aufgebaute Gespräch (SIP dient ja nur dem Gesprächsaufbau) über den eigenen Provider abgewickelt (er teilt ja die wirkliche Quelle des Anrufs nicht mit). Man hat dann zwei VoIP-Verbindungen, eine zwischen einem selbst und dem SIP-Provider (From aus Nutzername, IP, Port) und eine zwischen dem eigenen SIP-Provider und dem Ziel (From aus Nutzername und Domain des Providers)
Das letzte war es, was mich verwirrte bei der Fragestellung. Ein SIP-Provider ändert, wenn man über ihn telefoniert, zwangsläufig das From. Täte er es nicht, entstünden die von mir beschriebenen Probleme.

Dass Sipgate das From auch bei Anrufen über SIP von anderen SIP-Providern ändert, ist ein Bug. Der liegt aber daran, dass Sipgate den Anruf über SIP-Uri nicht unterstützt (Thema kostenlose Telefonspam).

Bei unverändertem Header bestehen aber (neben der Gefahr des Telefonspams wie immer, wenn eine Verbindung kostenlos ist), die von mir beschriebenen Risiken (DynIP).

Zur Verbreitung: Anrufe über SIP-Uris sind generell wenig verbreitet, da man sie an klassischen Telefonen so schwer wählen kann. Selbst nutze ich sie z.B. nur intern und für 2-3 externe Ziele (mit dem Umweg über das Telefonbuch in meiner Fritz). Daher wählen die meisten einfach eine Zieltelefonnummer - ob der Provider dann via VoIP weitergeht, ist dem Nutzer egal.

Wenn man schon eine SIP-Uri als Ziel hat, dann stellt sich die Frage, wie das Telefoniegerät damit umgeht. Ich vermute mal, SIP-Telefone, die direkt an einen Provider angemeldet sind, führen das Gespräch zwangsläufig über den eigenen SIP-Provider (wegen NAT). Die Fehlermeldungen von Softphonenutzern, die sich wundern, zwar einen Anruf aufbauen zu können, aber keine Sprachverbindung, weil sie nicht über einen SIP-Provider gingen, sind bekannt. Umgekehrt aber eben auch, dass bei Nutzung des SIP-Provider Geld berechnet wurde.

Nutzer von Telefonanlagen, die auch DSL-Router sind, können Gespräche zu SIP-Zielen auch aufbauen, wenn man gar keinen SIP-Provider eingetragen hat - die versuchen also den Aufbau direkt (was auch sinnvoll ist, bei geschlossenen Partnernetzen aber dazu führt, dass das Ziel nicht erreichbar ist. Dafür kann es nicht passieren, dass - wie bei 1&1 - plötzlich interner Gespräche kostenpflichtig werden). Dann ist "From" aber das des Endgerätes. Im Gegensatz zur Telefonie über einen SIP-Provider ist das immer kostenfrei.

SIP beschreibt ja nur den Verbindungsaufbau. Bei Telefonie über den SIP-Provider werden zwei-drei SIP Sessions gestartet (Anrufer - SIP-Provider - (SIP-Provider des Angerufenen) - Angerufener). Jede der drei Verbindungen kann ein individuelles From und To haben. Wenn ich das jetzt richtig sehe, bezog sich Deine Frage darauf, warum das From der dritten Verbindung bei Sipgate verändert wird. Meine Antwort darauf war letzlich, dass Sipgate bei der ersten Verbindung das From immer ändern muss und den Sonderfall einer eingehenden SIPverbindung gar nicht vorsieht. Was ja auch gar nicht nötig ist, es heist ja SipGATE, ist also primär ein Gateway zu anderen Telefonsystemen (POTS).

Enum wird von aktuellen FritzBoxen übrigens nicht mehr unterstützt. Zu wenig Bedarf. Direkter SIP-Aufbau ist aber immer noch möglich.
Wenn man bei einem Provider mit 2.PVC für VoIP ist, muss man direkt in die Config-Dateien. Dort kann man einzelnen SIP-Accounts (die sich übrigens nicht registrieren müssen, es reicht, wenn sie eingetragen sind, um ein und abgehend reine SIP-Anrufe zu starten und anzunehmen) gezielt auf die erste PVC legen. Man kann auch - wenn die 2.PVC eine echte IP hat - einen gesonderten DynDNS für Telefonie einrichten.

Freut mich, wenn die Diskussion Dich auf die FritzBoxen aufmerksam gemacht hat. Ich habe davon inzwischen rund 30 Stück in verschiedenen Nutzungen (O.K. einige nur noch als Deko...)