chan_capi-cm-0.6.3 Probleme mit Wahl Hicom Anlagenfunktionen

telchef

Neuer User
Mitglied seit
17 Dez 2005
Beiträge
112
Punkte für Reaktionen
0
Punkte
0
Hallo!

Ich glaube, ich benötige in chan_capi-cm eine Möglichkeit, eine Art Pause innerhalb einer Wahl einzufügen.

Ich möchte z.B. die TK-Anlagenfunktion der Siemens Hicom "Assoziierte Wahl" nutzen. (Das bedeutet, daß ich von einem fremden Telefon aus, für den Apparat eines Kollegen die Wahl auf dessen Telefon auslöse, Fernsteuerung seines Telefons also.)
Dazu wähle ich normalerweise *67 <Kollegenapparat> <Zielapparat>; z.B. *671112, damit wähle ich für den Apparat 11 den Zielapparat 12.

Das geht auch grundsätzlich über einen internen ISDN-Apparat, nur muß ich dort für den Stern die Ersatzziffernfolge 75 wählen, also 75671112.

Allerdings darf ich das nicht per Blockwahl machen, dann klappt es nicht.
Ich brauche offenbar eine Pause nach der Kennziffer der Anlagenfunktion, also 7567<Pause>1112.

Wenn ich manuell von einem SIP-Telefon aus wähle, klappt das auch, wenn ich zuerst die 7567 als Blockwahl schicke, und dann erst die weiteren Ziffern nachwähle. (Da wird das Dial-Kommando dann erst mit 7567 benutzt, die weiteren Ziffern gehen als Art Nachwahl als CAPI-"INFO Digit" an die TK-Anlage.)

Das hilft mir natürlich nicht für automatische Wahlregeln.


Hier mal ein Debug-Log von einer nicht funktionierenden Blockwahl:

Code:
    -- Executing Dial("SIP/user1-a942", "CAPI/g1/501:75671112/b|20") in new stack
    -- Called g1/501:75671112/b
    -- CAPI/ISDN1/75671112-6 is making progress passing it to SIP/user1-a942
       > CAPI INFO 0x349c: Invalid number format
  == ISDN1: CAPI Hangingup
  == Everyone is busy/congested at this time (1:0/0/1)
    -- Executing Hangup("SIP/user1-a942", "") in new stack
  == Spawn extension (sip2intern, 75671112, 2) exited non-zero on 'SIP/user1-a942'

Und hier mal ein Debug-Log von einer erfolgreichen manuellen Wahl mit "Pause":

Code:
    -- Executing Dial("SIP/user1-147f", "CAPI/g1/501:7567/b|20") in new stack
    -- Called g1/501:7567/b
    -- CAPI/ISDN1/7567-1 is making progress passing it to SIP/user1-147f
    -- ISDN1: Updated channel name: CAPI/ISDN1/75671-2
    -- ISDN1: Updated channel name: CAPI/ISDN1/756711-3
    -- ISDN1: Updated channel name: CAPI/ISDN1/7567111-4
    -- ISDN1: Updated channel name: CAPI/ISDN1/75671112-5
    -- CAPI/ISDN1/75671112-5 is proceeding passing it to SIP/user1-147f
    -- CAPI/ISDN1/75671112-5 is ringing
[usw...]

Vermutlich fehlt eine Pause-Funktion in chan_capi-cm-0.6.4. (Auch mit 0.6.3 fand ich keine Lösung / hatte ich den gleichen Effekt.)

Overlap Sending hilft mir auch nicht, das scheint die Hicom gleich abzulehnen ("Invalid number format", und am SIP-Telefon ist gleich ein Besetzt zu hören.)

Asterisk 1.2.3, FRITZ!Card PCI mit aktuellen AVM-Linux-Treibern

Gruß, Harald
 
Also CAPI dialparameter /bo funktioniert nicht?
Ein Log hiervon waere nich schlecht. chan_capi selbst hat keine wartefunktion, aber
das ist auch nicht noetig. Da chan_capi nur das macht, was asterisk sagt, kann man
das sicher mit dialplan relegeln loesen. Z.B. mit der M Funktion im Dial...

Armin
 
Hallo Armin!

Danke für Deine Antwort!

armincm schrieb:
Also CAPI dialparameter /bo funktioniert nicht?
Ein Log hiervon waere nich schlecht.

Hier mal ein Log mit /bo (nicht erfolgreich):
SIP-user1 ruft über CAPI (MSN 501) den Teilnehmer 11 der TK-Anlage.

Code:
    -- Executing Dial("SIP/user1-59b0", "CAPI/g1/501:11/bo|20") in new stack
       > data = g1/501:11/bo
       > parsed dialstring: 'g1' '501' '11' 'bo'
       > capi request group = 2
       > parsed dialstring: 'g1' '501' '11' 'bo'
  == ISDN1: Call CAPI/ISDN1/11-9 with B3 overlap (pres=0x00, ton=0x00)
CONNECT_REQ ID=001 #0x0016 LEN=0044
  Controller/PLCI/NCCI            = 0x1
  CIPValue                        = 0x1
  CalledPartyNumber               = <80>
  CallingPartyNumber              = <00 80>501
  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

