Rejecting unknown SIP connection

[Tom-VoIP]

Hallo,

bei mir läuft asterisk (freepbx) auf einem raspberry. Alle paar Wochen tritt das Problem auf, dass ankommende Anrufe mit "The number you have dialed is not in service" von asterisk beantwortet werden (Gibt es auch auf deutsch).

Im asterisk log finde ich dann die Meldung:
"Received incoming SIP connection from unknown peer“ bzw. „Rejecting unknown SIP connection from 217.0.128.133“:.
[Edit Novize: Code-Tage eingefügt]

[INDENT][2019-10-24 14:29:02] VERBOSE[26669] asterisk.c: Remote UNIX connection disconnected[/INDENT]
[INDENT][2019-10-24 14:29:24] VERBOSE[1237][C-0000007e] netsock2.c: Using SIP RTP TOS bits 184[/INDENT]
[INDENT][2019-10-24 14:29:24] VERBOSE[1237][C-0000007e] netsock2.c: Using SIP RTP CoS mark 5[/INDENT]
[INDENT][2019-10-24 14:29:24] VERBOSE[26736][C-0000007e] pbx.c: Executing [929xxxx@from-sip-external:1] NoOp(“SIP/ims.telekom.de-00000127”, “Received incoming SIP connection from unknown peer to 929xxxx”) in new stack[/INDENT]
[INDENT][2019-10-24 14:29:24] VERBOSE[26736][C-0000007e] pbx.c: Executing [929xxxx@from-sip-external:2] Set(“SIP/ims.telekom.de-00000127”, “DID=929xxxx”) in new stack[/INDENT]
[INDENT][2019-10-24 14:29:24] VERBOSE[26736][C-0000007e] pbx.c: Executing [929xxxx@from-sip-external:3] Goto(“SIP/ims.telekom.de-00000127”, “s,1”) in new stack[/INDENT]
[INDENT][2019-10-24 14:29:24] VERBOSE[26736][C-0000007e] pbx_builtins.c: Goto (from-sip-external,s,1)[/INDENT]
[INDENT][2019-10-24 14:29:24] VERBOSE[26736][C-0000007e] pbx.c: Executing [s@from-sip-external:1] GotoIf(“SIP/ims.telekom.de-00000127”, “1?setlanguage:checkanon”) in new stack[/INDENT]
[INDENT][2019-10-24 14:29:24] VERBOSE[26736][C-0000007e] pbx_builtins.c: Goto (from-sip-external,s,2)[/INDENT]
[INDENT][2019-10-24 14:29:24] VERBOSE[26736][C-0000007e] pbx.c: Executing [s@from-sip-external:2] Set(“SIP/ims.telekom.de-00000127”, “CHANNEL(language)=de_DE”) in new stack[/INDENT]
[INDENT][2019-10-24 14:29:24] VERBOSE[26736][C-0000007e] pbx.c: Executing [s@from-sip-external:3] GotoIf(“SIP/ims.telekom.de-00000127”, “1?noanonymous”) in new stack[/INDENT]
[INDENT][2019-10-24 14:29:24] VERBOSE[26736][C-0000007e] pbx_builtins.c: Goto (from-sip-external,s,5)[/INDENT]
[INDENT][2019-10-24 14:29:24] VERBOSE[26736][C-0000007e] pbx.c: Executing [s@from-sip-external:5] Set(“SIP/ims.telekom.de-00000127”, “TIMEOUT(absolute)=15”) in new stack[/INDENT]
[INDENT][2019-10-24 14:29:24] VERBOSE[26736][C-0000007e] func_timeout.c: Channel will hangup at 2019-10-24 14:29:39.345 CEST.[/INDENT]
[INDENT][2019-10-24 14:29:24] VERBOSE[26736][C-0000007e] pbx.c: Executing [s@from-sip-external:6] Set(“SIP/ims.telekom.de-00000127”, “receveip=recvip”) in new stack[/INDENT]
[INDENT][2019-10-24 14:29:24] VERBOSE[26736][C-0000007e] pbx.c: Executing [s@from-sip-external:7] Log(“SIP/ims.telekom.de-00000127”, "WARNING,“Rejecting unknown SIP connection from 217.0.128.133"”) in new stack[/INDENT]
[INDENT][2019-10-24 14:29:24] WARNING[26736][C-0000007e] Ext. s: “Rejecting unknown SIP connection from 217.0.128.133”[/INDENT]
[INDENT][2019-10-24 14:29:24] VERBOSE[26736][C-0000007e] pbx.c: Executing [s@from-sip-external:8] Answer(“SIP/ims.telekom.de-00000127”, “”) in new stack[/INDENT]
[INDENT][2019-10-24 14:29:24] VERBOSE[26736][C-0000007e] pbx.c: Executing [s@from-sip-external:9] Wait(“SIP/ims.telekom.de-00000127”, “2”) in new stack[/INDENT]
[INDENT][2019-10-24 14:29:26] VERBOSE[26736][C-0000007e] pbx.c: Executing [s@from-sip-external:10] Playback(“SIP/ims.telekom.de-00000127”, “ss-noservice”) in new stack[/INDENT]
[INDENT][2019-10-24 14:29:26] VERBOSE[26736][C-0000007e] file.c: <SIP/ims.telekom.de-00000127> Playing 'ss- noservice.g722’ (language ‘de_DE’)[/INDENT]
[INDENT][2019-10-24 14:29:30] VERBOSE[26736][C-0000007e] pbx.c: Executing [h@from-sip-external:1] Hangup(“SIP/ims.telekom.de-00000127”, “”) in new stack [/INDENT]

