[Problem] Asterisk "vergißt" extensions

[ostkind]

Hallo Gemeinde,

verflixt und zugenäht:
ein erfolgreich mit 3-Sip-Nummern der Telekom konfigurierter Asterisk 1.4.22.1 auf einer "Synology Disk Station" vergißt mit zuverlässiger Regelmäßikeit ankommende extensions. an der Konsole äußert sich dies Verhalten mit "core set verbose 3" folgendermaßen:

NOTICE[3944]: chan_sip.c:14383 handle_request_invite: Call from '' to extension 'telekom_1234567' rejected because extension not found.

Ein einfaches "module reload" schafft Abhilfe und alles funktioniert wie als wäre nichts gewesen:

 -- Executing [telekom_1234567@ankommend:1] NoOp("SIP/anonymous.invalid-416125a8", "Incoming call from # anonymous") in new stack
    -- Executing [telekom_1234567@ankommend:2] Goto("SIP/anonymous.invalid-416125a8", "gruppe_1|s|1") in new stack
    -- Goto (gruppe_1,s,1)
    -- Executing [s@gruppe_1:1] NoOp("SIP/anonymous.invalid-416125a8", " ") in new stack
    -- Executing [s@gruppe_1:2] Dial("SIP/anonymous.invalid-416125a8", "SIP/101|10|r") in new stack
    -- Called 101I>
    -- SIP/101-00189cb0 is ringing
  == Spawn extension (gruppe_1, s, 2) exited non-zero on 'SIP/anonymous.invalid-416125a8'

Hat jemand von euch eine Idee worauf das zurückzuführen ist?

Beste Grüße
das ostkind

 

[kombjuder]

Für die Ursache habe ich im Moment auch keine Lösung.

Aber du kannst bis zu einer Lösung einen Cron-Job aufsetzen der dir ein module reload mit der erforderlichen Häufigkeit macht. Dann funktioniert zumindestst deine Dialplan.

 

[ostkind]

Genauso hab ich es auch temporär gelöst: asterisk -rx "module reload" alle 5 Minuten. Unschön, aber effektiv.

Somit werde ich wohl auch zum regelmäßigen Leser der RELEASE NOTES.

 

[rmh]

Spricht etwas dagegen, ein akutelles Release zu verwenden? Seit 1.4.22 (anno 2008) hat sich doch einiges getan.


Gruß
R.

 

[ostkind]

Spricht schon: "Never change a winning team."
Aber da sich die "Win-Situation" durch ein stetes "module reload" eher in einen Dauerschluckauf gewandelt hat, sollte man(n) Tatsache ein Upgrade in Betracht ziehen. Macht es dabei Sinn gleich auf ein 1.8.x Release umzusteigen? Oder eher den Zwischenschritt zur 1.6.x zu wagen?

Gruß,
O.

 

[rmh]

Wenn du den Aufwand in Grenzen halten willst, versuche zunächst die 1.4.42. 1.6.x würde ich überspringen und direkt die nächste LTS-Version 1.8.x verwenden (mich aber vorher mit den Neuerungen vertraut machen).


Gruß
R.

 

[ostkind]

N'Abend die Herrschaften,

bin dem obigen Rat nunmehr gefolgt und den Versuch gestartet "* v1.8.x" an Stelle des "* 1.4.x" an den Start zu bringen. Nach eingehenden Studium der "UPGRADE"-files und Anpassung der "extension.conf" und dergleichen Konfigurationsdateien machen mir leider die Absonderlichkeiten der T-Online Server wirklich Kopfzerbrechen:

Mal davon abgesehen, daß eingehende Anrufe GAR KEINE Aktivität auf der CLI hinterlassen, so musste ich feststellen, daß ein REGISTER im "* 1.8.x" anders aussieht als im "* 1.4.x", denn die Server von T-Online antworten:

 -- Got SIP response 400 "Fehler: Befehl nicht korrekt (SIP Befehl nicht RFC3261-konform) (34)" back from 217.0.16.90:5060

Es-ist-zum-aus-der-Haut-fahren! Auch das hiesige Forum hält zum einen wenig Material dahingehend parat und zum anderen leider auch keine Lösung, denn die vorgeschlagenen Ansätze sind vorab in den Konf.-dateien für den "* 1.4.x" bereits umgesetzt gewesen. Hat jemand einen Rat bevor "tcpdump" und befreundete tools zum Einsatz kommen?

Beste Grüße,
O.

 

[kombjuder]

Such mal gezielt nach Befehl nicht korrekt und t-online. Das ist mir von früher her bekannt, da gab es auch eine Lösung.