Fritz!Box 7270 sendet lokale IP bei registrarlosem VOIP

[dumdideldumdei]

Hallo,

ich habe eine Fritz!Box 7270 mit Firmware 54.04.57 in Deutschland direkt an einer 1&1-DSL-Leitung und eine Fritz!Box 7170 mit Firmware 29.04.57 in Spanien hinter einem Telsey-Router an einer Tele2-Komplett-Leitung.

Auf beiden sind Pseudo-VOIP-Telefonnummern eingerichtet und beide registrieren einen DynDNS-Namen.

Auf die 7170 hinter dem Telsey-Router habe ich momentan telnet-Zugriff, auf die 7270 leider nicht. Ich habe meinen (technisch eher unbedarften) Vater trotzdem überreden können, auf der 7270 per telnet in der voip.cfg den Eintrag "do_not_register = yes;" für eine Pseudo-VOIP-Nummer (99999900) zu setzen.

Jetzt versuche ich, per Kurzwahl von der spanischen 7170 auf 99999900@<deutsche-fritz-box-dyndns-name> ein direktes Telefongespräch zu führen.

Die Verbindung kommt auch zustande, aber kein Ton geht durch.

Ich habe auf meiner 7170 den voipd mit "-v" gestartet. Und dabei sehe ich, dass die 7270 in den UDP-Paketen die lokale IP (192.168.178.1) sendet. Meine 7170 verwirft offenbar diese Pakete, weil sie eben nicht die erwartete echte IP-Adresse enthalten und der Partner hört auch nichts, weil (das ist jetzt aber nur meine Vermutung) meine 7170 dann trotzdem versucht, meine Sprachpakete an die 192.168.178.1 zu schicken, was ins Leere geht (meine 7170 ist wegen des vorgeschalteten Telsey-Routers auf ein anderes Subnetz konfiguriert, die 192.168.178.1 existert also auch bei mir nicht).

Das tonlose Gespräch wird so auf meiner 7170 mitgeloggt:

