Austria, PTP und Ruf auf Kopfnummer

[pphoenix]

Hallo,

ich habe ein aehnliches Problem wie hier (Ruf von einem Tel ohne Blockwahl an die Kopfnummer):

http://www.ip-phone-forum.de/showthread.php?t=133837

Wenn ich in meiner capi.conf isdnmode auf msn stelle, dann funktioniert der Ruf auf die Kopfnummer und nur auf die Kopfnummer. Konfiguriere ich den isdnmode auf did, funktionieren die Extensions, aber der Ruf auf die Kopfnummer wird nicht von Asterisk beantwortet bzw. nicht von chan_capi an Asterisk uebergeben.

Hier ein Auszug waehrend das Problem auftritt (did):

*CLI> CONNECT_IND ID=002 #0xd5cc LEN=0028
Controller/PLCI/NCCI = 0x101
CIPValue = 0x4
CalledPartyNumber = default
CallingPartyNumber = <00 a3>
CalledPartySubaddress = default
CallingPartySubaddress = default
BC = <90 90 a3>
LLC = default
HLC = default
AdditionalInfo = default

-- CONNECT_IND (PLCI=0x101,DID=,CID=,CIP=0x4,CONTROLLER=0x1)
== ISDN1#02: setting format alaw - 0x8 (alaw)
== ISDN1#02: Incoming call '' -> ''
INFO_IND ID=002 #0xd5cd LEN=0017
Controller/PLCI/NCCI = 0x101
InfoNumber = 0x1e
InfoElement = <82 83>

INFO_RESP ID=002 #0xd5cd LEN=0012
Controller/PLCI/NCCI = 0x101

-- ISDN1#02: info element PI 82 83
> ISDN1#02: Origination is non ISDN
INFO_IND ID=002 #0xd5ce LEN=0016
Controller/PLCI/NCCI = 0x101
InfoNumber = 0x18
InfoElement = <89>

INFO_RESP ID=002 #0xd5ce LEN=0012
Controller/PLCI/NCCI = 0x101

-- ISDN1#02: info element CHANNEL IDENTIFICATION 89
DISCONNECT_IND ID=002 #0xd5cf LEN=0014
Controller/PLCI/NCCI = 0x101
Reason = 0x0

DISCONNECT_RESP ID=002 #0xd5cf LEN=0012
Controller/PLCI/NCCI = 0x101

-- ISDN1#02: DISCONNECT_IND on incoming without pbx, doing hangup.
> CAPI/ISDN1#02/-4: set channel task to 1
== ISDN1#02: CAPI Hangingup for PLCI=0x101 in state 4
== ISDN1#02: Interface cleanup PLCI=0x101
> CAPI devicestate requested for ISDN1#02/

Meine extension.conf:

[pstn_in]
exten => s,1,Set(TIMEOUT(digit)=5)
exten => s,n,WaitExten(3)
exten => s,n,Macro(groupCall,${GROUP_CALL_ISDN})

exten => _X.,1,Macro(intCall,${EXTEN})

Asterisk: 1.4.11, capi-chan-HEAD (von sf.net), AVM B1

capifs: Rev 1.1.2.3
capi20: Rev 1.1.2.7: started up with major 68 (middleware+capifs)
b1pci-bc00: card 1 "B1" ready.
b1pci-bc00: card 1 Protocol: DSS1
b1pci-bc00: card 1 Linetype: point to point
b1pci-bc00: B1-card (3.11-03) now active
kcapi: card 1 "b1pci-bc00" ready.

Ein Unterschied ist mir zu
http://www.ip-phone-forum.de/showthread.php?t=133837
aufgefallen; SETUP kommt bei mir nicht an.

-- ISDN1#02: info element SETUP

Warum es im msn isdnmode funktioniert hat mir die Zeile 3493 in chan_capi.c schnell gezeigt:

