[Problem] Asterisk 22 + Telekom SIP: Eingehende Anrufe kommen nach einigen Gesprächen nicht mehr an. Registrierung laut PJSIP anscheinend unauffällig.

[wediaklup]

Hallo in die Runde,

seit kurzem habe ich einen Glasfaser-300-Vertrag bei der Telekom, der mir auch drei Rufnummern bereitstellt. Nun versuche ich, mich von meinem Asterisk-22-Server, der sich mit der IP-Adresse 10.20.0.100 in meinem Netzwerk befindet, mit Telekom-SIP (tel.t-online.de) zu registrieren (erstmal nur eine Rufnummer). Am Asterisk-Server ist ein analoges Wählscheibentelefon W 49 mittels Cisco VG204XM registriert (PJSIP/51); das funktioniert auch ohne Probleme.

Nun beobachte ich aber Folgendes: Eingehende Anrufe (ich teste mit meinem Mobiltelefon) kommen nach frischer Registrierung mit der Telekom durch und die Tonübertragung klappt in beide Richtungen; so weit, so gut. Nach einer gewissen Zeit (oder nach einer gewissen Zahl Anrufen?) kann ich meine Asterisk-Anlage vom Mobiltelefon aus allerdings nicht mehr erreichen. Ich erhalte bei eingehenden Anrufen überhaupt keine SIP-Requests von der Telekom mehr (weder in den Asterisk-Logs, noch bei Packet Capture sehe ich irgendetwas). Sobald ich mich neu registriere (z. B. via `pjsip send register telekom`), klappen die ersten Telefonate wieder und das Spiel wiederholt sich. Eine konkrete Beobachtung: Ein eingehender Anruf von etwa 2,5 Minuten Länge verläuft normal, ein kurz darauf folgender, kurzer Anruf ebenso, aber der dritte Anruf (vier Minuten nach dem ersten Anruf) scheitert auf beschriebene Weise; eine Neuregistrierung ermöglicht Telefonate wieder vorübergehend. Ich habe schon Telefonate (mit mir selbst) von mehr als sieben Minuten führen können, die auch nicht abbrachen, woraufhin weitere Telefonate ohne Neuregistrierung nicht mehr möglich waren.

Der Output von `pjsip show registrations` ist dabei immer unauffällig; der Trunk wird stehts als „Registered“ gemeldet.

Folgende ist meine pjsip.conf:

Spoiler

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0:5060
local_net=10.20.0.0/16  ; netzwerk, in dem sich dieser server befindet
local_net=192.168.2.0/24  ; netzwerk, in dem sich der cisco vg204xm befindet
external_signaling_address=example.com  ; diese domain zeigt per dyndns auf meine öffentliche ip-adresse
external_media_address=example.com

;================= TELEKOM

[telekom]
type=registration
transport=transport-udp
outbound_auth=telekom-auth
server_uri=sip:tel.t-online.de
client_uri=sip:[email protected]
contact_user=+4930xxx
retry_interval=60
expiration=180
support_path=yes

[telekom-auth]
type=auth
auth_type=userpass
username=+4930xxx
password=dasmoechtetihrwohlgernewissen

[telekom-aor]
type=aor
contact=sip:[email protected]

[telekom-endpoint]
type=endpoint
context=from-telekom
allow=alaw
outbound_auth=telekom-auth
aors=telekom-aor
identify_by=ip
direct_media=no
from_user=+4930xxx
from_domain=tel.t-online.de
rewrite_contact=yes
transport=transport-udp
rtp_symmetric=yes
force_rport=yes

[telekom-identify]
type=identify
endpoint=telekom-endpoint
match=217.0.146.5  ; ip der telekom

;================= TELEFON W 49 (VIA CISCO)

[51]
type=endpoint
transport=transport-udp
context=outgoing
aors=51-aor
allow=alaw
direct_media=no
rtp_symmetric=yes
force_rport=yes

[51-identify]
type=identify
endpoint=51
match=192.168.2.21

[51-aor]
type=aor
contact=sip:[email protected]:5060

Ferner ist der Asterisk dnsmgr aktiviert. In rtp.conf habe ich die RTP-Port-Range auf 10000–10100 eingestellt. Entsprechendes Port-Forwarding scheint unproblematisch zu sein.

