Neue Version von chan_capi_0_5_3_cm

[Tucca]

Armin Schindler hat eine neue Version von chan capi 0.5.3-cm online gestellt:

https://sourceforge.net/project/showfiles.php?group_id=140312&release_id=338368

Release Note:
Fix for B3q handling, based on original sync handling of voice data. Fixed support for CVS-HEAD of Asterisk.

Gruss,
Tucca

 

[Netview]

Und es sieht fast so aus als würde diese capi nur mit asterisk cvs-head richtig laufen - leider :-(

 

[chaos2000]

Und es sieht fast so aus als würde diese capi nur mit asterisk cvs-head richtig laufen - leider :-(

habe es heute morgen auch auf die 1.0.8 aufgespiel und ein paar mal telefoniert - bisher keine Probleme

 

[Netview]

Hi!

Läuft die 0.5.3 jetzt stabil oder gibt es noch Ausfälle des Audiochannels bzw. asterisk-Abstürze?

Welche asterisk-Version ist bei euch im Einsatz head/stabil/tarball?

 

[Hupe]

Benutze die Version jetzt zwei Tage. Bisher keine Ausfälle.

 

[sgofferj]

Hier auch. Seit Releasedatum im harten Test - einwandfrei bisher.

 

[jtsn]

Auf einem bristuff 0.2.0-RC8a mit Florz-Patches gibt es kein vernünftiges Indication-Handling.

ALERT wird zu früh signalisiert:
Der Anrufer hört also schon ein Freizeichen, obwohl Asterisk noch nach der passenden Extension sucht. Es klingelt also selbst wenn für die MSN überhaupt keine Extension existiert (incomingmsn=*)

Busy und Congestion können nur in der Phase RINGING abgesetzt werden, nicht jedoch davor.

Es sollte genau dann ein Freizeichen zu hören sein, wenn ein Endgerät klingelt oder man dieses mit Ringing anfordert.

Ich habe mir mit folgendem Quick-Hack geholfen:

--- chan_capi.c.orig    2005-06-28 22:02:14.000000000 +0200
+++ chan_capi.c 2005-07-03 14:51:06.000000000 +0200
@@ -1135,28 +1135,25 @@
        case AST_CONTROL_RINGING:
                cc_ast_verbose(3, 1, VERBOSE_PREFIX_2 "Requested RINGING-Indication for %s\n",
                        c->name);
+               capi_alert(c);
                break;
        case AST_CONTROL_BUSY:
                cc_ast_verbose(3, 1, VERBOSE_PREFIX_2 "Requested BUSY-Indication for %s\n",
                        c->name);
-               if (c->_state == AST_STATE_RING) {
                        CONNECT_RESP_HEADER(&CMSG, ast_capi_ApplID, i->MessageNumber, 0);
                        CONNECT_RESP_PLCI(&CMSG) = i->PLCI;
                        CONNECT_RESP_REJECT(&CMSG) = 3;
                        _capi_put_cmsg(&CMSG);
                        ret = 0;
-               }
                break;
        case AST_CONTROL_CONGESTION:
                cc_ast_verbose(3, 1, VERBOSE_PREFIX_2 "Requested CONGESTION-Indication for %s\n",
                        c->name);
-               if (c->_state == AST_STATE_RING) {
                        CONNECT_RESP_HEADER(&CMSG, ast_capi_ApplID, i->MessageNumber, 0);
                        CONNECT_RESP_PLCI(&CMSG) = i->PLCI;
                        CONNECT_RESP_REJECT(&CMSG) = 4;
                        _capi_put_cmsg(&CMSG);
                        ret = 0;
-               }
                break;
        case AST_CONTROL_PROGRESS:
                cc_ast_verbose(3, 1, VERBOSE_PREFIX_2 "Requested PROGRESS-Indication for %s\n",
@@ -1307,9 +1304,6 @@
        ast_mutex_unlock(&usecnt_lock);
        ast_update_use_count();
        if (state != AST_STATE_DOWN) {
-               /* we are alerting (phones ringing) */
-               if (state == AST_STATE_RING)
-                       capi_alert(tmp);
                if (ast_pbx_start(tmp)) {
                        ast_log(LOG_ERROR, "Unable to start pbx on channel!\n");
                        ast_hangup(tmp);

extensions.conf:

[isdn-incoming]
exten => 1234567,1,Goto(zap,1)

exten => zap,1,Dial(Zap/g1/11,120)
exten => zap,2,Congestion
exten => zap,102,Busy

Ein eingehender Anruf geht auf die Extension 1234567 (beispielhaft für die MSN) und wählt anschließend via chan_zap das Endgerät mit der Nummer 11 an. Ist dieses Endgerät frei, klingelt es und signalisiert ALERTING über den D-Kanal zurück, was chan_zap an Asterisk zurückmeldet (RINGING); der reicht es dann automatisch an chan_capi weiter. Neu ist jetzt: chan_capi wiederum schickt eine ALERTING-Nachricht über den D-Kanal des ISDN-Anschlusses und signalisiert damit dem Anrufer das Freizeichen. Vorher tat es in dem Falle einfach nichts.

Meldet das Endgerät BUSY zurück, wird Busy ausgeführt (in allen anderen Fällen Congestion). Da in diesem Falle Asterisk noch nicht in der Phase RINGING ist, würde dies einfach verworfen werden, das habe ich auch geändert.

Gleichzeitig habe ich die Funktion entfernt, die chan_capi veranlaßt, das Freizeichen völlig unabhängig vom Asterisk für jeden eingehenden Anruf zu signalisieren, da das jetzt an der richtigen Stelle passiert.

ciao, jtsn

 

[sgofferj]

Das ist ein bekanntes Problem, was ich seinerzeit schon KPJ reported habe und was auch in der Bugliste für chan_capi-cm drinsteht.
Funktioniert Dein Patch einwandfrei? Ich hatte mich auch schon am Geradebiegen der Indications versucht aber dabei hat mir die * immer mal wieder die Grätsche gemacht. Bin halt kein Programmierer .
Wenn Dein Patch funktioniert, schicke ihn doch an Armin.

Viele Grüße,
Stefan

 

[sgofferj]

Der patch failed bei mir. Könntest Du den evtl. als Attachment posten?
C&P ist bei diffs immer so eine Sache...

Danke,
Stefan

 

[Netview]

Hi!

Nun ich habe jetzt die 0.5.3 auch mal wieder in Betrieb genommen. Folgendes Problem (ist reported) stellt sich jedoch bei mir ein:

SetCallerID= must have an numerical value?!

If SetCallerID= is undefined or set to an alpha-numeric
string
like "anonymous" the capi will not work!

exten => s,1,SetCallerID(0) ; this is working
;exten => s,1,SetCallerID(anonymous) ; this is not working
exten => s,2,SetCallerPres(allowed)
exten => s,3,SetCIDNum(34) ; outgoing MSN
exten => s,4,Dial(Capi/contr1/b${ARG3}${EXTENF:${ARG6}},,)

Ich setze (bin bei 1&1) die Variable SetCallerID auf "anonymous" sofern ich vor der Nummer ein "##" stelle. Dies funktioniert auch einwandfrei. Wähle ich nun über die capi raus ist SetCallerID=anonymous und SetCallerPres(prohib) und die capi stört sich daran, dass SetCallerID keinen numerischen Inhalt hat!

Kann das jemand bestätigen?
Ich finde das ist ein bug - oder?

 

[jtsn]

Das ist ein bekanntes Problem, was ich seinerzeit schon KPJ reported habe und was auch in der Bugliste für chan_capi-cm drinsteht.

Schon gesehen.

Funktioniert Dein Patch einwandfrei? Ich hatte mich auch schon am Geradebiegen der Indications versucht aber dabei hat mir die * immer mal wieder die Grätsche gemacht. Bin halt kein Programmierer .

Das ganze Indication-Handling gehört gründlich überarbeitet. Das macht man natürlich nicht mal eben in 10 min. Der Code ist ziemlich unübersichtlich.

Wenn Dein Patch funktioniert, schicke ihn doch an Armin.

Es ist wie gesagt ein Hack, der hier bei mir funktioniert, Garantien gibt's darauf keine und für Produktivumgebungen empfehle ich ihn auch nicht.

Gerade hab ich noch einen Bug gefunden:
Eingehender Anruf:

*CLI> show channel CAPI/contr1/1234567-10
           Name: CAPI/contr1/1234567-10
           Type: CAPI
       UniqueID: asterisk-1753-1120404911.16
      Caller ID:
    DNID Digits: (N/A)
          State: Ring (4)
          Rings: 1
   NativeFormat: 8
    WriteFormat: 64
     ReadFormat: 8

Hier steht der Codec für WriteFormat seltsamerweise auf 64 (Signed Linear) statt 8 (a-Law). Ruft man jetzt eine Application wie Echo auf, steigt er auch prompt aus (mein Patch spielt dabei keine Rolle):

ERROR[2250]: chan_capi.c:1049 capi_write: dont know how to write subclass 64

Logisch, ein ISDN-B-Kanal kann auch nichts mit 16-Bit-Signed-Linear-PCM anfangen. Eigentlich müßte Asterisk das automatisch nach a-Law konvertieren, tut er aber nicht.

ciao, jtsn

 

[jkon]

Der Patch funktioniert bei mir nicht.
Ich habe heute mal länger die chan_capi betrachtet aber habe ums verrecken kein Besetzt signalisiert bekommen.
Was für eine ISDN Karte benutzt Du denn und welchen Kernel und welches Linux läuft bei Dir?

 

[Hupe]

Also, mit capi und einem Kernel > 2.6.10 gab es sowieso schon Probleme. Könnte es vielleicht daran liegen (eventuell die Suchfunktion benutzen!)?

 

[jkon]

Ja, da gab es schon diverse Patche, eingige von diesen habe ich auch angewandt.
Bei mir funktioniert sonst auch alles, nur Busy (vielleicht auch Congestion, das habe ich nicht ausprobiert) wird nicht richtig signalisiert.
Und alle Patche die Busy zum Thema haben, waren bei mir nicht erfolgreich.

 

[jkon]

Inzwischen habe ich das Problem geklärt. Es liegt doch nicht an chan-capi, sondern an
ptmp und daran das ich zwei Geräte am S0 Bus hängen habe. ISDN ptmp ist da wohl systembedingt nicht in der Lage 'busy' korrekt zu signalisieren.
Wenn ich das zweite Gerät vom S0 Bus entferne wird auch bei mit 'busy' korrekt signalisiert!

 

[sgofferj]

Das ist nicht "systembedingt". Der Ablauf ist folgendermaßen:

VSt schickt ALERT an den Bus.
Das Gerät, welches sich von der MSN angesprochen fühlt, schreit "HIER, ICH" und schickt entweder RINGING oder BUSY oder REJECT oder ... zurück.
Hast Du mehr als ein Gerät dran, das sich angesprochen fühlt, läuft der Call solange, bis entweder alle negativ signalisiert haben oder ein Timeout auftritt.
Um das zu umgehen, gibt es drei Möglichkeiten:
1. zweites Gerät abstöpsele
2. zweitem Gerät sagen, daß es die fragliche MSN ignorieren soll
3. Leistungsmerkmal Busy on Busy - Wenn EIN Gerät BUSY zurücksignalisiert, bekommt der Anrufer auch ein BUSY

Viele Grüße,
Stefan

 

[Netview]

chan_capi-cm.0.5.4 ist raus!

Änderungsliste:
- fixed 'group' setting according to Asterisk defaults.
- use SetCallerPres(prohib_not_screened) instead of CallingPres(32) for CLIR.
- full CallingPres support added.
- use mutex when debug/verbose messages are printed.
- set dnid on incoming call.
- catch errors in wrong dialstring.
- set correct DIALSTATUS and HANGUPCAUSE.
- set PROGRESS and PROCEEDING when the network signals them.
- increased voice send buffer a little bit.
- fixed seg-fault when unallocated number was dialed.

 

[Netview]

Ich hatte eben einen seg-fault als mich jemand über eine Analogleitung anrief (Nummer war unterdrückt) und asterisk stürzte ab!
Hat sonst noch jemand Probleme mit der 0.5.4?

 

[Hupe]

Hatte (zum Glück) noch keine Zeit das zu installieren. Naja, bei 0.5.4 sind ja ne menge neuer Sachen dring. Da tuen sich irgendwie parallelen zur 0.5.2 auf. Die führte bei mir auch zu häufigen Abstürzen von Asterisk. Und dann kam ja auch schnell die nächste Version, wo das Problem wohl gefixt wurde.
Mal sehen, wann die 0.5.5 rauskommt

 

[thorsten.gehrig]

Hi
@jkon: die Problematik dass "busy" nicht richtig signalsiert wurde - war meintest du damit "busy" bei ankommenden gesürächen - oder busy bei abgehenden gesprächen - also wenn die gegenstelle besetzt ist.

Ich habe nämlich auch ptmp und den chan_capi 3.5 mit backport - aber leider funktioniert zumindest gassenbesetzt nicht :-(
und da ich LCR einsetze ist das sehr ärgerlich - wenns gehen würde könnte ich wenigstens x-mal automatische wahlwiederholung machen und dann auf den zweitteuersten anbieter gehen... (die 01035 ist wirklich sch... verfügbar).

Gruß
Thorsten Gehrig