ECT, HOLD und RETRIEVE

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
N

norden

Neuer User
Mitglied seit
2 Nov 2004
Beiträge
62
Punkte für Reaktionen
0
Punkte
0
Hallo!

Ich versuche gerade mit chan_capi-cm-0.5.4 die oben genannten Funktionen zu nutzen. Mit dem alten chan_capi-0.3.5 funktionierten bei mir zumindest HOLD und ECT. Nun funktioniert zwar noch HOLD, aber bei ECT bekomme ich immer die Fehlermeldung
" WARNING[17615]: chan_capi.c:777 capi_call: Destination 12 requres a real destination"
und das Gespräch bleibt auf HOLD. Die 12 ist die Nummer meiner Nebenstelle der TK-Anlage, an der auch die Fritzcard hängt. Wie gesagt, mit chan_capi-0.3.5 lief's. Oder liegt's an meiner Asterisk-CVS-Version?

Gruß,
Ingmar
 
Im neuen chan_capi-cm (aktuelles CVS) ueberarbeite ich zur Zeit diese Applikationen. Ausser ECT sind bereits alle zusaetzlichen capi-apps in chan_capi eingebaut und werden durch capicommand(),
also z.B.:

exten => s,1,capicommand(HOLD)

benutzt.

HOLD und RETRIEVE funktionieren, aber ECT wollte ich am Wochenende fertig machen.

Eventuelle kannst Du das mal testen?

Armin
 
Danke für deinen Tipp! Mit dem aktuellen CVS funktionieren HOLD und RETRIEVE. ECT würde ich auch gerne testen, wenn's soweit ist. *Vorfreude*

Bisher habe ich zum Testen den folgenden Kontext benutzt:
[halten]
exten => 992,1,capicommand(HOLD)
exten => 992,2,SayDigits(000)
exten => 992,3,capicommand(RETRIEVE)
exten => t,1,Dial(Local/500@ingmar_ext,30,)

Der macht zwar noch nicht so viel Sinn, aber zeigt, dass HOLD und RETRIEVE im Prinzip funktionieren.

Nun möchte ich gerne zwischendurch auflegen und dann das Gespräch wieder zurückholen. Da hatte ich folgendes versucht:

[halten]
exten => 992,1,capicommand(HOLD)

[holen]
exten => 993,1,capicommand(RETRIEVE)

Dann bekomme ich aber leider beim wählen von 993 die Meldung:
-- Executing capiCommand("SIP/ingmar1-922d", "RETRIEVE") in new stack
Aug 18 13:03:17 WARNING[21111]: chan_capi.c:3181 capicommand_exec: capiCommand works on CAPI channels only, check your extensions.conf!

Wie bringe ich meinem * bei, dass ich das Gespräch vom Capi zurückholen möchte? Kann ich irgendwie manuell einen Capi-Channel aufbauen (ohne über Dial zu wählen)? Irgendwie stehe ich da gerade auf dem Schlauch...
 
Auf dieses Problem bin ich auch schon gestossen. So gut kenne ich aber Asterisk noch nicht um alle Möglichkeiten 'auszureizen'.
Ich habe bisher noch nichts gefunden, wie man mit channels agiert, die gerade nicht 'aktuell' sind.
Falls das ueberhaupt mit Asterisk geht, bzw. so gedacht ist.

Ein Idee waere, wenn durch HOLD eine Id zum Beispiel in einer Variablen gespeichert wird und bei RETRIEVE kann man diese Id dann angeben. Aber ich habe das noch nicht weiter gedacht... Hier gibts eventuell noch weitere Haken.

Fuer Ideen bin ich offen!

Armin
 
An die Sache mit der ID hatte ich auch schon gedacht, als ich mit dem "alten" chan_capi-0.3.5 experimentiert habe. Zumal dort die Funktion ja auch CAPIretrieve() hieß. Da dachte ich, dass in die Klammern eventuell ein ID gehören muss.

Ich werde auch noch mal nach Lösungen suchen. Allerdings wohl nur auf Basis der extensions.conf, denn mit dem Quelltext habe ich mich noch nicht wirklich befasst.

Meldest du dich hier, wenn ECT laufen sollte?
 
Okay, ich melde mich wenn ECT bei mir laeuft.

Wenn Du dich mit Moeglichkeiten in der extensions.conf dazu befasst waere super, ich mach dann die Aenderungen im chan_capi-cm.

Armin
 
Ich habe HOLD und RETRIEVE so umgebaut, dass man bei HOLD einen Variablennamen angeben kann. Dieser, wenn angegeben, wird dann mit der ID belegt. Bei RETRIEVE kann man dann diese ID angeben.
Im CVS habe ich das aber noch nicht, da es noch nicht ganz funktioniert.

Da Asterisk-HEAD nun auch HOLD/UNHOLD unterstuetzt, wird dies nun auch von CAPI supported (kann ueber capi.conf aktiviert werden).
Ich werde das wohl morgen ins CVS stellen.

Mit ECT habe ich so meine Probleme. Die alte Implemetierung war ja doch sehr wunderlich, da direkt auch ein Call eingleitet wurde. So etwas sollte man schon dem dialplan von Astreisk ueberlassen.
Meine Idee waere, dass man beim Dial() ein 't' fuer transfer in den capi dial Parametern angibt, wenn ein ECT anstelle von CAPI-CAPI bridging gemacht werden soll.

Ideen/Anmerkungen dazu ?

Armin
 
