Project

General

Profile

Community TDMSS7 Network » History » Revision 22

Revision 21 (laforge, 04/21/2022 05:28 PM) → Revision 22/28 (laforge, 10/08/2022 03:05 AM)

{{>toc}} 

 h1. Community TDM/ISDN/SS7 Network 

 This wiki page describes a _work in progress_ creating a community TDM/ISDN/SS7 network, enabling retronetworking enthusiasts around the world to interconnect their TDM equipment, such as PBXs, telephony switches, RAS servers, access multiplers, etc. 

 For classic analog telephones, there is the C*NET (https://www.ckts.info/).    This is basically the same idea but for one later generation of technology: Digital TDM/PDH/ISDN/SS7 networks.    And of course one can connect analog telephone/modem equipment via ISDN/SS7, if that is desired. 

 h2. Current Network 

 The network has a number of additional participants by now, but the general principle looks the same, updating the graph with every participant would make it rather complex without immediate gain: 

 {{graphviz_link() 
 graph G { 
   newrank=true; 
   divo [shape=house,label="Central Office\nyate + TE820"]; 
   subgraph cluster_1 { 
     label="@laforge / Berlin"; 
     uei1a [label="ISDN Phone"]; 
     uea1a [label="Analog Phone"]; 
     ues1a [label="SIP Phone"]; 
     pbx1a [label="Auerswald COMmander\nBasic 2 PBX"]; 
     pm3a [label="Livingston\nPortmaster 3\nRAS Server"]; 
     ice1a [shape=box3d,label="icE1usb\nGPS-DO\nosmo-e1d"]; 
     uei1a -- pbx1a [label="ISDN\nBRI"]; 
     uea1a -- pbx1a [label="POTS"]; 
     pbx1a -- divo [label="ISDN\nPRI"]; 
     pm3a -- divo [label="ISDN\nPRI"]; 
     ice1a -- divo [label="ISDN\nPRI"]; 
     ues1a -- divo [label="SIP"]; 
   } 

   subgraph cluster_2 { 
     label="@manawyrm / Kiel"; 
     ue2a [label="ISDN Phone\n"]; 
     pbx2 [label="Auerswald COMmander\nBasic 2 PBX"]; 
     ice2 [shape=box3d,label="icE1usb\nGPS-DO\nosmo-e1d\n"]; 
     ue2a -- pbx2 [label="ISDN\nBRI"]; 
     pbx2 -- ice2 [label="ISDN\nPRI"]; 
   } 

   subgraph cluster_3 { 
     label="@roox / Franconia"; 
     pbx3 [label="Auerswald COMmander\nBasic 2 PBX"]; 
     ice3 [shape=box3d,label="icE1usb\nGPS-DO\nosmo-e1d\n"]; 
     ue3a -- pbx3 [label="ISDN\nBRI"]; 
     pbx3 -- ice3 [label="ISDN\nPRI"]; 
   } 

   subgraph cluster_4 { 
     label="@gruetzkopf"; 
     pbx4 [label="PBX"]; 
     ice4 [shape=box3d,label="icE1usb\nGPS-DO\nosmo-e1d\n"]; 
     ue4a -- pbx4 [label="ISDN\nBRI"]; 
     pbx4 -- ice4 [label="ISDN\nPRI"]; 
   } 

   internet [shape=hexagon,label="Public Internet"]; 
   cnet [shape=hexagon,label="C*NET"]; 
   ice1a -- internet [label="OCTOI\nTDMoIP"]; 
   ice2 -- internet [label="OCTOI\nTDMoIP"]; 
   ice3 -- internet [label="OCTOI\nTDMoIP"]; 
   ice4 -- internet [label="OCTOI\nTDMoIP"]; 
   divo -- cnet [label="IAX2"]; 
 } 
 }} 

 h2. How to contact us 

 h3. Mailing List 

 We now have a public "mailing list":https://lists.retronetworking.org/postorius/lists/octoi.lists.retronetworking.org/ for discussion among interested parties. The list has a public "archive":https://lists.retronetworking.org/hyperkitty/list/octoi@lists.retronetworking.org/ 

 Don't be surprised by the lack of traffic on the ML, almost all communication happens on the IRC channel 

 

 h3. IRC Channel 

 A lot of us are hanging out on the @#retronetworking@ IRC channel on libera.chat. If you don't know much about "IRC":https://en.wikipedia.org/wiki/IRC, feel free to use the provided "webchat":https://web.libera.chat/ interface 

 

 h2. Underlying Protocol / Hardware 

 The underlying transport protocol is being designed around the wiki page [[e1-t1-adapter:Proposed_efficient_TDMoIP]].    The initial hardware implementation is an [[e1-t1-adapter:icE1usb]] attached to some kind of [embedded] Linux sytem like a Raspberry Pi.    The unique property about the icE1usb is that it contains a GPS-DO to ensure the same clock reference is used in all locations. 

 h2. Services 

 h3. ISDN PRI (available) 

 ISDN (Q.921/Q.931) permit to connect equipment like PBXs.     The hub offers the NT / central office function, while the client side implements the TE function. 

 A user connecting to the ISDN PRI service needs to be allocated telephone numbers in the dialling plan, see [[Phonebook]].. 

 On the hub side, the PRI lines and ISDN service are currently terminated in a yate instance. 

 {{graphviz_link() 
 graph G { 
   hub [shape=box, label="TDMoIP hub\ncross-connect\nin public internet"]; 
   subgraph cluster_1 { 
     label="Hobbyist A"; 
     ad1 [label="Access Device\n"]; 
     pbx1 [label="PBX"]; 
     phone1a [label="Phone"]; 
     modem1b [label="Modem"]; 
     ta1c [label="ISDN TA"]; 
     pbx1 -- ad1 [label="E1"]; 
     phone1a -- pbx1 [label="POTS"]; 
     modem1b -- pbx1 [label="POTS"]; 
     ta1c -- pbx1 [label="ISDN-BRI"]; 
   } 
   subgraph cluster_2 { 
     label="Hobbyist B"; 
     ad2 [label="Access Device\n"]; 
     pbx2 [label="PBX"]; 
     phone2a [label="Phone"]; 
     modem2b [label="Modem"]; 
     ta2c [label="ISDN TA"]; 
     pbx2 -- ad2 [label="E1"]; 
     phone2a -- pbx2 [label="POTS"]; 
     modem2b -- pbx2 [label="POTS"]; 
     ta2c -- pbx2 [label="ISDN-BRI"]; 
   } 
   subgraph cluster_3 { 
     label="Hobbyist C"; 
     ad3 [label="Access Device\n"]; 
     pbx3 [label="PBX"]; 
     phone3a [label="Phone"]; 
     modem3b [label="Modem"]; 
     ta3c [label="ISDN TA"]; 
     pbx3 -- ad3 [label="E1"]; 
     phone3a -- pbx3 [label="POTS"]; 
     modem3b -- pbx3 [label="POTS"]; 
     ta3c -- pbx3 [label="ISDN-BRI"]; 
   } 
   ad1 -- hub [label="TDMoIP\nInternet"]; 
   ad2 -- hub [label="TDMoIP\nInternet"]; 
   ad3 -- hub [label="TDMoIP\nInternet"]; 
 } 
 }} 


 h3. ISDN BRI 

 ISDN BRI service is expected to initially only be obtained indirectly: By connecting a ISDN PRI capable PBX to the hub, and then locally connecting to ISDN BRI ports of the PBX. 

 At a later point, one could consider implementing a ISDN BRI version of the TDMoIP protocol and some software implementation for ISDN BRI cards that support NT mode.    One notable topic is clocking:    The hardware would either need a GPS-DO (like [[e1-t1-adapter:icE1usb]] has for E1) or at the very least a VCTCXO that can be disciplined by software to match the timing recovered from the IP packet side.    See #5436 and #5417  


 h3. TDM layer hub / cross-connect (future) 

 The TDM layer would allow to interconnect any E1 line (or even only some timeslots of a line) with any other E1 line.    It doesn't interpret the payload but just passes it around. 

 {{graphviz_link() 
 graph G { 
   hub [shape=box, label="TDMoIP hub\ncross-connect\nin public internet"]; 
   subgraph cluster_1 { 
     label="Hobbyist A"; 
     ad1 [label="Access Device\n"]; 
     pbx1 [label="PBX"]; 
     pbx1 -- ad1 [label="E1"]; 
   } 
   subgraph cluster_2 { 
     label="Hobbyist B"; 
     ad2 [label="Access Device\n"]; 
     frr [label="FrameRelay Device"]; 
     frr -- ad2 [label="E1"]; 
   } 
   subgraph cluster_3 { 
     label="Hobbyist C"; 
     ad3 [label="Access Device\n"]; 
     ras [label="RAS Server"]; 
     ras -- ad3 [label="E1"]; 
   } 
   ad1 -- hub [label="TDMoIP\nInternet"]; 
   ad2 -- hub [label="TDMoIP\nInternet"]; 
   ad3 -- hub [label="TDMoIP\nInternet"]; 
 } 
 }} 

 h3. Classic SS7 (available, not yet tested) 

 Classic SS7 (MTP2/MTP3 plus TUP/ISUP) would permit to connect STPs and SPCs, such as those of telephony exchanges / switches. 

 A user connecting to the SS7 service would need to be allocated point codes. 


 h3. SCCP/MAP/TCAP (future) 

 SCCP/MAP/TCAP on top of SS7 can be used to provide interworking between private cellular networks. 


 h3. Frame Relay (future) 

 A Frame Relay network could be implemented on top of the TDM hub.    In this case, framed E1 would be used with groups of 64k timeslots (typically all 31) building the underlying FR transport medium. 

 h3. POTS / analog telephony 

 There is no plan to directly support analog telephony.    Rather, analog ports for phones, modems, etc. can be provided by means of ISDN PBXs connecting via ISDN PRI    (and possibly later ISDN BRI)
Add picture from clipboard (Maximum size: 48.8 MB)