Aug  9 08:11:05 voipd[1720]: call to sip:99999900@<7270-yndns-name> established
Aug  9 08:11:05 voipd[1720]: >>>UDP Request: ACK sip:[B][email protected][/B];uniq=988AB7906F7AB568FAA43AD549C6C (11)
[B]Aug  9 08:11:05 voipd[1720]: rtp_dgramrcv: [U]packet from <externe 7270-ip> ignored, should be from 192.168.178.1[/U]
[/B]Aug  9 08:11:05 voipd[1720]: plci_connected(appl=5 plci=0x1305 ncci=0x0 incoming)
Aug  9 08:11:05 voipd[1720]: connected(appl=5 plci=0x1305 ncci=0x11305 incoming) NCPIlen=0
Aug  9 08:11:05 voipd[1720]: <<<UDP Status: 200 OK (11)
Aug  9 08:11:05 voipd[1720]: >>>UDP Request: ACK sip:[B][email protected][/B];uniq=988AB7906F7AB568FAA43AD549C6C (11)
Aug  9 08:11:06 voipd[1720]: <<<UDP Status: 200 OK (11)
Aug  9 08:11:06 voipd[1720]: >>>UDP Request: ACK sip:[B][email protected][/B];uniq=988AB7906F7AB568FAA43AD549C6C (11)
Aug  9 08:11:08 voipd[1720]: <<<UDP Status: 200 OK (11)
Aug  9 08:11:08 voipd[1720]: >>>UDP Request: ACK sip:[B][email protected][/B];uniq=988AB7906F7AB568FAA43AD549C6C (11)
Aug  9 08:11:09 voipd[1720]: <<<UDP Status: 486 Busy Here (11)
Aug  9 08:11:19 voipd[1720]: call_progress_disconnect(appl=5 plci=0x1305 ncci=0x11305 incoming)
Aug  9 08:11:19 voipd[1720]: call_progress_disconnect(appl=5 plci=0x1305 ncci=0x11305 incoming): 0x3490 -
Aug  9 08:11:19 voipd[1720]: QoS-Report(> 99999900 via <7270-dyndns-name>): CS=274;PS=467;OS=112080;SP=0/0;SO=0;PR=0;OR=0;CR=0;SR=0;PL=0;BL=0;RB=0/0;SB=0/0;EN=PCMA;DE=;JI=0;DL=0
Aug  9 08:11:19 voipd[1720]: Codec - (-) - audio 0
Aug  9 08:11:19 voipd[1720]: >>>UDP Request: BYE sip:[B][email protected][/B];uniq=988AB7906F7AB568FAA43AD549C6C (12)
Aug  9 08:11:19 voipd[1720]: sent: 467 (112080) voice, 0 (0) CN, 0 silence
Aug  9 08:11:19 voipd[1720]: jitter packets 0 bytes 0 drop_toolate 0 drop_duplicates 0
Aug  9 08:11:19 voipd[1720]:        wrong_seq 0 packets lost 0 (max burst 0)
Aug  9 08:11:19 voipd[1720]: rtpsession drop_nobuffer 0 drop_tooshort 0 drop_wrong_version 0 decoder failed 0
Aug  9 08:11:19 voipd[1720]: >>>UDP Request: BYE sip:[B][email protected][/B];uniq=988AB7906F7AB568FAA43AD549C6C (12)
Aug  9 08:11:20 voipd[1720]: >>>UDP Request: BYE sip:[B][B][email protected][/B][/B];uniq=988AB7906F7AB568FAA43AD549C6C (12)
Aug  9 08:11:22 voipd[1720]: >>>UDP Request: BYE sip:[B][email protected][/B];uniq=988AB7906F7AB568FAA43AD549C6C (12)
Aug  9 08:11:24 voipd[1720]: disconnected(appl=5 plci=0x1305 ncci=0x11305 incoming): remote: 0x3490 (0x3301) -
Aug  9 08:11:24 voipd[1720]: output: failed 0, onhold 0, queue full 0
Aug  9 08:11:24 voipd[1720]:         small packets merged 0, output 0, consumed from CNG 0
Aug  9 08:11:24 voipd[1720]:         normal 0 merged 0 delayed 0
Aug  9 08:11:24 voipd[1720]:         dropped 0 chunks (0 samples) and 0 samples
Aug  9 08:11:24 voipd[1720]:         generated noise: oben 0/unten <=0
Aug  9 08:11:26 voipd[1720]: >>>UDP Request: BYE sip:[B][email protected][/B];uniq=988AB7906F7AB568FAA43AD549C6C (12)
Aug  9 08:11:30 voipd[1720]: >>>UDP Request: BYE sip:[B][email protected][/B];uniq=988AB7906F7AB568FAA43AD549C6C (12)
Aug  9 08:11:34 voipd[1720]: >>>UDP Request: BYE sip:[B][email protected][/B];uniq=988AB7906F7AB568FAA43AD549C6C (12)

Bei einer völlig gleich eingerichteten zweiten Pseudo-Nummer 99999901 auf der 7270, die sich nur im "do_not_register = no;" in der voip.cfg unterscheidet (naja, und in den Nummern-spezifischen Einträgen natürlich), kommt die Verbindung mit Ton-Paketen in beide Richtungen zustande. Mein voipd-Log auf der 7170 sieht dann wie folgt aus:

