bestimmte Nummern nicht erreichbar

tjonest

Neuer User
Mitglied seit
28 Feb 2006
Beiträge
43
Punkte für Reaktionen
0
Punkte
0
Hallo ,

erstmal meine Konfiguration:
Asterisk 1.2.14-BRIstuffed-0.3.0-PRE-1x
2 HFC QuadBri Karten; 1 Karte an 3 Anlagenanschlüssen und einem interner S0; 2. Karte bediente ehemals eine alte Telefonanlage

zapata.conf:
Code:
language = de
pridialplan = unknown
prilocaldialplan = local
nationalprefix = 0
internationalprefix = 00
echocancel = yes
echocancelwhenbridged=no
echotraining=400
immediate = no
usecallerid = yes
priindication = outofband

; ISDN quadBRI interfaces

priindication = outofband
switchtype = euroisdn           ;ptp TE auf Anlagenanschluss
signalling = bri_cpe
pridialplan = unknown
group = 1
context=incomingisdnpre
overlapdial = yes
immediate  = no
channel => 13-14
channel => 16-17
channel => 19-20


switchtype = euroisdn           ;ptp NT an alte Anlage
signalling = bri_net
pridialplan = unknown
priindication = outofband
overlapdial = yes
immediate  = no
group = 2
context=default
;channel => 1,2
;channel => 4-5
;channel => 7-8



switchtype = euroisdn           ;ptmp NT frei bei Karte Anlagenanschluss ptp TE
signalling = bri_net_ptmp
pridialplan = unknown
priindication = outofband
overlapdial = yes
immediate  = no
group = 3
context=default
channel => 22-23


switchtype = euroisdn           ;ptmp NT frei bei Karte ptp NT alte Anlage
signalling = bri_net_ptmp
pridialplan = unknown
priindication = outofband
overlapdial = yes
immediate  = no
group = 4
context=default
channel => 10-11


entsprechender Teil der extensions.conf:

Code:
[outgoingisdn]
exten => _0XX.,1,SetCallerPres(allowed_passed_screen)
exten => _0XX.,2,Dial(Zap/r1/${EXTEN:1},60,Tto) ;rauswaehlen
exten => _0XX.,3,Congestion
exten => _0XX.,4,Hangup
exten => _0XX.,103,Busy

Folgendes Problem taucht bei Faxen zu bestimmten Rufnummern auf:

Code:
    -- Executing SetCallerPres("SIP/34-b6e03608", "allowed_passed_screen") in new stack
    -- Executing Dial("SIP/34-b6e03608", "Zap/r1/0XXXXXXXX|60|Tto") in new stack
    -- Requested transfer capability: 0x00 - SPEECH
    -- Called r1/0XXXXXXXX
 Extension Changed 34 new state InUse for Notify User 10
    -- Zap/16-1 is proceeding passing it to SIP/34-b6e03608
    -- Channel 0/1, span 6 got hangup request
    -- Channel 0/1, span 6 received AOC-E charging 0 units
    -- Hungup 'Zap/16-1'
  == Everyone is busy/congested at this time (1:0/0/1)
    -- Executing Busy("SIP/34-b6e03608", "") in new stack

Die Rufnummern bei denen das Problem auftritt haben alle die gleiche Vorwahl, und gehören zu unterschiedlichen Anschlüssen/Firmen. Mit einem Fax, das über eine eumex100, direkt an einem ptmp ISDN hängt, kann ich aber Faxe an diesen Anschluss schicken. Ebenso erreiche/höre ich die Faxgeräte wenn ich diese mit einem ISDN Telefon (direkt an einem NTBA) anrufe. Mit einem Sip Telefon über den Asterisk tritt wieder obiges Problem auf.

Gruß
Jones
 
ein Nachtrag:

bei 2 von den drei Asterisk Servern habe ich die Faxe, an die "nicht funktionierenden" Rufnummern, jetzt mal über einen SIP Provider (Bellshare.com), nicht über ZAP, raus geschickt: Die Faxe kommen an! Allerdings mit der typischen Zuverlässigkeit von Faxen über externe SIP Provider. Jemand ne Idee?

Gruß
Jones
 
Hat niemand eine Idee?
 
Mach mal ein "pri debug span x", dabei x durch den Port an der Karte ersetzen. So sehe ich erstmal keinen Fehler.
 
Hallo,

hier der Debug:

Code:
@    -- Executing [[1;36;40mSetCallerPres[[0;37;40m("[[1;35;40mOSS/dsp[[0;37;40m", "[[1;35;40mprohib[[0;37;40m") in new stack
@    -- Executing [[1;36;40mSet[[0;37;40m("[[1;35;40mOSS/dsp[[0;37;40m", "[[1;35;40mCALLERID(number)=96550[[0;37;40m") in new stack
@    -- Executing [[1;36;40mDial[[0;37;40m("[[1;35;40mOSS/dsp[[0;37;40m", "[[1;35;40mZap/r1/65671209|60|Tto[[0;37;40m") in new stack
@6 -- Making new call for cr 177
@    -- Requested transfer capability: 0x00 - SPEECH
@6 > Protocol Discriminator: Q.931 (8)  len=32
@6 > Call Ref: len= 1 (reference 49/0x31) (Originator)
@6 > Message type: SETUP (5)
@6 > [04 03 80 90 a3]
@6 > Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: Speech (0)
@6 >                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
@6 >                              Ext: 1  User information layer 1: A-Law (35)
@6 > [18 01 89]
@6 > Channel ID (len= 3) [ Ext: 1  IntID: Implicit, Other Spare: 0, Exclusive Dchan: 0
@6 >                        ChanSel: B1 channel
@6                          ]
@6 > [6c 07 41 81 39 36 35 35 30]
@6 > Calling Number (len= 9) [ Ext: 0  TON: Subscriber Number (4)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
@6 >                           Presentation: Presentation permitted, user number passed network screening (1) '96550' ]
@6 > [70 09 80 36 35 36 37 31 32 30 39]
@6 > Called Number (len=11) [ Ext: 1  TON: Unknown Number Type (0)  NPI: Unknown Number Plan (0) '65671209' ]
@    -- Called r1/65671209
@Apr 27 09:00:25 [[1;31;40mWARNING[[0;37;40m[19506]: [[1;37;40mchan_oss.c[[0;37;40m:[[1;37;40m585[[0;37;40m [[1;37;40msetformat[[0;37;40m: @Unable to re-ope
@6 < Protocol Discriminator: Q.931 (8)  len=7
@6 < Call Ref: len= 1 (reference 177/0xB1) (Terminator)
@6 < Message type: CALL PROCEEDING (2)
@6 < [18 01 89]
@6 < Channel ID (len= 3) [ Ext: 1  IntID: Implicit, Other Spare: 0, Exclusive Dchan: 0
@6 <                        ChanSel: B1 channel
@6                          ]
@6 -- Processing IE 24 (cs0, Channel Identification)
@    -- Zap/16-1 is proceeding passing it to OSS/dsp
@Apr 27 09:00:25 [[1;31;40mWARNING[[0;37;40m[19506]: [[1;37;40mchan_oss.c[[0;37;40m:[[1;37;40m859[[0;37;40m [[1;37;40moss_indicate[[0;37;40m: @Don't know ho
@6 < Protocol Discriminator: Q.931 (8)  len=16
@6 < Call Ref: len= 1 (reference 177/0xB1) (Terminator)
@6 < Message type: DISCONNECT (69)
@6 < [08 02 82 81]
@6 < Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Public network serving the local user (2)
@6 <                  Ext: 1  Cause: Unallocated (unassigned) number (1), class = Normal Event (0) ]
@6 < [1e 02 82 88]
@6 < Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Public network serving the local user (2)
@6 <                               Ext: 1  Progress Description: Inband information or appropriate pattern now available. (8) ]
@6 < [1e 02 82 82]
@6 < Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Public network serving the local user (2)
@6 <                               Ext: 1  Progress Description: Called equipment is non-ISDN. (2) ]
@6 -- Processing IE 8 (cs0, Cause)
@6 -- Processing IE 30 (cs0, Progress Indicator)
@6 -- Processing IE 30 (cs0, Progress Indicator)
@    -- Channel 0/1, span 6 got hangup request
@    -- Channel 0/1, span 6 received AOC-E charging 0 units
@6 NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Disconnect Indication, peerstate Disconnect Request
@6 > Protocol Discriminator: Q.931 (8)  len=8
@6 > Call Ref: len= 1 (reference 49/0x31) (Originator)
@6 > Message type: RELEASE (77)
@6 > [08 02 81 81]
@6 > Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the local user (1)
@6 >                  Ext: 1  Cause: Unallocated (unassigned) number (1), class = Normal Event (0) ]
@    -- Hungup 'Zap/16-1'
@  == Everyone is busy/congested at this time (1:0/0/1)
@    -- Executing [[1;36;40mBusy[[0;37;40m("[[1;35;40mOSS/dsp[[0;37;40m", "[[1;35;40m[[0;37;40m") in new stack
@6 < Protocol Discriminator: Q.931 (8)  len=4
@6 < Call Ref: len= 1 (reference 177/0xB1) (Terminator)
@6 < Message type: RELEASE COMPLETE (90)
@6 NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
@6 NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null
@Apr 27 09:00:25 [[1;31;40mWARNING[[0;37;40m[25097]: [[1;37;40mchan_zap.c[[0;37;40m:[[1;37;40m8485[[0;37;40m [[1;37;40mpri_fixup_principle[[0;37;40m: @Call

Den "Anruf" habe ich von der Konsole aus getätigt.
Danke und Gruß
Jones
 
tjonest schrieb:
Cause: Unallocated (unassigned) number (1)

Diese Nachricht bekommst Du vom Amt zurück. Nummer 65671209 ist also nicht vergeben. Mögliche fehlerquellen: pridialplan (was ich übrigens nur ein Mal in der zapata.conf habe, nicht mehrfach). Bei mir steht in der zapata.conf folgendes:
pridialplan=unknown
prilocaldialplan=dynamic
Was passiert, wenn Du die Nummer mit Vorwahl anrufst? Klappt es dann?
 
Hallo,

so:

Code:
Aster-MuF-Roemer*CLI> dial 0XXXXXXXXXX@outgoingisdnCLIR
    -- Executing SetCallerPres("OSS/dsp", "prohib") in new stack
    -- Executing Set("OSS/dsp", "CALLERID(number)=9XXXXX") in new stack
    -- Executing Dial("OSS/dsp", "Zap/r1/0XXXXXXXXXX|60|Tto") in new stack
6 -- Making new call for cr 221
    -- Requested transfer capability: 0x00 - SPEECH
6 > Protocol Discriminator: Q.931 (8)  len=33
6 > Call Ref: len= 1 (reference 93/0x5D) (Originator)
6 > Message type: SETUP (5)
6 > [04 03 80 90 a3]>
6 > Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: Speech (0)
6 >                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
6 >                              Ext: 1  User information layer 1: A-Law (35)
6 > [18 01 89]er*CLI>
6 > Channel ID (len= 3) [ Ext: 1  IntID: Implicit, Other Spare: 0, Exclusive Dchan: 0
6 >                        ChanSel: B1 channel
6                          ]
6 > [6c 07 41 81 39 36 35 35 30]
6 > Calling Number (len= 9) [ Ext: 0  TON: Subscriber Number (4)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
6 >                           Presentation: Presentation permitted, user number passed network screening (1) 'YYYYYYY' ]
6 > [70 0a 80 30 36 35 36 37 31 32 30 39]
6 > Called Number (len=12) [ Ext: 1  TON: Unknown Number Type (0)  NPI: Unknown Number Plan (0) '0XXXXXXXXXX' ]
    -- Called r1/0XXXXXXXX
Apr 27 13:04:00 WARNING[23386]: chan_oss.c:585 setformat: Unable to re-open DSP device /dev/dsp: No such file or directory
6 < Protocol Discriminator: Q.931 (8)  len=7
6 < Call Ref: len= 1 (reference 221/0xDD) (Terminator)
6 < Message type: SETUP ACKNOWLEDGE (13)
6 < [18 01 89]
6 < Channel ID (len= 3) [ Ext: 1  IntID: Implicit, Other Spare: 0, Exclusive Dchan: 0
6 <                        ChanSel: B1 channel
6                          ]
6 -- Processing IE 24 (cs0, Channel Identification)
6 < Protocol Discriminator: Q.931 (8)  len=4
6 < Call Ref: len= 1 (reference 221/0xDD) (Terminator)
6 < Message type: CALL PROCEEDING (2)
    -- Zap/16-1 is proceeding passing it to OSS/dsp
Apr 27 13:04:00 WARNING[23386]: chan_oss.c:859 oss_indicate: Don't know how to display condition 15 on OSS/dsp
Apr 27 13:04:01 WARNING[23386]: chan_oss.c:585 setformat: Unable to re-open DSP device /dev/dsp: No such file or directory
Apr 27 13:04:02 WARNING[23386]: chan_oss.c:585 setformat: Unable to re-open DSP device /dev/dsp: No such file or directory
Apr 27 13:04:03 WARNING[23386]: chan_oss.c:585 setformat: Unable to re-open DSP device /dev/dsp: No such file or directory
Apr 27 13:04:04 WARNING[23386]: chan_oss.c:585 setformat: Unable to re-open DSP device /dev/dsp: No such file or directory
Apr 27 13:04:05 WARNING[23386]: chan_oss.c:585 setformat: Unable to re-open DSP device /dev/dsp: No such file or directory
Apr 27 13:04:06 WARNING[23386]: chan_oss.c:585 setformat: Unable to re-open DSP device /dev/dsp: No such file or directory
6 < Protocol Discriminator: Q.931 (8)  len=16
6 < Call Ref: len= 1 (reference 221/0xDD) (Terminator)
6 < Message type: DISCONNECT (69)
6 < [08 02 80 d8]
6 < Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: User (0)
6 <                  Ext: 1  Cause: Incompatible destination (88), class = Invalid message (5) ]
6 < [1e 02 82 88]
6 < Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Public network serving the local user (2)
6 <                               Ext: 1  Progress Description: Inband information or appropriate pattern now available. (8) ]
6 < [1e 02 82 82]
6 < Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Public network serving the local user (2)
6 <                               Ext: 1  Progress Description: Called equipment is non-ISDN. (2) ]
6 -- Processing IE 8 (cs0, Cause)
6 -- Processing IE 30 (cs0, Progress Indicator)
6 -- Processing IE 30 (cs0, Progress Indicator)
    -- Channel 0/1, span 6 got hangup request
    -- Channel 0/1, span 6 received AOC-E charging 0 units
6 NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Disconnect Indication, peerstate Disconnect Request
6 > Protocol Discriminator: Q.931 (8)  len=8
6 > Call Ref: len= 1 (reference 93/0x5D) (Originator)
6 > Message type: RELEASE (77)
6 > [08 02 81 d8]
6 > Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the local user (1)
6 >                  Ext: 1  Cause: Incompatible destination (88), class = Invalid message (5) ]
    -- Hungup 'Zap/16-1'
  == Everyone is busy/congested at this time (1:0/0/1)
    -- Executing Busy("OSS/dsp", "") in new stack
6 < Protocol Discriminator: Q.931 (8)  len=4
6 < Call Ref: len= 1 (reference 221/0xDD) (Terminator)
6 < Message type: RELEASE COMPLETE (90)
6 NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
6 NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null

"Incompatible destination" - Ne Idee?

Du hast recht pridialplan und prilocaldialplan sind globale Einstellungen in der zapata.conf. Meine mehrfach Angaben machen also keinen Sinn.

Schonmal Danke im Voraus für die Bemühungen!
Gruß
Jones
 
Zuletzt bearbeitet:
Hallo,

an einem normalen ISDN-Anschluß an einer normalen Vermittlungsstelle sollte
Code:
pridialplan=unknown
prilocaldialplan=unknown
zuverlässig funktionieren. Damit überläßt man der Vermittlungsstelle das Interpretieren der gesendeten Rufnummer. "international" wird von vielen Vermittlungsstellen nicht akzeptiert, selbst wann man die Rufnummer inkl. Ländervorwahl sendet. Mit "local" kann man häufig nicht mehr in Mobilfunknetze telefonieren und mit "national" entsprechend meistens keine Auslandsgespräche mehr führen.

Gruß
Henning

P.S. Die Aussage gilt nicht für Anlagenanschlüsse mit dem Leistungsmerkmal "CLIP no screening" ;)
 
Hallo,

>>Darf ich nach dem Anschlussanbieter fragen?
Anschlußanbieter ist die Telekom.

>>Das bedeutet wohl soviel wie pridialplan falsch (andere Erklärung hab ich dafür zumindest nicht).
Obwohl es zu anderen Ortsnetzten problemlos funktioniert?

>>Probier mal nacheinander local, national und international für pridialplan.
Mach ich.

Gruß
Jones
 
Hallo,

>>local, national und international
Ich hab die und dynamic jetzt ausprobiert: bei national und international geht überhaupt nichts mehr; bei local und dynamic scheint soweit alles ausser den Problemnummern zu funtionieren.

hat noch jemand einen Ratschlag?
 
Was hängt denn hinter der externen Nummer? 'incompatible destination' bedeutet, daß an der Zielnummer kein passendes Endgerät hängt, also z.B. ein ISDN-Fax, daß mit einem Sprachanruf nichts anfangen kann. Oder auch ein normales Fax hinter einer ungeschickt konfigurierten TK-Anlage.
 
Hallo,

dort wo es nicht funktioniert hängen in allen Fällen analoge Faxgeräte, teilweise hinter einer Anlage. Wir haben hier in der Firma unter anderem noch einen Swyx (Windows Voip Server) Server stehen. Wenn ich das über diesen versuche funktionierts (leider). Mit der "alten" Anlage (Tenovis) hats bei unserem Kunden auch funktioniert, versende ich per Asterisk über einen externen Sip Provider funktionierts auch. Mittlerweile habe ichs auch mit der neuen Bristuff ausprobiert (1y-e), auch hier habe ich die Probleme). Desshalb bin ich leider etwas ratlos. Ich hoffe von euch hat noch jemand eine Idee.

Gruß
Jones
 
Du kannst also nicht über den Asterisk faxen? Geht es denn umgekehrt, also von einer Problemnummer über den Asterisk zu einem Fax? Auch wenn es geht, wie sieht das Setup dann aus? Interessant ist dabei die Bearer Capability, High und Low Layer Capability (BC,HLC,LLC).
 
Hallo,
nur um das nochmal klarzustellen: Ich kann problemlos über meinen Asterisk/Zaptel faxe verschicken! Nur nicht zu den besagten Problemnummern die, so sieht es zumindest momentan aus, alle im gleichen Ortsnetz liegen. Verschicke ich Faxe über meinen Asterisk und lasse diesen über einen externen SIP Provider verschicken kommen die Faxe auch bei den Problemnummern an!

>>Geht es denn umgekehrt, also von einer Problemnummer über den Asterisk zu einem Fax?
Versuche ich und berichte dann.

>> Auch wenn es geht, wie sieht das Setup dann aus? Interessant ist dabei die Bearer Capability, High und Low Layer Capability (BC,HLC,LLC).
Kannst du etwas genauer beschreiben was du wissen willst bzw. wie ich das rausfinde :-) ?

Vielen Dank schonmal im Voraus
Jones
 
clan schrieb:
? 'incompatible destination' bedeutet, daß an der Zielnummer kein passendes Endgerät hängt,

Bei ISDN-Anlagen den entsprechenden Port auf "unbestimmter Dienst" schalten, dann gehts. Wie man das Asterisk beibringt weiss ich nicht.
Die Ursache ist vermutlich, ihr habt Fax eingestellt und die Gegenstelle Sprache, bzw umgedreht.

Das Problem hatte mich mal an einer ISDN-Anlage fast zur Verzweiflung gebracht bis ich die Lösung hatte.
 
Hallo,

Das Problem hatte mich mal an einer ISDN-Anlage fast zur Verzweiflung gebracht bis ich die Lösung hatte.
Kann ich nachvollziehen!

Bei ISDN-Anlagen den entsprechenden Port auf "unbestimmter Dienst" schalten, dann gehts. Wie man das Asterisk beibringt weiss ich nicht.
Die Ursache ist vermutlich, ihr habt Fax eingestellt und die Gegenstelle Sprache, bzw umgedreht.
danke für den Tip. Ich hoffe das ich das veranlassen kann, die Zielfaxe (bzw. die Anlage) stehen nicht unter meinem Zugriff. Interressant wäre natürlich ob man dem Asterisk das beibringen kann?! Die Lösung wäre mir da schon sympathischer, auch um zukünftig solche Probleme angehen zu können. Weis da jemand was :-) ?


Danke und Gruß
 
Hallo,

Auf jeden Fall habt Ihr mich der Lösung näher gebracht:
mit SetTransferCapability(3K1AUDIO) in der Extensions.conf funktionierts! Die Faxe kommen auch bei den Problemnummern an! Sollte das nicht automatisch geschehen wenn ein Fax verschickt wird (über die "Faxtöne" beim versenden)? So richtig schön finde ich die Lösung so noch nicht.

Gruß
 
tjonest schrieb:
mit SetTransferCapability(3K1AUDIO) in der Extensions.conf funktionierts! Sollte das nicht automatisch geschehen wenn ein Fax verschickt wird (über die "Faxtöne" beim versenden)? So richtig schön finde ich die Lösung so noch nicht.

Nein. Wenn du ein Fax verschickst, ist der Dienst Fax und nicht unbestimmt oder Sprache.

Wenn sich alle an die Regeln halten würden und ihre Faxe auf Fax einstellen, würde das funktionieren.
 
tjonest schrieb:
Auf jeden Fall habt Ihr mich der Lösung näher gebracht:
mit SetTransferCapability(3K1AUDIO) in der Extensions.conf funktionierts! Die Faxe kommen auch bei den Problemnummern an! Sollte das nicht automatisch geschehen wenn ein Fax verschickt wird (über die "Faxtöne" beim versenden)? So richtig schön finde ich die Lösung so noch nicht.
Die 'Faxtöne' kommen erst nach dem Verbindungsaufbau, die Verbindung kommt aber garnicht erst zustande. Die Probleme kommen WIMRE daher, daß Sprachverbindungen bei ISDN mit BC=64kBit/s von ISDN-Anschlüssen und mit 3.1kHz Audio von Analog-Anschlüssen signalisiert werden. Da es auch noch einen ISDN-Fax-Standard gibt (G4?) versuchen manche TK-Anlagen, anhand der Dienstekennung ISDN- von Analog-Fax zu unterscheiden. Wenn ein als (Analog-)Fax konfigurierter Port mit der BC 64KBit angerufen wird kann es dann schon mal vorkommen, daß die Verbindung abgelehnt wird, weil die Anlage glaubt, daß ein ISDN-Fax anruft. Bei als Telefon konfigurierten Ports ist das egal. Falls das irgendwie wirr klingt: es ist schon um die 10 Jahre her, daß ich mit dem Problem zu tun hatte, meine Erinnerung mag hier und da etwas verschwommen sein. Die einfachste (einzige?) Lösung ist tatsächlich, beim Faxen per Dienstekennung eine Analogleitung zu simulieren indem man fest 3,1kHz einstellt.
 
Kostenlos!

Statistik des Forums

Themen
248,437
Beiträge
2,291,456
Mitglieder
377,845
Neuestes Mitglied
alienvape