[Problem] Telekom: keine ausgehenden Anrufe / SIP/2.0 403 Zugriff nicht erlaubt (seit heute)

[abw1oim]

sip show peers mit OK bedeutet nur, dass die (IP)Gegenstelle erreichbar ist und auf OPTIONS-Pakete (Keepalives) reagiert. Das hat noch nichts mit einer erfolgreichen Registriertung zu tun, die ihrerseits für die eingehenden Anrufe notwendig ist.
Insoweit wäre spannend zu sehen, was im Fehlerfall bei sip show registry herauskommt ...

 

[sunnyman]

Ah, OK.
sip show registry sagt "Registered", auch im Fehlerfall.

 

[sparkie]

Hintergrund: Die 1.8 bricht die (Re)Registrierung ab, wenn vom peer ein SIP/403 Ergebnis (Forbidden) kommt. Mit dieser Einstellung ist es in den höheren 1.8er Versionen (ich weiß aber nicht mehr ab welcher) möglich, das Verhalten so zu beeinflussen, dass es der Asterisk doch weiter versucht (und es edann auch wieder klappt).

man braucht nicht unbedingt einen Asterisk bei dem das Forbidden/Retry Verhalten gefixt ist.

mit einer vernuenftigen Firewall kann man dem Asterisk das Forbidden mit Patternmatch + Drop auch schlicht weg vorenthalten

Beispiel:

/sbin/iptables -I INPUT -i eth1 -p udp -m string --string "403 Forbidden" --algo bm -j DROP

siehe hier: Permalink

 

[sunnyman]

man braucht nicht unbedingt einen Asterisk bei dem das Forbidden/Retry Verhalten gefixt ist.
mit einer vernuenftigen Firewall kann man dem Asterisk das Forbidden mit Patternmatch + Drop auch schlicht weg vorenthalten

Ein schöner Hack, hilft mir nur bei meinem Problem nicht, da Asterisk ja ja offenbar der Meinung ist, es bestünde eine Verbindung.

 

[xrated]

probiere mal qualifyfreq 3600 und alle expiry Parameter auf default lassen

 

[StephanHAJ]

Wenn nach einem IP-Wechsel ein gehender Verbindungsaufbau mit "Forbidden" abgelehnt wird und nach 'sip reload' alles wieder funktioniert, ist die Fehlerursache m.E. eine andere:

Der Asterisk speichert für das Register die mit "tel.t-online.de" aufgelöste IP-Adresse. Nach einem IP-Adresswechsel am Anschluss werden die zuständigen Server für die Telefonie vom Telekom-DNS neu vergeben (vmtl. Lastverteilung). Für das Register verwendet der Asterisk aber weiterhin die bereits gespeicherte IP-Adresse des ursprünglichen Servers.

Erfolgt nun ein Verbindungsaufbau vom Asterisk wird die Adresse "tel.t-online.de" aufgelöst und zeigt auf den neu zugeteilten Server. Der Server akzeptiert aber keinen Verbindungsaufbau von einem nicht registrierten Endgerät und lehnt den Verbindungsaufbau mit "Forbidden" ab.

Das Register läuft weiterhin gegen den ursprünglichen Server und zeigt natürlich auch keinen Fehler an.

Nach einem 'sip reload' wird dann auch für das Register die IP-Adresse neu ermittelt und alles funktioniert wieder.

Ich konnte bei mir das Problem mit STUN im Asterisk (11.6) lösen. Sobald ein IP-Adresswechsel mit STUN erkannt wurde, erfolgt eine Neuregistrierung am neuen Server. Seitdem ist bei mir Ruhe und ich hatte mit abgehenden Verbindungen keine Probleme mehr.

 

[xrated]

Das dürfte aber nur solange ein Problem sein wie die alte Registrierung gültig ist, also afaik 1 Std. bei Telekom.

