Incomming call landet im falschen Kontext

Hupe · 29 Aug 2005

Folgendes Problem: Ich möchte, dass chan_capi für mich schon eingehende Anruft, je nach MSN in unterschiedliche Kontexte schickt (fragt nicht warum, das hat was mit call transfer zu tun.....). Also habe ich zwei Interfaces in der capi.conf definiert:

Code:

[interfaces]

; mode: ptmp (point-to-multipoint) or ptp (point-to-point)
isdnmode=ptmp
; allow incoming calls to this list of MSNs, * == any
incomingmsn=22,29,15,20
; capi controller number
controller=1
; dialout group
group=1
; enable/disable software dtmf detection, recommended for AVM cards
softdtmf=1
; accountcode to use in CDRs
accountcode=
; context for incoming calls
context=capi-in
; _VERY_PRIMITIVE_ echo suppression
echosquelch=0
; EICON DIVA SERVER echo cancelation
;echocancel=yes
;echotail=64
; call group
;callgroup=1
; deflect incoming calls to 12345678 if all B channels are busy
;deflect=12345678
; number of concurrent calls on this controller (2 makes sense for single BRI)
devices => 2


; mode: ptmp (point-to-multipoint) or ptp (point-to-point)
isdnmode=ptmp
; allow incoming calls to this list of MSNs, * == any
incomingmsn=24,14
; capi controller number
controller=1
; dialout group
group=1
; enable/disable software dtmf detection, recommended for AVM cards
softdtmf=1
; accountcode to use in CDRs
accountcode=
; context for incoming calls
context=capi-at
; _VERY_PRIMITIVE_ echo suppression
echosquelch=0
; EICON DIVA SERVER echo cancelation
;echocancel=yes
;echotail=64
; call group
;callgroup=1
; deflect incoming calls to 12345678 if all B channels are busy
;deflect=12345678
; number of concurrent calls on this controller (2 makes sense for single BRI)
devices => 2

Wenn ich intern nun also die 24 Anrufe, dann klappt auch alles wunderbar. Der Anruf landet im Kontext "capi-at". Nur leider nicht ein Anruf auf der Nummer 14. Der wird in den Kontext "capi-in" geleitet. Dabei ist die Reihenfolge der Nummern in der capi.conf egal (schon getestet). Leider gibt es im Kontext "capi-in" auch ne extension 14, sodass es zu einem Fehler kommt.

Glaube zwar nicht, dass das hilft, aber hier das capi debug, wenn ich die 14 Anrufe :

Code:

server:/etc/asterisk# asterisk -rd
Parsing /etc/asterisk/asterisk.conf
Parsing /etc/asterisk/extconfig.conf
Asterisk CVS-HEAD, Copyright (C) 1999 - 2005 Digium.
Written by Mark Spencer <[email protected]>
=========================================================================
Connected to Asterisk CVS-HEAD currently running on server (pid = 3336)
Core debug is at least 1
server*CLI> set verbose 0
server*CLI> set verbose 5
Verbosity was 0 and is now 5
CONNECT_IND ID=001 #0x4e01 LEN=0035
  Controller/PLCI/NCCI            = 0x101
  CIPValue                        = 0x4
  CalledPartyNumber               = <81>14
  CallingPartyNumber              = <01 80 2a 2a>13
  CalledPartySubaddress           = default
  CallingPartySubaddress          = default
  BC                              = <90 90 a3>
  LLC                             = default
  HLC                             = default
  AdditionalInfo                  = default

  == CONNECT_IND (PLCI=0x101,DID=14,CID=**13,CIP=0x4,CONTROLLER=0x1)
    -- creating pipe for PLCI=0x101
ALERT_REQ ID=001 #0x4e01 LEN=0017
  Controller/PLCI/NCCI            = 0x101
  AdditionalInfo
   BChannelinformation            = default
   Keypadfacility                 = default
   Useruserdata                   = default
   Facilitydataarray              = default

    -- started pbx on channel (callgroup=0)!
