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

[fiesch]

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:

´ 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.

 

[fiesch]

configs

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

system.conf (dahdi):

# 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)

; [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

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

 

[fiesch]

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

 

[ramarro]

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..

 

[fiesch]

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..