[Gelöst] Retransmission timeout

[James2015]

Hallo,
ich habe folgendes Problem. Ich habe einen kleinen Linuxserver mit Asterisk konfiguriert. Ich gehe ganz normal mit sipgate Daten in das Telefonnetz.
Bis jetzt hat die outbound-Telefonie immer problemlos funktioniert. Seit ca. einer Woche bekomme ich in regelmässigen Abständen immer ein Retransmission timeout als Fehlermeldung.
Das Problem läßt sich irgendwie nie beheben, weil es das Problem kommt und geht ohne dass ich was verändere.
Eine Minute später ist das Problem nicht vorhanden, dann von einer Sekunden zur nächsten kommt die Fehlermeldung.
Wenn ich beispielsweise 10 mal raustelefoniere, immer die gleiche Nummer per Wahlwiederholung funktioniert das manchmal und manchmal nicht.
Liegt das irgendwie an der sip.conf? Mein Server steht ganz normal hinter einem Router, am Router habe ich nichts verändert.
Wieso geht es manchmal und manchmal nicht obwohl ich nichts daran mache?

 

[abw1oim]

Wie ist der Router konfiguriert? Ist TR069 (providerseitige Konfiguration) aktiv? Sind die relevanten Ports (SIP und RTP) an den Asterisk geforwarded oder ist SIP-ALG aktiv?
Das ganze sieht nämlich nach einem NAT-Problem aus.

 

[James2015]

also bis zum heutigen Tag war der Router gar nicht konfiguriert. Weil das Problem früher nie aufgetaucht ist und seit einer Woche immer nur manchmal. Das das irgendwie ein NAT Problem ist, habe ich auch die ganze Zeit befürchtet. Ich habe am Router jetzt SIP:UDP und SIP:TCP von aussen nach innen freigeschaltet. Das testen ist ja mühsam, muss ja den ganzen Tag immer wieder Wahlwiederholungen machen und bin ja nur dann sicher, das Problem gelöst zu haben, wenn das Problem nicht später wieder einfach so auftaucht. In der SIP.conf habe ich jetzt nat=force_report,comedia erst einmal gelassen. Hatte vorher aber auch alles mögliche eingestellt. Mal sehen, ob das Poblem weg ist.

 

[abw1oim]

Wichtig sind in der sip.conf dann allenfalls noch die Einstellungen zu localnet und externip bzw. externhost und externrefresh Alles andere sollte passen ...

 

[James2015]

das Problem ist immer noch,
was muss ich in externip und localhost eintragen.
In localhost steht die IP Adresse des Asteriskserver was bei mir im lokalen Netzt liegt. Muss bei externip die IP-adresse des SIPgate Provider oder meine öffentliche IP des Routers eingetragen werden?
was ist denn externhost und externrefresh?

 

[abw1oim]

Nicht localhost, sondern localnet, also Dein internes Netzwerk.
externip wäre die externe IP des Routers, wenn der denn eine statische IP hat.
Ansonsten hilft externhost (das wäre denn ein extern auflösbarer Domänenname für Deine externe IP-Adresse des Routers, die Du bei einem dyndns-Anbieter hättest). externrefresh sorgt im Zusammenhang mit externhost für die Überprüfung der zugehörigen IP-Adresse im Abstand von x Sekunden.

Alternative Varianten wie Auslesen der externen Router-IP und setzen in sip.conf mit anschließendem sip reload gehen natürlich auch, erfordern aber einigen Aufwand.

Ansonsten kann bei solchen Fehlern auch helfen, einfach mal einen sip debug anzuwerfen und zu schauen, welches Paket in die Retransmission geht ...

 

[James2015]

ja den sipdebug habe ich eingeschaltet. deswegen habe ich auch erfahren, dass es ein retransmissionsfehler ist. durch den debug on bekomme ich eine menge an meldungen zurück, mit denen ich erst einmal nicht so viel anfangen kann, zumal ich nicht weiß, was richtig ist und was nicht richtig ist.
nur die eine Fehlermeldung ist ja rot und deswegen sofort klar:

hier die Meldung:

[Nov 10 12:49:30] WARNING[6318]: chan_sip.c:4024 retrans_pkt: Retransmission timeout reached on transmission [noparse][email protected][/noparse] for seqno 102 (Critical Request) 
-- See [noparse]https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions[/noparse]
Packet timed out after 40174ms with no response
Really destroying SIP dialog '[noparse]4xxw4b2617d64345de3073b61e9b[/noparse]@sipconnect.sipgate.de' Method: INVITE

aber ich habe folgendes (glaube ich zumindestens) festgestellt, wenn der Anruf funktioniert steht auf jedenfall immer

<--- SIP read from UDP:217.10.68.150:5060 --->
SIP/2.0 200 canceling
Via: SIP/2.0/UDP 92.65.214.27:5060;rport=5060;[B][COLOR="#FF0000"]received=MEINE_ROUTER_IP[/COLOR][/B];branch=z9hG4bK77af2aa8
From: "49xxxx" <sip:[email protected]>;tag=as4481065b
To: <sip:[email protected]>;tag=38f019e33a135542ca386fc4eada6cee-edb7
Call-ID: [noparse][email protected][/noparse]
CSeq: 103 CANCEL
Content-Length: 0