INFO_IND ID=001 #0x4e02 LEN=0017
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x1e
  InfoElement                     = <85 83>

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

  == info element PI 85 83
 Origination is non ISDN
INFO_IND ID=001 #0x4e03 LEN=0018
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x70
  InfoElement                     = <81>14

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

  == info element CALLED PARTY NUMBER
       > INFO_IND DID digits in non PtP mode
INFO_IND ID=001 #0x4e04 LEN=0016
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x18
  InfoElement                     = <89>

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

  == info element CHANNEL IDENTIFIKATION 89
ALERT_CONF ID=001 #0x4e01 LEN=0014
  Controller/PLCI/NCCI            = 0x101
  Info                            = 0x0

    -- Executing SetMusicOnHold("CAPI/contr1/14-16", "default") in new stack
    -- Executing NoOp("CAPI/contr1/14-16", "") in new stack
    -- Executing SetLanguage("CAPI/contr1/14-16", "de") in new stack
    -- Executing NoOp("CAPI/contr1/14-16", "") in new stack
    -- Executing Set("CAPI/contr1/14-16", "CALLERID(number)=22") in new stack
    -- Executing Dial("CAPI/contr1/14-16", "CAPI/contr1/14|45|tTm") in new stack
    -- data = contr1/14
    -- capi request controller = 1
    -- creating pipe for PLCI=0
  == CAPI Call CAPI/contr1/14-17  (pres=0x00)
CONNECT_REQ ID=001 #0x0055 LEN=0045
  Controller/PLCI/NCCI            = 0x1
  CIPValue                        = 0x4
  CalledPartyNumber               = <80>14
  CallingPartyNumber              = <00 80>22
  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 contr1/14
CONNECT_CONF ID=001 #0x0055 LEN=0014
  Controller/PLCI/NCCI            = 0x201
  Info                            = 0x0

  == received CONNECT_CONF PLCI = 0x201 INFO = 0
    -- Started music on hold, class 'default', on CAPI/contr1/14-16
INFO_IND ID=001 #0x4e05 LEN=0015
  Controller/PLCI/NCCI            = 0x201
  InfoNumber                      = 0x800d
  InfoElement                     = default

INFO_RESP ID=001 #0x4e05 LEN=0012
  Controller/PLCI/NCCI            = 0x201

  == info element SETUP ACK
INFO_IND ID=001 #0x4e06 LEN=0017
  Controller/PLCI/NCCI            = 0x201
  InfoNumber                      = 0x1e
  InfoElement                     = <81 88>

INFO_RESP ID=001 #0x4e06 LEN=0012
  Controller/PLCI/NCCI            = 0x201

  == info element PI 81 88
 In-band information available
INFO_IND ID=001 #0x4e07 LEN=0016
  Controller/PLCI/NCCI            = 0x201
  InfoNumber                      = 0x18
  InfoElement                     = <8a>

INFO_RESP ID=001 #0x4e07 LEN=0012
  Controller/PLCI/NCCI            = 0x201

  == info element CHANNEL IDENTIFIKATION 8a
CONNECT_IND ID=001 #0x4e08 LEN=0042
  Controller/PLCI/NCCI            = 0x301
  CIPValue                        = 0x4
  CalledPartyNumber               = <81>14
  CallingPartyNumber              = <01 80 2a 2a>22
  CalledPartySubaddress           = default
  CallingPartySubaddress          = default
  BC                              = <90 90 a3>
  LLC                             = default
  HLC                             = default
  AdditionalInfo
   BChannelinformation            = <02 00>
   Keypadfacility                 = default
   Useruserdata                   = default
   Facilitydataarray              = default

  == CONNECT_IND (PLCI=0x301,DID=14,CID=**22,CIP=0x4,CONTROLLER=0x1)
