[Gelöst] Tag- Nachtschaltung..

[Tiieto]

Hallo zusammen..

Ich hab mich mal an einer Tag- Nachtschaltung für meine Asterisk Installation versucht..

Allerdings bekomme ich immer ne Fehlermeldung die sich mir nicht erschließen will..

Fehlermeldung
[Jul 30 17:43:15] WARNING[11398]: pbx.c:8717 ast_context_verify_includes: Context 'von-voip-provider' tries to include nonexistent context 'from-extern|07:00-21:00|mon-fri|*|*'

Wenn ich also meine extensions.conf bearbeite, von:

[von-voip-provider]
exten => myNum#1,1,NoOp(${CALLERID(num)} ruft an (${EXTEN}))
same  => n,ExecIf($[${DB_EXISTS(Device/1000)}]?Set(DIALGROUP(main,add)=SIP/1000):NoOp(nothing to do for SIP/1000))
same  => n,ExecIf($[${DB_EXISTS(Device/1001)}]?Set(DIALGROUP(main,add)=SIP/1001):NoOp(nothing to do for SIP/1001))
same  => n,ExecIf($[${DB_EXISTS(Device/1002)}]?Set(DIALGROUP(main,add)=SIP/1002):NoOp(nothing to do for SIP/1002))
same  => n,ExecIf($[${DB_EXISTS(dialgroup/main)}]?Dial(${DIALGROUP(main)}, 30,tT):VoiceMail(3000,u))
same  => n,VoiceMail(3000,u)

exten => myNum#2,1,NoOp(${CALLERID(num)} ruft an (${EXTEN}))
same  => n,ExecIf($[${DB_EXISTS(Device/1000)}]?Dial(SIP/1000,30,tT):VoiceMail(1000,u))
same  => n,VoiceMail(1000,b)                ; = besetzt

exten => myNum#3,1,NoOp(${CALLERID(num)} Faxt an (${EXTEN}))
same  => n,Dial(SIP/2000)                ; an HP_Fax 8500
 
exten => myNum#4,1,NoOp(${CALLERID(num)} ruft an (${EXTEN}))
same  => n,Set(DIALGROUP(Main,add)=SIP/1001)        ; MT1
same  => n,Set(DIALGROUP(Main,add)=SIP/1002)        ; MT2
;same  => n,Set(DIALGROUP(Main,add)=SIP/1003)        ; SIP iPhone
;same  => n,Set(DIALGROUP(Main,add)=SIP/1004)        ; SIP iPhone2
same  => n,Dial(${DIALGROUP(Main)},30,tT)

exten => myNum#5,1,NoOp(${CALLERID(num)} ruft an (${EXTEN}))
same  => n,Set(DIALGROUP(Main,add)=SIP/1001)        ; MT1
same  => n,Set(DIALGROUP(Main,add)=SIP/1002)        ; MT2
;same  => n,Set(DIALGROUP(Main,add)=SIP/1003)        ; SIP iPhone
;same  => n,Set(DIALGROUP(Main,add)=SIP/1004)        ; SIP iPhone2
same  => n,Dial(${DIALGROUP(Main)},30,tT)

exten => myNum#6,1,NoOp(${CALLERID(num)} Faxt an (${EXTEN}))
same  => n,Dial(SIP/2001)                           ; an HP_Fax 7500

nach:

[von-voip-provider]  ; externe Anrufe in Verbindung mit der Uhrzeit verteilen
include => from-extern|07:00-21:00|mon-fri|*|*            ; Tagschaltung unter der Woche
include => from-extern|09:00-22:00|sat-sun|*|*            ; Tagschaltung am Wochenende
include => nacht                        ; Restliche Zeit = Nachtschaltung = direkte Umleitung auf VoiceMail


