Rufumleitung: Anrufer zahlt Mehrkosten

[hlm]

Hallo,
experimentell habe ich folgendes festgestellt: Wenn ich (A) einen Teilnehmer B per SIP anrufe und der hat in seinem SIP-Telefon, z.B. SJPhone, eine Rufumleitung zu einer Nummer C programmiert, dann erfolgt - anders als im normalen Festnetz, wo B den Anruf von A zu C sozusagen durchschleust - eine Aufforderung an mein Telefon (A), die Umleitungsnummer C direkt anzurufen.

Wenn A-B ein kostenloses netzinternes Gespräch ist, C aber eine (teure) Auslands- oder Handynummer ist, zahle ich also - ohne dass z.B. an meinem Grandstream-IP-Telefon das im Display irgendwie sichtbar wäre - die Kosten selbst. (Im normalen Festnetz würde B die Umleitungskosten zu C tragen!)

Zwar meldet die Cactus-PBX, die hier auf einem Win2K-PC läuft, auf der dem anrufenden IP-Telefon zugeordneten Netzwerk-Workstation die Umleitung als Warnung in einem Popup-Fenster, bei anderen Anlagen (oder auch bei Nutzung eines IP-Telefons ohne Anlage direkt am SIP-Provider) merkt man aber gar nichts - bis man dann irgendwann eine Rechnung vom Provider bekommt.

Ich halte das für eine böse Gebührenfalle. Wenn irgendwann SIP-Provider auch 0900- oder 0137-Nummern erlauben, könnte das von bösartigen Zeitgenossen schnell ausgenutzt werden (klar sind diese Vorwahlen in der PBX hier vorsichtshalber sowieso gesperrt, aber nicht jeder arbeitet mit einer SIP-Telefonanlage).

Hat jemand entsprechende Erfahrungen oder Tipps, wie man eine ungewünschte Weiterleitung bei IP-Telefonen vermeiden kann?

 

[Walde]

Mit welchem Sip Provider soll den das so gehen ?

Ist mir bis jetzt so noch nicht untergekommen.

 

[hlm]

Sorry, wenn ich mich so unverständlich ausgedrückt habe, aber das Verhalten hat mit dem jeweiligen Provider nur begrenzt etwas zu tun. Das umleitende SIP-Telefon sendet bei einem ankommenden Ruf eine Aufforderung an den Anrufer, doch bitte eine andere Nummer anzurufen. Das Grandstream-BT102, das ich hier habe, tut das dann ohne jegliche Rückfrage und ohne irgend eine Änderung der gewählten Nummer im Display.

Könnte natürlich sein, dass bestimmte Provider (welche?) Rufumleitungen generell ausfiltern, aber laut SIP-Standard funktionieren sie genau so wie oben beschrieben - und eben ganz anders als im herkömmlichen Festnetz, wo der Anrufer nie mit den zusätzlichen Umleitungsgebühren belastet wird.

 

[RudatNet]

Das solltest du nochmal bitte genauer erklären!
Wie sieht denn diese "Aufforderung" aus?

Ehrlich gesagt glaube ich das nicht so recht, weil sowas eben nicht rechtens ist.

 

[hlm]

> Wie sieht denn diese "Aufforderung" aus?

Siehe SIP-Standard, RFC 3261, z.B. http://www.ietf.org/rfc/rfc3261.txt - dort unter "13.3.1.2 The INVITE is Redirected". Das angerufene Telefon sagt damit dem Anrufer, dass der Teilnehmer unter einer anderen Nummer erreichbar ist, typischerweise mit der Antwort "302 Moved temporarily" nach dem INVITE-Kommando. Daraufhin ruft das Telefon des Anrufers selbständig, ohne manuelles Zutun, die bei der 302-Antwort angegebene Zielnummer an.