if ((i->isdnmode == CAPI_ISDNMODE_MSN) && (i->immediate)) {
/* if we don't want to wait for SETUP/SENDING-COMPLETE in MSN mode */
start_pbx_on_match(i, PLCI, HEADER_MSGNUM(CMSG));
}

-> es wird nicht auf SETUP gewartet.

Liegt es vielleicht an meinem AVM Treiber/ an der AVM Firmware?

Waere sehr dankbar fuer Ideen/Hilfe!

Lg

 

[pphoenix]

Ich habe nun entdeckt, dass es eine spezielle Firmware fur PTP, DID gibt (b1.t4 DDI Variante), leider aendert das absolut nichts. Die AVM Karte ist uebrigens eine V4.

Zur Vervollstaendigung hier noch meine capi.conf:

[general]
nationalprefix=0
internationalprefix=00
rxgain=0.8 ;linear receive gain (1.0 = no change)
txgain=0.8 ;linear transmit gain (1.0 = no change)
language=de ;set default language

[ISDN1] ;this example interface gets name 'ISDN1' and may be any
;name not starting with 'g' or 'contr'.
;Use one interface section for each isdn port!
;ntmode=yes ;if isdn card operates in nt mode, set this to yes
isdnmode=did ;'MSN' (point-to-multipoint) or 'DID' (direct inward dial)
;when using NT-mode, 'DID' should be set in any case
incomingmsn=* ;allow incoming calls to this list of MSNs/DIDs, * = any
;defaultcid=0;set a default caller id to that interface for dial-out,
;this caller id will be used when dial option 'd' is set.
;controller=0 ;ISDN4BSD default
;controller=7 ;ISDN4BSD USB default
controller=1 ;capi controller number of this interface/port
group=1 ;dialout group
;prefix=0 ;set a prefix to calling number on incoming calls
softdtmf=on ;enable/disable software dtmf detection, recommended for AVM cards
relaxdtmf=on ;in addition to softdtmf, you can use relaxed dtmf detection
faxdetect=off ;enable faxdetection and redirection to EXTEN 'fax' for incoming and/or
;outgoing calls. (default='off', possible values: 'incoming','outgoing','both')
accountcode= ;PBX accountcode to use in CDRs
;amaflags=default;AMA flags for CDR ('default', 'omit', 'billing', or 'documentation')
context=pstn_in ;context for incoming calls
;holdtype=hold ;when the PBX puts the call on hold, ISDN HOLD will be used. If
;set to 'local' (default value), no hold is done and the PBX may
;play MOH.
immediate=yes ;DID: immediate start of pbx with extension 's' if no digits were
; received on incoming call (no destination number yet)
;MSN: start pbx on CONNECT_IND and don't wait for SETUP/SENDING-COMPLETE.
; info like REDIRECTINGNUMBER may be lost, but this is necessary for
; drivers/pbx/telco which does not send SETUP or SENDING-COMPLETE.
;echosquelch=1 ;_VERY_PRIMITIVE_ echo suppression
echocancel=yes ;EICON DIVA SERVER (CAPI) echo cancelation (yes=g165)
;(possible values: 'no', 'yes', 'force', 'g164', 'g165')
;echocancelold=yes;use facility selector 6 instead of correct 8 (necessary for older eicon drivers)
;echotail=64 ;echo cancel tail setting (default=0 for maximum)
;echocancelnlp=1 ;activate non-linear-processing; this improves echo cancel ratio, but might
;incorporate variable gain in the signal path.
bridge=yes ;native bridging (CAPI line interconnect) if available
;callgroup=1 ;PBX call group
;pickupgroup=1 ;PBX pickup group (which call groups are we allowed to pickup)
language=de ;set language for this device (overwrites default language)
;disallow=all ;RTP codec selection (valid with Eicon DIVA Server only)
;allow=all ;RTP codec selection (valid with Eicon DIVA Server only)
devices=2 ;number of concurrent calls (b-channels) on this controller

 

[ahaumer]

Hallo!

