diff --git a/2022/retronetcall-v110_v120_x75_h221/h221_figure1.png b/2022/retronetcall-v110_v120_x75_h221/h221_figure1.png new file mode 100644 index 0000000..0f8da36 Binary files /dev/null and b/2022/retronetcall-v110_v120_x75_h221/h221_figure1.png differ diff --git a/2022/retronetcall-v110_v120_x75_h221/h221_figure3.png b/2022/retronetcall-v110_v120_x75_h221/h221_figure3.png new file mode 100644 index 0000000..f1ad246 Binary files /dev/null and b/2022/retronetcall-v110_v120_x75_h221/h221_figure3.png differ diff --git a/2022/retronetcall-v110_v120_x75_h221/h221_figure4a.png b/2022/retronetcall-v110_v120_x75_h221/h221_figure4a.png new file mode 100644 index 0000000..7fc56b5 Binary files /dev/null and b/2022/retronetcall-v110_v120_x75_h221/h221_figure4a.png differ diff --git a/2022/retronetcall-v110_v120_x75_h221/t90_figure2.png b/2022/retronetcall-v110_v120_x75_h221/t90_figure2.png new file mode 100644 index 0000000..54cc88f Binary files /dev/null and b/2022/retronetcall-v110_v120_x75_h221/t90_figure2.png differ diff --git a/2022/retronetcall-v110_v120_x75_h221/v110_figure1.png b/2022/retronetcall-v110_v120_x75_h221/v110_figure1.png new file mode 100644 index 0000000..9a85681 Binary files /dev/null and b/2022/retronetcall-v110_v120_x75_h221/v110_figure1.png differ diff --git a/2022/retronetcall-v110_v120_x75_h221/v110_figure3.png b/2022/retronetcall-v110_v120_x75_h221/v110_figure3.png new file mode 100644 index 0000000..1276f7e Binary files /dev/null and b/2022/retronetcall-v110_v120_x75_h221/v110_figure3.png differ diff --git a/2022/retronetcall-v110_v120_x75_h221/v110_figure4.png b/2022/retronetcall-v110_v120_x75_h221/v110_figure4.png new file mode 100644 index 0000000..f521939 Binary files /dev/null and b/2022/retronetcall-v110_v120_x75_h221/v110_figure4.png differ diff --git a/2022/retronetcall-v110_v120_x75_h221/v110_table2_frame_structure.png b/2022/retronetcall-v110_v120_x75_h221/v110_table2_frame_structure.png new file mode 100644 index 0000000..2145bd9 Binary files /dev/null and b/2022/retronetcall-v110_v120_x75_h221/v110_table2_frame_structure.png differ diff --git a/2022/retronetcall-v110_v120_x75_h221/v110_table8.png b/2022/retronetcall-v110_v120_x75_h221/v110_table8.png new file mode 100644 index 0000000..d0aed5a Binary files /dev/null and b/2022/retronetcall-v110_v120_x75_h221/v110_table8.png differ diff --git a/2022/retronetcall-v110_v120_x75_h221/v110_table8contd.png b/2022/retronetcall-v110_v120_x75_h221/v110_table8contd.png new file mode 100644 index 0000000..ca8b68a Binary files /dev/null and b/2022/retronetcall-v110_v120_x75_h221/v110_table8contd.png differ diff --git a/2022/retronetcall-v110_v120_x75_h221/v110_tables6abcd_frames.png b/2022/retronetcall-v110_v120_x75_h221/v110_tables6abcd_frames.png new file mode 100644 index 0000000..db036c8 Binary files /dev/null and b/2022/retronetcall-v110_v120_x75_h221/v110_tables6abcd_frames.png differ diff --git a/2022/retronetcall-v110_v120_x75_h221/v110_v120_x75_h221.adoc b/2022/retronetcall-v110_v120_x75_h221/v110_v120_x75_h221.adoc new file mode 100644 index 0000000..2c2d414 --- /dev/null +++ b/2022/retronetcall-v110_v120_x75_h221/v110_v120_x75_h221.adoc @@ -0,0 +1,266 @@ +ISDN B-Channel protocols: V.110, V.120, X.75, H.221 +=================================================== +:author: Harald Welte +:copyright: 2022 by Harald Welte (License: CC-BY-SA) +:backend: slidy +:max-width: 45em + + +== Overview + +* quick recap on D-channel +* overview of B-channel classes/formats +* V.110 +* HDLC/syncPPP +* V.120 +* X.75 +* H.221 + +== ISDN D-channel protocols + +* many have seen ISDN D-channel protocol traces +** Q.921 (LAPD) as Layer 2 +** Q.931 as Layer 3 for call control +* several FOSS implementations around +* quite a bit of literature +* protocol decoders in wireshark + +== ISDN B-channel protocols: Why? + +* we had modems to transmit serial data over analog +* now that we have a digital ISDN B-channel, why are protocols needed? +* _serial data_ is traditionally not just a stream of bytes, but +** modem control signals (CD, DSR/DTR, RTS/CTS, ...) +** variable number of data bits, stop bits, parity +** ... and what about the break condition? + +== ISDN B-channel protocols + +* transport of +* interoperability with legacy data (modem, *V-series*) applications +** V.110 +** V.120 +** X.75 +* video telephony +** H.221 +* IP or other network traffic +** bit-synchronous HDLC +** octet-synchronous HDLC + + + +== ISDN Terminal Adapters: Interfaces + +* R interface (V-series / "RS-232") +* S interface (S0 in Germany) +* U interface (Uk0 in Germany) + +== V.110 + +* rate adaptation between classic serial modem rates and ISDN +* support synchronous and asynchronous user communications + +image::v120_figure1_connection_services.png[] + +== V.110 for synchronous users + +* bit-rates 600, 1200, 2400, 4800, 7200, 9600, 12000, 14400, 19200, 24000, 28800, 38400 +* two rate adaptation functions +** RA1 +** RA2 + +image::v110_figure1.png[width=1200,align="center"] + +== V.110 RA1 generic frame structure + +image::v110_table2_frame_structure.png[] + +* 17bit sync pattern +* 48 D-bits (user data) +* 7 E-bits (encode frame format/rate) +* 8 S/X-bits (RTS/CTS/DTR/CD/... status lines) + +== V.110 RA1 specific frame structure + +image::v110_tables6abcd_frames.png[width=1200,align="center"] + +* same as generic frame structure +* rate specific D-bit repetition +* rate specific E1/E2/E3 bit + +== V.110 RA0 for asynchronous users + +* bit-rates 50, 75, 110, 150, 200, 300, 600, 1200, 2400, 3600, 4800, 7200, 9600, 12000, 14400, 19200, 24000, 28800, 38400 +* async user rate is adapted to nearest sync user rate +** new RA0 rate-adaptation function +** all it does is _stop-bit manipulation_, i.e. inserting,removing extraneous stop bits between characters +* RA1 + RA2 like in synchronous case + +image::v110_figure4.png[width=1200,align="center"] + +== V.110 RA0 for asynchronous users + +image::v110_table8.png[width=1200,align="center"] +image::v110_table8contd.png[width=1200,align="center"] + + +== V.110 RA2 from 8/16/32k to 64k + +* V.110 just points to I.460 +* in the end, RA2 just means +** use only LSB of each byte for 8k +** use two LSB of each byte for 16k +** use four LSB of each byte for 32k + +It reminds a bit 16k sub-slots as in GSM Abis. + +However, V.110 doesn't allow multiplexing of multiple 8/16/32k channels in one 64k channel. + +== V.110 synchronization entry/exit + +image::v110_figure3.png[width=1200,align="center"] + +== V.110 misc features + +* synchronous rates of 48 + 56 kbps +** separate rate adaptation / frame format for those +* In-band parameter exchange +* network independent clocking +** in case you have synchronous communications, but running off a different clock than ISDN + + +== V.110 interworking with modems + +* what if an ISDN subscriber with a V.110 TA wants to talk to another subscriber with an analog modem, e.g. V.32? +** in theory, the ISDN network could provide an IFW (inter-working function) +** in practice, that didn't really happen, so it was not supproted in real-world networks + +== V.110 usage + +* major usage in the context of GSM +** GSM offers CSD (circuit switched data), a V.110 derivative +** CSD uses modified V.110 frames +** GSM-specific interworking function between GSM and ISDN converts to plain V.110 + + +== HDLC with syncPPP (RFC1618 / RFC1549) + +* Flag octet (0x7E) +* Address octet (0xFF; all-stations addres) +* Control octet (0x03; UI frame) +* FCS (CRC16) +* optional *compression* suppressing Address + Ctrl on transmit + + +== X.75 + +* HDLC based protocol +* 0x7E flag octets +* address octet +* 8/16/32bit control field +* variable-length information field +* 16bit FCS (CRC16) +* your usual HDLC/LAPD/LAPB/... type commands: I/RR/RNR/REJ/SABM/DISC/FRMR/UA/DM + + + +== V.120 + +* TA for providing V-series applications over ISDN +** same purpose as V.110 +* unlike V.110: Not based on rate adaptation functions and its own framing format, but HDLC/LAPB based +* supports operation over _unrestricted_ (64kBps) and _restricted_ (56kBps) [and other] channels +** made it popular in the US, where restricted 56k user channels were common +* optionally supports multiplexing of multiple streams as _logical links_ into one B-channel +* optionally supports V.42bis compression + +== V.120 + +* protocol stack +** Q.922 as data link layer (LAPB framing) +** Q.931 as L3 (SETUP/CONNECT/RELEASE/RELEASE_COMPLETE) for establishing logical links + +image::v120_figure3_frame_formats.png[align="center"] + +== V.120 flow control / modes + +* protocol sensitive asynchronous mode +** I-frames/ABM: flow control by data link layer (RNR frames, withholding V(R) updates) +** unacknowledged: flow control by RR bit in control state informatoin octet +* protocol sensitive synchronous mode +** no flow-control possible +* bit transparent mode +** over/underruns may happen in case of clock problems + + +== X.75 + +* predates ISDN: Specified as part of Packets Switched Public Data Networks +** X.25 is the UNI (user-network interface) of PSPDNs +** X.75 is the NNI (network-network interface) of PSPDNs +** so if German Datex-P interconnected with French Transpac or US Telenet, that was supposedly using X.75 in the 1970s + +image::x75_ulema_figure1.png[width=1000,align="center"] + +* X.75 SLP (single link procedure) was extended in 1988 for use on ISDN B-channels +* T.90 contains the specific rules how X.75 is used in ISDN + +== X.75 Frame Formats + +* looks just like LAPB, LAPD, LAPDm, LAPSat, or any of the other many HDLC derivates +* but: note the absence of UI-frames! No unacknowledged data transfer + +image::x75_table1.png[] + +== X.75 Commands and Responses + +image::x75_table7.png[] + +== X.75 Adresses + +image::t90_figure2.png[width=800,float="right"] + +* X.75 only uses two addresses (it's point-to-point...) +** Address _A_ (0x03) +*** commands from callee to caller +*** responses from caller to callee +** Address _B_ (0x01) +*** commands from caller to calee +*** responses from callee to caller + +== H.221 + +* bit-stream TDMA system; much more like V.110 or E1 multiframe structure than HDLC based bearers +* not just frames (like V.110), but _multiframes_ (like E1 or GSM) +** frame: 80 octets +** multiframe: 16 frames (1280 octets) + + +== H.221 frame structure + +image::h221_figure1.png[width=900,float="right"] + +* FAS: _Frame Alignment Signal_ +** alignment pattern (0011011) to lock on multiframe structure +** control (E/C-bits) and alarm information (A-bits) +* BAS: _Bit-rate allocation signal_ +** codeword to describe capability/capacity +* ECS: _Encryption control signal_ +** optional 800 bit/s channel + +== H.221 Frame Alignment Signal + +image::h221_figure3.png[width=1400,align="center"] + +== H.221 Frame Alignment Signal Multiframe + +image::h221_figure4a.png[width=1400,align="center"] + +* N1-N4, N5: Mulitframe number +* C: CRC4 +* TEA: Terminal Equipment Alarm + + +== EOF + +End of File diff --git a/2022/retronetcall-v110_v120_x75_h221/v110_v120_x75_h221.html b/2022/retronetcall-v110_v120_x75_h221/v110_v120_x75_h221.html new file mode 100644 index 0000000..2fd3590 --- /dev/null +++ b/2022/retronetcall-v110_v120_x75_h221/v110_v120_x75_h221.html @@ -0,0 +1,4803 @@ + + + + +ISDN B-Channel protocols: V.110, V.120, X.75, H.221 + + + + + + + + +
+

Overview

+
+
    +
  • + +quick recap on D-channel + +
  • +
  • + +overview of B-channel classes/formats + +
  • +
  • + +V.110 + +
  • +
  • + +HDLC/syncPPP + +
  • +
  • + +V.120 + +
  • +
  • + +X.75 + +
  • +
  • + +H.221 + +
  • +
+
+
+
+

ISDN D-channel protocols

+
+
    +
  • + +many have seen ISDN D-channel protocol traces + +
      +
    • + +Q.921 (LAPD) as Layer 2 + +
    • +
    • + +Q.931 as Layer 3 for call control + +
    • +
    +
  • +
  • + +several FOSS implementations around + +
  • +
  • + +quite a bit of literature + +
  • +
  • + +protocol decoders in wireshark + +
  • +
+
+
+
+

ISDN B-channel protocols: Why?

+
+
    +
  • + +we had modems to transmit serial data over analog + +
  • +
  • + +now that we have a digital ISDN B-channel, why are protocols needed? + +
  • +
  • + +serial data is traditionally not just a stream of bytes, but + +
      +
    • + +modem control signals (CD, DSR/DTR, RTS/CTS, …) + +
    • +
    • + +variable number of data bits, stop bits, parity + +
    • +
    • + +… and what about the break condition? + +
    • +
    +
  • +
+
+
+
+

ISDN B-channel protocols

+
+
    +
  • + +transport of + +
  • +
  • + +interoperability with legacy data (modem, V-series) applications + +
      +
    • + +V.110 + +
    • +
    • + +V.120 + +
    • +
    • + +X.75 + +
    • +
    +
  • +
  • + +video telephony + +
      +
    • + +H.221 + +
    • +
    +
  • +
  • + +IP or other network traffic + +
      +
    • + +bit-synchronous HDLC + +
    • +
    • + +octet-synchronous HDLC + +
    • +
    +
  • +
+
+
+
+

ISDN Terminal Adapters: Interfaces

+
+
    +
  • + +R interface (V-series / "RS-232") + +
  • +
  • + +S interface (S0 in Germany) + +
  • +
  • + +U interface (Uk0 in Germany) + +
  • +
+
+
+
+

V.110

+
+
    +
  • + +rate adaptation between classic serial modem rates and ISDN + +
  • +
  • + +support synchronous and asynchronous user communications + +
  • +
+
+
+v120_figure1_connection_services.png +
+
+
+
+
+

V.110 for synchronous users

+
+
    +
  • + +bit-rates 600, 1200, 2400, 4800, 7200, 9600, 12000, 14400, 19200, 24000, 28800, 38400 + +
  • +
  • + +two rate adaptation functions + +
      +
    • + +RA1 + +
    • +
    • + +RA2 + +
    • +
    +
  • +
+
+
+v110_figure1.png +
+
+
+
+
+

V.110 RA1 generic frame structure

+
+
+
+v110_table2_frame_structure.png +
+
+
    +
  • + +17bit sync pattern + +
  • +
  • + +48 D-bits (user data) + +
  • +
  • + +7 E-bits (encode frame format/rate) + +
  • +
  • + +8 S/X-bits (RTS/CTS/DTR/CD/… status lines) + +
  • +
+
+
+
+

V.110 RA1 specific frame structure

+
+
+
+v110_tables6abcd_frames.png +
+
+
    +
  • + +same as generic frame structure + +
  • +
  • + +rate specific D-bit repetition + +
  • +
  • + +rate specific E1/E2/E3 bit + +
  • +
+
+
+
+

V.110 RA0 for asynchronous users

+
+
    +
  • + +bit-rates 50, 75, 110, 150, 200, 300, 600, 1200, 2400, 3600, 4800, 7200, 9600, 12000, 14400, 19200, 24000, 28800, 38400 + +
  • +
  • + +async user rate is adapted to nearest sync user rate + +
      +
    • + +new RA0 rate-adaptation function + +
    • +
    • + +all it does is stop-bit manipulation, i.e. inserting,removing extraneous stop bits between characters + +
    • +
    +
  • +
  • + +RA1 + RA2 like in synchronous case + +
  • +
+
+
+v110_figure4.png +
+
+
+
+
+

V.110 RA0 for asynchronous users

+
+
+
+v110_table8.png +
+
+
+
+v110_table8contd.png +
+
+
+
+
+

V.110 RA2 from 8/16/32k to 64k

+
+
    +
  • + +V.110 just points to I.460 + +
  • +
  • + +in the end, RA2 just means + +
      +
    • + +use only LSB of each byte for 8k + +
    • +
    • + +use two LSB of each byte for 16k + +
    • +
    • + +use four LSB of each byte for 32k + +
    • +
    +
  • +
+

It reminds a bit 16k sub-slots as in GSM Abis.

+

However, V.110 doesn’t allow multiplexing of multiple 8/16/32k channels in one 64k channel.

+
+
+
+

V.110 synchronization entry/exit

+
+
+
+v110_figure3.png +
+
+
+
+
+

V.110 misc features

+
+
    +
  • + +synchronous rates of 48 + 56 kbps + +
      +
    • + +separate rate adaptation / frame format for those + +
    • +
    +
  • +
  • + +In-band parameter exchange + +
  • +
  • + +network independent clocking + +
      +
    • + +in case you have synchronous communications, but running off a different clock than ISDN + +
    • +
    +
  • +
+
+
+
+

V.110 interworking with modems

+
+
    +
  • + +what if an ISDN subscriber with a V.110 TA wants to talk to another subscriber with an analog modem, e.g. V.32? + +
      +
    • + +in theory, the ISDN network could provide an IFW (inter-working function) + +
    • +
    • + +in practice, that didn’t really happen, so it was not supproted in real-world networks + +
    • +
    +
  • +
+
+
+
+

V.110 usage

+
+
    +
  • + +major usage in the context of GSM + +
      +
    • + +GSM offers CSD (circuit switched data), a V.110 derivative + +
    • +
    • + +CSD uses modified V.110 frames + +
    • +
    • + +GSM-specific interworking function between GSM and ISDN converts to plain V.110 + +
    • +
    +
  • +
+
+
+
+

HDLC with syncPPP (RFC1618 / RFC1549)

+
+
    +
  • + +Flag octet (0x7E) + +
  • +
  • + +Address octet (0xFF; all-stations addres) + +
  • +
  • + +Control octet (0x03; UI frame) + +
  • +
  • + +FCS (CRC16) + +
  • +
  • + +optional compression suppressing Address + Ctrl on transmit + +
  • +
+
+
+
+

X.75

+
+
    +
  • + +HDLC based protocol + +
  • +
  • + +0x7E flag octets + +
  • +
  • + +address octet + +
  • +
  • + +8/16/32bit control field + +
  • +
  • + +variable-length information field + +
  • +
  • + +16bit FCS (CRC16) + +
  • +
  • + +your usual HDLC/LAPD/LAPB/… type commands: I/RR/RNR/REJ/SABM/DISC/FRMR/UA/DM + +
  • +
+
+
+
+

V.120

+
+
    +
  • + +TA for providing V-series applications over ISDN + +
      +
    • + +same purpose as V.110 + +
    • +
    +
  • +
  • + +unlike V.110: Not based on rate adaptation functions and its own framing format, but HDLC/LAPB based + +
  • +
  • + +supports operation over unrestricted (64kBps) and restricted (56kBps) [and other] channels + +
      +
    • + +made it popular in the US, where restricted 56k user channels were common + +
    • +
    +
  • +
  • + +optionally supports multiplexing of multiple streams as logical links into one B-channel + +
  • +
  • + +optionally supports V.42bis compression + +
  • +
+
+
+
+

V.120

+
+
    +
  • + +protocol stack + +
      +
    • + +Q.922 as data link layer (LAPB framing) + +
    • +
    • + +Q.931 as L3 (SETUP/CONNECT/RELEASE/RELEASE_COMPLETE) for establishing logical links + +
    • +
    +
  • +
+
+
+v120_figure3_frame_formats.png +
+
+
+
+
+

V.120 flow control / modes

+
+
    +
  • + +protocol sensitive asynchronous mode + +
      +
    • + +I-frames/ABM: flow control by data link layer (RNR frames, withholding V® updates) + +
    • +
    • + +unacknowledged: flow control by RR bit in control state informatoin octet + +
    • +
    +
  • +
  • + +protocol sensitive synchronous mode + +
      +
    • + +no flow-control possible + +
    • +
    +
  • +
  • + +bit transparent mode + +
      +
    • + +over/underruns may happen in case of clock problems + +
    • +
    +
  • +
+
+
+
+

X.75

+
+
    +
  • + +predates ISDN: Specified as part of Packets Switched Public Data Networks + +
      +
    • + +X.25 is the UNI (user-network interface) of PSPDNs + +
    • +
    • + +X.75 is the NNI (network-network interface) of PSPDNs + +
    • +
    • + +so if German Datex-P interconnected with French Transpac or US Telenet, that was supposedly using X.75 in the 1970s + +
    • +
    +
  • +
+
+
+x75_ulema_figure1.png +
+
+
    +
  • + +X.75 SLP (single link procedure) was extended in 1988 for use on ISDN B-channels + +
  • +
  • + +T.90 contains the specific rules how X.75 is used in ISDN + +
  • +
+
+
+
+

X.75 Frame Formats

+
+
    +
  • + +looks just like LAPB, LAPD, LAPDm, LAPSat, or any of the other many HDLC derivates + +
  • +
  • + +but: note the absence of UI-frames! No unacknowledged data transfer + +
  • +
+
+
+x75_table1.png +
+
+
+
+
+

X.75 Commands and Responses

+
+
+
+x75_table7.png +
+
+
+
+
+

X.75 Adresses

+
+
+
+t90_figure2.png +
+
+
    +
  • + +X.75 only uses two addresses (it’s point-to-point…) + +
      +
    • + +Address A (0x03) + +
        +
      • + +commands from callee to caller + +
      • +
      • + +responses from caller to callee + +
      • +
      +
    • +
    • + +Address B (0x01) + +
        +
      • + +commands from caller to calee + +
      • +
      • + +responses from callee to caller + +
      • +
      +
    • +
    +
  • +
+
+
+
+

H.221

+
+
    +
  • + +bit-stream TDMA system; much more like V.110 or E1 multiframe structure than HDLC based bearers + +
  • +
  • + +not just frames (like V.110), but multiframes (like E1 or GSM) + +
      +
    • + +frame: 80 octets + +
    • +
    • + +multiframe: 16 frames (1280 octets) + +
    • +
    +
  • +
+
+
+
+

H.221 frame structure

+
+
+
+h221_figure1.png +
+
+
    +
  • + +FAS: Frame Alignment Signal + +
      +
    • + +alignment pattern (0011011) to lock on multiframe structure + +
    • +
    • + +control (E/C-bits) and alarm information (A-bits) + +
    • +
    +
  • +
  • + +BAS: Bit-rate allocation signal + +
      +
    • + +codeword to describe capability/capacity + +
    • +
    +
  • +
  • + +ECS: Encryption control signal + +
      +
    • + +optional 800 bit/s channel + +
    • +
    +
  • +
+
+
+
+

H.221 Frame Alignment Signal

+
+
+
+h221_figure3.png +
+
+
+
+
+

H.221 Frame Alignment Signal Multiframe

+
+
+
+h221_figure4a.png +
+
+
    +
  • + +N1-N4, N5: Mulitframe number + +
  • +
  • + +C: CRC4 + +
  • +
  • + +TEA: Terminal Equipment Alarm + +
  • +
+
+
+
+

EOF

+
+

End of File

+
+
+ + diff --git a/2022/retronetcall-v110_v120_x75_h221/v120_figure1_connection_services.png b/2022/retronetcall-v110_v120_x75_h221/v120_figure1_connection_services.png new file mode 100644 index 0000000..cbb653b Binary files /dev/null and b/2022/retronetcall-v110_v120_x75_h221/v120_figure1_connection_services.png differ diff --git a/2022/retronetcall-v110_v120_x75_h221/v120_figure3_frame_formats.png b/2022/retronetcall-v110_v120_x75_h221/v120_figure3_frame_formats.png new file mode 100644 index 0000000..0c87fd1 Binary files /dev/null and b/2022/retronetcall-v110_v120_x75_h221/v120_figure3_frame_formats.png differ diff --git a/2022/retronetcall-v110_v120_x75_h221/x75_table1.png b/2022/retronetcall-v110_v120_x75_h221/x75_table1.png new file mode 100644 index 0000000..90d5db5 Binary files /dev/null and b/2022/retronetcall-v110_v120_x75_h221/x75_table1.png differ diff --git a/2022/retronetcall-v110_v120_x75_h221/x75_table7.png b/2022/retronetcall-v110_v120_x75_h221/x75_table7.png new file mode 100644 index 0000000..e9392e5 Binary files /dev/null and b/2022/retronetcall-v110_v120_x75_h221/x75_table7.png differ diff --git a/2022/retronetcall-v110_v120_x75_h221/x75_ulema_figure1.png b/2022/retronetcall-v110_v120_x75_h221/x75_ulema_figure1.png new file mode 100644 index 0000000..b28147e Binary files /dev/null and b/2022/retronetcall-v110_v120_x75_h221/x75_ulema_figure1.png differ