[Gelöst] Problem mit doppelt referenzierten Variablen

rbaer

Mitglied
Mitglied seit
7 Okt 2004
Beiträge
280
Punkte für Reaktionen
0
Punkte
0
Hallo zusammen,
ich habe ein seltsames Problem:
Ein Agi Skript setzt u.a. die Variablen LCR_DIAL sowie LCR_EXTEN.
Der Wert von LCR_DIAL wird auf PSTN, LCR_EXTEN auf die übergebene Telefonnummer mit der vorangestellten Vorwahl des Call by Call Providers gesetzt.
Die Variable LCR_DIAL wird dann doppelt referenziert, d.h. sie liefert den Inhalt der Variablen PSTN. Der NoOp als auch der darauffolgende Dial Befehl zeigen die korrekten Werte an, nur hat anscheinend chan_capi-cm ein Problem damit (V0.6.2).

Zum besseren Verständnis habe ich die entsprechenden Befehle kursiv, jeweils vor die CLI Ausgabe gesetzt.

Code:
[I]exten => s,n,AGI(lcr.agi|${MACRO_EXTEN}|${NEXT})[/I]
[I]exten => s,n,Set(PSTN='CAPI/g1/${LCR_EXTEN}/bo,30')[/I]
    -- Executing Set("Zap/2-1", "PSTN=CAPI/g1/01058xxxxxxx/bo,30") in new stack
[I]exten => s,n,NoOp(${${LCR_DIAL}})[/I]
    -- Executing NoOp("Zap/2-1", "CAPI/g1/01058xxxxxxx/bo,30") in new stack
[I]exten => s,n,Dial(${${LCR_DIAL}})[/I]
    -- Executing Dial("Zap/2-1", "CAPI/g1/01058xxxxxxx/bo,30") in new stack
Jan  4 13:44:28 WARNING[19459]: chan_capi.c:911 capi_call: Unknown parameter ',' in 'g1/01058xxxxxxx/bo,30', ignoring.
Jan  4 13:44:28 WARNING[19459]: chan_capi.c:911 capi_call: Unknown parameter '1' in 'g1/01058xxxxxxx/bo,30', ignoring.
Jan  4 13:44:28 WARNING[19459]: chan_capi.c:911 capi_call: Unknown parameter '0' in 'g1/01058xxxxxxx/bo,30', ignoring.
    -- Called g1/01058xxxxxxx/bo,30

Ergebnis ist, dass der Call zwar durchgeführt wird, aber der Timeout ignoriert wird. Im Normalfall sähe die letzte Zeile auch so aus:
-- Called g1/01058xxxxxxx/bo​


Irgendwelche Ideen?

Update:
OK, dieses Problem konnte ich lösen, indem ich das Macro folgendermaßen abänderte:
exten => s,n,Set(PSTN='CAPI/g1/${LCR_EXTEN}/bo')
exten => s,n,Dial(${${LCR_DIAL}},30)
Auch wenn ich es nicht verstehe, warum die erste Variante nicht funktioniert.
Dafür hat sich ein neues Problem ergeben:

Ortsgespräche funktionieren, da bekomme ich
Code:
   -- Executing Dial("SIP/123-2923", "CAPI/g1/01058xxxxxxx/bo|30") in new stack
    -- Called g1/01058xxxxxxx/bo
    -- CAPI/ISDN1/01058xxxxxxx-b is making progress passing it to SIP/123-2923
    -- CAPI/ISDN1/01058xxxxxxx-b is proceeding passing it to SIP/123-2923
    -- CAPI/ISDN1/01058xxxxxxx-b is ringing
Bei einem Ferngespräch jedoch:
Code:
    -- Executing Dial("SIP/123-3b21", "CAPI/g1/010450711xxxxxxx/bo|30") in new stack
    -- Called g1/010450711xxxxxxx/bo
