Portfreigabe für Internettelefonnummern von 1&1?

Ich nehme an, Du meinst das SIP REGISTER?

Sorry, das ist das erste Mal das ich mich tiefer mit der Materie beschäftige - bin noch nicht mit der Fachterminologie vertraut! Leider ist es auf diesem Gebiet sehr schwer an Einführende Beschreibungen zu kommen :(

Also, genau es geht um's SIP REGISTER

eder einigermassen standardkonforme Client registriert sich erst kurz vor Ablauf der im STATUS 200 OK auf das REGISTER vom Server im "expires" Headertag angegebenen Zeitspanne oder eben nach "ungewöhnlichen" Ereignissen (loss of connectivity, IP change etc.)

Genau das kann ich jetzt bestätigen - habe mit mal FritzCap den Netzwerkverkehr angeschaut.
Der im Header angegebene Status: 200 OK agegebene Expires Wert wird wohl von !&1 unabhängig von der voipd.cfg vergeben!
Er beträgt wohl 8h - wobei es hängt wohl auch vom letzten REGISTER ab:

1. Register per Telnet: Heute Morgen ~8.00 Uhr
2. Register per Telnet: 11:00 Uhr --> Expires: 18000
3. Register per Telnet: 11:15 Uhr --> Expires: 27900

Das Problem ist wahrscheinlich, dass die ATA hinter einem zwangsgetrennten Modem von der Trennung nichts mitbekommt, also auch keine erneute Registrierung vornimmt, wie z.B. die am dichtesten am DSL liegende Box. Die für die ATA damit noch bestehende Registrierung mit der alten IP ist damit hinfällig.

Genau das ist momentan das Problem! Ich kann sagen dass des der ATA hinter dem Router in meinem Fall definitiv nicht mitbekommt.

Allerdings ist mir auch aufgefallen das selbst nach einem REGISTER nach einer gewissen Zeit keine Anrufe mehr rein kommen (trotz NAT-Tabelle aktuell halten)!
Sind sonst noch Befehle für die Aufrechterhaltung des REGISTERs notwendig?
Oder bliebe dies bis zum Ablauf der Zeit die im Expires-Wert angeben wurde bestehen?

Ich werde einen solchen Fall mal dokumentieren (FritzCap) - ob da tatsächlich nichts mehr vom Anruf am Router ankommt!

Gruß
Steven
 
Hallo,

sollte die Box sich nicht mehr so oft registrieren, dann hat man das Verhalten jetzt in neuen Firmwares geändert. Denn
  1. Früher - als auf der Konsole noch die Ausgaben des voipd erschienen - konnte man definitiv in regelmäßigen Abständen die Neuregistrierung der Accounts sehen.
  2. Des weiteren siehe diesen Thread. Das Problem dort waren Inaktivitätstimeouts, die T-Com schmeißt einen nach 15 Minuten Inaktivität aus dem Netz. Ab ca. 4 VoIP Accounts in der Box kommt man nicht mehr auf diese 15 Minuten Inaktivität, die Box trennt die Verbindung nicht mehr, das haben mehrere Nutzer unabhängig in den verlinkten Beiträgen bestätigt. Wie soll das möglich sein, wenn nur alle 8 Stunden eine Neuregistrierung durchgeführt wird?
  3. Hatte ich die Neuregistrierungen in den Paketmitschnitten, die ich damals angefertigt hatte.
  4. Hatten wir hier schon mehrfach das Problem von Nichterreichbarkeit der ATAs nach Zwangstrennung, und das verändern des TTL Wertes hatte definitiv Einfluss auf das Verhalten.
  5. Macht es überhaupt keinen Sinn, eine Neuregistrierung so weit heraus zu schieben, denn
    • - VoIP-Phones und Softphones haben generell dieses Problem und wären über Stunden nicht erreichbar.
    • - der Provider würde stundenlang versuchen, Gespräche zu nicht mehr verfügbaren Endgeräten zu vermitteln.
    Mal ehrlich - wer würde sich sowas ausdenken? Ich halte 30 Minuten schon für extrem lang in diesem Zusammenhang.

Viele Grüße

Frank
 
Zuletzt bearbeitet:
Hmm. Falsch verstanden? Natürlich kannst Du auch noch REGISTER Intervalle a 30 min hinbekommen - mit dem richtigen Provider, mag das gehen.

Fakt ist (ab welcher FW Version das greift/gegriffen hat, weiss ich nicht):

* Der UAC kann sich eine Expire-Time wünschen. Wenn die z.B. xx s ist und der Registrar ist der Meinung "zu kurz", kann die Registrierung abgewiesen werden ("Intervall too brief") und der Client unter Angabe der min expires zu einer erneuten Registrierung aufgefordert werden.

* Mein Provider akzeptiert Expires 1800 (= 30min) im Status 200 OK und was macht die Box? Registriert sich fein erneut nach 1620 Sekunden...

* 1und1 legt m.W.n. das Intervall auf 8 h fest, egal, was sich der Client wünscht. Vor einem signifikanten Ablauf der 8 h macht die FB keine Anstalten, sich erneut zu registrieren. Irgendwie habe ich dafür auch schon mal Traces gesehen...

Hängt also vom Provider ab.

Grüsse
 
Hallo,

spongebob schrieb:
* Mein Provider akzeptiert Expires 1800 (= 30min) im Status 200 OK und was macht die Box? Registriert sich fein erneut nach 1620 Sekunden...
Ja, das passt. In etwa der Zeitraum war es auch bei mir. Bei allen Accounts, auch bei UI, da bin ich mir sicher.
Bei Sipgate wird auch der Expire-Zeitpunkt in der Weboberfläche im Online Status angezeigt. Der verlängert sich jedes mal nach 27 Minuten - 1620 Sekunden. :shock:

* 1und1 legt m.W.n. das Intervall auf 8 h fest, egal, was sich der Client wünscht.
Warum machen sie das? Es macht auch für die keinen Sinn, siehe meine Ausführungen oben. Sämtliche VoIP Endgeräte hinter Routern werden damit unter Umständen für Stunden ausgesperrt - was für ein Unfug.
Früher wurde sogar durch die Einstellung "Portweiterleitungen für Internettelefonie offen halten" eine Neuregistrierung durchgeführt - im Extremfall also alle 30 Sekunden. Erst durch die schon öfter erwähnten Paketmitschnitte ist mir aufgefallen, dass dafür jetzt Dummy Pakete verschickt werden.
Ich fahre morgen ins lange Wochenende und kann also vorläufig keine eigenen Beobachtungen vornehmen. Wenn ich nächste Woche noch mal ein bisschen Zeit übrig habe, werde ich mir das noch mal ansehen.

Viele Grüße

Frank
 
Früher wurde sogar durch die Einstellung "Portweiterleitungen für Internettelefonie offen halten" eine Neuregistrierung durchgeführt - im Extremfall also alle 30 Sekunden.

Bist Du da ganz sicher? M.E.n. war das immer nur ein UDP Paket der Länge 0 oder 2 Byte oder so...

Egal. Ich nehme an, dass sie aus Gründen der Last versuchen, die Authentisierungsintervalle zu minimieren. Dahinter stehen ja z.T. relativ komplexe RADIUS/DIAMETER Systeme über diverse Datenbanken etc...

Grüsse
 
Erkenntnis

Servus!

Nach einiger Trace-Aufzeichnung kann ich nun für meinen Fall folgendes feststellen

Verwendete Geräte: FritBox 7170 und 7050
Anbieter: 1und1

1)
Ich bekomme im EXPIRES Wert der 200 OK-Meldung einen Wert der vom davorgehenden SIP-Register abhängt.
Allerdingings beträgt de SUMME der EXPIRES-Werte zweier aufeinanderfolgender
SIP-Register 8 Stunden.