CONNECT_CONF ID=001 #0x0016 LEN=0014
  Controller/PLCI/NCCI            = 0x101
  Info                            = 0x0

    -- ISDN1: received CONNECT_CONF PLCI = 0x101
       > CAPI devicestate requested for ISDN1/11
    -- Called g1/501:11/bo
       > CAPI devicestate requested for ISDN1/11
INFO_IND ID=001 #0x4ec0 LEN=0017
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x8
  InfoElement                     = <81 9c>

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

    -- ISDN1: info element CAUSE 81 9c
DISCONNECT_IND ID=001 #0x4ec1 LEN=0014
  Controller/PLCI/NCCI            = 0x101
  Reason                          = 0x349c

DISCONNECT_RESP ID=001 #0x4ec1 LEN=0012
  Controller/PLCI/NCCI            = 0x101

       > CAPI INFO 0x349c: Invalid number format
  == ISDN1: CAPI Hangingup
       > CAPI devicestate requested for ISDN1/11
  == ISDN1: Interface cleanup PLCI=0x101
  == Everyone is busy/congested at this time (1:0/0/1)
    -- Executing Hangup("SIP/user1-59b0", "") in new stack
  == Spawn extension (sip-in, 11, 2) exited non-zero on 'SIP/user1-59b0'
       > CAPI devicestate requested for ISDN1/11

Zum Vergleich der erfolgreiche gleiche Versuch mit nur /b:

Code:
    -- Executing Dial("SIP/user1-00d0", "CAPI/g1/501:11/b|20") in new stack
       > data = g1/501:11/b
       > parsed dialstring: 'g1' '501' '11' 'b'
       > capi request group = 2
       > parsed dialstring: 'g1' '501' '11' 'b'
  == ISDN1: Call CAPI/ISDN1/11-1 with B3  (pres=0x00, ton=0x00)
CONNECT_REQ ID=001 #0x0007 LEN=0046
  Controller/PLCI/NCCI            = 0x1
  CIPValue                        = 0x1
  CalledPartyNumber               = <80>11
  CallingPartyNumber              = <00 80>501
  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

CONNECT_CONF ID=001 #0x0007 LEN=0014
  Controller/PLCI/NCCI            = 0x101
  Info                            = 0x0

    -- ISDN1: received CONNECT_CONF PLCI = 0x101
    -- Called g1/501:11/b
       > CAPI devicestate requested for ISDN1/11
       > CAPI devicestate requested for ISDN1/11
INFO_IND ID=001 #0x5031 LEN=0015
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x800d
  InfoElement                     = default

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

    -- ISDN1: info element SETUP ACK
INFO_IND ID=001 #0x5032 LEN=0017
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x1e
  InfoElement                     = <81 88>

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

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

    -- ISDN1: sent CONNECT_B3_REQ PLCI=0x101
INFO_IND ID=001 #0x5033 LEN=0016
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x18
  InfoElement                     = <8a>

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

    -- ISDN1: info element CHANNEL IDENTIFICATION 8a
CONNECT_B3_CONF ID=001 #0x0008 LEN=0014
  Controller/PLCI/NCCI            = 0x10101
  Info                            = 0x0

CONNECT_B3_ACTIVE_IND ID=001 #0x5034 LEN=0013
  Controller/PLCI/NCCI            = 0x10101
  NCPI                            = default

CONNECT_B3_ACTIVE_RESP ID=001 #0x5034 LEN=0012
  Controller/PLCI/NCCI            = 0x10101

    -- CAPI/ISDN1/11-1 is making progress passing it to SIP/user1-00d0
INFO_IND ID=001 #0x5035 LEN=0015
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x8002
  InfoElement                     = default

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

    -- ISDN1: info element CALL PROCEEDING
    -- CAPI/ISDN1/11-1 is proceeding passing it to SIP/user1-00d0
INFO_IND ID=001 #0x5041 LEN=0015
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x8001
  InfoElement                     = default

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

    -- ISDN1: info element ALERTING
INFO_IND ID=001 #0x5042 LEN=0019
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x76
  InfoElement                     = <00 83>68

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

    -- ISDN1: unhandled INFO_IND 0x76 (PLCI=0x101)
    -- CAPI/ISDN1/11-1 is ringing

[usw...]

armincm schrieb:
chan_capi selbst hat keine wartefunktion, aber
das ist auch nicht noetig. Da chan_capi nur das macht, was asterisk sagt, kann man das sicher mit dialplan relegeln loesen. Z.B. mit der M Funktion im Dial...

Das ist sehr schade!


Die M()-Funktion wird ja erst ausgeführt, wenn die angerufene Gegenstelle "geantwortet" hat, aber vor dem Bridging [Verbinden] (was immer das exakt heißt).
Es scheint jedoch so, als ob diese "Antwort" bei Nutzung der Hicom-Funktionen nicht erreicht wird, daher M(...) auch nicht ausgeführt wird.

