[AUFRUF] Schaltet eure normalen Telefonnumern ENUM frei!

[RSchnauzer]

Werde ich versuchen zu reproduzieren, ich habe letzte Woche die Sicherung rausgenommen und dann festgestellt, dass der Suffix wieder zerstört war.

 

[kai66]

Hallo ENUM-Erfahrene.

Es sollen ja alle Rufnummern von FreeWorldDialup (FWD) per ENUM erreichbar sein. Ein Check bei http://enumquery.com/lookup?e164=+8781039311612&source=form&query=» zeigt auch an, das z.B. die Zeitansage von FWD per ENUM erreichbar ist.

Ich habe nun die 008781039311612 in meiner FB7170 gewählt und hätte nun erwartet, dass ein ENUM-Lookup durchgeführt wird und ich dann zur Zeitansage (Nr. 612) von FWD gelange.

Stattdessen wird schon während des Wahlvorganges von der FB von Internettelefonie auf Festnetztelefonie umgeschaltet und ich höre dann die nette Frauenstimme der T-Com mit "Kein Anschluß unter dieser Nummer".

Ich weiß, dass es sich bei der Landesvorwahl 0087 um eine Pseudenummer handelt. Hat aber jemand eine Idee, warum von der FB sofort auf Festnetztelefonie umgeschaltet wird?

 

[HKindler]

Ich weiß, dass es sich bei der Landesvorwahl 0087 um eine Pseudenummer handelt. Hat aber jemand eine Idee, warum von der FB sofort auf Festnetztelefonie umgeschaltet wird?

Vielleicht hast du eine Wahlregel Ausland (=00xxx) -> Festnetz aktiviert?

 

[kai66]

Vielleicht hast du eine Wahlregel Ausland (=00xxx) -> Festnetz aktiviert?

Da muss ich dich leider enttäuschen. Auslandsgespräche (00) führe ich über SparVoip.

Trotzdem Danke für den Hinweis.

 

[blacksun]

Da muss ich dich leider enttäuschen. Auslandsgespräche (00) führe ich über SparVoip.

Hallo Kai,

wie sorgst Du denn dafür, dass alle Auslandsgespräche über Sparvoip laufen? Hast Du dafür eine Wahlregel definiert, die alle Gespräche, die mit 00 anfangen, über den FBF-SIP-Account von Sparvoip laufen lässt?
Evtl. liegt es auch daran.
Laut diesem Link hier findet bei einer Wahlregel, die auf das Festnetz zeigt, kein ENUM-Lookup statt. Vielleicht ist das auch so, wenn man generell eine Wahlregel gesetzt hat, sprich es wird evtl auch kein Lookup ausgeführt, wenn eine Wahlregel auf eine bestimmte VoIP-Verbindung zeigt.

Ist nur so eine Vermutung.

Viele Grüße
Martin

 

[kai66]

... dass alle Auslandsgespräche über Sparvoip laufen?

Ja, ich habe eine Wahlregel, dass alle Nummern, die mit "00" beginnen über Sparvoip laufen sollen.

Wahlregeln für das Festnetz exsitieren nur bei Sonderrufnummern (z.B. 0137, 0800, Notrufe). Wenn ich z.B. die Österreichische ENUM-Testnummer (0043 720 0101011) anwähle klappt alles einwandfrei.

Merkwürdig ist auch, dass 00878... auch nicht durch einen ENUM-Lookup bei Voxalot erreichbar ist.

 

[RSchnauzer]

Abgehender SIPCall nach ENUM Auflösung

Hallo @blacksun,

Ich habe deinen Trace bekommen, der ist allerdings verwirrend:

satz 250: 169.254.2.1 ruft Sipgate.de mit meiner DYNDNS SIP-URL auf.
satz 251: der Call wird abgewiesen mit 404 unknown domain
satz 256: fragt meine Festnetznummer invite bei bei sipgate.de
wird abgewiesen mit 407 proxy failed
abfrage das oertliche?
satz 304: SIP an meine Festnetznummer
Ruf geht raus - sehe ich mit deiner Festnetznummer bei mir im JFRITZ
warum Anfrage an www.gelbeseiten.de ?
warum Anfrage an www.goyellow.de?
satz 1108: Request cancelled - aufgelegt