Falls man externhost mit ddns verwendet, muss der natürlich auch vorher die korrekte IP haben sonst registriert man sich mit der falschen IP.
Ich verwende mittlerweile kein ddns mehr sondern setze externhost als Parameter mit #exec
https://leifmadsen.wordpress.com/2011/02/27/using-exec-to-set-externaddr-in-sip-conf/
Man muss dann von aussen einen sip reload machen wenn sich die IP ändert.
Nur mit stun gehts leider nicht da der explizit nur neu registriert.
Und ganz ohne externhost gehts auch nicht bei den meisten Anbietern, da diese keine privaten IPs aktzeptieren.

Gegen wechslende Peers hilft auch dnsmgr, stun ist mehr dazu gedacht wenn sich die eigene IP ändert.

 

[StephanHAJ]

@xrated: es geht nicht um die eigene IP-Adresse des Asterisk. Das funktioniert korrekt.

Es geht darum, dass für das Register die Domain "tel.t-online.de" nicht neu aufgelöst wird, bei einem Verbindungsaufbau aber sehr wohl.
Somit läuft das Register weiterhin zum Server A und der Verbindungsaufbau zum Server B. Server B lehnt den Verbindungsaufbau aber ab, da dort kein Register vorliegt.

Dieser Umstand wird erst mit 'sip reload' oder STUN behoben.

Der dnsmgr wirkt offenbar auch nicht auf das Register, das hatte ich m.W. probiert. Ist aber inzwischen einige Zeit her.

 

[sunnyman]

Das klingt ja geradezu so, als gäbe es keine Lösung ?

Und was mich viel mehr ärgert: warum kann jeder popelige Plasterouter sowas out of the box?

 

[thtomate12]

Weil der "popelige Plasterouter" die Einwahl (und sogar NAT) macht, damit weiß er wenn sich die IP ändert.

 

[sunnyman]

Weil der "popelige Plasterouter" die Einwahl (und sogar NAT) macht, damit weiß er wenn sich die IP ändert.

StephanHAJ zufolge verfügt aber auch das Asterisk über das Wissen, dass sich die IP geändert hat, reagiert aber nicht "richtig" darauf.

 

[sparkie]

wenn das Verhalten so wie beschrieben sein sollte frage ich mich wieso die Telekom

- den Verbindungsaufbau ablehnt
aber
- die Registrierung (auf den angeblich falschen Server) erlaubt

woher soll Asterisk bei diesem widerspruechlichen Telekom-Verhalten wissen was zu tun ist?

den Pfusch hat dann die Telekom zu verantworten und zu fixen

 

[sunnyman]

wenn das Verhalten so wie beschrieben sein sollte frage ich mich wieso die Telekom

- den Verbindungsaufbau ablehnt

Weil für den Teilnehmer der gerade anfragt keine gültige Registrierung vorhanden ist. Das Asterisk registriert sich ja die ganze Zeit fröhlich (und erfolgreich!) weiter an einem Server mit anderer IP.

aber
- die Registrierung (auf den angeblich falschen Server) erlaubt

Der ist ja nicht falsch, nur weil es nicht mehr der ist der gerade bei der DNS-Auflösung ausgespuckt wird.

- - - Aktualisiert - - -

So, da es an anderer Stelle Erfolg versprechend war, habe ich jetzt auf 3 Maschinen mal testweise den dnsmgr zugeschaltet.

 

[rentier-s]

Ihr redet hier gerade etwas aneinander vorbei, es geht wohl um zwei verschiedene Geschichten.

Zum einen, wenn sich die eigene öffentliche IP Adresse ändert, das muss Asterisk auf irgendeine Art und Weise erkennen und sich mit der neuen Adresse neu registrieren. Das kann man mit diversen Mitteln in den Griff bekommen. So oft wechseln die Adressen ja im Normalfall nicht mehr, also falls man nicht ausgerechnet genau nach einem Wechsel telefonieren will, bevor Asterisk die Änderung erkannt hat, sollte das kein allzu großes Problem darstellen.

Das zweite, wenn man seitens TCom auf einen anderen Load Balancer verlegt wird. Ich kann mir das auch durchaus vorstellen, dass es dann zu Problemen kommt, den Verdacht hatte ich schon mal in einem anderen Zusammenhang (Diskussion um allowguest für ankommende Anrufe). Das würde allerdings nicht nur Asterisk betreffen, sondern alle Router, sofern diese den Host bei einem Anrufversuch jedes Mal neu auflösen. Wahrscheinlich fällt das, sofern das tatsächlich so ist, dem Normalbürger nicht auf, der denkt sich wahrscheinlich ist halt grad besetzt. Wenn dann auch noch der Router so schlau ist und nach einem Fehler vorsichtshalber das Register erneuert, ist 10 Sekunden später alles wieder in Ordnung.