Ich habe versucht vor dem Retrieve den Channel mit Set(CHANNEL=CAPI) auf Capi zu setzen. Allerdings hat Asterisk die Änderung bei mir nicht übernommen. Noch habe ich also keinen Weg, das über die Extensions zu lösen.
Die Lösung mit der Variblen für HOLD und RETRIEVE gefällt mir. Ist damit auch das Problem gelöst, dass man erst irgendwie in den CAPI-Channel gelangen muss?
Was das ECT angeht, hoffe ich, deinen Vorschlag richtig verstanden zu haben. Es wäre dann also möglich, über Asterisk in den Transfer-Mode zu wechseln und dann über eine zugehörige Extension, das Dial-Kommando mit "t" für Transfer anzusprechen? Kommt man sich durch das "t" nicht mit der Transferfunktion von * ins Gehege? Oder war das "t" nur als Beispiel gedacht? Dass der neue Anruf über die Extensions aufgebaut werden soll, ist in meinen Augen sinnvoll.

Gruß aus dem Norden!
Ingmar
 
Dass man RETRIEVE auch ausserhalb eines CAPI-channels machen kann, muss ich noch einbauen.

Zur Zeit wird (da Asterisk-CVS-HEAD das anbietet) auch ein ISDN-HOLD supported, wenn Asterisk ein HOLD meldet. Dies kann ueber die capi.conf mit hold=yes aktiviert werden.
Das werde ich aber noch etwas modifizieren:
1) holdtype=local ;kein HOLD, Kommando wird wie frueher ignoriert
holdtype=hold ;echtes ISDN HOLD
holdtype=notify ;es wird nur ein notify gesendet (MOH geht weiterhin und Gegenstelle
bekommt nur diese Info.
2) das Ganze wie 1) aber auch dynamisch per capicommand()

Leider ist die Reihenfolge (wenn hold=yes), so wie sie Asterisk beim Transfer macht, nicht ganz
Telekom kompatibel. Hier muss noch ein Workaround rein:
Wenn man am Telekomanschluss eine Verbindung aufgebaut hat, diesen dann auf HOLD legt und eine zweite Verbindung aufbaut, kann man den ersten nicht RETRIEVEn: die Verbindungen brechen ab. Telekom und einige andere, sowie Anlagen machen hier im channel-id handling (bei einem Endgeraet) etwas durcheinander.

Was ECT betrifft habe ich eine etwas andere Loesung nun eingebaut:
capicommand(ECT|[ID]) sollte funktionieren und kann so eingesetzt werden:
(Ich habe ECT nicht und kann es nichtr wirklich testen)

[macro-capiect]
exten => s,1,capicommand(ect)

[default]
exten => s,1,capicommand(hold)
exten => s,2,Dial(CAPI/1234,60,M(capiect))

Die notwendige ID wird bei HOLD automatisch in _CALLERHOLDID gesetzt und bei ECT benutzt.

Waere nett, wenn jemand das testen koennte und ueber feedback wuerde ich mich auch freuen...

Armin
 
So, ich habe mal n bischen mit dem CVS von chan_capi getestet. Dabei bin ich zu folgendem Ergebnis gekommen:
So der anruf im Asterisk gehalten wird (holdtype=local) klappt das Vermitteln (blind und attended) unter einsatz beider B-Kanäle.
Bei Holdtype=local funt der Attendet Transfer garnicht. Beim blind-Transfer wird das Gespräch zuerst in der Tk-Anlage gehalten (man erkennt es an der schönen Musik), beim Verbindungsaufbau rutscht das Gespräch allerdings wieder in den Asterisk hold, und zum Verbinden werden dann wieder beide B-Kanäle benutzt.

Leider habe ich noch keine Möglichkeit gefunden die obige Variante mit dem Makro für einen Call-Transfer zu nutzen, da ich nicht weiss, wie ich diese Extension während eines Gespräches aufrufen soll.
 
Hallo Armin,

gibt es hierzu einen neuen Stand?
Ich habe ECT erfolglos an einer Octopus getestet: der gehaltene Ruf wird zwar transferiert, die channels bleiben im Asterisk aber belegt. (holdtype=hold). chan_capi CVS-Head Version von heute.
Ich könnte noch mit einem D-Channel trace dienen (über parallel angeklemmte sirrix-Karte), würde das helfen?

Danke&Grüße
Jörg
 
Ich habe bisher noch keine gute Loesung gefunden.
Kannst Du ein level 5 capi debug log erzeugen und mir schicken? An meiner (Test-)Anlage ist ECT leider gar nicht moeglich und extern ist es mir auf dauer zu teuer...

Armin
 
Ist das eigentlich bei den ISDN-Karten mit HFC-Chipsatz möglich? Da könnte man dann doch unter Umständen das Prinzip abkupfern (so es denn da geht). Sind ja auch nur ISDN-Karten.
 
Meinst Du mit dem ZAP Treiber?
Ich habe bisher da noch nichts bezueglich dieser Supplementary Services gefunden. Das Problem ist auch nicht die ISDN Karte oder der Treiber, den CAPI kann das. Nur in der Reihenfolge wie es Asterisk macht/vorgibt, geht es nicht so einfach. Hier muss dann chan_capi ein 'workaround' machen, aber mir ist noch nichts passendes eingefallen.

Armin
 
@Armin:

Ja, Trace ziehe ich gerne, hoffe, ich schaffe es noch heute nachm. oder morgen.

Danke&Grüße
Jörg
 
Hallo erstmal,

ich bin ganz neu hier und wollte nur mal so meinen Senf dazu geben. Evtl. hilft es ja weiter ?
Ich habe vor längerer Zeit schonmal mit ECT experimentiert (Als "Enduser" also nichts programmiertechnisches) Und es gibt wohl verschiedene Arten von ECT. Einmal in der Vermittlungsstelle der Telekom (dafür zahlt man monatlich glaube 5¤) und einmal in der Anlage selbst (2 B-Kanäle zusammenschalten ? Das ging! ) wenn diese es unterstützt. Ich hatte das mal mit Caiviar probiert (ECT über die Vermittlungsstelle). Aber leider haben der Entwickler und ich es nie hinbekommen. Angeblich muss man den Call erst auf HOLD legen und dann ECT aufrufen. Aber irgendwie klappte das wohl nicht so. Ich habe hier noch ein paar mails die von der Newsgroup comp.dcom.isdn.capi auf meine Fragen kamen.