Aug  9 08:25:25 voipd[1720]: call to sip:99999901@<7270-dyndns-name> established
Aug  9 08:25:25 voipd[1720]: >>>UDP Request: ACK sip:99999901@<externe 7270-ip>;uniq=988AB7906F7AB568FAA43AD549C6C (33)
Aug  9 08:25:25 voipd[1720]: plci_connected(appl=5 plci=0x805 ncci=0x0 incoming)
Aug  9 08:25:25 voipd[1720]: capiconn_send: failed 1
Aug  9 08:25:25 voipd[1720]: connected(appl=5 plci=0x805 ncci=0x10805 incoming) NCPIlen=0
Aug  9 08:27:18 voipd[1720]: call_progress_disconnect(appl=5 plci=0x805 ncci=0x10805 incoming)
Aug  9 08:27:18 voipd[1720]: call_progress_disconnect(appl=5 plci=0x805 ncci=0x10805 incoming): 0x3490 -
Aug  9 08:27:18 voipd[1720]: QoS-Report(> 99999901 via <7270-dyndns-name>): CS=309;PS=3790;OS=909600;SP=0/0;SO=0;PR=3792;OR=910080;CR=0;SR=0;PL=0;BL=0;RB=0/0;SB=0/0;EN=PCMA;DE=PCMA;JI=43;DL=106
Aug  9 08:27:18 voipd[1720]: Codec - (-) - audio 0
Aug  9 08:27:18 voipd[1720]: >>>UDP Request: BYE sip:99999901@<externe 7270-ip>;uniq=988AB7906F7AB568FAA43AD549C6C (39)
Aug  9 08:27:18 voipd[1720]: sent: 3790 (909600) voice, 0 (0) CN, 0 silence
Aug  9 08:27:18 voipd[1720]: jitter packets 3792 bytes 910080 drop_toolate 0 drop_duplicates 0
Aug  9 08:27:18 voipd[1720]:        wrong_seq 0 packets lost 0 (max burst 0)
Aug  9 08:27:18 voipd[1720]: rtpsession drop_nobuffer 0 drop_tooshort 0 drop_wrong_version 0 decoder failed 0
Aug  9 08:27:19 voipd[1720]: <<<UDP Status: 200 OK (39)
Aug  9 08:27:19 voipd[1720]: QoS-Report(< 99999901 via <7270-dyndns-name>): CS=0;PS=3799;OS=911760;SP=0/0;SO=0;PR=3790;OR=909600;CR=0;SR=0;PL=0;BL=0;RB=0/0;SB=0/0;EN=PCMA;DE=PCMA;JI=41;DL=107
Aug  9 08:27:19 voipd[1720]: 99999910: BYE complete
Aug  9 08:27:19 voipd[1720]: output: failed 2, onhold 0, queue full 0
Aug  9 08:27:19 voipd[1720]:         small packets merged 0, output 0, consumed from CNG 0
Aug  9 08:27:19 voipd[1720]:         normal 3789 merged 0 delayed 0
Aug  9 08:27:19 voipd[1720]:         dropped 34 chunks (1360 samples) and 23 samples
Aug  9 08:27:19 voipd[1720]:         generated noise: oben 0/unten <=48
Aug  9 08:27:19 voipd[1720]:         capiqueue[0]: 50 (  1.3%)
Aug  9 08:27:19 voipd[1720]:         capiqueue[1]: 2534 ( 66.8%)
Aug  9 08:27:19 voipd[1720]:         capiqueue[2]: 1055 ( 27.8%)
Aug  9 08:27:19 voipd[1720]:         capiqueue[3]: 150 (  3.9%)
Aug  9 08:27:19 voipd[1720]:         txqueue[  0ms]: 50 (  1.3%)
Aug  9 08:27:19 voipd[1720]:         txqueue[ 20ms]: 2 (  0.0%)
Aug  9 08:27:19 voipd[1720]:         txqueue[ 30ms]: 2533 ( 66.8%)
Aug  9 08:27:19 voipd[1720]:         txqueue[ 40ms]: 2 (  0.0%)
Aug  9 08:27:19 voipd[1720]:         txqueue[ 50ms]: 24 (  0.6%)
Aug  9 08:27:19 voipd[1720]:         txqueue[ 60ms]: 1028 ( 27.1%)
Aug  9 08:27:19 voipd[1720]:         txqueue[ 90ms]: 150 (  3.9%)
Aug  9 08:27:19 voipd[1720]: call to sip:99999901@<7270-dyndns-name> terminated (200)
Aug  9 08:27:19 voipd[1720]: disconnected(appl=5 plci=0x805 ncci=0x10805 incoming): local: 0x3490 (0x3301) -

