Verzögerung bei abgehenden Telefonaten

Felix.Schwarz

Neuer User
Mitglied seit
16 Feb 2006
Beiträge
12
Punkte für Reaktionen
0
Punkte
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
 
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.
 
Welche Version von chan_capi verwendest Du? Waehlst Du ISDN an, oder ist SIP dein Ziel? Wie sehen denn Deine confs aus?

Armin
 
armincm schrieb:
Welche Version von chan_capi verwendest Du? Waehlst Du ISDN an, oder ist SIP dein Ziel? Wie sehen denn Deine confs aus?

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
 
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
 
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
 
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
 
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
 
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
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.