Ich selber mache damit nix mehr. Kann also nicht mal eben testen ;)
Obwohl ich gerne nochmal das ganze beantrage wenn es helfen kann ?

Code: 
first thing "yes my telecom-provider supports ECT on my phone line".
I had to subscribe to this special service. They bill me for that every
month :)
I´m trying to connect 2 persons with each other.
I dial the first number bring it to hold and then dial the second number
after that I do an ECT. I just get an error message 3701 "Invoke Error".
I tried the same with 3PTY and then everything works fine.
I attached some log files maybe someone can tell me what´s wrong or where
I have to look for?

Thx,

Joerg Esser

The capiinfo from the driver tells me:

Manufacturer: AVM GmbH
CAPI Version: 2.0
Manufacturer Version: 3.100-05  (49.5)
Global Options: 0x00000039
   internal controller supported
   DTMF supported
   Supplementary Services supported
   channel allocation supported (leased lines)
B1 protocols support: 0x4000011f
   64 kbit/s with HDLC framing
   64 kbit/s bit-transparent operation
   V.110 asynconous operation with start/stop byte framing
   V.110 synconous operation with HDLC framing
   T.30 modem for fax group 3
   Modem asyncronous operation with start/stop byte framing
B2 protocols support: 0x00000b1b
   ISO 7776 (X.75 SLP)
   Transparent
   LAPD with Q.921 for D channel X.25 (SAPI 16)
   T.30 fro fax group 3
   ISO 7776 (X.75 SLP) with V.42bis compression
   V.120 asyncronous mode
   V.120 bit-transparent mode
B3 protocols support: 0x800000bf
   Transparent
   T.90NL, T.70NL, T.90
   ISO 8208 (X.25 DTE-DTE)
   X.25 DCE
   T.30 for fax group 3
   reserved

Supplementary services support: 0x000003ff
   Hold / Retrieve
   Terminal Portability
   ECT
   3PTY
   Call Forwarding
   Call Deflection
   MCID
   CCBS



Here is some log of the ISDN messages I get:

Fri Apr 11 09:03:38 2003: send CAPI message CONNECT_REQ: 0x02, 0x80,
PLCI:0x1
Fri Apr 11 09:03:38 2003: | CONNECT_REQ ID=005 #0x6420 LEN=0044
Fri Apr 11 09:03:38 2003: |   Controller/PLCI/NCCI            = 0x1
Fri Apr 11 09:03:38 2003: |   CIPValue                        = 0x1
Fri Apr 11 09:03:38 2003: |   CalledPartyNumber               = <80>919314
Fri Apr 11 09:03:38 2003: |   CallingPartyNumber              = <80>
Fri Apr 11 09:03:38 2003: |   CalledPartySubaddress           = default
Fri Apr 11 09:03:38 2003: |   CallingPartySubaddress          = default
Fri Apr 11 09:03:38 2003: |   BProtocol
Fri Apr 11 09:03:38 2003: |    B1protocol                     = 0x1
Fri Apr 11 09:03:38 2003: |    B2protocol                     = 0x1
Fri Apr 11 09:03:38 2003: |    B3protocol                     = 0x0
Fri Apr 11 09:03:38 2003: |    B1configuration                = default
Fri Apr 11 09:03:38 2003: |    B2configuration                = default
Fri Apr 11 09:03:38 2003: |    B3configuration                = default
Fri Apr 11 09:03:38 2003: |   BC                              = default
Fri Apr 11 09:03:38 2003: |   LLC                             = default
Fri Apr 11 09:03:38 2003: |   HLC                             = default
Fri Apr 11 09:03:38 2003: |   AdditionalInfo
Fri Apr 11 09:03:38 2003: |    BChannelinformation            = default
Fri Apr 11 09:03:38 2003: |    Keypadfacility                 = default
Fri Apr 11 09:03:38 2003: |    Useruserdata                   = default
Fri Apr 11 09:03:38 2003: |    Facilitydataarray              = default
Fri Apr 11 09:03:38 2003: |
Fri Apr 11 09:03:38 2003: got CAPI message CONNECT_CONF: 0x02, 0x81,
(Info:0) PLCI:0x201
Fri Apr 11 09:03:38 2003: | CONNECT_CONF ID=005 #0x6420 LEN=0014
Fri Apr 11 09:03:38 2003: |   Controller/PLCI/NCCI            = 0x201
Fri Apr 11 09:03:38 2003: |   Info                            = 0x0
Fri Apr 11 09:03:38 2003: |
Fri Apr 11 09:03:45 2003: got CAPI message CONNECT_ACTIVE_IND: 0x03,
0x82, (Info:0) PLCI:0x201
Fri Apr 11 09:03:45 2003: | CONNECT_ACTIVE_IND ID=005 #0x8ddc LEN=0015
Fri Apr 11 09:03:45 2003: |   Controller/PLCI/NCCI            = 0x201
Fri Apr 11 09:03:45 2003: |   ConnectedNumber                 = default
Fri Apr 11 09:03:45 2003: |   ConnectedSubaddress             = default
Fri Apr 11 09:03:45 2003: |   LLC                             = default
Fri Apr 11 09:03:45 2003: |
Fri Apr 11 09:03:45 2003: send CAPI message CONNECT_ACTIVE_RESP: 0x03,
0x83, PLCI:0x201
Fri Apr 11 09:03:45 2003: | CONNECT_ACTIVE_RESP ID=005 #0x8ddc LEN=0012
Fri Apr 11 09:03:45 2003: |   Controller/PLCI/NCCI            = 0x201
Fri Apr 11 09:03:45 2003: |
Fri Apr 11 09:03:45 2003: send CAPI message CONNECT_B3_REQ: 0x82, 0x80,
PLCI:0x201
Fri Apr 11 09:03:45 2003: | CONNECT_B3_REQ ID=005 #0x8ddc LEN=0013
Fri Apr 11 09:03:45 2003: |   Controller/PLCI/NCCI            = 0x201
Fri Apr 11 09:03:45 2003: |   NCPI                            = default
Fri Apr 11 09:03:45 2003: |
Fri Apr 11 09:03:46 2003: got CAPI message CONNECT_B3_CONF: 0x82, 0x81,
(Info:0) PLCI:0x20201
Fri Apr 11 09:03:46 2003: | CONNECT_B3_CONF ID=005 #0x8ddc LEN=0014
Fri Apr 11 09:03:46 2003: |   Controller/PLCI/NCCI            = 0x20201
Fri Apr 11 09:03:46 2003: |   Info                            = 0x0
Fri Apr 11 09:03:46 2003: |
Fri Apr 11 09:03:46 2003: got CAPI message CONNECT_B3_ACTIVE_IND: 0x83,
0x82, (Info:0) PLCI:0x20201
Fri Apr 11 09:03:46 2003: | CONNECT_B3_ACTIVE_IND ID=005 #0x8ddd LEN=0013
Fri Apr 11 09:03:46 2003: |   Controller/PLCI/NCCI            = 0x20201
Fri Apr 11 09:03:46 2003: |   NCPI                            = default
Fri Apr 11 09:03:46 2003: |
Fri Apr 11 09:03:46 2003: send CAPI message CONNECT_B3_ACTIVE_RESP:
0x83, 0x83, PLCI:0x20201
Fri Apr 11 09:03:46 2003: | CONNECT_B3_ACTIVE_RESP ID=005 #0x8ddd LEN=0012
Fri Apr 11 09:03:46 2003: |   Controller/PLCI/NCCI            = 0x20201
Fri Apr 11 09:03:46 2003: |
Fri Apr 11 09:03:46 2003: send CAPI message FACILITY_REQ: 0x80, 0x80,
PLCI:0x20201
Fri Apr 11 09:03:46 2003: | FACILITY_REQ ID=005 #0x8ddd LEN=0023
Fri Apr 11 09:03:46 2003: |   Controller/PLCI/NCCI            = 0x20201
Fri Apr 11 09:03:46 2003: |   FacilitySelector                = 0x1
Fri Apr 11 09:03:46 2003: |   FacilityRequestParameter        = <01 00
28 00 28 00 00 00>
Fri Apr 11 09:03:46 2003: |
Fri Apr 11 09:03:46 2003: send CAPI message FACILITY_REQ: 0x80, 0x80,
PLCI:0x20201
Fri Apr 11 09:03:46 2003: | FACILITY_REQ ID=005 #0x6420 LEN=0018
Fri Apr 11 09:03:46 2003: |   Controller/PLCI/NCCI            = 0x20201
Fri Apr 11 09:03:46 2003: |   FacilitySelector                = 0x3
Fri Apr 11 09:03:46 2003: |   FacilityRequestParameter        = <02 00 00>
Fri Apr 11 09:03:46 2003: |
Fri Apr 11 09:03:46 2003: got CAPI message FACILITY_CONF: 0x80, 0x81,
(Info:0) PLCI:0x20201
Fri Apr 11 09:03:46 2003: | FACILITY_CONF ID=005 #0x8ddd LEN=0019
Fri Apr 11 09:03:46 2003: |   Controller/PLCI/NCCI            = 0x20201
Fri Apr 11 09:03:46 2003: |   Info                            = 0x0
Fri Apr 11 09:03:46 2003: |   FacilitySelector                = 0x1
Fri Apr 11 09:03:46 2003: |   FacilityConfirmationParameter   = <00 00>
Fri Apr 11 09:03:46 2003: |
Fri Apr 11 09:03:46 2003: got CAPI message FACILITY_CONF: 0x80, 0x81,
(Info:0) PLCI:0x20201
Fri Apr 11 09:03:46 2003: | FACILITY_CONF ID=005 #0x6420 LEN=0022
Fri Apr 11 09:03:46 2003: |   Controller/PLCI/NCCI            = 0x20201
Fri Apr 11 09:03:46 2003: |   Info                            = 0x0
Fri Apr 11 09:03:46 2003: |   FacilitySelector                = 0x3
Fri Apr 11 09:03:46 2003: |   FacilityConfirmationParameter   = <02 00
02 00 00>
Fri Apr 11 09:03:46 2003: |
Fri Apr 11 09:03:46 2003: got CAPI message FACILITY_IND: 0x80, 0x82,
(Info:0) PLCI:0x201
Fri Apr 11 09:03:46 2003: | FACILITY_IND ID=005 #0x8de1 LEN=0020
Fri Apr 11 09:03:46 2003: |   Controller/PLCI/NCCI            = 0x201
Fri Apr 11 09:03:46 2003: |   FacilitySelector                = 0x3
Fri Apr 11 09:03:46 2003: |   FacilityIndicationParameter     = <02 00
02 00 00>
Fri Apr 11 09:03:46 2003: |
Fri Apr 11 09:03:46 2003: send CAPI message FACILITY_RESP: 0x80, 0x83,
PLCI:0x201
Fri Apr 11 09:03:46 2003: | FACILITY_RESP ID=005 #0x8de1 LEN=0020
Fri Apr 11 09:03:46 2003: |   Controller/PLCI/NCCI            = 0x201
Fri Apr 11 09:03:46 2003: |   FacilitySelector                = 0x3
Fri Apr 11 09:03:46 2003: |   FacilityResponseParameters      = <02 00
02 00 00>
Fri Apr 11 09:03:46 2003: |
Fri Apr 11 09:03:46 2003: got CAPI message DISCONNECT_B3_IND: 0x84,
0x82, (Info:0) PLCI:0x20201
Fri Apr 11 09:03:46 2003: | DISCONNECT_B3_IND ID=005 #0x8de2 LEN=0015
Fri Apr 11 09:03:46 2003: |   Controller/PLCI/NCCI            = 0x20201
Fri Apr 11 09:03:46 2003: |   Reason_B3                       = 0x3301
Fri Apr 11 09:03:46 2003: |   NCPI                            = default
Fri Apr 11 09:03:46 2003: |
Fri Apr 11 09:03:46 2003: send CAPI message DISCONNECT_B3_RESP: 0x84,
0x83, PLCI:0x20201
Fri Apr 11 09:03:46 2003: | DISCONNECT_B3_RESP ID=005 #0x8de2 LEN=0012
Fri Apr 11 09:03:46 2003: |   Controller/PLCI/NCCI            = 0x20201
Fri Apr 11 09:03:46 2003: |
Fri Apr 11 09:03:48 2003: send CAPI message CONNECT_REQ: 0x02, 0x80,
PLCI:0x1
Fri Apr 11 09:03:48 2003: | CONNECT_REQ ID=005 #0x6420 LEN=0049
Fri Apr 11 09:03:48 2003: |   Controller/PLCI/NCCI            = 0x1
Fri Apr 11 09:03:48 2003: |   CIPValue                        = 0x1
Fri Apr 11 09:03:48 2003: |   CalledPartyNumber               =
<80>01708524485
Fri Apr 11 09:03:48 2003: |   CallingPartyNumber              = <80>
Fri Apr 11 09:03:48 2003: |   CalledPartySubaddress           = default
Fri Apr 11 09:03:48 2003: |   CallingPartySubaddress          = default
Fri Apr 11 09:03:48 2003: |   BProtocol
Fri Apr 11 09:03:48 2003: |    B1protocol                     = 0x1
Fri Apr 11 09:03:48 2003: |    B2protocol                     = 0x1
Fri Apr 11 09:03:48 2003: |    B3protocol                     = 0x0
Fri Apr 11 09:03:48 2003: |    B1configuration                = default
Fri Apr 11 09:03:48 2003: |    B2configuration                = default
Fri Apr 11 09:03:48 2003: |    B3configuration                = default
Fri Apr 11 09:03:48 2003: |   BC                              = default
Fri Apr 11 09:03:48 2003: |   LLC                             = default
Fri Apr 11 09:03:48 2003: |   HLC                             = default
Fri Apr 11 09:03:48 2003: |   AdditionalInfo
Fri Apr 11 09:03:48 2003: |    BChannelinformation            = default
Fri Apr 11 09:03:48 2003: |    Keypadfacility                 = default
Fri Apr 11 09:03:48 2003: |    Useruserdata                   = default
Fri Apr 11 09:03:48 2003: |    Facilitydataarray              = default
Fri Apr 11 09:03:48 2003: |
Fri Apr 11 09:03:48 2003: got CAPI message CONNECT_CONF: 0x02, 0x81,
(Info:0) PLCI:0x301
Fri Apr 11 09:03:48 2003: | CONNECT_CONF ID=005 #0x6420 LEN=0014
Fri Apr 11 09:03:48 2003: |   Controller/PLCI/NCCI            = 0x301
Fri Apr 11 09:03:48 2003: |   Info                            = 0x0
Fri Apr 11 09:03:48 2003: |
Fri Apr 11 09:03:56 2003: got CAPI message CONNECT_ACTIVE_IND: 0x03,
0x82, (Info:0) PLCI:0x301
Fri Apr 11 09:03:56 2003: | CONNECT_ACTIVE_IND ID=005 #0x8de8 LEN=0015
Fri Apr 11 09:03:56 2003: |   Controller/PLCI/NCCI            = 0x301
Fri Apr 11 09:03:56 2003: |   ConnectedNumber                 = default
Fri Apr 11 09:03:56 2003: |   ConnectedSubaddress             = default
Fri Apr 11 09:03:56 2003: |   LLC                             = default
Fri Apr 11 09:03:56 2003: |
Fri Apr 11 09:03:56 2003: send CAPI message CONNECT_ACTIVE_RESP: 0x03,
0x83, PLCI:0x301
Fri Apr 11 09:03:56 2003: | CONNECT_ACTIVE_RESP ID=005 #0x8de8 LEN=0012
Fri Apr 11 09:03:56 2003: |   Controller/PLCI/NCCI            = 0x301
Fri Apr 11 09:03:56 2003: |
Fri Apr 11 09:03:56 2003: send CAPI message CONNECT_B3_REQ: 0x82, 0x80,
PLCI:0x301
Fri Apr 11 09:03:56 2003: | CONNECT_B3_REQ ID=005 #0x8de8 LEN=0013
Fri Apr 11 09:03:56 2003: |   Controller/PLCI/NCCI            = 0x301
Fri Apr 11 09:03:56 2003: |   NCPI                            = default
Fri Apr 11 09:03:56 2003: |
Fri Apr 11 09:03:56 2003: got CAPI message CONNECT_B3_CONF: 0x82, 0x81,
(Info:0) PLCI:0x20301
Fri Apr 11 09:03:56 2003: | CONNECT_B3_CONF ID=005 #0x8de8 LEN=0014
Fri Apr 11 09:03:56 2003: |   Controller/PLCI/NCCI            = 0x20301
Fri Apr 11 09:03:56 2003: |   Info                            = 0x0
Fri Apr 11 09:03:56 2003: |
Fri Apr 11 09:03:56 2003: got CAPI message CONNECT_B3_ACTIVE_IND: 0x83,
0x82, (Info:0) PLCI:0x20301
Fri Apr 11 09:03:56 2003: | CONNECT_B3_ACTIVE_IND ID=005 #0x8de9 LEN=0013
Fri Apr 11 09:03:56 2003: |   Controller/PLCI/NCCI            = 0x20301
Fri Apr 11 09:03:56 2003: |   NCPI                            = default
Fri Apr 11 09:03:56 2003: |
Fri Apr 11 09:03:56 2003: send CAPI message CONNECT_B3_ACTIVE_RESP:
0x83, 0x83, PLCI:0x20301
Fri Apr 11 09:03:56 2003: | CONNECT_B3_ACTIVE_RESP ID=005 #0x8de9 LEN=0012
Fri Apr 11 09:03:56 2003: |   Controller/PLCI/NCCI            = 0x20301
Fri Apr 11 09:03:56 2003: |
Fri Apr 11 09:03:56 2003: send CAPI message FACILITY_REQ: 0x80, 0x80,
PLCI:0x20301
Fri Apr 11 09:03:56 2003: | FACILITY_REQ ID=005 #0x8de9 LEN=0023
Fri Apr 11 09:03:56 2003: |   Controller/PLCI/NCCI            = 0x20301
Fri Apr 11 09:03:56 2003: |   FacilitySelector                = 0x1
Fri Apr 11 09:03:56 2003: |   FacilityRequestParameter        = <01 00
28 00 28 00 00 00>
Fri Apr 11 09:03:56 2003: |
Fri Apr 11 09:03:56 2003: got CAPI message FACILITY_CONF: 0x80, 0x81,
(Info:0) PLCI:0x20301
Fri Apr 11 09:03:56 2003: | FACILITY_CONF ID=005 #0x8de9 LEN=0019
Fri Apr 11 09:03:56 2003: |   Controller/PLCI/NCCI            = 0x20301
Fri Apr 11 09:03:56 2003: |   Info                            = 0x0
Fri Apr 11 09:03:56 2003: |   FacilitySelector                = 0x1
Fri Apr 11 09:03:56 2003: |   FacilityConfirmationParameter   = <00 00>
Fri Apr 11 09:03:56 2003: |
Fri Apr 11 09:03:58 2003: send CAPI message DISCONNECT_B3_REQ: 0x84,
0x80, PLCI:0x20301
Fri Apr 11 09:03:58 2003: | DISCONNECT_B3_REQ ID=005 #0x04d2 LEN=0013
Fri Apr 11 09:03:58 2003: |   Controller/PLCI/NCCI            = 0x20301
Fri Apr 11 09:03:58 2003: |   NCPI                            = default
Fri Apr 11 09:03:58 2003: |
Fri Apr 11 09:03:58 2003: got CAPI message DISCONNECT_B3_CONF: 0x84,
0x81, (Info:0) PLCI:0x20301
Fri Apr 11 09:03:58 2003: | DISCONNECT_B3_CONF ID=005 #0x04d2 LEN=0014
Fri Apr 11 09:03:58 2003: |   Controller/PLCI/NCCI            = 0x20301
Fri Apr 11 09:03:58 2003: |   Info                            = 0x0
Fri Apr 11 09:03:58 2003: |
Fri Apr 11 09:03:58 2003: got CAPI message DISCONNECT_B3_IND: 0x84,
0x82, (Info:0) PLCI:0x20301
Fri Apr 11 09:03:58 2003: | DISCONNECT_B3_IND ID=005 #0x8e0c LEN=0015
Fri Apr 11 09:03:58 2003: |   Controller/PLCI/NCCI            = 0x20301
Fri Apr 11 09:03:58 2003: |   Reason_B3                       = 0x0
Fri Apr 11 09:03:58 2003: |   NCPI                            = default
Fri Apr 11 09:03:58 2003: |
Fri Apr 11 09:03:58 2003: send CAPI message DISCONNECT_B3_RESP: 0x84,
0x83, PLCI:0x20301
Fri Apr 11 09:03:58 2003: | DISCONNECT_B3_RESP ID=005 #0x8e0c LEN=0012
Fri Apr 11 09:03:58 2003: |   Controller/PLCI/NCCI            = 0x20301
Fri Apr 11 09:03:58 2003: |
Fri Apr 11 09:03:58 2003: send CAPI message FACILITY_REQ: 0x80, 0x80,
PLCI:0x20301
Fri Apr 11 09:03:58 2003: | FACILITY_REQ ID=005 #0x6420 LEN=0022
Fri Apr 11 09:03:58 2003: |   Controller/PLCI/NCCI            = 0x20301
Fri Apr 11 09:03:58 2003: |   FacilitySelector                = 0x3
Fri Apr 11 09:03:58 2003: |   FacilityRequestParameter        = <06 00
04 01 02 00 00>
Fri Apr 11 09:03:58 2003: |
Fri Apr 11 09:03:58 2003: got CAPI message FACILITY_CONF: 0x80, 0x81,
(Info:0) PLCI:0x20301
Fri Apr 11 09:03:58 2003: | FACILITY_CONF ID=005 #0x6420 LEN=0022
Fri Apr 11 09:03:58 2003: |   Controller/PLCI/NCCI            = 0x20301
Fri Apr 11 09:03:58 2003: |   Info                            = 0x0
Fri Apr 11 09:03:58 2003: |   FacilitySelector                = 0x3
Fri Apr 11 09:03:58 2003: |   FacilityConfirmationParameter   = <06 00
02 00 00>
Fri Apr 11 09:03:58 2003: |
Fri Apr 11 09:03:58 2003: got CAPI message FACILITY_IND: 0x80, 0x82,
(Info:0) PLCI:0x301
Fri Apr 11 09:03:58 2003: | FACILITY_IND ID=005 #0x8e0d LEN=0020
Fri Apr 11 09:03:58 2003: |   Controller/PLCI/NCCI            = 0x301
Fri Apr 11 09:03:58 2003: |   FacilitySelector                = 0x3
Fri Apr 11 09:03:58 2003: |   FacilityIndicationParameter     = <06 00
02 01 37>
Fri Apr 11 09:03:58 2003: |
Fri Apr 11 09:03:58 2003: send CAPI message FACILITY_RESP: 0x80, 0x83,
PLCI:0x301
Fri Apr 11 09:03:58 2003: | FACILITY_RESP ID=005 #0x8e0d LEN=0020
Fri Apr 11 09:03:58 2003: |   Controller/PLCI/NCCI            = 0x301
Fri Apr 11 09:03:58 2003: |   FacilitySelector                = 0x3
Fri Apr 11 09:03:58 2003: |   FacilityResponseParameters      = <06 00
02 01 37>
Fri Apr 11 09:03:58 2003: |
Fri Apr 11 09:04:06 2003: got CAPI message DISCONNECT_IND: 0x04, 0x82,
(Info:0) PLCI:0x201
Fri Apr 11 09:04:06 2003: | DISCONNECT_IND ID=005 #0x8e0f LEN=0014
Fri Apr 11 09:04:06 2003: |   Controller/PLCI/NCCI            = 0x201
Fri Apr 11 09:04:06 2003: |   Reason                          = 0x3490
Fri Apr 11 09:04:06 2003: |
Fri Apr 11 09:04:06 2003: send CAPI message DISCONNECT_RESP: 0x04, 0x83,
PLCI:0x201
Fri Apr 11 09:04:06 2003: | DISCONNECT_RESP ID=005 #0x8e0f LEN=0012
Fri Apr 11 09:04:06 2003: |   Controller/PLCI/NCCI            = 0x201
Fri Apr 11 09:04:06 2003: |
Fri Apr 11 09:04:06 2003: got CAPI message DISCONNECT_IND: 0x04, 0x82,
(Info:0) PLCI:0x301
Fri Apr 11 09:04:06 2003: | DISCONNECT_IND ID=005 #0x8e10 LEN=0014
Fri Apr 11 09:04:06 2003: |   Controller/PLCI/NCCI            = 0x301
Fri Apr 11 09:04:06 2003: |   Reason                          = 0x3490
Fri Apr 11 09:04:06 2003: |
Fri Apr 11 09:04:06 2003: send CAPI message DISCONNECT_RESP: 0x04, 0x83,
PLCI:0x301
Fri Apr 11 09:04:06 2003: | DISCONNECT_RESP ID=005 #0x8e10 LEN=0012
Fri Apr 11 09:04:06 2003: |   Controller/PLCI/NCCI            = 0x301
Fri Apr 11 09:04:06 2003: | 