Nehmen wir einmal an es erfolgen 2 SIP Register kurz hintereinander - dann bekomme ich in der 200 OK-Meldung des 2. Registers einen EXPIRES-Wert von etwas weniger als 8 Stunden

2)
Die FritzBox hält sich strikt an diesesn EXPIRES-Wert (egal was in der voip-Config steht)

3)
Was genau 1und1 davon hat konnte ich leider nicht beantworten ;)
Abe wie schon von "spongebob" vermutet wahrscheinlich ehrheblich weniger Traffic

3a) Die aufrechterhaltung der NAT-Tabelle verwendet bei mir keinen REGISTER-Kommando

4)
Im Normalfall ergibt sich jedoch hieraus ja kein Problem da beide Boxen - wenn als Router betrieben - sofort nach Trennung eine neue Verbindung herstellen und dann auch ein erneutes SIP-Register durchführen (dann unabhängig vom EXPIRES-Wert).
Was allerdings die Box als ATA angeht...

5)...ist dann Punkt 5: Daran arbeite ich noch: Der ATA bekommt von einer Trennung des Routers nichts mit und wäre im ungünstigsten Fall somit <8h ohne registrierte Nummern.
Sobald ich ein gescheites Sript fertig habe melde ich mich :p

Gruß
Steven

P.S. Wie gesagt - gilt alles nur für meinen Fall
 