Warum wird nicht versucht meine URL per DNS aufzulösen?
Warum geht der sip-call an sipgate.de und nicht direkt an meine URI?
Die Box erkennt nicht, dass das eine SIP-Adresse ist?
Kannst du mal meine DNS mit nslookup überprüfen, ob dein DNS meine domain findet?

Ich schlage vor mal die URL direkt aufzurufen, mal sehen, ob das wenigstens funktioniert.
Ich sehe den Versuch dann hoffentlich in meinem JFritz.

Ich habe deine SIP-URL heute (ca. 13:00) direkt angerufen und es klingeln lassen und einen Trace gemacht.
Das sieht ganz anders und so wie man es erwartet aus.

Da wird zuerst eine DNS-Namensauflösung gemacht und dann direkt eine SIP-Verbindung angestoßen, ohne über Sipgate.de zu gehen.
Dabei wird bei mir nur der Sipgate Eintrag und als abgehende Telefonnummer meine Sipgate Nummer genutzt.
Danach klingelt es bei dir.

Am besten versucht du erst mal, ob du einen direkten SIP-Call machen kannst. Meine SIP-URI hast du ja aus dem Trace oder der ENUM Auflösung.

Ich mache den Call bei mir aus dem Telefonfuch mit der firefox-erweiterung.
mit der folgenden Nummer:*123#**736 (meine 3. Internetrufnummereintrag und 36. Kurzwahl im Telefonbuch mit deiner SIP-URL)

 

[blacksun]

Ich habe deine SIP-URL heute (ca. 13:00) direkt angerufen und es klingeln lassen und einen Trace gemacht.

Dachte ich mir fast, dass Du das warst.

Am besten versucht du erst mal, ob du einen direkten SIP-Call machen kannst. Meine SIP-URI hast du ja aus dem Trace oder der ENUM Auflösung.

Ich mache den Call bei mir aus dem Telefonfuch mit der firefox-erweiterung.
mit der folgenden Nummer:*123#**736 (meine 3. Internetrufnummereintrag und 36. Kurzwahl im Telefonbuch mit deiner SIP-URL)

Habe ich natürlich auch schon probiert.
Ich habe im Telefonbuch einen Eintrag gemacht mit 74****2@****ig47***.dyndns.org als Rufnummer und diesen Eintrag dann versucht mit **702 anzurufen.
Funktioniert aber nicht. Es kommt sofort ein Belegtzeichen.

Zu den Einträgen im Trace mit dasOertliche, goyellow, usw:
Die kannst Du getrost ignorieren. Die stammen von meinem Anrufmonitor, der bei einem ausgehenden oder eingehenden Call sofort eine Inverssuche bei den besagten Telefonbuchseiten durchführt. Das ganze hat aber wiegesagt nichts mit dem eigentlichen Call zu tun.

Wie soll ich denn mit nslookup eine Abfrage durchführen
so:
nslookup 1.2.*.*.*.*.*.*2.9.4.e164.arpa

oder so:
nslookup ****ig47***.dyndns.org
?

ersteres liefert keine ip zurück, das zweite löst zur Deiner ip-Adresse auf.

Viele Grüße
Martin

 

[RSchnauzer]

Direkter SIP-Call

Hallo blacksun,

nslookup mit dem DNS.Namen war richtig (nicht ENUM Schreibweise).
Ich verstehe nicht, warum deine Box den SIP-Call nicht direkt ausführt, sondern an Sipgate schickt.

Habe deinen 2. Trace noch nicht angesehen. Habe meinen zweiten PC gerade mit Linux laufen, um einen Speedport zu fritzen und mußte noch Eishockey in Premiere kucken.

Vielleicht weiß irgendjemand anders was eine FB daran hindern kann eine formal richtige SIP-URL bei abgehenden Call direkt zu nutzen und stattdessen an den VoIP Provider zu schicken.

Werde mir deinen Trace morgen anschauen befürchte aber, dass man da nichts findet, da das Problem vorher in der Software der Box passieren muss.