--------------------ANTWORT---------------------------------------
Betreff:
Re: ECT with AVM Fritz/DSL doesn´t work but 3PTY works !
Von:
"Tobias Erichsen" 
Datum:
Tue, 7 Oct 2003 11:36:51 +0200
Newsgroups:
comp.dcom.isdn.capi

"Jörg Esser" > schrieb im Newsbeitrag
news:[email protected]...

>> Hi,
>>
>>
>> first thing "yes my telecom-provider supports ECT on my phone line".
>> I had to subscribe to this special service. They bill me for that every
>> month  :) 
>> I´m trying to connect 2 persons with each other.
>> I dial the first number bring it to hold and then dial the second number
>> after that I do an ECT. I just get an error message 3701 "Invoke Error".
>> I tried the same with 3PTY and then everything works fine.
>> I attached some log files maybe someone can tell me what´s wrong or where
>> I have to look for?


First of all, you are sending the ECT to an NCCI - although most
controllers will accept this, this really makes no sense, since this
operation works on the connection, not on the b-channel-data.

Second the - error you are getting is an ASN.1 reject of error
class "Invoke Problem", code "unrecognized operation". You are initiating
an "explicit" ECT (PLCI in main-part of message is different from the
PLCI in the supp-service-specific parameter) - this procedure is not
supported by almost everything to be found in the ISDN-world -
should work nicely in VoiP though  ;-) . Use the implicit invocation (both
PLCIs pointing to the same connection) - then it should work in the
ISDN-network, too.

