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

[Problem] PRI schneidet bei vereinzelten einkommenden Anrufen die letzten Stellen ab

Dieses Thema im Forum "Asterisk ISDN mit Bristuff (hfc, zaptel)" wurde erstellt von fiesch, 9 Nov. 2011.

  1. fiesch

    fiesch Neuer User

    Registriert seit:
    15 Dez. 2008
    Beiträge:
    6
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Bei eingehenden Rufen auf einer recht neu in Betrieb genommenen Anlage tauchen vereinzelt Probleme bei ankommenden Rufen auf. Nur vereinzelt werden die letzten Stellen der angerufenen Nummer (die intern behandelte) abgeschnitten.

    Ist die eigentlich von aussen gewählte nummer z.B: XXXXXX 9550, so kommt in der Anlage nur XXXXXX 95 an. Das sieht man sogar schon direkt im PRI span:

    Code:
    ´ TEI: 0 State 7(Multi-frame established)
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 < V(A)=0, V(S)=0, V(R)=0
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 < K=7, RC=0, l3_initiated=0, reject_except=0, ack_pend=0
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 < T200_id=0, N200=3, T203_id=16384
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 < [ 02 01 00 00 08 02 00 2c 05 04 03 90 90 a3 18 03 a1 83 89 1e 02 80 83 6c 0c 21 81 38 39 33 31 36 30 39 38 34 33 70 09 c1 33 35 36 33 36 33 39 35 ]
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 < Informational frame:
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 < SAPI: 00  C/R: 1 EA: 0
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 <  TEI: 000        EA: 1
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 < N(S): 000   0: 0
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 < N(R): 000   P: 0
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 < 44 bytes of data
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 < Protocol Discriminator: Q.931 (8)  len=44
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 < TEI=0 Call Ref: len= 2 (reference 44/0x2C) (Sent from originator)
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 < Message Type: SETUP (5)
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 < [04 03 90 90 a3]
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 < Bearer Capability (len= 5) [ Ext: 1  Coding-Std: 0  Info transfer capability: 3.1kHz audio (16)
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 <                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 <                                User information layer 1: A-Law (35)
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 < [18 03 a1 83 89]
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 < Channel ID (len= 5) [ Ext: 1  IntID: Implicit  Other(PRI)  Spare: 0  Preferred  Dchan: 0
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 <                       ChanSel: As indicated in following octets
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 <                       Ext: 1  Coding: 0  Number Specified  Channel Type: 3
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 <                       Ext: 1  Channel: 9 Type: CPE]
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 < [1e 02 80 83]
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 < Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  0: 0  Location: User (0)
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 <                               Ext: 1  Progress Description: Calling equipment is non-ISDN. (3) ]
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 < [6c 0c 21 81 38 39 33 31 36 30 39 38 34 33]
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 < Calling Number (len=14) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 <                           Presentation: Presentation permitted, user number passed network screening (1)  'YYYYYYYYYYY' ]
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 < [70 09 c1 33 35 36 33 36 33 39 35]
    [Nov  9 21:59:37] VERBOSE[19850] chan_dahdi.c: PRI Span: 2 < Called Number (len=11) [ Ext: 1  TON: Subscriber Number (4)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)  'XXXXXX95' ]
    Daten sind wie folgt
    CentOS 2.6.18
    LibPRI 1.4.12
    DAHDI(-complete) 2.4.1
    Asterisk 1.8.8

    auf einer OpenVox DE210E
    DTAG E1 verbunden auf Span2 mit selbstgebasteltem Kabel

    geschätzt 95% der Anrufe klappen, bei den Anrufen die das oben geschilderte Problem zeigen handelt es sich vor allem um Faxanrufe.
    Ich kann es mit einer "knacksenden" Faxleitung von aussen reproduzieren.

    Ich bin leider am Ende meiner Weisheit. Hat jemand eine Idee?

    Habe dazu auch noch ein Problem bei Faxen, ähnlich viele (so 5%) brechen während des Sendens ab, aber das kann ein separates Problem sein.
     
  2. fiesch

    fiesch Neuer User

    Registriert seit:
    15 Dez. 2008
    Beiträge:
    6
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    configs

    Sorry... bringt natürlich nix ohne die configs..

    system.conf (dahdi):
    Code:
    # Autogenerated by /usr/sbin/dahdi_genconf on Tue Nov  8 20:24:44 2011
    # If you edit this file and execute /usr/sbin/dahdi_genconf again,
    # your manual changes will be LOST.
    # Dahdi Configuration File
    #
    # This file is parsed by the Dahdi Configurator, dahdi_cfg
    #
    # Span 1: TE2/0/1 "T2XXP (PCI) Card 0 Span 1" (MASTER) HDB3/CCS/CRC4 ClockSource
    span=1,1,1,ccs,hdb3,crc4
    # termtype: te
    bchan=1-15,17-31
    dchan=16
    #echocanceller=mg2,1-15,17-31
    
    # Span 2: TE2/0/2 "T2XXP (PCI) Card 0 Span 2" HDB3/CCS/CRC4 RED
    span=2,1,1,ccs,hdb3,crc4
    # termtype: te
    bchan=32-46,48-62
    dchan=47
    #echocanceller=mg2,32-46,48-62
    
    # Global data
    
    loadzone        = de
    defaultzone     = de
    
    chan_dahdi_groups.conf (über dahdi-modul freepbx)
    Code:
    ; [span_1]
    signalling=pri_cpe
    switchtype=euroisdn
    pridialplan=national
    prilocaldialplan=national
    group=0
    context=from-pstn
    channel=1-15,17-31
    
    ; [span_2]
    signalling=pri_cpe
    switchtype=euroisdn
    pridialplan=unknown
    prilocaldialplan=unknown
    group=0
    context=from-pstn
    channel=32-46,48-62
    
    chan_dahdi_general_custom.conf
    Code:
    internationalprefix = 00
    nationalprefix = 0
    localprefix = 089
    unknownprefix 0
    priindication = outofband
    usecallerid = yes
    callerid = asreceived
    usecallingpres=yes
    
    Und weitere Info: Leitung sollte passen, lief noch vor 2 Tagen problemlos an einer Swyx mit einer cologne Sigle PRI
     
  3. fiesch

    fiesch Neuer User

    Registriert seit:
    15 Dez. 2008
    Beiträge:
    6
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    #3 fiesch, 11 Nov. 2011
    Zuletzt bearbeitet: 11 Nov. 2011
    Noch weitere infos: Ich hatte zwischenzeitlich auch mal den rxgain Wert der Karte bis auf 5 DB hochgestellt, ohne merkbare Veränderung.
    Das Kabel hab ich auch getauscht durch ein neues, ich hab hier gerade mal einen Wiederstand von 3-4 Ohm auf den einzelnen Andern (1,2,4,5), hier kann ich also eigentlich auch davon ausgehen dass alles OK ist.
    Die Frage ist jetzt woher das Grundproblem kommt.
    Gefühlsmässig würde ich sagen dass die Leitung vom Primärmultiplex-Abschlusspunkt zur PRI Karte gestört ist, mit meinem simplen Multimeter und Kabeldurchgangsprüfer für RJ45 kann ich dass natürlich nur im Ansatz testen.
    Gibt es weitere Meinungen aus der Community?

    Korrektur: Sind natürlich 0,3-0,4 Ohm
     
  4. ramarro

    ramarro Neuer User

    Registriert seit:
    2 Jan. 2012
    Beiträge:
    1
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hallo fiesch,

    eventuell ist dein Problem auf Anrufe zurückzuführen, die nicht per sogenannter Blockwahl wählen. Das passiert, wenn jemand erst den Hörer abnimmt und dann eine Nummer wählt, anstatt die Nummer vorher als ganzes einzugeben. (So arbeiten auch analoge, also z.B. Faxgeräte.)

    Dann passiert es, dass deine Kopfnummer übermittelt und direkt durchgestellt wird. Die weiteren Ziffern der Durchwahl kommen dann nur noch als Tastentöne bei der Telefonanlage an. Das Problem tritt also nur bei Anschlüssen mit Durchwahlnummern (=> PRI) auf.

    Bei Asterisk gibt es extra eine Option, die die Tasteneingaben nach der Durchwahl "abhört" und somit auf die Eingabe der Durchwahl wartet. Die Option heißt overlapdial=yes und gehört (zumindest bei Elastix) in die chan_dahdi.conf. Wenn du diesen Wert änderst, musst du Asterisk beenden und die dahdi-Treiber neuladen, um die neue Konfiguration zu aktivieren.

    Soweit die Theorie. Bei meinen Versuchen mit einer Astribox an einem Elastix-Server mit Asterisk 1.4.36 schaffe ich es mit overlapdial, dass Asterisk die erste Ziffer der Durchwahl abwartet - die zweite wird nur als Tastenton übermittelt. Ich bin schon am verzweifeln: Liegt das Problem an der Astribox, an Asterisk oder gar beim Telefonanbieter? Ich bin dringend auf der Suche nach einem Expertenrat..
     
  5. fiesch

    fiesch Neuer User

    Registriert seit:
    15 Dez. 2008
    Beiträge:
    6
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hi und sorry das ich vergessen hatte diesen Thread zu updaten

    Mein Problem hatte sich Tatsache mit

    overlapdial=yes
    und
    immediate=no

    lösen lassen - das Problem war das die Leitung es "zu gut" meinte und ein frühes routing vor der Übermittlung der kompletten rufnummer zuließ - darauf war asterisk aber nicht vorbereitet..