Edit: Hab mir deinen Trace angeschaut. Dasselbe Problem die SIP-URL wird mit einem Invite an Sipgate.de (Satz 149) geschickt und dort mit 404 abgewiesen. Die Box versucht nicht die Adresse nnnnn@****.dyndns.org aufzulösen und direkt anzusprechen.
Den Effekt kann ich mir nicht erklären, da brauchen wir die Hilfe von jemandem der die FB Definitionen besser kennt.
Ich weiß nicht wie man diese Funktionalität in den Definitionen aus/an-schaltet.

 

[RSchnauzer]

Hallo blacksun,

hast du bei deiner Sipgate Definition über die der Call rausgeht einen Proxy definiert?
Sieht man nur, wenn man auf -andere Anbieter- umschaltet.
Geht der Call über den ersten Anschluss raus, oder wählst du beim Call den Eintrag explizit aus?

 

[blacksun]

hast du bei deiner Sipgate Definition über die der Call rausgeht einen Proxy definiert?

Geht der Call über den ersten Anschluss raus, oder wählst du beim Call den Eintrag explizit aus?

Wie die Konfiguration bei mir aussieht, hab ich Dir gerade per PM geschickt.
Es spielt übrigens auch keine Rolle, ob ich den STUN eintrage oder ob nicht.
Den Proxy kann ich nicht weglassen, sonst ist die Rufnummer nicht mehr bei sipgate registriert.

Dieser Eintrag ist der erste Sip-Account in der FBF.
FON 1 ist standardmäßig auf diesen Account zugeordnet. Sprich ich brauche kein *12x# vorwählen, um einen Account zu benutzen. Aber wenn ich *121#**702 für den Eintrag im Telefonbuch benutze, geht auch kein SIP-Call.

Viele Grüße
Martin

 

[RSchnauzer]

Hallo,

hab mir deine Einstellungen in der PN angesehen.
Nimm mal die Einstellung proxy sipgate.de raus und nimm die Vorwahl bei der Internetrufnummer raus.
Ist bei mir nicht drin und wird glaube ich nicht gebraucht.
Und versuch dann nochmal.

Ich hab übrigens zwei Sipgate Einträge. Beim ersten hab ich lkz und okz ergänzen an und beim zweiten nicht.
Den ersten benutze ich für die normalen abgehenden calls und den zweiten für die SIP-URL Calls.

 

[KuniGunther]

Den Proxy kann ich nicht weglassen, sonst ist die Rufnummer nicht mehr bei sipgate registriert.

Der Proxy-Server ist definitiv nicht nötig. Es reicht als Registrar "sipgate.de". Sollte es ohne bei Dir nicht gehen, stimmt was nicht.

STUN ist nur nötig, wenn die Box hinter einem NAT-Router steht. Ansonsten hat sie sowieso die externe IP-Adresse. Die Ergänzung von OKZ und LKZ sollte keine Rolle spielen, da die bei direkten SIP-Calls sowieso nicht wirkt.

Dieser Eintrag ist der erste Sip-Account in der FBF.
FON 1 ist standardmäßig auf diesen Account zugeordnet. Sprich ich brauche kein *12x# vorwählen, um einen Account zu benutzen. Aber wenn ich *121#**702 für den Eintrag im Telefonbuch benutze, geht auch kein SIP-Call.

Für SIP-Calls ist die Zuordnung zu FON1 irrelevant. Es wird grundsätzlich der 1. Internettelefonie-Account als Absender gewählt. Wenn Du einen anderen möchtest, musst Du *12X# vorwählen. Die Vorwahl von *121# ist demnach gleichbedeutend mit weglassen.

Nochmal zum Proxy: In verschiedenen Firmwares wurde ein SIP-Call über den eingetragenen Proxy der gewählten Absenderadresse geroutet anstatt den direkten Weg zu gehen. Das war nicht so ganz sinnfrei, wie es scheinen mag, denn einen Proxy trägt man normalerweise nur dann ein, wenn man möchte, dass jeder Traffic für diesen Account über den Proxy geht. Wenn man das nicht möchte, konnte man ja einen anderen Account ohne Proxy wählen. In neueren Firmwares war dieses Verhalten weg und alles ging direkt. Was in der aktuellen 7050er Firmware drin ist, weiß ich nicht, das musst Du ausprobieren. Also entweder Proxy rausnehmen oder einen anderen VoIP-Account nehmen, bei dem kein Proxy eingetragen ist.

 

