expertenaustausch > comm.* > comm.internet.telefonie

Tim Ritberg (25.11.2018, 12:54)
Hi!

Ich hab hier Asterisk 13.18 direkt auf dem Linuxrouter laufen.
Ich habe immer noch Probleme mit dem DSL-Reconnect nachts. Asterisk
bekrabbelt sich erst Stunden später:

[Nov 25 10:07:22] NOTICE[7164]: chan_sip.c:15876 sip_reg_timeout: --
Registration for '0xxxxxx' timed out, trying again
(Attempt #1088)

Ich habe externhost auf meinen Dyn-Hostnamen gesetzt.
Register steht auf ~480.

Wo muss ich drehen, damit sowas nicht passiert?

Tim
Andreas Hartmann (27.11.2018, 18:19)
On 25.11.18 at 11:54 Tim Ritberg wrote:
> Hi!
> Ich hab hier Asterisk 13.18 direkt auf dem Linuxrouter laufen.
> Ich habe immer noch Probleme mit dem DSL-Reconnect nachts.


Wieso DSL-Reconnects? Was darf ich mir darunter vorstellen? PPoE-Restart? Oder Resync auf
DSL-Leitungsebene? Bei mir läuft v.a. letzteres über Jahre stabil. Und Asterisk ist Teil des
PPPoE-Starts. Erst wenn alles gesichert stabil ist, wird Asterisk reingestartet! Macht vorher eh
keinen Sinn.

> Asterisk
> bekrabbelt sich erst Stunden später:
> [Nov 25 10:07:22] NOTICE[7164]: chan_sip.c:15876 sip_reg_timeout: --
> Registration for '0xxxxxx' timed out, trying again
> (Attempt #1088)


Im Rahmen des PPPoE-Restarts asterisk auch neu starten - und zwar erst dann, wenn DNS-Lookups
funktional sind und alle Paketfiltereinträge erfolgreich durch sind!

Ansonsten: Auf ppp0 mittracen, um zu sehen, was da konkret schief geht und auf der Basis dann
Massnahmen treffen.

Gruß,
Andreas
Tim Ritberg (27.11.2018, 19:25)
Am 27.11.18 um 17:19 schrieb Andreas Hartmann:

> Wieso DSL-Reconnects? Was darf ich mir darunter vorstellen? PPoE-Restart? Oder Resync auf
> DSL-Leitungsebene? Bei mir läuft v.a. letzteres über Jahre stabil. Und Asterisk ist Teil des
> PPPoE-Starts. Erst wenn alles gesichert stabil ist, wird Asterisk reingestartet! Macht vorher eh
> keinen Sinn. PPP-reconnect nach 24 Stunden.


> Im Rahmen des PPPoE-Restarts asterisk auch neu starten - und zwar erst dann, wenn DNS-Lookups
> funktional sind und alle Paketfiltereinträge erfolgreich durch sind!

Versteh ich nicht, kann Asterisk nicht den Teil, den er auch beim Start
macht, bei einem Registry time out machen?

Tim
Marc Haber (27.11.2018, 19:43)
Tim Ritberg <tim> wrote:
>Am 27.11.18 um 17:19 schrieb Andreas Hartmann:
>> Wieso DSL-Reconnects? Was darf ich mir darunter vorstellen? PPoE-Restart? Oder Resync auf
>> DSL-Leitungsebene? Bei mir läuft v.a. letzteres über Jahre stabil. Und Asterisk ist Teil des
>> PPPoE-Starts. Erst wenn alles gesichert stabil ist, wird Asterisk reingestartet! Macht vorher eh
>> keinen Sinn.

>PPP-reconnect nach 24 Stunden.


Vulgo "Zwangstrennung".
Andreas Hartmann (27.11.2018, 20:09)
Am 27.11.18 um 18:25 schrieb Tim Ritberg:
> Am 27.11.18 um 17:19 schrieb Andreas Hartmann:
> PPP-reconnect nach 24 Stunden.
> Versteh ich nicht, kann Asterisk nicht den Teil, den er auch beim Start
> macht, bei einem Registry time out machen?


Hier gibt es zwei Anforderungen:
1. Er muss den grundsätzlichen IP-Wechsel mitbekommen (daran zweifle ich
sehr stark)
2. Er muss die evtl. neuen SIP-Server mitbekommen (je nach Netz, das Du
im Rahmen des PPPoE-Restarts zugewiesen bekommst, bringt teilweise
andere SIP-Server als Ergbnis im DNS-Lookup). Zumindest pjsip kann das
erst ab Version 15.

Wo ist das Problem, Asterisk nach dem PPPoE-Restart durchzustarten? Wie
gesagt, telefonieren ist eh nicht, wenn Du kein Netz hast.
Das Durchstarten selbst dauert vielleicht 1 Minute, bis er wieder alle
Registers hat. Außerdem ist mir auch schon aufgefallen, dass die Server
der Telekom auch ein paar Minuten benötigen, bis sie den Adresschange
alle vollständig mitbekommen haben.

Ich würde dringend dazu raten, Asterisk im Rahmen vom PPPoE-Restart zu
beenden und neu zu starten. Damit meldet er sich auch bei der Telekom
ordentlich ab und die Systeme wissen, dass Du weg bist.

Ist auch ganz einfach:

/etc/ppp/ip-up.local
-> da baust Du den Asterisk start ein

/etc/ppp/ip-down.local
-> da baust Du den Asterisk stop ein

Wobei, ich überlege mir gerade, ob das Down ausgeführt wird, bevor PPPoE
runtergefahren wird - sollte eigentlich. Ist aber nicht so. Daher ist es
am Besten, wenn Du asterisk stopst, bevor Du PPPoE stopst (muss ich hier
auch noch korrigieren).
Warum ist das wichtig? Weil Du es allen Beteiligten einfacher machst,
wenn sich der Telefonieservice vorher ordentlich abmeldet und damit auch
die Telekomsysteme Bescheid wissen.

Starten geht über ip-up.local. Das wird erst aufgerufen, wenn das
ppp-Device steht.

Gruß,
Andreas
Andreas Hartmann (27.11.2018, 20:23)
Am 27.11.18 um 19:09 schrieb Andreas Hartmann:
[..]
> -> da baust Du den Asterisk start ein
> /etc/ppp/ip-down.local
> -> da baust Du den Asterisk stop ein


Falls es sich um eine Zwangstrennung handeln sollte, müssste der
asterisk-stop doch da rein (weil er sonst nie ziehen würde). Oder Du
machst beim Start oben einen asterisk restart (statt nur start).

Andererseits: alle all-ip-Anschlüsse der Telekom haben keine tgl.
Zwangstrennung mehr.
[..]
Tim Ritberg (27.11.2018, 20:49)
Am 27.11.18 um 19:23 schrieb Andreas Hartmann:
> Andererseits: alle all-ip-Anschlüsse der Telekom haben keine tgl.
> Zwangstrennung mehr. Ja das will ich heute nacht ausprobieren.


Tim
Tim Ritberg (27.11.2018, 22:34)
Am 27.11.18 um 19:09 schrieb Andreas Hartmann:

> Hier gibt es zwei Anforderungen:
> 1. Er muss den grundsätzlichen IP-Wechsel mitbekommen (daran zweifle ich
> sehr stark) Wofür ist dann externrefresh?


Tim
Andreas Kohlbach (27.11.2018, 23:24)
On Tue, 27 Nov 2018 17:19:16 +0100, Andreas Hartmann wrote:
> On 25.11.18 at 11:54 Tim Ritberg wrote:
> Wieso DSL-Reconnects? Was darf ich mir darunter vorstellen? PPoE-Restart? Oder Resync auf
> DSL-Leitungsebene? Bei mir läuft v.a. letzteres über Jahre stabil. Und Asterisk ist Teil des
> PPPoE-Starts. Erst wenn alles gesichert stabil ist, wird Asterisk reingestartet! Macht vorher eh
> keinen Sinn.


Gibt es vielleicht noch beim einen oder anderen ISP einen
Zwangs-Reconnect nach 24 Stunden?
Andreas Hartmann (28.11.2018, 10:37)
On 27.11.18 at 21:34 Tim Ritberg wrote:
> Am 27.11.18 um 19:09 schrieb Andreas Hartmann:
>> Hier gibt es zwei Anforderungen:
>> 1. Er muss den grundsätzlichen IP-Wechsel mitbekommen (daran zweifle ich
>> sehr stark)

> Wofür ist dann externrefresh?


Wenn Du Asterisk im NAT-Modus (das müsstest Du zusätzlich tun) betreibst, sorgt das in Verbindung
mit noch zwei weiteren Parametern dafür, dass Asterisk die geänderte externe IP mitbekommt[1].

Du hast hier aber eine grundlegend andere Situation:
- Asterisk läuft auf dem Router mit dem ppp-Device (und damit der Internet-IP - daher ist kein NAT
nötig)

- Beim Beenden des Devices entziehst Du Asterisk ein Netzwerkdevice und nicht nur eine IP! Das ist
mit externrefresh nicht gemeint!

- NAT ist bei Dir nicht nötig / relevant, weil Asterisk über das Device ppp direkt an der
öffentlichen IP hängt (SIP und RTP-Thema).

- Als B2BUA terminiert Asterisk jedes Callleg - d.h., Dein Telefon geht bis zu Asterisk und weiß von
der Aussenwelt nichts und der SIP-Provider von Aussen weiß nichts über deine Telefone intern. Damit
ist Asterisk auch ein SBC.

Was wäre die NAT-Situation? Dein Asterisk wäre auf irgendeiner Maschine, die keine Internet-IP hat
und auf einem Router oder sonstigen geeigneten Device wird NAT gemacht, damit Asterisk Deinen
Provider erreichen kann. Weil Asterisk jedoch für SIP und RTP die externe IP wissen muss, holt er
sich diese über einen Umweg: über dyndns (das Du im Rahmen des ppp-Starts aktivieren musst und das
auch schnell genug propagiert werden muss, dass das alles tickt).

Wie gesagt: Bei Deiner Architektur ist NAT unnötig und auch nicht sinnvoll.

Gruß,
Andreas
Tim Ritberg (28.11.2018, 14:11)
Am 28.11.18 um 09:37 schrieb Andreas Hartmann:
> Wenn Du Asterisk im NAT-Modus (das müsstest Du zusätzlich tun) betreibst, sorgt das in Verbindung
> mit noch zwei weiteren Parametern dafür, dass Asterisk die geänderte externe IP mitbekommt[1]. Ja, aber das Problem mit der IP wäre ja das gleiche.


> Du hast hier aber eine grundlegend andere Situation:
> - Asterisk läuft auf dem Router mit dem ppp-Device (und damit der Internet-IP - daher ist kein NAT
> nötig)
> - Beim Beenden des Devices entziehst Du Asterisk ein Netzwerkdevice und nicht nur eine IP! Das ist
> mit externrefresh nicht gemeint! äh ne?! Asterisk lauscht auf 0.0.0.0.


> - NAT ist bei Dir nicht nötig / relevant, weil Asterisk über das Device ppp direkt an der
> öffentlichen IP hängt (SIP und RTP-Thema). schon klar


> - Als B2BUA terminiert Asterisk jedes Callleg - d.h., Dein Telefon geht bis zu Asterisk und weiß von
> der Aussenwelt nichts und der SIP-Provider von Aussen weiß nichts über deine Telefone intern. Damit
> ist Asterisk auch ein SBC.

Jein. Ich benutzte Asterisk nur als Call-Monitor für meine
Gigaset-Telefone. Die sprechen mit der Telekom direkt.

Tim
Tim Ritberg (28.11.2018, 19:48)
Am 27.11.18 um 19:49 schrieb Tim Ritberg:
> Am 27.11.18 um 19:23 schrieb Andreas Hartmann:
>> Andererseits: alle all-ip-Anschlüsse der Telekom haben keine tgl.
>> Zwangstrennung mehr.

> Ja das will ich heute nacht ausprobieren.
> Tim


Ich habe gerade gesehen, dass sip_reg_timeout auch ohne DSL-Reconnct
kommt :-(

Tim
Thomas Einzel (28.11.2018, 21:26)
Am 28.11.2018 um 18:48 schrieb Tim Ritberg:
> Am 27.11.18 um 19:49 schrieb Tim Ritberg:
> Ich habe gerade gesehen, dass sip_reg_timeout auch ohne DSL-Reconnct
> kommt :-(


Hast du mal andere SIP Provider parallel eingerichtet? Sipgate z.B. gibt
es kostenlos. Ob es ähnliche Effekte, Häufigkeiten oder zeitgleiches
gibt wäre spannend, es muss ja gar nicht an deinem setup liegen.

Ich sehe auch immer mal timeouts (aber kein asterisk), bei Easybell
tritt das das nach meiner Beobachtung etwas häufiger auf. SIP Leitungen
von Telekom und Sipgate laufen hier[tm] z.B. viel stabiler als Easybell
oder eventuell PBX.
Andreas Hartmann (28.11.2018, 23:02)
On 28.11.18 at 18:48 Tim Ritberg wrote:
> Am 27.11.18 um 19:49 schrieb Tim Ritberg:
> Ich habe gerade gesehen, dass sip_reg_timeout auch ohne DSL-Reconnct
> kommt :-(


Ich kann mich noch dunkel daran erinnern, dass ich solche / ähnliche Probleme auch hatte zu der
Zeit, als ich noch chan_sip verwendet habe. Nach Umstellung auf pjsip war da dann final Ruhe im
Karton. pjsip ist sowieso nötig wg. reproduzierbaren Gesprächsabbrüchen nach 15 Minuten (damals) in
Verbindung mit dem einen oder anderen Provider via Telekom.

Um die Timeoutprobleme in den Griff zu bekommen mit chan_sip hatte ich damals noch beim
Registerstring am Ende ein "~480" und bei den Outgoing peer details defaultexpiry=480 gesetzt. Damit
ist es dann, wenn ich mich noch richtig erinnere, ganz ordentlich gelaufen. Ich hatte zu der Zeit
allerdings auch den eth-Treiber ausgetauscht durch einen Treiber vom Hersteller, der erheblich
besser läuft als der Inkernel-Treiber.

Die Telekom verwendet hier als Timeout allerdings 660s (gerade im Trace gesehen). Pjsip bietet bei
mir 3600s im Register an (gemäß Konfig), welche dann die Telekom mit 660s überschreibt.

Mit pjsip (asterisk 13.x - derzeit 13.23) habe ich absolut keine Probleme mehr gehabt mit Telekom
oder auch easybell.

Gruß,
Andreas
Tim Ritberg (28.11.2018, 23:22)
Am 28.11.18 um 22:02 schrieb Andreas Hartmann:

> Ich kann mich noch dunkel daran erinnern, dass ich solche / ähnliche Probleme auch hatte zu der
> Zeit, als ich noch chan_sip verwendet habe. Nach Umstellung auf pjsip war da dann final Ruhe im
> Karton. pjsip ist sowieso nötig wg. reproduzierbaren Gesprächsabbrüchen nach 15 Minuten (damals) in
> Verbindung mit dem einen oder anderen Provider via Telekom.


Ich habs mal gesnifft:


Tim

Ähnliche Themen