So sieht der SIP-Verkehr beim Registrieren aus:

Spoiler

<--- Transmitting SIP request (480 bytes) to UDP:217.0.146.5:5060 --->
REGISTER sip:tel.t-online.de SIP/2.0
Via: SIP/2.0/UDP 91.41.236.142:5060;rport;branch=z9hG4bKPj663a6d10-557a-4735-a5c2-6cc13c625aa0
From: <sip:[email protected]>;tag=9ae7433b-e148-4082-8473-628eed5b4529
To: <sip:[email protected]>
Call-ID: 59768fdb-84d2-43c5-b997-a21866e685a6
CSeq: 25507 REGISTER
Contact: <sip:[email protected]:5060>
Expires: 0
Supported: path
Max-Forwards: 70
User-Agent: Asterisk PBX 22.10.1
Content-Length:  0


<--- Received SIP response (620 bytes) from UDP:217.0.146.5:5060 --->
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 91.41.236.142:5060;received=91.41.236.142;rport=59022;branch=z9hG4bKPj663a6d10-557a-4735-a5c2-6cc13c625aa0
From: <sip:[email protected]>;tag=9ae7433b-e148-4082-8473-628eed5b4529
To: <sip:[email protected]>;tag=mavodi-0-4b-0-3-ffffffc7-85b-ffffffffffffffff-bee00000-6a30505a-_02FCFD6E43E5-1bce-a7602700-1a158a1-6a6646c1-1dfb
Call-ID: 59768fdb-84d2-43c5-b997-a21866e685a6
CSeq: 25507 REGISTER
Reason: SIP;cause=403;text="CC_IMS_OBSOLETE_DEREG"
Session-ID: 00000000000000000000000000000000; remote=5a752d5e8909d35edac8cea0e133f2cd
Content-Length: 0


<--- Transmitting SIP request (598 bytes) to UDP:217.0.146.5:5060 --->
REGISTER sip:tel.t-online.de SIP/2.0
Via: SIP/2.0/UDP 91.41.236.142:5060;rport;branch=z9hG4bKPj1309ab87-ecce-4728-92ea-65f0188dfa48
From: <sip:[email protected]>;tag=6e66f74a-229a-4eef-a3e8-2b0b388f6693
To: <sip:[email protected]>
Call-ID: 724d4a77-165a-411f-8323-11c55916b53a
CSeq: 354 REGISTER
Contact: <sip:[email protected]:5060>
Expires: 1800
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, INFO, REFER
Supported: path
Max-Forwards: 70
User-Agent: Asterisk PBX 22.10.1
Content-Length:  0


<--- Received SIP response (753 bytes) from UDP:217.0.146.5:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 91.41.236.142:5060;received=91.41.236.142;rport=59022;branch=z9hG4bKPj1309ab87-ecce-4728-92ea-65f0188dfa48
WWW-Authenticate: Digest algorithm=MD5,realm="tel.t-online.de",nonce="4e42414e4241aa26b0c3951f5d436a39a1a9a085f55f",qop="auth"
From: <sip:[email protected]>;tag=6e66f74a-229a-4eef-a3e8-2b0b388f6693
To: <sip:[email protected]>;tag=mavodi-0-4b-19-3-ffffffc7-85b-ffffffffffffffff-bf6b0000-6a30505a-_02FCFD6E43E5-1bce-a7602700-1a158be-6a6646c4-e54c6
Call-ID: 724d4a77-165a-411f-8323-11c55916b53a
CSeq: 354 REGISTER
Reason: SIP;cause=401;text="CC_SIP_UNAUTHORIZED_401"
Session-ID: 00000000000000000000000000000000; remote=cf53cae0b3f485c94d07ed737d8c7ddb
Content-Length: 0


<--- Transmitting SIP request (878 bytes) to UDP:217.0.146.5:5060 --->
REGISTER sip:tel.t-online.de SIP/2.0
Via: SIP/2.0/UDP 91.41.236.142:5060;rport;branch=z9hG4bKPj3b74a8ce-0810-499e-afb0-1193b545f73a
From: <sip:[email protected]>;tag=6e66f74a-229a-4eef-a3e8-2b0b388f6693
To: <sip:[email protected]>
Call-ID: 724d4a77-165a-411f-8323-11c55916b53a
CSeq: 355 REGISTER
Contact: <sip:[email protected]:5060>
Expires: 1800
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, INFO, REFER
Supported: path
Max-Forwards: 70
User-Agent: Asterisk PBX 22.10.1
Authorization: Digest username="+4930...", realm="tel.t-online.de", nonce="4e42414e4241aa26b0c3951f5d436a39a1a9a085f55f", uri="sip:tel.t-online.de", response="zensiert", algorithm=MD5, cnonce="8eeea8dc84bd4e7da7244402161e8102", qop=auth, nc=00000001
Content-Length:  0