[from-extern]
exten => myNum#1,1,NoOp(${CALLERID(num)} ruft an (${EXTEN}))
same  => n,ExecIf($[${DB_EXISTS(Device/1000)}]?Set(DIALGROUP(main,add)=SIP/1000):NoOp(nothing to do for SIP/1000))
same  => n,ExecIf($[${DB_EXISTS(Device/1001)}]?Set(DIALGROUP(main,add)=SIP/1001):NoOp(nothing to do for SIP/1001))
same  => n,ExecIf($[${DB_EXISTS(Device/1002)}]?Set(DIALGROUP(main,add)=SIP/1002):NoOp(nothing to do for SIP/1002))
same  => n,ExecIf($[${DB_EXISTS(dialgroup/main)}]?Dial(${DIALGROUP(main)}, 30,tT):VoiceMail(3000,u))
same  => n,VoiceMail(3000,u)

exten => myNum#2,1,NoOp(${CALLERID(num)} ruft an (${EXTEN}))
same  => n,ExecIf($[${DB_EXISTS(Device/1000)}]?Dial(SIP/1000,30,tT):VoiceMail(1000,u))
same  => n,VoiceMail(1000,b)                ; = besetzt

exten => myNum#3,1,NoOp(${CALLERID(num)} Faxt an (${EXTEN}))
same  => n,Dial(SIP/2000)                ; an HP_Fax 8500
 
exten => myNum#4,1,NoOp(${CALLERID(num)} ruft an (${EXTEN}))
same  => n,Set(DIALGROUP(Main,add)=SIP/1001)        ; MT1
same  => n,Set(DIALGROUP(Main,add)=SIP/1002)        ; MT2
;same  => n,Set(DIALGROUP(Main,add)=SIP/1003)        ; SIP iPhone
;same  => n,Set(DIALGROUP(Main,add)=SIP/1004)        ; SIP iPhone2
same  => n,Dial(${DIALGROUP(Main)},30,tT)

exten => myNum#5,1,NoOp(${CALLERID(num)} ruft an (${EXTEN}))
same  => n,Set(DIALGROUP(Main,add)=SIP/1001)        ; MT1
same  => n,Set(DIALGROUP(Main,add)=SIP/1002)        ; MT2
;same  => n,Set(DIALGROUP(Main,add)=SIP/1003)        ; SIP iPhone
;same  => n,Set(DIALGROUP(Main,add)=SIP/1004)        ; SIP iPhone2
same  => n,Dial(${DIALGROUP(Main)},30,tT)

exten => myNum#6,1,NoOp(${CALLERID(num)} Faxt an (${EXTEN}))
same  => n,Dial(SIP/2001)                           ; an HP_Fax 7500


[nacht]
exten => myNum#1,1,NoOp(${CALLERID(num)} ruft an (${EXTEN}))    ; Private Rufnummer
same  => n,VoiceMail(3000,u)

exten => myNum#2,1,NoOp(${CALLERID(num)} ruft an (${EXTEN}))    ; AZ - Rufnummer
same  => n,VoiceMail(1000,u)

;exten => myNum#3,1,NoOp(${CALLERID(num)} ruft an (${EXTEN}))    ; Fax - entfällt in Nachtschaltung
;same  => n,VoiceMail(1000,u)

;exten => myNum#4,1,NoOp(${CALLERID(num)} ruft an (${EXTEN}))    ; Not used
;same  => n,VoiceMail(1000,u)

;exten => myNum#5,1,NoOp(${CALLERID(num)} ruft an (${EXTEN}))    ; Not used
;same  => n,VoiceMail(1000,u)

;exten => myNum#6,1,NoOp(${CALLERID(num)} ruft an (${EXTEN}))    ; 2. Fax - entfällt in Nachtschaltung
;same  => n,VoiceMail(1000,u)

; ############################################# Ende Tag / Nachtschaltung

erscheint obige Fehlermeldung...
Raff ich nicht... Die extension [from-extern] ist doch vorhanden...

Bin ich zu blöd?

 

[koyaanisqatsi]

Moin


Solche Syntax für @sterisk Inkludierungen hab ich ja noch nie gesehen.
...da kann ich dir also nicht weiterhelfen.
Wo hast du das denn her/gelesen/gesehen?

Zeitbedingte Verzweigungen werden mit...

C.67. GotoIfTime()

...gemacht.
Dachte ich bis jetzt zumindest.

 

[Tiieto]

Hier:

3.4. Includes im Dialplan

gehe zu: "Includes Zeitgesteuert"

Evtl auch schon überholt und veraltet... Ist aber meine einzige Quelle diesbezüglich gewesen...

LG

 

[sonyKatze]

Was es nicht alles gibt. Laut der aktuellen Beispiel-Datei nimmst Du als Trenner nicht (mehr) „|“ sondern Kommas. Aber laut Quellcode musst Du nur dann Kommas nehmen, wenn Du auch die Zeitzone angeben willst. Ansonsten geht beides, also vertikale Linie und/oder Komma.

Bin ich zu blöd?

Sieht mir nicht so aus. Könnte ein Software-Bug sein. Weißt Du wie Du mit einem Debugger wie GDB den Quell-Code durch-steppst? Dann könntest Du schauen, ob das Entfernen der „Timings“ vor oder erst nach „ast_context_verify_includes“ geschieht. Die Warn-Meldung ist auf jeden Fall falsch, weil die nur den Kontext-Namen ausgeben dürfte. Hast Du bereits probiert, die beiden Kontexte vorher anzugeben?

 

[Tiieto]

Öhm, nö...
Debugger sowie die Vorgehensweise ist mir nicht geläufig..

Die einzelnen Kontexte der Tag- Nachtschaltung hab ich schon in jeder möglichen Kombination der Positionen im Dialplan durchprobiert... Ohne erfolg... (war meine erste Idee diesbezüglich..)

Ich probier mal die "|" (heißt der nicht "grep"?) durch Kommas zu ersetzen.. Evtl bringt das ja was...

LG

 

[gehtdoch]

Vielleicht hilft Dir es ja weiter, wie FreePBX timeconditions realisiert (im Beispiel von 20:00 Uhr abends bis 06:00 Uhr morgens):

[timeconditions]
include => timeconditions-custom
exten => 1,1,Set(DB(TC/1/INUSESTATE)=INUSE)
exten => 1,n,Set(DB(TC/1/NOT_INUSESTATE)=NOT_INUSE)
exten => 1,n,Noop(TIMENOW: ${STRFTIME(${EPOCH},,%H:%M,%a,%e,%b)})
exten => 1,n,Noop(TIMEMATCHED: ${IFTIME(00:00-06:00,mon-fri,*,*?TRUE:FALSE)})
exten => 1,n,GotoIfTime(00:00-06:00,mon-fri,*,*?truestate)
exten => 1,n,Noop(TIMENOW: ${STRFTIME(${EPOCH},,%H:%M,%a,%e,%b)})
exten => 1,n,Noop(TIMEMATCHED: ${IFTIME(20:00-23:59,mon-fri,*,*?TRUE:FALSE)})
exten => 1,n,GotoIfTime(20:00-23:59,mon-fri,*,*?truestate)
exten => 1,n,Noop(TIMENOW: ${STRFTIME(${EPOCH},,%H:%M,%a,%e,%b)})
exten => 1,n,Noop(TIMEMATCHED: ${IFTIME(*,sat-sun,*,*?TRUE:FALSE)})
exten => 1,n,GotoIfTime(*,sat-sun,*,*?truestate)
exten => 1,n(falsestate),GotoIf($["${DB(TC/1):0:4}" = "true"]?truegoto)
exten => 1,n,ExecIf($["${DB(TC/1)}" = "false"]?Set(DB(TC/1)=))
exten => 1,n(falsegoto),Set(DEVICE_STATE(Custom:TC1)=INUSE)
exten => 1,n,ExecIf($["${DB(TC/1)}" = "false_sticky"]?Set(DEVICE_STATE(Custom:TCSTICKY${ARG1})=INUSE))
exten => 1,n,GotoIf($["${TCRETURN}"!="RETURN"]?from-did-direct,91,1)
exten => 1,n,Set(TCSTATE=false)
exten => 1,n,Set(TCOVERRIDE=${IF($["${DB(TC/1):0:5}" = "false"]?true:false)})
exten => 1,n,Return()
exten => 1,n(truestate),GotoIf($["${DB(TC/1):0:5}" = "false"]?falsegoto)
exten => 1,n,ExecIf($["${DB(TC/1)}" = "true"]?Set(DB(TC/1)=))
exten => 1,n(truegoto),Set(DEVICE_STATE(Custom:TC1)=NOT_INUSE)
exten => 1,n,ExecIf($["${DB(TC/1)}" = "true_sticky"]?Set(DEVICE_STATE(Custom:TCSTICKY${ARG1})=INUSE))
exten => 1,n,GotoIf($["${TCRETURN}"!="RETURN"]?ext-local,vmu91,1)
exten => 1,n,Set(TCSTATE=true)
exten => 1,n,Set(TCOVERRIDE=${IF($["${DB(TC/1):0:4}" = "true"]?true:false)})
exten => 1,n,Return()

 