Damit zahlt der Anrufer die Gebühren zur neuen Zielnummer, und die können natürlich viel höher sein als für die Nummer, die er vorher eigentlich gewählt hatte. Das Dumme ist nur, dass er davon bei vielen Telefonen (z.B. Grandstream BT102) überhaupt nichts merkt.

EDIT (15.03.07): Tests bei den SIP-Providern DUS.NET und T-Online zeigten, dass diese eine an einem IP-Telefon programmierte Rufumleitung nicht an den Anrufenden weiterleiten. Bei DUS.NET hört man statt dessen die Netzansage "Die gewählte Rufnummer ist nicht geschaltet". T-Online liefert dagegen einfach sofort (!) einen Fehlercode 480 = Timeout zurück. Man ist sich also des Problems zumindest bei diesen Providern bewusst. Andere habe ich bisher noch nicht getestet.

 

[spongebob]

(Habe gerade meinen geschriebenen Beitrag zurückgezogen, nicht wundern, wenn Abonnenten einen anderen Text hier finden) ---

weil ich nämlich gesehen habe, dass es um Rufumleitung von SIP Telefonen geht. _Das_ ist dann natürlich möglich. Bei Anrufen über SIP in das Fest/Mobilnetz mit Rufumleitung habe ich das noch nie gesehen.

Grüsse

 

[RudatNet]

Siehe SIP-Standard, RFC 3261, z.B. http://www.ietf.org/rfc/rfc3261.txt - dort unter "13.3.1.2 The INVITE is Redirected". Das angerufene Telefon sagt damit dem Anrufer, dass der Teilnehmer unter einer anderen Nummer erreichbar ist, typischerweise mit der Antwort "302 Moved temporarily" nach dem INVITE-Kommando. Daraufhin ruft das Telefon des Anrufers selbständig, ohne manuelles Zutun, die bei der 302-Antwort angegebene Zielnummer an.

Nein, das steht da so nicht!

Da steht statt "Zielrufnummer":

... one or more URIs of new addresses to be tried...

