Least Cost Routing komplett!

[elmar69]

Hallo,

mit 1.02 scheint das am CAPI jetzt zu gehen.

Ich hab noch einen weiteren Bug in 'tsblcr.agi' gefunden:

In Zeile 193 fehlen die Klammern im regulären Ausdruck.

$prefix = "/^(" . asterisk_patterns($splitted[0]) . ")/";

gemerkt hab ich das daran, daß bei einigen Nummern unerwartet "preselection" gewählt wurde.

Elmar

[allesOK]

Update ist unterwegs -> danke fuer den Bugreport

[jui]

@Eric

Ich verwende noch den alten Dialplan und habe den umgebaut für Sirrix und Anlagenanschluss und bin dabei auf ein paar kleinere Problemchen gestossen. Wollte fragen ob das bei den neuen Sachen berücksichtigt werden kann bzw. manuell sehr einfach eingepflegt werden kann.

Im alten Dialplan hast Du die Möglichkeit gebpten über 2Z*X gezeilt einen SIP-Provider für den nächsten abgehenden Anruf auszuwählen bzw. anzusprechen. ICh habe z.B. einen Provider in Australien über den ich eine dortige lokale Rufnummer habe. Möchte ich nun über diesen SIP-Provider rauswählen (die Rufnummer die dorthin übergeben wird lautet 617xxxxxx, das Format ist vorgegeben), dann baut mir der alte Dialplan immer noch meine lokale Vorwahl vorne dran, da ich ja nicht mit einer "0" beginne. Allerdings wäre das bei einer gezielten Auswahl des SIP-Providers ja nicht nötig die Rufnummer durch das MAcro numbers alufen zu lassen und ggf. noch durch LCR, sondern er sollte eigentlich direkt über den SIP-Provider rausgehen mit der am Telefon eingegebenen Nummer.

Irgendwie habe ich aber genau da ein Problem das zu realisieren! Vielleicht findet das Berücksichtigung, ich kenne den neuen Dialplan ja noch nicht

Noch eine Sache ... ich hatte auch das Problem, dass ich z.B. von meinem Faxgerät aus IMMER über Festnetz gehen will/muss und NIE über SIP (auch wenn im LCR am günstigsten). Auch das war im alten Dialplan nicht berücksichtigt, dass mein einen User (eben das Fax) gesondert betrachtet und z.B. immer über T-COM oder maximal über 010xx laufen lässt, aber nie über SIP. Auch das wäre klasse wenn es Berücksichtigt werden kann. Dabei ist es natürlich die Frage ob es Sinn macht wenn man mehrere LCR-Profile von TSB für die diversen Nutzer laden muss, ist ja der Serverlast nicht gerade zuträglich aber sicher die einfachste Lösung, alles andere wird im Dialplan sehr komplex.

Gruß,

Jui

[allesOK]

Hallo Jui!

Wenn nich es richtig gesehen habe sind es zwei Dinge:

1) Sip-Provider ohne Numbers-Makro: OK, ich schau mal wie sowas gehen kann
2) Nutzerspezifisches LCR: Ich denke, dass solltest du machen wie oben angerissen. Man koennte zwar ein Flag einbauen, dass das LCR evtl. vorhandene Sip-Routings auslaesst, aber dann landet man sehr schnell bei Preselection. Um die Serverlast niedrig zu halten, koennte man das Fax-LCR ja auch nur einmal am Tag updaten (zum Beispiel).

[jui]

@allesOK