Kennt jemand das Verhalten des dnsmgr im Bezug auf Register? Man müsste bei einer Änderung der unter tel.t-online.de aufgelösten Adresse ja Asterisk zu einer Erneuerung der Registrierungen veranlassen. Laut StephanHAJ ist das nicht der Fall. Alternativ mit einem Skript alle paar Minuten mit host die Adresse abfragen und ggf ein sip reload an Asterisk schicken.

Evtl könnte jemand, der vermehrt unter dem Problem leidet, einfach mal vor jedem Dial() eine host Abfrage mit System() ausführen und protokollieren, ob sich die Adresse von der unterscheidet, an die das letzte Register ging. Dann wüssten wir genau, ob es wirklich daran liegt.

@StephanHAJ, STUN muss man bei Asterisk etwas differenzieren. Bei 1.8 gab es mal eine missglückte Implementierung, die wieder entfernt wurde. Danach gab es erst mal nur noch den res_stun_monitor, der lediglich mittels STUN eine Änderung der WAN Adresse erkennt und ein Re-Register veranlasst. Erst ab 13 haben chan_sip und chan_pjsip wieder eine echte STUN Funktion, was die taugt kann ich aber nicht sagen.

 

[sparkie]

wenn ich derartige Probleme habe starte ich einfach das anhaengende Script auf meinem Router. Interface und Asterisk-IP etc. ggfs. natuerlich entsprechend anpassen.

Das dumpt den kompletten VoIP Traffic in fortlaufend nummerierte Files mit handlicher Laenge. Diese kann ich dann, wenn der Fehler aufgetreten ist, in aller Ruhe analysieren. Z.B. mit wireshark(1) Damit kann man sogar die Gespraeche nochmal komplett anhoeren. So sie denn ueberhaupt zustande kamen.

Anhaenge (z.B. *.gz Files) scheinen von der Forumssoftware nicht mehr unterstuetzt zu werden. Bei Manage-Attachments bekomme ich nur ein leeres Fenster praesentiert???
Dann cut&paste ich das SCript eben gleich direkt hier rein (ist ja ned lang)

#!/bin/sh

exec >> $0.log 2>&1

cat > $0_$$.awk << !
func pr(a \
    )
{
    print strftime("%y-%m-%d %T") ": " a
    fflush()
}

BEGIN {
    ASTERISK_IP = "192.168.153.145"
    system("rm $0_$$.awk")
    CMD = "/var/run/scan_tcpdumpd.pid"; print "-" PROCINFO["pgrpid"] > CMD; close(CMD)

    DUMP_DIR = "/root/TD/"
    DUMP_FILE = "trace"
    DUMP_PFX = ".[0-9][0-9]"

    # 20000 pkts - 4694310 bytes trace.00

    PCKTS_PER_FILE = 200000
    MAX_FILES = 100

    # find file number where to continue
    NEXT = 0
    CMD = "ls -t " DUMP_DIR DUMP_FILE DUMP_PFX " 2>&1"
    while (CMD | getline line > 0) {
        if (match(line, DUMP_DIR DUMP_FILE ".([0-9][0-9])", a)) {
            NEXT = a[1]
            NEXT = (NEXT + 1) % MAX_FILES
            break
        }
    }
    close(CMD)

    pr("--- starting tcpdump service: " PCKTS_PER_FILE " pckts/file, " MAX_FILES " files to rotate ---")
    system("mkdir -p " DUMP_DIR)
    while (!TERMINATED) {
        FILE = DUMP_DIR DUMP_FILE "." sprintf("%02d", NEXT)
        CMD = "tcpdump "                            \
              "-i eth0 "                            \
              "host " ASTERISK_IP " "               \
              "-B 4096 -n -c " PCKTS_PER_FILE " "   \
              "-w " FILE " "                        \
              "2>&1"

        pr("CMD: " CMD)
        mangle_pidfile = 0
        while (CMD | getline line > 0) {
            if (!mangle_pidfile++) {
                CMD1 = "pgrep ^tcpdump"
                while (CMD1 | getline line1 > 0) {
pr("<" line1 ">")
                    CMD2 = "/var/run/scan_tcpdumpd.pid"; print line1 > CMD2; close(CMD2)
                }
                close(CMD1)
            }
            if (match(line, "^([0-9]+) packets captured", a)) {
                if (a[1] >= PCKTS_PER_FILE) {
                    # continue
                } else {
                    pr("terminates by signal: max packet count not reached")
                    ++TERMINATED
                }
            }
            pr(line)
        }
        close(CMD)
        NEXT = (NEXT + 1) % MAX_FILES
    }
}
!
exec awk -f $0_$$.awk

 