Ich arbeite momentan an (wie ich vermute) dem selben Problem (siehe http://www.ip-phone-forum.de/showthread.php?t=156042)

Ich benutze jedoch chan_capi mit Eicon Diva Server BRI Karten.

Konntest Du das Problem lösen?

Ich wäre Dir dankbar, wenn Du mir Deine Erfahrungen und den Lösungsweg (falls vorhanden) mitteilen könntest.

Ich habe auch bemerkt, dass Du folgende Zeile im Dialplan benutzt:

exten => s,n,Macro(groupCall,${GROUP_CALL_ISDN})

Was macht das Makro "groupCall"?
Was steht in der Variablen "GROUP_CALL_ISDN"? Wer initialisiert diese Variable bzw. wann wird sie initialisiert?

Danke!

- andreas

 

[mwulz]

Hallo, ich habe ebenfalls das gleiche Problem wie du!
Hast du deinen ISDN Anschluss auf Point-to-Point oder Point-to-Multipoint?

danke
M

 

[ahaumer]

Hallo M,

ich weiß nicht, ob Du Deine Frage an mich gerichtet hast, aber zur Sicherheit: ich betreibe meinen ISDN Anschluss im PTP Modus (Anlagenanschluss)

Eigentlich sind es ja zwei ISDN Basisanschlüsse, die jeweils im PTP Modus geschaltet und an je eine Eicon Diva Server BRI-2M 2.0 PCI geführt sind.

Die /etc/asterisk/capi.conf sieht so aus:

[general]
nationalprefix=0
internationalprefix=00
rxgain=1.0
txgain=1.0
language=de

; Diva Server BRI card for internal S0 Bus
[ISDN1]
ntmode=yes
isdnmode=msn
incomingmsn=*
controller=1     
group=2
softdtmf=on
relaxdtmf=on
faxdetect=off
accountcode=
context=s0intern
immediate=no
echocancel=yes
devices=2 

; First Telekom Austria public ISDN line
[ISDN2]
ntmode=no
isdnmode=did
incomingmsn=*
controller=2
group=1
softdtmf=on
relaxdtmf=on
context=extern
immediate=yes
echocancel=yes
language=de
devices=2

; Second Telekom Austria public ISDN line
[ISDN3]
ntmode=no
isdnmode=did
incomingmsn=*
controller=3
group=1
softdtmf=on
relaxdtmf=on
context=extern
immediate=yes
echocancel=yes
language=de
devices=2

(Anmerkung: ISDN1 ist für einen internen ISDN S0 Bus, die beiden öffentlichen ISDN Basisanschlüsse hängen an ISDN2 und ISDN3)

Mein in http://www.ip-phone-forum.de/showthread.php?t=156042 geschildertes Problem habe ich immer noch, trotz verschiedener Tests mit unterschiedlichen Konfigurationseinstellungen hat sich daran nichts geändert!

Leider habe ich auf meinen Forumbeitrag bis jetzt exakt 0 Rückmeldungen erhalten und ich weiß daher nicht, ob mit den Eicon Diva Server BRI Karten an einem ISDN BA der TK Austria dieses Problem überhaupt in den Griff zu bekommen ist (es gibt zwar einige Beiträge in diesem Forum, die das immerhin vermuten lassen, aber alle diese Beiträge schweigen sich über die konkreten Details der Konfiguration aus oder sind zumindest für mich soweit unklar, dass ich daraus keine funktionierende Konfiguration für meinen Anwendungsfall ableiten kann)

Daher an dieser Stelle nochmals eine Bitte an alle Anwender von Asterisk mit Diva Server Karten an einem ISDN Basisanschluss der Telekom Austria im PTP Modus: konntet Ihr das hierorts bereits so oft geschilderte Problem mit der Direkt-Durchwahl an interne Nebenstellen tatsächlich lösen und falls ja, wie genau habt Ihr das gemacht? Über Rückmeldungen wäre ich sehr dankbar! (Anmerkung: ich kann mir kaum vorstellen, dass eine derartige Grundfunktion mit Asterisk und chan_capi/Diva Server BRI nicht realisierbar ist und kann eigentlich nur von einem Bug in meiner Konfiguration ausgehen. Oder liegt es doch an der Software?)

Danke!

- andreas

 

[armincm]

Den Logs zufolge (z.B. aus 156042) funktioniert chan_capi so wie benötigt.
Das Problem scheint in der Tat vom WaitExten() zu kommen. Hier scheinen die nachfolgenden Digits einfach ignoriert zu werden.
Ich habe versucht das ganze mal zu reproduzieren. Da ich kein solchen PtP Anschluss habe, musste ich es mit einem Port im NT-mode und einem Telefon dahinter testen. Dies sollte identisch sein, denn beim Abheben wird ein Anruf ohne Zielnummer gestartet und die digits kommen dann danach an. Also erst nach 's' und dann WaitExten().
Dies hat bei mir ohne Probleme funktioniert (auch mit Dialogic Diva).
Getestet mit chan_capi trunk rev 583 und Asterisk 1.4.18.

Armin

 

[ahaumer]

Armin, vielen Dank für Deine Rückmeldung!

Eine Frage habe ich aber noch zur Klarstellung: Wenn Du sagst "Dies hat bei mir ohne Probleme funktioniert", was genau meinst Du damit?

Hat bei Dir die WaitExten() Applikation die nachfolgend gewählten Ziffern "empfangen" und wurde danach die aus diesen Ziffern gebildete Durchwahl korrekt angewält?

Falls ja, habe ich wohl immer noch einen Fehler in meiner extensions.conf. Mich würde daher interessieren, wie Du das konfiguriert hast.

Falls nein, scheint WaitExten() für die gegenständliche Aufgabe entweder ungeeignet zu sein oder wir beide haben einen Konfigurationsfehler... ;-)