Wenn M(...) ausgeführt werden würde, könnte ich mit SetDTMF(...) Töne senden, das will ich aber gar nicht bzw. ist auch nicht angesagt, da sich Asterisk wohl noch im rufenden Zustand befindet, wo ich nun noch ein paar Nummern per D-Kanal nachwählen sollte (s. Log vom Originalpost, wo ich das manuell mit meinem SIP-Telefon auslöse -> "Updated channel name..." für jede weitere Ziffer).

Leider weiß/finde ich nicht, wie ich mit Asterisk im gerufenen Channel noch per D-Kanal "nachwählen" kann.


Gruß, Harald

P.S. Leider finde ich nirgends eine taugliche Übersetzung: Was ist dieses "overlap sending" eigentlich genau? Ist das das Gegenteil von "Blockwahl", also "Einzelziffernwahl" oder "fortschreitende Wahl", habe ich das richtig interpretiert? Mit der direkten Übersetzung "überlappendes/überschneidendes Senden" kann man ja wenig anfangen, es sei denn, es ergibt sich aus der Technik wirklich ein Sinn.
 
Zuletzt bearbeitet:
Also das ist dann die erste Anlage die kein Overlap dial machen kann. Dann wuerde
Dial(CAPI/contr1//b) also auch nicht funktionieren um den Dialtone zu bekommen? Und ein ISDN Telefon wuerde auch kein Dialtone beim Abheben bekommen...

Overlap ist das Gegenteil zur Blockwahl also eigentlich genau das was du brauchst.

Stimmt, M() hilft hier nicht. Aber hat Asterisk nicht auch eine Moeglichkeit mit 'warten' und weiterwaehlen? Oder war das nur ein anderer channel-Treiber?
Da sowas eine globale Funktion ist, waere es schon bloed wenn jeder channel-Treiber das selbst nochmal implementieren wuerde.

Armin
 
Hallo Armin!

armincm schrieb:
Also das ist dann die erste Anlage die kein Overlap dial machen kann. Dann wuerde
Dial(CAPI/contr1//b) also auch nicht funktionieren um den Dialtone zu bekommen?

Es ist eine "SIEMENS Hicom 150 H, Firmware 1.2" von etwa 2001. Wenig später wurden die als "SIEMENS HiPath 3550" vermarktet. (Also nicht gerade ein Hotten-Totten-Modell, oder doch?)

Richtig: "Dial(CAPI/contr1//b)" geht nicht:
(Hier wird allerdings der SIP-User "user1" als Calling Party benutzt. Ein "Dial(CAPI/contr1/501:/b)" geht aber ganauso nicht.)

Code:
   -- Executing Dial("SIP/user1-eefb", "CAPI/contr1//b|20") in new stack
       > data = contr1//b
       > parsed dialstring: 'contr1' 'NULL' '' 'b'
       > capi request controller = 1
       > parsed dialstring: 'contr1' 'NULL' '' 'b'
  == ISDN1: Call CAPI/ISDN1/-3 with B3  (pres=0x00, ton=0x00)
CONNECT_REQ ID=001 #0x0006 LEN=0046
  Controller/PLCI/NCCI            = 0x1
  CIPValue                        = 0x1
  CalledPartyNumber               = <80>
  CallingPartyNumber              = <00 80>user1
  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

CONNECT_CONF ID=001 #0x0006 LEN=0014
  Controller/PLCI/NCCI            = 0x101
  Info                            = 0x0

    -- ISDN1: received CONNECT_CONF PLCI = 0x101
    -- Called contr1//b
       > CAPI devicestate requested for ISDN1/
       > CAPI devicestate requested for ISDN1/
INFO_IND ID=001 #0x5204 LEN=0017
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x8
  InfoElement                     = <81 9c>

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

    -- ISDN1: info element CAUSE 81 9c
DISCONNECT_IND ID=001 #0x5205 LEN=0014
  Controller/PLCI/NCCI            = 0x101
  Reason                          = 0x349c

DISCONNECT_RESP ID=001 #0x5205 LEN=0012
  Controller/PLCI/NCCI            = 0x101

       > CAPI INFO 0x349c: Invalid number format
  == ISDN1: CAPI Hangingup
       > CAPI devicestate requested for ISDN1/
  == ISDN1: Interface cleanup PLCI=0x101
  == Everyone is busy/congested at this time (1:0/0/1)
  == Auto fallthrough, channel 'SIP/user1-eefb' status is 'CHANUNAVAIL'
       > CAPI devicestate requested for ISDN1/


armincm schrieb:
Und ein ISDN Telefon wuerde auch kein Dialtone beim Abheben bekommen...

Kann ich momentan nicht sagen. Würde ich aber für sehr unwahrscheinlich halten.

armincm schrieb:
Overlap ist das Gegenteil zur Blockwahl also eigentlich genau das was du brauchst.

Lag ich also richtig, danke!
Wäre vermutlich die 2. Möglichkeit, mit der ich weiterkäme. Hatte ich schon vermutet.

Die 1. Möglichkeit scheint Asterisk zu können, leider wiß ich nicht, wie ich sie durch Wahlregeln hinbekomme, schaffte ich bisher nur manuell mit SIP-Telefon:

In dem Log meines Originalposts sieht man es:

Zunächst wähle ich die Ziffernfolge der Anlagenfunktion "7567" per Blockwahl
-> Executing Dial("SIP/user1-147f", "CAPI/g1/501:7567/b|20"),
dann, nachdem wohl schon mit dem SIP-Telefon verbunden wurde
-> CAPI/ISDN1/7567-1 is making progress passing it to SIP/user1-147f,
irgendwie die nächsten Ziffern ("1", "1", ...) einzeln weiter
-> ISDN1: Updated channel name: CAPI/ISDN1/75671-2
-> ISDN1: Updated channel name: CAPI/ISDN1/756711-3
-> ...

Per DTMF geht das nicht, jedenfalls nicht über CAPI zur TK-Anlage, sonst würde Asterisk hier nicht den "Channel updaten", sondern die DTMF-Töne transparent über den B-Kanal zur TK-Anlage leiten.

armincm schrieb:
Stimmt, M() hilft hier nicht. Aber hat Asterisk nicht auch eine Moeglichkeit mit 'warten' und weiterwaehlen? Oder war das nur ein anderer channel-Treiber?
Da sowas eine globale Funktion ist, waere es schon bloed wenn jeder channel-Treiber das selbst nochmal implementieren wuerde.

Ich habe zumindest bisher in Asterisk so eine Funktion nicht gefunden.

Ansonsten habe ich Beiträge gefunden, nach denen es so aussieht, als ob die Pause-Möglichkeit im Channel-Treiber steckt, wenn ich das richtig interpretiert habe, z.B. hier beim "ZAPTEL" (?):

http://groups.google.com/group/Aste...df24?lnk=st&q=asterisk+zap+pause&rnum=2&hl=de
http://groups.google.com/group/Aste...erisk+zap+pause&rnum=1&hl=de#4a4a7bb0dba63e4d
http://www.marko.net/asterisk/archives/0203/0033.html


Gruß, Harald
 
Die Pause bei zaptel macht meiner Meinung nach nur bei analogen Anschluessen Sinn, aber nicht bei ISDN. Hier ist Overlap dial einfach wichtig.
Ich denke, dass es bei Dir funktionieren wuerde, wenn overlap klappt.
Eventuell mag die Anlage nur ein paar Einstellungen nicht.
Dial(CAPI/contr1//b) sollte grundsaetzlich einen Dialtone bringen, denn das ist
genau das gleiche beim abheben des Hoerer eines ISDN Telefons.
Ich rate dir dies mal mit verschiedenen Einstellungen (eigene Nummer, _CALLERTON, etc) zu testen. Wenn das mal klappt, dann geht so auch overlap.

Armin
 
Hallo Armin!

Danke für Deine neuerliche Antwort!

(Man, ist das verflixt! Schon Tage verbringe ich mit dem Mist. SIEMENS konnte mir auch nicht richtig weiterhelfen. Es hieß nur etwa "fortschreitende Wahl klappt am internen S0".)

armincm schrieb:
Die Pause bei zaptel macht meiner Meinung nach nur bei analogen Anschluessen Sinn, aber nicht bei ISDN. Hier ist Overlap dial einfach wichtig.

Ach, dieser "ZAPTEL" ist ein Treiber für einen analogen Channel? Kann sein.
Ja, dann hört es sich sinnig an, was Du sagst.


armincm schrieb:
Ich denke, dass es bei Dir funktionieren wuerde, wenn overlap klappt.
Eventuell mag die Anlage nur ein paar Einstellungen nicht.
Dial(CAPI/contr1//b) sollte grundsaetzlich einen Dialtone bringen, denn das ist
genau das gleiche beim abheben des Hoerer eines ISDN Telefons.

Ich glaube, ich habe hier das Problem entdeckt:

Es scheint eine Spezialität der Hicom zu sein, daß man mit einem ISDN-Telefon nicht einfach abheben kann, sondern mindestens 1 Ziffer in Blockwahl vor dem Abheben gewählt haben muß.
(Ich glaube sogar, daß ich vor 5 Jahren schonmal in das gleiche Problem gerannt bin, an einer anderen Hicom-Anlage.)


"Dial(CAPI/contr1/501:/b)" bringt also keinen "Wählton" hervor, wie im obigen Log schon zu sehen war.


"Dial(CAPI/contr1/501:0/b)" bringt aber einen! Holt mir in diesem Fall ein Amt, und ich kann z.B. die 0310 in Einzelziffern nachwählen (s. Log unten).
Asterisk scheint das mit "CALLEDPARTYNUMBER INFO digits" (s. Log: > ISDN1: sent CALLEDPARTYNUMBER INFO digits = '0' (PLCI=0x101)) zu machen.

Nur weiß ich nicht, wie ich die dem Executing Dial("SIP/user1-bd24", "CAPI/contr1/501:0/b|20") nachzuwählenden "CALLEDPARTYNUMBER INFO digits" von Asterisk im Wählplan erzeugen kann.

Weißt Du, was diese "CALLEDPARTYNUMBER INFO digits" genau sind? Offenbar ja Ziffern (digits), welche zur angerufenen Nummer (CALLEDPARTYNUMBER) gehören. Sind das "overlap" gewählte Ziffern? Kann man das daran eindeutig erkennen? (Oder ist das noch irgendeine andere Technik?)


"Dial(CAPI/contr1/501:1/b)" klappt auch, wählt also die erste Ziffer "1" eines Internteilnehmers, die zweite Ziffer kann ich dann nachwählen.


armincm schrieb:
Ich rate dir dies mal mit verschiedenen Einstellungen (eigene Nummer, _CALLERTON, etc) zu testen. Wenn das mal klappt, dann geht so auch overlap.

Verstehe nicht genau, was Du hier meinst.
"Eigene Nummer" habe ich ja bereits benutzt -> 501: ("Dial(CAPI/contr1/501:/b)"). Das klappte, wie gesagt, auch nicht. Meinst Du das?
"_CALLERTON": muß ich erst kennenlernen.
"etc.": suche ich sowieso schon seit Tagen. ;-)


Log einer Blockwahl 501:0, dann 0 3 1 0 nachgewählt:

Code:
    -- Executing Dial("SIP/user1-bd24", "CAPI/contr1/501:0/b|20") in new stack
        > data = contr1/501:0/b
        > parsed dialstring: 'contr1' '501' '0' 'b'
        > capi request controller = 1
        > parsed dialstring: 'contr1' '501' '0' 'b'
   == ISDN1: Call CAPI/ISDN1/0-9 with B3  (pres=0x00, ton=0x00)
 CONNECT_REQ ID=001 #0x0012 LEN=0045
  Controller/PLCI/NCCI            = 0x1
  CIPValue                        = 0x1
  CalledPartyNumber               = <80>0
  CallingPartyNumber              = <00 80>501
  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

 CONNECT_CONF ID=001 #0x0012 LEN=0014
  Controller/PLCI/NCCI            = 0x101
  Info                            = 0x0

     -- ISDN1: received CONNECT_CONF PLCI = 0x101
     -- Called contr1/501:0/b
        > CAPI devicestate requested for ISDN1/0
        > CAPI devicestate requested for ISDN1/0
 INFO_IND ID=001 #0xe60f LEN=0015
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x800d
  InfoElement                     = default

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

     -- ISDN1: info element SETUP ACK
 INFO_IND ID=001 #0xe610 LEN=0017
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x1e
  InfoElement                     = <81 88>

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

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

     -- ISDN1: sent CONNECT_B3_REQ PLCI=0x101
 INFO_IND ID=001 #0xe611 LEN=0016
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x18
  InfoElement                     = <8a>

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

     -- ISDN1: info element CHANNEL IDENTIFICATION 8a
  CONNECT_B3_CONF ID=001 #0x0013 LEN=0014
  Controller/PLCI/NCCI            = 0x10101
  Info                            = 0x0

 CONNECT_B3_ACTIVE_IND ID=001 #0xe612 LEN=0013
  Controller/PLCI/NCCI            = 0x10101
  NCPI                            = default

 CONNECT_B3_ACTIVE_RESP ID=001 #0xe612 LEN=0012
  Controller/PLCI/NCCI            = 0x10101

     -- CAPI/ISDN1/0-9 is making progress passing it to SIP/user1-bd24
 
[b](***hier wähle ich die "0" der "0310" manuell nach***)[/b]

     -- ISDN1: Updated channel name: CAPI/ISDN1/00-a
 INFO_REQ ID=001 #0x0014 LEN=0020
  Controller/PLCI/NCCI            = 0x101
  CalledPartyNumber               = <80>0
  AdditionalInfo                 
   BChannelinformation            = default
   Keypadfacility                 = default
   Useruserdata                   = default
   Facilitydataarray              = default

 INFO_CONF ID=001 #0x0014 LEN=0014
  Controller/PLCI/NCCI            = 0x101
  Info                            = 0x0

        > ISDN1: sent CALLEDPARTYNUMBER INFO digits = '0' (PLCI=0x101)

[b](***hier wähle ich die "3" der "0310" manuell nach***)[/b]

     -- ISDN1: Updated channel name: CAPI/ISDN1/003-b
 INFO_REQ ID=001 #0x0015 LEN=0020
  Controller/PLCI/NCCI            = 0x101
  CalledPartyNumber               = <80>3
  AdditionalInfo                 
   BChannelinformation            = default
   Keypadfacility                 = default
   Useruserdata                   = default
   Facilitydataarray              = default

 INFO_CONF ID=001 #0x0015 LEN=0014
  Controller/PLCI/NCCI            = 0x101
  Info                            = 0x0

        > ISDN1: sent CALLEDPARTYNUMBER INFO digits = '3' (PLCI=0x101)

[b](***hier wähle ich die "1" der "0310" manuell nach***)[/b]

     -- ISDN1: Updated channel name: CAPI/ISDN1/0031-c
 INFO_REQ ID=001 #0x0016 LEN=0020
  Controller/PLCI/NCCI            = 0x101
  CalledPartyNumber               = <80>1
  AdditionalInfo                 
   BChannelinformation            = default
   Keypadfacility                 = default
   Useruserdata                   = default
   Facilitydataarray              = default

 INFO_CONF ID=001 #0x0016 LEN=0014
  Controller/PLCI/NCCI            = 0x101
  Info                            = 0x0

        > ISDN1: sent CALLEDPARTYNUMBER INFO digits = '1' (PLCI=0x101)

[b](***hier wähle ich die "0" der "0310" manuell nach***)[/b]

     -- ISDN1: Updated channel name: CAPI/ISDN1/00310-d
 INFO_REQ ID=001 #0x0017 LEN=0020
  Controller/PLCI/NCCI            = 0x101
  CalledPartyNumber               = <80>0
  AdditionalInfo                 
   BChannelinformation            = default
   Keypadfacility                 = default
   Useruserdata                   = default
   Facilitydataarray              = default

 INFO_CONF ID=001 #0x0017 LEN=0014
  Controller/PLCI/NCCI            = 0x101
  Info                            = 0x0

        > ISDN1: sent CALLEDPARTYNUMBER INFO digits = '0' (PLCI=0x101)
 INFO_IND ID=001 #0xe7f0 LEN=0015
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x8002
  InfoElement                     = default

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

     -- ISDN1: info element CALL PROCEEDING
     -- CAPI/ISDN1/00310-d is proceeding passing it to SIP/user1-bd24

[b](***hier etwa höre ich die Netzansage***)
(der Rest dürfte uninteressant sein: weggelassen)[/b]

Danke, Harald
 
Die Variable _CALLERTON ist der 'type of number' Wert. Dies wird bei eingehenden Anrufen gesetzt und abgehend entsprechend benutzt. Dieser Wert is nach Q.931 definiert und ist einer beiden Werte, die vor der Nummer im debug log angezeigt werden. Hier wird z.B. national/international number festgelegt.

"CALLEDPARTYNUMBER INFO digits" sind Ziffern die per overlap-dial ueber den D-Kanal gesendet/empfangen werden, wenn noch keine Verbindung besteht.

Armin
 
Hi Armin!

armincm schrieb:
"CALLEDPARTYNUMBER INFO digits" sind Ziffern die per overlap-dial ueber den D-Kanal gesendet/empfangen werden, wenn noch keine Verbindung besteht.

Damit können wir uns dann ja sicher sein, daß die Hicom "overlap dialing" beherrscht.

Nur eben erst ab der zweiten Ziffer.

Hintergrund könnte die Bedienphilosophie der SIMENSisaner sein. Hier wird immer zuerst eine "Richtung" (ein Amt) mit Hilfe einer Richtungskennziffer (üblicherweise "0") gewählt.

Man kann die Anlage offenbar auch so umstellen, daß für Internanrufe eine Taste "Intern" vorgewählt werden muß, trodzdem jedoch ist auch für Amtsgespräche eine Richtungskennziffer zu wählen.

Eine Umstellung auf "Spontane Amtsholung" bzw. "Automatische Amtsholung", wie man sie von niedrigpreisigeren TK-Anlagen kennt, scheint gar nicht vorgesehen zu sein. EDIT: Wohl doch möglich, jedoch nur unter speziellen Bedingungen, also nicht bei jeder Konfiguration.

Soviel also zum Thema "immer mindestens eine Ziffer zur Richtungsauswahl nötig".

Das ganze ist zwar auch ärgerlich, jedoch weiß ich so immerhin, daß "overlaped dialing" möglich ist.


Von meinem Problem bleibt also der Kern übrig, daß ich nicht herausfinde, wie ich nach einem exten => _7567.,1,Dial(CAPI/contr1/${EXTEN:0:4}/b,10), der die ersten 4 Ziffern ("7567") der Anlagen-Funktion per Blockwahl wählt, noch die weiteren Ziffern ${EXTEN:4} an dem selben Channel, der sich im Rufaufbau befindet, nachwählen kann.

Vielleicht liest ja nochmal ein anderer Asterisk-Spezialist mit?



armincm schrieb:
Die Variable _CALLERTON ist der 'type of number' Wert. Dies wird bei eingehenden Anrufen gesetzt und abgehend entsprechend benutzt. Dieser Wert is nach Q.931 definiert und ist einer beiden Werte, die vor der Nummer im debug log angezeigt werden. Hier wird z.B. national/international number festgelegt.

Ich denke, daß das Experimentieren damit nach den Erkenntnissen nun nicht mehr nötig ist, weil es nicht das spezielle Problem der Hicom ("overlap dialing erst nach erster Ziffer möglich") adressiert. Trotzdem danke für die Idee!


Gruß, Harald
 
Zuletzt bearbeitet:
Hallo Armin!

armincm schrieb:
"CALLEDPARTYNUMBER INFO digits" sind Ziffern die per overlap-dial ueber den D-Kanal gesendet/empfangen werden, wenn noch keine Verbindung besteht.

Weiterhin mein Hauptproblem:

Offenbar kann ja Asterisk, wenn es von einem SIP-Telefon aus einen Ruf auf ein chan_capi-cm-Channel aufbaut, nach dem erfolgreichen "Dial(CAPI/contr1/501:12345/b)" während der Rufphase noch weitere Ziffern "6789" out-of-band/overlapped nachwählen ("CALLEDPARTYNUMBER INFO digits"), die vom SIP-Telefon nach der 123456 (vermutlich) per DTMF an Asterisk gegeben wurden, und Asterisk also offenbar den chan_capi-cm-Channel damit mit D-Kanal-"digits" ändert ("updated channel name"). Wüßte nicht, wie die AVM FBF (= das SIP-Telefon dieses Testfalls) die nachgewählten Ziffern sonst per SIP an den Asterisk gibt (DTMFMODE=rfc2833).

Wie funktioniert das!? Macht das die Dial-Application/-Funktion alleine?
Hat man da sonst keinen Zugriff per separatem Asterisk-Kommando drauf?

Muß ja irgendwie gehen, und es ist ja auch im Dial kein /bo angegeben, und trotzdem kann nachgewählt werden!

Damit ich mal suchen kann, ob und wie ich das per extension.conf auch automatisch hinbekomme - nicht nur über die SIP-Telefon-DTMF-Wahl in den Rufaufbau des chapi_chan-cm-Channel.


Danke, Harald
 
Zuletzt bearbeitet:
Also dass man per DTMF nach der eigentlichen Wahl noch Ziffern nachwaehlt, geht ja mit jedem Device, das geht auch ueber CAPI. Aber Dein Problem ist ja, dass du es nicht vom SIP Telefon aus selbst machen willst, sondern automatisch per dialplan.

Wenn chan_capi den Befehl 'send_digit' von Asterisk bekommt, dann tut es das per DTMF falls die Verbindung schon besteht, ansonsten wird es als overlap INFO gesendet und der channel-name korrigiert.
D.h. wenn Dial() aufgerufen wurde und Seite A digits sendet, dann werden die von Dial() weitergereicht und bei chan_capi an B gesendet.

Falls Asterisk fuer deinen Fall (Anlage kann kein initiales overlap) keine Moeglickeit bietet eine Nachwahl zu machen (hast du schon mal in der Asterisk mailingliste gefragt?), dann bleibt nur noch Asterisk oder chan_capi zu patchen.

Armin
 
Hallo Armin!

Nochmals danke, Deine Antwort ist der Hinweis, den ich brauchte, um die weitere Vorgehensweise entscheiden zu können (die "Channel-Steuerfunktion" 'send_digit').
(Jetzt habe ich mich schon deutlich viel mehr Stunden, nein _Tage_, insgesamt mit der Sache beschäftigt, langsam geht mit der Schwung aus. Vor allem, da es ja nur Spielerei ist, d.h. damit niemals ein Return zu erreichen sein wird.)

armincm schrieb:
Falls Asterisk fuer deinen Fall (Anlage kann kein initiales overlap) keine Moeglickeit bietet eine Nachwahl zu machen (hast du schon mal in der Asterisk mailingliste gefragt?), dann bleibt nur noch Asterisk oder chan_capi zu patchen.

So muß ich also einen Weg finden, Asterisk 'send digit' per Dialplan senden zu lassen, weil Asterisk offenbar keine Möglichkeit dazu bietet.

Am sinnvollsten erscheint mir, Asterisk zu patchen; ich stelle mir eine Alternative der im 'Dial()'-Kommando möglichen 'D()'-Option vor, die dann eben schon wählen kann, bevor der Anruf beantwortet wurde. Ich werde mal in die Richtung arbeiten.

Ein Patchen der chan_capi-cm für "kein initiales Overlap" erscheint mir komplizierter, hatte schonmal im Quelltext ein wenig gesucht.


Nein, in asterisk-users hatte ich noch nicht gefragt, allerdings schon viel gesucht.

Nebenbei: Hatte in der SIEMENS Hicom 150 H schonmal versucht, die Automatische Amtsholung (dort genannt "Automatische Leitungsbelegung", auch nur für alle möglich, nicht für einzelne Nebenstellen) für Tests zu aktivieren, was mir leider nicht gelang, um mal zu sehen, ob /bo dann wenigstens funktioniert. (Vermutlich geht die Automatische Leitungsbelegung nicht für ISDN-Nebenstellen.)


Gruß, Harald
 
Hallo Armin!

armincm schrieb:
Wenn chan_capi den Befehl 'send_digit' von Asterisk bekommt,

So, jetzt habe ich mal die Dial()-Applikation im Asterisk 1.2.4 grob gepatcht, und lasse das Argument meiner neuen Dial()-Option "E(${EXTEN:4})" zunächst mal kurz vor der Dial()-Funktion wait_for_answer() ausführen.

Es klappt so schonmal, aber: Dabei stellte ich fest, daß ggf. nach Wahl der SIEMENS Kennziffern (67) und der Amtsholung/Richtungsauswahl (0) Pausen benötigt werden, sonst klappt's nicht. Das habe ich erstmal mit einem ollen sleep(1) eingefügt.


Also ich möchte ja wählen:
75 67 11 12 (für NSt. 11 die 12 wählen)
oder
75 67 11 0 123456 (für NSt. 11 die 0 123456 wählen)

(75 = Ersatzziffernfolge für den Stern, 67 Kennzahl für die SIEMENS-Anlagenfunktion "assoziierte Wahl")


Ich wähle also folgendermaßen:
exten => _7567.,1,Dial(CAPI/contr1/501:${EXTEN:0:4},E($EXTEN:4))

Die "7567" per Blockwahl, dann mit meinem Patch per ast_senddigit() weiter
11 sleep(1) 0 sleep(1) 123456

Das klappt. (*stolz guck*)


Ist doch wirklich "krückig", wenn eine TK-Anlage (und die SIEMENS Hicoms sind ja nicht gerade unverbreiteter und/oder billiger Schrott) da so blöde Pausen bei digitaler Wahl benötigt...
Nun muß ich also in meine neue E()-Option eine Pausenfunktion einbauen.


Gibt's in Asterisk bzw. in chan_capi-cm eigentlich auch eine Funktion, mit der man mehrere (overlap-)Digits auf einmal senden kann (also z.B. ast_senddigits() statt ast_senddigit() )?
Wohl eher nicht - würde ja irgendwie gegen das Overlap-Konzept laufen.


Weißt Du zufällig schnell, wie man am Ende einen solchen Patch an Digium vermittelt, damit die den mal einbauen?
EDIT: Habe ich gerade selbst rausgesucht auf http://www.digium.com/bugtracker.html


Gruß, Harald
 
Zuletzt bearbeitet:
telchef schrieb:
Weißt Du zufällig schnell, wie man am Ende einen solchen Patch an Digium vermittelt, damit die den mal einbauen?
EDIT: Habe ich gerade selbst rausgesucht auf http://www.digium.com/bugtracker.html

Das ist aber nicht so einfach, denn wenn Du patches an digium schickst, musst du einen Disclaimer unterschreiben und dein copyright abgeben, sonst wird der patch nicht aufgenommen.
Das ist das Uebel von Asterisk und Digium.... so viel zu open-source bei Digium.

Armin
 
Hallo Armin!

Nur mal der Vollständigkeit halber:

Bei einer "Telekom Octopus E30" (wohl baugleich mit "Siemens Hicom 118 E" [aus Modellreihe 100 E]) geht /bo offenbar auch nicht.

Das dürften leicht ältere Anlagen sein, als meine "Siemens Hicom 150 H" (neuer vermarktet als "Siemens HiPath 3350").

Hier zu finden:
http://www.ip-phone-forum.de/showthread.php?p=536843#post536843


Gruß, Harald
 
Das heisst auch da es nicht moeglich ist mit einem ISDN Telefon einfach nur abzuheben und den Waehlton zu bekommen? Also ich habe bisher keine Anlage
gesehen, wo das so ist.

Armin
 
Hallo Armin!

armincm schrieb:
Das heisst auch da es nicht moeglich ist mit einem ISDN Telefon einfach nur abzuheben und den Waehlton zu bekommen? Also ich habe bisher keine Anlage gesehen, wo das so ist.

Leider habe ich kein ISDN-Telefon einfach zur Hand, daß ich das ausprobieren könnte. Ich glaube aber schon, daß es so sein wird.

Ich erinnere mich auch dunkel an ein Support-Gespräch mit einem Siemensianer vor Jahren, der mir auch mal bestätigt hat, daß dieses Verhalten so sei. Kann aber auch sein, daß ich das nur geträumt habe.
Auf jeden Fall hatte/hätte ich das abgehakt unter typischer "SIEMENS-Arroganz".

Es paßt auch gut zu deren Monopol-Strategien. Ich freue mich direkt, daß SIEMENS-Com nun sieht, was es davon hat.

Hintergrund bei SIEMENS wird wohl sein, daß dort niemand Interesse an ISDN-Telefonen hat(te). Vermögende Kunden sollen Systemtelefone zu obszönen Preisen mieten, und gut ist. An anderen Kunden ist man nicht interessiert.
ISDN-Schnittstellen sind für Amtsleitungen oder Datengeräte vorgesehen, Analog-Schnittstellen für Faxgeräte...

Richtige Männer (mit Kohle) benutzen/kaufen/mieten Systemtelefone.

An Interoperabilität ist niemand interessiert. Alles, was der Kunde wünscht, kann SIEMENS aus eigenem Hause gegen krass-obszöne Preise vermieten.


Trotzdem sind die SIEMENS-Anlagen und Endgeräte hervorragend robust und für den geweblichen Einsatz sehr gut geeignet. Man muß sich eben nur auf herkömmliches Telefonieren mit Systemtelefonen beschränken.


Gruß, Harald
 
Kostenlos!

Statistik des Forums

Themen
248,903
Beiträge
2,304,569
Mitglieder
378,604
Neuestes Mitglied
Duggy