[xrated]

@xrated: es geht nicht um die eigene IP-Adresse des Asterisk. Das funktioniert korrekt.

Es geht darum, dass für das Register die Domain "tel.t-online.de" nicht neu aufgelöst wird, bei einem Verbindungsaufbau aber sehr wohl.
Somit läuft das Register weiterhin zum Server A und der Verbindungsaufbau zum Server B. Server B lehnt den Verbindungsaufbau aber ab, da dort kein Register vorliegt.

Dieser Umstand wird erst mit 'sip reload' oder STUN behoben.

Das ist mir klar das es nicht um die eigene IP geht aber diese kann auch ein Problem sein, nicht nur der Peer.
stun ist aber m.M.n. nur dazu da um die eigene öffentliche IP zu überwachen und macht eine Neuregistrierung falls sich diese ändert.
Hilft also nicht wenn sich ausschließlich der Remote Peer ändert.
Das ist dann wohl mehr Zufall wenn stun hilft, weil bei der Zwangstrennung beide Sachen gleichzeitig geändert werden.

Der dnsmgr wirkt offenbar auch nicht auf das Register, das hatte ich m.W. probiert. Ist aber inzwischen einige Zeit her.

In den Sourcen schaut das tatsächlich so aus als ob Asterisk nur einen dns refresh macht.
Nach Ablauf der bestehenden Registrierung müsste dann die erneute Registierung auf jeden Fall wieder ok sein.
Oder eben ein extern angesteuertes sip reload, das lädt ja alles komplett neu.

Man fragt sich aber schon warum sowas nicht in dnsmgr implementiert ist oder ich hab mich verguckt.