Bei beiden Nummern ist natürlich ein Registrar (nämlich der dyndns-Name der Fritzbox) eingetragen, der Unterschied besteht eben nur im do_not_register. Natürlich müllt die 99999901-Nummer wegen der dauernden Fehlversuche beim Registrieren das Eventlog voll, aber sie funktioniert. Die 99999900-Nummer lässt zwar wegen des Nicht-Registrierens das Eventlog in Ruhe, aber die Fritzbox scheint ohne das Registrieren nicht die externe IP zu benutzen, sondern die lokale.

In allen Threads zum registrarlosen Telefonieren bin ich auf dieses Problem noch nie gestoßen [KORREKTUR: hier geht es um dasselbe Problem (im Beitrag 3 wird erwähnt, dass die LAN-IP von der Fritzbox versendet wird, nicht aber die externe), eine Lösung sehe ich aber nicht. NAT ist wie gesagt definitiv nicht das Problem.]

Ich würde es ja vielleicht verstehen, wenn die 7270 hinter einem Router hängt und die externe IP nicht heraus bekommt (das wäre dann ja mit STUN zu lösen). Aber die 7270 hat die direkte DSL-Verbindung, sollte also ihre externe IP kennen (tut sie ja auch bei der 99999901-Nummer).

Gibt es dazu hilfreiche Meinungen?

Gruß

dumdideldumdei

 

[dumdideldumdei]

Nanu, nach einer Woche noch niemand, der dazu etwas sagen kann? Alle in Urlaub?

Gruß

dumdideldumdei

 

[superpapa]

Nö, aber leider auch keine Ahnung. Bin zwar schon drüber gestolpert, bin dann auf eine registrierte Nr.@dyndns ausgewichen. Und nun mit der Labor-firmware geht nicht mal mehr das vorübergende Einschalten der Registrierung per FB-Editor. Gern kannste mal mich testweise direkt antelebimmeln - dann bitte PN.
Gruß
Michael

 

[NanoBot]

Hi,

ich gucke mir dieses Problem immer nur sporadisch an und bei der letzten all-in-one Labor für die 7170 ergibt sich bei mir folgendes Bild:

Ist "do_not_register" auf yes, dann kann ich den Dummy-Account gar nicht nutzen. Sobald ich versuche vom Dummy-Account einen Anruf abzusetzen, bekomme ich nur eine Fehlermeldung.

Ist "do_not_register" auf no, so wird der Anruf zwar korrekt auf der Gegenseite signalisiert, aber es tritt nach wie vor das Problem der Nutzung der falschen IP auf, so daß keine Sprachübertragung stattfindet.


Offenbar ist es so, daß der voipd erst bei der Registrierung des Accounts an einem SIP-Server die WAN-IP mitgeteilt bekommt und nur dann die korrekte ( WAN- ) IP verwendet. Daher fürchte ich, daß man das Problem nur lösen kann, indem man einen eigenen SIP-Server nutzt und die Dummy-Accounts daran anmeldet. Zu diesem Zweck hatte ich früher auch schon mal die DTMF Box installiert, woran ich dann meinen Dummy Account auch anmelden konnte. Aber irgendwie habe ich die ganze Funktionalität der DTMF-Box nicht richtig kapiert; offenbar will die DTMF-Box dann nicht nur der SIP-Server, sondern auch gleich der SIP-Proxy sein. Und das ist ja nicht der Sinn der Sache, wir wollen ja direkt ohne Proxy per Voip telefonieren.

C.U. NanoBot

 

[dumdideldumdei]

Die Lösung des Problems scheint also, einen eigenen SIP-Registrar zu betreiben.