- andreas

 

[armincm]

Ich meinte damit, dass es funktioniert. WaitExten() arbeitet bei mir einwandfrei. Die nchgwählten Ziffern werden so wie erwartet gesammelt und dann die entsprechende EXTEN im context aufgerufen.

Armin

 

[ahaumer]

Hallo Armin!

> Ich meinte damit, dass es funktioniert. WaitExten() arbeitet bei mir einwandfrei. Die nchgwählten Ziffern werden so wie erwartet gesammelt und dann die entsprechende EXTEN im context aufgerufen.

Aha, ok, dann also Fall 1 (ich habe noch einen Fehler in meiner Konfiguration)

Könntest Du mir bitte die entsprechende Konfiguration in Deiner extensions.conf und, falls möglich, einen Auszug der Asterisk Logmeldungen für diese Anwendung zeigen? Vielleicht hilft mir das, den Fehler in meiner Konfiguration zu finden.

Was mich vor allem interessiert (und wo ich immer noch Verständnisprobleme habe): Wie ist die Ablauffolge bei der Anwendung von WaitExten() ?

Ich habe hier folgende Konfiguration:

; Kontext für Anrufe aus dem öffentlichen Telefonnetz
[extern]
exten => s,1,Set(TIMEOUT(digit)=5)
exten => s,2,WaitExten(5)
exten => 0,1,Macro(siphone,10)   ; Zentrale
include => sipphones 

; Unsere internen SIP Telefone
[siphones]
exten => 10,1,Macro(siphone,${EXTEN})
exten => 11,1,Macro(siphone,${EXTEN}) 
exten => 12,1,Macro(siphone,${EXTEN})

; Macro zur Anwahl eines SIP Telefons
[macro-siphone]
exten => s,1,Dial(SIP/${ARG1},45)
exten => s,n,Goto(s-${DIALSTATUS},1) 
exten => s-NOANSWER,1,VoiceMail(${ARG1},u)  
exten => s-BUSY,1,VoiceMail(${ARG1},b) 
exten => s-ANSWER,1,Hangup() 
exten => _s-.,1,Goto(s-NOANSWER,1)

