Lancom ISDN (1000,1100,800) - Gebührenzähler falsch
Moderator: Lancom-Systems Moderatoren
Lancom ISDN (1000,1100,800) - Gebührenzähler falsch
Ich habe bei unserer und alle Kunden-Telefonanlagen immer falsche oder unrealistische Gebühreneinheiten in den Log-Files der Verbindungen gefunden.
Welches ISDN Merkmal verwenden die Lancom Router, um die Anzahl der verbrauchten Einheiten zu registrieren?
Beispiele aus meinem Log:
>>Verb. beendet, Gebühren: 73 Einh., Dauer: 0 Sekunden<<
>>Verb. beendet, Gebuehren: 74 Einh., Dauer: Eine Minute und 31 Sekunden<<
...wohl kaum richtig ...
Welches ISDN Merkmal verwenden die Lancom Router, um die Anzahl der verbrauchten Einheiten zu registrieren?
Beispiele aus meinem Log:
>>Verb. beendet, Gebühren: 73 Einh., Dauer: 0 Sekunden<<
>>Verb. beendet, Gebuehren: 74 Einh., Dauer: Eine Minute und 31 Sekunden<<
...wohl kaum richtig ...
Re: Lancom ISDN (1000,1100,800) - Gebührenzähler falsch
Moin, moin!
Ciao, Georg
Immer diese Abkürzungen. Ich glaub, es war AOCE - Gebührenübermittlung am Ende des Gesprächs. AOCD funktioniert aber auch, denn da kommt am Ende auch noch eine Gebühreninformation.motions hat geschrieben:Welches ISDN Merkmal verwenden die Lancom Router, um die Anzahl der verbrauchten Einheiten zu registrieren?
Ich hab da einen Verdacht, was falsch laufen könnte - kannst du bitte einen D-Kanal-Trace vom Verbindungsende posten?motions hat geschrieben:Beispiele aus meinem Log:
>>Verb. beendet, Gebühren: 73 Einh., Dauer: 0 Sekunden<<
>>Verb. beendet, Gebuehren: 74 Einh., Dauer: Eine Minute und 31 Sekunden<<
Ciao, Georg
Hier der d-kanal-dump des disconnects meiner eigenen Telefonanlage.
Code: Alles auswählen
[D-Kanal-Dump] 2005/03/08 16:11:13,560
RX 21:29:51,560 Frame number : 31
1 0000 00-- SAPI : 0
---- --1- C/R : bit set
---- ---0 EA : bit not set
2 1000 110- TEI : 70
---- ---1 EA : bit set
3 0000 011- N(S) : 3
---- ---0 Type : I-Frame
4 0000 010- N(R) : 2
---- ---0 P/F : bit not set
5 0000 1000 Prot. Discr. : Q.931
6 0000 ---- spare bit(s) : 0x00
---- 0001 Call ref. length : 1
7 1--- ---- CR-Flag : Destination
-110 0010 Call reference value : 98
8 0100 0101 Message Type : DISCONNECT
9 0000 1000 I-Element : Cause
10 0000 0010 length : 2
11 1--- ---- Extension bit : bit set
-00- ---- coding standard : CCITT
---0 ---- spare bit(s) : bit not set
---- 0000 location : user
12 1--- ---- Extension bit : bit set
-001 0000 cause : normal call clearing
13 0001 1100 I-Element : Facility
14 0001 0111 length : 23
15 1--- ---- Extension bit : bit set
-00- ---- spare bit(s) : 0x00
---1 0001 service discrimin. : suppl. service application
16 10-- ---- class : context-specific
--1- ---- form : constructor
---0 0001 component tag : invoke
17 0--- ---- length format : length is one octet
-001 0100 length : 20
HEX-Dump:
18 0x02 0x01 0x11 0x02 0x01 0x24 0x30 0x0C
26 0x30 0x0A 0xA1 0x05 0x30 0x03 0x02 0x01
34 0x01 0x82 0x01 0x00
38 0001 1110 I-Element : Progress indicator
39 0000 0010 length : 2
40 1--- ---- Extension bit : bit set
-00- ---- coding standard : CCITT
---0 ---- spare bit(s) : bit not set
---- 0001 location : priv. netw. serv. local user
41 1--- ---- Extension bit : bit set
-000 1000 progress indication : in-band information now available
________________________________________________________________________________
[D-Kanal-Dump] 2005/03/08 16:11:13,660
TX 21:29:51,660 Frame number : 32
1 0000 00-- SAPI : 0
---- --1- C/R : bit set
---- ---0 EA : bit not set
2 1000 110- TEI : 70
---- ---1 EA : bit set
3 0000 0001 Type : RR
4 0000 100- N(R) : 4
---- ---0 P/F : bit not set
________________________________________________________________________________
[D-Kanal-Dump] 2005/03/08 16:11:13,740
TX 21:29:51,740 Frame number : 33
1 0000 00-- SAPI : 0
---- --0- C/R : bit not set
---- ---0 EA : bit not set
2 1000 110- TEI : 70
---- ---1 EA : bit set
3 0000 010- N(S) : 2
---- ---0 Type : I-Frame
4 0000 100- N(R) : 4
---- ---0 P/F : bit not set
5 0000 1000 Prot. Discr. : Q.931
6 0000 ---- spare bit(s) : 0x00
---- 0001 Call ref. length : 1
7 0--- ---- CR-Flag : Origination
-110 0010 Call reference value : 98
8 0100 1101 Message Type : RELEASE
9 0000 1000 I-Element : Cause
10 0000 0010 length : 2
11 1--- ---- Extension bit : bit set
-00- ---- coding standard : CCITT
---0 ---- spare bit(s) : bit not set
---- 0000 location : user
12 1--- ---- Extension bit : bit set
-001 0000 cause : normal call clearing
________________________________________________________________________________
[D-Kanal-Dump] 2005/03/08 16:11:13,780
RX 21:29:51,780 Frame number : 34
1 0000 00-- SAPI : 0
---- --0- C/R : bit not set
---- ---0 EA : bit not set
2 1000 110- TEI : 70
---- ---1 EA : bit set
3 0000 0001 Type : RR
4 0000 011- N(R) : 3
---- ---0 P/F : bit not set
________________________________________________________________________________
[D-Kanal-Dump] 2005/03/08 16:11:13,810
RX 21:29:51,810 Frame number : 35
1 0000 00-- SAPI : 0
---- --1- C/R : bit set
---- ---0 EA : bit not set
2 1000 110- TEI : 70
---- ---1 EA : bit set
3 0000 100- N(S) : 4
---- ---0 Type : I-Frame
4 0000 011- N(R) : 3
---- ---0 P/F : bit not set
5 0000 1000 Prot. Discr. : Q.931
6 0000 ---- spare bit(s) : 0x00
---- 0001 Call ref. length : 1
7 1--- ---- CR-Flag : Destination
-110 0010 Call reference value : 98
8 0101 1010 Message Type : RELEASE COMPLETE
________________________________________________________________________________
[D-Kanal-Dump] 2005/03/08 16:11:13,880
TX 21:29:51,880 Frame number : 36
1 0000 00-- SAPI : 0
---- --1- C/R : bit set
---- ---0 EA : bit not set
2 1000 110- TEI : 70
---- ---1 EA : bit set
3 0000 0001 Type : RR
4 0000 101- N(R) : 5
---- ---0 P/F : bit not set
Moin, moin!
Nein, war es doch nicht.
Das sollte ganz normal als eine Einheit dekodiert werden. Werden die Verbindungen immer falsch abgerechnet, oder nur gelegentlich?
Ciao, Georg
Nein, war es doch nicht.
Code: Alles auswählen
13 0001 1100 I-Element : Facility
14 0001 0111 length : 23
15 1--- ---- Extension bit : bit set
-00- ---- spare bit(s) : 0x00
---1 0001 service discrimin. : suppl. service application
16 10-- ---- class : context-specific
--1- ---- form : constructor
---0 0001 component tag : invoke
17 0--- ---- length format : length is one octet
-001 0100 length : 20
HEX-Dump:
18 0x02 0x01 0x11 0x02 0x01 0x24 0x30 0x0C
26 0x30 0x0A 0xA1 0x05 0x30 0x03 0x02 0x01
34 0x01 0x82 0x01 0x00
Ciao, Georg
Ach ja, zur Vollständigkeit noch mal die LanMonitor Angaben für obigen Test (die Zeiten zwischen PC und Lancom sind wohl nicht ganz syncron), deshalb bin ich nicht sicher, welcher von beiden Tests es war:
>>Verb. beendet, Gebuehren: 77 Einh., Dauer: Eine Minute und 6 Sekunden
>>Verb. beendet, Gebuehren: 78 Einh., Dauer: 16 Sekunden
Auf jedenfall sind die Gebühreneinheiten nicht korrekt.
Fehlt da also ein Dienstmerkmal der Telefonanlagen bzw. ist inkorrekt oder ist es doch mehr ein Bug in der Firmware, der lange nicht bemerkt wurde?
>>Verb. beendet, Gebuehren: 77 Einh., Dauer: Eine Minute und 6 Sekunden
>>Verb. beendet, Gebuehren: 78 Einh., Dauer: 16 Sekunden
Auf jedenfall sind die Gebühreneinheiten nicht korrekt.
Fehlt da also ein Dienstmerkmal der Telefonanlagen bzw. ist inkorrekt oder ist es doch mehr ein Bug in der Firmware, der lange nicht bemerkt wurde?
Moin, moin!
Ok, die Anzahl der Einheiten steigt von Verbindung zu Verbindung. Ich vermute, das ist einfach nur die Gesamtzahl der bisher aufgelaufenen Einheiten. Was meinen die Exsperten? Ich bin beim LANmonitor auch nur Benutzer.
Ciao, Georg
Wenn man so ein Feature selber nie benutzt ...motions hat geschrieben:>>Verb. beendet, Gebuehren: 77 Einh., Dauer: Eine Minute und 6 Sekunden
>>Verb. beendet, Gebuehren: 78 Einh., Dauer: 16 Sekunden
Ok, die Anzahl der Einheiten steigt von Verbindung zu Verbindung. Ich vermute, das ist einfach nur die Gesamtzahl der bisher aufgelaufenen Einheiten. Was meinen die Exsperten? Ich bin beim LANmonitor auch nur Benutzer.
Ciao, Georg
Ja, das wäre eine mögliche Erklärung. Ich habe gerade mal die Logs einiger Tage durchgesehen und der Tat steigen die Werte an.
Irgendwann wird dann wohl der interne Gebührenzähler wieder zurückgesetzt (wie im Lanconfig definiert).
Also ist es dann eher so zu interpretieren: Stand des internen Gebührenzählers und NICHT die Gebühren der gerade beendeten Verbinding.
So könnte da schon ein Schuh draus werden....
Irgendwann wird dann wohl der interne Gebührenzähler wieder zurückgesetzt (wie im Lanconfig definiert).
Also ist es dann eher so zu interpretieren: Stand des internen Gebührenzählers und NICHT die Gebühren der gerade beendeten Verbinding.
So könnte da schon ein Schuh draus werden....
und eben habe ich noch mal die SysLog Meldungen kontrolliert, welche die Lancoms absetzen:
>>elsaw CONNECTION_INFO: Router state: S0-1-B1 - Ready ; charges for last connection: 93 units
>>elsaw CONNECTION_INFO: Router state: S0-1-B1 - Ready ; charges for last connection: 96 units
Also da bleibt schon was faul: Entweder es ist der fortlaufende interne Zähler (dann müssen die Texte aber zur Klarheit schon etwas angepaßt werden) oder aber die Ausgaben werden dergestallt korrigiert, das zusammen mit der Dauer der letzten Verbindung auch nur die Einheiten dafür angegeben werden.
>>elsaw CONNECTION_INFO: Router state: S0-1-B1 - Ready ; charges for last connection: 93 units
>>elsaw CONNECTION_INFO: Router state: S0-1-B1 - Ready ; charges for last connection: 96 units
Also da bleibt schon was faul: Entweder es ist der fortlaufende interne Zähler (dann müssen die Texte aber zur Klarheit schon etwas angepaßt werden) oder aber die Ausgaben werden dergestallt korrigiert, das zusammen mit der Dauer der letzten Verbindung auch nur die Einheiten dafür angegeben werden.