zu 1)
Richtig, denn 1&1 hat noch eine "pending Registration" < 8 h.

zu 2)
Wie gesagt...
Vor einem signifikanten Ablauf der 8 h macht die FB keine
Anstalten, sich erneut zu registrieren.

Das ist sogar leidlich standardkonform, obwohl man das explizit nicht so rauslesen kann aus dem SIP RFC. Zwischen den Zeilen aber...

3a)
Genau, das sind nur so kleine Mini-UDPs. Die werden ja eigentlich auch nur für das NAT Refresh der FB gebraucht...

4)
Exakt.

5)
ATA eine auf'n Deckel geben, wenn's vorne weggeflogen ist :)

Grüsse
 
Geschafft!

5)
ATA eine auf'n Deckel geben, wenn's vorne weggeflogen ist

;) Genau das hatte ich auch erst vor:
Mit der Holzhammermethode "voipd- R" alles 5 Minuten per Schleife in der debug.cfg

War mir allerdings dann etwas unsicher ob 1&1 irgendwann anfängt zu meckern wenn ich statt geplanten ~4 SIP-Register plötzlich > 288 pro Tag von mir bekommt :p

Versucht habe ich es dann hiermit

Code:
cat > /var/tmp/sipreg.sh << 'ENDCHECK'
#!/bin/sh
#
# Ueberpruefung auf Aenderung der IP (extern)
# Gegebenenfalls SIP REGISTER
#
echo 7,2 >/var/led
wget -q -O /var/tmp/neu.ip http://whatismyip.org
if [ "`cat /var/tmp/neu.ip`" = "`cat /var/tmp/alt.ip`" ]
then
echo "Keine neue IP - Ende"
echo 2,2 > /var/led
sleep 1
echo 2,1 > /var/led
echo 7,1 > /var/led
else
/bin/voipd -R
echo "Neue IP - SIP-Register"
echo 7,3 > /var/led
sleep 5
echo 2,1 > /var/led
echo 7,1 > /var/led
fi
rm /var/tmp/alt.ip
mv /var/tmp/neu.ip /var/tmp/alt.ip
ENDCHECK
chmod +x /var/tmp/sipreg.sh

Das Ding mit vi oder Pseudo-Update (dank an "the-construct.com") in die debug.cfg und dann mit Crontab alle 10 Minuten aufgerufen - läuft super!