[Tiieto]

mittels

[von-voip-provider]  ; externe Anrufe in Verbindung mit der Uhrzeit verteilen  *NOTE grep ("|") durch Komma (",") ersetzt
;                       <time range>,<days of week>,<days of month>,<months>[,<timezone>]
include => from-extern, 07:00-21:00,mon-fri,*,*         ; Tagschaltung unter der Woche
include => from-extern, 09:00-22:00,sat-sun,*,*         ; Tagschaltung am Wochenende
include => nacht                        ; Restliche Zeit = Nachtschaltung = direkte Umleitung auf VoiceMail

gibts jetzt zumindest keine Fehlermeldung mehr...
Ma schauen obs auch tatsächlich funktioniert...

<UPDATE> Es scheint tatsächlich zu tun wie gewünscht... </UPDATE>

LG

 

[sonyKatze]

Debugger sowie die Vorgehensweise ist mir nicht geläufig.

OK. Bevor ich das lange erkläre, schaue ich mir das selbst mal an, denn das müsste alternativ auch mit der Vertical-Bar gehen.

1. Welche Asterisk-Version nutzt Du genau?
2. Woher hast Du ein Asterisk (Quell-Code oder ein Repository, welches genau)?

heißt der nicht "grep"?

Wäre mir neu, siehe englische Wikipedia. In diesem Fall wird es als Delimiter genutzt. Heißt aber nicht „Delimiter“, weil es ja zwei Möglichkeiten für den Delimiter gibt. Oben nahm ich den offiziellen Namen aus Unicode. „Pipe“ lese ich noch oft, aber ist hier in diesem Zusammenhang auch nicht richtig, weil es nicht als Pipe genutzt wird.

 

[Tiieto]

zu 1: siehe Signatur
zu 2: Repo (Raspberry Pi Standard Repo)

 

[sonyKatze]

OK. 16.2.1 ist vom Feb. 2019. Meine Meinung dazu … Den 16er-Branch sollte man wirklich erst ab 16.8.0 nutzen. Aber ich schaue mal, ob das in der aktuellen Version noch buggt.

 

[Tiieto]

Macht es denn Sinn auf Asterisk 16.8.x oder sogar auf 18.x auf nem Raspi zu updaten?
Wenn ja gibts da n guideline wie man so ein Update ausführen sollte?

Andere Sache...
Die Beste Tag- & Nachtschaltung ringt ja nix wenn man diese nicht durchbrechen können soll
Also quasi für ausgewählte Anrufer, die die Berechtigung haben auch nach "Geschäftsschluss" anzurufen & auch durchgestellt werden sollen...

Ich denke mal das Cleverste wird sein die Entsprechenden Teilnehmer in der Datenbank zu verewigen und im Nacht Kontext abzugleichen ob die $callerid(num) in der DB "whitelist" hinterlegt ist..
Wenn ja, Anruf auf die Tag- extension umleiten (geht das, oder muss ich das da alles neu schreiben?)
Wenn nein, weiter zur VoiceMail...

Oder gibts da nen Besseren Weg?

LG

 

[koyaanisqatsi]

Ich denke mal das Cleverste wird sein die Entsprechenden Teilnehmer in der Datenbank zu verewigen und im Nacht Kontext abzugleichen ob die $callerid(num) in der DB "whitelist" hinterlegt ist..