Ja, im Wesentlichen sind es die zwei Punkte, damit man wirklich für jeden SIP-Provider gewappnet ist (jeder hat da evtl andere Eigenarten, ausserdem haben manche ja die Möglichkeit durch Vorwählen von ziffernfolgen auch kostenfrei in PArtnernetze umzusteigen (777 vorneweg und man kommt von einem SIP-Provider in das Netz eines Anderen und der Ruf kostet nichts). Dafür wäre die Option wichtig auch ohne number-Vereinheitlichung gezielt über einen SIP-Provider ausszusteigen. Nebenbei ist man zu ausländischen Providern gleich kompatibel

Das mit dem Fax ist ok so, wenn man benutzerspezifisch ein LCR-Profil verwenden kann, denke alles Andere würde es nur verkomplizieren.

Danke für das schnelle Feedback. Ich bin mit dem alten Dialplan schon ab und zu an meine Grenzen gestossen heute und habe eh noch das Ein oder Andere zu lösen. Aber mit dem lernt man sehr effektiv

Gruß,

Jui

[jui]

Noch ne Anmerkung oder besser ein Feature Request
Was mir fehlt ist ein Dialplan der spontane Amtsholung unterstützt und gleichzeitg aber auch interne Gespräche und internes Vermitteln erlaubt. Nun ist es ja so, dass of z.B. 2-stellige Durchwahlen direkt auf interne Endgeräte gehen und 3 und mehrstellig geht es dann nach extern. Wäre es nicht odeal, interne Gespräche z.B. durch ein vorangestelltes "*" zu kennzeichnen, sodass man mit beliebig vielen Stellen intern arbeiten könnte. Wenn man einen internen Teilnehmer erreichen will (egal ob SIP-Client oder DDI oder MSN), dann stellt man ein * voran und der Ruf bleibt auf den internen Channels, fehlt der * wird immer von einem Anruf nach extern ausgegangen und alles läuft über die numbers oder wie auch immer LCR-Macros.

Mir ist aber noch nicht eingefallen wie man so ne Lösung mit * als Kennzeichnung für interne Rufe vereinfacht in einen Dialplan reinbringt. Aber Eric hat vielleicht eine Idee oder einen Ansatz oder ein Modul das man anfügen kann und das mit seiner neuen Lösung zusammenarbeitet

Wollte diese Wunschvorstellung zumindest mal hier vorstellen, vielleicht wünschen sich auch Andere sowas noch?

Gruß,

Jui

[allesOK]

Hallo Jui!

Also * mit intern kann man machen - ich bin ein Kind der 80er und mag daher die Amtsholung per 0, so wie auf der guten alten TK *g*. Ich kann es ja aber mal auf meine Todo setzen. Bin gerade den neuen Router am installieren. Dann kommt der Dialplan.

[jui]

@Eric

Das wäre ne super Sache mit dem *-(intern) als Alternative zur Amtsholung mit "0". Ich denke es kommt immer auf die Umgebung an wo es Sinn macht. Wird wenig intern telefoniert, dann ist die *-Lösung angenehmer, wird viel intern telefniert ist die 0 zur Amtsholung wohl die geschicktere Lösung. Die 0 it m.E. leichter zu realisieren als die *-Lösung.

Anm. d. R. für alle die das nur überfliegen:
Mit * ist hier nicht Asterisk sondern das Symbol auf der Tastatur gemeint

Gruß,

Jui

[glotzi]

Bei mir klappt es, aber ich werde es nochmal ueberpruefen. Ich baue mal ezu Testzwecken eine Ansage rein, die mir sagt, welchen Provider ich gerade teste.

Gibt's irgendwelche Erkenntnisse wegen dem Fallback?
Mir ist aufgefallen, dass der Fallback von Voip auf Festnetzt geht. Liegt es evtl. daran, dass ich CAPI zum rausklingeln benutze?

[allesOK]

Noch keine Erkenntniss. Hab gestern erst den neuen Server in Betrieb genommen. Jetzt kann ich wieder entwickeln.

Ich schau mir das Makro nochmal genau an. Was steht denn in TSBLCRROUTING?

[MaFL]

@allesOK

Hi Eric,

erstmal vielen Dank für die Mühe die Du Dir gibst!

Ich hab hier mal den LCR mit Capi+Hfc und 2xHFC getestet.
Mit HFC klappt der Fallback, über Capi kommt ein besetzt.
Asterisk mit -vvvc gestartet zeigt keine Zustandsmeldung über das besetzt in der Konsole. Der Plan bekommt also gar nichts davon mit.

Gruß
Matthias

[allesOK]

Ok, scheint also an der CAPI zu liegen. Gibt die evtl. andere DIALSTATUS Werte zurueck?

(Anm.: Bin erst naechste Woche wieder da)

[jui]

@Eric

(Anm.: Bin erst naechste Woche wieder da)

Wahhhhh! Ich harre noch immer aus und mache nix weiter weil ich sehnsüchtigst auf dem neuen Dialplan aufsetzen will und Du verkrümelst Dich einfach mal

Gruß,

Jui

[glotzi]

@allesOK
Ich hab hier mal den LCR mit Capi+Hfc und 2xHFC getestet.
Mit HFC klappt der Fallback, über Capi kommt ein besetzt.
Asterisk mit -vvvc gestartet zeigt keine Zustandsmeldung über das besetzt in der Konsole. Der Plan bekommt also gar nichts davon mit.

Das kann ich inzwischen auch bestätigen. Habe noch eine 2te HFC Karte eingebaut, damit klappt der Fallback.

[allesOK]

Bin beruflich unterwegs ... voip/* ist ja mein grosses Hobby

[elmar69]

Hallo,

ich hab beim chan_capi den Eindruck, daß der Dial-Status nur "BUSY" oder "NO ANSWER" ist, wobei "BUSY" anscheinend beim Gassenbesetzt signalisiert wird. Beim normalen Besetzt wird garkein Dialstatus gesetzt, da das Dial-Komando anscheinend erfolgreich mit dem Capi-Kanal verbindet, der dann das Besetzt signalisiert.

Elmar

[allesOK]

Danke Elmar fuer die Infos ... hmm ist ja nicht so besonders schoen.

[elmar69]

Danke Elmar fuer die Infos ... hmm ist ja nicht so besonders schoen.

Eventuell liegt das Problem auch am "Early-B3" Wählverhalten, das hat zwar den Vorteil, daß der Nutzer Statusmeldungen und Tarifansagen hört, dafür werden sie im Dialplan aber anscheinend nicht bereitgestellt.

Elmar

[Jonny]

Das Problem liegt hier definitiv an chan_capi. Diese signalisiert als DIALSTATUS immer nur NOANSWER. Ich habe den Entwickler mal darauf angesprochen und er sagte mir, dass der chan_capi schon sehr alt sei und das bisher noch nicht aufgefallen wäre.

Ich empfehle eine zweite HFC Karte in den Rechner einzusetzen und mit zaphfc anzusprechen. Dieser Treiber signalisiert alles korrekt. Sogar ein nicht verfügbarer CbC wird als Conguestion signalisiert. Für Fallback einfach genial!
Und early B3 Connect (der immer an ist) funktioniert ebenfalls besser als in chan_capi.

[elmar69]

Das Problem liegt hier definitiv an chan_capi. Diese signalisiert als DIALSTATUS immer nur NOANSWER. Ich habe den Entwickler mal darauf angesprochen und er sagte mir, dass der chan_capi schon sehr alt sei und das bisher noch nicht aufgefallen wäre.

Dan wird das Problem hoffentlich bald beseitigt.

Ich empfehle eine zweite HFC Karte in den Rechner einzusetzen und mit zaphfc anzusprechen.

Leider ist das für mich keine Lösung, da ich hier 3xPTP-ISDN hab und neben der Telefonie auch noch Faxe versenden will - ohne aktive Karten läuft da wohl ehr garnichts.

Elmar