Was mich allerdings nervte dass ich zum Ermitteln der IP immer eine Anfrage an eine Website stellen musste (die Spezifikation von http://checkip.dyndns.com/ möchte z.B. nicht mehr als 1 Abfrage in 10 Minuten)!

Mittlerweile habe ich mich durch diverse Themen hier im Forum gelesen und hiermit letzlich meine endgültige Abfrage der WAN-IP hinbekommen

Notwendig war dann allerdings der ds-mod auch auf dem Router (für das Skript get_ip und die Rudi-Shell):

Code:
cat > /var/tmp/sipreg.sh << 'ENDCHECK'
#!/bin/sh
#
# Ueberpruefung auf Aenderung der IP (intern)
# Gegebenenfalls SIP REGISTER
#
echo 7,2 > /var/led
wget -q -O - http://admin:[email protected]:81/cgi-bin/rudi_shellcmd.cgi?script=get_ip | sed -n 's/.*id="cmd_output">//p' > /var/tmp/neu.ip
if [ "`cat /var/tmp/neu.ip`" = "" ]
then
echo "Kann IP nicht ermitteln - Ende"
echo 7,1 > /var/led
else
if [ "`cat /var/tmp/neu.ip`" = "`cat /var/tmp/alt.ip`" ]
then
echo "Keine neue IP - Ende"
echo 2,2 > /var/led
sleep 1
echo 2,1 > /var/led
echo 7,1 > /var/led
else
/bin/voipd -R
echo "Neue IP - SIP-Register"
echo 7,3 > /var/led
sleep 5
echo 2,1 > /var/led
echo 7,1 > /var/led
fi
rm /var/tmp/alt.ip
mv /var/tmp/neu.ip /var/tmp/alt.ip
fi
ENDCHECK
chmod +x /var/tmp/sipreg.sh

Das mit den LEDs habe ich nur zur besseren Kontrolle des Skriptes eingefügt.

Wieder starten des Skriptes "sipreg.sh" alle 2 Minuten per Crontab!

--> Kein "externer" Traffic
--> WAN-IP am ATA ermitteln durch ausführen des Skriptes "get_ip" (ds-mod) über die Rudi-Shell

Läuft (bis jetzt) absolut problemlos. Allerdings habe ich den Patch des get_ip in den mod eingespielt (POST statt GET zur IP-Ermittlung)

Danke an alle die mir bis hierher geholfen haben :)
Wenn ich bedenke dass ich bis vor ein paar Tagen noch ungläubig den Kopf geschüttelt hätte wenn mir jemand etwas von Fritz!Box-Modden erzählt hätte :noidea: - ich war froh "Linux" richtig schreiben zu können :gruebel:

Ich weiß nicht warum aber im Dauertest hatte ich dennoch ab-und-zu Zeiten der "Nichterreichbarkeit": gelöst habe ich das indem ich die Ports des ATA verändert habe --> Einstellungen sichern --> Edit dieser Datei
wie hier beschrieben

Port-Ändern:
5060 --> 5070
7077 --> 7177 usw.

+

Portweiterleitung im Router von Port 5070

So, hoffe dass das jetzt läuft - danke nochmal :bier:
Mal gespannt wann ich an meinem neuen "Spielzeug" weiterbastle ;-)

Gruß
Steven
 
Gut gemacht. Schau mal, ob das Bestand hat.

Das mit den 288 Register habe ich nicht verstanden. Im Ernstfall ist es doch nur ein zusätzliches am Tag und zwar nach Zwangstrennung + (0...IP_QUERY_TIME). Wer sollte was dagegen haben?

Grüsse
 
Das mit den 288 Register habe ich nicht verstanden. Im Ernstfall ist es doch nur ein zusätzliches am Tag und zwar nach Zwangstrennung

Da bezog ich mich auf die Holzhammermethode "alle 5 Minuten voipd -R" per Schleife in der debug.cfg --> Hierbei würde ja dann alle 5 Minuten ein REGISTER ausgeführt - wie ich finde etwas unverhältnismäßig.

Gruß
Steven
 
Danke, genau das was ich suchte!
Hab leider nur das Problem, das auf meiner 2.Box ds-mod nicht richtig läuft. Kann ich auch ohne ds-mod einen cron-job erstellen?
Evtl. kann ich ja auch in der 1.Box die VoIP Nummern der 2.Box nach einer Zwangstrennung registrieren/updaten, oder? Die IP aller Nummern ist ja gleich und die Ports fest eingestellt.. Wenn ja, wie? :)
Grüße
Jörg
 
Das wird nichts, vergiss es.
 
Warum nicht? Evtl. kann sich ja auch Box 1 bei einer Neueinwahl/bzw. neuer IP über Telnet oder SSH in Box 2 einloggen und das voip -r ausführen?
 
So schon eher.
 
geht das in etwa so?
das hier kommt in die erste Box mit Internet DSL Verbindung

Code:
# Create online status event handler
cat > /var/tmp/onlinechanged << EOF
#!/bin/sh
if [ "\$1" = "online" ] ; then

