Timeout bei eingehenden Anrufen

[tangens]

Hallo Forum,

erstmal zum Thema Ausstattung:
Debian System
AVM Fritz PCI - parallel zur Telefonanlage am s0 vom NTBA, da das Teil leider kein internen s0 hat - wohl nicht ideal...

Neuster fcpci Treiber von avm
chan_capi .6.3
Asterisk 1.2.1

Jetzt zu meinem Problem:
ich habe so etwas wie einen anrufbeantworter aufgebaut, der nach 15sek eine mail an mich schickt wer anruft und nach 30 sekunden das ganze aufnimmt und per Mail zustellt. Das ging bis vor dem Upgrade von 1.0 und chan_capi_3.5 auch zuverlässig.
Mit der neuen Version killt er immer nach ca. 10 Sekunden den kompletten Channel und das ganze tut nicht mehr.

hier mal ein vvvvvc und capi debug:

troller/PLCI/NCCI            = 0x101
  CIPValue                        = 0x4
  CalledPartyNumber               = <c1>4039743
  CallingPartyNumber              = <21 81>xxx4039743
  CalledPartySubaddress           = default
  CallingPartySubaddress          = default
  BC                              = <90 90 a3>
  LLC                             = default
  HLC                             = default
  AdditionalInfo                  = default

    -- CONNECT_IND (PLCI=0x101,DID=4039743,CID=xxx4039743,CIP=0x4,CONTROLLER=0x1)
       > ISDN1: msn='*' DNID='4039743' MSN
  == ISDN1: Incoming call 'xxx4039743' -> '4039743'
    -- ISDN1: CAPI/ISDN1/4039743-0: 4039743 matches in context capi-in
       > CAPI devicestate requested for ISDN1/4039743
  == Started pbx on channel CAPI/ISDN1/4039743-0
INFO_IND ID=001 #0x0016 LEN=0017
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x1e
  InfoElement                     = <85 83>

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

    -- ISDN1: info element PI 85 83
       > ISDN1: Origination is non ISDN
INFO_IND ID=001 #0x0017 LEN=0023
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x70
  InfoElement                     = <c1>4039743

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

    -- ISDN1: info element CALLED PARTY NUMBER
       > ISDN1: INFO_IND DID digits not used in this state.
INFO_IND ID=001 #0x0018 LEN=0016
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0x18
  InfoElement                     = <8a>

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

    -- ISDN1: info element CHANNEL IDENTIFICATION 8a
INFO_IND ID=001 #0x0019 LEN=0016
  Controller/PLCI/NCCI            = 0x101
  InfoNumber                      = 0xa1
  InfoElement                     = <a1>

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

    -- ISDN1: info element Sending Complete
  == ISDN1: pbx already started on channel CAPI/ISDN1/4039743-0
    -- Executing NoOp("CAPI/ISDN1/4039743-0", " received call xxx4039743 -> 4039743") in new stack
    -- Executing Dial("CAPI/ISDN1/4039743-0", "SIP/me|10|T") in new stack
Jan 17 01:12:46 NOTICE[2623]: app_dial.c:1010 dial_exec_full: Unable to create channel of type 'SIP' (cause 3 - No route to destination)
  == Everyone is busy/congested at this time (1:0/0/1)
    -- Executing Wait("CAPI/ISDN1/4039743-0", "2") in new stack
    -- Executing Wait("CAPI/ISDN1/4039743-0", "3") in new stack
    -- Executing Wait("CAPI/ISDN1/4039743-0", "3") in new stack
    -- Executing AGI("CAPI/ISDN1/4039743-0", "nailme.sh|xxx4039743|[email protected]") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/nailme.sh
DISCONNECT_IND ID=001 #0x001a LEN=0014
  Controller/PLCI/NCCI            = 0x101
  Reason                          = 0x0

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

  == Spawn extension (capi-in, 4039743, 6) exited non-zero on 'CAPI/ISDN1/4039743-0'
  == ISDN1: CAPI Hangingup
       > CAPI devicestate requested for ISDN1/4039743
  == ISDN1: Interface cleanup PLCI=0x101
       > CAPI devicestate requested for ISDN1/4039743
INFO_IND ID=001 #0x001b LEN=0033
  Controller/PLCI/NCCI            = 0x1
  InfoNumber                      = 0x1c
  InfoElement                     = <91 a1 0f 02 02 90 c3 06 06 04 00 82>g<01 0a 02 01 01>

INFO_RESP ID=001 #0x001b LEN=0012
  Controller/PLCI/NCCI            = 0x1

CAPI: INFO_IND no interface for PLCI=0x1
       > CAPI: Command=INFO_IND,0x8492: no interface for PLCI=0x1, MSGNUM=0x1b!

Das dreifache wait hat zumindest bei der version .3.5 geholfen (ohne gings auch nicht). Er haut halt jetzt schon nach 8 sek. ne mail raus...
Wenn ich z.b. wait(15) mache dann stirbt er auch nach 10 sek mit gleicher meldung ...

ich hoff jemand weiss da weiter - hab mich schon halb tod gegoogelt

 

[armincm]

Wenn ein eingehender Anruf nicht bearbeitet wird, dann schlaegt bei ISDN nach einer bestimmten Zeit der Timeout zu. Beim alten chan_capi-0.3.5 wurde grundsaetzlich z.B. ALERT geschickt um den Timeout auszuschalten, was eigentlich ein Fehler ist. Das neue chan_capi macht das korrekt und schickt kein 'falsches' ALERT. In Deinem Fall benoetigst Du aber das ALERT und das kannst Du mit einem
Ringing() vor dem Wait() erreichen.

Armin

 

[tangens]

juhu!!! er funktioniert wieder!

herzlichen dank für die schnelle antwort!

 

[tangens]

juhu!!! er funktioniert wieder!

herzlichen dank für die schnelle antwort!

gut, zu früh gefreut...
nachdem ich mich gewundert habe, warum jetzt meine telefone nicht mehr funktionieren hab ich mir die dokumentation des ringing befehles angeschaut. wenn ich das nicht falsch verstanden habe nimmt asterisk mit ringing das gespräch an und legt ein klingeln auf die leitung. damit ist das gespräch für meine telefone die an der isdn anlage hängen weg und ich kanns nicht mehr annehmen...
kann ich das verhalten von chan capi im quelltext ändern?

 

[armincm]

Das Ringing() erzeugt nur ein 'indicate'. Asterisk nimmt den Anruf dabei nicht entgegen. Es sei denn der chan_ Treiber macht das dann. chan_capi macht das jedoch nicht, es wird nur das notwendige ALERT gesendet.
Mach doch bitte mal ein log davon (set verbose 5, capi debug)

Armin

 

[tangens]

oha,
da hakts bei mir an anderer stelle... ich wollte das log für die antwort hier machen und musste feststellen, dass es tatsächlich einwandfrei funktioniert.
die vermutung von mir ist jetzt, dass es sich bei dem anruf bei dem mein telefon nicht mehr ging um einen sip anruf handelte... (garstiges enum ). aber die sip geschichte hab ich eh noch nicht richt richtig getestet. insofern nehm ich meinen letzten post zurück - es funktioniert so wie gedacht...