Ich bin beim Durchlesen der Release Notes für 19.00 auf folgende Passage gestoßen
Wichtige Hinweise zu dieser BETA Version:
Trunk Failover (Ämterketten) ersatzlos gelöscht. Keine Migration und keine direkte Problemumgehung.
Der Support kann bei Bedarf mit einem ausgehenden Skript helfen.
Wir haben bei uns in der Pascom 18 die verschiedenen Ämter in Ämterketten miteinander verknüpft, um z.B. bei Nutzung aller Leitungen auf ein alternatives Amt umzuschalten, …
Ich denke die Ämterkette ist doch ein recht sinnvolles Feature welches, in welcher Form auch immer, beibehalten werden sollte.
Denke in Zeiten von VoIP hat jeder zumindest einen Internetanschluss, evtl. noch einen zweiten als Fallback/LB. Die VoIP-Provider sind in der Regel redundant und ausfallsicher aufgestellt.
Wenn der Internetzugang also funktioniert sollte auch die Telefonie möglich sein.
Der Schwerpunkt sollte meiner Meinung nach eher auf einen ausfallsicheren Internetzugang gelegt werden. Allerdings habe ich nie mit Callcentern in diesem Bereich zu tun gehabt, wie ist die Lage dort?
das Feature wird relativ selten benutzt und ist ohnehin nur “halbherzig” (bezüglich Rufnummernsignalisierung beipsielsweise) umgesetzt gewesen. Die “meisten” Failovergründe waren das eine Technelogie (Internet/ISDN) nicht mehr zur Verfügung stand und das fällt mittlerweile ja immer mehr weg. Abgehende Kanallimitierung bei SIP Providern ist nicht überall gang und gebe (i.d.R. verdient der Provider hier ja Verbindungsentgeld von seinem Kunden), bei vielen findet das nur eingehend statt.
Wie @rapha schon angeschnitten hat ist ein Redundanter Internetanschluss wesentlich weichtiger als ein zweiter SIP Provider. Wenn es dennoch benötigt wird sollte man das ganze über ein ausgehendes CustomScript “selbststricken” können.
Das Folgende ist nur ein ungetestetes Beispiel daher bitte mit Vorsicht genießen:
Erweitert Scripte ein neues Dialplanscript erstellen, einbinden: ausgehend
Beispielinhalt:
exten => s,1,NoOp(customFailover)
same => n,Set(__SPYGROUP=${MDC_CALLEE_NUM_NAT}:${MDC_CALLER_NUM})
same => n,ExecIf($[ "${MDC_HINT_HANGUP_HANDLER}" != "" ]?Set(CHANNEL(hangup_handler_push)=hdlr-hint,s,1(${MDC_HINT_HANGUP_HANDLER})))
same => n,ExecIf($[ "${MDC_HINT_HANGUP_HANDLER}" != "" ]?Set(DEVICE_STATE(Custom:${MDC_HINT_HANGUP_HANDLER})=INUSE))
same => n,Dial(PJSIP/${MDC_CALLEE_NUM_NAT}@mdc_trunk_conf-{TRUNKID},,tb(mdc_outgoing_predial^s^1))
same => n,GoToIf($[ "${DIALSTATUS}" = "ANSWER" ]?out)
same => n,PlayBack(beep)
same => n,Dial(PJSIP/${MDC_CALLEE_NUM_NAT}@mdc_trunk_conf-{TRUNKID2},,tb(mdc_outgoing_predial^s^1))
same => n,GoToIf($[ "${DIALSTATUS}" = "ANSWER" ]?out)
same => n,PlayBack(beep)
same => n(out),Return()
Wichtig ist hier das man bei dem Dial() den richtigen Trunkkontext setzt, diesen kann man in der /etc/asterisk/mdc_sip_trunk.conf nachsehen. Das ist hier mit {{{TRUNKID}}} gemeint, das wird also durch eine Ziffer erstetzt.
ich sehe das etwas anders. wir haben das im letzten jahr ganz oft implementiert… das problem ist oft nicht eine stabile internetleitung ( wir haben einige kunden mit glas direkt leitungen ) sondern die probleme bei den sip providern. in unserem fall easybell, peoplefone, telekom.
wir monitoren auch alle sip provider und wissen auch wie oft es alleine bei uns zu einem failover kommt… sekunden aussetzte sind alles andere als eine seltenheit. zugegeben die provider haben in den letzten monaten deutlich weniger probleme - aber wer weiß wie lange das so bleibt.
seit wir die failover szenarien konfiguriert haben sind unsere kunden zufriedener.
gefühlt ist nichts so undankbar wie wenn die das telefon nicht geht…
mit den ämterketten haben wir zumindest das problem das sp provider weg bekommen - das schon mal eine ganze reihe an ausfällen abfedert.
Für ein Failover Szenario ist natürlich die peoplefone auch als Backup ideal (z.B. wenn der Kunde nicht von der einem bestimmten Provider weg will). Großer Vorteil ist, dass der SIP TRUNK mit unbegrenzt vielen Sprachkanälen keine monatlichen Kosten hat und der Account mit einem Prepaid Guthaben (das nicht verfällt) genutzt werden kann.
Eine Backup Internetleitung ist leider für ein Backup nicht ausreichend, weil die SIP Verbindung an die fixe IP Adresse gebunden ist (magenta.at), und somit sich mit einer Backup Internetleitung nicht mehr registrieren lässt (falsche öffentliche IP). Deshalb habe wir als Backup eine peoplefone account der für diese Fall genutzt wird und auch z.B. wenn alle Leitungen der Hauptleitung belegt sind.
Hallo @Steve,
beim testweisen Upgrade auf 19.03 ist mir aufgefallen, dass keine ausgehende Regel der Ämterketten übernommen wird. Es wäre wirklich wünschenswert, das z.B. die ausgehenden Regeln auf das erste Amt in der Ämterkette übernommen wird. Ansonsten müsste Ich nun recht umständlich, abschreiben und neu eingeben, alle ausgehenden Regeln neu anlegen, was doch ein recht erheblicher Aufwand wird, da wir nicht nur die Standardregel definiert haben.
ich hab hier mal vorsichtig angefragt, jedoch ist der Aufwand diese zu Übernehmen auch nicht ohne und der Kundenkreis der das Feature nutzt (zumindest vermutet) zu gering. Ggf. finden sich hier noch ein paar Gefolgsleute bei denen wirklich mehr als 2-3 Regeln und/oder einige Instanzen/Anlagen betroffen sind, dann kann ich gerne nochmals darauf hinweisen.
Das obige Skript funktioniert ab Version 19 einwandfrei. Es ist zu beachten, dass manche SIP-Anbieter(z.B. easybell) bei erreichen der maximalen Sprachkanalanzahl eine Ansage schalten, wodurch das Skript so nicht mehr funktioniert, da der Kanal beantwortet wird.
wie komme ich an die Information von der “mdc_sip_trunk.conf”, wenn ich diese auf dem Server nicht finde?
Das Verzeichnis “asterisk” existiert auch nicht in der etc.
Wir betrieben die 19.08R auf unserem Server.
Leider erhalten ich dann.
You lack access to /home/admin/.local/share/lxc
Ich aber bin als admin angemeldet mit dem ich auch das server-management aufrufen kann.
Auch “lxc-info -n …” behauptet, dass es die gesuchte Instanz nicht geben soll.
Ich muss den alten Thread nochmal ausgraben.
Unter der aktuellen Cliudversion funktioniert das Skript zwar, allerdings wird auf dem snom D725 statt des Namen ein “s” angezeigt oder auch manchmal an diesen angehängt.
Es sieht so aus, als würde dieses “s” anstatt der Telefonnummer übermittelt. Welche Variable enthält diese Nummer oder - was mache ich falsch?
ich habe damals (2021) diese Information vom Pascom Support erhalten, habe es aber selbst nie
ausprobiert, da die Anforderung doch nicht benötigt wurde!
"Im Failoverscript be iden Dial() Aufrufen anstelle von
tb(mdc_outgoing_predial^s^1)
Itb(mdc_outgoing_predial^s^1)
verwenden. Durch das große i sollte die Signalisierung hier dann passen."
Danke!