Damit wäre die ganze Sache wieder ok, (ENUM macht's genauso)
weil direkte Verbindungen zu URIs immer kostenlos sind!
... wenn diese Verbindungen überhaupt funktionieren.

 

[spongebob]

Damit wäre die ganze Sache wieder ok, (ENUM macht's genauso)
weil direkte Verbindungen zu URIs immer kostenlos sind!
... wenn diese Verbindungen überhaupt funktionieren

Na, darauf würde ich NICHT wetten.... <sip:[email protected]> ist eine klassische URI und und wenn der A Teilnehmer auf das Redirect eingeht, hat er tatsächlich die Kosten am Hals...

Grüsse

 

[spongebob]

Man ist sich also des Problems zumindest bei diesen Providern bewusst. Andere habe ich bisher noch nicht getestet.

Aber Du hast das Problem doch aufgeworfen. Mit welchem Provider hast Du es denn beobachtet?

 

[HKindler]

<sip:[email protected]> ist eine klassische URI und und wenn der A Teilnehmer auf das Redirect eingeht, hat er tatsächlich die Kosten am Hals...

Nein, hat er nicht! Denn <sip:[email protected]> ist ausserhalb von United Internet nicht erreichbar! Und wenn es erreichbar wäre, wäre es kostenlos, da SIP-URI.

 

[spongebob]

Nein, hat er nicht! Denn <sip:[email protected]> ist ausserhalb von United Internet nicht erreichbar! Und wenn es erreichbar wäre, wäre es kostenlos, da SIP-URI.

Also ehrlich, ich verstehe hier nur Bahnhof:

Punkt 1: <sip:[email protected]> ist die SIP Repräsentation einer Nummer im T-Mobile Handynetz bei Anruf von meinem SIP Phone. Natürlich ist diese Nummer "ausserhalb von UI erreichbar", die gibbet ja. So und nicht anders sieht das im SIP aus, ggf. ist der 49er Präfix weg. Aber Fest/Handynummern sehen nun mal so aus, und nicht anders und im Sinne von SIP sind das URIs.

Punkt 2: Ein Anruf über SIP darauf kostet mich bei 1und1 ca. 20ct / Minute.

Punkt 3: Wenn der entfernte Teilnehmer ein SIP Phone wäre, z.B. ein Softphone hinter einem 1und1 Account 030wasweissich, und dieses Softphone hat eine Redirection programmiert in der o.b. Weise auf eben die o.a. Handynummer - wie sollte im SIP die Redirection-URI anders aussehen, damit eine Verbindung zustande kommt?

Punkt 4: Und wer, ausser ich, sollte bezahlen, wenn die Verbindung wie initial beschrieben eingeleitet wird?

Ich bin jetzt fast soweit, das versuchsweise mal nachzustellen.

Grüsse

 

[spongebob]

So, ich habe das jetzt mal nachgestellt und versteige mich jetzt zu der Behauptung, dass die im RFC aufgeworfene Möglichkeit des "Redirects und Anrufer zahlt" bei den gängigen Providern NICHT zuschlägt. Hier ist es so, wie man es vom klassischen FN oder HN gewohnt ist: Der Anrufer zahlt bis zum angerufenen Ziel, der Weiterleitende zahlt die Weiterleitung. Bei meinen Tests konnte ich nichts anderes sehen.

Hier: FB über 1und1 SIP Account "A" angeschlossen. Rufweiterleitung bei 1und1 von "A" nach ISDN "B" eingerichtet. Von C auf A angerufen, Anruf kommt _ohne_ Redirect bei C raus. Calling Party bei C signalisiert wird A. A bekommt von der Umleitung nichts mit (auch schade, zumindest ein NOTIFY wie im FN und HN üblich wäre nicht schlecht).

Zusammenfassung: Ich denke, der Initiator des Threads meinte nicht die Rufumleitung im klassischen Sinne (die über den Provider geht), sondern sowas wie Call Deflection am Endgerät. Das angerufene EG sagt: Nö, keine Lust, ruf doch da mal an. Wenn der A-Teilnehmer dem folgt, zahlt er immer. Aber leider habe ich hier kein Szenario, was dies nachstellen könnte.

Grüsse

 

[RudatNet]

Punkt 1: <sip:[email protected]> ist die SIP Repräsentation einer Nummer im T-Mobile Handynetz bei Anruf von meinem SIP Phone. Natürlich ist diese Nummer "ausserhalb von UI erreichbar", ...

Das kann ich absolut nicht nachvollziehen!

Habe die SIP-URI [email protected] mal ins Telefonbuch eingetragen- wobei die 0163xxxyy31 tatsächlich existiert - und zu wählen versucht!
Das ist dabei - absolut logischerwiese - herausgekommen:

17.03.07 01:12:26 Internettelefonie mit 0163xxxyy31 über 1und1.de war nicht erfolgreich. Ursache: Verboten (403)

 

[spongebob]

Welches Telefonbuch meinst Du? Aber egal. Ich hoffe, ich stifte jetzt nicht noch mehr Verwirrung...

Die SIP URI, die ich meinte, existiert nur "virtuell" In keinem Telefonbuch ist sie _so_ eingetragen. Nur zum Zeitpunkt des INVITES ist sie so auf der "Leitung": Sie ist die Repräsentation einer Handynummer, die per SIP über 1und1 angerufen wird. Gilt für jede andere FN-Nummer auch.

INVITES über andere Provider sehen natürlich anders aus: <HN/FN-Nr>@sipgate.de, <HN/FN-Nr>@dus.net o.a. Das bildet das jeweilige SIP Phone aus der eigentlichen Zielnummer und dem Realm des aktuellen Accounts.

Dein Telefonbuch hätte natürlich ohne Realm befüttert werden müssen, dann hätte das auch geklappt. Klar - normale Nummer halt, die eben keinem Provider gehört.

So, und jetzt weiter im Text der initialen Fehlermeldung. Wenn alles "normal" läuft mit der Rufumleitung, dann erkennt der Provider des Zielpartners, dass eine RU konfiguriert ist und führt den "Restanruf" on behalf of A-Teilnehmer aus (der davon im SIP leider noch nichts merkt). Die Kosten trägt der Inhaber des "Umleiter"-Accounts. Gilt im FN, HN und auch für SIP. So weit so normal.

Nun behauptete der Initiator dieses Threads, dass sein umgeleitetes SIP Zielphone den Anrufer mit einer "Moved Temp..." auffordert, doch eine andere Nummer zu wählen. Ich habe sowas noch nie gesehen, deswegen würde ich NICHT darauf wetten, dass da nicht doch eine Möglichkeit besteht, den ahnungslosen A-Teilnehmer zu einem kostenpflichtigen Anruf nach Timbuktu zu bewegen...

Ich war in meinen obigen Aussagen nicht eindeutig genug was die Geschichte Nummer <-> Realm angeht. Ich hoffe, ich konnte das jetzt
klarstellen. So verstanden hat Helmut natürlich vollkommen Recht: [email protected] existiert _so_ nicht bei UI

Grüsse

 

[alex-911]

hallo

hlm hat da vollkommen recht. im 3261 ist call diversion so definiert, dass auf ein 302 der call redirected wird. wie bemerkt wurde, ist das aus abrechnungstechnischen gründen doof für den anrufer

es gibt verchiedene ansätze, zB diversion header in SIP (draft-levy-sip-diversion). problem hier auch wieder: kein endgerät unterstützt dies, das draft hat es auch nie wirklich über den draft status hinaus geschafft. und der herr levy treibt die sache nicht weiter.


gruss
/alex

 

[RudatNet]

Wirklich sehr interesant dein Ausführung.
Nur leider habe ich kein Wort davon verstanden. :noidea:

Welches Telefonbuch meinst Du? ...

... natürlich das Telefonbuch meiner FBF.
Ansonsten habe ich überhaupt keine andere Möglichkeit, eine SIP-Adresse direkt zu wählen!

 

[KuniGunther]

Damit wäre die ganze Sache wieder ok, (ENUM macht's genauso)
weil direkte Verbindungen zu URIs immer kostenlos sind!

Nun ja ... es könnte ja jemand über ENUM eine Umleitung auf eine Service-Rufnummer unter Nutzung eines der verbreitesten Providers eintragen und dann auf die warten, die bei diesem Provider sind. Das wäre dann nicht kostenlos!

Z.B. würde die FritzBox - obwohl es direkter URI-Call ist - sich mit den gespeicherten Zugangsdaten authentifizieren, wenn der 1.VoIP Account bei diesem Provider ist - und damit diesen Call möglich machen.

 

[alex-911]

Wirklich sehr interesant dein Ausführung.
Nur leider habe ich kein Wort davon verstanden. :noidea:

du meinst meine ausführungen? es geht darum, dass derjenige, der eine rufumleitung einrichtet, auch für diese weiterleitung bezahlt und nicht der anrufer.
um das mit SIP in den griff zu bekommen, darum geht's...

gruss
/alex

 

[RudatNet]

Ja, genau das meinte ich!

Aber auch nach nochmaligem Lesen konnte ich dein jetzt beschriebenes Fazit nicht in dem Beitrag erkennen! Sei's drum.

 

[spongebob]

"Möglich, hätte, könnte"... kommt mal bitte mit ein paar Traces rüber, die die Situation zeigen. Im SIP RFC lese ich unter diesem Thema auch nur Ausführungen, die eher in RIchtung Loadbalancing beim Registrar oder Proxy zeigen, d.h. man redirected auf sich selbst...

Zeigt mal her Eure "Anrufer zahlt die Umleitung"-Traces. Ein Trace sagt mehr als tausend Worte...

Grüsse