Der letzte Reboot war am 01.10. in der Zeit (3 Wochen) wurden über 700 Gespräche problemlos geführt. In diesen Zeitraum gab es nie die Meldung “Received incoming SIP connection” ?!?

Das sind meine chan_sip SIP Settings:

[email protected]​

type=friend​

secret=123456​

qualify=yes​

insecure=invite​

host=tel.t-online.de​

fromuser=0xxxxxxxx​

fromdomain=tel.t-online.de​

dtmfmode=rfc2833​

directmedia=no​

context=from-trunk​

session-timers=refuse​

​

SIP Settings:

Allow Anonymous Inbound SIP Calls=NO​

Type=friend oder Type=peer mach keinen Unterschied.

Reboote ich den raspberry ist das Problem sofort gelöst und das System arbeitet für 4-6 Wochen stabil. Dann geht es wieder los. Das ganze beobachte ich jetzt schon seit einem Jahr.

Ein automatischer Reboot jeden Sonntag (cron-job) behebt das Problem leider nicht.

 

[Tom-VoIP]

Lösung:

Der Raspberry nutzte als DNS Server die 1.1.1.1. Bei der Namesauflösung von tel.t-online.de antwortet dieser DNS Server mit der 217.0.128.133.

Nutzt man allerdings die Telekom DNS Server die bei der PPPOE Einwahl zugewiesen werden so erhalte ich aktuell die 217.0.27.53.

Seit der Änderung arbeitet die Anlage stabil

VOIP SIP Server meldet FORBIDDEN (Asterisk, DNS)

Hallo Community, ich habe gerade wieder eine seltsame Entdeckung beim konfigurieren meiner Asterisk-Anlage gemacht. Der VOIP SIP-Server 217.0.27.104 (do-epp-105.isp.t-ipnet.de) meldet bei ausgehenden Telefonaten immer "FORBIDDEN", trotz erfolgreichem REGISTRY und Invite-Proxy-Auth. Wenn...

telekomhilft.telekom.de

 

[gehtdoch]

Zum Background (und warum das oben als Lösung bezeichnete keine ist):

Die Architektur der Telekom AllIP realisiert Hochverfügbarkeit und Lastmanagement u.a. über viele unterschiedliche SIP-Server. Hierzu werden über den SRV SIP-Record (über die eigenen DNS-Server) in der Regel drei(!) SIP-Server mit unterschiedlicher Priorität ausgeliefert. Der Client hat nun die Aufgabe, sich einen auszusuchen und diesen fortan für alle weiteren Aktionen zu nutzen. Ändert sich der Server im DNS-Record muss der Client adäquat darauf reagieren, indem er bei nächster Gelegenheit zum neuen Server wechselt.
Falls ein genutzter Server plötzlich nicht mehr erreichbar sein sollte, muss der Client einen anderen aus der Liste nehmen und fest zu diesem wechseln.
Der Standard dahinter ist IMS / 3GPP.

Keine der oben beschriebenen Anforderungen wird aktuell von Asterisk unterstützt. Asterisk kennt keine Abhängigkeit zwischen Register und weiteren SIP-Aktionen. Bei jeder Aktion wird ein lookup gemacht und das genommen, was da eben gerade aktuell ist - völlig egal, was vor 5 Minuten beim Register war.

Du kannst es nur in soweit von außen etwas stabilisieren, in dem Du im lokalen bind eine RPZ (response policy zone) einrichtest, die Du über einen eigenen Job mit stabilisierten Ergebnissen beschickst bzw. welcher Änderungen erkennt und erst dann einpflegt, wenn Asterisk gerade idle ist und danach einen ReRegister ausführt.

Das alles löst aber nicht die Problematik eines ausgefallenen Servers in der Liste. Da kannst Du nur zusätzlich das Logfile von Asterisk auswerten und auf Basis von Fehlermeldungen den entsprechenden Server aus der RPZ nehmen und danach neu registrieren lassen. Dann musst Du Dir den merken und irgendwann wieder reinnehmen.

Warum das von Dir als Lösung bezeichnete trotzdem scheinbar funktioniert, liegt ausschließlich daran, dass die Telekom einerseits die SIP SRV-Listen an einem DNS nur äußerst selten zu ändern scheint (ich habe hier im Rahmen meiner RPZ-Lösung in einem Jahr bisher nicht eine einzige Änderung mitbekommen - das heißt nicht, dass es bei anderen DNS-Servern der Telekom genauso war - es gibt deren einige) und andererseits die Stabilität der (von mir genutzten) SIP-Server sehr hoch ist (ich habe es seit meiner RPZ-Nummer einmal erlebt, dass ein SIP-Server, der in der Liste war, ausgefallen ist - auch damit kommt Asterisk absolut nicht klar - logischerweise).

 

[Tom-VoIP]

Dann wollen wir mal hoffen, dass Asterisk auch in diesen Punkt weiter entwickelt wird. Und wenn es mit dem aktuellen Server 1 Jahr hält, bin ich schon zufrieden

 

[Tom-VoIP]

Rückmeldung nach über einem halben Jahr (vielleicht interessant für weitere Asterisk User):

Mit den Telekom DNS Servern gab es nicht einen Asterisk Ausfall. Ob es nun daran liegt, dass es keine DNS Änderungen seitens der Telekom gab kann ich nicht sagen.

Fakt bei mir ist: Nutze ich einen externen DNS Server, gibt es alle paar Wochen Probleme, die mich über ein Jahr geärgert haben.
Der externe DNS Server löst tel.t-online.de in 217.0.128.133 auf. Der Telekom DNS Server in 217.0.27.53.