Ich habe (zugegeben nur kurz) nach SIP-Servern geschaut und die sind natürlich alle auf richtige Rechner ausgelegt. Alle natürlich mit SQL-Datenbank-Abhängigkeiten und mehr. Das sind teilweise so richtige Klöpse mit Hunderten von Megabyte Installier-Kram. Das passt natürlich nicht auf die Fritzbox und würde einen eigenen Server erfordern (und das auch noch bei mir je einer an jeder Fritzbox, weil die andere ja ohne Verbindung sein könnte, ich aber aus einem offenen WLAN-Accesspoint trotzdem die eine oder andere Fritzbox per Direktwahl erreichen möchte).

Am liebsten wäre mir natürlich, einen schlanken SIP-Server nur mit Registrar-Funktionalität und niedlichem Text-File für die Account-Definition auf die jeweilige Fritzbox selbst zu setzen. So was habe ich auf die Schnelle jetzt noch nicht gefunden. Werde weitersuchen, aber vielleicht hat ja schon jemand einen Tip.

[EDIT: Ich sollte nicht immer nur schräg lesen. Im Post vor mir steht ja schon der Hinweis auf dtmf-box. Das schaue ich mir mal näher an!]

Gruß

dumdideldumdei

 

[Ruebe]

Wenn ich es richtig verstanden habe, geht es hier um eine Art "p2p" Telefonverbindung zwischen Vater un Sohn dumdideldumdei.
Bei allem Verständnis und Respekt für das Bestreben, eine technisch anspruchsvolle Lösung zu implementieren, sollte aber das "KISS"-Prinzip (Keep It Simple, Stupid) nicht völlig misachtet werden.

Du könntest stattdessen (z.B.) bei smsdiscount.com ein Konto einrichten und für ¤ 12,50 ein Guthaben kaufen. Dafür kannst Du 120 Tage lang alle Deutschen und Spanischen Festnetzanschlüsse (aus beiden Ländern) praktisch unbegrenzt anrufen. Darüberhinaus Deutsche Mobilfunkanschlüsse für 7,5 ct/Min und Spanische für 6,25 ct/Min anrufen.
Wohlgemerkt mit demselben Konto von beiden FBs!
Zeitaufwand, wen's hoch kommt insges. 1 Stunde.
Mit Hilfe von Teamviewer könntest Du sogar Deinen Vater "entlasten" und seine FB von hier einrichten. Bei der Gelegenheit gleich die Fernwartung enrichten, dann geht alles noch einfacher.
Ist natürlich technisch nicht so anspruchsvoll!

 

[NanoBot]

Hi Ruebe,

sicher liese sich das Problem so recht einfach lösen. Aber der Grund für den Wunsch nach registrarloser Telefonie ist, zumindestens auf meiner Seite, nicht die Geldersparnis. Vielmehr geht es auch darum, den Datensammlern, seien es Telefongesellschaften oder sei es der Staat, eine lange Nase zu zeigen. Denn wenn man ohne Registrar direkt von IP zu IP telefoniert, gibt es niemanden, der Verbindungsdaten speichern kann oder muß.

Zusätzlich wäre es natürlich sinnvoll und wünschenswert, gleich noch SRTP oder ZRTP einsetzen zu können, aber das ist auf einer Fritzbox derzeit nicht möglich.

C.U. NanoBot

 

[superpapa]

Ich habe festgestellt, dass man bei sipgate sich selbst von seiner eigenen Nummer auf die eigene Nummer anrufen kann. Das habe ich getestet mit zwei Boxen, per WDS verbunden und in beiden sipgate aktiviert. Ist vielleicht rechtlich nicht 100%ig und die Überwacher können überwachen(aber was-Selbstgespräche?).
Gruß
Michael

 

[telocho]

Denn wenn man ohne Registrar direkt von IP zu IP telefoniert, gibt es niemanden, der Verbindungsdaten speichern kann oder muß.

Nicht ganz, nach neuen EU Regeln muss ja deine ISP auch Daten sammeln z.B. wann eingelogt ist, zu wem du E-mails schickst usw. Er bewahrt kein Content aber kann schon auch auf SIP filtern und die Verbindungsaaufbaudaten loggen. (Das muss er dan 1 oder 2 Jahre oder so aufbewahren?)

 