Was also passiert, wenn Asterisk im Kontext "extern" in der Extension "s" landet?
Meine Vorstellung ist, dass zuerst der Befehl "Set(TIMEOUT(digit)=5)" und dann der Befehl "WaitExten(5)" aufgerufen wird. Nun soll WaitExten() fünf Sekunden lang die nachfolgenden Nummern einsammeln. Was passiert aber, wenn die Wartezeit abgelaufen ist?
Beginnt der Asterisk "Programmzeiger" wieder am Anfang des Kontextes "extern" oder wird die Ausführung mit der nächsten Zeile der "s" Extension fortgesetzt (WaitExten() steht bei mir ja in der letzten Zeile der "s" Extension)?
Wird die von WaitExten() ermittelte Nummer in die Variable $EXTEN oder in eine andere Variable eingetragen?

Die zu "WaitExten()" verfügbare Dokumentation ist leider sehr kurz und lässt diese Fragen unbeantwortet.

Danke!

- andreas

 

[armincm]

Die Feinheiten von WaitExten() sind mir jetzt auch nicht so bekannt, da müsste ich mir mal den Code ansehen. Aber im Grunde mache ich nichts anderes:

exten => s,1,NoOp(${CALLERID})
exten => s,2,Set(TIMEOUT(digit)=4)
exten => s,3,Set(TIMEOUT(response)=4)
exten => s,4,WaitExten(5)
exten => _X.,1,Goto(internal,${EXTEN},1)

Eventuell hat es was mit dem 'include' zu tun. Aber sonst kann ich es mir nicht erklären.

Armin

 

[ahaumer]

Hi!

Ich habe meine Konfiguration jetzt wie folgt geändert:

[extern]
exten => s,1,NoOp(${CALLERID})
exten => s,2,Set(TIMEOUT(digit)=4)
exten => s,3,Set(TIMEOUT(response)=4)
exten => s,4,WaitExten(5)

exten => 0,1,Macro(siphone,10)			; Durchwahl 0 -> Zentrale
exten => 10,1,Macro(siphone,${EXTEN})	
exten => 11,1,Macro(siphone,${EXTEN})	
exten => 12,1,Macro(siphone,${EXTEN})

D.h. ich habe das "include" entfernt und erstmal die SIP-Phone Extensions direkt eingetragen.