Meine Vorgehensweise zur Zeit:
Eigene IP (Abfrage stun server) und Remote Peers (host Befehl) mit externem Script überwachen, wenn sich diese ändern: sip reload.
In sip.conf mit Script (#exec) die öffentliche IP direkt reinschreiben, anstatt ddns zu benutzen welches nur eine zusätzliche Fehlerquelle ist. Stun geht damit allerdings nicht weil da nur ein Reregister stattfindet aber kein sip reload.

 

[sunnyman]

Kurzer Zwischenstand meinerseits: hier läufts seit Aktivieren des dnsmgr stabil, seit ein paar Tagen schon.

 

[tob_]

Der Asterisk speichert für das Register die mit "tel.t-online.de" aufgelöste IP-Adresse. Nach einem IP-Adresswechsel am Anschluss werden die zuständigen Server für die Telefonie vom Telekom-DNS neu vergeben (vmtl. Lastverteilung). Für das Register verwendet der Asterisk aber weiterhin die bereits gespeicherte IP-Adresse des ursprünglichen Servers.

Erfolgt nun ein Verbindungsaufbau vom Asterisk wird die Adresse "tel.t-online.de" aufgelöst und zeigt auf den neu zugeteilten Server. Der Server akzeptiert aber keinen Verbindungsaufbau von einem nicht registrierten Endgerät und lehnt den Verbindungsaufbau mit "Forbidden" ab.

Das Register läuft weiterhin gegen den ursprünglichen Server und zeigt natürlich auch keinen Fehler an.

Nach einem 'sip reload' wird dann auch für das Register die IP-Adresse neu ermittelt und alles funktioniert wieder.

Mein Asterisk läuft ohne NAT direkt auf dem Gerät mit der öffentlichen IP, und bei einer Neueinwahl wird automatisch ein "sip reload" ausgeführt, um sofort wieder erreichbar zu sein.

Allerdings habe ich an meinem Anschluss eine weitere Fehlerquelle entdeckt. Eigentlich soll sich der SRV-Record für tel.t-online.de nur beim Verbindungsaufbau ändern und nicht während der laufenden Verbindung. Da ich aber auch IPv6 verwende, bekomme ich beim Verbindungsaufbau insgesamt 4 DNS-Server zugewiesen (2x IPv4, 2x IPv6) - und genau an dieser Stelle scheint die Lastverteilung nicht bis zu Ende sauber implementiert zu sein: die IPv4- und IPv6-DNS-Server liefern jeweils eine andere Antwort für den SRV-Record von tel.t-online.de:

# dig @217.237.149.205 +short +noshort +identify SRV _sip._udp.tel.t-online.de
_sip._udp.tel.t-online.de. 3600    IN    SRV    0 5 5060 f-epp-207.isp.t-ipnet.de.
_sip._udp.tel.t-online.de. 3600    IN    SRV    1 5 5060 h-epp-207.isp.t-ipnet.de.
;; Received 131 bytes from 217.237.149.205#53(217.237.149.205) in 8 ms

# dig @217.237.151.51 +short +noshort +identify SRV _sip._udp.tel.t-online.de
_sip._udp.tel.t-online.de. 3600    IN    SRV    0 5 5060 f-epp-207.isp.t-ipnet.de.
_sip._udp.tel.t-online.de. 3600    IN    SRV    1 5 5060 h-epp-207.isp.t-ipnet.de.
;; Received 131 bytes from 217.237.151.51#53(217.237.151.51) in 11 ms

# dig @2003:180:2:6000::53 +short +noshort +identify SRV _sip._udp.tel.t-online.de
_sip._udp.tel.t-online.de. 3600    IN    SRV    1 5 5060 s-epp-102.isp.t-ipnet.de.
_sip._udp.tel.t-online.de. 3600    IN    SRV    0 5 5060 b-epp-102.isp.t-ipnet.de.
;; Received 131 bytes from 2003:180:2:6000::53#53(2003:180:2:6000::53) in 9 ms

# dig @2003:180:2::53 +short +noshort +identify SRV _sip._udp.tel.t-online.de
_sip._udp.tel.t-online.de. 3600    IN    SRV    0 5 5060 b-epp-102.isp.t-ipnet.de.
_sip._udp.tel.t-online.de. 3600    IN    SRV    1 5 5060 s-epp-102.isp.t-ipnet.de.
;; Received 131 bytes from 2003:180:2::53#53(2003:180:2::53) in 11 ms

Da die 4 Nameserver von meinem Resolver (dnsmasq) zufällig verwendet werden, kann sich der Wert nach jeweils einer Stunde (TTL 3600) ändern, was dann zu oben beschriebenem Problem führt.

Lösungsmöglichkeiten:
1) im Asterisk srvlookup = no (habe ich nicht ausprobiert, da dann wohl auch uri-Dials nicht mehr zuverlässig funktionieren, die ich aber benötige - umgeht die Lastverteilung)

2) IPv6-DNS deaktivieren und nur die IPv4-DNS-Server verwenden (löst das Problem ohne die Lastverteilung zu umgehen)

3) komplett andere DNS-Server verwenden (z.B. von Google - dann gibts gar keine Änderungen des SRV-Records - umgeht die Lastverteilung)

4) bei der Einwahl per Skript den SRV-Record genau einmal gezielt auflösen und dann bis zur nächsten Einwahl im Resolver fest "cachen" - z.B. dnsmasq.conf:

srv-host=_sip._udp.tel.t-online.de,f-epp-207.isp.t-ipnet.de,5060,0,5
srv-host=_sip._udp.tel.t-online.de,h-epp-207.isp.t-ipnet.de,5060,1,5

