Hallo Karsten,
Karsten Keil
On Tue, May 16, 2006 at 06:52:15PM +0200, Christian Wittmer wrote:
Hallo Karsten,
hier das LOG im Anhang. Ich schicke es nur Dir, da ich die Daten nicht an die Liste schicken will.
OK.
1. Um was für einen Anschluss handelt es sich genau ? Es ist ein Anlagen-Anschluß. Der C4 hängt direkt am NTBA.
2. Auswertung: ... May 16 16:44:07 srv-ux-0001 kernel: kcapi: put [0x1] LISTEN_REQ ID=001 #0x0048 LEN=0026 May 16 16:44:07 srv-ux-0001 kernel: Controller/PLCI/NCCI =
May 16 16:44:07 srv-ux-0001 kernel: InfoMask = 0x40 May 16 16:44:07 srv-ux-0001 kernel: CIPmask = 0x1fff03ff May 16 16:44:07 srv-ux-0001 kernel: CIPmask2 = 0x0 May 16 16:44:07 srv-ux-0001 kernel: CallingPartyNumber = default May 16 16:44:07 srv-ux-0001 kernel: CallingPartySubaddress = default May 16 16:44:07 srv-ux-0001 kernel: May 16 16:44:07 srv-ux-0001 kernel: kcapi: got [0x1] LISTEN_CONF ID=001 #0x0048 LEN=0014 May 16 16:44:07 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x1 May 16 16:44:07 srv-ux-0001 kernel: Info = 0x0 May 16 16:44:07 srv-ux-0001 kernel: May 16 16:44:07 srv-ux-0001 kernel: kcapi: put [0x2] LISTEN_REQ ID=001 #0x0048 LEN=0026 May 16 16:44:07 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x2 May 16 16:44:07 srv-ux-0001 kernel: InfoMask = 0x40 May 16 16:44:07 srv-ux-0001 kernel: CIPmask = 0x1fff03ff May 16 16:44:07 srv-ux-0001 kernel: CIPmask2 = 0x0 May 16 16:44:07 srv-ux-0001 kernel: CallingPartyNumber = default May 16 16:44:07 srv-ux-0001 kernel: CallingPartySubaddress = default May 16 16:44:07 srv-ux-0001 kernel: May 16 16:44:07 srv-ux-0001 kernel: kcapi: put [0x3] LISTEN_REQ ID=001 #0x0048 LEN=0026 May 16 16:44:07 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x3 May 16 16:44:07 srv-ux-0001 kernel: InfoMask = 0x40 May 16 16:44:07 srv-ux-0001 kernel: CIPmask = 0x1fff03ff May 16 16:44:07 srv-ux-0001 kernel: CIPmask2 = 0x0 May 16 16:44:07 srv-ux-0001 kernel: CallingPartyNumber = default May 16 16:44:07 srv-ux-0001 kernel: CallingPartySubaddress = default May 16 16:44:07 srv-ux-0001 kernel: May 16 16:44:07 srv-ux-0001 kernel: kcapi: put [0x4] LISTEN_REQ ID=001 #0x0048 LEN=0026 May 16 16:44:07 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x4 May 16 16:44:07 srv-ux-0001 kernel: InfoMask = 0x40 May 16 16:44:07 srv-ux-0001 kernel: CIPmask = 0x1fff03ff May 16 16:44:07 srv-ux-0001 kernel: CIPmask2 = 0x0 May 16 16:44:07 srv-ux-0001 kernel: CallingPartyNumber = default May 16 16:44:07 srv-ux-0001 kernel: CallingPartySubaddress = default May 16 16:44:07 srv-ux-0001 kernel: May 16 16:44:07 srv-ux-0001 kernel: kcapi: got [0x2] LISTEN_CONF ID=001 #0x0048 LEN=0014 May 16 16:44:07 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x2 May 16 16:44:07 srv-ux-0001 kernel: Info = 0x0 May 16 16:44:07 srv-ux-0001 kernel: May 16 16:44:07 srv-ux-0001 kernel: kcapi: got [0x3] LISTEN_CONF ID=001 #0x0048 LEN=0014 May 16 16:44:07 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x3 May 16 16:44:07 srv-ux-0001 kernel: Info = 0x0 May 16 16:44:07 srv-ux-0001 kernel: May 16 16:44:07 srv-ux-0001 kernel: kcapi: got [0x4] LISTEN_CONF ID=001 #0x0048 LEN=0014 May 16 16:44:07 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x4 May 16 16:44:07 srv-ux-0001 kernel: Info = 0x0 May 16 16:44:07 srv-ux-0001 kernel:
Applikation 1 schickt an alle 4 Controller einen LISTEN REQ für
0x1 praktisch
alle Anrufe, das ist die capidrv Application für I4L. ...
May 16 16:45:21 srv-ux-0001 kernel: kcapi: put [0x4] LISTEN_REQ ID=002 #0x0001 LEN=0026 May 16 16:45:21 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x4 May 16 16:45:21 srv-ux-0001 kernel: InfoMask = 0x7ff May 16 16:45:21 srv-ux-0001 kernel: CIPmask = 0x10012 May 16 16:45:21 srv-ux-0001 kernel: CIPmask2 = 0x0 May 16 16:45:21 srv-ux-0001 kernel: CallingPartyNumber = default May 16 16:45:21 srv-ux-0001 kernel: CallingPartySubaddress = default May 16 16:45:21 srv-ux-0001 kernel: May 16 16:45:21 srv-ux-0001 kernel: kcapi: got [0x4] LISTEN_CONF ID=002 #0x0001 LEN=0014 May 16 16:45:21 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x4 May 16 16:45:21 srv-ux-0001 kernel: Info = 0x0 May 16 16:45:21 srv-ux-0001 kernel:
Eine 2. Applikation (ich nehme an der CAPRI Server) schickt auch ein LISTEN, aber nur für Controller Nr. 4
Service: Voice,Audio,Telephonie Das ist so korrekt, denn der User ist laut capri.aut an Conroller 4 gebunden.
May 16 16:45:21 srv-ux-0001 kernel: kcapi: put [0x4] FACILITY_REQ ID=002 #0x0002 LEN=0018 May 16 16:45:21 srv-ux-0001 kernel: Controller/PLCI/NCCI =
0x4
May 16 16:45:21 srv-ux-0001 kernel: FacilitySelector = 0x3 May 16 16:45:21 srv-ux-0001 kernel: FacilityRequestParameter = <00 00 00> May 16 16:45:21 srv-ux-0001 kernel: May 16 16:45:21 srv-ux-0001 kernel: kcapi: got [0x4] FACILITY_CONF ID=002 #0x0002 LEN=0026 May 16 16:45:21 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x4 May 16 16:45:21 srv-ux-0001 kernel: Info = 0x0 May 16 16:45:21 srv-ux-0001 kernel: FacilitySelector = 0x3 May 16 16:45:21 srv-ux-0001 kernel: FacilityConfirmationParameter = <00 00 06 00 00>\377<03 00 00> May 16 16:45:21 srv-ux-0001 kernel:
Die Applikation 2 fragt die supporteten Supplementary Services ab. ... May 16 16:46:01 srv-ux-0001 kernel: kcapi: got [0x4] CONNECT_IND ID=001 #0x0023 LEN=0049 May 16 16:46:01 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x104 May 16 16:46:01 srv-ux-0001 kernel: CIPValue = 0x1 May 16 16:46:01 srv-ux-0001 kernel: CalledPartyNumber = ?6053911 May 16 16:46:01 srv-ux-0001 kernel: CallingPartyNumber = <21 81>6227385160 May 16 16:46:01 srv-ux-0001 kernel: CalledPartySubaddress = default May 16 16:46:01 srv-ux-0001 kernel: CallingPartySubaddress = default May 16 16:46:01 srv-ux-0001 kernel: BC = <80 90 a3> May 16 16:46:01 srv-ux-0001 kernel: LLC = <80 90 a3> May 16 16:46:01 srv-ux-0001 kernel: HLC = default May 16 16:46:01 srv-ux-0001 kernel: AdditionalInfo = default May 16 16:46:01 srv-ux-0001 kernel: May 16 16:46:01 srv-ux-0001 kernel: kcapi: got [0x4] CONNECT_IND ID=002 #0x0024 LEN=0049 May 16 16:46:01 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x104 May 16 16:46:01 srv-ux-0001 kernel: CIPValue = 0x1 May 16 16:46:01 srv-ux-0001 kernel: CalledPartyNumber = ?6053911 May 16 16:46:01 srv-ux-0001 kernel: CallingPartyNumber = <21 81>6227385160 May 16 16:46:01 srv-ux-0001 kernel: CalledPartySubaddress = default May 16 16:46:01 srv-ux-0001 kernel: CallingPartySubaddress = default May 16 16:46:01 srv-ux-0001 kernel: BC = <80 90 a3> May 16 16:46:01 srv-ux-0001 kernel: LLC = <80 90 a3> May 16 16:46:01 srv-ux-0001 kernel: HLC = default May 16 16:46:01 srv-ux-0001 kernel: AdditionalInfo = default May 16 16:46:01 srv-ux-0001 kernel:
Ein Voice CALL von Controller 4 wird an Appl. 01 und 02 gemeldet
May 16 16:46:01 srv-ux-0001 kernel: capidrv-4: incoming call 6227385160,1,0,6053911 May 16 16:46:01 srv-ux-0001 kernel: kcapi: got [0x4] INFO_IND ID=002 #0x0025 LEN=0023 May 16 16:46:01 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x104 May 16 16:46:01 srv-ux-0001 kernel: InfoNumber = 0x70 May 16 16:46:01 srv-ux-0001 kernel: InfoElement = ?6053911 May 16 16:46:01 srv-ux-0001 kernel: May 16 16:46:01 srv-ux-0001 kernel: isdn_net: call from 6227385160 -> 3 6053911 ignored May 16 16:46:01 srv-ux-0001 kernel: kcapi: got [0x4] INFO_IND ID=002 #0x0026 LEN=0016 May 16 16:46:01 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x104 May 16 16:46:01 srv-ux-0001 kernel: InfoNumber = 0x18 May 16 16:46:01 srv-ux-0001 kernel: InfoElement = <89> May 16 16:46:01 srv-ux-0001 kernel:
An Appl 2 gehen noch die Zusatzinfos ueber Nr. und Channel.
May 16 16:46:01 srv-ux-0001 kernel: kcapi: put [0x4] MANUFACTURER_IND ID=002 #0x0000 LEN=0031 May 16 16:46:01 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x4 May 16 16:46:01 srv-ux-0001 kernel: ManuID = 0x214d5641 May 16 16:46:01 srv-ux-0001 kernel: Class = 0x0 May 16 16:46:01 srv-ux-0001 kernel: Function = 0x1 May 16 16:46:01 srv-ux-0001 kernel: ManuData = <80 08 02 01 01 16>
Hier fehlt was im LOG, wahrscheinlich zuviele LogInfos auf einmal. Es war wahrscheinlich ein CONNECT_RESP der 1. Appl (capidrv) das sie den CALL nicht will.
May 16 16:46:01 srv-ux-0001 kernel: default May 16 16:46:01 srv-ux-0001 kernel: LLC = <80 90 a3> May 16 16:46:01 srv-ux-0001 kernel: AdditionalInfo = default May 16 16:46:01 srv-ux-0001 kernel: May 16 16:46:01 srv-ux-0001 kernel: capidrv-4: incoming call 6227385160,1,0,6053911 ignored May 16 16:46:01 srv-ux-0001 kernel: kcapi: got [0x4] DISCONNECT_IND ID=001 #0x0027 LEN=0014 May 16 16:46:01 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x104 May 16 16:46:01 srv-ux-0001 kernel: Reason = 0x0 May 16 16:46:01 srv-ux-0001 kernel: May 16 16:46:01 srv-ux-0001 kernel: kcapi: put [0x4] DISCONNECT_RESP ID=001 #0x0027 LEN=0012 May 16 16:46:01 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x104 May 16 16:46:01 srv-ux-0001 kernel:
Die erste Applikation wird disconnected. ...
May 16 16:46:11 srv-ux-0001 kernel: kcapi: got [0x4] DISCONNECT_IND ID=002 #0x0028 LEN=0014 May 16 16:46:11 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x104 May 16 16:46:11 srv-ux-0001 kernel: Reason = 0x0 May 16 16:46:11 srv-ux-0001 kernel:
Der Call wurde von der anderen Seite aufgelegt und Appl.2 wird disconnected. Andere Seite ist der Anrufer ? Ja, der hat aufgelegt, weil er "Dienst oder Dienstmerkmal nich verfügbar" gehört hat.
... May 16 16:48:01 srv-ux-0001 kernel: May 16 16:48:01 srv-ux-0001 kernel: kcapi: got [0x2] CONNECT_IND ID=001 #0x0029 LEN=0049 May 16 16:48:01 srv-ux-0001 kernel: Controller/PLCI/NCCI = 0x102 May 16 16:48:01 srv-ux-0001 kernel: CIPValue = 0x1 May 16 16:48:01 srv-ux-0001 kernel: CalledPartyNumber = ?6053911 May 16 16:48:01 srv-ux-0001 kernel: CallingPartyNumber = <21 81>6227385160 May 16 16:48:01 srv-ux-0001 kernel: CalledPartySubaddress = default May 16 16:48:01 srv-ux-0001 kernel: CallingPartySubaddress = default May 16 16:48:01 srv-ux-0001 kernel: BC = <80 90 a3> May 16 16:48:01 srv-ux-0001 kernel: LLC = <80 90 a3> May 16 16:48:01 srv-ux-0001 kernel: HLC = default May 16 16:48:01 srv-ux-0001 kernel: AdditionalInfo = default May 16 16:48:01 srv-ux-0001 kernel:
Ein Voice CALL von Controller 2 wird an Appl. 01 gemeldet, Appliktion 2 nicht, da diese nur auf Controller 4 ein LISTEN abgesetzt hat. Schlecht, da die gerufene Nummer "6053911" ja wirklich auch nur an Controller 4 lauscht. (User ist laut capri.aut mit seiner Rufnummer an Controller 4 gebunden)
May 16 16:48:01 srv-ux-0001 kernel: capidrv-2: incoming call 6227385160,1,0,6053911 May 16 16:48:01 srv-ux-0001 kernel: isdn_net: call from 6227385160 -> 1 6053911 ignored May 16 16:48:01 srv-ux-0001 kernel: isdn_tty: call from 6227385160 -> 6053911 ignored May 16 16:48:01 srv-ux-0001 kernel: kcapi: put [0x2] CONNECT_RESP ID=001 #0x0029 LEN=0031 May 16 16:48:01 srv-ux-0001 kernel: Controller/PLCI/NCCI =
0x102
May 16 16:48:01 srv-ux-0001 kernel: Reject = 0x1 May 16 16:48:01 srv-ux-0001 kernel: BProtocol May 16 16:48:01 srv-ux-0001 kernel: B1protocol = 0x0 May 16 16:48:01 srv-ux-0001 kernel: B2protocol = 0x0 May 16 16:48:01 srv-ux-0001 kernel: B3protocol = 0x0 May 16 16:48:01 srv-ux-0001 kernel: B1configuration = default May 16 16:48:01 srv-ux-0001 kernel: B2configuration = default May 16 16:48:01 srv-ux-0001 kernel: B3configuration = default May 16 16:48:01 srv-ux-0001 kernel: ConnectedNumber = default May 16 16:48:01 srv-ux-0001 kernel: ConnectedSubaddress = default May 16 16:48:01 srv-ux-0001 kernel: LLC = <80 90 a3> May 16 16:48:01 srv-ux-0001 kernel: AdditionalInfo = default May 16 16:48:01 srv-ux-0001 kernel:
Appl. 01 (capidrv) REJECTED den CALL.
Das sieht erstmal so nicht verkehrt aus. Das sehe ich ein. Nach Deiner ausführlichen Erklärung komme ich zu dem Schluß, den Controller über eine TK-Anlage zu schalten. Dann kann ich, wenn ich alles richtig verstanden habe, den kommended Ruf an den richtigen Controller weiterleiten. Dann sollte es doch funktionieren, oder ?
Oder kann ich ein LISTEN der Applikation 1 an allen Controllern verhindern, denn ausreichend wäre doch ein LISTEN der Applikation 2 (CAPRI-Server), denn die setzt ja nur ein LISTEN an Controller 4 ab. Danke für die Hilfe. Gruß Christian
-- Karsten Keil SuSE Labs ISDN development