Ergebnis: keine Änderung, das Problem existiert immer noch :-(

Hier die Asterisk Logmeldungen mit dieser Konfiguration bei einem Anruf von einem Gerät ohne Blockwahl an die Nummer 10:

    -- CONNECT_IND (PLCI=0x102,DID=,CID=1nnnnnnn,CIP=0x4,CONTROLLER=0x2)
  == ISDN2#02: setting format alaw - 0x8 (alaw)
  == ISDN2#02: Incoming call '01nnnnnnn' -> ''
    -- ISDN2#02: info element PI 80 83
    -- ISDN2#02: info element CHANNEL IDENTIFICATION 89
    -- ISDN2#02: info element SETUP
    -- ISDN2#02: CAPI/ISDN2#02/-17: s matches in context extern for immediate
    -- ISDN2#02: CAPI/ISDN2#02/-17: s matches in context extern
       > CAPI devicestate requested for ISDN2#02/
    -- Executing [s@extern:1] NoOp("CAPI/ISDN2#02/-17", "") in new stack
    -- Executing [s@extern:2] Set("CAPI/ISDN2#02/-17", "TIMEOUT(digit)=4") in new stack
    -- Digit timeout set to 4
    -- Executing [s@extern:3] Set("CAPI/ISDN2#02/-17", "TIMEOUT(response)=4") in new stack
    -- Response timeout set to 4
    -- Executing [s@extern:4] WaitExten("CAPI/ISDN2#02/-17", "5") in new stack
  == Started pbx on channel CAPI/ISDN2#02/-17
    -- ISDN2#02: info element CALLED PARTY NUMBER
    -- ISDN2#02: Updated channel name: CAPI/ISDN2#02/K10-18
    -- CAPI queue frame: [ TYPE: DTMF End (1) SUBCLASS: 1 (49) ] [ISDN2#02]
    -- CAPI queue frame: [ TYPE: DTMF End (1) SUBCLASS: 0 (48) ] [ISDN2#02]
    -- ISDN2#02: info element INFORMATION
[Feb 17 15:11:32] WARNING[29087]: pbx.c:5609 pbx_builtin_waitexten: Timeout but no rule 't' in context 'extern'
  == Spawn extension (extern, s, 4) exited non-zero on 'CAPI/ISDN2#02/K10-18'
  == ISDN2#02: CAPI Hangingup for PLCI=0x102 in state 7
    -- ISDN2#02: activehangingup (cause=0) for PLCI=0x102
       > CAPI devicestate requested for ISDN2#02/K10
    -- ISDN2#02: info element CAUSE 80 90
    -- ISDN2#02: info element RELEASE COMPLETE
       > ISDN2#02: CAPI INFO 0x3490: Normal call clearing

Asterisk läuft also in die Extension "s", ruft "WaitExten(5)" auf, empfängt anscheinend auch die beiden nachgewählten Ziffern "1" und "0", geht dann aber in einen Timeout, anstatt den Kontext "extern" nochmals zu exekutieren und die gewünschte Durchwahl, die als Extension "10" ja nun explizit im Kontext eingetragen ist, aufzurufen.

Der Anrufer bekommt ein paar Sekunden nach dem Wahlvorgang ein BUSY Signal (ich teste das mit einem ELSA MicroLink 28.8TQV Analogmodem, auf das ich Fernzugriff habe):

atdNNNNNNN10
BUSY

Frage an Armin: wie sehen die Asterisk Logmeldungen für diesen Fall bei Dir aus?

 

[armincm]

Frage an Armin: wie sehen die Asterisk Logmeldungen für diesen Fall bei Dir aus?

Bei mir sehen die Meldungen genauso aus, nur dass eben WaitExten nicht in Timeout läuft und entsprechend die richtige EXTEN nutzt.

Ich denke man müsste jetzt mal den Code von WaitExten mit ein paar Debug-Ausgaben versehen.

Armin

 

[ahaumer]

Hi!

Bei mir sehen die Meldungen genauso aus, nur dass eben WaitExten nicht in Timeout läuft und entsprechend die richtige EXTEN nutzt.

ok, danke für die Info.

Ich denke man müsste jetzt mal den Code von WaitExten mit ein paar Debug-Ausgaben versehen.

Das sehe ich schön langsam auch als letzte Möglichkeit... :-(

Mal sehen, ob ich da was machen kann, wird aber wohl etwas dauern.
Ich melde mich wieder, sobald ich was Berichtenswertes rausgefunden habe.

 

[ahaumer]

Ok, hier die versprochene Rückmeldung: ich habe den Fehler gefunden: ein Bug in Asterisk, der mit Version 1.4.15 Ende November 2007 gelöst wurde: Durch den Bug hat WaitExten die nachgewählten Nummern einfach nicht korrekt erkannt!

In http://www.ip-phone-forum.de/showthread.php?t=156042 habe ich eine genauere Beschreibung des Problems und der Lösung verfasst (nur für den Fall, dass ein fellow Austrian nochmal so ein Problem hat... ;-)

Danke an Armin: sein Hinweis, dass es bei ihm mit der gleichen Konfiguration, aber einer anderen Asterisk-Version ohne Probleme funktioniert, hat mich dazu gebracht, Asterisk und WaitExten näher unter die Lupe zu nehmen und so bin ich dann auch auf den ChangeLog Eintrag gestoßen...