<--- Received SIP response (1494 bytes) from UDP:217.0.146.5:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 91.41.236.142:5060;received=91.41.236.142;rport=59022;branch=z9hG4bKPj3b74a8ce-0810-499e-afb0-1193b545f73a
From: <sip:[email protected]>;tag=6e66f74a-229a-4eef-a3e8-2b0b388f6693
To: <sip:[email protected]>;tag=mavodi-0-4b-19-3-ffffffc7-85b-ffffffffffffffff-bf6b0000-6a30505a-_02FCFD6E43E5-1bce-a7602700-1a158bf-6a6646c4-f2e2e
Call-ID: 724d4a77-165a-411f-8323-11c55916b53a
CSeq: 355 REGISTER
Contact: <sip:[email protected]:5060>;expires=1800;+sip.instance="<urn:uuid:8918b0fb-b084-3609-ed7e-f8a119f3708d>"
Contact: <sip:[email protected]:5060>;expires=1800;+sip.instance="<urn:uuid:b8869369-8db8-c8af-1e98-88b235cbb490>"
Contact: <sip:[email protected]:5060>;expires=1800;+sip.instance="<urn:uuid:bd40a101-7431-9294-4651-09fc8a755292>"
Contact: <sip:[email protected]:5060>;expires=1800;+sip.instance="<urn:uuid:34c5bb4c-b27c-3d62-6270-1f558a1da407>"
P-Associated-URI: <sip:[email protected]>
P-Associated-URI: <tel:+4930...>
Authentication-Info: nc=00000001,cnonce="8eeea8dc84bd4e7da7244402161e8102",rspauth="4bda766cac55fed978661a6ffa63a171",qop=auth
Reason: SIP;cause=200;text="CC_NO_ERROR"
Session-ID: 00000000000000000000000000000000; remote=cf53cae0b3f485c94d07ed737d8c7ddb
Service-Route: <sip:[email protected]:5060;transport=UDP;lr;mpcftk=0-269-103d-6-ffffffff-226a2034-65672577ecacb-8f4>
Content-Length: 0


sbc*CLI> pjsip show registrations

 <Registration/ServerURI..............................>  <Auth....................>  <Status.......>
==========================================================================================

 telekom/sip:tel.t-online.de                             telekom-auth                Registered        (exp. 1785s)

Objects found: 1

Ich bin ein Laie und kann mir diese Vorkommnisse nicht so recht erklären; der Fakt, dass manche Anrufe funktionieren, sollte ja darauf hindeuten (hoffentlich?), dass die Config zumindest nicht fundamental Käse ist. Kann mir jemand diesbezüglich weiterhelfen? Sollten weitere Informationen gewünscht sein, rücke ich sie gerne raus; ich wollte den Post nur erstmal nicht mit Logs und anderem fluten.

Vielen Dank im Voraus.

 

[sonyKatze]

Router ist? Klingt nach diesem Problem …

 

[wediaklup]

Danke für die Antwort. Router läuft mit pfSense. Dort habe ich per Port Forwarding die Ports 5060 und 10000–10100 freigegeben und an den Asterisk-Server weitergeleitet; dachte eigentlich, das Thema Router wäre damit vom Tisch – wie sehr man sich irren kann.

Zunächst habe ich die UDP State Timeouts in pfSense auf 300 Sekunden hochgeschraubt und es schien länger zu funktionieren als vorher.

Nachdem dann dasselbe Problem wieder auftrat, wechselte ich für die Registrierung zu TCP (der Established-Timeout in meinem Router sind dafür 86400 Sekunden, das wird ja wohl genug sein) und es scheint tatsächlich so, als würde es wie gewollt funktionieren.

