1. # 2. # Zaptel Configuration File 3. # 4. # This file is parsed by the Zaptel Configurator, ztcfg 5. # 6. # 7. # First come the span definitions, in the format 8. # span=,,,,[,yellow] 9. # 10. # All T1/E1 spans generate a clock signal on their transmit side. The 11. # parameter determines whether the clock signal from the far 12. # end of the T1/E1 is used as the master source of clock timing. If it is, our 13. # own clock will synchronise to it. T1/E1's connected directly or indirectly to 14. # a PSTN provider (telco) should generally be the first choice to sync to. The 15. # PSTN will never be a slave to you. You must be a slave to it. 16. # 17. # Choose 1 to make the equipment at the far end of the E1/T1 link the preferred 18. # source of the master clock. Choose 2 to make it the second choice for the master 19. # clock, if the first choice port fails (the far end dies, a cable breaks, or 20. # whatever). Choose 3 to make a port the third choice, and so on. If you have, say, 21. # 2 ports connected to the PSTN, mark those as 1 and 2. The number used for each 22. # port should be different. 23. # 24. # If you choose 0, the port will never be used as a source of timing. This is 25. # appropriate when you know the far end should always be a slave to you. If the 26. # port is connected to a channel bank, for example, you should always be its 27. # master. Any number of ports can be marked as 0. 28. # 29. # Incorrect timing sync may cause clicks/noise in the audio, poor quality or failed 30. # faxes, unreliable modem operation, and is a general all round bad thing. 31. # 32. # The line build-out (or LBO) is an integer, from the following table: 33. # 0: 0 db (CSU) / 0-133 feet (DSX-1) 34. # 1: 133-266 feet (DSX-1) 35. # 2: 266-399 feet (DSX-1) 36. # 3: 399-533 feet (DSX-1) 37. # 4: 533-655 feet (DSX-1) 38. # 5: -7.5db (CSU) 39. # 6: -15db (CSU) 40. # 7: -22.5db (CSU) 41. # 42. # The framing is one of "d4" or "esf" for T1 or "cas" or "ccs" for E1 43. # 44. # Note: "d4" could be referred to as "sf" or "superframe" 45. # 46. # The coding is one of "ami" or "b8zs" for T1 or "ami" or "hdb3" for E1 47. # 48. # E1's may have the additional keyword "crc4" to enable CRC4 checking 49. # 50. # If the keyword "yellow" follows, yellow alarm is transmitted when no 51. # channels are open. 52. # 53. #span=1,0,0,esf,b8zs 54. #span=2,1,0,esf,b8zs 55. #span=3,0,0,ccs,hdb3,crc4 56. # 57. # Next come the dynamic span definitions, in the form: 58. # dynamic=,
,, 59. # 60. # Where is the name of the driver (e.g. eth),
is the 61. # driver specific address (like a MAC for eth), is the number 62. # of channels, and is a timing priority, like for a normal span. 63. # use "0" to not use this as a timing source, or prioritize them as 64. # primary, secondard, etc. Note that you MUST have a REAL zaptel device 65. # if you are not using external timing. 66. # 67. # dynamic=eth,eth0/00:02:b3:35:43:9c,24,0 68. # 69. # Next come the definitions for using the channels. The format is: 70. # = 71. # 72. # Valid devices are: 73. # 74. # "e&m" : Channel(s) are signalled using E&M signalling (specific 75. # implementation, such as Immediate, Wink, or Feature Group D 76. # are handled by the userspace library). 77. # "fxsls" : Channel(s) are signalled using FXS Loopstart protocol. 78. # "fxsgs" : Channel(s) are signalled using FXS Groundstart protocol. 79. # "fxsks" : Channel(s) are signalled using FXS Koolstart protocol. 80. # "fxols" : Channel(s) are signalled using FXO Loopstart protocol. 81. # "fxogs" : Channel(s) are signalled using FXO Groundstart protocol. 82. # "fxoks" : Channel(s) are signalled using FXO Koolstart protocol. 83. # "sf" : Channel(s) are signalled using in-band single freq tone. 84. # Syntax as follows: 85. # channel# => sf:,,,,, 86. # rxfreq is rx tone freq in hz, rxbw is rx notch (and decode) 87. # bandwith in hz (typically 10.0), rxflag is either 'normal' or 88. # 'inverted', txfreq is tx tone freq in hz, txlevel is tx tone 89. # level in dbm, txflag is either 'normal' or 'inverted'. Set 90. # rxfreq or txfreq to 0.0 if that tone is not desired. 91. # "unused" : No signalling is performed, each channel in the list remains idle 92. # "clear" : Channel(s) are bundled into a single span. No conversion or 93. # signalling is performed, and raw data is available on the master. 94. # "indclear": Like "clear" except all channels are treated individually and 95. # are not bundled. "bchan" is an alias for this. 96. # "rawhdlc" : The zaptel driver performs HDLC encoding and decoding on the 97. # bundle, and the resulting data is communicated via the master 98. # device. 99. # "fcshdlc" : The zaptel (software) driver performs HDLC encoding and decoding on the 100. # bundle and also performs incoming and outgoing FCS insertion 101. # and verification. "dchan" is an alias for this. 102. # "hardhdlc" : The hardware driver performs HDLC encoding and decoding on the 103. # bundle and also performs incoming and outgoing FCS insertion 104. # and verification. Is subject to limitations and support of underlying 105. # hardware. 106. # "nethdlc" : The zaptel driver bundles the channels together into an 107. # hdlc network device, which in turn can be configured with 108. # sethdlc (available separately). In 2.6.x kernels you can also optionally 109. # pass the name for the network interface after the channel list. 110. # Syntax: 111. # nethdlc=[:interface name] 112. # Use original names, don't use the names which have been already registered 113. # in system e.g eth. 114. # 115. # "dacs" : The zaptel driver cross connects the channels starting at 116. # the channel number listed at the end, after a colon 117. # "dacsrbs" : The zaptel driver cross connects the channels starting at 118. # the channel number listed at the end, after a colon and 119. # also performs the DACSing of RBS bits 120. # 121. # The channel list is a comma-separated list of channels or ranges, for 122. # example: 123. # 124. # 1,3,5 (channels one, three, and five) 125. # 16-23, 29 (channels 16 through 23, as well as channel 29 126. # 127. # So, some complete examples are: 128. # e&m=1-12 129. # nethdlc=13-24 130. # fxsls=25,26,27,28 131. # fxols=29-32 132. # 133. fxoks=1-4 134. #fxoks=1-24 135. #bchan=25-47 136. #dchan=48 137. #fxols=1-12 138. #fxols=13-24 139. #e&m=25-29 140. #nethdlc=30-33 141. #clear=44 142. #clear=45 143. #clear=46 144. #clear=47 145. #fcshdlc=48 146. #dacs=1-24:48 147. #dacsrbs=1-24:48 148. # 149. # Finally, you can preload some tone zones, to prevent them from getting 150. # overwritten by other users (if you allow non-root users to open /dev/zap/* 151. # interfaces anyway. Also this means they won't have to be loaded at runtime. 152. # The format is "loadzone=" where the zone is a two letter country code. 153. # 154. # You may also specify a default zone with "defaultzone=" where zone 155. # is a two letter country code. 156. # 157. # An up-to-date list of the zones can be found in the file zaptel/zonedata.c 158. # 159. loadzone = us 160. #loadzone = us-old 161. #loadzone=gr 162. loadzone=it 163. #loadzone=fr 164. #loadzone=de 165. #loadzone=uk 166. #loadzone=fi 167. #loadzone=jp 168. #loadzone=sp 169. #loadzone=no 170. #loadzone=hu 171. #loadzone=lt 172. #loadzone=pl 173. defaultzone=us 174. # 175. # Section for PCI Radio Interface 176. # (see http://www.zapatatelephony.org/app_rpt.html) 177. # 178. # The PCI Radio Interface card interfaces up to 4 two-way radios (either 179. # a base/mobile radio or repeater system) to Zaptel channels. The driver 180. # may work either independent of an application, or with it, through 181. # the driver;s ioctl() interface. This file gives you access to specify 182. # load-time parameters for Radio channels, so that the driver may run 183. # by itself, and just act like a generic Zaptel radio interface. 184. # 185. # Unlike the rest of this file, you specify a block of parameters, and 186. # then the channel(s) to which they apply. CTCSS is specified as a frequency 187. # in tenths of hertz, for example 131.8 HZ is specified as 1318. DCS 188. # for receive is specified as the code directly, for example 223. DCS for 189. # transmit is specified as D and then the code, for example D223. 190. # 191. # The hardware supports a "community" CTCSS decoder system that has 192. # arbitrary transmit CTCSS or DCS codes associated with them, unlike 193. # traditional "community" systems that encode the same tone they decode. 194. # 195. # this example is a single tone DCS transmit and receive 196. # 197. # # specify the transmit tone (in DCS mode this stays constant) 198. # tx=D371 199. # # specify the receive DCS code 200. # dcsrx=223 201. # 202. # this example is a "community" CTCSS (if you only want a single tone, then 203. # only specify 1 in the ctcss list) 204. # 205. # # specify the default transmit tone (when not receiving) 206. # tx=1000 207. # # Specify the receive freq, the tag (use 0 if none), and the transmit code. 208. # # The tag may be used by applications to determine classification of tones. 209. # # The tones are to be specified in order of presedence, most important first. 210. # # Currently, 15 tones may be specified.. 211. # ctcss=1318,1,1318 212. # ctcss=1862,1,1862 213. # 214. # The following parameters may be omitted if their default value is acceptible 215. # 216. # # set the receive debounce time in milliseconds 217. # debouncetime=123 218. # # set the transmit quiet dropoff burst time in milliseconds 219. # bursttime=234 220. # # set the COR level threshold (specified in tenths of millivolts) 221. # # valid values are {3125,6250,9375,12500,15625,18750,21875,25000} 222. # corthresh=12500 223. # # Invert COR signal {y,n} 224. # invertcor=y 225. # # set the external tone mode; yes, no, internal {y,n,i} 226. # exttone=y 227. # 228. # Now apply the configuration to the specified channels: 229. # 230. # # We are all done with our channel parameters, so now we specify what 231. # # channels they apply to 232. channels=1,3,4 233. 234. defaultzone=it 235. channels=2