Date: Thu, 16 Jul 1998 16:26:52 +0200 (METDST) From: hm@hcs.de (Hellmuth Michaelis) To: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies) Cc: freebsd-isdn@FreeBSD.ORG Subject: Re: i4b coexistence with NT on same S0 bus Message-ID: <m0ywozl-0000dfC@hcswork.hcs.de> In-Reply-To: <199807160919.LAA29396@gilberto.physik.RWTH-Aachen.DE> from Christoph Kukulies at "Jul 16, 98 11:19:36 am"
next in thread | previous in thread | raw e-mail | index | archive | help
>From the keyboard of Christoph Kukulies: [this is a long mail .... -hm] > Suddenly, since I installed i4b I'm conflicting with other services > which are using the S0 bus. This used to work smoothly under bisdn. > > Now it seems that a number which is not in the entry section of > /etc/isdn/isdnd.rc is being accepted and then rejected. > > I'm not sure if it's because of the I4BTEL service is configured > to allow anyone call in. OTOH the opposite site is not requesting the > TEL service. > > This trace is showing the unwanted reaction of i4b: Hmm, lets see: > -- NT->TE - unit:0 - frame:000001 - time:15.07 16:11:01.40 - length:40 --------- > Dump:000 02 ff 03 ... > Q921: SAP=0 (Call Control), C, TEI=127, U-Frame: UI PF 0 > Dump:003 08 01 01 05 a1 04 02 88 90 18 01 89 6c 0d 21 81 ............l.!. > Dump:019 33 35 31 38 37 33 34 31 32 33 34 70 08 c1 34 31 35187341234p..41 > Dump:035 39 31 32 33 36 91236 > Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=SETUP: > [sending complete] > [bearer capability: > cap=unrestricted digital information > std=CCITT > rate=64 kbit/s > mode=circuit] > [channel id: channel=B-1 (exclusive)] > [calling party number: 35187341234 (type=national, plan=ISDN, > presentation allowed, screening user provided: verified & passed)] > [called party number: 4191236 (type=subscriber, plan=ISDN)] An incoming call comes in. From: 35187341234 To: 4191236 Service: data transfer (not telephony!) > -- TE->NT - unit:0 - frame:000002 - time:15.07 16:11:01.40 - length:8 ---------- > Dump:000 fc ff 03 0f 5a b9 01 ff ....Z... > Q921: SAP=63 (TEI-Management), C, TEI=127, Ri=0xb95a, IdRequest, Ai=127 > > -- NT->TE - unit:0 - frame:000003 - time:15.07 16:11:01.42 - length:8 ---------- > Dump:000 fe ff 03 0f 5a b9 02 ed ....Z... > Q921: SAP=63 (TEI-Management), C, TEI=127, Ri=0xb95a, IdAssign, Ai=118 the isdn4bsd machine requests a TEI and gets one, it got TEI 118. > -- TE->NT - unit:0 - frame:000006 - time:15.07 16:11:01.43 - length:8 ---------- > Dump:000 00 ed 00 00 .... > Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 0 N(R) 0 P 0 > Dump:004 08 01 81 07 .... > Q931: pd=Q.931/I.451, cr=0x01 (from destination), message=CONNECT: the isdn4bsd machine accepts the call. In order to do this, there must be an entry matching: From: 35187341234 To: 4191236 Service: data transfer (not telephony!) > -- NT->TE - unit:0 - frame:000007 - time:15.07 16:11:01.44 - length:3 ---------- > Dump:000 00 b5 73 ..s > Q921: SAP=0 (Call Control), R, TEI=90, U-Frame: UA PF 1 This seems to be your NT machine, it has TEI 90. > -- NT->TE - unit:0 - frame:000011 - time:15.07 16:11:01.58 - length:12 --------- > Dump:000 02 b5 00 04 .... > Q921: SAP=0 (Call Control), C, TEI=90, I-Frame: N(S) 0 N(R) 2 P 0 > Dump:004 08 01 01 4d 08 02 82 9a ...M.... > Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=RELEASE: > [cause: 26: Non-selected user clearing (Q.850) > (location=public network serving local user, std=CCITT)] And the NT gets a RELEASE from the exchange with cause = 26. Cause 26 is: "This cause indicates that the user has not been awarded the incoming call". Quite normal..... > -- NT->TE - unit:0 - frame:000012 - time:15.07 16:11:01.58 - length:8 ---------- > Dump:000 02 ed 00 02 .... > Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 0 N(R) 1 P 0 > Dump:004 08 01 01 0f .... > Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=CONNECT ACKNOWLEDGE: Because i4b (with the better OS !! :-)) has gotten the call! > -- NT->TE - unit:0 - frame:000014 - time:15.07 16:11:01.60 - length:15 --------- > Dump:000 02 b5 02 04 .... > Q921: SAP=0 (Call Control), C, TEI=90, I-Frame: N(S) 1 N(R) 2 P 0 > Dump:004 08 01 01 7d 08 02 82 e5 14 01 13 ...}....... > Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=STATUS: > [cause: 101: Message not compatible with call state (Q.850) > (location=public network serving local user, std=CCITT)] > [call state: Std=CCITT, State=Release request] Then the NT machine does something bad (not that unusual): a protocol violation. > -- NT->TE - unit:0 - frame:000025 - time:15.07 16:11:36.15 - length:12 --------- > Dump:000 02 ed 02 02 .... > Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 1 N(R) 1 P 0 > Dump:004 08 01 01 45 08 02 80 90 ...E.... > Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=DISCONNECT: > [cause: 16: Normal call clearing (Q.850) > (location=user, std=CCITT)] > > -- TE->NT - unit:0 - frame:000026 - time:15.07 16:11:36.15 - length:8 ---------- > Dump:000 00 ed 02 04 .... > Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 1 N(R) 2 P 0 > Dump:004 08 01 81 4d ...M > Q931: pd=Q.931/I.451, cr=0x01 (from destination), message=RELEASE: > > -- NT->TE - unit:0 - frame:000027 - time:15.07 16:11:36.16 - length:4 ---------- > Dump:000 00 ed 01 04 .... > Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 2 PF 0 > > -- NT->TE - unit:0 - frame:000028 - time:15.07 16:11:36.26 - length:8 ---------- > Dump:000 02 ed 04 04 .... > Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 2 N(R) 2 P 0 > Dump:004 08 01 01 5a ...Z > Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=RELEASE COMPLETE: After some time the remote side disconnects from the i4b side. Then, the very same remote calls in again: > -- NT->TE - unit:0 - frame:000032 - time:15.07 16:11:47.96 - length:40 --------- > Dump:000 02 ff 03 ... > Q921: SAP=0 (Call Control), C, TEI=127, U-Frame: UI PF 0 > Dump:003 08 01 01 05 a1 04 02 88 90 18 01 89 6c 0d 21 81 ............l.!. > Dump:019 33 35 31 38 37 33 34 31 32 33 34 70 08 c1 34 31 35187341234p..41 > Dump:035 39 31 32 33 36 91236 > Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=SETUP: > [sending complete] > [bearer capability: > cap=unrestricted digital information > std=CCITT > rate=64 kbit/s > mode=circuit] > [channel id: channel=B-1 (exclusive)] > [calling party number: 35187341234 (type=national, plan=ISDN, > presentation allowed, screening user provided: verified & passed)] > [called party number: 4191236 (type=subscriber, plan=ISDN)] > > -- TE->NT - unit:0 - frame:000033 - time:15.07 16:11:47.96 - length:8 ---------- > Dump:000 00 ed 04 06 .... > Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 2 N(R) 3 P 0 > Dump:004 08 01 81 07 .... > Q931: pd=Q.931/I.451, cr=0x01 (from destination), message=CONNECT: The i4b machine wants to get the call ... > -- NT->TE - unit:0 - frame:000038 - time:15.07 16:11:48.09 - length:8 ---------- > Dump:000 02 ed 06 06 .... > Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 3 N(R) 3 P 0 > Dump:004 08 01 01 0f .... > Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=CONNECT ACKNOWLEDGE: and gets it again! > -- NT->TE - unit:0 - frame:000040 - time:15.07 16:11:48.11 - length:12 --------- > Dump:000 02 b5 00 04 .... > Q921: SAP=0 (Call Control), C, TEI=90, I-Frame: N(S) 0 N(R) 2 P 0 > Dump:004 08 01 01 4d 08 02 82 d1 ...M.... > Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=RELEASE: > [cause: 81: Invalid call reference value (Q.850) > (location=public network serving local user, std=CCITT)] > > -- NT->TE - unit:0 - frame:000041 - time:15.07 16:11:48.13 - length:15 --------- > Dump:000 02 b5 02 04 .... > Q921: SAP=0 (Call Control), C, TEI=90, I-Frame: N(S) 1 N(R) 2 P 0 > Dump:004 08 01 01 7d 08 02 82 e5 14 01 13 ...}....... > Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=STATUS: > [cause: 101: Message not compatible with call state (Q.850) > (location=public network serving local user, std=CCITT)] > [call state: Std=CCITT, State=Release request] And the NT machine did something nasty again. After some time the remote machine disconnects again from the i4b machine > -- NT->TE - unit:0 - frame:000052 - time:15.07 16:12:22.56 - length:12 --------- > Dump:000 02 ed 08 06 .... > Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 4 N(R) 3 P 0 > Dump:004 08 01 01 45 08 02 80 90 ...E.... > Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=DISCONNECT: > [cause: 16: Normal call clearing (Q.850) > (location=user, std=CCITT)] > > -- TE->NT - unit:0 - frame:000053 - time:15.07 16:12:22.56 - length:8 ---------- > Dump:000 00 ed 06 0a .... > Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 3 N(R) 5 P 0 > Dump:004 08 01 81 4d ...M > Q931: pd=Q.931/I.451, cr=0x01 (from destination), message=RELEASE: > > -- NT->TE - unit:0 - frame:000054 - time:15.07 16:12:22.58 - length:4 ---------- > Dump:000 00 ed 01 08 .... > Q921: SAP=0 (Call Control), R, TEI=118, S-Frame: RR N(R) 4 PF 0 > > -- NT->TE - unit:0 - frame:000055 - time:15.07 16:12:22.64 - length:8 ---------- > Dump:000 02 ed 0a 08 .... > Q921: SAP=0 (Call Control), C, TEI=118, I-Frame: N(S) 5 N(R) 4 P 0 > Dump:004 08 01 01 5a ...Z > Q931: pd=Q.931/I.451, cr=0x01 (from origination), message=RELEASE COMPLETE: And thats it. There is nothing strange going on. It seems that the NT _and_ the i4b machine have some identical configuration and want _both_ to take that incoming call. When 2 devices compete for an incoming call, the fastest one sending the CONNECT message gets the call. This seems to be your situation - the i4b machine is faster. This might have been different with bisdn, because that was slower than i4b. hellmuth -- Hellmuth Michaelis Tel +49 40 559747-70 HCS Hanseatischer Computerservice GmbH Fax +49 40 559747-77 Oldesloer Strasse 97-99 Mail hm@hcs.de 22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0ywozl-0000dfC>