[blacksun]

Der Proxy-Server ist definitiv nicht nötig. Es reicht als Registrar "sipgate.de". Sollte es ohne bei Dir nicht gehen, stimmt was nicht.

STUN ist nur nötig, wenn die Box hinter einem NAT-Router steht. Ansonsten hat sie sowieso die externe IP-Adresse. Die Ergänzung von OKZ und LKZ sollte keine Rolle spielen, da die bei direkten SIP-Calls sowieso nicht wirkt.

Stimmt, da lag das Problem, dass ich den Konfigurationsvorschlag für die FBF von Sipgate übernommen habe und einen Proxy eingetragen habe. Einfach den Proxy rauslöschen hilft leider nicht. Ich habe nun einfach den gesamten SIP-Account in der FBF gelöscht und neu angelegt, und zwar ohne Proxy und ohne STUN. Dann klappte auch die Registrierung bei Sipgate.

Für SIP-Calls ist die Zuordnung zu FON1 irrelevant. Es wird grundsätzlich der 1. Internettelefonie-Account als Absender gewählt.

Echt, wird das bei SIP-Calls immer ignoriert? Und wie sieht das ganze bei ENUM aus?
Bsp.
FON 2 hat als Standard-SIP-Account den SIP-Account 5 der FBF zugeordnet. Durch die Aktivierung des ENUM Lookup findet die FBF nun eine SIP-URI heraus. Die FBF braucht für den Verbindungsaufbau zwar dann keinen SIP-Account, da es sich um ein SIP-URI-to SIP-URI Gespräch handelt. Die FBF sollte aber dann trotzdem als Rufnumer die Rufnummer von SIP-Account 5 übertragen.

Sprich welche Rufnummer wird dann übermittelt? Die aus Account 5 oder die aus dem ersten?

Nochmal zum Proxy: In verschiedenen Firmwares wurde ein SIP-Call über den eingetragenen Proxy der gewählten Absenderadresse geroutet anstatt den direkten Weg zu gehen. Das war nicht so ganz sinnfrei, wie es scheinen mag, denn einen Proxy trägt man normalerweise nur dann ein, wenn man möchte, dass jeder Traffic für diesen Account über den Proxy geht. Wenn man das nicht möchte, konnte man ja einen anderen Account ohne Proxy wählen. In neueren Firmwares war dieses Verhalten weg und alles ging direkt. Was in der aktuellen 7050er Firmware drin ist, weiß ich nicht, das musst Du ausprobieren.

Stimmt, genau so habe ich das nun auch herausgefunden. Ist ein Proxy eingetragen (ich habe die neueste FW 14.04.33 für die FBF 7050), dann werden auch die SIP-Calls (und auch die per ENUM herausgefunden SIP-Calls) über diesen Proxy geleitet, was dann dazu führt, dass im Wireshark-Mitschnitt dieses 404-unknown-domain auftaucht.


Dieses SIP-Proxy-Thema bringt mich in diesem Zusammenhang schon zur nächsten Frage.
Einen STUN brauche ich ja nur, wenn die FBF nicht direkt die öffentliche ip-Adresse hat, was z.B. der Fall ist, wenn diese hinter einem anderen Router betrieben wird.
Wie sieht das ganze aber mit dem SIP-Proxy aus? Wann brauche ich diesen? Brauche ich diesen überhaupt?

Sipgate ist ja nun geklärt. Hier werden nur die Einträge Benutzername, Passwort und Registrar benötigt, dann funktioniert alles.

Ich habe noch folgende weitere SIP-Accounts in meiner FBF konfiguriert:
einen zweiten Sipgate-Account
3 x dus.net
1 x freenet
1 x carpo.de
1 x betamax (webcalldirect.com)
1 x solomo

Weißt Du zufällig, wie das ganze bei diesen Accounts aussieht? Kann ich den Proxy grundsätzlich weglassen?

Viele Grüße
Martin

 

[KuniGunther]

Heißt dass, das die direkten SIP-Calls jetzt gehen?