Tobias

Gruss,

Jörg
 
Probleme mit ECT

Hallo zusammen,
nach einem Umstieg auf die neue Asterisk-Version (1.2.1) habe ich einige Probleme mit dem
neuen chan_capi-cm-0.6.3.tar.gz (auch mit den Vorgängerversion 0.6.1 und 0.6.2).
Mein Server hängt mit einer Fritz!card PCI am internen So-Bus einer Auerswald-Anlage und ist über zwei MSN's (43, 42)
von den anderen Geräten der Anlage aus erreichbar.
Mit meiner bisherigen Kombination aus Asterisk 1.0.9 und dem alten chan_capi-0.3.5 hatte ich meinen
Server so konfiguriert, dass Anrufe, die auf einer Asterisk-MSN ankommen, vom Server zunächst verarbeitet werden und
dann bei Bedarf wieder zurück zu einem anderen Teilnehmer der ISDN-Anlage vermittelt werden und dabei beide B-Kanäle wieder freigeben (eben ECT).
Dazu sah ein Teil meines alten Dialplans wie folgt aus:
Code: 
exten => _3[1-6],1,capiHOLD
exten => _3[1-6],2,capiECT,43:${EXTEN}

Da die neuen Asterisk-Versionen und die alte CAPI-Version ja nicht kompatibel sind, habe ich mich an chan_capi-cm herangewagt, komme aber momentan nicht weiter.