Dafür würde mir eine verschachtelte ExecIfTime() und ExecIf() in Kombination vorschweben, anstatt ein bedingtes include für zu nutzen.
...denn darin ( den ExecIf... Funktionen ) lässt sich ja alles bedingt ausführen was es an Funktionen/Applikationen gibt.

 

[Tiieto]

so ähnlich hab ich mir das ausgedacht...

[nacht]
exten => myNum#1,1,NoOp(${CALLERID(num)} ruft an (${EXTEN}))    ; Private Rufnummer
same  => n,ExecIf($[${DB_EXISTS(whitelist/${CALLERID(num)})}]?Dial(${DIALGROUP(main)},30,tT):VoiceMail(3000,b))
same  => n,VoiceMail(3000,u)

in der Asterisk Datenbank eben noch die Einträge eingetippt.

VoiP-Pi*CLI> database show whitelist
/whitelist/ruf#                           : Black_Widow           
/whitelist/ruf#                            : AntMan        
/whitelist/ruf#                           : Spidy           
/whitelist/ruf#                           : Loki        
/whitelist/ruf#                           : Thor              
/whitelist/ruf#                            : Thors Hammer          
/whitelist/ruf#                            : Bifröst          
/whitelist/ruf#                            : Hulk      
/whitelist/ruf#                            : Tony_Stark

Test des ganzen steht jetzt noch aus... <UPDATE> Scheint so zu funktionieren wie gewünscht </UPDATE>
Ist zumindest Fehlerfrei übernommen worden...

 

[sonyKatze]

Macht es denn Sinn auf Asterisk 16.8.x oder sogar auf 18.x auf nem Raspi zu updaten?

Wie in meinem verlinkten Post verlinkt, gibt es dafür mehrere gute Gründe. Wenn Dein Server über das Internet zugänglich ist, „musst“ Du sogar auf die Variante aus dem Repository verzichten, weil es dort keinerlei Security-Fixes gibt.

gibts da n guideline wie man so ein Update ausführen sollte?

Eine Möglichkeit … vorher Asterisk über sudo apt remove … entfernen und davor Konfiguration-Dateien sichern.

 

[Tiieto]

Moin...

- Dein Link "Eine Möglichkeit..." funzt nicht...

Ich denke, wenn ich Asterisk nochmal von Scratch neu auf den Raspi installiere, würde es wohl sinn machen direkt auf Asterisk 18 LTS zu gehen, oder?
Läuft das auf nem Raspi 3B (ohne Plus) oder sollte es evtl direkt ein 4er sein?
Wären die Config Daten vom aktuellen 16er kompatibel mit der 18er?

Wo sind die Unterschiede zwischen den Versionen 13, 16 & 18?
Warum kursieren überhaupt so viele Unterschiedliche Versionen?

LG

 

[KunterBunter]

Dein Link "Eine Möglichkeit..." funzt nicht...

Du konntest den Post 2426472 nicht finden?

 

[Tiieto]

Du konntest den Post 2426472 nicht finden?

Das hab ich nicht gesagt...
Ich sagte nur das der gepostete Link nicht das tut was er sollte...

 

[sonyKatze]

Dein Link "Eine Möglichkeit..." funzt nicht.

Repariert.

Macht es sinn, direkt auf Asterisk 18 LTS zu gehen?

Ich würde erstmal auf die neuste Asterisk 16 LTS gehen. Dann ein wenig spielen und ausprobieren. Und dann auf Asterisk 18 LTS.

Wo sind die Unterschiede zwischen den Versionen 13, 16 & 18?

Das siehst Du hier …

Warum kursieren überhaupt so viele Unterschiedliche Versionen?

Die Antwort ist gar nicht so einfach.

