.titleBar { margin-bottom: 5px!important; }

Verzögerung bei abgehenden Telefonaten

Dieses Thema im Forum "Asterisk ISDN mit CAPI (chan_capi, chan_capi_cm)" wurde erstellt von Felix.Schwarz, 16 Feb. 2006.

  1. Felix.Schwarz

    Felix.Schwarz Neuer User

    Registriert seit:
    16 Feb. 2006
    Beiträge:
    12
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    Hallo,

    mein Problem ist, dass ich nach dem Wählen der Nummer immer etwa 5 Sekunden warten muss, bevor es das erste Mal klingelt. Ich hatte schon an DigitTimeout gedacht (bzw. die neuere SET-Variante), aber im Asterisklog sehe ich, dass eine entspr. Ausgabe mit dem Eintrag des DigitTimeout erst erscheint, nachdem diese 5 Sekunden abgelaufen sind...

    An der Wartezeit im Telefon selbst (CISCO 7970 bzw. Softphone Xten lite) sollte es auch nicht liegen, denn dann sollte das Problem nach meinem Verständnis bei einer Wahlwiederholung nicht auftreten.

    Kurz etwas zu meinem Systemsetup:
    P3-800 mit Fritz!Card PCI an einem normalen ISDN-Anschluss. Asterisk 1.2.3, chan_capi und proprietärem AVM-Treiber. Kernel 2.6.15. Das Softphone verwendet SIP, Cisco wurde mittels chan_sccp angeschlossen.

    Bei internen Telefonaten zwischen Softphone und Cisco gibt es diese Verzögerung nicht, auch eingehende Telefonate werden sofort durchgestellt.

    Wo könnte ich noch suchen? Eigentlich hätte ich ja erwartet, dass die o.g. Problematik ein Standardfall wäre, aber trotz intensiver Suche habe ich scheinbar nicht die richtigen Suchbegriffe gefunden. Welche Informationen wären hier noch hilfreich?

    vielen Dank schon mal im Voraus :)
    Felix
     
  2. Felix.Schwarz

    Felix.Schwarz Neuer User

    Registriert seit:
    16 Feb. 2006
    Beiträge:
    12
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    Nur als Info: Ich habe diverse Nachrichten gelesen, dass Leute Probleme mit SIP-Providern hätten, aber das kann hier keine Rolle spielen, weil VoIP in meinem Setting ausschließlich intern verwendet wird. Ich habe den Rechner auch direkt mit dem NTBA verbunden. Ein (allerdings über eine Telefonanlage angeschlossenes) Telefon am gleichen Anschluss hat die angesprochene Verzögerung nicht.
     
  3. armincm

    armincm Aktives Mitglied

    Registriert seit:
    3 Aug. 2005
    Beiträge:
    1,006
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Welche Version von chan_capi verwendest Du? Waehlst Du ISDN an, oder ist SIP dein Ziel? Wie sehen denn Deine confs aus?

    Armin
     
  4. Felix.Schwarz

    Felix.Schwarz Neuer User

    Registriert seit:
    16 Feb. 2006
    Beiträge:
    12
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    Ich glaube, chan_capi cm-0.6.3.

    Aus der extensions.conf
    exten => _0.,1,DigitTimeout(1)
    exten => _0.,2,Dial(CAPI/g1/${EXTEN:1}/b)

    Ich wähle also von einem SIP- bzw. Cisco-Telefon aus ins normale Telefonnetz.

    fs
     
  5. armincm

    armincm Aktives Mitglied

    Registriert seit:
    3 Aug. 2005
    Beiträge:
    1,006
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Das sieht soweit okay aus. Wenn du dir das verbose log ansiehst, kannst Du sagen ob was 'warten' schon vor dem Aufruf von Dial(...) ist, oder ist Dial() schon aufgerufen worden?

    Armin
     
  6. Felix.Schwarz

    Felix.Schwarz Neuer User

    Registriert seit:
    16 Feb. 2006
    Beiträge:
    12
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    Zum Logging habe ich eine Frage:
    Kann ich mich darauf verlassen, dass alle Ereignisse genau in der zeitlichen Reihenfolge aufgetreten sind, wie sie von Asterisk auf der Konsole ausgegeben wurden? Nicht, dass da ein Thread seine gesammelten Logmeldungen erst später ausspuckt o.ä...

    fs
     
  7. armincm

    armincm Aktives Mitglied

    Registriert seit:
    3 Aug. 2005
    Beiträge:
    1,006
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    In der Regel stimmt das Log mit der Reihenfolge ueberein.
    Man kann eine andere Reihenfolge nicht ganz aussschliessen, aber die meisten (wichtigen) Messages kommen sowieso nur von einem Thread.

    Armin
     
  8. Felix.Schwarz

    Felix.Schwarz Neuer User

    Registriert seit:
    16 Feb. 2006
    Beiträge:
    12
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    Nach etwas Logging habe ich herausgefunden, dass das Rauswählen bei folgendem Logeintrag für 5 Sekunden anhält:
    "ISDN1: info element CHANNEL IDENTIFICATION 89"

    Leider habe ich keine Ahnung, woran das liegt wo ich genau suchen sollte.

    Grobüberblick:
    Code:
        -- SEP001319153E40: New call on line 79051
        -- Executing DigitTimeout("SCCP/79051-00000001", "1") in new stack
    Feb 23 12:29:40 WARNING[19090]: pbx.c:5828 pbx_builtin_dtimeout: DigitTimeout is deprecated, please use Set(TIMEOUT(digit)=timeout) instead.
        -- Set Digit Timeout to 1
        -- Executing Dial("SCCP/79051-00000001", "CAPI/g1/08001721212/b") in new stack
        -- Called g1/08001721212/b
       (hier wartet er)
        -- CAPI/ISDN1/08001721212-0 is ringing
    

    Mit Loglevel 5 sieht das ganze dann in etwa so aus:
    Code:
        -- SEP001319153E40: Speeddial Button (1) pressed, configured number is (008001721212)
        -- SEP001319153E40: New call on line 79051
        -- Executing DigitTimeout("SCCP/79051-0000000f", "1") in new stack
        -- Set Digit Timeout to 1
        -- Executing Dial("SCCP/79051-0000000f", "CAPI/g1/08001721212/b") in new stack
           > data = g1/08001721212/b
           > parsed dialstring: 'g1' 'NULL' '08001721212' 'b'
           > capi request group = 2
           > parsed dialstring: 'g1' 'NULL' '08001721212' 'b'
      == ISDN1: Call CAPI/ISDN1/08001721212-3 with B3  (pres=0x00, ton=0x00)
    CONNECT_REQ ID=001 #0x01c2 LEN=0059
      Controller/PLCI/NCCI            = 0x1
      CIPValue                        = 0x1
      CalledPartyNumber               = <80>08001721212
      CallingPartyNumber              = <00 80>66497
      CalledPartySubaddress           = default
      CallingPartySubaddress          = default
      BProtocol
       B1protocol                     = 0x1
       B2protocol                     = 0x1
       B3protocol                     = 0x0
       B1configuration                = default
       B2configuration                = default
       B3configuration                = default
       GlobalConfiguration            = default
      BC                              = default
      LLC                             = default
      HLC                             = default
      AdditionalInfo
       BChannelinformation            = <00 00>
       Keypadfacility                 = default
       Useruserdata                   = default
       Facilitydataarray              = default
       SendingComplete                = default
    
        -- Called g1/08001721212/b
    CONNECT_CONF ID=001 #0x01c2 LEN=0014
      Controller/PLCI/NCCI            = 0x101
      Info                            = 0x0
    
        -- ISDN1: received CONNECT_CONF PLCI = 0x101
           > CAPI devicestate requested for ISDN1/08001721212
           > CAPI devicestate requested for ISDN1/08001721212
    INFO_IND ID=001 #0x838e LEN=0015
      Controller/PLCI/NCCI            = 0x101
      InfoNumber                      = 0x800d
      InfoElement                     = default
    
    INFO_RESP ID=001 #0x838e LEN=0012
      Controller/PLCI/NCCI            = 0x101
    
        -- ISDN1: info element SETUP ACK
    INFO_IND ID=001 #0x838f LEN=0016
      Controller/PLCI/NCCI            = 0x101
      InfoNumber                      = 0x18
      InfoElement                     = <89>
    
    INFO_RESP ID=001 #0x838f LEN=0012
      Controller/PLCI/NCCI            = 0x101
    
        -- ISDN1: info element CHANNEL IDENTIFICATION 89
    
    <WARTEN>    
        
        
    INFO_IND ID=001 #0x8390 LEN=0015
      Controller/PLCI/NCCI            = 0x101
      InfoNumber                      = 0x8001
      InfoElement                     = default
    
    INFO_RESP ID=001 #0x8390 LEN=0012
      Controller/PLCI/NCCI            = 0x101
    
        -- ISDN1: info element ALERTING
    INFO_IND ID=001 #0x8391 LEN=0017
      Controller/PLCI/NCCI            = 0x101
      InfoNumber                      = 0x1e
      InfoElement                     = <82 88>
    
    INFO_RESP ID=001 #0x8391 LEN=0012
      Controller/PLCI/NCCI            = 0x101
    
        -- ISDN1: info element PI 82 88
           > ISDN1: In-band information available
    CONNECT_B3_REQ ID=001 #0x01c3 LEN=0013
      Controller/PLCI/NCCI            = 0x101
      NCPI                            = default
    
        -- ISDN1: sent CONNECT_B3_REQ PLCI=0x101
        -- CAPI/ISDN1/08001721212-3 is ringing
    CONNECT_B3_CONF ID=001 #0x01c3 LEN=0014
      Controller/PLCI/NCCI            = 0x10101
      Info                            = 0x0
    
    CONNECT_B3_ACTIVE_IND ID=001 #0x8392 LEN=0013
      Controller/PLCI/NCCI            = 0x10101
      NCPI                            = default
    
    CONNECT_B3_ACTIVE_RESP ID=001 #0x8392 LEN=0012
      Controller/PLCI/NCCI            = 0x10101
    
        -- CAPI/ISDN1/08001721212-3 is making progress passing it to SCCP/79051-0000000f
    

    Ich hoffe also auf eure Hilfe :) Wenn noch andere Informationen interessant sind, einfach Bescheid sagen.

    fs
     
  9. armincm

    armincm Aktives Mitglied

    Registriert seit:
    3 Aug. 2005
    Beiträge:
    1,006
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Also das ist eindeutig und hat weder mit Asterisk noch mit chan_capi zu tun. Das 'Warten' kommt vom ISDN selbst. Die Vermittlungsstelle meldet das 'ringing'/'alerting' erst so spaet.
    Versuch mal ob sich was aendert, wenn du auf overlap gehst, also dial parameter /bo
    Ich werde in neueren Versionen von chan_capi mal das sending-complete bei
    nicht-overlap aktivieren, das koennte auch in solchen Faellen helfen.

    Armin