[dumdideldumdei]

Wenn ich es richtig verstanden habe, geht es hier um eine Art "p2p" Telefonverbindung zwischen Vater und Sohn

Das hast Du richtig verstanden. Aber Deinen Vorschlag mit Registrierung bei einem VOIP-Provider und Verwendung von Guthaben hatte ich vorher schon mal mit Sipgate ausprobiert, das ist gnadenlos schiefgegangen (siehe hier). Einen anderen Versuch tu ich mir nicht mehr an. Wozu auch? Vater hat DSL-Flat, ich hier in Spanien bei Bedarf auch. Seine Fritzbox ist per DynDNS erreichbar, meine auch. Was brauche ich da noch einen VOIP-Provider? Der wäre speziell unter Berücksichtigung des von Dir selbst vorgeschlagenen KISS-Prinzips nur eine überflüssige Kompenente.

Aber der Grund für den Wunsch nach registrarloser Telefonie ist, zumindestens auf meiner Seite, nicht die Geldersparnis.

Also, bei mir schon. Wenn ich in Spanien Internet-Flatrate habe und Vater in Deutschland auch, was soll ich dann noch Geld für irgendwelche Festnetz-Anrufe bezahlen?. Zumal das ja gar nicht mehr Festnetz ist. Vater hat in Deutschland zwar noch POTS, zusätzlich aber auch die 1&1-VOIP-Nummer, über die er mittlerweile alle deutschen Festnetz-Anrufe führt (weil kostenlos!). Ich hier in Spanien habe mit Tele2 noch nicht mal mehr POTS, das läuft AUSSCHLIEßLICH über VOIP (und nebenbei auch alle spanischen "Festnetz"-Anrufe kostenlos). Noch mehr VOIP-Provider einzuschalten kostet überflüssig Geld und erhöht (nochmal zurück zum KISS-Prinzip) überflüssig die Komplexität.

Nicht ganz, nach neuen EU Regeln muss ja deine ISP auch Daten sammeln z.B. wann eingelogt ist, zu wem du E-mails schickst usw.

Meine Emails kann mein ISP gar nicht verfolgen. Die schicke ich per Secure-SMTP über meinen Domain-Provider. Wäre mir neu, dass der ISP dabei mitbekommt, an wen ich Emails schicke. Mein Domain-Provider bekommt das natürlich schon mit, aber der muss ja bei entsprechendem Geschäftssitz keine EU-Richtlinien befolgen.

Aber seid mir nicht böse, darum geht es hier ja gar nicht. Es wäre mir lieb, wenn wir wieder zum eigentlichen Thread-Thema kommen und das ist das Verwenden von VOIP-Direktverbindungen ohne Registrierung bei einem echten/existierenden Registrar mit Fritzboxen.

Die Vorschläge von Rübe passen deshalb nicht so sehr, weil sie entweder am Thema vorbeigehen (z.B. verwalte ich Vaters Fritzbox natürlich schon längst per HTTPS-Fernwartung, aber was hat das mit VOIP-Direktverbindungen zu tun?), oder nicht wirklich eine Alternative zur Direktverbindung zwischen den Fritzboxen sind (Sorry Rübe, das soll jetzt bitte nicht als persönlicher Angriff verstanden werden).

Derzeit habe ich natürlich VOIP-Registrierungen bei kostenlosen Echt-Registraren in beiden Boxen aktiv, weil nur so das Überfluten des Logs mit "Kann nicht registrieren"-Meldungen gestoppt ist und bei do_not_register=yes in den aktuellen Firmwares eben fehlerhafterweise die lokale IP an die Gegenstelle geschickt wird.

Da aber VOIP-Provider auch mal Geld verdienen wollen (Freeworld-Dialup ist gerade von kostenlos auf 30$ Jahresgebühr geschwenkt) wäre mir die Providerlose Direktverbindung eben doch lieber, da ich rein technisch für die Verbindung von mir zu einer mir bekannten Gegenstelle eben keinen VOIP-Registrar brauche. Der Tip von superpapa