Welche Absenderadresse bei ENUM Auflösung verwendet wird, weiß ich nicht, das musst Du mal ausprobieren (sollte im Trace ja klar werden). Bei SIP-Calls ist es ja nicht Nummer die zählt, sondern die SIP-Adresse, die übertragen wird. Eventuell wird die Nummer als "Display-Name" (oder ähnlich Bezeichnungen) übertragen, ähnlich wie bei EMail (i.e. "Nummer" <user@hiost>"). Zum Rückruf per SIP-Call ist die Nummer aber irrelevant und was angezeigt wird hängt von Endgerät ab.

Bzgl. Proxy kenne ich keinen Anbieter, bei dem das nötig ist. Allerdings kenne (=habe ich schon mal benutzt) auch nur wenige. Normalerweise gibt es für einen Client, der am öffentlichen Netz hängt, keinen Grund den Server, der per Registrar angegeben ist, per Proxy zu kontaktieren. Wenn beide Einträge gleich sind, schon mal gar nicht.

 

[RSchnauzer]

SIP Calls kommen an

@blacksun

Hallo,

gratuliere jetzt stimmt die Konfiguration.
Beide Calls sind gleich mit nnnnn47 reingekommen, es wird nur der Teil der URL vor dem @ angezeigt.

ENUM Call Trace:
201 wird nach download.fon.com gesucht?
527 ENUM DNS e164.arpa für meine Festnetznummer
528 kommt die SIP-URL von portunity
628 wird die DNS Auflösung für meine SIP-URL gemacht
633 SIP invite geht direkt raus
643 SIP ringing
764 das Gespräch wird von dir abgebrochen.

Telefonbuch SIP Call Trace:
390 DNS Auflösung SIP-URL
391 SIP invite direkt
403 SIP Anwort trying
410 SIP ringing
575 SIP canceled

Bei mir ist jetzt noch das Problem, dass die Suffix-Angabe da nichts vernünftiges draus machen kann.

 

[blacksun]

Heißt dass, das die direkten SIP-Calls jetzt gehen?

So wie es aussieht funktionieren nun die SIP-Calls bei mir.
Da die Testrufnummer von http://www.enum-test.at/ +43 720 0101011 nur per SIP-Call (bzw. natürlich ENUM) zu erreichen ist, bin ich mir fast sicher, dass die FBF nun das so macht wie sie soll. Die Wireshark-Aufzeichnungen deuten auch darauf hin.

Welche Absenderadresse bei ENUM Auflösung verwendet wird, weiß ich nicht, das musst Du mal ausprobieren (sollte im Trace ja klar werden). Bei SIP-Calls ist es ja nicht Nummer die zählt, sondern die SIP-Adresse, die übertragen wird. Eventuell wird die Nummer als "Display-Name" (oder ähnlich Bezeichnungen) übertragen, ähnlich wie bei EMail (i.e. "Nummer" <user@hiost>"). Zum Rückruf per SIP-Call ist die Nummer aber irrelevant und was angezeigt wird hängt von Endgerät ab.

nicht ganz.
Zum einen sieht es beim Angerufenen immer blöde aus, wenn da irgendwelche Zahlenkombinationen (in meinem Fall die Sipgate-ID) im Display steht, und zum anderen denke ich funktioniert der Rückruf bei einer FBF nicht.

Bsp: Du hast eine FBF 7050, daran ein analoges Telefon

Mal angenommen ich rufe bei Dir an, Du bist nicht da, im Display von Deinem Telefon steht die Sipgate-ID. Die lautet als Beispiel 784338. Du selbst hast keinen Account bei Sipgate. Nun drückst Du an Deinem analogen telefon auf wählen.
Dann wählt Dein Telefon eben nicht die Sip-URI, sondern nur die 784338, was falsch ist. Denn mit dieser 784338 könnte lediglich Sipgate etwas anfangen und eine Verbindung aufbauen. Du hast aber in dem Beispiel keinen Account bei Sipgate.

Wenn ich mit Wireshark schaue, was im Header bei "from" steht, dann übermittelt die FBF wohl dort immer
<Benutzername>@<registrar>
des jeweiligen SIP-Accounts.

Sprich bei mir steht bei abgehenden Telefonaten immer [email protected] oder im Falle von Freenet [email protected] als Absender drinn.
Bei ankommenden Anrufen nimmt die FBF wohl immer den Teil vor dem @-Zeichen als Rufnummer. Im Falle von Sipgate steht wohl die 784338 im Display vom Analogtelefon. Was ist Display angezeigt wird, wenn dort auch Buchstaben enthalten sind, kann ich Dir jetzt gar nicht sagen. Ich vermute max.mustermann oder gar nichts.

Daher wäre es gut, wenn man die FBF wenigstens dazu bewegen könnte, dass Sie vor das @-Zeichen immer die beim SIP-Account hinterlegte Nummer, die im Feld "Internetrufnummer" eingetragen ist, setzt.

Dann ist die Sip-URI mit [email protected] zwar immer noch falsch, jedoch können diejenigen, deren Gerät nur den Teil vor dem @-Zeichen auswertet, mich bequem zurückrufen. Und es wird eine tatsäch funktionierende Nummer angezeigt. Sprich die geht dann sowohl per ENUM (der ENUM-Looup gibt ja dann die richtige SIP-URI zurück) als auch ganz normal über Festnetz.

Eine denkbare Lösung wäre das Häkchen bei "Internetrufnummer für die Anmeldung verwenden" zu setzen. Dann verwendet die FBF die Internetrufnummer als Benutzername und die FROM-Zeile im Header würde wie gewünscht [email protected] lauten. Leider funktioniert dann aber nur bei den wenigsten SIP-Providern die Registrierung des Accounts.

Daher bleibt nur die Weg, dass man der FBF sagen muss, aus welchen Feldern sie die FROM-Zeile zusammensetzen muss. Und genau danach suche ich, wie man das machen könnte.

Habe ich da irgendwo einen Denkfehler?

Viele Grüße
Martin

 

[RSchnauzer]

Anzeige bei SIP-Calls

Hallo @blacksun,

bei dem letzten Versuch mit einer alpha VoIP-Userid steht bei mir nur die 00 im call wahrscheinlich von meiner suffix Angabe (00*;0*49;0*0;00*00).

Die Folgerung wäre jetzt, dass nur numerischen Zeichen vor dem @ zum Endgerät propagiert werden.

Umformen kann man das für die Anzeige nur mit suffix.

Wenn man für jeden VoIP Eintrag eine andere suffix Angabe macht kann man das eindeutig kennzeichnen, und manuel vielleicht für einen Rückruf nutzen.

 

[=Henry=]

Guten Abend blacksun & RSchnauzer

zu diesem Thema (Callerr-ID) hat Moonbase schon sehr schön etwas zusammen geschrieben.
Hier kann man es nachlesen. Falls ihr es noch nicht kennt.

Gruß Henry

 

[blacksun]

zu diesem Thema (Callerr-ID) hat Moonbase schon sehr schön etwas zusammen geschrieben.
Hier kann man es nachlesen.

Hallo Henry,

das bestätigt eigentlich nur das, was ich schon geschrieben habe, dass die FBF immer als Absender in die FROM-Zeile einträgt, was in den Feldern "benutzername" und "registrar" steht.
Bei einem Dummy-Eintrag kann ich dort die Daten so eingeben, dass die FBF daraus die tatsächliche SIP-URI baut.

Sprich ich trage als Benutzername die Rufnummer ein und bei Registrar nehme ich mustermann.dyndns.org.

Ich und RSchnauzer verwenden aber keine Dummy-Einträge, sondern müssen die richtigen Anmeldedaten (in unserem Fall die von Sipgate) verwenden. Und das funktioniert nur mit der Sipgate-ID als Benutzername und sipgate.de als Registrar. Wir wollen ja, dass die FBF zwar einen ENUM-Lookup macht und im Falle einer Rückmeldung einer SIP-URI diese direkt anruft. Sollte aber nichts zurückgeliefert werden, soll der Call ganz normal über Sipgate laufen. Und das funktioniert nicht, wenn ein Dummy-Account verwendet wird.

Die Sache mit dem Dummy-Account funktioniert nur, wenn ich weiß, dass es sich bei der anzurufenden Nummer einen ENUM-Eintrag gibt. Ich muss es also selbst wissen.

Optimal wäre es, wenn es pro Sip-Account in der Konfiguration noch ein Feld gäbe, in das man selbst das schreiben kann, was als FROM-Zeile bei einem Sip-Call mitgeschickt wird.

Viele Grüße
Martin