This document covers information about the Endpoint of Khomp as a whole, include the options, applications, CLI commands, among others.
For first installation procedures, please see the README.
Configuring the Khomp Endpoint is a task that consists of three steps:
These steps are described more fully below.
This step is carried out in a semi-automated way using the khompwizard program, a wizard that configures the basic parameters of the system boards. This wizard initializes the configuration files using information from the user when they are needed, initializing the standard settings to default values.
Typically, this program runs automatically after installation of the system. However, you may need to run it manually if an update is being performed, or if new cards were added to the system after installing new drivers.
If you need to set advanced parameters of the board and/or signaling, the program k3lconfig allows you to access all the available settings for each installed card. For more information about this program, check the k3lconfig User's Guide. For solving synchronization issues, check the Troubleshooting section for manual configuration of the boards.
The system's default configuration normally meet most user's needs. However, the configuration of the Endpoint Khomp can be modified through the configuration file '/usr/local/freeswitch/conf/autoload_configs/khomp.conf.xml'.
The list of options is as follows:
Define general settings of all channels of Khomp:
Sintaxe: <param name="..." value="..."/>
Defines the groups to be used in channel allocation.
In this case, the options are used to define names for strings allocation of channels. The format follows the standard <group name> = <allocation string>, where the allocation string is the same string used in the bridge application, and group name is an arbitrary name chosen by the user.
<param name="pstn" value="b0c0 + b0c5"/>
This group, in turn, could be used in the bridge application as <action application="bridge" data="Khomp/Gpstn/..."/>.
For example, to define the same group pstn as channels 0 to 20 of card 0, and defining the incoming context to for channels in this groups to from-pstn, one could use the line:
<param name="pstn" value="b0c0-20:from-pstn"/>
This group would be used the same way as before in the bridge application, and all the calls coming from these channels would be treated in context from-pstn.
Defines settings for the Endpoint cadences.
In this case, the options are names cadences, followed by one or two pairs of numbers - that define the ranges of tone and silence to be used in cadences.
For details, please refer to the configuration file for examples.
Defines source numbers for the board KFXS.
In this case, the options are sequences of prefixes of branches and serial numbers of the boards, which define the basic numbers of source addresses, and the numerical order of the boards. The format of the options is:
<param name="prefixo" value="serial1, serial2, ...."/>
For example, if two KFXS-300 SPX boards with serial numbers K0374 and K2352 must be numbered sequentially, starting from branch 200, you may write:
<param name="200" value="374, 2352"/>
This will define the first branch of board 'K0374 as number 200, the second as 201, and so one. The first branch from board K2352 will have number 230 (as K0374 has 30 channels), the second will be numbered 231, and so on - until the last channel, numbered 259.
For more details, please refer to the configuration file for other exemples.
Sets hotlines for the KFXS based boards
In this case, the options are sequences of branches and sequences of destination numbers, which define branches to be treated as "hotlines" and numbers to be dialed when they are take off hook. For instance:
<param name="100" value="1234"/> <param name="200" value="4321"/>
In the first line, the branch numbered 100 will call extension 1234 when taken off hook, while in the second one, branch 200 will call number 4321 when taken off hook.
Allows you to set specific settings for FXS extension.
In this case, the settings are extension numbers (based on those defined in the <fxs-branches>), and the options and their values.
Each option is separated from each other by a pipe "|" or a slash "/" and defined after the colon ":". Example:
<param name="200" value="input-volume:1|context:master-branch" />
For more information on the syntax and examples, please refer to the configuration file.
For more information visit the configuration file 'khomp.conf.xml'.
When connections are received on the boards and devices Khomp, they are forwarded by the Endpoint to specific contexts within the dialplan of FreeSWITCH®. These settings can be changed via the configuration file khomp.conf.xml, available on the FreeSWITCH configuration directory (by default, "/usr/local/freeswitch/conf/autoload_configs").
For details about the specific contexts, see section Endpoint configuration.
Below are details of how to configure the settings for incoming calls
For E1 boards, inbound contexts are predefined as option context-digital with default value as following:
<param name="context-digital" value="khomp-DD-LL"/>
This standard defines the context that links will be redirected in accordance with the number of the board and number of the link: DD is the device number (two digits), and LL is the number of the link (also with two digits).
However, it is possible to configure other inbound contexts, with different formats. There is format CCC, which means the channel number on the card (three digits), and SSSS, which represents the serial board number (with four digits).
Examples for configuration entries (khomp.conf.xml):
<!-- Serial board number and sequential link (ex: khomp-01-00) --> <param name="context-digital" value="khomp-DD-LL"/>
<!-- Serial board number and sequential link (ex: khomp-3049-00) --> <param name="context-digital" value="khomp-SSSS-LL"/>
<!-- Sequential board number and the channel (ex: khomp-00-001) --> <param name="context-digital" value="khomp-DD-CCC"/>
<!-- Receive all calls in one context (khomp-digital) --> <param name="context-digital" value="khomp-digital"/>
Follows an example the context usage inside the dialplan:
<!-- The present context in 'extensions.conf' will handle calls that come from the link 0 (first link) of the board 0. --> <context name="khomp-00-00"> . . . </context>
Another example, using the same format:
<!-- The present context in 'extensions.conf' will handle calls that come from the link 1 (second link) of the board 0. --> <context name="khomp-00-01> . . . </context>
A complete example, with a few simple actions:
<context name="khomp-00-00"> <extension name="exemplo_1"> <condition field="destination_number" expression="^1234$"> <action application="bridge" data="Khomp/b0L1/2345"/> </condition> </extension> <extension name="exemplo_2"> <condition field="destination_number" expression="^23(\d{2})$"> <action application="bridge" data="sofia/${use_profile}/11$1@${sip_from_host}"/> </condition> </extension> </context>
<context name="khomp-00-01"> <extension name="exemplo_3"> <condition field="destination_number" expression="^1111$"> <action application="bridge" data="Khomp/b0L0/2345"/> </condition> </extension> </context>
This dialplan defines that:
Just as in the context of E1 cards, inbound links are forwarded to the Endpoint FreeSwitch.
The context is pre-defined as follows, according to the file khomp.conf.xml:
<param name="context-gsm" value="khomp-DD-CC"/> ;placas GSM
<param name="context-fxs" value="khomp-DD-CC"/> ; placas FXS
<param name="context-fxo" value="khomp-DD-CC"/> ; placas FXO
For these options, DD is the device number (two digits), and CC is the channel number (also two digits). There is also the SSSS format, which represents the serial number board.
On calls originated from an FXS branch, the Endpoint searches for a valid extension (digits sent) after the DTMF # or after the timeout (option fxs-digit-timeout). That search is done in the context defined in section <fxs-options>, or if no context configured, the search is done in context defined in context-fxs.
SMS messages are received by the Khomp Endpoint and forwarded to FreeSWITCH as a normal connection but no audio, which has some variables set with information received in the message - for more information on these variables, see the documentation of the variables of the Endpoint. This context can also be modified in the same way as the above contexts.
The default value for this option follows (khomp.conf.xml):
<param name="context-gsm-sms" value="khomp-sms-DD-CC"/>
Where DD is the device number (two digits), and CC is the channel number (also with two digits). For example:
<context name="khomp-sms-00-01"> <extension name="sms"> <condition field="destination_number" expression="^s$"> <action application="log" data="DEBUG KSmsType=${KSmsType}"/> <action application="log" data="DEBUG KSmsBody=${KSmsBody}"/> </condition> </extension> </context>
For these cards, inbound links have a pre-defined context, as shown below:
<param name="context-pr" value="khomp-DD-CC"/>
In this case, DD is the device number (two digits), andCC is the channel number (also two digits). The name and format of this context can also be changed through the "context-pr" in the configuration file.
The section groups, in the configuration file khomp.conf.xml, can be used to define specific settings for certain groups of channels.
This section is detailed in the section Endpoint Configuration.
The bridge application is responsible for generating calls from the FreeSWITCH from a dialplan. This application can be used to generate calls from different Endpoints technologies, following a specific format to define destination, dialing options and define the communication Endpoint to be used.
When used for Khomp channels, the bridge string can have two, three or four fields separated by slash (/). Some example strings:
<action application="bridge" data="Khomp/B2L0/32625644"/> <action application="bridge" data="Khomp/*B2L0/32625644"/> <action application="bridge" data="Khomp/S0411/99991234"/> <action application="bridge" data="Khomp/Gpstn/99991234"/> <action application="bridge" data="Khomp/*Gpstn/99991234"/> <action application="bridge" data="Khomp/B2C58/32625644/category=4:orig=4855553232"/> <action application="bridge" data="Khomp/b0c9"/> <action application="bridge" data="Khomp/b0c1+b0c14"/> <action application="bridge" data="Khomp/r304"/>
In the first five examples, three fields have been specified; in the sixth, four fields are used; in the last three examples, just two are used.
The fields description for the Khomp Endpoint:
NOTE: The bridge allocation string with only two fields is specific to the KFXS boards, where the destination is the channel itself.
The policy for allocation of channels on the Khomp Endpoint can be specified in the bridge string itself or in the groups section (inside the configuration file khomp.conx.conf). To specify boards, links and channels, the following syntax is available (considering X, Y and Z as any numbers):
To search for extensions of cardsKFXS according to the extension number, can be used the following syntax (whereas X and Y valid extension numbers):
The capitalization of the letter 'B', 'S' or 'R' defines the search order of the channels: if capitalized, order is descending; otherwise, ascending.
As for the allocation of channels across groups, the following syntax is available:
There are cases where you need to get more channels for a particular device or particular group of extensions. For this, there is an extension available in string allocation, with respect to the use of token sum (+) to concatenate multiple stringsbinding, as follows:
<action application="bridge" data="Khomp/B1L0+B2L0/32332933"/> <action application="bridge" data="Khomp/*B2+B3+B4/99887766"/> <action application="bridge" data="Khomp/S0411+B1L0/99887766"/> <action application="bridge" data="Khomp/Gpstn1+Gpstn2/99991234"/> <action application="bridge" data="Khomp/*gOperadora1+gOperadora2/98891234"/>
This grouping is available for the application bridge and on the specification of groups. The processing of allocation takes place from left to right - except when using cyclic channel allocation, whereall the specified channels are scanned simultaneously.
Another way for allocation of channels is the cyclic and/or fair allocation, which chooses the channel that has completed the the lowest number of outgoing calls. This mode of allocation may be used by passing an asterisk (*) before the allocation string of channels (as can be seen in the section above, in the second and fifth examples).
When started with an asterisk (*), other forms of allocation (increasing, decreasing, etc) are used to decide what channel will be allocated when there are two or more channels with less number of outgoing calls.
<action application="bridge" data="Khomp/b0/99887766/orig=restricted"/>
Here's a list of variables available in the Endpoint:
Below, follows an explanation on how to use variables of Khomp Endpoint in the dialplan, to communicate and/or to receive information:
When activated, causes the Endpoint to drop Khomp collect calls through dual service (available for signaling 'R2 Digital' and FXO), through information available on the ISDN protocol and R2/MFC, or by detecting the audio call collect (available for any digital signage for E1, and GSM signaling).
This variable is useful to filter collect calls to certain extensions, and must be set before making any type of answer - applications such as playback and bridge should always be executed after setting this variable, for example.
For better functionality, is also recommended that no call status (ringback) is sent before this variable is set, so applications should be performed only after the correct setting of this variable.
This variable can be set locally and globally, both to yes or no. The adjustment of global variable to yes will drop all the collect calls, unless the particular call is set to no - this allows the creation of a global filter of collect calls, with few exceptions.
Enabling the variable in context default:
<context name="default">
<extension name="example"> . . . <action aplication="set" data="KDropCollectCall=yes"/> . . . </extension>
</context>
Enabling the variable in the global context, remembering that it must be configured in the file vars.xml:
<X-PRE-PROCESS cmd="set" data="KDropCollectCall=yes"/>
When you receive a call, can be set before sending ringback by FreeSWITCH (ie, before the run FreeSWITCH applications answer, bridge). When used in signaling R2/MFC, this variable sets the condition for B to the numeric value desired.
Exemplo:
<!-- Condition "NUMBER CHANGED" warns the caller that the number of B has changed. --> <action application="KR2SendCondition" data="3"/>
When you receive a call, is set by the Endpoint with the category received from the number that originated the call. It is set in signaling R2/MFC, and can be found anywhere in the dialplan.
Example:
<action application="log" data="DEBUG KR2GotCategory [${KR2GotCategory}]"/>
Variable adjusted by the Endpoint, and available after returning from a call made by FreeSWITCH. Has the condition of B received when making the call. Available only for signaling R2/MFC.
Example:
<action application="log" data="DEBUG KR2GotCondition [${KR2GotCondition}]"/>
Variable adjusted by the Endpoint in the context of entry, from information received by the ISDN network functionality through user-to-User Information. Contains the descriptor number of the protocol used by the other end, and usually contains the value '0 ', but this is dependent on application.
For further information, consult the specification ITU-T Q931 (more precisely, the specification table 4-26).
Example (working with the descriptor number of the protocol):
<action application="log" data="DEBUG KUserInfoDescriptor [${KUserInfoDescriptor}]"/>
Variable adjusted by the channel in the context of entry, from information received by the ISDN network functionality through user-to-User Information. Contains the actual data, which were received in the form of a string of text.
More information about this feature, see the specification ITU-T Q931.
Example (working with the data received):
<action application="log" data="DEBUG KUserInfoData [${KUserInfoData}]"/>
It is important to note that the variables are sensitive to the capitalization of letters (case sensitive).
Variable adjusted by the Endpoint. It is set in outbound connections, representing the type of answer performed by the other end. May contain the following values:
(*) This type of service is detected by signals at certain frequencies that are sent before the call comes into a mailbox, and vary by operator. The algorithm captures most of the mailboxes, but can fail if there is not a clear signal, or if it is not within the standards most commonly used;
(**) The difference between these two types of care depends on the specific configuration using the program k3lanswerinfoconfig, with the detection only based on heuristics and never with an accuracy of 100%.
List of available commands in the console for the FreeSWITCH Endpoint of Khomp:
This chapter discusses additional features of the Endpoint, related to the special features present in certain signs.
The Endpoint Khomp, and to record a type of communication channel "Khomp" also records the following items:
Performs the transfer process from the current channel number for the extension using the signaling protocol QSig (Single Step Call Transfer) for boards configured with E1 ISDN signaling (ISDN), or use the FLASH command for FXO.
The syntax follows:
<action application="KUserTransfer" data="number[,options])"/>
Example:
<action application="answer"/> <action application="KUserTransfer" data="2345"/>
The fields have the following meanings:
This application has the function of sending SMS messages through the boards of KGSM Khomp using modules and SIM cards in the board to do so. The syntax of the application is as follows:
<action application="KSendSMS" data="resource | destination | message" />
Each field can be summarized in:
After sending the message, the variables KSmsDelivered and KSmsErrorCode will contain the result of the post. For more information about these, please consult the section on variables used in the Endpoint.
Examples of use of this application are as follows:
<action application="log" data="DEBUG Sending SMS ..." /> <action application="KSendSMS" data="b0c1|99887766|Test message" />
<action application="log" data="DEBUG Sending SMS ..." /> <action application="KSendSMS" data="b0|99887766|Test message" /> <action application="log" data="DEBUG Sent? ${KSmsDelivered}" /> <action application="log" data="DEBUG Code: ${KSmsErrorCode}" /> <action application="log" data="DEBUG Desc: ${KSmsErrorName}" />
<action application="log" data="DEBUG Sending SMS ..." /> <action application="KSendSMS" data="b0+b1|99887766|Test message" />
<action application="log" data="DEBUG Sending SMS ..." /> <action application="KSendSMS" data="b0|99887766!|Test message" />
This application has the function to enable or disable the echo canceller channel.
<action application="KEchoCanceller" data="action[,options])"/>
Where:
Example usage of this application:
<action application="KEchoCanceller" data="off"/>
This application has the function to enable or disable the automatic gain control in the channel.
<action application="KAutoGainControl" data="action[,options])"/>
Where:
Example usage of this application:
<action application="KAutoGainControl" data="on"/>
This application has the function to enable or disable the suppression of DTMF channel. The syntax of the application is as follows:
<action applicatin="KDTMFSuppression" value="action[,options])"/>
Where:
It is important to note that when disabled suppression of DTMF, DTMF tones are passed inband and will not be reported to FreeSWITCH. Thus FreeSWITCH does not recognize the DTMF tones, which may result in malfunction of applications such as IVR.
Example usage of this application:
<action applicatin="KDTMFSuppression" value="off"/>
This application has the function to adjust the volume of incoming and outgoing channels Khomp, and its syntax as follows:
<action application="KSetVolume" data="<volume>"/> <action application="KSetVolume" data="<output-volume>|<input-volume>"/>
Where the fields have the following meanings:
This application has the function of setting a channel for receiving Khomp signal FAX/modem, optimizing the communication channel for data traffic. Syntax:
<action application="KAdjustForFax" data=""/>
This application does not receive parameters. Example of use:
<action application="KAdjustForFax" data=""/>
This application has the function to send faxes using digital channels or FXO connections Khomp in pre-established, and its syntax as follows:
<action application="KSendFax" data="<file>[:<file2>[:...]][|<faxid>]"/>
This application requires a license purchased separately to be used in digital (non-FXO) channels. Fields have the following meanings:
Example usage of this application:
<action application="KSendFax" data="/tmp/fax.tif:/home/root/fax2.tif,1234"/>
This application has the function of receiving digital channels or fax using the FXO Khomp, and its syntax as follows:
<action application="KReceiveFax" data="<file>[|<faxid>]/>
This application requires a license purchased separately to be used in digital (non-FXO) channels. Fields have the following meanings:
Example usage of this application:
<action application="answer" /> <action application="KReceiveFax" data="/tmp/fax.tif"/>
This communication channel is used to receive SMS and create incoming links in FreeSWITCH for each message received. This channel does not have any treatment or audio processing, and is called with five variables set:
The FreeSWITCH dialplan processing can be used to store this message in a database, run any application, among others. However, the only action accepted by this channel is shutdown (Hangup), so this incoming call should be considered a special dialplan execution without audio streams or channel allocation.
This communication channel is used to receive calls on boards passive recording (KPR family and KFXO-HI), creating incoming links on FreeSWITCH for each incoming call. This channel allows only receiving audio captured the linkby not allowing both the transmission of audio signalings as the control.
The FreeSWITCH dialplan processing can be used to record data on this link in a database, perform some special application and/or some recording application (such as record), among others. However, the only action accepted by this channel is shutdown (Hangup), so this should not be considered a common call.
This chapter presents the codes present in the channel Khomp and their meanings, used in both events as in the AMI console commands:
Reflect the state of the channel on the board. In the case of E1 links, the state may have one or more of the following:
In the case of a FXS channel, the state is defined by one of these values:
In the case of a GSM channel, the state is defined by one of the following values:
And in the case of an FXO channel, the states are as follows:
Defines the logical state for each channel, which can be:
Directly reflects the call state controlled by FreeSWITCH, which can be:
The following numeric codes are reported:
1 Unassigned number 8 Operator determined barring 10 Call barred 21 SMS transfer rejected 27 Destination out of service 28 Unidentified subscriber 29 Facility rejected 30 Unknown subscriber 38 Network out of order 41 Temporary failure 42 Congestion 47 Resources unavailable 50 Facility not subscribed 69 Facility not implemented 81 Invalid SMS transfer reference value 95 Invalid message 96 Invalid mandatory information 97 Message type non existent 98 Message not compatible with SMS protection state 99 Information element non existent 111 Protocol error 127 Interworking 128 Telematic interworking not supported 129 SMS type zero not supported 130 Cannot replace SMS 143 Unspecified TPPID error 144 Alphabet not supported 145 Message class not supported 159 Unspecified TPDCS error 160 Command cannot be actioned 161 Command unsupported 175 Unspecified TP command error 176 TPDU not supported 192 SC busy 193 No SC subscription 194 SC system failure 195 Invalid SME address 196 Destination SME barred 197 SM rejected duplicate SM 198 TPVPF not supported 199 TPVP not supported 208 SIM SMS storage full 209 No SMS storage capability in SIM 210 Error in SMS 211 Memory capatity exceeded 213 SIM data download error 255 Unspecified error 300 Phone failure 301 SMS service reserved 302 Operation not allowed 303 Operation not supported 304 Invalid PDU mode parameter 305 Invalid text mode parameter 310 SIM not inserted 311 SIM PIN necessary 312 Phone SIM PIN necessary 313 SIM failure 314 SIM busy 315 SIM wrong 320 Memory failure 321 Invalid memory index 322 Memory full 330 SMSC address unknown 331 No network service 332 Network timeout 500 Unknown error 512 Network busy 513 Invalid destination address 514 Invalid message body length 515 Phone is not in service 516 Invalid preferred memory storage 517 User terminated
1 Unallocated number 3 No route to destination 6 Channel unacceptable 8 Operator determined barring 16 Normal call clear 17 User busy 18 No user responding 19 No answer from user 21 Call rejected 22 Number changed 26 Non Selected user clear 27 Destination out of order 28 Invalid number format 29 Facility rejected 30 Response status enquiry 31 Normal, unspecified 34 No circuit channel available 38 Network out of order 41 Temporary failure 42 Switch congestion 43 Access information discarded 44 Requested channel unavailable 47 Resource unavailable 49 QoS unavailable 50 Request facility not subscribed 55 Call barred with UG 57 Bearer capability not authorized 58 Bearer capability not available 63 Service not available 65 Bearer capability not implemented 69 Request facility not implemented 70 Only restricted bearer capability available 79 Service not implemented 81 Invalid call reference value 82 User not member of UG 88 Incompatible destination 91 Invalid transit network selected 95 Invalid message 96 Missing mandatory information element 97 Message type not implemented 98 Message incompatible with state 99 Information element not implemented 100 Invalid information element 101 Message incompatible with state (2) 102 Recovery on timer expiry 111 Protocol error 127 Interworking
0 Phone failure 1 No connection to phone 2 Phone adaptor link reserved 3 Operation not allowed 4 Operation not supported 5 Phone SIM PIN required 6 Phone FSIM PIN required 7 Phone FSIM PUK required 10 SIM not inserted 11 SIM PIN required 12 SIM PUK required 13 SIM failure 14 SIM busy 15 SIM wrong 16 Incorrect password 17 SIM PIN2 required 18 SIM PUK2 required 20 Memory full 21 Invalid index 22 Not found 23 Memory failure 24 Text string too long 25 Invalid character in text string 26 Dial string too long 27 Invalid character in dial string 30 No network service 31 Network timeout 32 Network not allowed 33 Command aborted 34 Number parameter instead of text parameter 35 Text parameter instead of number parameter 36 Numeric parameter out of bounds 37 Text string too short 40 Network PIN required 41 Network PUK required 42 Network subset PIN required 43 Network subset PUK required 44 Network service provider PIN required 45 Network service provider PUK required 46 Corporate PIN required 47 Corporate PUK required 60 SIM Service option not supported 100 Unknown 103 Illegal MS #3 106 Illegal MS #6 107 GPRS service not allowed #7 111 PLMN not allowed #11 112 Location area not allowed #12 113 Roaming not allowed #13 132 Service option not supported #32 133 Registration service option not subscribed #33 134 Service option temporary out of order #34 147 Long context activation 148 Unspecified GPRS error 149 PDP authentication failure 150 Invalid mobile class 151 GPRS disconnection TMR active 256 Too many active calls 257 Call rejected 258 Unanswered call pending 259 Unknown calling error 260 No phone number recognized 261 Call state not idle 262 Call in progress 263 Dial state error 264 Unlock code required 265 Network busy 266 Invalid phone number 267 Number entry already started 268 Cancelled by user 269 Number entry could not be started 280 Data lost 281 Invalid message body length 282 Inactive socket 283 Socket already open
In this section, errors and their most common solutions are presented.
During installation of the Endpointof Khomp may occur the following messages:
K3L: WARNING: Unable to find a module for [...]
or
install: ****** THE KERNEL MODULE HAS NOT BEEN INSTALLED: ******* install: install: ** Please, untar the file kpdriver*.tar.gz located in: ** install: ** '/usr/src/khomp/' ** install: ** then check the README.txt ** install: ** for knowing how to proceed with the installation. **
In this case, you must compile the drivers manually to your system. Proceed to the item below for more information.
Just follow to the directory /usr/src/khomp, unpack the file "kpdriver_2.0.0XX.tar.gz", and follow procedures described in the file README_en.txt.
After performing compilation and installation of the module, just load it into the system, configuring the boards and start the server processes Khomp.
To load the kernel driver, you must run the following command:
# /etc/init.d/khompdrv start
To set up the boards, in turn, must run the command:
# khompwizard
This will run a setup wizard that will ask the signaling used in the system, as well as other parameters of use of the boards.
If necessary configure other additional parameters you can use the following command:
# k3lconfig
This configurator, in turn, shows all possible options for card configuration. The parameters that are not configured automatically assume the default values, and are compatible with most systems. More details about this program can be obtained from the section number '2 '.
<!-- <load module="mod_khomp" /> -->
When the board Khomp is properly configured and loaded modules khomp (explained above), remember to uncomment this line in the file.
Finally, to load the server process, simply run the following command:
# kserver start
After performing these procedures, the Endpoint is already operational, and FreeSWITCH can now be loaded.
To set specific parameters of timing and/or signaling, you can use the program "k3lconfig": simply select the card you want, and options of the boards will be presented, divided into sections and subsections for easy access. It is not necessary to effect the configuration of all parameters: default values are assumed, if not configured.
To adjust the signaling link, simply - after selecting the card - enter the "Options signaling, and then in" Signs of the line. " To choose a particular signaling, just use the direction keys (arrows) to select it, press 'space', and confirm the option by pressing 'Enter' on the "Confirm" button.
Finally, to save the modified settings, just exit the program: it will display a window with options to save the changes made or not.
Please not that the following options are required to be unchanged from the defaults:
These options are controlled by Endpoint and should be disabled in 'k3lconfig' (the default configuration).
If the loading of kernel module or Khomp services startup is not performed automatically at startup, you can perform this installation manually, creating a link for the scripts /etc/init.d/khompdrv and /etc/init.d/kserver in the system startup directory.
In the case of Debian-based distributions the script for loading kernel modules would be linked within the directory /etc/rcS.d, while the services loader would be linked within the directories /etc/rc2.d, /etc/rc3.d, /etc/rc4.d, /etc/rc5.d as follows:
# ln -s /etc/init.d/khompdrv /etc/rcS.d/S19khompdrv # ln -s /etc/init.d/kserver /etc/rc2.d/S20kserver # ln -s /etc/init.d/kserver /etc/rc3.d/S20kserver # ln -s /etc/init.d/kserver /etc/rc4.d/S20kserver # ln -s /etc/init.d/kserver /etc/rc5.d/S20kserver
Please check the rules of your distribution to initialize the services in accordance with what is expected by the start of it.
This section presents useful informations about Endpoint and related components.
The directories created/modified in this facility are:
/etc/init.d/ -- Startup scripts; /etc/khomp/ -- Firmware files and settings; /usr/local/freeswitch/conf/ -- Settings for FreeSWITCH and Endpoint; /usr/doc/khomp/ -- Docs for the boards, Channel, and utilities; /usr/sbin/ -- Utilities and server processes; /usr/lib/ -- Shared libraries; /usr/local/freeswitch/mod/ -- Endpoint module; /var/log/khomp2.1/ -- Log directory for K3L and Endpoint;
The script /etc/init.d/khompdrv is responsible for loading modules kpci9030.ko and kpex8311.ko in the kernel, which should be carried out automatically at system startup. In case of problems, check the Troubleshooting section.
For more details: http://www.khomp.com.br