Ich habe festgestellt, dass man bei sipgate sich selbst von seiner eigenen Nummer auf die eigene Nummer anrufen kann. Das habe ich getestet mit zwei Boxen

ist deshalb zwar nicht schlecht, geht aber eben auch nur per Registrar und ist für mich auch wirklich rechtlich zweifelhaft. Derzeit verwenden wir dann doch lieber für jede der beteiligten Personen eigene registrierte Nummern.

Wenn's geht, wären mir hier Diskussionen um irgendwelche dahin führende Konfigurations-Tricks in den Fritzboxen deshalb lieber, als Vorschläge, die doch nur auf eine normale VOIP-Registrierung hinauslaufen. Darum geht's halt eigentlich nicht!

Gruß

dumdideldumdei

 

[telocho]

Überlege mal iptel.org als (öffentliche) Registrar? Dann ist die Voipaccount registriert bz Aktiv. Danach versuchen direct peer-to-peer anrufen (trage mal deine Vaters Fritz als Proxy ein, oder seine dyndns:5060 als Proxy?)
Registrar: behält letzte IP adresse zum angerufen werden
Proxy: behandelt anrufe. (Wenn kein separate Proxy macht der Registrar diese Funktion.)

 

[dumdideldumdei]

Genauso mache ich es im Moment ja (nicht mit iptel.org, aber das ist ja egal). Das Anrufen erfolgt dann schon direkt an die DynDNS der anderen Fritzbox ohne Proxy und ohne SIP-Vermittlung des Registrars (dazu brauche ich auch nicht die andere Fritzbox als Proxy einzutragen, das geht ja über <andere Registrar-Fritzbox-Nummer>@<andere Fritzbox-DynDNS-Name> im Telefonbuch). Das geht ja auch alles. Ich wollte eben nur ganz ohne Registrar auskommen, was ja auch mal mit älteren Firmwares der Fritzboxen funktioniert haben muss (jedenfalls gibt es hier Threads, nach denen das so aussieht). Jetzt ist das do_not_register=yes aber offensichtlich buggy.

Meine Hoffnung war eher, dass es findige/pfiffige Fritzbox-Kenner gibt, die Workarounds wissen. Die Registrierung bei einem echten Registrar ist ja kein Workaround, sondern die normale Verwendung einer VOIP-Nummer mit do_not_register=no.

 

[telocho]

Sieht so aus, entweder baut AVM die alte funktionalität ein wie es mal war, oder mann muss selber irgendwas im Firmware eingreifen im Telefon/VoIP daemon (auch ausgeschlossen da Closed Software).
Alles andere wäre ja Workarounds.
Oder es muss noch ein versteckter Parameter geben in Trent von do_not_register, und danach sucht du in dieses Thema.

 

[dumdideldumdei]

Übrigens, ein wichtiger Grund für meine Wunsch des registrar-losen Telefonierens ist die Unabhängigkeit von den unzuverlässigen Registrar-Servern. Seit heute morgen ist z.B. eu.voxalot.com nicht verfügbar (und ratet mal, wo ich im Moment wegen des do_not_register-Bugs in der Fritzbox registriere!). Und sowas kam auch immer wieder bei FWD oder Sipgate vor, dass mal einen halben Tag oder auch ein Wochenende lang der Registrar-Server ausfiel.

Bei der Direkt-Verbindung hat man zwar noch den DynDNS als schwaches bzw. verzögerndes Glied in der Kette, aber selbst wenn eine neue IP nach Reconnect sich noch nicht durch das DNS-System propagiert hat, kann ich bei meinen bekannten Boxen zumindest bei meinem DynDNS-Provider die Update-Versuche sehen und kenne die IP dann schon vor dem DNS. Im dringendsten Fall kann ich den Telefonbucheintrag dann also auf <Nummer>@<IP> ändern.