Jan  4 17:32:49 ERROR[23740]: chan_capi.c:214 _capi_put_cmsg: CAPI error sending INFO_REQ ID=12593 #0x0032 LEN=0035
  Controller/PLCI/NCCI            = 0x101
  CalledPartyNumber               = <80>010450711xxxxxxx
  AdditionalInfo
   BChannelinformation            = default
   Keypadfacility                 = default
   Useruserdata                   = default
   Facilitydataarray              = default
 (NCCI=0x101) (error=0x1101)
    -- CAPI/ISDN1/010450711xxxxxxx-c is making progress passing it to SIP/123-3b21
Wenn ich die gleiche Nummer ohne Macro wähle geht das.

2. Update
Ist ja schön wenn man seine Probleme selbst lösen kann - das o, also overlap dial scheint das Problem gewesen zu sein. Nur hatte das mit früheren Versionen funktioniert, und beim Ortsgespräch ebenso. Vielleicht kann Armin dazu eine kurze Erklärung liefern.
 
Zuletzt bearbeitet:
Also zum ersten Problem kann ich nur sagen, dass es eigentlich nicht an chan_capi liegen kann. Der Dialstring wird von Asterisk ausgewertet und der Teil vor dem ersten Komma wird dann an chan_capi weitergegeben. In Deinem Fall scheint hier Übergabestring anders zu sein. Mach doch bitte mal ein log mit 'set verbose 5' und 'capi debug'.

Auch bei zweiten Problem mit 'o', bitte mal ein o.g. Log machen. Es ist zwar eine Änderung bezüglich 'o' im neuen chan_capi: Es wird nun keine Ziffer direkt gewaehlt (vorher wurden die ersten beiden schon weitergegeben), sondern erst die Leitung belegt, early-B3 aktiviert und dann erst alle Ziffern gewählt. So wie es ein normales Telefon macht, wenn man den Hörer abnimmt.
Trotzdem kann ich mir so noch nicht vorstellen, was Dein Problem verusachen kann. Eventuell ist es das gleiche wie oben.

Armin
 
@Armin
Das erste Problem hat, wie du schon vermutest hast, damit zu tun wie * den String übergibt, oder vielmehr mit dem Set Befehl, der es erlaubt durch die Trennzeichen "|" oder "," getrennt, mehrere Variablen zu setzen. Würde ich den String beim Set nicht in ' ' setzen, würde ,30 auch komplett ignoriert. Bei der Übergabe wird die 30 dann nicht abgetrennt, somit ist das geklärt.

Code:
    -- Executing Dial("Zap/2-1", "CAPI/g1/010380711xxxxxxx/bo,30") in new stack
       > data = g1/010380711xxxxxxx/bo,30
       > parsed dialstring: 'g1' '' '010380711xxxxxxx' 'bo,30'
       > capi request group = 2
       > parsed dialstring: 'g1' '' '010380711xxxxxxx' 'bo,30'
Jan  5 08:21:59 WARNING[31757]: chan_capi.c:911 capi_call: Unknown parameter ',' in 'g1/010380711xxxxxxx/bo,10', ignoring.
Jan  5 08:21:59 WARNING[31757]: chan_capi.c:911 capi_call: Unknown parameter '1' in 'g1/010380711xxxxxxx/bo,10', ignoring.
Jan  5 08:21:59 WARNING[31757]: chan_capi.c:911 capi_call: Unknown parameter '0' in 'g1/010380711xxxxxxx/bo,10', ignoring.

Das Problem mit dem Overlap Dial jedoch, lässt sich auch ohne das Makro reproduzieren.
Wenn ich die gleiche Nummer ohne Macro wähle geht das.
Als ich das gestern probierte, war das ohne "bo" und Timeout

Das Problem tritt aber nur mit einem 010nn Prefix bei Ferngesprächen auf, wähle ich die 0711xxxxxx direkt geht es auch mit o, bzw. Ortsgespräche gehen auch mit 010nn.