Aug 29 20:03:14 ERROR[3452]: chan_capi.c:2324 capi_handle_connect_indication: received a call waiting CONNECT_IND
Aug 29 20:03:14 ERROR[3452]: chan_capi.c:2417 capi_handle_connect_indication: did not find device for msn = 14
CONNECT_RESP ID=001 #0x4e08 LEN=0032
  Controller/PLCI/NCCI            = 0x301
  Reject                          = 0x3
  BProtocol
   B1protocol                     = 0x0
   B2protocol                     = 0x0
   B3protocol                     = 0x0
   B1configuration                = default
   B2configuration                = default
   B3configuration                = default
  ConnectedNumber                 = default
  ConnectedSubaddress             = default
  LLC                             = default
  AdditionalInfo
   BChannelinformation            = default
   Keypadfacility                 = default
   Useruserdata                   = default
   Facilitydataarray              = default

INFO_IND ID=001 #0x4e09 LEN=0018
  Controller/PLCI/NCCI            = 0x301
  InfoNumber                      = 0x70
  InfoElement                     = <81>14

 CAPI: unable to find a pipe for PLCI = 0x301 MN = 0x4e09
INFO_RESP ID=001 #0x4e09 LEN=0012
  Controller/PLCI/NCCI            = 0x301

CAPI: INFO_IND no pipe PLCI=0x301
INFO_IND ID=001 #0x4e0a LEN=0016
  Controller/PLCI/NCCI            = 0x301
  InfoNumber                      = 0x18
  InfoElement                     = <80>

 CAPI: unable to find a pipe for PLCI = 0x301 MN = 0x4e0a
INFO_RESP ID=001 #0x4e0a LEN=0012
  Controller/PLCI/NCCI            = 0x301

CAPI: INFO_IND no pipe PLCI=0x301
DISCONNECT_IND ID=001 #0x4e0b LEN=0014
  Controller/PLCI/NCCI            = 0x301
  Reason                          = 0x0

 CAPI: unable to find a pipe for PLCI = 0x301 MN = 0x4e0b
DISCONNECT_RESP ID=001 #0x4e0b LEN=0012
  Controller/PLCI/NCCI            = 0x301

CAPI: DISCONNECT_IND no pipe PLCI=0x301
INFO_IND ID=001 #0x4e0c LEN=0015
  Controller/PLCI/NCCI            = 0x201
  InfoNumber                      = 0x8002
  InfoElement                     = default

INFO_RESP ID=001 #0x4e0c LEN=0012
  Controller/PLCI/NCCI            = 0x201

  == info element CALL PROCEEDING
    -- CAPI/contr1/14-17 is proceeding passing it to CAPI/contr1/14-16
  == Requested PROCEEDING-Indication for CAPI/contr1/14-16
INFO_IND ID=001 #0x4e0d LEN=0017
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x8
  InfoElement                     = <85 90>

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

  == info element CAUSE 85 90
DISCONNECT_IND ID=001 #0x4e0e LEN=0014
  Controller/PLCI/NCCI            = 0x101
  Reason                          = 0x3490

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

    -- Stopped music on hold on CAPI/contr1/14-16
    -- CAPI Hangingup
       > activehangingup
DISCONNECT_REQ ID=001 #0x0056 LEN=0017
  Controller/PLCI/NCCI            = 0x201
  AdditionalInfo
   BChannelinformation            = default
   Keypadfacility                 = default
   Useruserdata                   = default
   Facilitydataarray              = default

DISCONNECT_CONF ID=001 #0x0056 LEN=0014
  Controller/PLCI/NCCI            = 0x201
  Info                            = 0x0

    -- Executing Hangup("CAPI/contr1/14-16", "") in new stack
    -- CAPI Hangingup
    -- removed pipe for PLCI = 0x101
DISCONNECT_IND ID=001 #0x4e0f LEN=0014
  Controller/PLCI/NCCI            = 0x201
  Reason                          = 0x3400

DISCONNECT_RESP ID=001 #0x4e0f LEN=0012
  Controller/PLCI/NCCI            = 0x201

    -- removed pipe for PLCI = 0x201
server*CLI> set verbose 0
Verbosity is now OFF
server*CLI>

Und hier für die 24:

Code:

server:/etc/asterisk# asterisk -rd
Parsing /etc/asterisk/asterisk.conf
Parsing /etc/asterisk/extconfig.conf
Asterisk CVS-HEAD, Copyright (C) 1999 - 2005 Digium.
Written by Mark Spencer <[email protected]>
=========================================================================
Connected to Asterisk CVS-HEAD currently running on server (pid = 3336)
Verbosity is at least 5
Core debug is at least 1
CONNECT_IND ID=001 #0x4e16 LEN=0035
  Controller/PLCI/NCCI            = 0x101
  CIPValue                        = 0x4
  CalledPartyNumber               = <81>24
  CallingPartyNumber              = <01 80 2a 2a>13
  CalledPartySubaddress           = default
  CallingPartySubaddress          = default
  BC                              = <90 90 a3>
  LLC                             = default
  HLC                             = default
  AdditionalInfo                  = default

  == CONNECT_IND (PLCI=0x101,DID=24,CID=**13,CIP=0x4,CONTROLLER=0x1)
    -- creating pipe for PLCI=0x101
ALERT_REQ ID=001 #0x4e16 LEN=0017
  Controller/PLCI/NCCI            = 0x101
  AdditionalInfo
   BChannelinformation            = default
   Keypadfacility                 = default
   Useruserdata                   = default
   Facilitydataarray              = default

    -- started pbx on channel (callgroup=0)!
INFO_IND ID=001 #0x4e17 LEN=0017
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x1e
  InfoElement                     = <85 83>

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

  == info element PI 85 83
 Origination is non ISDN
INFO_IND ID=001 #0x4e18 LEN=0018
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x70
  InfoElement                     = <81>24

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

  == info element CALLED PARTY NUMBER
       > INFO_IND DID digits in non PtP mode
INFO_IND ID=001 #0x4e19 LEN=0016
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x18
  InfoElement                     = <89>

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

  == info element CHANNEL IDENTIFIKATION 89
ALERT_CONF ID=001 #0x4e16 LEN=0014
  Controller/PLCI/NCCI            = 0x101
  Info                            = 0x0

  == Starting CAPI/contr1/24-19 at capi-at,24,1 failed so falling back to exten 's'
    -- Executing NoOp("CAPI/contr1/24-19", ""Incoming call for s"") in new stack
INFO_IND ID=001 #0x4e1a LEN=0017
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x8
  InfoElement                     = <85 90>

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

  == info element CAUSE 85 90
DISCONNECT_IND ID=001 #0x4e1b LEN=0014
  Controller/PLCI/NCCI            = 0x101
  Reason                          = 0x3490

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

    -- Executing Hangup("CAPI/contr1/24-19", "") in new stack
    -- CAPI Hangingup
    -- removed pipe for PLCI = 0x101
server*CLI> set verbose 0

Ach nochwas. 14 und 24 sind gültige Nummern: am gleichen S0 hängt ein ISDN-Telefon, welches auf beide Nummeren gleich reagiert (also es klingelt).
Mir wäre es schon ganz lieb, wenn das funzen würde, da ich mein ISDN-Telefon durch ein IP-Phone ersetzen will, und Asterisk als Gateway arbeiten soll. Daher sollte es auch mit der Nummer 14 funzen. Sonst könnte man ja auch ne andere Nummer nehmen.

Maik · 29 Aug 2005

Erstell doch einfach nen neuen Kontext und lege dort extensions mit Goto als erste Aktion an.

Hupe · 29 Aug 2005

Die Idee ist nicht schlecht, bringt mich aber nicht weiter:
Wie ich schon sagte: Das hat was mit Call-Transfer zu tun. Wenn ich einen Anruf von Sipauf meinem ISDN-Telefon annehme, und diesen Anruf dann weiterleiten will, so geschieht dieses im Kontext "capi-in", da das Telefon ja über die MSN 22 angerufen wird. Ich möchte aber auch auf die Nummer 14 weiterleiten können, daher existiert dort auch eine extension 14. Gleichzeitig soll Asterisk aber auch auf die MSN 14 reagieren. Wenn ich das im gleichen Kontext mache, so überschneiden sich die unterschiedlichen Extensions 14. Da hilft auch kein goto, da der Asterisk ja nicht zwischen 14 -Anruf von außen und 14-CallTransfer unterscheiden kann. Daher die zwei Kontexte (außerdem möchte ich das sauber trennen). Selbst wenn ich mit einer Lösung mit Goo ans Ziel kommen würde, bleibt ja immernoch das seltsame Verhalten von chan_capi (übrigens version 0.5.4). Ich halte es für ein bischen riskant, wenn man sich bei bestimmten MSNs nicht sicher sein kann, in welchem Kontext sie behandelt werden....