Meine Einstellungen in der capi.conf sehen momentan so aus:
Code: 
[general]
nationalprefix=0
internationalprefix=00
rxgain=0.8
txgain=0.8
language=de

; interface sections ...
[ISDN1]
;ntmode=yes
isdnmode=msn
incomingmsn=43
defaultcid=43		 
controller=1     
group=1          
softdtmf=on
relaxdtmf=on
accountcode=
context=isdn-in
holdtype=hold
immediate=yes
bridge=no
devices=2
Ich musste zunächst immediate=yes setzen, damit die Maschine überhaupt antwortet.

Wenn ich dann probehalber ganz normal mittels Dial weiterverbinde (wie unten dargestellt) funktioniert dies inzwischen auch, blockiert dann aber dummerweise beide B-Kanäle:
Code: 
[isdn-in]
exten => 43,1,Answer
exten => 43,n,Wait(4)
exten => 43,n,Dial(CAPI/ISDN1/44:33,30,tT)

Daher wollte ich das ganze, wie bisher, auch mittels ECT machen. Mein getesteter Dialplan dazu sieht wie folgt aus:

Code: 
[isdn-in]
exten => 43,1,Answer
exten => 43,n,Wait(4)
exten => 43,n,capicommand(hold)
exten => 43,n,Wait(1)
exten => 43,n,Dial(CAPI/ISDN1/43:<Zielrufnummer>,30,M(capiect))