Asterisk fährt mehrere Branches. Das bedeutet, dass neue Feature nur in Master aufgenommen werden. Und dann wird etwa alle zwei Jahre vom Master-Branch ein neuer LTS-Branch gebildet. Ab dann gibt es nur noch Bug-Fixes und Security-Fixes. Dadurch können die vielen Telefonie-Anbieter langsam und mit Vorbereitung auf die neuste Version migrieren ohne Sicherheitslecks zu fürchten. Wirklich funktionieren tut das übrigens alles nicht. Selbst heute findet man immer noch Software-Bugs, die mit Asterisk 11 eingeführt wurden – dicke Dinger, die durch einfaches Copy-and-Paste geschehen sind. Viele Nutzer sind mit Asterisk 11 verloren gegangen und testen deswegen die neueren Branches nicht mehr.

In den Repositories der Linux-Distributionen kommt dann die aktuelle Version des aktuellen LTS-Branch. Aber weil diese Packages nicht in „Security“ sind, bekommen die keine Security-Patches. Warum die Maintainer dieser Packages nicht wenigstens die Certified-Asterisk-Branches nehmen, die wirklich nur bei Security-Updates aktualisiert werden … verstehe auch ich nicht.

Für uns Normalos, uns Privat-Heimanwender ist es das Beste immer auf dem neusten Branch zu sein, also sogar nicht-LTS-Branches mitzumachen. In ein paar Monaten wird das Asterisk 19 sein. Wenn Du einen Fehler findest, kannst Du so den schnell melden. Ist Fehler-melden nicht so Dein Ding, gehst Du auf den letzten LTS-Branch. Aktuell ist das Asterisk 18 LTS. Findest Du einen vermeintlichen Fehler, gehst Du dann auf einem Test-System auf den letzten Branch. Ist Fehler-melden so überhaupt nicht Dein Ding, gehst Du auf den letzten LTS-Branch von dem bereits zwei Certified-Asterisk abgespalten worden sind. Aktuell ist das Asterisk 16 LTS. Wenn Dich neue Funktionen nicht interessieren, könntest Du auch auf den Certified-Asterisk gehen. Aber dann musst Du genau schauen, welche Version von Debian kompatibel ist; oft ist die allerneuste Debian- bzw. Ubuntu-Version nicht kompatibel zu Certified-Asterisk.

 

[gehtdoch]

So ganz nachvollziehen kann ich diverse Aussagen von Dir nicht, sonyKatze, die Du oben getätigt hast. Die LTS-Branches von Asterisk erfahren sehr wohl Sicherheitsupdates - das ist ja einer der Hauptzwecke, warum diese eingerichtet wurden. Selbst kleinere neue Features sind enthalten - wie z.B. hier. Die x.y.z-Releases sind üblicherweise reine Security-Fixes.
Dass in einer SW ständig neue security Bugs gefunden werden, ist ja nun absolut nichts besonderes. Ich kann Deine Argumentation an dieser Stelle auch nicht nachvollziehen. Dabei ist völlig irrelevant, wie sie am Ende des Tages reingekommen sind. Der Unterschied zur closed source SW ist eben, dass man es bei OSS einfach nachvollziehen kann.

Man muss einfach verstehen und akzeptieren, das hinter Asterisk eine Firma steht, die die MA stellt (und bezahlt) und fast alles macht (derzeit Sangoma). Diese Firma hat ein klares Ziel: Enterprise-Kunden (überwiegend jenseits des Atlantiks), die auch bezahlen (ja, die MA von Sangoma wollen auch leben). Daraus ergibt sich automatisch die Entwicklungsrichtung und alle weiteren Grundlagen / Bedingungen:
Zielplattform ist nach wie vor (und auch bis auf Weiteres) CentOS 7 auf x86_64. Alles andere ist nicht supported. Die offiziellen Binaries bzw. Sourcecode (und damit auch getestet) kommen von Sangoma. Das heißt nicht (zwingend), dass es auf anderen Plattformen nicht läuft - aber es ist eben Zufall und wenn man da auf Probleme stößt, ist man eben logischerweise meistens auch auf sich selbst gestellt.
Bugreports in diesem Zusammenhang werden dann bearbeitet, wenn sie zufällig trotzdem in das Konzept von Sangoma passen - ansonsten eben nicht.