# Und hier auf der 2.Box das Skript mit voipd -r ausfuehren..
# in etwa so??

#das script /var/tmp/sipreg.sh starten
http://admin:[email protected]:81/cgi-bin/rudi_shellcmd.cgi?script=sipreg
#wie uebergebe ich doch gleich den pfad? urlencode?

fi
EOF

# Make event handler script executable
chmod +x /var/tmp/onlinechanged
 
# Restart multid with event handler script
multid -s
multid -S /var/tmp/onlinechanged

und das auf die 2. Box

Code:
cat > /var/tmp/sipreg.sh << 'ENDCHECK'
#!/bin/sh
#
# SIP REGISTER
#
/bin/voipd -R

ENDCHECK
chmod +x /var/tmp/sipreg.sh

oder noch einfacher?
 
Hi Steven,
die 192.168.170.1 ist natürlch die 2.Box (IP Client). Denn ds-mod wollte ich dort zwar nicht installieren, da ich Probleme mit ds-mod+ip client hatte. Wenn es nicht anders geht, versuche ich es aber nochmal..
Das müsste also funktionieren?
Code:
..
wget -q -O http://admin:[email protected]:81/cgi-bin/rudi_shellcmd.cgi?script=/var/tmp/sipreg
..

Grüße
Jörg
 
Hey,

ich weiß nicht ob es eine Möglichkeit gibt auf einer unmodifizierten Box ein Skript von extern auszuführen - mir ist nur der Weg über wget und Rudi bekannt.

Bei deinem Code oben muss es jedoch wget -q -O - ....... usw. lauten (- =Standardausgabepfad)

Ansonsten sollte das so funktionieren!

Gruß
Steven
 
So hänge mich mal hier an, da ich auch so meine Probleme mit einer 7150 hinter 7170 habe.
Siehe dazu hier

Habe eine ganze weile mit AVM kommuniziert.

Nach diversen Mitschnitten welche ich AVM zur Verfügung gestellt habe, hat mir AVM diese Nachricht geschickt.

die Ursache für das Verhalten besteht darin, dass der im Fehlerfall verwendete Internettelefonieanbieter die eingehenden Internetgespräche nicht über die Adresse des in der nachgeschalteten FRITZ!Box konfigurierten Registrars, sondern eine andere signalisiert. Die Funktion zur Aufrechterhaltung der Portweiterleitung kann deshalb an diesem Punkt keinen Einfluss nehmen.

Die Lösung besteht darin, dass Sie im vorgeschalteten Router folgende statische Portweiterleitungen konfigurieren:

- von beliebigem noch nicht verwendeten UDP-Port ab 1024 (z.B. 6060) auf Port 5060 der IP-Adresse des nachgeschalteten FRITZ!Box Fon-Gerätes
- von beliebigem noch nicht verwendeten UDP-Ports ab 1024 (z.B. 6078-6097) auf 7078-7097 der IP-Adresse des nachgeschalteten FRITZ!Box Fon-Gerätes

Nachdem dies geschehen ist, müssen sowohl der vorgeschaltete Router als auch die nachgeschaltete FRITZ!Box neu gestartet werden.


Mit freundlichen Grüßen aus Berlin

So nun meine Frage dazu - wie bitte gebe ich dies in die FBF ein ?
"von beliebigem noch nicht verwendeten UDP-Ports ab 1024 (z.B. 6078-6097) auf 7078-7097 der IP-Adresse des nachgeschalteten FRITZ!Box Fon-Gerätes"
in die Box einzugeben ist.

Muss ich für den Bereich 7078-7097 19 Einträge erstellen?
Sorry für diese Frage, aber mit diesem Thema habe ich mich noch nicht beschäftigt.

Hab es mal mit dem 6060 auf 5060 eingetragen und angehängt.
habe aber keine Ahnung ob dies richtig ist.


Wer kann mir das mal als Leihe erklären wie ich diese von AVM vorgeschlagenen Ports eingeben muss.
 
Zuletzt bearbeitet:

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,067
Beiträge
2,245,472
Mitglieder
373,504
Neuestes Mitglied
andkel
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.