Maik · 29 Aug 2005

Ich dachte mir das so, dass du alle Anrufe, die ueber Capi reinkommen (und nur die) in einen eigenen Kontext schiebst und dann direkt per goto in den anderen Kontext springst.

Das sollte dein Problem doch eigentlich umgehen oder verstehe ich da was falsch?

Dass chan_capi ein Problem mit deiner Config hat, ist natuerlich ne ganz andere Sache. Ich weiss aber nicht ob das wirklich ein Bug ist, denn eigentlich war es glaube ich nie so gedacht, dass der Kontext anhand der MSN ausgewaehlt wird.

Hupe · 29 Aug 2005

Die eingehenden Anrufe über Capi landen sowieso in einem eigenen Kontext. Und von da aus geht es ja auch per gite in andere Kontexte. Das problem ist nur die Rufweiterleitung. Wenn ich diese von einem Telefon aus einleite, dann wird diese eben auch im Selben Kontext behandelt (ist ja auch irgendwie logisch, das st ja eben der Startcontext für Capi). Und leider muss ich die extension 14 zweimal unterschiedlich behandeln (einmal, wenn ein Anruf über die ISDN-Karte des Asterisk auf der 14 signalisiert wird, und einmal, für die Rufweiterleitung). Gotos helfen da nicht, da ja immer dir Extension 14 passt, und so auch dem Goto folgen würde. Ich weiss auch nochnicht, ob es da irgendein anderes Kriterium für die Unterscheidung der beiden Extensions finden kann. Soweit habe ich das nochnicht getestet. Ich möchte es irgendwie hinbekommen, dass ich einen Anruf von ISDN auf meinen Asterisk in der Telefonanlage vermittle (möglichst mit ankündigung). Innerhalb des Asterisk würe es kein Problem, aber dann sind beide Kanäle besetzt, und das Sip-Telefon ist via SDN nichtmehr erreichbar. Außerdem könnte ich dann nichtmehr auf ein ISDN-Telefon weitervermitteln.

Was die Funktionalität von chan_capi betrifft. Mit dem Alten hatte ich das nur so gemacht, und es hatte ziemlich gut gefunzt (auch wenn ich das mit der nummer 14 nie getestet habe).
Wenn es nie Vorgesehen war, dass man einen Kontext anhand der MSN schon in der capi.conf festlegen kann, so ist das meiner Meinung nach ein Fehler. Es sollte zwingend die Möglichkeit geben, dass man für verschieden MSNs verschieden Kontexte bestimmen kann. Man kann natürlich alles irgendwie hinbekommen, aber es erleichter die Sache doch erheblich (gerade bei ISDN) und solange der CallTransfer so funktioniert, wie er jetzt läuft, sowieso. Es müsste die Möglichkeit geben, dass man für jeden Kontext auch noch zusätzlich einen separaten Transfer-Kontext bestimmt, um Überschneidungen bei den Extensions zu vermeiden.

Languages

Suche

Languages

Suche

Incomming call landet im falschen Kontext

Hupe

Aktives Mitglied

Maik

Gesperrt

Hupe

Aktives Mitglied

Maik

Gesperrt

Hupe

Aktives Mitglied

Neueste Beiträge

Kategorien

Wissenswertes

Zurzeit aktive Besucher

Statistik des Forums

3CX jetzt einen Monat kostenlos testen

Unternehmen

Lösungen

Nützliche Links

Mehr erfahren