Der use case Endanwender, wie die meisten hier, ist kein (primäres) Ziel von Sangoma - das ist nur Abfallprodukt. Wenn es funktioniert ist es gut - ansonsten eben nicht - musst Du selbst in Griff bekommen. Daher kommt es auch, dass ich oder auch sonyKatze z.B. mehr oder weniger viele eigene Patches haben (die dann eben teilweise auch VoIP-Provider abhängig sind), um eben diesem grundsätzlich anderen use case gerecht zu werden. Ist eben so.

Das ist genau der Grund, warum ich die LTS-Versionen bevorzuge: weil ich da eher selten Patches anpassen muss, weil sie eben doch weitestgehend stabil sind.
Von irgendwelchen nicht Sangoma-Quellen würde ich sowieso grundsätzlich und vollständig die Finger lassen. weil man nicht zwangsweise davon ausgehen kann, dass alle jeweiligen Repositorymaintainer das nötige know how haben, dass sie wirklich verstehen, was sie da treiben. Außerdem würde ich grundsätzlich bei der original Zielplattform von Sangoma bleiben. Am besten mit FreePBX starten. Aber das kann natürlich jeder halten, wie er will. Ihm muss nur klar sein: je weiter er sich vom Standard wegbewegt, um so mehr muss er selber machen und um so noch mal viel mehr know how muss er insgesamt mitbringen. Diese Anforderung werden die allerwenigsten (zumindest von denen, die hier so aufschlagen) auch nur ansatzweise erfüllen aus meiner Sicht, wenn man hier im Forum die Fragen so sieht und wie wenig Ahnung oft vorhanden ist, wie man VoIP Probleme analysiert, um an die Ursachen der Probleme heranzukommen, um sie damit abstellen zu können.

 

[sonyKatze]

Die LTS-Branches von Asterisk erfahren sehr wohl Sicherheitsupdates …

Probiere meinen Post einfach nochmal zu lesen: Alle Branches, die noch aktiv sind, erhalten Security-Fixes. Aber die Debian-basierten Linux erhalten in „ihrem“ Repository einmal eine Version und diese erhält (aktuell) dann keine Security-Updates mehr, weil Asterisk dort nicht im entsprechenden Repository-Bereich ist.

das ist nur Abfallprodukt

Ja, das ist eine Einschätzung von Dir, ein „Excuse“ für die Machenschaften bei Sagoma. Eine Plattform lebt auch von Nutzern. Und wenn Sangoma nicht-funktionalen Anforderungen auf Hobbisten ablädt, dann muss man sich irgendwann nicht mehr wundern, wenn es keiner nutz. Und das ist die Crux bei Digium zum Schluss gewesen, dass bei jedem neuen Branch ganz viele Nutzer (Privat aber besonders auch Professionell) verloren gehen. Diese Verlorenengegangen testen dann die nicht-LTS-Branches nicht vor, in einem Testbed. Und dann können auch deren neuen Features nur mit wahnsinnig viel Aufwand im Master-Branch zusammengebracht werden. Ein anderes Problem sind Nachrenner – zu denen gehöre ich –, die auf einem alten Branch hängen, einen Software-Bug finden, und dann auf allen neueren Branches diesen Bug-Fix einpflegen müssen (inklusive testen). Oder anders formuliert: Ich als Nutzer, Hobbist, muss (auch) alle (anderen) Branches bedienen, um meine Änderungen reinzubekommen. Warum sollte man das nach Deiner Einschätzung überhaupt machen?

weil man nicht zwangsweise davon ausgehen kann, dass alle jeweiligen Repositorymaintainer das nötige know how haben, dass sie wirklich verstehen, was sie da treiben

Das ist der nächste Witz an Digium. Diese Maintainer finden reihenweise interessante Punkte, von denen man lernen könnte. Aber Digium macht sich keine erkenntliche Mühe, dieses Wissen zurück in Haupt-Projekt zu transferieren. Und schon wieder gehen Plattformen und damit Nutzer verloren. Ich persönlich hätte nichts dagegen, wenn sich Digium auf eine Plattform versteifen würde. Aber auch das geschieht nicht, jedenfalls kann ich nicht erkennen, dass das ehemalige Digium-Team dieses RHEL/CentOS als „the platform“ ansieht.