Deshalb noch einmal meine Bitte: Kennt nicht irgendjemand bei der jetzigen aktuellen Firmware der Fritzboxen (bzw. der vorletzten, ich habe gesehen, am 18.08. gab es ein Update) einen Workaround, wie man die Fritzbox OHNE Registrar dazu bringt, korrekte VOIP-Pakete zu schicken?

Gruß

dumdideldumdei

 

[fetap]

Ich weiß, der Thread ist alt, aber ich hatte das oben geschilderte Problem aktuell mit einer noch älteren FRITZ!Box:

Mit "do_not_register = no;" funktioniert der Dummy-Account problemlos, müllt aber das Eventlog voll, mit "do_not_register = yes;" kommt zwar die Verbindung zustande, bleibt aber stumm (Sprachpakete senden fälschlich die lokale IP und werden daher verworfen).

Mein Workaround und die voip.cfg sieht jetzt folgendermaßen aus:

do_not_register = no;
(also die Standardeinstellung)

register_failwaitmax = 1d;
(1 day)

Mit dieser Einstellung versucht die Box nach einem Neustart des voipd (z.B. bei einem Box-Reset oder einer Änderung an der VoIP-Konfiguration) immer noch etwa 12 Mal innerhalb der ersten 24h (mit zunehmendem Zeitabstand), den Dummy-Account zu registrieren. Im Alltagsbetrieb versucht sie es aber nur noch einmal am Tag, nämlich unmittelbar nach dem Wiederaufbau der Internetverbindung:

05.12.11 05:15:52 Anmeldung der Internetrufnummer xxx war nicht erfolgreich. Ursache: Gegenstelle antwortet nicht. Zeitüberschreitung.

Und genau dieser eine Versuch ist es wohl, den es braucht, damit die Sache funktioniert. Eine noch elegantere Lösung (keine Einträge im Eventlog nach Neustart des voipd) habe ich leider nicht gefunden, aber so ist das Ganze auch schon deutlich besser.

 

[sherifomran]

Ich habe das gleiche Problem. DTMFbox registriert richtig aber ein anderere Server beschwert und sagt

Bitte nutzen Sie eine globale IP

 

[lorddiablo]

Ich bin auch ein leidtragender dieser Problematik.

Schätzungsweise wäre das "eleganteste" ein pseudo Provider, der ungefährt vielleicht "lokale Internettelefonnummer" oder "private Internettelefonie ohne Registrierar" heißt und ganz regulär in der Web-Oberfläche ausgewählt werden kann.

Hat das schon mal jemand AVM als Feature-Request vorgeschlagen und eine Reaktion geerntet?

Man kann zwar nicht erwarten, dass sich da schnell was tut, aber AVM erhört ja nun doch manchmal im Laufe der Zeit die Wünsche seiner Kunden.

 

[sherifomran]

Ich habe es gelöst. Bitte ein Stun server nutzen

z.B stun.ekiga.net


lg

Sherif

 

[ahnungslos³]

Ich habe eine 7390 und an die ist eine 2N IP Türsprechstelle angeschlossen. Dazu habe ich in der FBF pseudo Internetrufnummer 55511 bis 55520 angelegt. Beim Registrar ist fritz.box eingetragen. Ein Feld stun-Server ist nicht vorgesehen. Die Klingelsignalisierung auf die Telefone erfolgt über meine Auerswald COMpact 4410USB.

Es funktioniert alles Super, bis auf den Fakt, dass das Protokoll alle 10 Sekunden vollgemüllt wird. Die Fritzbox hängt sich auch ca. alle 3-4 Tage einmal auf. Ich denke es liegt an den erfolglosen Versuchen die Nummern anzumelden.

Hat jemand einen Tip für mich?

Gruß,
ahnungslos³

 

[aquarium]

Mir erschliesst sich nicht ganz, warum Du Internetrufnummern angelegt hast. Die Türsprechstelle meldet sich doch als IP-Telefon am Sip-Registrar der Fritzbox an. Wenn die Telefonanlage am internen S0 der FB angeschlossen ist, sollte es doch als internes Telefongespräch funktionieren?