Den verlinkten Thread habe ich sogar bereits vor Tagen überflogen, dachte aber wie gesagt, die Passage mit dem NAT Binding beträfe mich nicht... tja. Mal wieder etwas neues gelernt. Ein bisschen peinlich ist es mir schon, eine anscheinend mehr oder minder redundante Frage gestellt zu haben... naja.

Vielen Dank

 

[sonyKatze]

Eigentlich solltest Du gar keine Port-Freigabe machen, denn so kann Dich nicht nur die Telekom sondern quasi das ganze Internet anrufen. Daher besser zusehen, dass die Anwendung = Asterisk aus Deinem Netz heraus den Port offen hält. Falls Du im Router doch Port 5060 aufmachst – und nur der sollte nötig sein – dann hätte auch ich erwartet, dass kein Binding-Timeout geschieht, weil nämlich gar kein Binding erzeugt werden sollte. Hierzu bitte in der Community rund um pfSense fragen, warum dann immer noch ein Binding erzeugt wird. Kann mir nur vorstellen, dass es vielleicht am Quellport liegt, also nicht auf beiden Seiten 5060/5060.

UDP State Timeouts in pfSense auf 300 Sekunden hochgeschraubt

Wenn Du UDP machst, dann kannst Du auf dem Computer mit Asterisk das verlinkte Skript ausführen. Das sollte eigentlich 5060 offen halten. Wobei ich nicht mehr weiß, ob es ich mit Telekom Deutschland getestet hatte.

 

[TomS3]

Hallo wediaklup,

ich habe gerade die gleiche Situation: Telekom LWL-Anschluss, Asterisk per pjsip direkt bei Telekom registriert, ähnlicher Router (opnSense).
Das ganze lief bis Mitte Juli ohne Probleme. Seit dem gibt es Verbindungsprobleme, als ob sich bei der Telekom etwas geändert hat.
Habe keine Portfreigaben an der Firewall. Outbound NAT hat ein statisches Port-Mapping für den Asterisk-Server.
Nach einer gewissen Zeit kommen die SIP-Verbindungen nicht mehr am Asterisk an. Im Firewall-Log sieht man, dass Anfragen von einem Telekom-Server Port 5060 an einen Client-Port bei uns von der Firewall geblockt werden.
Eventuell Load-Balancing bei der Telekom?

Hat noch jemand seit Mitte Juli solche Probleme?
Ich bin am Überlegen ein SIP-Gateway wie Lancom zwischen Asterisk und Telekom zu schalten, damit Ruhe ist mit den Telekom-Anpassungen im Asterisk.

@sonyKatze: wo finde ich das von dir genannte Script zum offenhalten der UDP-Verbindung?

 

[sonyKatze]

wo finde ich das von dir genannte Script zum offenhalten der UDP-Verbindung?

Wenn Du Hyperlinks im Forum nicht als als solche siehst, dann bitte ganz unten rechts hier im Forum einmalig den Style auf „Original“ ändern. Dann müsstest Du in dem anderen Post sowohl den Text und Link unterschieden: „ist das bei UDP auch gar nicht nötig, denn Du kannst bei UDP parallel dafür ein Skript laufen lassen …“

Eventuell Load-Balancing bei der Telekom?

Schau mal, ob Asterisk immer mit dem selben Port rausgeht, also auch 5060. Habe das schon lange nicht mehr angeschaut.

Eventuell Load-Balancing bei der Telekom?

Müsste man an der ankommenden IP-Adresse sehen, also ob die sich ändert. Habe keinen Telekom Anschluss mehr, um das selbst zu testen.

 

[TomS3]

Danke, im IPP-Style sind die links tatsächlich unsichtbar. Mit dem Original-Style sieht man sie. Bisher hab ich rausgehend zufällige Client-Ports am Asterisk, das kann ich aber sicher anpassen. Ich werde das Script bei nächster Gelegenheit mal testen.
Danke für die Hilfe.

 

[sonyKatze]

Wenn Du zufällige Ports hast, dann musst Du auf Ebene von PJSIP das NAT-Binding erneuern. Falls Du unbedingt mit UDP arbeiten willst, dann der Parameter qualify_frequency. Ansonsten mit TCP der Parameter keep_alive_interval. Steht eigentlich alles in dem verlinkten Post. Daher: War das keine Option oder habe ich das zu kryptisch beschrieben oder ‥?