Code:
    -- Executing Dial("Zap/2-1", "CAPI/g1/010380711xxxxxxx/bo|30") in new stack
       > data = g1/010380711xxxxxxx/bo
       > parsed dialstring: 'g1' '' '010380711xxxxxxx' 'bo'
       > capi request group = 2
       > parsed dialstring: 'g1' '' '010380711xxxxxxx' 'bo'
  == ISDN1: Call CAPI/ISDN1/010380711xxxxxxx-22 with B3 overlap (pres=0x00, ton=0x00)
CONNECT_REQ ID=001 #0x0052 LEN=0049
  Controller/PLCI/NCCI            = 0x1
  CIPValue                        = 0x1
  CalledPartyNumber               = <80>
  CallingPartyNumber              = <00 80>xxxxxxx
  CalledPartySubaddress           = default
  CallingPartySubaddress          = default
  BProtocol
   B1protocol                     = 0x1
   B2protocol                     = 0x1
   B3protocol                     = 0x0
   B1configuration                = default
   B2configuration                = default
   B3configuration                = default
  BC                              = default
  LLC                             = default
  HLC                             = default
  AdditionalInfo
   BChannelinformation            = <00 00>
   Keypadfacility                 = default
   Useruserdata                   = default
   Facilitydataarray              = default

    -- Called g1/010380711xxxxxxx/bo
CONNECT_CONF ID=001 #0x0052 LEN=0014
  Controller/PLCI/NCCI            = 0x101
  Info                            = 0x0

    -- ISDN1: received CONNECT_CONF PLCI = 0x101
INFO_IND ID=001 #0x2d92 LEN=0015
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x800d
  InfoElement                     = default

INFO_RESP ID=001 #0x2d92 LEN=0012
  Controller/PLCI/NCCI            = 0x101

    -- ISDN1: info element SETUP ACK
Jan  5 08:28:52 ERROR[26856]: chan_capi.c:214 _capi_put_cmsg: CAPI error sending INFO_REQ ID=12593 #0x0053 LEN=0035
  Controller/PLCI/NCCI            = 0x101
  CalledPartyNumber               = <80>010380711xxxxxxx
  AdditionalInfo
   BChannelinformation            = default
   Keypadfacility                 = default
   Useruserdata                   = default
   Facilitydataarray              = default
 (NCCI=0x101) (error=0x1101)
INFO_IND ID=001 #0x2d93 LEN=0017
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x1e
  InfoElement                     = <82 88>

INFO_RESP ID=001 #0x2d93 LEN=0012
  Controller/PLCI/NCCI            = 0x101

    -- ISDN1: info element PI 82 88
       > ISDN1: In-band information available
CONNECT_B3_REQ ID=001 #0x0054 LEN=0013
  Controller/PLCI/NCCI            = 0x101
  NCPI                            = default

INFO_IND ID=001 #0x2d94 LEN=0016
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x18
  InfoElement                     = <89>

INFO_RESP ID=001 #0x2d94 LEN=0012
  Controller/PLCI/NCCI            = 0x101

    -- ISDN1: info element CHANNEL IDENTIFICATION 89
    -- CAPI/ISDN1/010380711xxxxxxx-22 is making progress passing it to Zap/2-1
 
Hallo rbaer,

da ist wohl noch ein Fehler im chan_capi. Könntest Du bitte mal folgendes testen:
In der Datei chan_capi.c, ca. in Zeile 500, findest Du folgendes:
/*
* send digits via INFO_REQ
*/
static int capi_send_info_digits(struct capi_pvt *i, char *digits, int len)
{
MESSAGE_EXCHANGE_ERROR error;
_cmsg CMSG;
char buf[16];
int a;

Die vorletzte Zeile
char buf[16];
bitte mal in
char buf[32];
ändern und neu compilieren.

Armin
 
Okay, also das war ein Bug in chan_capi.
Ich habe das nun im neuen chan_capi-cm-0.6.3 korrigiert.

Danke,
Armin
 
Kostenlos!

Statistik des Forums

Themen
247,241
Beiträge
2,264,387
Mitglieder
375,760
Neuestes Mitglied
Thomasbetty