und wenn es nicht funktioniert, dann kommt folgendes wobei der Part fehlt was ich oben dick markiert habe

Retransmitting #7 (no NAT) to 217.10.68.150:5060:
REGISTER sip:sipconnect.sipgate.de SIP/2.0
Via: SIP/2.0/UDP 92.65.214.27:5060;branch=z9hG4bK31863d17
Max-Forwards: 70

 

[abw1oim]

Das no NAT ist schon mal schlecht, da sollte NAT stehen. nat=rport,comedia muß im general-Abschnitt der sip.conf stehen.
Das Retransmitting bedeutet aber im Kern, dass das abgesendete Paket (hier: Register) nicht beantwortet wird. Da die Ziel-IP 217.10.68.150 und der Port 5060 für den Provider stimmen und ich jetzt mal unterstelle, dass 92.65.214.27 Deine aktuelle IP ist (das wäre dann eine, die KPN gehört), sieht das aus Paketsicht und damit Asterisk-Sicht gut aus. Dann dürfte der Router der Schuldige sein.
Dort muss in der Konstellation Port 5060 UDP an des Asterisk-Server weitergeleitet sein und ein etwaiges SIP-ALG-Feature muss deaktiviert sein.

 

[James2015]

komischerweise ist die 92.65.214.27 nicht meine IP, diese unterscheidet sich um eine Ziffer, ganz merkwürdig. Ich habe ja eine dynamische.
und was auch merkwürdig ist, dass "Reliably Transmitting (no NAT)" auch steht, wenn der Anruf funktioniert.
Ich habe am Router SIP:UDP an den Asterisk weitergeleitet (obwohl es ja bis vor einer Woche auch ohne diese Einstellungen immer funktioniert hat)
SIP-ALG finde ich an den Routereinstellungen nicht, was ist das denn?

 

[abw1oim]

Wenn SIP-ALG nicht vorhanden ist, brauchst Du Dich darum nicht zu kümmern.
Ok, der VIA-Header kann auch einfach eine interne Netzwerkroute Deines Providers sein, das ist nicht schlimm.

"Reliably Transmitting (no NAT)" ist jedem gesendeten paket vorangestellt, das bedeutet nur, dass etwas übertragen wird, wie gesagt: no NAT sollte bei richtigen NAT-Einstellungen nicht da stehen, sondern NAT.

Wenn der Port 5060 geforwarded ist und der Router keine VoIP-fähige Fritzbox ist, ist jetzt nur noch die Firewall des Routers oder - falls genutzt - des Asterisk (dort typischerweise iptables) relevant. Wenn das Antwortpaket nicht ankommt, sollte eine der beiden das Paket droppen (aus irgendwelchen Gründen). Das müsste dann aber in den entsprechenden Logs stehen (die ggf. erst aktiviert werden müssen).
Eher unwahrscheinlich ist, dass das Paket vom Router nicht richtig an sipgate zugestellt wird. Um dies auszuschliessen, müsste man einen Packet-Trace auf der WAN-Schnittstelle des Routers machen - leider habe ich zuletzt auch mal mit Routing-Problemen in Providernetzwerken zu tun gehabt, die auch zu solchen Effeklten wie beschrieben geführt haben: Mal geht es und mal nicht ...

 

[James2015]

ganz interessant, ich muss ja immer 100mal testen bevor ich einen Eindruck bekommen, ob es weiter funktioniert oder nicht. Wir haben hier einen Router mit zwei WAN Anschlüsse, jetzt habe ich den WAN Anschluss von Kabeldeutschland gekappt und der Router hat jetzt nur noch ein WAN von vodafone aktiv ist. Ich habe in den letzten 20 Minuten bestimmt ca. 30 Anrufe getestet und bisher hat es immer funktioniert. Was nicht heißt, dass es gleich wieder nicht geht. Aber dann weiß ich, dass das Hauptproblem am router liegt.
Entweder kommt er mit zwei WAN nicht zurecht oder am router ist falsch eingestellt worden.

 

[abw1oim]

Ja, dann ist alles klar: Du mußt dafür sorgen, dass der Verkehr über die Ports 5060 UDP und 10.000-20.000 UDP immer über ein und dieselbe Leitung rausgeht.
Sollte das so nicht konfigurierbar sein, kannst Du es auch mit einer IP-basierten Route machen: Aller Verkehr nach 217.10.68.150 über einen dedizierten WAN-Anschluss. Andernfalls bringst Du den Provider aus dem Tritt und die Pakete werden eben auch mal nicht wieder empfangen ...

 

[James2015]

ja das war wohl das Hauptproblem, dass der router mit den zwei WAN Anschlüssen nicht ganz sauber programmiert ist. Obwohl ich ja noch viel an den SIP machen muss, damit alles so einwandfrei funktioniert.
trotzdem danke für die hinweise.