(löst das Problem ohne die Lastverteilung zu umgehen)

5) den SRV-Record statisch eintragen, so wie er bei der Verwendung von fremden DNS-Servern zurückgeliefert wird:

srv-host=_sip._udp.tel.t-online.de,ims001.voip.t-ipnet.de,5060,0,5
srv-host=_sip._udp.tel.t-online.de,ims002.voip.t-ipnet.de,5060,1,5

(entspricht dann letztendlich b-epp-001.isp.t-ipnet.de und h-epp-001.isp.t-ipnet.de - umgeht die Lastverteilung)

6) den SRV-Record komplett "entfernen"

local=/_sip._udp.tel.t-online.de/

(dann verwendet Asterisk den A-Record, was letztendlich b-epp-001.isp.t-ipnet.de entspricht - umgeht die Lastverteilung)

Aktuell läuft bei mir seit einigen Wochen Lösung 4, aber auch Lösung 6 habe ich einige Wochen erfolgreich getestet.

Es ist zwar sicher unschön, eine vom Anbieter vorgesehene Lastverteilung zu umgehen, aber die paar Asterisk-Nutzer die das machen dürften gegenüber den ganzen Speedports (für die die Lastverteilung wohl in erster Linie gedacht ist) locker untergehen. Außerdem ist die Lastverteilung (zumindest aktuell) nur über den SRV-Record umgesetzt - aber nicht alle SIP-Endgeräte und SIP-Clients nutzen überhaupt SRV-Records - und nirgends steht, dass man für die IP-Telefonie die Telekom-DNS-Server nutzen muss. Daher muss die Telekom natürlich damit rechnen, dass nicht alle Endgeräte an dieser Lastverteilung teilnehmen, daher sollte es kein Problem sein, den SRV-Record "auszuschalten" oder statisch zu setzen.

Alternativ kann die Telekom den Lastverteilungs-Mechanismus auch gerne so reparieren, dass er auch mit den IPv6-DNS-Servern so funktioniert, wie gedacht.

 

[tob_]

Jetzt haben sich trotz ununterbrochener PPPoE-Verbindung (Verbindung besteht seit 41,5 Tagen) die SRV-Records auf den IPv4-Nameservern verändert:

# dig @217.237.149.205 +short +noshort +identify SRV _sip._udp.tel.t-online.de
_sip._udp.tel.t-online.de. 3600    IN    SRV    1 5 5060 h-epp-007.isp.t-ipnet.de.
_sip._udp.tel.t-online.de. 3600    IN    SRV    0 5 5060 n-epp-007.isp.t-ipnet.de.
;; Received 131 bytes from 217.237.149.205#53(217.237.149.205) in 8 ms

# dig @217.237.151.51 +short +noshort +identify SRV _sip._udp.tel.t-online.de
_sip._udp.tel.t-online.de. 3600    IN    SRV    1 5 5060 h-epp-007.isp.t-ipnet.de.
_sip._udp.tel.t-online.de. 3600    IN    SRV    0 5 5060 n-epp-007.isp.t-ipnet.de.
;; Received 131 bytes from 217.237.151.51#53(217.237.151.51) in 10 ms

Es reicht also leider nicht, auf die Änderungen nur direkt bei einer Neueinwahl zu reagieren. Am besten ist es also mit dem Asterisk, eine Lösung zu verwenden, bei der sich die Server überhaupt nicht ändern, so spart man sich viel Ärger.

 

[beda]

Hallo Kollegen

Ich habe seit längerem das gleiche Problem. Würde es auch gehen wenn man statt den DNS Namen "tel.t-online.de" einfach die direkte IP angibt... Wenn ist derzeit bei mir tel.t-online.de pinge erhalte ich die IP Adresse: 217.0.23.100...

Also einfach einmal tel.t-online.de pingen und dann immer an der Server IP registrieren die beim Ping ausgegeben wird...

Die Telekom wird ja wohl nicht von ihren SIP Servern die ständig die IPś ändern... Oder was meint Ihr... Somit umgeht man natürlich auch das LOAD BALANCING aber das wäre mir ehrlich gesagt Wurscht....

Danke und Gruß

Peter