[macro-capiect]
exten => s,1,capicommand(ect)
Dies klappt leider noch nicht wie gewünscht. Sobald der Anrufer auf Hold gesetzt wird, bekommt er zunächst einmal die Wartemusik der TK-Anlage zu hören, ist also auf ISDN-Hold. Dann wählt der Asterisk tatsächlich die Zielrufnummer an. Sobald dort abgehoben wird, hört der Angerufene allerdings gar nichts und der Anrufer hört weiter die Wartemusik.
Folgende Ausgabe sehe ich im Debug-Modus:
Code: 
 -- CONNECT_IND (PLCI=0x101,DID=43,CID=<Anrufer>,CIP=0x4,CONTROLLER=0x1)
  == Started pbx on channel CAPI/ISDN1/43-0
    -- Executing Answer("CAPI/ISDN1/43-0", "") in new stack
    -- Executing Wait("CAPI/ISDN1/43-0", "4") in new stack
    -- Executing capiCommand("CAPI/ISDN1/43-0", "hold") in new stack
    -- capiCommand: 'hold' '(null)'
       > ISDN1: sent HOLD for PLCI=0x101
    -- Executing Wait("CAPI/ISDN1/43-0", "1") in new stack
    -- ISDN1: PLCI=0x101 put onhold
    -- Executing Dial("CAPI/ISDN1/43-0", "CAPI/ISDN1/42:<Zielrufnummer>|30|M(capiect)") in new stack
       > data = ISDN1/42:<Zielrufnummer>
       > capi request for interface 'ISDN1'
  == ISDN1: Call CAPI/ISDN1/<Zielrufnummer>-1   (pres=0x00, ton=0x41)
    -- Called ISDN1/42:<Zielrufnummer>
    -- ISDN1: received CONNECT_CONF PLCI = 0x201
    -- CAPI/ISDN1/<Zielrufnummer>-1 is making progress passing it to CAPI/ISDN1/43-0
    -- CAPI/ISDN1/<Zielrufnummer>-1 is ringing
    -- ISDN1: attempting ALERT in state 10
    -- CAPI/ISDN1/<Zielrufnummer>-1 answered CAPI/ISDN1/43-0
    -- Executing capiCommand("CAPI/ISDN1/<Zielrufnummer>-1", "ect") in new stack
    -- capiCommand: 'ect' '(null)'
       > ISDN1: using PLCI=0x101 for ECT
       > ISDN1: sent ECT for PLCI=0x101 to PLCI=0x201
    -- Attempting native bridge of CAPI/ISDN1/43-0 and CAPI/ISDN1/<Zielrufnummer>-1
    -- ISDN1: PLCI=0x201 ECT  Reason=0x3303
Der Schalter bridge=yes bzw. bridge=no bewirkt keine Änderung des Phänomens.
 
Das Reason=0x3303 bedeutet "Protocol error layer 3" und wird von der Anlage gemeldet. Offensichtlich wird ECT nicht akzeptiert.
Ein log mit "set verbose 5" und "capi debug" koennte mehr helfen. Wenn es mit dem alten Asterisk/chan_capi funktioniert, waere ein log davon zum Vergleich auch gut.

Armin
 
gewünschte Logfiles

So, die Debug-Outputs sollten im angefügten Archiv zu finden sein.
Danke schon einmal für die viele Mühe!!!
 

Anhänge

  • logs.tgz
    7.3 KB · Aufrufe: 4
Danke fuer die Logs. Koenntest Du bitte mal folgenden Patch zum neuen chan_capi-cm testen?

diff -u -r1.175 chan_capi.c
--- chan_capi.c 6 Jan 2006 14:35:51 -0000 1.175
+++ chan_capi.c 8 Jan 2006 15:47:49 -0000
@@ -3691,7 +3691,7 @@
_capi_put_cmsg(&CMSG);
}

- while ((i->state != CAPI_STATE_CONNECTED) && (waitcount > 0)) {
+ while ((i->isdnstate & CAPI_ISDN_STATE_B3_UP) && (waitcount > 0)) {
waitcount--;
usleep(10000);
}


Armin
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 444 (Mitglieder: 39, Gäste: 405)

Neueste Beiträge

Statistik des Forums

Themen
244,913
Beiträge
2,220,780
Mitglieder
371,665
Neuestes Mitglied
H350
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück