T-DisplayTel » History » Revision 4
Revision 3 (laforge, 03/13/2022 08:10 PM) → Revision 4/19 (laforge, 03/19/2022 05:30 PM)
h1. T-DisplayTel This is probably the only ISDN Phone with built-in [[BTX]] Terminal that was ever made. h2. Pictures FIXME h2. Making the BTX / Datex-J terminal work @laforge has been attempting to find out what needs to be done to get the BTX/terminal part of T-DisplayTel to work. On the D-channel signaling side, it is establshing a normal _UDI (unrestricted digital information)_, no specific HLC/LLC. The more interesting question is what it speaks on the B-channel. h3. Accepting the call, dumping raw B channel When accepting a call (from the simulated BTX server side), the T-DisplayTel unexpectedly doesn't send HDLC but some 0xff-padding based signaling: <pre> 00000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00000040 ff ff ff ff ff ff ff ff ff ff ff ff fb 05 7c 59 |..............|Y| 00000050 df ed f7 ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 00000060 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00001f20 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff fb |................| 00001f30 05 7c 59 df ed f7 ff ff ff ff ff ff ff ff ff ff |.|Y.............| 00001f40 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00007ce0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff fb |................| 00007cf0 05 7c 59 df ed f7 ff ff ff ff ff ff ff ff ff ff |.|Y.............| 00007d00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 0000daa0 ff ff ff ff ff ff ff ff ff ff ff ff fb 05 7c 59 |..............|Y| 0000dab0 df ed f7 ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 0000dac0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00013860 ff ff ff ff ff ff ff ff 7e 01 5f d6 77 fb fd ff |........~._.w...| 00013870 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00019620 ff ff ff ff ff ff fb 05 7c 59 df ed f7 ff ff ff |........|Y......| 00019630 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 0001f3e0 ff ff ff ff 7e 01 5f d6 77 fb fd ff ff ff ff ff |....~._.w.......| 0001f3f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 000251a0 ff fb 05 7c 59 df ed f7 ff ff ff ff ff ff ff ff |...|Y...........| 000251b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 0002b310 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ab ab |................| 0002b320 ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab |................| </pre> So we see two messages, with a lot of 'ff' padding in between: <pre> fb 05 7c 59 df ed f7 7e 01 5f d6 77 fb fd </pre> If we re-order the bits of each byte and then HDLC decode (e.g. with https://git.osmocom.org/osmo-e1-recorder/tree/src/hdlc-test.c) we get <pre> fffb057c59dfedf7ff => F 01 3f eb df F ff7e015fd677fbfdff => F 01 3f eb df F </pre> so it's actually a repeat transmission of the same frame. anyone has an idea what they mean, please do let me know. h3. establishing a call against an ISDN TA Establishing call towards ISDN TA ([[US_Robotics_Sportster_ISDN_TA_Ext]]) and playing with the B-channel protocol on the TA, I can get a "proper" connection established when putting the TA into *T.70-NL* mode (@ATB22@). No success with HDLC, X.75 or V.120. When the T.70-NL call is established, the DisplayTel cleaars its screen, and any characters sent by the TA are displayed on the screen. Great. However, no characters are transmitted from the DisplayTel in the opposite direction. In fact, it doesn't even ever leave the 'ff' mode, i.e. no HDLC flag octets are sent by it. No keypress on the DisplayTel generates any non-ff data to be transmitted on the B-channel. I'm attaching raw B-channel traces for both directions (attachment:displaytel-32-rx.raw and attachment:displaytel-32-tx.raw) Interstingly, in this situation, the uplink from the Displaytel only contains a single, non-ff message: <pre> df a0 3e 9a fb b7 ef </pre>
