Nach Providerwechsel von TK zu QSC wollten wir auch das bisher analoge Telefon über den SP und VOIP betreiben. Die Registrierung bei sip.qsc.de funktioniert, und von ein außen kommender Ruf wird signalisiert. Aber:
1.) der Ruf kann nicht angenommen werden. Der Anrufer hört weiterhin seinen Rufton, und lokal hört man nichts.
2.) Trotz Freizeichen scheitern alle ausgehenden Anrufe. Nach einigen Sekunden ertönen drei Signaltöne. Wenn man ata.sh von Hand startet, werden diese als NETBUSY interpretiert. Ebenso erscheint ohne nähere Erläuterung mehrmals der Hinweis: "Can not connect to server" im Zusammenhang mit der SIP Registrierung, die ansonsten als erfolgreich vermeldet wird.
Wir haben alle relevanten BS-Images durchprobiert, auch die TARGA Versionen und auch die älteren. Die original Telekom Firmware 1.35 hat das gleiche Problem, ebenso die Version 1.37, die eigentlich für den SP w500V gedacht ist.
Sehr ärgerlich ist, daß der vodsl Aufruf nicht testweise abgeändert werden kann, ohne die Firmware komplett selbst zu kompilieren, da diese Scripte im read-only image liegen. Vorschlag: Symlinks nach /opt/etc/start_skripts
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dann liegt dein Problem wahrscheinlich am vodsl und lässt sich so ohne weiteres nicht lösen. Am besten wäre wenn du mal einen Dump mit Wireshark oder tcpdump von der Kommunikation zwischen Router und SIP-Server machst.
Weiterhin hätte dir ein Blick in '/etc/start_scripts/startscript.sh' folgende Zeile offenbart:
Deshalb kannst du natürlich beliebige Skripte nach /opt/etc/start_scripts/ kopieren und dort editieren. Die werden dann auch beim Startvorgang bevorzugt ausgeführt.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ich war gerade dabei den Dialog mitzuschneiden, nachdem ich entdeckt habe, daß hier tcpdump doch zur Verfügung steht. Ein offensichtlich relevanter Part (während des Versuchs, jemanden anzurufen) ist dieser hier:
15 38.038000 213.148.136.2 87.234.xx.xx SIP Status: 500 Server Internal Error
--> Spagetti-Code auch im QSC SIP Server? Würde man nicht eher eine Meldung wie "illegal request" erwarten, wenn der SIP-Client Unsinn sendet?
Ich würde ja gerne den kompletten pcap log hier posten, denn bestimmt gibt es wenigstens einen hier, der eine SIP-konforme Anfrage von einer leicht illegalen unterscheiden kann. Wer sich dazu in der Lage sieht, möge mir bitte eine Email senden.
>Weiterhin hätte dir ein Blick in '/etc/start_scripts/startscript.sh'
Danke! Wenn man nur immer wüßte, wo man jeweils hinzusehen hat. Abgesehen davon kann man das Skript ja auch einfach nach /opt kopieren, dort versuchsweise ändern und ausführen ... das fiel mir allerdings erst einige Zeit später ein.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mir ist aufgefallen, daß vodsl nicht aufeinanderfolgende "Cseq" Nummern vergibt (siehe unten anghängtes Protokoll). Es ist zwar laut RFC 3261 legal, "Cseq" anfangs auf irgendeinen Wert zu setzen, aber die Zahl soll strikt monoton hochgezählt werden. Sie dient einerseits dazu, Transaktionen zusammenzuhalten, und andererseits dazu, doppelt empfangene Anforderungen zu erkennen.
Im unten anhängtem Protokoll beginnt vodsl nun mit
"CSeq: 1824938743 REGISTER", was zu einer erfogreichen
Registrierung bei sip.qsc.de führt. Beim kurze Zeit später nach außen gehenden Anruf nimmt vodsl dann aber eine Sequenznummer, die sehr viel kleiner ist:
CSeq: 1546115924 INVITE
Der Server müßte in diesem Fall Listen darüber führen, welche Nummern von welcher Verbindung schon verwendet wurde, was doch sehr ineffizient wäre. Der QSC-eigene IPfonie(R) - Client jedenfalls zählt die CSeq Nummern immer um eins hoch.
Die Gegenstelle sip.qsc.de ist ein "Huawei SoftX3000", V300R601. Ein Huawei Dokument über die SIP Implementierung in SoftX3000 sagt zu "Cseq" folgendes:
"The CSeq sequence number of a BYE request should be higher than that of the corresponding INVITE request. The server must remember the highest sequence number of an INVITE request having the same Call-ID. Upon receipt of an INVITE request with a lower sequence number, the server sends a response and discards the INVITE request."
Na wenn die CSEQ wirklich das Problem sein sollte, und du hast ja schon ordentlich recherchiert, dann lässt sich das Problem wahrscheinlich nicht ohne Umwege lösen. Ich würde einen SIP-Proxy vorschlagen der lokal auf dem Router installiert wird...
Wie ist denn deine Netzwerkkonfiguration? Ist der Speedport bei dir Gateway oder hast du noch nen anderen Router davor (Fritzbox o.ä.). Im Falle von Fritzbox beispielsweise könntest du auch diese als Proxy im Speedport angeben. Wenn nichts hilft könnte man auch z.B. den 'siproxd' oder den 'Milkfish' mal für den Speedport kompilieren (würde ich dir helfen). Klingt aufwändig ich weiß, aber am 'vodsl' können wir leider gar nichts ändern. Da würde aber wahrscheinlich ein Problem mit den Port-Nummern auftreten, da beide Programme auf Port 5060 laufen.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Für den obigen Test lief vodsl bei ausgeschaltetem Firewall direkt am ppp Interface, und und der SP direkt an der DSL-Leitung. Leider habe ich keine FB, sonst wäre alles viel einfacher.
Über einen Proxy habe ich auch nachgedacht. Man könnte den Proxy ja auf ein anderes Interface setzen, und via iptables umleiten, oder bei bekannter PID den owner match verwenden um das Problem der gleichen Portnummer zu umgehen. Es soll auch ein SIP - Modul für iptables geben, nur gefunden habe ich es bisher noch nicht. Mit welchem der beiden Proxys würdest Du beginnen?
Letztlich könnte man vodsl patchen, wenn sonst nichts hilft. Auf diese Weise habe ich gerade dropbear davon überzeugt, "authorized_keys" von "/opt/dropbear/" zu lesen. Nebenbei: "/etc/dropbear/" sollte wirklich ein Symlink werden, da es für die Lage dieser Datei wenigstens in der verwendeten Version keine Option gibt.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mit der aktuellen siproxd Version 0.7.1 stürzt nicht mehr siproxd ab, dafür aber vodsl (sig 11). Das Hauptproblem ist auch, daß vodsl auf allen Interfaces 5060/udp belegt, unabhängig von proxy/registrar Parametern. Und grundsätzlich akzeptiert vodsl nur br0 und ppp_1_32_1, nicht z.B. lo (->"waiting for interface to come up"), auch nicht ein durch "vtund" bereitgestelltes tun/tap interface.
Es gab hier mal ein Programm namens fakeonline, ich finde aber keine Information darüber, wozu das wohl gut war. Ich bin jetzt am überlegen, ein spezielles SIP Modul für iptables zu schreiben, und darüber die CSeq Nummern umzusetzen. Wenn nur sicher wäre, daß das auch wirklich das Problem ist. Die RFC 3261 ist hinsichtlich CSeq nicht eindeutig -- denn sie definiert nicht, was unter einem "dialog" zu verstehen ist.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dann lager den siproxd doch erstmal auf deinen Rechner aus und geb den als Proxy an, dann kannst du zumindest mal schauen ob der Proxy die CSEQ ändert und ob dann der Call erfolgreich ist.
Wenn du wirklich mit iptables arbeiten willst dann empfehl ich dir zunächst die Pakete im Userspace zu behandeln (siehe IPQueue oder NFQueue). Hat den Vorteil das du besser debuggen kannst und der Kernel nicht abstürzen kann.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
RFC 3261 sagt, daß nur INVITE einen Dialog beginnt. Demnach gibt es keine Beziehung zwischen den CSeq der Registrierung und den CSeq des allein durch INVITE eingeleiteten Dialogs. Die SIP-Netfilter Module des Linux Kernel vergleichen CSeq auch immer nur auf Identität.
vodsl hat aber noch eine verdächtige Eigenart. Bei INVITE Telegrammen sendet vodsl id@registrar:port, anstatt id@domain, wie man im weiter oben stehenden Mitschnitt sehen kann:
INVITE sip:[andere nr]@sip.qsc.de:5060 SIP/2.0
Das ist ein weiterer Unterschied zum funktionierenden QSC-Client, der [andere nr]@qsc.de sendet, während der Registrar dort auf sip.qsc.de sitzt. Mir fiel das auf, als ich vodsl bei sip2sip.info angemeldet habe. vodsl schickte bei Anwahl der Nummer 3333
SIP/2.0 483 Too many hops
To: 3333<sip:3333@proxy.sipthor.net:5060>
From: 223xxxx <sip:223xxxx@sip2sip.info>
Im Thread "Probleme mit DSL-Telefonie und Telekom" steht nun zu lesen, daß man für die Registrierung mit T-online die "Domain" "tel.t-online.de" verwenden soll, und den Registrar "62.225.245.122".
nslookup der "Domain" tel.t-online.de ergibt genau diese IP
Name: ul-tas-a01.isp.t-ipnet.de
Address: 62.225.244.122
Demnach sollte vodsl bei allen Providern funktionieren, deren DNS Telekom-artig aufgesetzt ist, also ip(registrar) == ip(domain) ?
>coolman1982
>Dann lager den siproxd doch erstmal auf deinen Rechner aus
Das habe ich bisher nur deshalb vermieden, weil noch ein zweiter Router dazwischen hängt und ich der zusätzlichen Fehlerquelle NAT aus dem Weg gehen wollte.
>IPQueue oder NFQueue
Guter Hinweis
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Nach Providerwechsel von TK zu QSC wollten wir auch das bisher analoge Telefon über den SP und VOIP betreiben. Die Registrierung bei sip.qsc.de funktioniert, und von ein außen kommender Ruf wird signalisiert. Aber:
1.) der Ruf kann nicht angenommen werden. Der Anrufer hört weiterhin seinen Rufton, und lokal hört man nichts.
2.) Trotz Freizeichen scheitern alle ausgehenden Anrufe. Nach einigen Sekunden ertönen drei Signaltöne. Wenn man ata.sh von Hand startet, werden diese als NETBUSY interpretiert. Ebenso erscheint ohne nähere Erläuterung mehrmals der Hinweis: "Can not connect to server" im Zusammenhang mit der SIP Registrierung, die ansonsten als erfolgreich vermeldet wird.
Wir haben alle relevanten BS-Images durchprobiert, auch die TARGA Versionen und auch die älteren. Die original Telekom Firmware 1.35 hat das gleiche Problem, ebenso die Version 1.37, die eigentlich für den SP w500V gedacht ist.
Sehr ärgerlich ist, daß der vodsl Aufruf nicht testweise abgeändert werden kann, ohne die Firmware komplett selbst zu kompilieren, da diese Scripte im read-only image liegen. Vorschlag: Symlinks nach /opt/etc/start_skripts
Dann liegt dein Problem wahrscheinlich am vodsl und lässt sich so ohne weiteres nicht lösen. Am besten wäre wenn du mal einen Dump mit Wireshark oder tcpdump von der Kommunikation zwischen Router und SIP-Server machst.
Weiterhin hätte dir ein Blick in '/etc/start_scripts/startscript.sh' folgende Zeile offenbart:
export PATH=$PATH:/opt/etc/start_scripts/:etc/start_scripts/
Deshalb kannst du natürlich beliebige Skripte nach /opt/etc/start_scripts/ kopieren und dort editieren. Die werden dann auch beim Startvorgang bevorzugt ausgeführt.
Ich war gerade dabei den Dialog mitzuschneiden, nachdem ich entdeckt habe, daß hier tcpdump doch zur Verfügung steht. Ein offensichtlich relevanter Part (während des Versuchs, jemanden anzurufen) ist dieser hier:
13 38.005000 87.234.xx.xx 213.148.136.2 SIP/SDP Request: INVITE sip:0xx51xxxxxx0@213.148.136.2:5060, with session description
14 38.038000 213.148.136.2 87.234.xx.xx SIP Status: 100 Trying
15 38.038000 213.148.136.2 87.234.xx.xx SIP Status: 500 Server Internal Error
--> Spagetti-Code auch im QSC SIP Server? Würde man nicht eher eine Meldung wie "illegal request" erwarten, wenn der SIP-Client Unsinn sendet?
Ich würde ja gerne den kompletten pcap log hier posten, denn bestimmt gibt es wenigstens einen hier, der eine SIP-konforme Anfrage von einer leicht illegalen unterscheiden kann. Wer sich dazu in der Lage sieht, möge mir bitte eine Email senden.
>Weiterhin hätte dir ein Blick in '/etc/start_scripts/startscript.sh'
Danke! Wenn man nur immer wüßte, wo man jeweils hinzusehen hat. Abgesehen davon kann man das Skript ja auch einfach nach /opt kopieren, dort versuchsweise ändern und ausführen ... das fiel mir allerdings erst einige Zeit später ein.
Mir ist aufgefallen, daß vodsl nicht aufeinanderfolgende "Cseq" Nummern vergibt (siehe unten anghängtes Protokoll). Es ist zwar laut RFC 3261 legal, "Cseq" anfangs auf irgendeinen Wert zu setzen, aber die Zahl soll strikt monoton hochgezählt werden. Sie dient einerseits dazu, Transaktionen zusammenzuhalten, und andererseits dazu, doppelt empfangene Anforderungen zu erkennen.
Im unten anhängtem Protokoll beginnt vodsl nun mit
"CSeq: 1824938743 REGISTER", was zu einer erfogreichen
Registrierung bei sip.qsc.de führt. Beim kurze Zeit später nach außen gehenden Anruf nimmt vodsl dann aber eine Sequenznummer, die sehr viel kleiner ist:
CSeq: 1546115924 INVITE
Der Server müßte in diesem Fall Listen darüber führen, welche Nummern von welcher Verbindung schon verwendet wurde, was doch sehr ineffizient wäre. Der QSC-eigene IPfonie(R) - Client jedenfalls zählt die CSeq Nummern immer um eins hoch.
---- snip ---
REGISTER sip:sip.qsc.de SIP/2.0
Via: SIP/2.0/UDP [eigene ip];branch=z9hG4bK692147bcc
Max-Forwards: 70
Content-Length: 0
To: [eigene nr] <sip:[eigene nr]@qsc.de>
From: [eigene nr] <sip:[eigene nr]@qsc.de>;tag=a9ebb0eec1cd536
Call-ID: 21ff44c73382711a68e847dc46b9e2e2@[eigene ip]
CSeq: 1824938743 REGISTER
Contact: [eigene nr] <sip:[eigene nr]@[eigene ip]>;expires=600
Allow: NOTIFY, REFER, OPTIONS, INVITE, ACK, CANCEL, BYE
Authorization:Digest
[auth response zensiert]
User-Agent: T-Com Speedport W500V / Firmware v1.37 MxSF/v3.2.6.26
SIP/2.0 200 OK
Via: SIP/2.0/UDP [eigene ip];branch=z9hG4bK692147bcc;rport=5060
Call-ID: 21ff44c73382711a68e847dc46b9e2e2@[eigene ip]
From: [eigene nr] <sip:[eigene nr]@qsc.de>;tag=a9ebb0eec1cd536
To: [eigene nr] <sip:[eigene nr]@qsc.de>;tag=30e1ae04
CSeq: 1824938743 REGISTER
Expires: 600
Server: QSC SIP Router
Contact: <sip:[eigene nr]@[eigene ip]:5060>;expires=600
Content-Length: 0
INVITE sip:[andere nr]@sip.qsc.de:5060 SIP/2.0
Via: SIP/2.0/UDP [eigene ip];branch=z9hG4bK7754b421f
Max-Forwards: 70
Content-Length: 232
To: [andere nr] <sip:[andere nr]@sip.qsc.de:5060>
From: [eigene nr] <sip:[eigene nr]@qsc.de>;tag=635b21b9cde5e53
Call-ID: eb15295259b8c16a630883cd52d6f1e6@[eigene ip]
CSeq: 1546115924 INVITE
Allow: NOTIFY, REFER, OPTIONS, INVITE, ACK, CANCEL, BYE
Content-Type: application/sdp
Contact: [eigene nr] <sip:[eigene nr]@[eigene ip]>
Supported: replaces
User-Agent: T-Com Speedport W500V / Firmware v1.37 MxSF/v3.2.6.26
v=0
o=MxSIP 0 9819832 IN IP4 [eigene ip]
s=SIP Call
c=IN IP4 [eigene ip]
t=0 0
m=audio 16384 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=silenceSupp:off
SIP/2.0 100 Trying
Via: SIP/2.0/UDP [eigene ip];branch=z9hG4bK7754b421f;rport=5060
Call-ID: eb15295259b8c16a630883cd52d6f1e6@[eigene ip]
From: [eigene nr] <sip:[eigene nr]@qsc.de>;tag=635b21b9cde5e53
To: [andere nr] <sip:[andere nr]@sip.qsc.de:5060>
CSeq: 1546115924 INVITE
Content-Length: 0
SIP/2.0 500 Server Internal Error
Via: SIP/2.0/UDP [eigene ip];branch=z9hG4bK7754b421f;rport=5060
Call-ID: eb15295259b8c16a630883cd52d6f1e6@[eigene ip]
From: [eigene nr] <sip:[eigene nr]@qsc.de>;tag=635b21b9cde5e53
To: [andere nr] <sip:[andere nr]@sip.qsc.de:5060>;tag=facc6873
CSeq: 1546115924 INVITE
Content-Length: 0
ACK sip:[andere nr]@sip.qsc.de:5060 SIP/2.0
Via: SIP/2.0/UDP [eigene ip];branch=z9hG4bK7754b421f
Max-Forwards: 70
Content-Length: 0
To: [andere nr] <sip:[andere nr]@sip.qsc.de:5060>;tag=facc6873
From: [eigene nr] <sip:[eigene nr]@qsc.de>;tag=635b21b9cde5e53
Call-ID: eb15295259b8c16a630883cd52d6f1e6@[eigene ip]
CSeq: 1546115924 ACK
User-Agent: T-Com Speedport W500V / Firmware v1.37 MxSF/v3.2.6.26
---snip---
Die Gegenstelle sip.qsc.de ist ein "Huawei SoftX3000", V300R601. Ein Huawei Dokument über die SIP Implementierung in SoftX3000 sagt zu "Cseq" folgendes:
"The CSeq sequence number of a BYE request should be higher than that of the corresponding INVITE request. The server must remember the highest sequence number of an INVITE request having the same Call-ID. Upon receipt of an INVITE request with a lower sequence number, the server sends a response and discards the INVITE request."
Quelle:http://telco-protocol.blogspot.com/2007/01/sip.html
Na wenn die CSEQ wirklich das Problem sein sollte, und du hast ja schon ordentlich recherchiert, dann lässt sich das Problem wahrscheinlich nicht ohne Umwege lösen. Ich würde einen SIP-Proxy vorschlagen der lokal auf dem Router installiert wird...
Wie ist denn deine Netzwerkkonfiguration? Ist der Speedport bei dir Gateway oder hast du noch nen anderen Router davor (Fritzbox o.ä.). Im Falle von Fritzbox beispielsweise könntest du auch diese als Proxy im Speedport angeben. Wenn nichts hilft könnte man auch z.B. den 'siproxd' oder den 'Milkfish' mal für den Speedport kompilieren (würde ich dir helfen). Klingt aufwändig ich weiß, aber am 'vodsl' können wir leider gar nichts ändern. Da würde aber wahrscheinlich ein Problem mit den Port-Nummern auftreten, da beide Programme auf Port 5060 laufen.
Für den obigen Test lief vodsl bei ausgeschaltetem Firewall direkt am ppp Interface, und und der SP direkt an der DSL-Leitung. Leider habe ich keine FB, sonst wäre alles viel einfacher.
Über einen Proxy habe ich auch nachgedacht. Man könnte den Proxy ja auf ein anderes Interface setzen, und via iptables umleiten, oder bei bekannter PID den owner match verwenden um das Problem der gleichen Portnummer zu umgehen. Es soll auch ein SIP - Modul für iptables geben, nur gefunden habe ich es bisher noch nicht. Mit welchem der beiden Proxys würdest Du beginnen?
Letztlich könnte man vodsl patchen, wenn sonst nichts hilft. Auf diese Weise habe ich gerade dropbear davon überzeugt, "authorized_keys" von "/opt/dropbear/" zu lesen. Nebenbei: "/etc/dropbear/" sollte wirklich ein Symlink werden, da es für die Lage dieser Datei wenigstens in der verwendeten Version keine Option gibt.
siproxd kompiliert, kopiert, konfiguriert, gestartet. Leider stürzt er beim ersten Kontakt mit vodsl ab.
Mit der aktuellen siproxd Version 0.7.1 stürzt nicht mehr siproxd ab, dafür aber vodsl (sig 11). Das Hauptproblem ist auch, daß vodsl auf allen Interfaces 5060/udp belegt, unabhängig von proxy/registrar Parametern. Und grundsätzlich akzeptiert vodsl nur br0 und ppp_1_32_1, nicht z.B. lo (->"waiting for interface to come up"), auch nicht ein durch "vtund" bereitgestelltes tun/tap interface.
Es gab hier mal ein Programm namens fakeonline, ich finde aber keine Information darüber, wozu das wohl gut war. Ich bin jetzt am überlegen, ein spezielles SIP Modul für iptables zu schreiben, und darüber die CSeq Nummern umzusetzen. Wenn nur sicher wäre, daß das auch wirklich das Problem ist. Die RFC 3261 ist hinsichtlich CSeq nicht eindeutig -- denn sie definiert nicht, was unter einem "dialog" zu verstehen ist.
Dann lager den siproxd doch erstmal auf deinen Rechner aus und geb den als Proxy an, dann kannst du zumindest mal schauen ob der Proxy die CSEQ ändert und ob dann der Call erfolgreich ist.
Wenn du wirklich mit iptables arbeiten willst dann empfehl ich dir zunächst die Pakete im Userspace zu behandeln (siehe IPQueue oder NFQueue). Hat den Vorteil das du besser debuggen kannst und der Kernel nicht abstürzen kann.
RFC 3261 sagt, daß nur INVITE einen Dialog beginnt. Demnach gibt es keine Beziehung zwischen den CSeq der Registrierung und den CSeq des allein durch INVITE eingeleiteten Dialogs. Die SIP-Netfilter Module des Linux Kernel vergleichen CSeq auch immer nur auf Identität.
vodsl hat aber noch eine verdächtige Eigenart. Bei INVITE Telegrammen sendet vodsl id@registrar:port, anstatt id@domain, wie man im weiter oben stehenden Mitschnitt sehen kann:
INVITE sip:[andere nr]@sip.qsc.de:5060 SIP/2.0
Das ist ein weiterer Unterschied zum funktionierenden QSC-Client, der [andere nr]@qsc.de sendet, während der Registrar dort auf sip.qsc.de sitzt. Mir fiel das auf, als ich vodsl bei sip2sip.info angemeldet habe. vodsl schickte bei Anwahl der Nummer 3333
INVITE sip:3333@proxy.sipthor.net:5060 SIP/2.0
From: 223xxxx<sip:223xxxxx@sip2sip.info>
Woraufhin der Server antwortet:
SIP/2.0 483 Too many hops
To: 3333<sip:3333@proxy.sipthor.net:5060>
From: 223xxxx <sip:223xxxx@sip2sip.info>
Im Thread "Probleme mit DSL-Telefonie und Telekom" steht nun zu lesen, daß man für die Registrierung mit T-online die "Domain" "tel.t-online.de" verwenden soll, und den Registrar "62.225.245.122".
nslookup der "Domain" tel.t-online.de ergibt genau diese IP
Name: ul-tas-a01.isp.t-ipnet.de
Address: 62.225.244.122
Demnach sollte vodsl bei allen Providern funktionieren, deren DNS Telekom-artig aufgesetzt ist, also ip(registrar) == ip(domain) ?
>coolman1982
>Dann lager den siproxd doch erstmal auf deinen Rechner aus
Das habe ich bisher nur deshalb vermieden, weil noch ein zweiter Router dazwischen hängt und ich der zusätzlichen Fehlerquelle NAT aus dem Weg gehen wollte.
>IPQueue oder NFQueue
Guter Hinweis