Asterisk an T-Com Anschluss - plötzlich keine Nummernregistrierung mehr möglich

ltrotzki

Neuer User
Mitglied seit
22 Okt 2015
Beiträge
25
Punkte für Reaktionen
0
Punkte
0
Ich betreibe einen Asterisk-Server (13.1 LTS) hinter einem T-Com Anschluss mit dynamischer IP hinter einem NAT-Router. Plötzlich, seit heute morgen, keine Registrierung mehr möglich. Ich kann den Server neustarten, so oft ich mag. Das ganze lief jetzt zwei Wochen ohne Probleme und nun das:

Code:
[Nov 13 10:50:38] NOTICE[763] chan_sip.c:    -- Registration for '[email protected]' timed out, trying again (Attempt #6)
[Nov 13 10:50:38] NOTICE[763] chan_sip.c:    -- Registration for '[email protected]' timed out, trying again (Attempt #6)
[Nov 13 10:50:38] NOTICE[763] chan_sip.c:    -- Registration for '[email protected]' timed out, trying again (Attempt #6)

Ab und an mal:

Code:
[Nov 13 10:41:09] WARNING[763] chan_sip.c: Retransmission timeout reached on transmission [email protected] for seqno 102 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 32000ms with no response
[Nov 13 10:41:09] WARNING[763] chan_sip.c: Retransmission timeout reached on transmission [email protected] for seqno 102 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 32000ms with no response
[Nov 13 10:41:09] WARNING[763] chan_sip.c: Retransmission timeout reached on transmission [email protected] for seqno 102 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions

Ist jemand von demselben Problem betroffen, das es plötzlich nicht mehr tut (ohne Config-Änderung)? Hat die T-Com was umgebaut?

sip.conf:
Code:
[general]
context=public                  ; Default context for incoming calls. Defaults to 'default'
allowoverlap=no                 ; Disable overlap dialing support. (Default is yes)
udpbindaddr=0.0.0.0             ; IP address to bind UDP listen socket to (0.0.0.0 binds to all)
tcpenable=no                    ; Enable server for incoming TCP connections (default is no)
tcpbindaddr=0.0.0.0             ; IP address for TCP server to bind to (0.0.0.0 binds to all interfaces)
transport=udp                   ; Set the default transports.  The order determines the primary default transport.
srvlookup=yes                   ; Enable DNS SRV lookups on outbound calls
qualify=yes
register=0725312345:01234567:[email protected]@tel.t-online.de/0725312345~3600
register=0725367890:01234567:[email protected]@tel.t-online.de/0725367890~3600
register=0725312378:01234567:[email protected]@tel.t-online.de/0725312378~3600
bindport=5060
allowguest=no
alwaysauthrejct=yes
externhost=mydnsname.dyndns.org
externrefresh=30
localnet=192.168.1.0/255.255.255.0
disallow=all
allow=alaw,ulaw,gsm
maxexpiry=3600
defaultexiry=1800
registertimeout=120
language=de

[tcom-in]
qualify=yes
type=peer
context=incoming
allow=ulaw,alaw,g722
session-timers=refuse
[email protected]
[email protected]
remotesecret=1234567
sendrpid = no
trustrpid = yes
host=tel.t-online.de
fromdomain=tel.t-online.de
nat=auto_force,auto_comedia
directmedia=no

STUN habe ich auch drin. Das funktioniert alles.

[Beitrag 2:]

Konnte das Problem teilweise lösen. Firewall war so geconfed, das nur was von 217.0.0.0/8 auf 5060 (SIP) reingehen darf. Scheinbar hat T-Com jetzt irgendeinen Server im LB-Verbund außerhalb der normalen T-Com Range zu stehen, an den ich geraten bin. Nur eine einzige Nummer, kann momentan nicht registriert werden, er sagt Service Unavailable:
Code:
[Nov 13 11:20:42] NOTICE[1337]: chan_sip.c:15254 sip_reg_timeout:    -- Registration for '[email protected]' timed out, trying again (Attempt #4)
    -- Got SIP response 503 "Service Unavailable" back from 217.0.23.4:5060

[Beitrag 3:]

Kann mir vielleicht jemand in diesem Zusammenhang erklären was es mit allowguest=no auf sich hat. Ich habe im Zusammenhang mit den REGISTER TIMEOUTS gelesen, dass manche Benutzer "Guests zulassen"? Was hat es damit auf sich?
 
Zuletzt bearbeitet von einem Moderator:
Zunächst: Die Konfig sieht gut aus, das ist dann ein anderes Problem. Da Du nach FW-Anpassung die 503 bekommst, solltest Du tatsächlich mal bei der Telekom nachfragen, denn die Fehlermeldung kommt von denen.
Im Übrigen: 217.0.0.0/8 ist für die Telekom schon richtig, alle mir bekannten SIP-Srver des LoadBalancer-Verbundes der Telekom liegen in diesem Netz.

Was das allowguest anbelangt: Da die Telekom die Balancer nicht maskiert, kann ein eingehender Anruf von einer beliebigen IP aus 217.0.0.0/8 kommen. Da Asterisk im host-Eintrag des peers aber nur einen FQDN/eine IP unterstützt, kann es bei einkommenden Calls Probleme geben, wenn nicht alle IPs des Telekom Loadbalancer-Verbundes explizit konfiguriert sind. Wer dann diese Arbeit scheut (zumal schon mal neue Server dazukommen), arbeitet gerne mit allowguest=yes um darüber die Calls empfangen zu können.
 
Danke abw1oim für die ausführliche Erklärung. Das leuchtet ein. Angenommen man möchte alle IPs pflegen, wie soll man das denn realisieren? Es müsste ja irgendwo im System eine statische Zuordnung geben, also tel.t-online.de => {217.0.21.1, 217.0.23.45, ...}
 
Zuletzt bearbeitet:
z.B. so (aktueller Stand bei mir)

in sip.conf im general-Bereich:

Code:
[external-standard](!)
        type=peer
        usereqphone=no
        t38pt_udptl=no
        nat=yes
        directmedia=no
        disallow=all
        allow=ulaw
        allow=alaw
        dtmfmode=rfc2833
        sendrpid=yes
        trustrpid=no
        rpid_update=yes
        trust_id_outbound=yes
        context=inc_pstn

#include sip_thome.conf

sip_thome.conf

Code:
[DTAG-IP_IN16_026](external-standard)
host=217.0.16.26

[DTAG-IP_IN16_035](external-standard)
host=217.0.16.35

[DTAG-IP_IN16_090](external-standard)
host=217.0.16.90

[DTAG-IP_IN16_102](external-standard)
host=217.0.16.102

[DTAG-IP_IN16_106](external-standard)
host=217.0.16.106

[DTAG-IP_IN16_154](external-standard)
host=217.0.16.154

[DTAG-IP_IN16_163](external-standard)
host=217.0.16.163

[DTAG-IP_IN16_166](external-standard)
host=217.0.16.166

[DTAG-IP_IN16_170](external-standard)
host=217.0.16.170

[DTAG-IP_IN16_227](external-standard)
host=217.0.16.227

[DTAG-IP_IN16_230](external-standard)
host=217.0.16.230

[DTAG-IP_IN16_231](external-standard)
host=217.0.16.231

[DTAG-IP_IN17_026](external-standard)
host=217.0.17.26

[DTAG-IP_IN17_035](external-standard)
host=217.0.17.35

[DTAG-IP_IN17_090](external-standard)
host=217.0.17.90

[DTAG-IP_IN17_102](external-standard)
host=217.0.17.102

[DTAG-IP_IN17_106](external-standard)
host=217.0.17.106

[DTAG-IP_IN17_154](external-standard)
host=217.0.17.154

[DTAG-IP_IN17_163](external-standard)
host=217.0.17.163

[DTAG-IP_IN17_166](external-standard)
host=217.0.17.166

[DTAG-IP_IN17_170](external-standard)
host=217.0.17.170

[DTAG-IP_IN17_227](external-standard)
host=217.0.17.227

[DTAG-IP_IN17_230](external-standard)
host=217.0.17.230

[DTAG-IP_IN17_231](external-standard)
host=217.0.17.231

[DTAG-IP_IN19_026](external-standard)
host=217.0.19.26

[DTAG-IP_IN19_035](external-standard)
host=217.0.19.35

[DTAG-IP_IN19_090](external-standard)
host=217.0.19.90

[DTAG-IP_IN19_102](external-standard)
host=217.0.19.102

[DTAG-IP_IN19_106](external-standard)
host=217.0.19.106

[DTAG-IP_IN19_154](external-standard)
host=217.0.19.154

[DTAG-IP_IN19_163](external-standard)
host=217.0.19.163

[DTAG-IP_IN19_166](external-standard)
host=217.0.19.166

[DTAG-IP_IN19_170](external-standard)
host=217.0.19.170

[DTAG-IP_IN19_227](external-standard)
host=217.0.19.227

[DTAG-IP_IN19_230](external-standard)
host=217.0.19.230

[DTAG-IP_IN19_231](external-standard)
host=217.0.19.231

[DTAG-IP_IN20_026](external-standard)
host=217.0.20.26

[DTAG-IP_IN20_035](external-standard)
host=217.0.20.35

[DTAG-IP_IN20_090](external-standard)
host=217.0.20.90

[DTAG-IP_IN20_102](external-standard)
host=217.0.20.102

[DTAG-IP_IN20_106](external-standard)
host=217.0.20.106

[DTAG-IP_IN20_154](external-standard)
host=217.0.20.154

[DTAG-IP_IN20_163](external-standard)
host=217.0.20.163

[DTAG-IP_IN20_166](external-standard)
host=217.0.20.166

[DTAG-IP_IN20_170](external-standard)
host=217.0.20.170

[DTAG-IP_IN20_227](external-standard)
host=217.0.20.227

[DTAG-IP_IN20_230](external-standard)
host=217.0.20.230

[DTAG-IP_IN20_231](external-standard)
host=217.0.20.231
 
Ich würde einfach iptables weiter einschränken von 217.0.16.x-217.0.20.y und mit allowguest=yes. Dann landen die Anrufe alle in Default die von anderen Peers als definiert kommen.

Im Default könnte man nochmal die eigene exten eintragen und mit Goto in den entsprechenden Context weiterleiten. Und alles andere also z.b. _X. einfach Loggen und danach hangup. Dann landet man nur im Asterisk wenn zumindest die richtige Rufnummer gewählt wurde.

Weil bei mir mit 1&1 alles mit 49 vorne reinkommt was man nicht zurückrufen kann weil vorne 00 oder + fehlt, ersetze ich noch die 49 durch 0.
 
Danke abw10im für die gute Erklärung.
Mir leuchtet aber nicht ein, dass, wenn ich den Traffic auf Port 5060 auf 217.0.0.0/8 beschränke, Asterisk nicht mehr am T-Com Server registrieren kann (auf einmal). Wenn ich alles durchlasse, gehts. Dann bekomm ich aber jetzt eine Menge Spam:
Code:
[Nov 14 11:23:42] NOTICE[14088][C-0000005b] chan_sip.c: Failed to authenticate device 205<sip:[email protected]>;tag=4ec23a37
[Nov 14 11:24:04] NOTICE[14088][C-0000005c] chan_sip.c: Failed to authenticate device 205<sip:[email protected]>;tag=4c60971b
[Nov 14 11:24:26] NOTICE[14088][C-0000005d] chan_sip.c: Failed to authenticate device 300<sip:[email protected]>;tag=40893e5b
[Nov 14 11:24:49] NOTICE[14088][C-0000005e] chan_sip.c: Failed to authenticate device 300<sip:[email protected]>;tag=a6da94d3
[Nov 14 11:25:11] NOTICE[14088][C-0000005f] chan_sip.c: Failed to authenticate device 300<sip:[email protected]>;tag=0aecefb2
Das Device wird zufällig gewählt und wie man sieht, jede 32 Sekunden tritt es auf.
 
Mir leuchtet aber nicht ein, dass, wenn ich den Traffic auf Port 5060 auf 217.0.0.0/8 beschränke, Asterisk nicht mehr am T-Com Server registrieren kann

Das ist in der Tat merkwürdig. Kannst Du mal schauen, ob

- Die Pakete (REGISTER) tatsächlich auch rausgehen (und nicht irgendwo geblockt werden)
- Antwortpakete am Router ankommen und ggf. verworfen werden.

Nach leidvoller Erfahrung habe ich schon manches mal feststellen müssen, dass die Ursache auch mal eine entsprechende unbeabsichtigte Firewallblockierung war ...
 
Ich kann das ganze ja mal debuggen. Vorgeschaltet ist nur pfSense mit eigentlich sauber konfigurierter Firewall. Auch habe ich jetzt hin und wieder REGISTER timeouts. Asterisk bekomme ich dann nur noch zum Laufen durch ein restart des Dienstes. Das artet soweit aus, dass ich ein cronjob laufen lasse, welcher überwacht ob timeouts im log auftauchen. Das kann natürlich nicht die Lösung sein.
pfSense sollte ja eigentlich keine SIP-Magie produzieren.
Debug: Wie funktioniert das interne Debugging in Asterisk? Bisher schneide ich alles mit tcpdump mit, was ein wenig mühselig auszuwerten ist.
 
Zuletzt bearbeitet von einem Moderator:
In Asterisk auf der CLI:

Code:
sip set debug peer tcom-in

Dabei berücksichtigen, dass in /etc/asterisk/logger.conf eingestellt ist, dass DEBUG-Messages auch in ein logfile (messages oder full oder ein dezidiertes File) geloggt werden (Nach Änderungen dort den logger reload auf der Asterisk-CLI nicht vergessen).

Mit dieser Einstellung werden alle SIP-Nachrichten zum und vom peer (und damit von/nach der IP tel.t-online.de) geloggt.
 
okay, hab debug an, mal gucken was da so reinkommt. muss warten bis der REGISTER timeout wieder auftritt.

was mir aber sofort auffällt, weil gerade ein Call rausgeht:
Code:
<------------->
--- (13 headers 0 lines) ---

 [B][Nov 17 15:40:24] NOTICE[15287]: chan_sip.c:23749 handle_response_register: Outbound Registration: Expiry for tel.t-online.de is 660 sec (Scheduling reregistration in 645 s)[/B]

 [B]Really destroying SIP dialog '[email protected]' Method: REGISTER[/B]

 [B][Nov 17 15:40:24] NOTICE[15287]: chan_sip.c:15180 sip_reregister:    -- Re-registration for  [email protected][/B]

 REGISTER 12 headers, 0 lines

  Reliably Transmitting [B](no NAT)[/B] to 217.0.23.100:5060:
 REGISTER sip:tel.t-online.de SIP/2.0
 Via: SIP/2.0/UDP 79.123.456.789:5060;branch=z9hG4bK3d35d9c5
 Max-Forwards: 70
 From: <sip:[email protected]>;tag=as412f3862
 To: <sip:[email protected]>

 Call-ID: [email protected]
 CSeq: 151 REGISTER
 Supported: replaces, timer
 User-Agent: Asterisk PBX 13.1-cert2

 ...
 ---
 
<--- SIP read from UDP:217.0.23.100:5060 --->

 SIP/2.0 200 OK

 Via: SIP/2.0/UDP 79.123.456.789:5060;branch=z9hG4bK3d35d9c5
 To: <sip:[email protected]>;tag=x9krqt11hjzh73uzyq4olrh7volt45xs

 From: <sip:[email protected]>;tag=as412f3862
 Call-ID: [email protected]
 CSeq: 151 REGISTER

 Contact: <sip:[email protected]:5060>;expires=660
 P-Associated-Uri: <sip:[email protected]>
 P-Associated-Uri: <tel:+49725312345>
 Supported: replaces

 Supported: timer
 User-Agent: Asterisk PBX 13.1-cert2
 Content-Length: 0

- Kann man den REGISTER timeout nicht höher stellen?
- Warum steht da No Nat und es taucht auch die interne IP auf. Config sagt doch NAT und externhost ist auch angegeben
 
Zuletzt bearbeitet:
sip set debug peer tcom-in

Ich bin mir nicht sicher, ob das hier reicht. Asterisk löst den Hostnamen im Moment der Eingabe auf und zeigt nur der Verkehr mit dieser einen IP-Adresse. Wenn man an einen anderen Load-Balancer gerät, wird der Verkehr dorthin glaube ich nicht mehr angezeigt.

Das Re-Register Interval kommt vom Provider, man kann in Asterisk nur die akzeptierten Grenzen einstellen. Wenn die zu kurz oder zu lang sind, lehnt die T-Com die Registrierung aber gnadenlos ab. Gut 10 Minuten ist aber auch vollkommen in Ordnung.

no NAT ist in diesem Fall auch richtig, der T-Com Server befindet sich ja nicht hinter einem NAT.

Die interne IP-Adresse steht nur im Bezeichner des Channels, das ist OK. In den Headern des Pakets steht die WAN Adresse, das ist wichtig.

Wie hast Du die Regeln für ankommende Verbindungen in der Firewall definiert? Ist da wirklich ankommend erlaubt oder abgehend mit referred/established (NAT Prinzip)? Weil an Asterisk wird es nur recht unwahrscheinlich liegen, wenn es ohne Restriktionen in der Firewall funktioniert.

Btw., Dienst (=Asterisk) neu starten muss nicht sein, sip reload reicht normalerweise aus, und ein anderer bindport als 5060 schützt zuverlässig vor Attacken.
 
@rentier-s

Ich bin mir nicht sicher, ob das hier reicht.

Da magst Du recht haben. Wenn alle Stränge reißen, muss man einen allgemeinen sip debug machen (da man ja nur auf peers bzw. IPs einschränken kann und dann wird es schnell unübersichtlich, da die internen sip-Clients und ggf. weitere Provider auch noch geloggt werden.

Ansonsten bin ich bei Dir, dass der Asterisk sehr unwahrscheinlich als Fehlerursache ist. ich tippe hier auch auf die FW. Allerdings hatte der OP ja betont, dass der gesamte IP-Range der DTAG erlaubt sei, das macht mich dann schon etwas stutzig ...
 
FW ist Stateful Inspection, d.h. erst muss ausgehend initiiert werden, bevor ein Paket reinkommen darf (established). In diesem Fall gibt es aber ein port forwarding auf eine interne Adresse (192.168.1.61:5060) und dann auch noch UDP -> verbindungslos -> nichts zu tracken, dementsprechend greift die Firewall hier nicht. Es könnte aber möglich sein, dass die Firewall Pakete droppt, wenn Asterisk nach draußen schickt und vorher nichts reinkam. Daran könnte es tatsächlich liegen und es würde auch ins Bild passen, da es für Tage oder Stunden geht und dann plötzlich nicht mehr. Ich lege mal noch eine Regel an, welche auch ausgehend alles erlaubt von der internen IP Adresse. Ich lasse euch wissen, wie es damit läuft.
 
Es könnte aber möglich sein, dass die Firewall Pakete droppt, wenn Asterisk nach draußen schickt und vorher nichts reinkam.

Wenn sich die FW so verhalten sollte, hast Du Deinen Grund: Bei Registrierungspaketen ist immer der Client (also Asterisk) der aktive Teil, er initiiert den Dialog, indem er einen Request sendet. Wird der von der FW abgefangen, kann naturgemäß die Bestätigung nicht zurückkommen, da die Telekom ja gar nichts von der Anfrage merkt ...
 
Ausgehend war aber auch alles richtig geconfed, sonst hätte Asterisk ja nie raustelefonieren können. Wie gesagt, zwei Wochen absolut problemlos. Ich habe folgenden Verdacht: pfSense verknüpft die FW-Regeln mit der NAT-Regel, d.h. wenn eine NAT-Regel angelegt wird, wird auch die passende FW-Regel erzeugt. Jetzt habe ich, aus Bequemlichkeit, die NAT-Regel so angepasst, dass nur Ports 217.0.0.0/8:5060 auf Asterisk umgebogen werden. Die passende FW-Regel wird erzeugt und greift dann auch. Es werde alle anderen IPs gedropped. Dort scheint es aber ein Problem zu geben - so meine Vermutung ohne weiteres Debuggen so weit.
Ich biege jetzt mal testweise alle Adressen auf Austerisk um und filtere anschließend mit der passenden FW-Regel auf 217.0.0.0/8. Ausgehend gibt es eine Regel die alles rauslässt was von Asterisk kommt. Ich berichte in ein paar Tagen, wie es sich verhält.
 
Meine Vermutung wäre eher gewesen, dass Asterisk ein Register schickt, die Antwort aber von einem anderen Load Balancer kommt. Keine Ahnung, ob das technisch möglich/sinnvoll ist. Dann nämlich würde es keine ausgehende Verbindung zu der IP-Adresse geben, von der das ACK zurück kommt. Das wiederum müsste aber auf dem WAN Trace zu sehen sein, wenn dem so wäre. Ggf musst Du Dir halt doch die Arbeit machen und das durchsuchen, ob auf ein fehlgeschlagenes Register eine Antwort kommt und von wo.

Du hast ja qualify an, insofern sollte es regelmäßig Pakete geben, damit die Route offen bleibt.
 
Meine Vermutung wäre eher gewesen, dass Asterisk ein Register schickt, die Antwort aber von einem anderen Load Balancer kommt.

Das denke ich auch. Seit meinem letzten Eintrag läuft es stabil. Hin und wieder geht nachts zwischen 0 und 1 Uhr nichts, bis die IP wechselt. Dann startet mein Script Asterisk neu und dann ist die Registrierung wieder möglich. Ich beobachte das.
 
Seit meinem letzten Post relativ stabil. Es kommt fast jede Nacht vor, dass exakt zwischen 0 und 1 Uhr nichts geht. Schaltet die Telekom da ihre Server aus?... In der Zeit laufen die Timeouts auf. An zwei Tagen seit meinem letzten Post ging nichts bis 9 Uhr morgens, 1x auch mitten am Tag für eine Stunde. Ab und an das hier im Log:
Code:
[Dec  8 21:00:03] ERROR[28716] netsock2.c: getaddrinfo("ims001.voip.t-ipnet.de", "(null)", ...): Name or service not known
[Dec  8 21:00:03] WARNING[28716] acl.c: Unable to lookup 'ims001.voip.t-ipnet.de'
Was gibt die T-Com da für einen DNS Namen raus?...

Die Stabilität ist also noch nicht perfekt. Zwei Ausfälle am Tag (zwischen 7 und 18 Uhr) in vier Wochen ist nicht tolerabel.
 
Hallo ltrotzki,

wie sieht denn die Regel aus, welche die eingehenden Verbindungen von der Telekom zulässt? Ich habe das gleiche Problem.
 
Schalte mal in der pfsense unter advanced -> firewall/nat bei "Firewall Optimization Options" auf "conservative" um - das hat bei mir damals geholfen, als ich auch große Registrierungsprobleme hatte.
Seitdem läuft unser T-Com Anschluss perfekt ohne irgendwelche Probleme (oder diese sind noch nicht aufgefallen :mrgreen: ).
Habe allerdings noch Asterisk 1.4 laufen...und keine IP range Begrenzung - alles kann auf 5060 rein, allowguest=no + LB Liste.
 

Statistik des Forums

Themen
244,943
Beiträge
2,221,325
Mitglieder
371,716
Neuestes Mitglied
Beronimus
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.